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.

Building Tech Teams is produced by DayOne.

Listen to the episode

Transcript

Auto-transcribed with AI.

Jack Rodenko [0:00]: There are a religion approach and an engineering approach. And religion is like, you add new skills, you believe it works, you pray it works. And they find out that the agent doesn’t load it, doesn’t use the skill. 40% of the time it used the skill, 60% doesn’t. And the industry was already with these skills for like one and a half years. Everyone uses the skills for one and a half years, 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 [0:31]: Jack Rodenko. He’s Chief AI Officer at 10x 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 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 a 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.

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.

Jack Rodenko [1:44]: Thank you, thank you, happy to be here.

James MacDonald [1:44]: Mate, you’re probably one of the most technical AI engineers I know. So let’s go straight into the technical side of things. What’s the biggest bottleneck right now in AI engineering?

Jack Rodenko [1:48]: As always, the biggest bottleneck are humans. 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, and use it as an excuse, instead of finding the way how to make it work 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 is much, much more faster — and what is more important, it’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 good example is Atlassian. Oh my God, Australian company, which created Jira. Atlassian.

I have a couple of friends who are like senior roles in Atlassian. And what they say is that AI hasn’t sped 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 [3:13]: So the best way to open up that bottleneck then, it sounds like, is re-engineering your actual team from the ground up. So it’s not looking at how do we just roll AI over the 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?

Jack Rodenko [3:36]: Good question. But it depends on context. Ideally, yeah — like, kill everything if you can and build it from scratch using an AI-native approach. Because all we have was built around human unreliabilities. Because humans forget, humans should communicate, and that’s all processes — especially like PR, or code review, or delivery, or release tickets, all the stages when you deliver the new feature. All the stages of the feature delivery are built to overcome the 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, to get the ticket management system? Do we need the ticket management system at all? That’s a big question.

James MacDonald [4:32]: And do you use a ticket management system yourself?

Jack Rodenko [4:35]: 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 [4:49]: Which comes back to the human element, right? Absolutely. It’s changing those human behaviours, and software engineering behaviours — I’ve always done it this way, to changing it to something 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? Is it just giving everyone access to the tools to start with? Or how do we take it that next step further, next step further, next step further?

Jack Rodenko [5:24]: That’s a question which will make me a billionaire if I have an answer. Because the majority of the tools and approaches we have right now, they’re individual. Like, all these AI harnesses, setups, other stuff — they create it around one person. I have never seen any successful team which applies those policies, rules and approaches on a team level. We’re trying to do that with measurable success, but we’re far away from saying that we’re 100% there.

Claude Code — like, the team managed by Boris — they are not there as well. They’re talking about that.

James MacDonald [6:12]: Anthropic’s not there, so the likelihood of you and I getting there is —

Jack Rodenko [6:18]: The idea that you should treat Anthropic as the most advanced team — they created Claude Code, 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 built that industry, for sure. But it doesn’t mean they are the best in there.

James MacDonald [6:46]: So if we go to that — and we’ll get to what you’re building at the moment — it feels like, if I’m building at an individual level, if you’re building individually, like, let’s say I have an MD file, 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 Rodenko [7:07]: Yeah, because we start to add layers and layers of restriction. For example, imagine connect your personal Gmail account to Claude Code or Claude Desktop. That’s easy. MCP server, or authentication through OAuth Connect, you get tokens, it can access through API, get your email and answer your question.

Just imagine that you need to get to my mailbox. That means we have to build some kind of boundaries, authorisation. So for example, your agent can go and read my email, but it couldn’t expose that email without my permission. It’s like someone wants to read your email, they want to accept that, reject that, whatever. And I said, yeah, I want to accept — someone read all the team, read emails from GitHub, yeah, but other emails, I’m not sure. That kind of boundaries. And just one example, it’s hundreds, hundreds of problems, when you’re thinking about an AI system we should apply across the whole team.

James MacDonald [8:19]: Yeah, I think it’s being done significantly better at individual productivity level. You’re looking at, you know, the Hermes agent, you’re looking at even Grokbot just recently — there’s a bit of hype around there right now. Working at individual level. Actually trying to do that at company level, significantly different.

Talk to me about what you’re building at the moment, and what you’re trying to release out through the Tanex team. I’d love to hear more about this way of trying to roll out that consistency of a software development lifecycle that you’ve built and you’re currently testing.

Jack Rodenko [8:53]: Yeah. So it’s called Magus — quite a magical thing. The idea is that it’s using an already proven engineering approach and applying that to the new agent thing. Because in general, what are the skills? It’s just files. And they live in different ways — they could relate to the project, or relate to whole projects, or like company standards, or just specific tools, specific project, or specific to a user. 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 Anthropic Sonnet 3.5 or something like that, and GPT-4, already two years ago. And we started to apply that, and I was playing with one of the senior engineers in our team, working on the same project. And he was in a 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 we found out is that our agents start to fight each other. Like, whenever my agent implemented, 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 for that, because we have different harnesses.

And there, when it becomes 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 likes, but something which makes us work together, not against each other. And there the idea starts.

So we apply the same principles — package management, dependency. So all the skills, they have versions. Whenever I get from GitHub, I get the GitHub project, I just push, 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 is just one thing. There’s another one — whether that’s MCP servers, there are hooks. One more concept: skills, hooks, MCP servers, and agents — oh my gosh, sub-agents. And they have instructions, they have workflows. For example, their workflow consists of 11 steps.

And then that becomes evolved, and now we have 500 skills in that system. That sounds crazy, because one of the principles is that you shouldn’t provide too much information to the agent. But we created the system which is a curated knowledge base and approaches. For example, there are 12 principles of the software factory. They’ve been created 30 years ago, and they will not change in the near — like, 100 years. They’re fundamental principles.

But AI couldn’t dedicate that. Like, if you give it freedom, it goes to research the internet, it will find these medical discussions 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 the agent extracts and uses only when it’s needed. So probably it uses one from that 500 skills a week. But we guarantee that it’s going to follow this engineering practice — best practice, best approach, which we believe in.

And we start to make it flexible, because different teams have different beliefs and different approaches and different context. If you work with large enterprise, old project, that principle is very different to when you work in a startup.

James MacDonald [13:00]: Like, if you’re working on a startup, you’re building something from scratch, a different approach, different principle to working in an 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 — it’ll pick up the right skills, it’ll pick up the right approach?

Jack Rodenko [13:21]: That should be manually set up by the team initially. There is a risk command which tries to guess. So you push and set up. But I will not trust that. Because that thing where we still have to — when you build expectation from AI, you should be 100% sure that expectation is your expectation, not what AI guessed what is your expectation.

James MacDonald [13:46]: This is a good point. 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 — 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. And I’m not guessing — 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 for you, when you give it that context up front. And I think you mentioned this right at the start — one of the bottlenecks there is that lack of context, or the lack of ways of working with AI.

You just talked to me about your approach when it comes to that. You mentioned to me before, you talk to your LLM for a couple of hours of the morning, provide context, questioning its assumptions — rather than somebody like myself, who would just tell it, this is what I want 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 Rodenko [14:56]: Yes. And I would start from a different one. Because you start that question with, like, quoting, “I’m building, you’re building” — like, this is a crazy thing, when people are thinking that if they are not the engineer, they couldn’t build the product. It’s not truth anymore.

And what I can see — the quality, and even architecture approach, from the projects built by non-engineers who never coded before, had zero experience, is very good. It’s much better than the average, before AI, level of engineering. Even, like, the good level of software companies or software agencies. If you go to a software agency five years ago, even local in Australia, they will produce not as good as you can build right now, with zero knowledge.

There is a special term I just recently heard. It’s called “non-engineering builder”. The person has no software engineering background. I will remove that “non-engineer”, because that’s engineering. They’re just not coding anymore. And the result is very good. A lot of creators, or those builders, they for some reason are not proud, and say, oh, it’s probably like not very good output. If it works, that’s outstanding. It’s done it. That’s the criteria. It doesn’t matter.

James MacDonald [16:23]: I think it comes from the lack of understanding of what’s under the hood, because I do respect the engineering discipline. 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 Rodenko [17:06]: Actually, that’s a very unfair point. Because the shittiest software I ever saw in my life is actually enterprise. Even startups, much better. Because they collect a lot of shit together, year by year. And they don’t have a chance — even if 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 [17:36]: Do you think with AI now, some of those bigger organisations, the big legacy tech stacks, will look to start to refactor and bring it up? Because it’s like the old conversations around COBOL, right? COBOL developers get paid a fortune because there were only very few of them that could come in and actually do stuff.

Jack Rodenko [17:53]: Almost all dead already.

James MacDonald [17:55]: Exactly. But then, because of AI now, we can bridge that gap. Do you think those big organisations will start to refactor or rebuild their legacy tech stacks?

Jack Rodenko [18:05]: I don’t think so. That is where this human factor plays. Because it’s not about rebuilding, it’s about mindset. And the mindset in corporate is like, actually, if it’s working, don’t touch it, just forget about that. They’re 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. And it should be such a huge reason to do that, and proven, like, so un-risky. And AI is 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 likes hacking, playing and other stuff, and don’t afraid of that in a way.

James MacDonald [19:00]: Yeah, that’s a good point. I want to go back to how you work with it. 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. 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 where you have your testing and evals in there as well. But how do you start your day, or a project, with providing context to an LLM?

Jack Rodenko [19:32]: Yeah. I would say — I would start how it used to be three or five years ago. So I usually called it “the words”. I loved my job, that’s why I could 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 in your head, it’s like a flow. Getting from your head — I don’t even have this barrier of typing, very fast. And it’s just nearly like what Elon Musk is trying to create — I already had that. And this was like meditation. It was fun.

For now, when I work with a guy — when I had just started and hadn’t organised and didn’t know how to work, like, as I said, previously 20, 16 hours was not exhausting, I went to bed not tired at all and can do the same thing the same day. When I started to do it with AI agents, I found out it’s completely different. Just in six, seven hours, I’m done. My brain is not working. And then I realised that when you work with AI, it requires much more intense thinking, reading and understanding.

And when I got started to research and read that, I found out — it was a very good article from Atwasyem and another researcher — they said that that thinking-through development, it’s like, usually, previously was two hours a week.

James MacDonald [21:03]: To develop. And the rest of the time is just banging their tongue.

Jack Rodenko [21:08]: Yeah, you’re talking, you’re writing, you’re thinking about that. But just this intense thinking was just two hours a week. Now you’re sitting and doing that six hours in a row. And it’s so exhausting, and not fun.

And so I found a new way to do that — to not drop myself for being a software engineer. I want to still enjoy that, but trying to find another way to do it. And I found that way is that whenever you have a fresh mind, like in the morning, run a couple of sessions and start to discuss your vision with AI. And the best way to do that, the easiest, is to run in plan mode. So AI doesn’t change anything.

So we have a little bit advanced planning mode in Magus, which incorporates the architect with all this architect knowledge, and has the deep research tools as well. So it can go to the internet, or to the code base, and collect. One of the things when you’re trying to find out the solution — all your future decisions should be based on evidence, not on assumptions. And your code base is gold. That’s why it’s quick.

James MacDonald [22:28]: Yeah. And building that — the same sense.

Jack Rodenko [22:32]: Yeah. And when the AI comes to you and says, 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 analyse that, see, oh, it’s unclear, let’s do more research. And you start to do that. It’s amazing how much research you can do, and collect related information, in a small period of time, that gets you deeper and deeper on understanding what you’re going to build.

And in the end, you have a very detailed plan. I’m completely against spec-driven development, but you should know what you want to see in the end. And one of the critical things — you should find a way how to provide AI tools to validate that your result is what you’re expecting.

One of the simplest examples is, like, if we’re building a login screen, you’re saying, I want to see a login screen, I want to be able to log in with these credentials. And as a validation, please send me screenshots. Show me what’s wrong when you provide wrong credentials, how it works, how the error message works, and how it works when the good credential. That’s a very simple question. AI couldn’t finish the session without actually opening the browser and entering, clicking the button. Otherwise it’s like, I built, here’s a unit test, it worked. And when you build more complex stuff, it’s obviously way more complex.

James MacDonald [24:10]: But it’s a good foundational principle. 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. Do you get to a point where you’re providing what that end state must look like, or what “good” looks like?

Jack Rodenko [24:34]: Yes. Like, there’s acceptance criteria in our industry. Everyone who works with a junior engineer, they understand — because their lack of understanding, they don’t have in the head how it should look in the end. And you, as a senior, should provide them a very clear picture of what you’re expecting to see.

James MacDonald [24:58]: So you treat the LLM, or your agents, like a junior?

Jack Rodenko [25:03]: Sometimes. But I try to not, because that’s a bad idea. LLMs are smarter than me. But they try to cut the corner for a reason, and I could explain that later. But the idea is that this acceptance criteria is the key for you not getting back to the same session next day.

Literally, what’s happening — if you work through that initial session, which usually was 30, 40 or 60 minutes, 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 the wrong outcome — like negative prompting, how it’s called — what it shouldn’t do. For example, please do not build unit tests, it’s not working well. Do not use this approach, or this database, or whatever. Do not create your own components, for example — reuse our components library. And you should limit that. And as soon as you build that good — because it’s very hard to understand where LLM starts to sleep over, or getting off the rails, or reinvent the stuff which already there.

That’s the understanding of what is good enough for the LLM, but not overwhelming for yourself. Those skills, which you build with time. Now, when I have this two-hour conversation, I have a picture in my head. I read everything, and understand that we are on the same page with the LLM. And it starts, and this session could last usually two or three days.

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 changed on the way and why. Yeah, three days is four years. It’s a lot of work. It’s a big chunk of work, and obviously something was not as you expected or not as you planned.

James MacDonald [27:26]: And I think this is a part where people are questioning dark factories at the moment, right? There are some people that are saying, we’re going to get to that point where it’s literally human completely out of the loop. And then there are other people questioning, hey, if something goes wrong on day two, does that problem continue to get worse until — and you don’t find out until the end of day three? How do you go about building that testing, those evals, that human in the loop, into your processes?

Jack Rodenko [27:55]: In this step, it’s very, very important to understand what are you trying to improve when you add some new skills or change the approach. Because what I describe, it’s not a bare thing which I drop the code and it decides how to implement that. That’s using the dev plugin from Magus, which has 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 Claude browser plugin, for sure. No, it’s using Browserbase. And it has how to control terminal — because by default Claude Code runs all CLI tools in a background process, which means that tools couldn’t run interactive mode. And the majority of CLI tools are created in interactive mode. So for humans, you see on the screen, click there. So there is a plugin to do that. And whenever Claude Code tries to run it in the 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 CLI tools running background in non-interactive mode work completely different. They limited, they provide different output, because nobody tested that — they created it for CI/CDs, not for regular workflow. They’re very limited.

That’s a lot of examples. And that comes together in this huge system which operates for a long time and provides me reliable results. And whenever you introduce even a simple small change in that complex workflow, which is orchestrated with a complex black-box system, you have to measure if it’s helping.

And that’s a big difference right now, splitting across the whole industry. There are a religion approach and an 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 measure. Which is partly religion as well, because some parts you still have to pray and believe it works.

And for this reason, I was trying to use a lot of eval systems which exist right now. They’re immature, and mainly focused on testing your agents — which are not harnesses, different things. Agents, small things which have tools, writing somewhere in the cloud with a prompt. And that’s Promptfoo, and Braintrust, LangChain have a tool set, and a couple of other projects. Mastra, with the main SDK we’re using, that have an eval system. Everyone have evals. And they don’t test your full harness. Like, I couldn’t test my Claude Code setup and understand if those skills are actually helping or making it worse.

And it was funny, because one year ago, Vercel was trying to — one of the biggest companies here — they were trying to implement the skills, Vercel skills for everyone to use Vercel properly. And they found out that the agent doesn’t load it, doesn’t use the skill. 40% of the time it used the skill, 60% doesn’t. And the industry was already with these skills for like one and a half years. Everyone used the skills for one and a half years, and nobody knows that they don’t work at all. Like, they were the first ones who measured that, in the whole planet. Again, that’s why I’m saying that Boris’s team, amazing engineering team, but they couldn’t cover everything, and they’re not the best one. That’s why they invented the skill, but they haven’t found that they don’t work for one and a half years.

And yeah, that’s too much unknowns. You couldn’t do everything and validate everything. So what they did — they just took a very simple step. Just adding this index to your Claude map, or memory, and then the agent 100% of the time is hitting your skill. Very simple, but nobody measured.

Now, the thing is here, you have to have this eval system which has a baseline. Just measure how it works right now. And whenever you start to add new changes, ensure that it’s actually helping, not making it worse.

We got another experiment — another experiment was testing agentic memory, which I believe is the most religious branch of AI research industry.

James MacDonald [32:52]: I think it’s very controversial. Because from what I’m understanding at the moment, a lot of people are actually going back to a traditional database, like not relying on agentic memory, or memory within Anthropic, or —

Jack Rodenko [33:06]: The current wave of belief, the biggest religion right now in agentic memory, is graph. There is so little evidence it’s actually helping. And for software engineering, 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 AST. 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. And they surface it up. So when you are in the IDE, you type in the function name, and for example, doing a typo is underlined with a red thing — hey, there is no such function, or there’s a 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 a central part of your source code.

And it’s already here. It’s a real tree of all your functions, and they update in real time. Whenever you type, that should highlight the text in real time. And people trying to replace that with a graph, like Neo4j or something like that. You do it because it’s stale. It doesn’t understand the language, because every single language is different. And you already have native AST built by your language server, which you can directly feed to your agent. So it can understand, like, where do we have authentication — instantly pointing to this, this and this function, or, like, what this function does, then this function is doing that because it’s called by this app. Immediately. That graph is useless. Like, implementing a graph instead of AST is harmful. It’s making it worse. Working longer, using stale data, because the index is not updated in real time. And it’s proven by tests, by evals.

And I ran one of those evals as well. Because one of the main engineering principles is, don’t trust anyone, even yourself. If you open someone’s research, always question that. Do not believe. We are not religion. Engineering.

James MacDonald [35:38]: Yeah. Engineering. It is about that test. So if we get to the point where you’re at the moment — you’re building in tests, you’re giving that really strong context up front, going away and letting it build for a couple of days in a row. When we talk about the 10x engineer, or 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? Is it 10x? Is it 100x? Because I’m going to follow this on with the teams of the future.

Jack Rodenko [36:02]: I’m very lucky. I have the opportunity to really measure that. Because we had a so-called 10x engineering approach before AI. It’s like, we had a project which critically stuck — for example, it should be released, but it didn’t, or required fixes, but, like, business requirements impossible to implement with regular engineering. And because I’m crazy, and I have a couple of those crazy guys, we have this process where I go to Kangaroo Island, for example, close myself, sit in a room, and code, as I said, 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’re completely undistracted, completely detached, no meetings, completely in. And we were able to deliver a couple of projects.

Like, for example, there was a project which — good engineering team, but they over-engineered the solution. It was an investment application to regulate those investment funds, onboarding and calculation of the stuff. And they spent eight months. The team was something around 10 people. And they hadn’t delivered a working product. The estimation was they need one more year to do that. Which is not crazy, but from a business perspective, they were losing a lot of money, because they had this set of investors who already said, we will 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.

And then, like, six months ago, seven months ago, we were working on a project which was called Circle. And Circle was very good as a business, they struggled with technical implementation. They have three different systems which were not connected together. And they were usually using a lot of manual labour 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. We were building the system which integrated those three parts, which don’t have APIs. So this was hacking around.

And that system is complex, because it 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 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. As a human, it’s impossible to keep everything, in that way. No chance, 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 a new system from scratch. And that was a miracle. That was much more than 10x compared to the previous 10x.

And right now we’re doing the second version of that. And I spent myself two weeks doing the same amount of job that we’ve done — three of us done — three months, six months ago.

James MacDonald [39:34]: Is this because of your setup, or do you think the model changed?

Jack Rodenko [39:56]: Good question. And I was thinking about that, and saying it could be one thing. I believe that everything together. First of all, my skills grew. I’m much more proficient, work much better with AI. Models are superior compared to what we had just six months ago. Opus 5 is just serious. Unimaginably smart model. Much smarter than me. Way smarter. Sometimes I feel guilty asking it to do some simple stuff.

And three is the harness. Our Magus harness evolves every day. We measure that, we add into that. And Claude Code, which is the basement of that, evolves every day. Like, Boris’s team doing a lot of job to make it work better. And we’re leveraging that brilliant engineering outcome. And that’s the result. Such a huge multiplying part from all these directions together.

And if I was just guessing, like, okay, how performant was I six months ago, I will never guess such a difference.

James MacDonald [41:02]: If we had to say three years or five years ago versus now?

Jack Rodenko [41:06]: Oh, yeah. I was a baby.

James MacDonald [41:08]: 100x?

Jack Rodenko [41:12]: I would say — I don’t have that example, to compare, if I had built the same project five years ago. Because I’m underestimating what I understood, I’m underestimating the impact I’m getting from AI. Significantly. So I would safely say 50x.

James MacDonald [41:33]: I like that. 50x. All right. Software engineering of the future. You’re 50x now. If I’m going to build a software engineering — I’m going to build a product. I’ve got product-market fit, I’ve built my proof of concept myself. In the past, I was going to be a SaaS company, I would have scaled my engineering team to 200 engineers. Essentially, I’m going to grow this internationally, big high-scaling SaaS company. What does that engineering team look like in the future?

Jack Rodenko [42:08]: Even five years ago, I would say 200 is too much. Like, if you’re building startups, you’re probably 20 people max. Because you’re going to lose in the process. You have to move fast, and to move fast — smaller team, less communication, less losing.

And, yeah, 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 that state, and nothing stops 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, the tech is going to be good enough to deliver that value.

James MacDonald [42:53]: At what point do I, the builder, bring in somebody like you to shore it up for scale, better security, making sure that 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 Rodenko [43:09]: As I’m biased here — I’m in the industry for a long time — that’s another, you couldn’t make a 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 treat that this key is already compromised. There is no way to stop AI, to guarantee that it’s not going to go somewhere, through conversations, through works, through other stuff. There is no way — like, we don’t have tools and approaches to guarantee that it’s not happening. Especially if it’s not your API key, but it’s third party, like, for example, Notion or whatever.

It’s complicated. We are facing cybersecurity incidents every week as a development team — some of the developers using that, the key somehow. We don’t know how, and we get it through reality. We rotate them often. 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 — not secure, in reality, right now. But on the other side, it’s never been secure as well. Because when we got these new smart models, they found very critical vulnerabilities with the most important libraries we have on the planet, like OpenSSL. It powers almost every server, every machine, every communication — a little bit exaggerating, but almost every IT communication. It found a vulnerability which had not been found by the biggest, most smart human experts during the past 20 years. And it’s not a niche library, it’s a main one. And AI was able to find that.

So I would not trust people about cybersecurity. If I were building, I would not worry about it — just ask AI agent to validate and say, is your security good enough? And whenever you get cybersecurity incidents, in a row, for a long time, then probably engage someone who knows what’s happening.

James MacDonald [45:53]: My current approach is I get my ChatGPT to assess my Claude’s output. And then I get them to essentially argue against each other until we get —

Jack Rodenko [46:03]: That’s the best way to do that. Because models are biased.

James MacDonald [46:06]: It keeps asking me to review something. I’m the dumbest person in this room. I’m like, you guys review each other.

Jack Rodenko [46:13]: I don’t believe — but I feel the same. Does it make you feel good?

James MacDonald [46:20]: I’m quite happy to be the dumbest one there.

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. What’s the role of a junior engineer of the future? I’m just going to open-end it.

Jack Rodenko [46:44]: Yeah, let’s start from that. You called yourself an engineer again. If you build something, you’re an engineer. Like, no question. And I can explain, because we have three main roles who build. It’s artist, it’s scientist, and engineer. And there’s a big difference between the three.

Artists have no borders. Whenever he decides the job is done, it’s done. And it’s going to be a bad idea to build some barriers. Maybe it’s an artistic move — Dr. Seuss, he wrote these books because he was limited with just 20 words, or 30 words, and that’s a piece of art.

Scientists don’t have words for the final result. They have an approach, a way, and this way never ends. And the main tool they use is observation. They try to understand how things work. 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, scales, whatever you name it.

Engineer is different. Engineers build a 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 — if you’re building the new bridge, you have limited 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. Or twice cheaper.

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 an idea. And you don’t know how to write code. Writing code was never software engineering, from the beginning. Well — you are an engineer. You have constraints, and you create the new product with the tools you have. That’s exactly what engineering means.

And coding was never software engineering ever, in the past as well. Whenever you go to the job interview, they never ask you, write me the most beautiful function. The practical programming question was about solving the problem. Like, write me the rate limiter. Or sometimes you don’t even write the real code, you use pseudocode. 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. What value does it deliver to you? How stable is that? You care about the final product, not about the way, how good it’s for refactoring, for future support.

Obviously that’s a limitation for the business, if you make a cheat and all your resources go to maintain the product instead of creating the new feature. And that’s another side of engineering. Artist and scientist don’t have responsibility about the results they created. Engineers, they have. If you build a shit bridge, that will kill people. If you cheat software, that will kill the business. And make a lot of people struggle without the product, or without the job. And that responsibility is the biggest thing engineers have.

The same — you decided to spend your time creating the new product. It means your kids are going to have less time with you. It means your friends are going to have less time with you. You’re mentally going to be hit. It’s hard, it’s a challenge. And when people enjoy that challenge, when they’re happy to go next and next, that’s a real engineering mindset. They’re trying to solve the challenges.

James MacDonald [51:04]: So if we go back to the junior engineer — it’s a mindset thing as much as anything. It’s that problem solving. So if they can problem solve with the new tooling, how important is the whole understanding of software fundamentals?

Jack Rodenko [51:23]: I have two opinions. I wanted to say that I don’t have an opinion. I have two.

James MacDonald [51:28]: And I wouldn’t believe you if you said you didn’t have an opinion.

Jack Rodenko [51:32]: 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 engineers 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. Slow, but proven way, safe way. To push them, hold manually, at least something at some level. Not even in production, but just a way of learning.

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 — like, what SOLID is. In 20 years, if AI and harnesses are such good things as now — just imagine, they’re already smarter than me, what’s going to be in 20 years? I’m already dumber than Opus 5. I’m not talking about Fable or Mythos. And just imagine what we’re going to have in 20 years.

James MacDonald [52:49]: But then it doesn’t matter if I write poor code, because then it’s going to fix that itself.

Jack Rodenko [52:54]: You already don’t have to write the code. The idea, you have to understand what the LLM writes, to redirect. That’s the state. I haven’t written any single line of code myself for the last nine months. Literally, officially, zero lines of code. But I have delivered myself. When I can say that I was engaged more than 70% of the coding I created, or my AI created, I still consider I created it.

James MacDonald [53:23]: Yeah, well, it is, right? If it’s all that you’ve controlled and pointed out.

Jack Rodenko [53:27]: Yeah, from engineering point of view. I set it up. From that perspective, I delivered more than six or seven projects already. They’re live, and millions of people using that.

James MacDonald [53:40]: You can’t do that writing the code.

Jack Rodenko [53:42]: Yesterday I had a conversation with one of the junior developers, and he said — I watch these YouTubes, and a lot of experienced engineers, very experienced, even Uncle Bob Martin, everyone knows who that is, they’re talking about that, no writing code anymore. He said, that’s easy, because you know how good code looks like. We don’t, as a junior. As a senior, that’s solved. For us not. Is that important?

I want to measure that. I don’t know. This is the thing. If we don’t need to understand that detail and coding anymore, because it’s legacy already — that understanding helped me right now to produce a better code. But that’s possibly because the LLM is not good enough to do it themselves. Maybe they will do that in one year. And then my knowledge and experience doesn’t matter anymore.

James MacDonald [54:39]: And then the ability to write code as a junior engineer matters less than a junior engineer being a good problem solver.

Jack Rodenko [54:45]: Absolutely. And there, this is my second approach, saying that, forget about everything. I couldn’t suggest you anything, because I have legacy knowledge. The best way is to get five junior engineers, talented good guys who are problem solvers, and ask them to find the better way.

James MacDonald [55:02]: Well, I think if you have a look at some of the startups coming through — or if you have a look at YC, or any of the startups coming from non-engineering backgrounds — actually producing some pretty high-quality products, right? Because they’re problem solvers, and it comes down to that problem-solving ability. And then one other ability as well, which I think becomes even more important at the moment, is go-to-market, and sales. I’ll put those two overlapping, because if everyone can build — if everyone can build, the ability to problem solve, so you’re building something to actually solve a problem that a customer might pay for — and then the ability to sell that becomes as important as the building itself.

Jack Rodenko [55:47]: Yeah. I have three points. Point number one, why I’m saying not “quote” — because you’re limiting yourself. You’re setting up your mindset that you’re producing not-good-enough results. That’s harmful. Stop doing that. For everyone, stop doing that. Very important. This is a habit you have to kill.

Number two is that I believe, in a lot of cases, what I know and my experience makes it worse. As you said, a lot of new startups, a lot of new projects coming up, and those people don’t have that “I’m stopped, I couldn’t release without proof of validating that”. And I’m slowing myself.

James MacDonald [56:32]: So your experience is creating constraints for you.

Jack Rodenko [56:35]: Absolutely. It’s slowing me down. We don’t need to do that. It shouldn’t be that perfect. I shouldn’t follow 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.

And if you go with examples — even the tools for developers, which is Cursor, has been just acquired and was created by very young guys. Even they have an engineering background, they don’t have experience in building complex big projects. And they built a solution on top of existing VS Code. And it’s very good. And it’s even very good for an engineer like me, who is very critical, and like, ah, that’s slow, whatever. It’s a very good example that you don’t have to have this deep knowledge to create the best product on the planet.

James MacDonald [57:33]: Okay. So for a junior engineer, the engineering skills may be not as important in the future, as that problem-solving ability.

Jack Rodenko [57:40]: Software writing skills not important. Engineers still here.

James MacDonald [57:45]: Good correction. If you’re at the higher end of your team right now — for a senior AI engineer to sit alongside you, work alongside you — how important is that strong engineering background?

Jack Rodenko [57:58]: 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 decisions as me, following the same principle. So for my team right now, as soon as I haven’t validated the other assumption, that’s critical. I want someone who already knows what the shit product looks like. He already experienced the pain — pain created by his own decisions. Not being the engineer, the software engineer part of the team, just following someone’s approach or vision, who created the system and the system failed, and he spent a lot of time to fix that and learn from that.

James MacDonald [58:38]: Every single step is important. 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 — as you mentioned early today, engineering is, I guess, less exciting, more 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 take on some big things, like you mentioned, Circle — you’re talking three different systems not talking to each other, 500 edge cases. These are problems you would have never taken on before, without AI. What excites you about the future? Is it completely looking at brand new projects that have never been taken on? Is it solving complex problems? What’s exciting you for the future?

Jack Rodenko [59:35]: For me personally — like, not for humanity — I feel superpower. I had a lot of ideas in my head, and they were always there with me. Like, oh, it’s going to be cool to build this tool which will help me. Now I release it immediately. My head is empty of ideas. They’re already implemented. Like, all these Magus, it has more than 15 tools uniquely created by me, because I decided this way it works better, I measured that. And it’s here, or solving the problem. Those ideas coming from my head, here, materialising.

That superpower is extremely addictive. That’s even — the non-engineer builders we mentioned before, who have no engineering use — because everyone on the internet is saying, oh, it’s so cool, I’m writing a prompt and it’s going and filling my ATO forms, whatever. And you’re like, yeah, whatever. And then you see someone try that, and he’s saying, I actually ran my agent and they go and fill my forms. And that excitement — that’s the feeling that you actually now can do much more than you saw.

Understanding and feeling that superpower is a different thing. The same, like, regular political power, for example, it’s addictive. This is a power as well, but different — creative power. You can create 10 times more things. And as an example, two years ago, everyone thought — maybe people already forget about that — but two years ago, everyone thought, oh, what am I going to do in two years as a software engineer, if AI is writing the code, what is my job? Now I have 10 times more jobs than I had two years ago. I’m literally dying working. Because I can do more, I produce more, and I want to produce more.

James MacDonald [1:01:49]: For sure. I think it’s — the vast majority of people that have leant 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 Rodenko [1:02:04]: And in psychology, or philosophy, it’s called the horizon view. So now you have the vision of this number of branches, like 10. Whenever you achieve that, each one opens you 10 more. And it creates an immersive amount of opportunities, 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 surf, and I want to just have a beer and a chat with my friend, and just do this, and I don’t care. Me, doing more. And I’m very jealous, I want to be that kind of person. Because I couldn’t sleep if I know I could do more. I see this problem daily. You know this pain. And I see everyone who is deeply in AI right now, everyone feeling the same. It’s so hard to go to bed.

James MacDonald [1:02:57]: 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 still aren’t willing to have that vision of what’s potentially possible now versus what wasn’t possible a couple of years ago. 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 Rodenko [1:03:25]: It technically was not even — like, everything possible technically. The amount of work we should and time invest in that project, like, 10 times overcomes building the whole system from scratch.

James MacDonald [1:03:39]: You’d have no reason to do that. It might have been possible, but you wouldn’t put the budget behind it. It just doesn’t make sense.

Jack Rodenko [1:03:49]: They don’t have money for that. But now we have the tools. And, yeah, as I said, businesses afraid — 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, and go forward.

James MacDonald [1:04:13]: But if we take that a little bit further then — software engineering of the future, or businesses of the future, if there’s more and more software being built — do we see a couple of just bigger players take out everything and solve everything? Or do you think the way of the future is a lot of just everyone building their own little things, a lot of micro products, everyone runs their own little business? Or is it everyone takes over the world? Or is it AI takes over the world? I’d love your bigger-picture thinking, because I think you’re as deep in this as 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 where we’re going from an AI perspective.

Jack Rodenko [1:04:55]: Let’s start from that. We get more and more — now humanity produces probably 100 more startups a day than before. And, like, everyone can build their reliable startup right now, technically. You don’t need to have software developers. 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 [1:05:27]: Yeah, if we have a look at even the App Store a few years gone by, there would have been thousands of really well-written apps that had no market penetration, built for a product that nobody wanted.

Jack Rodenko [1:05:37]: That’s the — software was never a problem. The problem was market validation, marketing itself. And that’s why such a small amount of successful startups powered by software engineers. Because that means that the software engineer should be a visionary, or entrepreneur. That’s a completely different set of skills. And software was never a problem for startups. It was easy to create a lot of tools, not much money, like $100,000, and we have almost anything. But still, working to validate the idea.

And now, because that barrier doesn’t exist anymore, and a creator or entrepreneur could create products himself, it means we have much, much more products. And they’re more aligned with the vision of that person. And it means more of them could be validated and become successful.

And then we come to that stage — what is the future of software? Are we going to have big corporate solutions, which everyone uses, or a lot of small ones? I believe it’s going to be both. The biggest value of software is when it solves 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 things. That’s why the CRM and the business automations have a big team from Accenture sitting in your office, 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 — just imagine Salesforce.

Bad example, I hate it. Badly done product, but one more example of that huge software products. Shit. Done very badly, but because they work, and there is nothing like it — it’s still better than Excel files and paperwork, it’s bringing value to the business, at that scale, it’s a huge impact. That’s why they’re still here. So that product is going to exist, but that Accenture team which is 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 have agents inside Salesforce, and a tool set to optimise or adapt that big tool to your specific needs and business.

James MacDonald [1:08:04]: I think this is why the consultancies are really doing well at the moment. So the Accentures and the like — a bunch of AI consultancies doing really well at the moment. Because a lot of companies don’t have that internal know-how yet. The consultancies do, to a degree. And their job is to come into your organisation 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. In the future, you’re saying people have those skills themselves, and just customise for the business.

Jack Rodenko [1:08:39]: 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 [1:08:52]: Well, Anthropic’s doing a good job with that. They’ll release a new little tool, whether it be with Cowork, setting up in-set morning routines, or your morning check-ins, and your scheduled tasks and things like that. So they’ve got their product, which is allowing you and I to customise for ourselves.

Jack Rodenko [1:09:08]: That’s a very good example. Anthropic is in a worse position right now. They innovate the market, and everyone copies them. Anthropic move very fast. As a result, Claude Code is the shittiest, worst software ever created on the planet.

James MacDonald [1:09:30]: I love it.

Jack Rodenko [1:09:32]: It’s my best-loved thing, which solved my problems. It’s killing my super expensive and powerful machine, like M5 Ultra maximum setup. It’s killing that. It’s always in the fans, always, like, dying trying to do the stuff. But Claude Code is extremely simple software. It’s sending your request to the cloud, and all the hard work is happening there in a cloud. It shouldn’t even work on your machine, but one session getting from one gig of memory to three. I have no idea why. But it’s a result of very bad engineering. Very bad.

On the other side, Codex CLI, for example, is created in Rust, proficient, super fast, but nobody uses it. Because Anthropic brings innovation. It’s trying to reinvent the way we work. And the biggest value of Anthropic is not because their models are very good. Frankly speaking, if I ask you to judge outcome from, for example, GPT, or even Kimi 3, you’re not going to mention the difference. The biggest advantage of Anthropic is to find the better way to solve your problem using LLMs. That’s the advantage over the models.

James MacDonald [1:11:04]: 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. We started technical, I’d love to end technical as well. 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. 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 Rodenko [1:11:39]: I am a good engineer because of open source. I had no ability to study at Stanford. I was studying at a military university. I had no money, and that was the only option for me at that time. 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 an open source project, the Linux Kernel, for example. I have a couple of my contributions there. And I am proud to have comments about how shitty my code is from Linus themselves — like, from my contribution.

The majority of open source projects, they’re maintained 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.

All our current software is powered by open source. And I believe that’s the biggest — like, companies, Microsoft, Apple, Chrome, built on top of WebKit, which was built by Apple. They redid the KHTML from the Linux KDE project, which was an open source project. All the web now powered by open source projects. All the main libraries, open source. Someone, after the main work, comes 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-organisation.

That’s crazy — a 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 border, an IDE, to write the code. And then we have open source, IDEs there for free. And that was a big advantage for me, or other people who had no money to learn, for every student who had no money to learn. And that’s great, more and more. For now, it’s obvious, okay, all IDEs 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.

And these people who now are in charge of that, in Anthropic, OpenAI and others — they understand that, and they try to contribute back, because whatever they created is because of open source. Some open source products die, for sure — Tailwind just died recently, one of the most used. And in general, without open source, we don’t have a future. 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 [1:14:10]: I like that. I think 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, the mentorship you get from other people, it levels everybody up.

Jack Rodenko [1:14:59]: Yeah. And it’s not only about mentorship, it’s about — I use a lot of open source in my product, and I earn money from that. We always support and contribute to the libraries we use. And that’s good behaviour, being a good part of the whole industry.

James MacDonald [1:15:17]: I think it’s a nice way to finish. Thanks for your time today, mate.

Jack Rodenko [1:15:21]: Thank you.

James MacDonald [1:15:23]: 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. Religion is, 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 rollout I see in 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 around the writing code each day, but he’s 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.

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, forward slash James MacDonald AU. You won’t miss me. This episode was produced by Day One.