The Engineer Who Hasn’t Written Code in 9 Months: Jack Rudenko, 10x Labs
Jack Rudenko hasn’t written a line of code himself in nine months. In that time, his team has shipped six or seven products used by millions of people, and he says that gap, between who writes the code and who’s actually building, is the whole story of engineering right now.
In this episode of Building Tech Teams, James MacDonald sits down with Jack Rudenko, Partner and Chief AI and Technical Strategist at 10x Labs, where he has spent the past two years building an AI-native engineering practice from the ground up. They get into the project everyone called impossible before AI made it a three-month build, why working with AI agents is more exhausting than writing code ever was, and what actually separates an engineer from an artist or a scientist now that the code itself isn’t the hard part.
It’s a hands-on, practitioner’s take on what building with AI agents actually looks like day to day, not the conference-keynote version. They cover Jack’s own workflow for briefing an AI agent, why he doesn’t trust any project’s security the moment an API key exists, the “non-engineering builders” quietly out-building agencies, and why he calls Claude Code some of the worst-engineered software he’s ever used, and also the tool he loves most.
About the guest
Jack Rudenko is Partner and Chief AI and Technical Strategist at 10x Labs, where he has spent the past two years building the team’s AI-native engineering practice, Magus, from the ground up. He has deep expertise in cloud-native architecture, Go, Kubernetes and complex systems, and has delivered production platforms that would have been considered technically impossible before AI, including a three-system integration project used as a case study on this episode. Jack is also a longtime open-source contributor, including to the Linux kernel.
About the show
Building Tech Teams is hosted by James MacDonald, Managing Director of NTP Talent, and produced by Day One®, the team that helped build Blackbird Ventures’ Wild Hearts. Sister shows include First Cheque, Oversubscribed and In The Blink of AI.
Transcript Synced · click any line to jump ▾
Jack Rudenko: There are a religion approach and engineering approach. And religion is like you add new skills, you believe it works, you pray it works.
Jack Rudenko: And they find out that the agent doesn't load it, doesn't use the skill. 40% of the time it's used the skill, 60% doesn't. And the industry was already with his skills like one and a half year. Everyone uses the skills one and a half year and nobody knows that they don't work at all. I haven't written any single line of code myself for the last nine months. Literally, zero lines of code.
James MacDonald: Jack Rodenko, he's Chief AI Officer at Tanex Labs. 25 years in engineering and he's not written a line of code in nine months. In that nine months he's also shipped six projects that are live and being used by millions of people each week. He rebuilt an entire system on his own in two weeks that had taken three of them three months. That's how fast the tools have changed, that's how fast the models are getting better. He now runs a system called Magus with 500 skills in it and he thinks most of what the AI industry believes about AI engineering is not actually being measured. And then today we get into what a team is for software engineers when no one's actually typing anymore. What does a software engineering job look like? Whether it's junior engineer needs to still learn how to code, why he treats every API key he owns as already compromised. Jack's one of the most technical software engineers I know. I was so keen to share his opinions, what he's seeing in the market, and some advice for other people that are looking to grow in the AI engineering space. Let's get into it.
James MacDonald: Welcome to another episode of Building Tech Teams. On today's episode we've got Jack Rodenko, he's Chief AI Officer at 10x Labs. Welcome Jack. Thank you, thank you, happy to be here. Mate, you're probably one of the most technical AI engineers I know. So we'll let's go straight into the technical side of things. What's the biggest bottleneck right now in AI engineering?
Jack Rudenko: As always, the biggest bottleneck are humans.
Jack Rudenko: It's a lot of different directions. Number one is fear and resistance. A lot of people just trying to find the way how AI doesn't work, instead of finding the way and use it as excuse, instead of finding the way how make it works properly. Another direction is that the whole processes in the company's development engineering now was created for humans to be handled by humans. But AI much, much more faster and what is more important that's much, much more scalable. Like instead of hiring three people, you can run 50 agents. It is the same job. And that bottleneck has become a big good example and traffic. And, oh, not on tropics, this, oh my God, Australian company, which create JIRA. Atlassian. Yeah, Atlassian. I have a couple of friends who, like senior roles in tropics on Atlassian, sorry. And what they say that AI haven't speed up anything on their side just because the majority of the process was communication between humans. And they're still here. Like they're very open to enable and bring it to the company, replace humans. But we're still here.
James MacDonald: So the best way to open up that bottleneck then, it sounds like it's re-engineering your actual team from the ground up. So it's not looking at how do we just roll AI over top of an existing software engineering practice. It's actually ripping the software engineering practice apart and then building it AI native. Is that your opinion? Good question.
Jack Rudenko: But on context. Ideally, yeah, like kill everything if you can and build it from scratch using AI, AI native approach. Because all we have was built around human unreliables. Because humans forgetting, humans will, humans should communicate. And that's all processes, especially like PR or code review or delivery or release tickets in all the stages when you deliver the new feature. All the stages of the feature delivery is built around to overcome human weak parts. Now we don't have this weak parts anymore. And that should be, I don't even know, could we use JIRA for example or linear
Jack Rudenko: to get the ticket management system. Do we need the ticket management system at all? Like that's big questions. And
James MacDonald: you use the ticket management system yourself? Yes.
Jack Rudenko: No, it's still there for now. For me, yes. But I'm not saying that should be for everyone because I was with that thing for 25 years and it's very hard to drop your habits.
James MacDonald: Which comes back to the human element, right? Absolutely. Yes. It's changing those human behaviors and software engineering behaviors. I've always done it this way to changing it different. Okay, if I go at it differently, if a company has a software engineering team of at least 20 people, 20 engineers across their building product and they can't rip it all apart and build AI native from the ground up, how do you go about introducing AI into the software development lifecycle?
James MacDonald: Is it just giving everyone access to the tools to start with or how do we then take it that's next step further, next step further, next step further?
Jack Rudenko: That's a question which will make me billionaire if I have an answer. Why? Because the majority of the tools and approaches we have right now, they individual. Like all these AI harnesses, setups, other stuff, they create it around one person. I have never seen any successful team which applies that policies, rules and approaches on a team level. We trying to do that with measurable success, we far away from saying that we 100% there.
Jack Rudenko: Clot-Cot, like team managed by Boris,
Jack Rudenko: they are not there as well. They're talking about that.
James MacDonald: Anthropics not there, the likelihood of you and I getting there is closer than I am.
Jack Rudenko: The idea that you should treat Anthropic as the most advanced team. They create Clot-Cot for sure. Like that's tool number one for AI agent coding. That's the most advanced one with the most new features and inventions. They build that industry for sure. But it doesn't mean they are the best in there.
James MacDonald: So if we go to that and we'll get to what you're building at the moment. And it feels like if I'm building at individual level, if you're building individually, like let's say I have an MD for or I try to go as far as building my own company brain or individual brain and then it works on the back of that. Building that for me seems possible. Building that across a company seems very challenging.
Jack Rudenko: Yeah, because like we start to add layers and layers and restriction. For example, imagine connect your personal Gmail account to Clot-Cot or Clot-Disk. That's easy. MCP server or authentication through or also OpenDisk connect. You get it tokens, it can access through API, get your email and answer your question. Just imagine that you need to get to my mailbox. And that's mean we have to build some kind of boundaries, authorization. So for example, agent can go, your agent can go and read my email, but it couldn't expose that email without my permission. It's like someone want to read your email, they want to accept that reject that whatever. And I said, yeah, I want to accept someone read like all the team read emails from that. From GitHub. Yeah. I'm not, but other emails, I'm not sure. Like that's kind of boundaries. And just one example, it's hundreds, hundreds of problems. When you thinking about AI system, we should apply across the whole team.
James MacDonald: Yeah, I think it's being done significantly better at individual productivity level. You're looking at, you know, Hermes agent, you're looking at even Grockbot just recently. Like there's a bit of hype around there right now.
James MacDonald: Working at individual level, actually trying to do that, company level significantly different.
James MacDonald: Talk to me about what you're building at the moment and what you're trying to release out through the Tanex team. Yeah, we're building a lot. Talk to me about this, this way of trying to roll out that consistency of a software development life cycle that you've built and you're currently testing. I'd love to hear more and share more about that.
Jack Rudenko: Yeah. So it's called Magus, quite a magical thing. The idea that it's using their already proven engineering approach and apply that to new agent thing, because in general, what are the skills? It's just files. And they live in different ways. Like they could relate to the project or relate to whole projects or like company standards or just specific tools, specific project or specific to user. Yeah. Oh, there are different levels of that. And the idea, when we started two years ago using AI in production, like testing and applying that, this was in Tropic Sunnet 3.5, something like that. And GPT-4 already was two years ago. And we started to apply that and I was playing with one of the senior engineers in our team, like working on the same project. And he was in different time zone and we were working on the same project. And I was getting to bed and say, hey, here we are finished, continue. And what do we found out that our agents start to fight to each other? Like whenever my agent implement, his agent say, oh, that's not how it should work. And as a result, instead of moving together, we were fighting with each other. And the reason of that, because we have different harnesses. And there, when it's become obvious that we should have the same harness, the same setup, it could be compromised. Not something I really like or not something he really like,
Jack Rudenko: something which make us work together, not against each other.
Jack Rudenko: And there's the idea starts. So we apply the same principles, package management dependency. So all the skills, they have versions. When I went get from GitHub, I get the GitHub project, I just push, put up, set up. It's getting all the skills, the same version that everyone in the team. Whenever we introduce any changes, that changes coming to the project to GitHub, committing and getting available for every team member, wherever you just get this commit branch, whatever, you get the same skills at the same stage when this commit was created. So it's already there, all the tools there. And on top of that, skills, just one thing. There is another one. It's, whether that's mtp servers,
Jack Rudenko: servers,
Jack Rudenko: there are hooks.
Jack Rudenko: One more concept, skills, hooks, mtp servers, and agents. Oh my gosh, sub agents. Yeah. So, and they have instructions, they have workflows, for example, their workflow consists of 11 steps. And then we start to, that's become evolve. And now we have 500 skills in that system. That sounds crazy, because one of the principles that you should provide too much information to the agent, but we created the system which that's curated knowledge base and approaches. We got to our team. For example, there are 12 principle offer factory. They've been created 30 years ago, and they will not change in near like 100 years ago. They fundamental principle.
Jack Rudenko: But AI couldn't dedicate that that's like, if you get its freedom, it's go to research internet, it will find this medical discussion around the people, and it could not understand what is fundamental and what is not, what is noise. But we create that curated knowledge base, which agent get extract and use only when it's needed. So probably he is one from that 500 skills a week. But we guarantee that it's going to follow this engineering practice. Yeah, best practice, best approach, which we believe in. Yeah. And we start to make it flexible because different team have different beliefs and different approach and different context. If you work with large enterprise, old project that principle very different when you work in startup.
James MacDonald: Like if you're working on a startup, you're building something from scratch, a different approach, different principle to working in enterprise environment, legacy, tech stack. Does your system, is it smart enough to sort of understand if you give it a context on, okay, we're working on this, but rather than that, it'll pick up the right skills, it'll pick up the right approach.
Jack Rudenko: That should be manually set up by the team initially. It is the risk comment which try to guess. So you push and set setup. But I will not trust that because that thing where we still have to, when you build expectation from EI, you should be 100% sure that expectation is your expectation, not what EI guessed, what is your expectation.
James MacDonald: This is a good point. I think I've had this conversation quite a bit recently where trying to find out the differences between somebody like myself who's building, I use building loosely.
James MacDonald: But I'm building stuff, but I don't have that strong software engineering principle background, so I don't understand what great architecture looks like. I don't understand the best practice when it comes to refactoring. I don't understand. And not guessing, and I'd guess, but when I'm like, hey, you should know how to architect this for our way, it's a different approach for somebody like myself than you when you give it that context up front. And I think you mentioned this right at the start, we use like there's one of the bottlenecks there is that lack of context or the lack of ways of working with AI.
James MacDonald: You just talked to me about your approach when it comes to that. I'm going to explain that. You've mentioned me before, you talked to your LLM for a couple of hours of the morning, provided context,
James MacDonald: questioning its assumptions rather than somebody like myself who would just tell it, this is what I wanted to build and it'll go away and do best practice of what it says. You would actually question that before you let it run because the agents are good at code, but not great at that context all the time.
Jack Rudenko: Yes. And I would start from different one because you start that question with like quoting, yeah, I'm building, you're building like this is crazy thing when people are thinking that if they are not the engineer, they couldn't build the product. It's not truth anymore.
Jack Rudenko: And what I can see the quality and even architecture approach from the projects built by non-engineers who never quote before had zero experience, very good. It's much better than average before AI level of engineering with average,
Jack Rudenko: even like good level of software companies or software agencies. If you go to software agency five years ago, even a local in Australia,
Jack Rudenko: they will produce not as good as you can build right now without zero knowledge. There is a special term I just recently heard. It's called non-engineering builder.
Jack Rudenko: The person have no software engineering background. I will remove that non-engineer because that's engineering. They're just no coding anymore. And the result is very good. Well, a lot of creators or that builders, they for some reason not proud and say, oh, so probably like not very good output. If it works, that's the outstanding. It's done it. That's criteria. It doesn't matter.
James MacDonald: I think it comes from the lack of understanding of what's under the hood because I do respect the engineering discipline.
James MacDonald: So I think that's probably where my thought process comes from. And also I've been working with a lot of engineers lately and interviewing engineers and getting the differences between somebody like myself and somebody like you who actually understands it and just trying to figure out what that is. And while somebody like myself might be good for building a proof of concept or even getting something to market to test and iterate and see whether there's actually some form of product market fit, that's very different to me trying to go into an enterprise and build something that's going to go.
Jack Rudenko: Actually, that's a very unfair point because the shit is worth software I ever see in my life is actually enterprise. Even startups much better because they collect that a lot of shit together year by year. And they don't have a chance. Even they want, they don't have a chance to refactor that. It's too big, too bulky. And that's why they just build on top, on top and that's never a good idea.
James MacDonald: Do you think with AI now some of those bigger organizations are the big legacy tech stacks will look at, start to refactor in this and bring it up because it's like the old conversations around COBOL, right? Yeah. COBOL developers get paid a fortune because there was only very few of them that could come in and actually do stuff.
Jack Rudenko: Almost all dead already. Yeah, exactly.
James MacDonald: But then because of AI now, then we can bridge that gap. Do you think those big organizations will start to refactor or rebuild their legacy tech stacks?
Jack Rudenko: I don't think so. That is where this human factor plays because it's not about rebuilding, it's about mindset.
Jack Rudenko: And the mindset in corporate is like actually if it's working, doesn't touch it. I just forget about that. They happy to pay like hundreds of engineers on board just to make it working. Still going. And the risk of breaking that is going to horrify all the management layers. They have a lot of them and on the top the board members. And the shareholders. Yeah. And just it should be such a huge reason to do that and proven like just so unrisky and AI just here. Like it's a lot of risk, a lot of experiments. It's for startups, it's for inventors, it's for who like hacking, playing and other stuff. And don't afraid to that in a way.
James MacDonald: Yeah, that's a good point. I want to go back to how you work with it. Like in a traditional day, providing that context to it and then essentially letting the coding agents run all day unsupervised after you've given it that context.
James MacDonald: Talk to me about what that setup looks like for you, how you'd recommend others work with that. I want to start there and then I want to introduce like where you have your testing and evals in there as well. But yeah, how do you start your day, whether you're going to start your day or a project with providing context or an LLM?
Jack Rudenko: Yeah, I would say I would start how it used to be three or five years ago. So I usually called the wards and I called, I left my job. That's why I can do it for 20 hours. And I was not even exhausted. I was so excited and it was fun and it's not fun anymore. Why? Because when you write a code and you already have an idea on your head, it's like a flaw. Getting from your head, I don't even have this barrier of typing. Yeah, very fast. And it's just nearly like what's Elon Musk trying to create. I already had that. And this was like meditation. It was fun.
Jack Rudenko: For now, when I work with a guy, when I have just started and haven't organized and didn't know how to work, like as I said, like previously, 20, 16 hours, like was not exhausting. I went to bed not tired at all and can do the same day the same thing. When I start to do it with AI agents, I find out it's completely different. Just in six, seven hours, I'm done. My brain is not working. And then I realized that when you work with a guy, what require much more intense thinking, reading and understanding. And when I get started to research and read that, I found out it was very good article from Atwasyem and another researcher. They said that that thinking through development, it's like usually two hours, previously was two hours
James MacDonald: a week, to develop. And everyone and the rest of the time is just banging their tongue.
Jack Rudenko: Yeah, you're talking, you're writing, you're thinking about that. But just this intense thinking was just two hours a week.
Jack Rudenko: Now you're sitting and doing that six hours in a row. And it's so exhausting and not fun.
Jack Rudenko: And so I find a new way to do that, like to not drop myself for being software engineer. I want to enjoy that, still enjoy, but trying to find the other way to do that. And I found that way is that whenever you have a fresh mind, like in the morning, have to run whatever you sit in front of the couple of sessions and start to discuss your vision with AI. And the best way to do that is the easiest is to run in plan mode. So AI doesn't do, doesn't change anything. So we have a little bit advanced planning mode in Magus, which incorporate the architect with all this architect knowledge. And have the deep research tools as well. So it can go to the internet or to the quota base and collect. One of the things when you're trying to find out the solution, you should, all your future decisions should be based on evidence, not on assumptions. Yes. Yeah, I love to sum. All right, you have to build everything. You're like, oh, yeah, you're like, your quota base is gold. That's why it's quick.
James MacDonald: Yeah. And like building that. The sham sense and tell you, right?
Jack Rudenko: Yeah. And like when you start to say, the AI comes to you and say, that's what I think you should do. And you start to get, now go investigate this and this aspect, then bring to me, go to the internet, find someone who already done that, share the experience and let's collect pros and cons. And you analyze that, see there, oh, it's unclear. Let's do more research. And you start to do that. It's amazing how much research you can done. And collect like related information, collect just in small period of time, that get you deeper and deeper on understanding what you're going to build.
Jack Rudenko: And in the end, you have a very detailed plan. I'm not, I'm completely against for spec driven development, but you should know what you want to see in the end. And one of the critical thing you should find a way, how to provide to AI tools to validate that your result is what you're expecting. One of the simplest example is like, if we building login screen, you're saying, I want to see a login screen. I want us to be able to login with these credentials. And as a validation, please send me screenshots. We's wrong when you provide wrong credential, how it works, how error message works, and how it works when the good credential. That's a very simple question. Yeah, AI couldn't finish the session without actually opening the browser and entering, clicking the button. Otherwise, it's because I built, here's unit test. It's worked. And when you build more complex stuff, it's obvious way, more complex.
James MacDonald: But it's a good foundation principle on, it's coming from a place, it's got access to the code base, it's got access to the internet, it's got access to architectural skills. So you're giving it that right context up front. So it's not coming from a guessing place, right? And then it's building after that. Like, do you get to a point where you're providing what that end state must look like or what a good looks like? Or?
Jack Rudenko: Yes, like there are acceptance criteria in our industry. And that's, if you ever work with junior engineer, everyone who work with junior engineer, they understand, because their lack of understanding and like, doesn't have in the head, how it should look in the end. And you as a senior, you should provide them very clear picture. What are you expecting to see?
James MacDonald: So you treat the LLM like or your agents like a junior?
James MacDonald: Sometimes.
Jack Rudenko: But I will try to not because that's a bad idea.
Jack Rudenko: LLM's smarter than me.
Jack Rudenko: But they try to cut the corner for a reason. And I could explain that later.
Jack Rudenko: But the idea that this acceptance criteria is a key for you not getting back to the same session next day.
Jack Rudenko: Literally what's happening if you work through that initial session, which usually was 30, 40 or 60, sometimes two hours with that discussion with the AI, what are you going to build and building the acceptance criteria. And what is more important, you should identify what is wrong outcome, like negative prompting how it's called, like what it shouldn't do in a way like, for example, please do not build unit test. It's not works well. Do not use this approach or this database or whatever. Do not create your all components, for example, reuse our components library. Do not try LLM's left to right. And you should limit that. And as soon as you build that good, is that a skill? Because it's very hard to understand where LLM starts to sleep or like, sleep over while getting out of rails or reinvent the stuff which already there.
Jack Rudenko: That's cute understanding what is good enough for LLM, but not overhelming for yourself. That skills which you build with time. Now what I have like this two hours conversation, I have picture in my head. I drop it like I read everything and understand that we are on the same page with LLM. And it starts and this session could last usually day two or three.
Jack Rudenko: That's another problem as well, because in three days I don't remember anything that we discussed. So it's another skill. After it's finished work, have like this summary. What we decided, why we decided, what's done, what's proven, what's done and haven't validated and why and what have been skipped and what's it's changed on a way and why. Yeah, that's three days is four years. That's a lot of work. Yeah, and it's a big chunk of work and obviously something was not as you expected or not as you planned.
James MacDonald: And I think this is a part where people are questioning dark factories at the moment, right? There's some people that are saying, you know, we're going to get to that point where it's literally human completely out of the loop. And then there's other people questioning, hey, if something goes wrong on day two and does that problem continue to get worse until day and you don't find out until the end of day three. Whereas if you were, how do you go about building that testing that evals that human in the loop into your processes?
Jack Rudenko: I can this in this step, it's very, very important to understand what are you playing trying to improve that system when you add in some new skills or changing the approach. Because that's what I describe it's not bear thing which I drop the quote code and it's decide how to implement that. That's using their dev plugin from Magus, which have a lot of rail guards, a lot of validation steps, because how to manage and make screenshots from the browser, for example, to not use, to not use quote browser plugin for sure. No, it's using browser base. And it's have how to control terminal because by default quote code running all CLI tools in background process, which means that tools couldn't run interactive mode. And the majority of CLI tools are created interactive mode. So for humans, you see on the screen, click there. So there is a plugin to do that. And it's whenever like it's rail guard whenever quote code trying to run it's in background, they say, no, don't do that. Stop blocking that. It's like rail guards which can block action. Do it another way. And the reason because that's CLI tools which running background in non interactive mode works completely different. They limit it. They provide different output because nobody tested that. They created for CI CDs, not for regular workflow. They very limited. That's a lot of examples. And that's come up together in this huge system which operates for a long time and provide me reliable results. Yeah. And whenever you introduce even simple small change in that complex workflow, which orchestrated with a complex black box system, you have to measure if it's helping.
Jack Rudenko: And that's a big difference right now, splitting across the whole industry. There are religion approach and engineering approach. And religion is like you add new skills, you believe it works, you pray it works and continue like just religion and engineering you're trying to wait to measure.
Jack Rudenko: Which partly religion as well because some parts you still have to pray and believe it works. Yes. And for this reason, I was trying to use a lot of eval system which exists right now. Then immature and mainly focused on testing your agents, which not harnesses different things. Agents, small thing which have tools, writing somewhere in the cloud with a prompt. And that's promptful and brain trust, land chain have a tool set and a couple of other projects. I don't know. Mastra with the main SDK we're using that have eval system. Everyone have evals. And they doesn't test your full harness. Like I couldn't test my quote, quote set up and understand if that skills actually helping or making it worse. And it was funny because one year ago, Verso was trying to create one of the biggest companies here. Like and they were trying to implement the skills, Verso skills for everyone to use Verso properly. And they find out that the agent doesn't load it, doesn't use the skill. In 40% of the time it's used the skill, 60% doesn't. And the industry was already with his skills like one and a half year. Everyone use the skills one and a half year and nobody knows that they doesn't work at all. Like they were the first one who measured that. In the whole planet, again, that's why I'm saying that Boris team, amazing engineering team, but they couldn't cover everything and they not the best one. That's why they invented the skill, but they haven't found that they doesn't work for one and a half years.
Jack Rudenko: And yeah, that's too much unknowns. You couldn't do everything and validate everything. So what they did, they just very simple step. Just adding this index to your cloud map or memory and then the agent 100% times hitting your skill. Very simple, but nobody measured.
Jack Rudenko: Now, the thing is here, you have to have this eval system which
Jack Rudenko: have baseline. Just measure how it works right now. And whenever you start to add new changes, it's ensure that it's actually helping, not making it worse. We got another experiment. Oh, I'm going to get it. Another experiment was showing like testing a genetic memory, which I believe is the most religious branch of AI research industry.
James MacDonald: I think it's very controversial because I think from what I'm understanding at the moment, a lot of people actually going back to a traditional database actually like not relying on a genetic memory or memory within enthropic or...
Jack Rudenko: Like the current wave of belief, the biggest religion right now in the genetic memory is graph.
Jack Rudenko: There is so little evidence it's actually helping and it's for software engineering,
Jack Rudenko: big evidence it doesn't work. For other industry, it's not. Why? I could explain because in source code, we have this concept of AST3. So whenever you compile the language, this compiler like any one, all the languages use the same approach. It should understand what is the function, split them across, which function called another function, which arguments to properly compile that.
Jack Rudenko: And they surface it up. So when you are in IDE, you type in the function name, and for example, doing typo is underlined with a red thing. Hey, there is no such function or there's different set of arguments or this type mismatch. To understand that and surface to you is building that tree of dependency. Every token in your... And then it's using that tree to actually compile and do the binary. So it's central part of your source code.
Jack Rudenko: And it's already here. It's a real tree of all your functions and they update in a real time. Whatever you type that should highlight the text in real time. Yeah. And people trying to replace that with a graph like neonDB or something like that. You do it because it's stale. It doesn't understand the language because every single language is different.
Jack Rudenko: And you already have native AST3 built by your language server, which you can directly fit to your
Jack Rudenko: agent. So it can understand like, where we have authentication. Instantly pointing this, this and this function or like what this function does. Then this function doing that because it's called by this app. Immediately. That's useless. Like implementing GraphQL instead of AST3 is harmful. It's making it worse.
Jack Rudenko: Work longer using stale data because index is not updated in real time and make your own decisions. And it's proven by tests, by evils. Yeah. And I run one of that evils as well. Because one of the main engineering principle is doesn't trust anyone, even yourself. If you open their...
Jack Rudenko: Someone's research always questions that. Yeah. Do not believe. We are not religion. Engineering.
James MacDonald: Yeah. Engineering. It is about that test. Yeah. So if we get to the point where you're at the moment, right, you're building in tests. You're giving that really strong context up front. Going away and let it build for a couple of days in a row. When we talk about the 10x engineer of whatever it is, the engineering capability productivity output now, what's the current version of you versus the version of you of five years ago?
James MacDonald: Is it 10x? Is it 100x? Because I'm going to follow this on with the teams of the future.
Jack Rudenko: I'm very lucky. I have opportunity to really measure that. Because we had so-called like 10x engineering approach before AI. Outlooks. It's like we had a project which critically stuck, for example, it should be released, but it didn't or require fixes, but like business requirements, impossible to implement with regular engineering. And because I'm crazy and I have a couple of that crazy guys, we have this process when I go in Kangaroo Island, for example, close myself, sit in a room and call it like, as I said, like for 16, 18, 20 hours a day, for six weeks. And there are a couple of other guys who do the same with me. We completely undistract, completely detached, no meetings, no like, no like, yeah, completely in. And we were able to deliver a couple of projects. Like for example, there was a project which guys, good engineering team, but they over-engineered the solution. It was an investment application to regulate and like that investment funds, boarding and boarding and calculation of the staff. And they spent eight months. Team was something around 10 people. And they haven't delivered working product. I haven't thought far beyond expectation or estimation was they need one more year to do that. Which not crazy, but from business perspective, they were losing a lot of money because they had this set of investors who already like give us and we will let's put the money in the platform. But we spent six weeks to deliver the project. Working project in six weeks. I believe we already were 10x engineers at that time. That's the gap. Yeah. And then like six months ago, seven months ago, we were working on a project which called Circle.
Jack Rudenko: And Circle was like very good as a business. They struggled with technical implementation. They have three different systems which were not connected together. And they are usually using a lot of labor, many labor in Manila. Hundreds of people were just copying data from one system to another, making a lot of mistakes in a way. And they were struggling with scale.
Jack Rudenko: We were building the system which integrated that three parts which doesn't have APIs.
Jack Rudenko: But this was hacking around.
Jack Rudenko: And that system complex because this was trying to build the state of the data from three different systems which have different states at the same time. And do the actions instead of the people. And we spent three months doing that. Without AI, no any chance we can do that. Like zero chance, too complex, too hard, too much. Like it was 500 edge cases just to understand the complexity. Yeah, well. As a human, it's impossible to keep everything in that way. No chances, like too complex. If we had no AI, I would say we're not going to do this project. We're going to fail that. It's too complex. And it's better to rebuild new system from scratch. And that was a miracle. That was much 10x compared to previous 10x.
Jack Rudenko: And right now we're doing the second version of that. And I spent myself two weeks doing the same amount of job. We've done three of us done three months six months ago.
James MacDonald: Is this because of your setup or do you think the model change?
Jack Rudenko: Good question. And I was thinking about that and saying that could be one thing. I believe that everything together. First of all, my skills grow. I know much proficient works much better with AI. Yeah. Models are superior compared to what we have just six months. And like opposite five is just serious. Unimaginably smart model. Much smarter than me. Way smarter. Sometimes I feel guilty asking that to do some simple stuff.
Jack Rudenko: And three is the harness. Like our Magus harness evolve in every day. We measure that, we add into that and quote, quote, which basement of that. Evolve in every day. Like Boris team doing a lot of job to make it works better. And we're using a leveraging of that brilliant engineering outcome. And that's the result. Like such huge multiplying part from all this direction together.
Jack Rudenko: And if I was just guessing and like, okay, how performant I was six months ago, I will never guess such a difference.
James MacDonald: If we had to say three years or five years ago, first now.
Jack Rudenko: Oh, yeah. I was a baby.
James MacDonald: 100X?
Jack Rudenko: I would say like,
Jack Rudenko: I don't have that example. To compare if I had like build the same project five years ago, I would, that's going to be because I'm underestimating what I understood. I'm underestimating the impact I'm getting from a year. Yeah. Significantly. So I would safely say 50X.
Jack Rudenko: I like that. 100% yeah.
James MacDonald: 50X. All right. Software engineering of the future.
James MacDonald: You're 50X now. If I'm building a software engineering, I'm going to build a product. Yes. I've got product, microfit. I've built my, my proof concept myself.
James MacDonald: In the past, I was going to be a SaaS company. I would have scaled my engineering team to 200 engineers.
James MacDonald: Essentially, I'm going to grow this internationally big hop-scaling SaaS company.
James MacDonald: What does that engineering team look like in the future?
Jack Rudenko: Even five years ago, I would say 200 too much. Yeah. Like if you're building startups, you're probably 20 people is max. Because you're going to lose in the process. You have to move fast and to move fast.
Jack Rudenko: Smaller team. Less communication, less losing. And yeah,
Jack Rudenko: let's go to religion. I believe, never imagined, never seen that. But I believe you can do the product by yourself. You don't need anyone. It's already in the state and nothing stop you. You can do that. It's going to be good enough to onboard the client. If the idea brings the value to the customer,
Jack Rudenko: the tech would going to be good enough to deliver that value.
James MacDonald: At what point do me, the builder, bring in somebody like you to shore it up for scale better security,
James MacDonald: making sure that, you know, if my customer is going to start to put some of their client data in there, that I'm going to be safe from a privacy perspective.
Jack Rudenko: As I'm biased here, I'm in the industry for a long time. And that's another, you couldn't make, you couldn't make secure project anymore at all. As soon as I have your key, there is no way, like as soon as you give it to AI, you should, it's time that this key already compromised. There is no way to stop AI too. Not guarantee that it's not going to go somewhere through conversations, through works, through other stuff. Yeah, very good, like better and better to reveal that. There is no way, like we don't have tools and approaches to guarantee that it's not happening.
Jack Rudenko: Especially if it's not your API key, but it's third party, like for example, Notion or whatever.
Jack Rudenko: It's complex, like it's complicated. We are facing cybersecurity incidents every week as development team, some of developers using that team is a key somehow. We don't know how and we get it through reality. We rotate them often. Yeah, we don't keep the API keys on a file system anymore. It's not practical. Before that, you can see that all your file system only accessible by yourself. Not anymore. It's not your file system anymore on your computer. And that's like growing, growing. So you should build the system already keeping it headed, not secure reality right now. But on the other side, it's never been secure as well. Because when we get this new smart models, they found their very critical vulnerabilities
Jack Rudenko: with the most important libraries we have on the planet, like SS Open, SSL. It's powered up almost every server, every machine, every communication, like a little bit exagerating, but almost every IT communication. It's found the vulnerability which was not
Jack Rudenko: been found by the biggest, most smart human expert during past 20 years.
Jack Rudenko: And it's not a hash library, it's more one. And AI was able to find that. So I would not trust people about cybersecurity.
Jack Rudenko: If I were here and building, I would not worry about like just ask AI agent to validate and say, is your security is good enough? And whenever you get cybersecurity incidents in a role for a long time, then probably engage someone who knows what's happening.
James MacDonald: Oh yeah, my current approach is I get my chat JVT to assess my clods output. And then I get them to essentially argue against each other until we get. That's the best way to do that.
Jack Rudenko: That's because models are biased.
James MacDonald: It keeps asking me to review something. I'm the dumbest person in this room. I'm like, you guys review each other.
Jack Rudenko: I don't believe, but I feel the same. Does it make you feel good?
James MacDonald: I'm quite happy to be on the dumbest one there.
James MacDonald: The engineer of the future then. There's a lot of talk out there. Junior engineers are dead. On the flip side of that, you referred to me earlier today as potentially an engineer because I'm building. Yes. What's the role of a junior engineer of the future?
James MacDonald: I'm just going to open end it.
Jack Rudenko: Yeah, let's start from that. You called yourself as engineer again. If you build something, you're engineer. Like no question. And I can explain because we have three main roles who building. Like it's artist, it's scientist and engineer. And it's big difference between the three. Artists have no borders.
Jack Rudenko: Whenever he decide the job is done, it's done.
Jack Rudenko: And it's going to be a bad idea to build some barriers. Maybe it's artistic move. Dr. See, he wrote these books because he was limited with just 20 words or 30 words. And that's piece of art. Yeah.
Jack Rudenko: Scientists doesn't have words to the final result. They have approach, a way, and this way never ends. And the main tool they use is observation. They try to understand how things work.
Jack Rudenko: Measure that and explain. They don't have the final product and they don't have limitations as well. They just build the system, which helps them measure telescopes, like, I don't know, scales, whatever you name it. Engineer is different. Engineers build in solution using the limitations. Have limited budget, limited time, and you have to build a bridge. Limited amount of people, the education, the tools, the previous experience, like if you're building the new bridge, you have limited with the knowledge. And you have to find a way out to find the new way to build a bridge. That's engineering. It's building something not even new, but with constraints. Probably you build the same car you have, but now you have to build it twice faster. Yeah. Or twice cheaper.
Jack Rudenko: The same with software. We are building software, but with AI. That's the new constraint. And that's the constraint which makes engineering. When you're building a startup, you have constraints. You don't have money. You have idea.
Jack Rudenko: And you don't know how to write code.
Jack Rudenko: Writing code never being software engineer from the beginning. Well, you are engineer. You have constraints and you create the new product with the tools you have. That's exactly what engineering means. And we never,
Jack Rudenko: coding was never software engineering ever in the past as well. Whenever we go to the job interview, they never ask you, write me the most beautiful function. The question practical programming was about solving the problem. Like write me the rate limiter. Or sometimes you don't even write the real code. You use field of code. Like that's imaginable, not compilable code, but describe how you're thinking. How you solve the problem. Software engineering was always about solving the problem. And whenever you buy software products like Notion, you don't care how many lines of code it has.
Jack Rudenko: Which values deliver to you? How stable is that? You care about the final product, not about the way how good it's for a factory, for future support.
Jack Rudenko: Obviously that limitation for the business if you make a cheat and all your resources got to
Jack Rudenko: maintain the product instead of creating the new feature. And that's another side of engineering. Artist and scientist doesn't have responsibility about the results they created. Engineers they have. If you build a shit breach, that will kill people. If you cheat software, that will kill business. And make a lot of people struggle without the product or without the job. And that's responsibility is the biggest thing engineers have. The same, you decided to spend your time creating the new product. It's mean your kids gonna have less time with you. It's mean your friends gonna have less time with you. You are mentally gonna be hit. It's hard. It's challenge.
Jack Rudenko: And when people enjoy that challenge, when they happy to go next and next, that's real engineering mindset. They're trying to solve the challenges.
James MacDonald: So if we go back to the engineer, the junior engineer, it's a mindset thing as much as anything. It's that problem solving. Yes. So if they can problem solve with the new tooling, do they, how important is the whole understanding of software fundamentals?
Jack Rudenko: I have two opinions. I wanted to say that I don't have opinion. I have to.
James MacDonald: And I didn't, I wouldn't believe if you said you didn't have an opinion.
Jack Rudenko: Yeah. Yeah. And I want to measure them both as an engineer. So I have two assumptions. The first one is we need to teach junior engineer to make their hands dirty and understand the principles. Why, for example, decoupling is important. So feel that pain as we felt that in the past, do not make these mistakes.
Jack Rudenko: Flow, but proven way, like safe way, right? To push them hold manually, at least something at some level.
Jack Rudenko: Not even in production, but just a way of learning.
Jack Rudenko: And the second way is accept that in 20 years, all software engineers have no understanding about all that fundamental principles like solid. Nobody ever shit about what solid is. No, like that's in 20 years, if AI and harness is such good things as now, just imagine, they're already smarter than me. What's going to be in 20 years? Yeah. I'm already dumber than Opus 5. I'm not talking about Fable or Mythos. And just imagine what we're
James MacDonald: going to have in 20 years. But then it doesn't matter if I write Paul Koeb because then it's going to fix the set of rights.
Jack Rudenko: You already don't have to write the code. The idea you have to understand was LLM write to redirect. That's the state. I haven't written any single line of code myself for the last nine months, literally, like officially, zero lines of code. But I have delivered myself. Like when I can say that I was engaged more than 70% of coding I created or my two created, I still consider I created.
James MacDonald: Yeah, well, it is right. If it's all that you've controlled and pointed out.
Jack Rudenko: Yeah, from engineering point of view, what I said it up. From that perspective, I delivered more than six or seven projects already. They live and millions of people using that. Yeah.
James MacDonald: You can't do that. Yeah. I'm writing the code.
Jack Rudenko: Yesterday I had a conversation with one of the junior developers and he said,
Jack Rudenko: like, I watch his ads, YouTube and a lot of experienced engineers, very experienced, even Dr. Martin, like everyone knows who that. They're talking about that.
Jack Rudenko: No writing code anymore.
Jack Rudenko: Like he said, that's easy because you know how good code looks like. We don't as a junior. Yes. As a senior, that's solved. For us not. Is that important?
Jack Rudenko: I want to measure that. I don't know. Like this is the thing. If we don't need to understand that details and many of coding anymore, because it's legacy already. That's understanding. It helped me right now to produce a better code.
Jack Rudenko: But that's possibly because LLM is not good enough to do it themselves. Maybe they will do that in one year. And then that's my knowledge and experience doesn't matter anymore.
James MacDonald: And then the ability to write code as a junior engineer matters less than junior engineer be a good problem solver.
Jack Rudenko: Absolutely. And there, like this my second approach is saying that, forget about everything. Like I couldn't suggest you anything because I have legacy knowledge. You like the best ways to get five junior engineer talented good guys who like problem solvers and ask them to find the better way.
James MacDonald: Well, I think if you have a look at some of the startups coming through or if you have a look at YSE or any of the startups having coming from non-engineering backgrounds, actually producing, you know, some pretty high quality products, right? Because they're problem solvers and comes down to that problem solving ability. Yes. And then one other ability as well, which I think becomes even more important at the moment is go to market. And I think in sales, I'll put those two overlapping because if everyone can build,
James MacDonald: That's close. If everyone can build, everyone can build the ability to problem solve. So you're building something to actually solve a problem that a customer might pay for. Yes. And then the ability to sell that becomes as important as the building itself.
Jack Rudenko: Yeah. I have three points. Yeah. Point number one. Why I'm saying not quote because you're limited yourself. You setting up your mindset that you producing not good enough results. Yeah. It's harmful. Stop doing that. Yeah. For everyone, stop doing that. Very important.
Jack Rudenko: This is a habit you have to kill.
Jack Rudenko: Number two is that I believe in a lot of cases, what I know and my experience make it worse. Yeah. As you said, a lot of new startups, a lot of new projects coming up and that people doesn't have that.
Jack Rudenko: I'm stopped. Like I couldn't release without prof of validating that.
Jack Rudenko: Maybe with on needs. And I'm slow myself.
James MacDonald: As your experience is creating constraints for you.
Jack Rudenko: Absolutely. It's slowing me down. We don't need to do that. It shouldn't be that perfect. I shouldn't fall this principle at all. And I don't know the answer for that. Because the market validation shows that sometimes that doesn't matter anymore.
Jack Rudenko: And if you go with examples, even the tools for developers, which is cursor have been just acquired and been created by very young guys, even they have engineering background, they don't have experience in building complex big project. And they build a solution on top of existing visual code.
Jack Rudenko: And it's very good. These were good. And it's even very good for engineer like me, who are very critical and like, ah, that's slow, whatever. And it's me that's very good example that you don't have to be. You don't have to be that. Have this deep knowledge to create the best product on a planet.
James MacDonald: Okay. So for junior engineer, the engineering skills may be not as important in the future. So that problem solving ability.
Jack Rudenko: Software writing skills not important. Engineers still here.
Jack Rudenko: Good correction.
James MacDonald: If you're at a higher end, your team right now for a senior AI engineer to sit alongside you, work alongside you.
James MacDonald: How important is that strong engineering background?
Jack Rudenko: As I said, I'm old and I'm biased. So for me to sleep well, I should ensure that that guy's making the same decision as I'm like following the same principle. So for my team right now, as soon as I haven't validated other assumption, that's critical. I want someone who already know what the shit product looks like. He already experienced the pain.
Jack Rudenko: Pain created by his own decisions. Yeah. Not being the engineer who like software engineer part of the team just following someone's approach or vision who have created the system and the system failed. And he spent a lot of time to fix in that and learn from that.
James MacDonald: Every single step is important. Yeah. I think that's that learning through pain, right? And that's whether engineering or any other part of career growth or just personal growth. There's no pain, no gain. That's true, right? Not engineering only. Engineering, I've spoken about this with you previously. Engineering as you sort of, oh, actually you mentioned early today. Engineering is I guess less exciting, less boring when the AI is writing the code for you now. So for you, it's more about solving complex problems. And at 10X, you're actually there to sort of projects you're taking on some big things like you mentioned, circle you mentioned, you're talking three different systems, not talking to each other.
James MacDonald: 50 education, 500 education, 500 education, like these are problems you would have never taken on before without AI. What excites you about the future? Like is it completely looking at brand new projects that have never been taken on? Is it solving complex problem? Complex problem? What's exciting you for the future?
Jack Rudenko: For me personally, it's like not for humanity. I feel superpower. Like, oh, I had a lot of ideas in my head and they were there always with me. Like, oh, it's going to be cool to change these all greatest tool which will help me. Now I release it immediately. My head is empty of ideas. They already implemented.
Jack Rudenko: Like all these mages, it's have more than 15 tools unique created by me because I decide this way, it works better. I measure that.
Jack Rudenko: And it's here or solving the problem. That's ideas coming from my head here.
Jack Rudenko: Materializing. That superpower is extremely addictive. Yeah. That's even non-engineer builders we mentioned before who have no engineering use because everyone on the Internet saying, oh, it's so cool. Like I'm writing prompt and it's going filling my ATO forms, whatever. And we're like, yeah, whatever you see, someone try that.
Jack Rudenko: You see this like in the, like they repeat absolutely everything already told before. But he's saying, I actually run my agent and they go and fill my forms and that excitement. That's why feeling that you actually now can do much more than you saw.
Jack Rudenko: Understanding and feeling that superpower is different thing. The same like the regular political power, for example, it's addictive.
Jack Rudenko: This is the power as well, but different creative power. You can create 10 times more things. And as an example, two years ago, everyone, maybe people already forget about that, but two years ago, everyone thought, oh, what I'm going to do in two years as software engineer. If AI writing a code, what is my job? Yeah. Now I have 10 times more jobs that I have two years ago. I'm literally dying working. Yeah. And because I can do more, I produce more. And I want to produce more.
James MacDonald: For sure. I think it's gone. The vast majority of people that have learnt into AI, they've not become less busy. They've become more busy because they're capable of doing more, capable of exploring some of those projects or ideas that they wouldn't have been able to complete before.
Jack Rudenko: And it's in psychology or philosophy, it's called the horizon view. So now you have like the vision of this number of branch like 10. Whenever you achieve that, each one opens you 10 more. And it's created like immersive amount of opportunities, the ways to go forward. And I know a lot of people don't give a shit about that. A lot of people, I want to go serve. And I want to just have beer and cash with my friend and just do this. But I don't care. Make doing more.
Jack Rudenko: And I'm very jealous. I want to be that kind of person because I could sleep if I know I could do more. Oh, I see this problem daily.
Jack Rudenko: You know this pain. And I see everyone who deeply in AI right now, everyone feeling the same. It's so hard to go to bed.
James MacDonald: Yeah, I completely agree. And then that's the thing with you and Tanex. It's taking on those projects because they're the projects you wouldn't have been able to take on in the past. And other people aren't still willing to have that vision that what's potentially possible now, then what wasn't possible a couple of years ago that you wouldn't even you mentioned the other project you took on. You wouldn't have even taken it on three years ago because you just didn't have the technology or the know how to do it.
Jack Rudenko: That's technically was not even like everything possible technically.
Jack Rudenko: The amount of work we should and time invest in that project, like 10 times overcome building the whole system from scratch. Yeah.
James MacDonald: Have no reason to do that. Yeah, I just wouldn't have been like it might have been possible, but I wouldn't be you wouldn't put the budget behind it. That would be necessary. Like it just doesn't make sense.
Jack Rudenko: They don't have money for that. Yeah. But now we have we have a tools and yeah, as I said,
Jack Rudenko: businesses afraid, like people afraid, it's risky, it's unknown. And the majority of people just sitting and waiting for when it's going to be validated safe enough.
Jack Rudenko: And go forward. But if
James MacDonald: we take that a little bit further then
James MacDonald: software engineering of the future or businesses of the future, if it's a more and more software being built,
James MacDonald: is that do we see a couple of just bigger players take out everything and solve everything? Or do you just think there's a way of the future is
James MacDonald: a lot of just everyone's building their own little things, a lot of micro products, everyone sort of runs their own little business? Or is it everyone takes over the world? Or is it AI takes over the world? Love your bigger picture thinking because I think yours deep in this is anyone I know and probably have a better vision or understanding of where it's at now and probably where it's going. I'd love to get your opinion on
James MacDonald: where we're going from a AI perspective.
Jack Rudenko: As we get more and more, let's start from that. We get a more and more like now humanity produce probably 100 more startups a day than it's before. And like everyone can build their reliable startup right now technically. You don't need to have software developers.
Jack Rudenko: And but it's never been a bottleneck before. Never like I saw hundreds of well done startups and hundreds of not well done.
James MacDonald: Yo, we have a look at even the App Store a few years gone by, there would have been thousands of really well written apps.
James MacDonald: Had no market penetration built for product that nobody wanted.
Jack Rudenko: That's what's never a problem. The problem was to market validation, marketing itself. And that's why so small amount of successful startups
Jack Rudenko: powered by software engineers. Because that means that software engineer should be a vision or entrepreneur. That's completely different set of skills. And software never been a problem for startups. That was easy to create a lot of tools, not much money, like 100,000 of dollars and we have almost anything.
Jack Rudenko: Yeah, actually, but still working to validate the idea.
Jack Rudenko: And now because that barrier doesn't exist anymore. And creator or entrepreneur could create products himself. It's mean we have much, much more products. And they more aligned with the vision of that person. And it means a more successful of them could be validated and become successful. And then we come into that stage. What is the future of software? Are we going to have like big corporate solution, which everyone use, or a lot of small ones? I believe it's going to be both. The biggest value of software is when it solve your personal problem. Not like you don't care if that works for me. And a lot of businesses have a lot of very specific thing. That's why the CRM and the business automations have big team from Accenture sitting in your office and making this big product fit to your needs. And we're not going to have this anymore. We're going to have the same approach like just imagine Salesforce.
Jack Rudenko: Bad example, I hate it. Bad done product, but one more example that huge software products. Shit. Done very badly, but because they work and there is nothing like it's still better than Excel files. And paperwork, it's bringing value to the business. That the scales, it's huge impact.
Jack Rudenko: That's why they still here. So that product going to exist, but that Accenture team, which sitting in your office, will not. You're going to have a couple of guys who know your business, who are going to be not even software engineers, but they will agents inside Salesforce and tool set to optimize or adopt that big tool to your specific needs and business.
James MacDonald: I think this is why the consultancy is really doing well at the moment. So the Accenture is the other and everyone like a bunch of AR consultancies doing really well at the moment because a lot of companies don't have that internal know how yet. Yes. The consultancies do some of them. They're in degrees, but they see they have. And their job is to come into your organization at the moment and implement some form of AI. Most of the time it's just automation into your business and solve some of those custom problems that you have that other people don't. Right. Yeah. In the future, you're saying people have those skills themselves and we're just customized for the business.
Jack Rudenko: Ideally, if you're creating that big product like Salesforce, you should empower your main user to modify it. Now we have this tool. We didn't have that before, but now we have.
James MacDonald: Well, Anthropics is doing a good job with that. They'll release a new little tool, whether it be with the co-work, setting up the in-set up morning routines or your morning check-ins and your schedule tasks and things like that. So they've got their product, which is allowing you and I to customize for ourselves.
Jack Rudenko: That's a very good example.
Jack Rudenko: Anthropics is in a worse position right now. They innovate the market and everyone copies them.
Jack Rudenko: Let's push Anthropics move very fast. As a result, Cloud Cloud is the shittiest, worst software ever created on the planet.
Jack Rudenko: I love it. It's my best loved thing which solved my problems.
Jack Rudenko: It's killing my super expensive and powerful machine like M5 Ultra Maximum Setup. It's killing that. That's always in the fans, always like dying trying to do the stuff, but Cloud Cloud is extremely simple software. It's sending your request to the cloud and all hard work is happening there in a cloud. It shouldn't even work on your machine, but one session getting like from one geek of memory to three. I have no idea why, but it's a result of very bad engineering, very bad.
Jack Rudenko: On the other side, Codex CLI for example, it's created rust, proficient, super fast, but nobody uses it because Anthropics brings innovation. It's trying to reinvent the way we work and their biggest value of Anthropics, not because their models are very good.
Jack Rudenko: Frankly speaking,
Jack Rudenko: if I ask you to judge outcome from, for example, GPE, Sol,
Jack Rudenko: or even Kimi 3, you're not mentioned the difference. Biggest advantage of Anthropics is to find the better way to solve your problem using LLMs. That's the advantage of the models.
James MacDonald: Yeah. I think what they've done is made it more accessible for everyday people as well. The people that haven't traditionally been engineers to actually do some engineering themselves. We don't have long left, but we started Technicore, I'd love to end Technicore as well.
James MacDonald: Open Source, I know it's a passion area of yours. I think you've got an Open Source product that's being used by 3 million users weekly.
James MacDonald: Talk to me quickly about what you're passionate about, what you've built for Open Source, and then maybe the future of Open Source or why it's important.
Jack Rudenko: I am good engineer because of Open Source.
Jack Rudenko: I have no ability to study at Stanford.
Jack Rudenko: I was studying at a military university.
Jack Rudenko: I had no money. And that was the only option for me at that time.
Jack Rudenko: The only way, and there was zero people around me to show me the proper way to do the job. And I was super lucky to find a way to contribute to Open Source project by Kleenex Kernel, for example. I have a couple of my contributions there. And I am proud to have comments how shitty my code from Linus themselves, like from my contribution. The majority of Open Source projects, they maintain by engineers who are passionate, extremely good, the best on the planet. And you can reach their mentorship working with them together on Open Source products.
Jack Rudenko: All our current software powered by Open Source. And I believe that's the biggest unfair, like company was Microsoft, Apple, like Chrome, built on top of the WebKit, which was built by Apple.
Jack Rudenko: They redo the KHTML from Linux KDE project, which was created by, was Open Source project. All the web now powered by Open Source project, all the main libraries open source, someone after the main work, come to home. And because he was passionate, he created that software for free, for fun. And it's crazy to think that this is what we have. And this is the value of contribution and that self-help or self-organization.
Jack Rudenko: That's crazy, whole industry. A lot of people learn from that, use that tool for free, because I remember the time when you have to pay $3,000 for a ball and ID to write the code. And then we have Open Source, like, IDs there for free. And that was a big advantage for me or other people who had no money to learn, or like, for every student who had no money to learn. And that's great. More and more. For now, like, it's obvious, okay, all IDs are free, but it's never been that. Before you had to pay a lot. And that's great, the whole industry. And that's how it should be.
Jack Rudenko: And that's people who now in charge for that in this entropic, open AI and other, they understand that. And they try to contribute back, because whatever they created, because of Open Source, they, some open source product die for sure.
Jack Rudenko: Tailwind just died recently, one of the most used. And in general, without Open Source, we don't have future.
Jack Rudenko: And as we should find a way to work as engineers in the future, we should find a way how to contribute back to open source.
James MacDonald: Oh. I like that. I think it's a nice way. It's a nice message to finish on as well for the engineers to continue to give back. And I guess working with each other, as you said, like the mentorship you get from other people, it levels everybody up.
Jack Rudenko: Yeah. And it's not only about mentorship, it's about like, I use a lot of open source in my product. And I own money from that. I need, we always support and contribute to the libraries we use. And that's like good behavior, being a good part of the whole industry.
James MacDonald: I think it's a nice way to finish. Thanks for your time today, mate. Thank you.
James MacDonald: Jack is at 10x Labs. Here's what I'm taking out of that conversation. Jack said there are two approaches right now to software engineering. Religion and engineering. Religions, you add the thing, you believe it works, you pray it works, and then you keep going. Engineering is you measured actually whether it happened. Now nearly every AI roll out I see Australia at the moment is probably part religion. Not a great deal of measurement going on. Tools are being bought, the announcements are going out. The team's busier than usual, but we're not actually measuring the output and how businesses change because of it. People are busier. Jack's become busier because of it. Not along the writing code each day, but he's busier, busier in the day job. But he's actually measuring what the output looks like. So my question for everyone here, pick one thing you've added to your team in the last month, whether it be an agent, a new set of rules, a new tool. And now name the measurement and how it proved a differentiator in your business. How it proved that it provided value. And if you can't actually prove that, then maybe you're operating more with religion than engineering. It's something that I'll definitely be taking on myself. I've built things without measuring outputs and I'm sure I'm not alone. Hope you enjoyed this episode. Reach out and find Jack on LinkedIn. Really interesting guy to follow. One of the strongest AI engineers I know in Australia. Hope you enjoyed the yes episode. See you next time. This was the Building Tech Teams podcast. We release new episodes every Tuesday. Really keen for feedback on guests you'd like to see, more topics you'd like to see in depth. If you'd love to provide any form of feedback to me, find me on LinkedIn. James McDonnell at AU. You won't miss me. This episode was produced by Day One.
Related episodes
▶ Nobody Knows What to Pay Anymore: A Building Tech Teams Best-Of
▶ Why "The Number Is Never the Problem": Matt McFarlane, Founder of FNDN
▶ Why "Show Me Your Harness" Beats Any Coding Test: Adam Witanowski, AI Architect
▶ The Junior Engineer Isn’t Needed Anymore: Cloë Stanbridge, Talent Lead at Airtree
▶ How to Build AI Capability Without Chasing Every New Model — Patrick McQuaid, NGM Group
▶ Are Your People More Productive — or Just Faster? — Claudia Barriga-Larriviere, Startup Flamingo
Building Tech Teams is produced with Day One — the podcast network for founders, investors and operators. Want a show like this for your company?
Other shows worth a listen
Episodes from across the network exploring similar themes — part of the same Day One conversation.
▶In The Blink Of AI with Georgie Healy
Inside ElevenLabs: Voice AI, Cloning Ethics, and the End of the Call Centre?
26 June 2026
▶Operator AI with Zachary King
How Paul Rowsthorn Runs Airguides With an AI Co-Founder Named Amelia
27 August 2026
▶Secured by Galah Cyber
AI, Hiring, and Trust: Why Shortcuts Break Interviews
5 February 2026
Turn podcasting into pipeline
We're the team behind the Day One Network, and we helped build Blackbird Ventures' Wild Hearts. We help founders, funds and operators build trust, authority and deal flow with a show tailored to their market.