podcast

Why AI agents belong in the sandbox | Darren Shepherd

Darren Shepherd of Obot AI on why tool-call-only sandboxing is flawed and how to sandbox the whole agent loop with one policy for secrets and egress.

Listen on

Spotify

Apple Podcasts

YouTube

Jan-Niklas Wortmann

24 Sep 2026

Episode 23 · September 24, 2026 · Darren Shepherd

Why buy a sandbox when you can just launch a container? Darren Shepherd spent years at Rancher building on Kubernetes, so sandboxes looked dumb to him. Then he built his own coding agent to run 15 things in parallel without work-tree chaos, and the most interesting part of it turned out to be a sandboxing system. He had proved himself wrong.

The sharp part is where the sandbox boundary goes. The common pattern keeps the agent loop outside and sandboxes only its tool calls. Darren calls that completely flawed, because the loop itself directs code that holds secrets and talks to external systems. His answer: put the agent and its tools in one sandbox, with one policy for secrets and egress.

Darren is on X and GitHub at @ibuildthecloud. https://obot.ai/

Where does your boundary sit: around the agent itself, or only around the tools it calls?

Key Takeaways

A container is not a sandbox. Sandboxes sit one layer up: create, clone, copy files in and out, on a base image that mostly just carries language runtimes.
Parallel agents need isolation. Running many tasks at once without Git work-tree chaos means giving each task its own sandbox.
Egress is the policy surface, not ingress. Agents sit on the consuming side of services, so outbound traffic is what you control.
Keep real secrets out of reach. Hand the agent a fake key with the right shape and swap in the real one at a transparent proxy, where policy and exfiltration checks live.
Sandbox the agent loop, not only the tool calls. The loop directs code that holds secrets and talks to external systems, so the agent and its tools belong in one sandbox with one policy.
Client-side agent loops beat centralized ones. Server-side provider tools such as web search open exfiltration paths that are hard to reason about.
MCP's lasting value is the interface, not the protocol: a contract designed for AI, which is why it fits the enterprise.
Output is not progress. Letting a model barf out thousands of lines feels productive until the regressions pile up, and one estimate raised in the conversation puts a skilled engineer's real gain at around 5 to 10 percent.

Chapters

Mentioned In This Episode

Pull Quotes

Why do I need to buy a sandbox? I can just launch a container. To me, that's dumb.

The most interesting thing I built out of it was a very fancy sandboxing system. I inadvertently proved myself wrong.

You care very much about egress traffic, not ingress.

I think that perspective of the agent out of the sandbox is just kind of dumb.

The easiest thing, honestly, is just throw it all into the same sandbox. It's just way easier.

I have AI which is directing code. That code has access to secrets. It can talk to an external system. Well, why doesn't that belong in a sandbox too?

It is not a compiler. It is a tool. As a human, you are still ultimately responsible for that code.

It is so easy to lean into the model and just let it barf out code and feel all great, because you just created 10,000 lines of code and you just dug yourself into a hole.

Guest Bio

Darren Shepherd, Chief Architect & Co-Founder, Obot AI

Darren Shepherd is Chief Architect and Co-Founder of Obot AI, formerly Acorn Labs, which builds open-source infrastructure for running and governing MCP servers and AI agents in the enterprise. Before that he co-founded Rancher Labs and served as its chief architect, working on Rancher and K3s. At Acorn he built GPTScript and Clio, early tool-calling experiments that led him into MCP. He started his career in 2003 and now builds his own coding agent and sandboxing system. Find him on X and GitHub at @ibuildthecloud.

Full Transcript

Read the full transcript

I really haven't written pretty much any lines of code this whole year. Like, everything I write is AI, that's stupid. Why do I need to buy a sandbox? Like, I can just launch a container. So first, I'm just like sandboxes are dumb. It's like, it's flawed. It's completely flawed. It's not the right way to go about things. They are useless. Absolutely useless. Beyond useless, they're dangerous.

If you take somebody who doesn't know if you allow them to touch real systems. I'm cranking out code. I'm all happy I'm producing this. Then you take like, I'm beginning to regression, regression, regression. I'm like, okay, what's going on? And you just dug yourself into a hole. Companies leaning into AI and destroying their products. Quality has gone down. Everything's terrible. I'm a skilled engineer and I use AI.

I would guess it's somewhere of the range of 5 to 10%. I'm actually 5 to 10% or production. Yes. But we are so far off from figuring out how to do that. My first thought, and this is kind of how I get into most technologies. I see like, oh, they're offering this thing for sandboxes. I'm like, that's stupid. Why do I need to buy a sandbox? I can just launch a container. To me, I'm just like, that's dumb.

It's like my background is in building these types of systems, like orchestration or whatever. And so my previous company was Rancher. We did Kubernetes, which is a container. So it's like, I know containers. So I'm just like, first I'm just like, sandboxes are dumb. So it took me a while of like, kind of like fighting that of getting into like, using them of like,

realizing why it's slightly different than a container, even though it's still built on either a micro VM or container technologies. So because the reason why I got into this was I built my own coding agent. Because I was so frustrated with everyone else's coding agents where I'm just like, I'll just build my own. So I built my own. This is the second time I heard this on this podcast. Okay. Yeah.

Well, that's the, this is what we do as engineers. And like, it's kind of a beautiful thing, right? It's like, is like nobody's tools as good as my tool. Like, I'm going to build my tool, right? And then someone like JetBrains or whatever can go and build the general tool for everyone. But like, engineers love to like, you know, we love our tools, right? So I'm just like, no, like, and like my, like, anyways,

I built the coding agent. And then what I realized as I was building the coding agent was the most interesting thing I built out of it was I built a very fancy sandboxing system. And that kind of like, so I inadvertently like proved myself wrong where I'm like, oh, wait, like I need a sandboxing system because what I realized was I'm like, oh, well, obviously like, because what my main thing

when I was doing a coding agent was I just can't stand work trees because it creates so much chaos. And like, I want to do a lot of things in parallel because I can't stand waiting for the agent response. Like I typed something I have to wait like a minute or two, right? So my like, ADD brain is like, no, no, no, no, I'm going to do like 15 things in parallel. I love that. I like thrive on the chaos, right?

So I wanted to create all these parallel things. And the only way I can make that work in my mind was like, I've got to throw them into their own little sandbox, right? But once I did that, you realize like, oh, well, it's not just as simple as like, oh, spin up a container because it's like, once you put it in a container, like how do you get things in and out?

Or like, even if it's in a container, what damage can it do? Because like, are you going to put secrets in there? If you put secrets in there, then it has access to things you don't want it to do possibly. Like, or you know, are you just going to let it go out to the internet? So a sandbox is like, you have to look at it is like under the hood, it's still going to be like a micro, like a micro VM or container

technology that's the main primitive. But we've moved up one layer where like, we kind of don't, like you can look at it this way of like, VMs is like an AMI or a, a image, right? Like so a VM has like a root disk image. Like that's kind of the asset that's the containers. Have a Docker image, which is the OS file system kind of thing. When you get to sandboxes, it's just files. You just don't care anymore.

Like you, you really actually don't care too much about the Docker image. So if you look at a sandbox API, it's going to be, it's created sandbox, clone something, copy files in and out. So we're kind of getting, we're just moving up one more layer where we're just like, you know what? I don't really care about those rest of those layers anymore.

Like because I'm now to the point where I largely just care about language runtimes. If you give me a base image that has like the language runtimes in there, then I'm fine. Like I can just copy and get close. So we're kind of moving up one layer where so one thing that's very important is, is like, okay, now I just want to spin up this thing and this copy files in and out.

Because you know, I need to get things into the sandbox and out of the sandbox. But files are not the only story is like, I also basically kind of like need to get traffic in and out. And I need to get secrets in and out. So like secrets management is a big part of these sandboxing things. There's like, because like the whole thing with agents is like, you don't want to give them.

You don't, you like, you need them to do privileged things, but you don't want them to do too much. So, right. And it's like, so, so like one of the kind of like the state of the art, the common thing that most people are doing, this is like, so I'm building my own sandboxing technology because I just, I know there's kind of plenty of them out there, but this is what you know, what we do as engineers.

So just roll my own and hopefully I learned something is, um, like for secrets, it's like one of the approaches like you basically just, you give the, the, the agent like a sentinel value. It's a fake secret. It actually looks like a real secret. It has the same pattern. It'll say like SK dash whatever. And then on a transparent proxy, you swap it out with the real secret.

And this like helps with exfiltration and you can assign policy and all this stuff. So like that's one thing is secrets management. Then the other thing is, um, is a network policy. So one thing is very interesting about agents in sandboxes is that we are basically automating kind of like the client or consumption tier. It's like, we're not creating these large like, if you're thinking about like,

I like, I want to build something like ChatGPT, which is one large multi tenant agent. Like that's not going to, like whatever is in my prediction. That's not going to be the norm of agents agents are much more like single purpose. A lot of, they're more like they're sitting on the consuming side of services. They're interacting with services, right? Because they more complement the human than it is to provide.

So that's specifically like what this new agent workload is. That's not AI in general. Like because people kind of confuse the two things is like, AI has wide applicability across everything. Every single technical, technological industry will use AI in some way. But we have this new very specific thing, which is kind of like the agent, which is this new compute workload that we're slowly defining as an industry.

And so we'll, we'll work kind of work. Yeah. So, so sorry, you asked like one question and I'm just like going on forever. No, you're good. There'll be layers to the sandboxing thing. So it's so I say it's like, so you care very much about egress traffic, not ingress. Yeah. So fundamentally changes a lot of ways that we handle policy and whatnot.

Because most everything you're saying like server cloud, what you're typically looking at the ingress, you're looking at ingress. This is all about egress. So it changes the nature of like how you look at policies and stuff. So, so because for me, before like when I was saying like, well, sandboxes are dumb, they're just containers like, why do I need something new?

But when you start looking at like, what's the technology you need to solve this? You start realizing there's all these like new properties, like not uniquely new, but there's things we haven't focused on before is like, we've always known about egress. We just hadn't really cared that much about it. But like now it's the number one thing you care about with agents, kind of like all those

properties of like what is sandbox. But then I mean, because I can go, so that's like the basic thing. But then there's what you looked at like scheduling and and how you run them. They don't. The like one of the things that's really interesting. about sandboxes is like, because you'll say like, oh serverless is very similar, but anyways, I don't wanna go way too far. I'll stop and let you interject whatever,

because like, there's like so much more time, because you get into like agent in the sandbox, agent out of the sandbox, there's like so many different things. That's, yeah. That's a good point. I never thought about the agent in the sandbox. This is like my rant today is like, I'm just like keep beating this is like, if you go with Anthropic's, it's gonna tell you that the common,

the best way to do this is you have the agent out of the sandbox, and sandboxes are for tool calls. So the agent is like the, that's kind of how I always thought about it till now. That's the, that's, that is the common thinking right now, and that's how the current sandbox companies, they tailor to that model. So because they're like, oh well we can spin up a sandbox and you know, negative milliseconds or something.

You know, it's like, like they come up really fast to whatever because they're like, oh well the agent makes the tool call, but they're looking at tool calls sandboxing, which is very specific to kind of like this pure architecture where I have this LLM loop that can't kind of do anything, and then it has to call it, but I'm telling you it's like, it's flawed. It's completely flawed.

It's like, it's not the right way to go about things because I can give you some very practical examples because you have to think about sandboxing as more than just like, oh I need to control arbitrary tool call execution. Like people think about like, oh I need to put it in a sandbox because it's generating JavaScript and it's executing it, and you don't know what's gonna happen, right?

Well, Codex is always generating Python, but other than that, yes. Yeah, yeah, yeah. So it's like, so the thing is is like, so people think of it as sandboxing from that perspective of like, oh well I'm gonna generate arbitrary code and execute it, right? There's plenty of like, that's of course a very good pattern going forward or whatever, but network calls are more dangerous than just like execute.

So you have to think about like, think about sandboxing of like, well when I put that code in there and execute it, one of the attributes of a sandbox is network calls is like, you know what to confine the network. Okay, so that becomes a very important part of the policy of like what you wanted to do because if you can't make any network calls and it can't communicate with external systems,

you wanted to communicate with external systems because you wanted to accomplish things, right? But the problem that happens with agents right now is like, if you don't have a very pure architecture, you're gonna screw yourself over on the agent because if today if somebody writes a custom agent, if they write a custom agent where like, I'm saying like you like LangChain or ee or one of these agent frameworks,

you know, if you write some code, the way the developer is gonna think is like, okay, I have the LLM loop and then I have to hook up tool calls. So I have this one tool called that does code boat or whatever or code execution. So I put that into a sandbox by this other tool call which just like interacts with this other system. They just put the code directly there, right?

There in that same code that has the LLM loop, right? So now at that point, you're like, woo, I have AI which is directing code. That code has access to secrets. It can talk to an external system and it's being guided by, right? Well, why doesn't that belong in a sandbox too, right? No, that makes sense. So everyone looks at this thing of like, well, agent is out of the sandbox because it's like,

well, yeah, it's like it makes sense. It's just a dumb LLM loop. But I'm just saying like you have to talk about things from a very practical perspective because like I deal with enterprise and enterprise it's just all about like, you know, control and paranoia of what are people doing, right? So they're like, I don't know, my developers are writing code. They're deploying this like Python, that's an agent.

How do I make sure it's not good? And so it's like, if I go to them and say like, oh, well, yeah, you let the developers deploy that code and then they need to make tool calls, you know, over here in the sandbox and the sandbox is really secure. And it's like, well, how do I secure that thing? Because that's the thing that's also going out to the LLM too. And you do care about like what information is being,

you know, exiting your network, even though LLM traffic should be more trusted than people do trust it because it is stateless. And but there's concerns there or whatever. Yeah, it's like, but so, so, so for me, it's like, I think that perspective of the agent out of the sandbox is just kind of dumb. It's like, no, no, no, like, like if anything, you can be like agent in the sandbox tool calls also in a sandbox.

Because there's certain things that make that simple too. But but the easiest, the easiest thing is honestly, for me is like, oh, just throw it all into the same sandbox. It's just way easier. Seems like it, yeah. Because like they share all the same properties where it's like, I care about the network traffic, I care about access to secrets, I care, like just throw it all into the same spot, whatever.

So but the difference is like, of course, Anthropic or someone like, they're going to pitch this architecture because Anthropic is the agent, like they want to be that agent brain. But oddly enough, they're fighting against themselves because of Claude Code. Because like they're in the split mentality right now where they have, you know, OpenAI does the same thing

where you have, you have kind of like the internet hosted agentic loop. But then you also have the Codex CLI and Claude Code that agentic loop, which is client-side and the better architecture is the client-side one. It's not the centralized one. Because the centralized one just has so many controls. Because as you look at how they've tried to expand that server-side architecture of like, oh, now I have provider

tools like web search and code, they're throwing the tools server-side. But that just causes all these other problems because then it's like, well, what's the security profile of those tools, right? So I'm running like, I'm hooking up my own tools plus you have your own tools. What does that look like? Like, can I accidentally exfiltrate because like, because what if I take, you know,

like I have a tool called which accidentally grabbed for proprietary information sends out to the LLM, the LLM then puts that into a web search, right? Like I just exfiltrate. So like the profile just doesn't make sense. So this whole idea of separating these two things is I think it's like somewhat naive. Like it's not like, you know, it's kind of like,

this is how the world should be versus what the world really is. Right? So it's like, I see things going much more to a simpler pattern where it's like, throw the whole thing in there. It's way easier. Have one consistent policy, one consistent approach to it. But anyways, so yeah. Is that perspective what got you to work on an MCP orchestration platform? Or was that kind of like an afterthought of like,

this is all, could be better. And I happened to have our work on something I could improve this. No, also, so it's interesting. So I got into MCP because so the very first project I did that got me into this space of AI was this project called GPTScript, which I've like kind of archived at this time. But I was very, very fascinated with tool calling. So I'm like, I want the easiest way to do tool calling.

Like how can I make it? Because like, once I saw it's like, oh, if I have this chat, this is a genetic loop. But if I can make it very easy to hook up tools to it, I can do amazing things. So I built the system called GPTScript. And then I built this other, there's this other project that I put out there was called Clio, C-L-I-O. These are both like archive things.

Because just, but like, but it was like basically a very primitive, like it was a very early version of what Claude Code is where it's like, if you were to look at that project, like I can show some demos up, you know, I'm not going to now, but like if you're looking at some demos of it, you, you, it was like, oh, you tied, and then it had access to the shell and it could run commands.

And it was funny. At the time that I built that project, it was the coolest thing. I'm like, this is the best thing in the world. But at that time, this was years ago, years ago, developers, they still have strong feelings about AI, but they were very much opposed to AI at that point, where I'm like, developers don't give a crap about this. So I couldn't get any developers. I'd even think it was possible of like,

oh, you could use, like, I was using it to develop my own code. But I couldn't convince anyone else that I was a good idea. Anyway, so I showed that project. So sorry, so there's a long-winded way of getting into. So the reason why I got into MCP was because I built these toolcalling these things. And when MCP came out, it was like, oh, this is good.

The boundary made sense. So it was like, oh no, this makes sense of like, I've built a lot of very similar things. It makes sense for something like MCP to exist, some type of like standard. And so I kind of got into that because, you know, just architecturally it made sense. And it still does, even though most people want to say like

negative things about MCP. But it really excels very much in the enterprise space, which is like not fun. But it really, it really does well in like that space. Not so much the the coding agent, like the developers are doing. Or even the public internet, there's this idea of like, oh, websites will be replaced with MCP and maybe I don't know, but we'll see.

For what it's worth, I think the Web MCP proposal is interesting, but that's a device. I think it's fascinating. But the most valuable thing about MCP is like, it's not the protocol. So I think it's the interface. It's just the fact that like you can define an interface, which is specifically designed for us. Yes. Because there's a lot of basically, let me take this

system and shove it into AI. Right. So, so there's a lot of different ways where it's like, oh, I can just use existing APIs, or I can use a CLI, or I could screen scrape, you know, launch browser, right? Those are kind of like hacky ways to get in. But it's like, well, what if I specifically want to design for AI? There's not a like a mechanism for that besides MCP. So MCP is like, it's kind of like

open, open API for AI where it's like, this is, this is what the structure should look like, and this is how it should integrate. But the funny thing is like, the actual protocol, like, the hardest thing about MCP is connecting the two because of the context and stuff, but that's kind of, it's like a solved problem at this point now with like effectively code code code and

tool searching and deferred tool calling and stuff like that. So we've kind of figured that out. But like, but yeah, but the most important thing is just the interface and that's also why it works so well, kind of like an enterprise, because like if you look at enterprise, for example, like SOAP, you know, and S O A and EDA and all these dumb, you know, things that us web developers think are

silly, like they worked in enterprise because like contracts and how do you expose systems between teams and stuff. So MCP is kind of filling that gap where it's like, I just need a contract, you know. Yeah, from my perspective, it's over and underspecified at the same time, like, things where I think like they're utterly stupid and no one really needs them, like MCP apps,

for instance, is a fantastic example. I think it's a great flashy demo, but there's no practical use case that I can see for it. Whereas the whole authentication story is concerning your aspect as well as like MCP is fantastic for enterprise. I don't understand how authentication can be such an afterthought for a protocol like this.

Well, okay. Well, I mean, yeah, authentication is pretty much always an afterthought for everyone, because it's so hard, but that's fair enough. Yeah, but the thing that's actually amazing about MCP is that like, it was a very, very short afterthought of like, they brought in OAuth so early, and they've been so bleeding edge with the OAuth stuff, like OAuth 2.1, and now all this

weird federated identity stuff. And so that's actually one of its strengths is the OAuth story. That for a while, like the biggest selling point of MCP within like an enterprise was that it was an authentication story because OAuth is so freaking hard. And the main thing that makes it so hard with agents is this you're basically operating on behalf of the person, where typically

when we talk about like building services and stuff, there's a lot of like systems to system trust. And you don't typically carry through user identity a lot of times, even though like, you know, you're acting on behalf of someone you're doing a query for an account ID, but you don't have a strong sense of, you know, so this, so it's a very difficult problem. And it's a very

difficult solution to be honest because OAuth is just super hard to deploy. So, so it's interesting to see PC. So like so I weekly or semi-weekly, whatever host this this context podcast where we pretty much just talk about MCP stuff. And so they just released the newest spec where it's like they've kind of, I feel like they've come to the reality of what MCP, what it is,

and what it value is, trying to address both those concerns of being like overspecified. And like it's like they went too broad on features where they're like, like, oh MCP's the future of the world and we're going to do like we can do everything and like let's try this, this, this, this, you know, it's like once you release something, you know, you always get like

it has a community adoption, people jump in and are like, oh well I can get it to do this, you know, so they kind of want to co-opt it for their own concerns or whatever so you get all these crazy proposals. So, and so they kind of went a little too wide with things. Some things were just ambitious of like sampling, for example, was like that would be really great, but it's kind of like

tool calling was hard enough, staying your lane, don't try to do, you know, AI completions. So, so there's some things they're like deprecating, but then there's other things where like the protocols becoming simpler, like because it was this three-way handshake adjacent RPC, which I liked, I kind of liked the statefulness of it, but because I really thought agents would piggyback on top

of this, we would end up doing a like agent communication over MCP, that hasn't really panned out and it's stuck to just pretty much stateless tool calling and if you want some concept of session, it can be optional or done. You know, so, so they've kind of narrowed it down that like now you can run a MCP totally stateless, you don't need to have an initialize. So they've kind of

simplified it and just what it is. So, it's like, you know, it's like growing up, which is good. So, there's a lot of crazy ideas of what it could be and now we're kind of getting to reality of what it actually is and just focusing on its true value. And so. Do you think that is super speculating, but do you think that's one of the benefits of it being

part of the Linux Foundation instead of a start, more startup space, fast moving and I mean, the Linux Foundation has experience with like protocol standards and these things. Or just a pleasant side effect. I think, you know, I give a lot of credit to like David and the ones like I met David by insulting him on X, which was I said, who, what intern designed this protocol and he just replied

with like a hand of like me. So, you know, it's interesting because I could go in a long because I've heard that. a lot with Linux Foundation and stuff in the past. And it's like, they're a foundation that's very hands off on how you do things. So the projects that join there, they really kind of live and die with like, how good the team is. And so a lot of credit goes to like, like, I'm just really bad with Dan,

because I know there's other people besides like David like the other like kind of co-founders or the spec and stuff, but like, but the core team that's behind that spec is like, just it's their sane approach to it of like, I don't know, it's kind of like being kind of a level head within this chaos. And so they've, so I think the hands are really well

because it's just been, I mean, this whole space is just impossible. It's like, you know, because I've been doing this, like I started like saying my professional career like 2003. I know. So, you know, so like 20 some years. So I came in like right after the internet bust, right? Oh yeah, yeah, yeah, yeah. So it's like the dot com that destroyed, but then like, you know, like everything blew up.

I came up, it's funny because I started my career when it was a terrible time to be an engineer. It was like, you didn't, it was a worse time to be an engineer. And then to go through this kind of weird cycle where like engineer became this rock star thing. And then now we're in this kind of weird reckon, you know, reckoning moment of like, you know, maybe we're not the rock stars we thought of.

Like, you know, we thought we are, see, or maybe we still are who knows. So, yeah. Um, but yeah, so like it's weird like to just watch the trends and stuff to be like, from like kind of like before cloud and mobile and going through that whole technology thing. And then kind of like starting this new generation of AI. And so because I was there from the beginning of cloud, I'm now here at the beginning of AI.

And, and this is nuts. This is absolute insanity. What is going on? But it's fun. If you can kind of somehow keep a level head, which is so hard because like I don't say that I do it. If you follow me on X, you can just see like what a big emotional world goes try to go through like hourly, right? And so it's like, if you can keep a level head, it's super fun. It's amazing what we're doing, but it's just max.

It's just absolute madness. So, so this brings me to an interesting question. And because I, there's a saying, oh, with AI code is not free. I don't believe that. What I do think is that it to some extent levels of playing field. And what I mean with that is more like being a good engineer is now less important than it used to be. I'm not saying bad, like not an engineer will have equal results, right?

That's not what I'm saying. What I do kind of think though is like these outstanding Silicon Valley salaries versus like the average developer income. I think that playing field is kind of going to a level out with the aspect of, okay, we need engineers, but just as an example, a PM can do a starting point for an engineer. Just so, and that is just my fear of how I think this is going to be developed.

I definitely don't think development is going away. I don't, none of that nonsense. So, but where you're at? Yeah, so it's just like you say like a level of playing field. Because I think it's like, I'm going to go like complete opposite from you here. Okay. Is it like, if you look at like, okay, well, this is leveling the playing field or whatever, it's like that.

I think what AI doing is this opposite where it's like this, where it's like if you have like the hyperformers, and then you have like the low performers, the low performers are dropping off the map. Because and then you have the hyperformers. So, so what's happening is, so when I look at, so, I think this is a good thing for engineering,

a very, very good thing for engineering is what's happening is because like when I get into AI, what I realize is like, well, one is like I haven't, I haven't, you know, I can, you know, I'm not like being boastful. I have like an enough experience of doing this long enough or whatever. Where I'm like, dude, the things that I know if I combine it with AI, it's frickin' amazing. I can accomplish so much.

It's very cool, right? But I realize I'm like, because I work with more junior developers and think, you know, people with different spectrums, like, they can't do what I can do with AI because they don't have the same background. They don't have the same knowledge and context and stuff. So they can't, so, so what I'm saying is like, oh, I have more skills. So my skills have amplified.

People on the low end are struggling, but I think like if you look at like, and remember kind of making this up because I'm not 100% sure on the history here, but like, I believe like in the 80s, 90s, there was like Wall Street was a big thing, right? That was like, that's where all the bros went. Where it's like, if you want to make money, you go to Wall Street.

You go to Wall Street and then so there's this big boom where everyone wanted to be on Wall Street and they're a stock trader and whatever. And everyone's making money and doing cocaine or whatever, whatever, you know. So then there is this shift where Silicon Valley and the tech market, that's where the bros went, where it's like, that's where you can make money. Like, that's where the money's being made, right?

So the whole engineering industry like exploded in that like, I kind of feel like there's tons of people who are engineers who should not be engineers. It's like, they're there. I would agree with that too. They're there because it was a good job. You can make money, whatever you're a smart person, you can kind of apply to it, right? You can, but like, I think what's happening with AI is it's like,

is the engineering domain is going to kind of get sifted out of like, those people who didn't really know what they were doing, but they could get by, they are useless now. Absolutely useless. Beyond useless, they're dangerous. If you take somebody who doesn't know, they're dangerous. If you allow them to touch real systems, right? So, so this is core engineering because there's this whole thing,

because like when you get into say like, Oh, a PM can start programming, that's a whole different ground. Like, if you look at core engineering, which is like, the objective of my job is to build systems, right? Like, it's different than let's say like a programmer who does like AI, right? Like their job is like, they really want to do data science and except and they program as a side effect of it, right?

And they program to accomplish that. But in like core engineering, like my, my job is to kind of build and command systems or whatever is like that. I think is getting refined down to we really just need the very smart people. Like the people who love it have passion for it and AI makes it better. And then you kind of lose that lower end or whatever. But when you get to something like web development,

where it's like, Oh, I just need a website. Like this is a very well known thing, right? Like the technologies, the patterns are kind of already established. I don't need developers to write so much react code anymore. That's that's right. So, so, so it's kind of what because like this explosion of like, because web dev, for example, is one of those areas where it's like, it's kind of kind of get gutted because like,

I mean, I don't, I don't want it like because I know very smart brilliant people work in that area. But there's like that kind of like boot camp industry where it's like, Oh, just learn some react and whatever. Where it's like, you're just kind of like the code monkey. You're like, Oh, yeah, I can type the things and do the problem. Like that's that's all gone now. And so those things which are like well known,

the process has already been established. AI will replicate like crazy. So building web sites, AI is going to mostly take over. And you're right. And in a lot of app development, a lot of app development. will you know shift towards like a PM can have a more You know like the kind of the business person can have more direct interaction with that but at some point

You still need an engineer to really know what's going on one million percent Absolutely, so that so what's gonna happen is like so the core engineering is kind of getting refined Where's like we still need really good people and we've always struggled to find brilliant people The top is going to explode in that you now have

You know before let's say I got a million people building web apps. I'm now going to have like a hundred million people producing web apps So I kind of still need like a million people who know what they're doing, you know, so it's like The the reach of of programming is expanding But that doesn't that doesn't change the core people who like really understand the guts of what's going on

So it's like so I'm wondering a little bit though So if I if I think about like like peak engineering activities, right like people that have right compiler or something like oh yeah or like Linux kernel like way smarter than I am. I have no fucking idea about these things right? I'm I think These skills are less relevant like These like highly technical skills like they are going to be

Less relevant to the extent of negligible um, and that's kind of where I meant with like leveling the playing field like I think like these like like people that I consider super smart I Think I'm going to have less often impact than like an engineer that has like a solid understanding of the system At the same time I agree with you like

There's going to be like a sifting outside in that sense. I think there's maybe like a Leveling I stick with my saber novel level little bit of a level The thing where I would like to challenge you if you describe um like kind of like this okay amplification with AI which I fundamentally don't disagree with um Do you believe

I think it was the click up CEO and I've asked several people this because I think it's so utterly stupid Do you believe in the hundred X developer due to AI yeah? I mean I do But it's kind of BS right like it's relative It's relative right because this is the thing is like what's happened? Let's say in the sas industry a lot of sas companies like a lot of I saw this on X the other day

Some were saying like hey all like my This kind of like indie sas market where people are building these indie like sas sites and trying to build it is like they're all struggling Because like once anyone can do it it has no value so so it's so the thing is is like it's so it's relative where it's like Okay, like my dad programmed computers in like the 60s or early 70s, right

So if I compare what I do to what he does I'm a thousand X developer compared to what you guess right so What does it mean because the problem is is like you know you're gonna be a hundred X developer And you're still not gonna accomplish enough It's like it's relative like it's just because this is what thing is interesting is is if you look at technology different trends

So we went through all these errors and we won't mainframe then distributed which is PCs then server then cloud mobile right If you look at all of those trends and I think I'm fairly right here, but I'm not very well good at research is that If you look at mainframes for example, we have more mainframes than we've ever had If then we if you look at servers we have more servers than we've ever had with

Not these main technology trends they don't stop right so they don't They just don't They either slow down their growth, but the growth continues or The next it's typically the next generation grows at such a rate that it that people forget about the last thing But it's still there right so when you say like compile like some people who do compilers or whatever That's not gonna go away because we still agree we still

Like we need so we only have so many people in this world who are actually really good at building like You know you only get like someone who can build like a Golang or really Innovate at that level or whatever. There's only so many people and We're honestly not getting that money me, you know people talking about overpopulation was on it's like all the things

I think they project predict we're gonna peak out of like 12 billion or something We're now concerned about populous collapse right so it's like We have enough work to sustain the people to do that today and they'll continue to be valuable It's just you know what AI brings is like it's so say it's like I just think it's bringing

The ability to kind of like command computers to a larger market that just creates a whole new set of like problems or whatnot So it's like if you're good Like if you really are passionate and you love what you're doing and you're good at something There's a good chance there's gonna be a need for that like But but there is kind of like but if you're really passionate about building and react websites

You know, so like there is some things that are gonna get like impacted but but it's kind of like You know, it's like what? You know, we still need very smart people who understand systems because because when I think it's interesting because you talk about this thing Where's like oh well the CEO now they could build their own website but but you know what like

Though you know that's the CEO does not want to do is they do not want to spend all their time worrying about the website Right so so they just because somebody can do it doesn't mean that's like that's The best use of their time So it's like it it all kind of works out so it's like yeah I do believe in a hundred x developer or whatever but we're all hundred x so it's like the the when I say a hundred x I

Or to me at least it kind of implies that with oh my base level performance without AI And then I use Claude Code or something and out of If I before that Manager push out one PR a day now I manage to publish like hundred PR so they and I I While this might be like logistically possible I think it is BS in that sense That we don't have organizational structures to sustain that on all levels and

Product quality being one of the biggest one I would venture to guess that if you took any even I say like I'm a skilled engineer and I use AI What is my productivity gain over over it right? I would guess it somewhere in the range of five to ten percent. I'm actually five to ten percent more productive. Yes. Yes I think it can go way higher But we are so far off from figuring out how to do that

It is this is what I think is fascinating because like When AI you know entered the you know space like as engineers We just love to like say prove it wrong right? It was just like that would never work So so what I did was I'm like because I have other same thoughts It's like how's that gonna work like it just it just didn't fund a major like how's computers gonna replace what I do Love a lot of crap

So I took the route of like it's like one smart. I'm gonna make it do that like I'm gonna try to figure out how to like prove myself wrong I'm gonna So I'm like like I'm just gonna drink the cool aid and I'm gonna try this and I'm gonna you know just like You know just Close my eyes to how terrible this is right like try the like oh

I'm just gonna bite code it if like if it's a black box and I put this in and I get this out Like what that that should be good who cares? It's crap right So I've I've tried really hard to do that and I've been through all the phases of seeing like it doesn't really work It but it really depends on the context really depends on the one fixed

That is a lot of nuance to that yeah told me agree but but overall what I'm seeing is like this idea of like It's like AI is a compiler. No, no, no, no, it's not. It is not a compiler. It is a tool. As a human, you are still ultimately responsible for that code. And so what it is, IDEs, whatever, tooling company, is like, because I remember, I got into development when Java was taking off.

And there was a lot of developers who came into the market, especially with contract or offshore and stuff like that, whereas dumb Java developers only knew anything with ID. They're like, I can just, I clicked this button and somehow it runs and I typed this code. And they're abstracted away from everything. And they were kind of useless. You need a lot, but they're kind of useless.

It's like, so it's kind of the same thing with AI words. If you don't understand what AI is actually doing, you're gonna get screwed. It doesn't work out because there's so many things. But I look and I see I'm like, this is definitely possible because I've been, I honestly like me career-wise, kind of got a little like jaded of like bored, because I went through cloud, the whole cloud thing.

And I'm just like, at the tail end of cloud, I just had this thing where I'm like, I'm just not seeing any more innovation. It's like, what's going, like, it just seems dead. It's like, every time I'm like, oh, there's this cool new thing. I look at it and I'm like, it's nothing new. It's like, so the, oh, crap, I just lost my train of thought or whatever. Oh, yeah, lost my train of thought.

I know, I do, I was growing with that. So let me chime in then here. I have one thesis that I think the T-shaped developer is going to be more valuable than before with AI. It was one thing that I definitely see is like, and we touch on that slightly, it's like that the boundaries between like the traditional roles, PM, QA, engineer, designer, whatever, with AI is kind of getting more and more blurry.

There's absolutely still a need for all of these roles in some capacity, but they hand over and these kind of things are definitely going to be more seamless in one way or another. So from that aspect, I think it is immensely valuable if you have like good understanding in terms of system design, can like these architectural skills, fundamental, foundational, computer science skills. Yeah, computer science.

But then pairing that, so here's the thing, like I wrote a lot of react application. I was never like the most react the developer, right? I think that is now more valuable knowing like how to compose this and what to look out for. And instructor AI to figure these things out and like mitigate that instead of like, oh, we now need the hardcore react developer to solve these problems.

Because I keep saying, it's a very difficult, because it's like, well, how are you gonna get engineers into this? How do we train the next thing of this? Yes, right? And that's what I was going with this. Okay. So what I keep saying on X is I'm like, I really do think we need to return to the fundamentals because in my career, it got to this point where I was like, ask through college,

like I'm not a big, I got a degree in college and I don't have any respect for the universities. Like that's just my bias. I just did not have any respect for it. I checked off a box. I got the degree because at that time, that's what you're supposed to do. And so when boot camps became a thing, I was much more in the thought of like, I don't know, go learn programming. If you enjoy it, learn the skill,

all that really matters is experience, get in there, somehow get your foot in the door and you'll be fine, right? I think it's wrong now. Like I think we need to go back to like, no, you really need to know what you're doing. You don't know the fundamentals. Interesting. You're kind of screwed. And I look at this from this perspective of like, like when I went to a computer school or whatever,

I learned about like, oh, I was like sorting algorithms and red black trees and all these, like, you know, you learn about those algorithms and stuff. And at that time, I'm like, well, this is BS because it's like, whatever, I just call sort. I call sort in its sorts. I don't know how it's sorted. And so it's like, so the fact that I actually love algorithms and data structures, whatever. So that's one thing I loved.

But I always have this mental conflict. It's like, well, what does it really matter? Right? But I kind of feel like we're kind of this point now where it's like, you need to understand the mechanisms and it's something like the sorting algorithms and the ON notation and stuff like that so that you can make the proper decisions on how to design the system. Because there's this fundamental, like,

I don't know, like information theory problem or something when it comes to building a system is like, AI can't just, like, if you say, build me a website, it's not possible. It does not have enough information to build the website, right? So it's the same thing with software design and architecture and stuff like that. So it's like, I build distributed systems. They're very difficult.

And it's like, so, but even if you're not doing a distributed system, even just software design, it's like, you have to make choices. There's like, there's no perfect answer for anything. You're building a system for a specific context for a specific context. I mean, I mean, I'm putting it back here are and you need to tell, because AI is not, does it fundamentally cannot? It can tell you the pros and cons,

but somebody has to make the choice. Look, that's the human aspect you bring to it. So, the thing that's weird is, I think you have to return to the fundamentals. So, I like said this stupid thing on X, where it's like quote, tweeting someone, who's like, you still need the program and I'm like, no, you don't need the program. You need to learn fundamentals. And then everyone argue with me,

which makes sense of like, well, how do you learn, how do you learn, how can you understand programming if you never learned? So, it's this thing that's like, you need to understand the fundamentals. You need to spend some time programming. But what I find is like, you can be very, as long as you're very good in one language, like we spent some time in one language

or a couple of paradigms, you know, functional versus, you know, an narrative, then that extrapolates to it. So, it's like, as long as you kind of master it in one way, but like, because like, I understand like, I'm the most comfortable in Golang. So, it's like, if you put out a bunch of Golang, you know, because I programmed so much in it, it used to be this way with Java, but I don't do that anymore.

Like with Golang, it's like, oh, I can just immediately, it's kind of like, it's my native tongue word. It's like, I understand the inflection where it's like, oh, that's slightly different, that's what this code is doing, right? So, I know Golang really well, but I can take those concepts and what I'm doing right now is I apply it to Rust, and like, I don't like Rust as a language.

I don't want to program it as a language, but it has its applicability and certain domains and it's now I'm using AI to generate Rust. And I can command that, even though I honestly, I could not write it from scratch because I just don't know the syntax well enough. I had the same experience with Kotlin, 100% Yeah, is that like, or learning it or are you actually? So I grew up technically up my roots in Rails,

or Ruby and Rails, but I haven't done that in a while. I have done JavaScript TypeScript for the last, I don't know, 12, 15 years. And then I did a feature in IntelliJ, which is Kotlin, no idea of Kotlin, but it was enough to pass the code review just with like, instructing it properly. Yeah, yeah. And because that's kind of, it's like interesting words. Like, you know, it's kind of this thing where it's like,

I think you need to know, like, could you, for example, like, Node.js, could you start from an empty directory and build a Node.js application? I wonder if people can be because it's like, all these tsconfig lent, there's so much boilerplate, setup, all this. thing, you know, like you throw the framework, like it's like, no, you just start with

npx create react and, you know, but it's like, you should have that skill of like being able, could you actually do it from scratch? But not that like you can do it, like I'd have to, you know, it's like, oh, yeah, I have to reference what it is. But I know the layers. I know how it is. But I'm not like off the top of my head, I know all the parameters

in tsconfig, you know, but, but, you know, you have to know those things. So it's like, this is weird balance. I don't know. Cause I think about this a lot of like, how are we going to train developers? Because I'm struggling myself to figure out how to program with AI that like, because it's it's like a it's like a it's like a drug or something is bad

of like, it is so easy to lean into the model and just let it barf out code and feel all great. Cause you just created 10,000 lines of code and you just dug yourself into a hole. So it's like this thing of like, how much do you let it do? What level of visibility? You can't possibly review every single line of code. Like what can you delegate in like,

and what I realized is just because, you know, I've I've led teams and stuff and had to be like delegating stuff is like, oh, the skills of like how how you would be a tech leader or a mangered ever they start to apply where it's like, oh, how do they trust what that person is doing is what they said they did? What level of visibility do I need to make

myself feel comfortable that it's the quality without micromanaging it. Cause you can't micromanage AI. And that's where a lot of engineers do it now. I think from the learning perspective, though, I would probably disagree because I'm always a big fan of like trying to learn on the job kind of thing. I'm like realistically engineers

are going to use AI. So I I'm wondering and I totally see where you're coming from of like, okay, you need to have good understanding of at least one language should like be efficient. At the same time, dad, like hand coding or react application or whatever, that is disappeared. So yeah, from that aspect, I'm wondering if rather the diligence aspect of like you said,

like reviewing every single line of code and being extremely critical about it is the way to go. That's at least works probably better for me. But I'm also in the fortunate situation that I not learning with AI now. I have my background, right? I don't know. It's super difficult. I'm thinking about this a lot because I mean, I'm already because of kind of like the way I work with

teams right now is because I've always just played like an architect role. I mean, I'm very hands on a program a lot. But like when it comes working in a team, I work at more like the architecture level where it's like, I don't really give a crap about like the body of the function so much. It's just like I kind of trust you're an engineer. You'll, you know, do your job. And if it

blows up, you have to fix it. Anyways, you know, so so that so I kind of take a little bit perspective of like I very much care about design and what like one of the little like hacks that I found lately that I really enjoy with AI is I have it right ADRs like in that because I I struggled to figure out how to effectively discuss and communicate design with AI. I like what's the best way for us to

agree on the design such that like, you know, how do I turn design into an asset that we can collaborate on and then implement and then maintain it sub like a so ADR was actually a really interesting thing. But but so it's like it's it's figuring out what that that balance is. But I mean, I think like so I was interested interested because like so my son I've a 16 now but like so this is like a year or so

ago. We were programming a Roblox game together. This is a fun thing like doing with my son. We're uploading programming Roblox. And so he's like very, you know, junior developer person or whatever. And so I'm over here. I'm just like AI in like crazy and like, AI in some just yeah, you just use AI. And it was really interesting because it was very detrimental that I could see to him

of like because my perspective was like well, use AI it's going to give you a thing. You see the structure. And then if you break it down, you know, you should be able to learn what it's doing. I take for granted all these things that I've learned that because I remember when I was when I was young, I learned basic right. And in the way I learned basic was literally my dad just gave me the basic

manual. It was like DOS or it was like Microsoft. And it wasn't like how to do it. It was just the reference thing of like I've like what all the commands meant. And I remember seeing four in there. And I for the life of me could not figure out what the heck four was. What a for loop. So all of my code because nobody taught me I just did it was just go to go to go to go to go to I didn't understand.

So anyway, so it's like the concept of four was difficult for me at that time. So so that's the thing is it's like if you like you just start with AI. It's like that's what I am somewhat can like I think you can't today you can't start I don't you can't really you obviously have to use AI from day one if you're doing anything professional. But like I think they're still the value of like no do it by

hand. Type out a Python function. Run it. Execute it. Because I do think that's the best you know it's like if you're to learn Java like type Java C and compile the dumb thing. But but it's but it's hard because it's like I don't know like I think but I think it's what we're going to figure so I think there's I think it's a very for people who are educators and stuff like that it's like creating this all

it's going to be a very interesting thing I'm trying to balance of like how do we teach this because I don't know what the skills are because I as I was saying it's like I'm I'm really struggling with it of like because there's this huge pressure to move fast. Yes. You lean into that you screw yourself over so much. It's just so just a couple things in case someone is watching this for the first time

and it's just thinking about computer getting into it. I still I still think people should get into computer science. At least the way that I learned and I've said this on this podcast also multiple time was very much by pain right I ran into the wall it failed so I kept running till I found my way through it. And like tools like Google and stuff help me find my way through it right

with AI I have this easy out and I think it's going to be very important for people coming into the industry particularly into the beginning to identify when to use AI to move fast and when not to use AI to properly learn because as you said it's it's a drug you literally can crang out you feel super productive and then three weeks later it cashed fire and you'll be like awww. It's like

settling like you know because I did that words like I was just cranking out code I'm all happy I'm producing this and then I got to this point where it's like it was like I do a new feature regression like I just started hitting the regressions like crazy and I'm just like then you take like I'm hitting the regression regression regression I'm like okay what's going on then I started taking

a closer look at the code that's been produced and it's just like oh my gosh this is a nightmare but the models are getting better too so it like I mean and they literally you know with every couple weeks we get a new model and it gets better I mean if you just if you like look back right software development was always a fast moving industry but if you now like looking back at the

model generation from like a year ago that is like a night and day difference like if you just look like a couple weeks back like yes it was five as night but if you really compare between to 4.8 it's just a little nicer right yeah but if you really take back and like compared to Opus 4 last year night and day difference yeah and and I think it's really interesting because people talk about like

the performance because there was like let's say a year or so ago, we're like, oh, we're kind of hitting the ceiling on how smart these models are. And then we can, the coding models just continue to get better. And there's all this idea of like, well, we don't have enough data in the world to make it smarter. We just need to

exponentially more data and we don't have. But we've kind of moved past that where it's like, we need a data to have this base level like understanding. But the way the coding models are getting better right now is really like refining their behavior. It's training them on how to act and behave like a better developer where it's like, no, no, no, don't just barf out code. You need to realize like

in this situation, no, let me go and, you know, so it's, I think it's interesting because people talk about like, people are like, oh, you know, we try to, was it answered for more fives things? That's right. We're like, you know, try to make it see. Yeah. Well, so it's like, and then engineers are like, no, it's just probabilistic. It doesn't have a personality and it's like, no, no, no, no, no, no,

like, yeah, we can agree. These are just dumb random numbers and there's no real intelligence. Like I don't think AI is actually intelligent. But, but you train a personality of behavior. And that's what's getting better about these models. It's like, they're just getting better discipline that being a well-rounded engineer. Yes. And like, two calling was one of the major ones.

Yeah. I had my aha moment for that was kind of when Cursor released their Composer 2.5, which I think was just like reinforced learning on the Kimi 2.0 item. Yeah. But they're just, if you use spelled models, you felt a difference. No one can tell me that they didn't feel a difference if they use the model for more than like, just a hell of a world or whatever. I can

compare to what? Because I never really, I've never been in a cursor. So, so the composer model just feels like very capable, very capable engineer with when you tell them clearly what to do, they crank it out in a decent quality, not a fantastic quality. So you still need that guidance. Whereas like, Kimi was always like very generalistic and like you. And in a similar way also like

from what dimension with the personality aspect, I just need to look at like, use any anthropic model and any open AI model. Yeah. Like, particularly the newer open AI models, me as a German feel very much seen there. It's very direct communication, very like, do you feel like, because I always feel like it is a bad thing to think, but the GPT model seemed very German to me.

Yeah. I had the shock moment. So I test all these models for JetBrains, right?

And like, whatever they all work the same blah blah blah. I don't really care. Like, just figure out how to use it. And so I was working in an existing project and I was switching between Claude and GPT, you know, five, whatever. And I'm like, yeah, whatever they both work about the same. But then I started with like, from scratch. And like, I typically for from scratch, I'd used

Claude just for whatever reason. And then so I started a couple projects from scratch with GPT like five at the time. It did not create a brand new project from scratch because what I do, it like, I do is like, I'm prototype new ideas. Like, I'm just always trying to write. So it's like, I don't have a clear path forward. I don't know exactly right. So it struggled so much where it's

like, it's like, oh, you want to do this? Boom, that's the pattern. And I'm like, no, no, no, I want it slightly different. Right. So the thing though is like, it was like very rigid towards an existing pattern. If you work inside of an existing project, it can derive the pattern. Like, it's like, oh, this is how I should behave in here because it sees what it is. So

so what was interesting with Claude is, like, I realized like, oh, for these like a lot of the projects that I'm starting off with, Claude works so much better because it's like, it has a more creative aspect to it where it's like, oh, I, you know, I don't really want like like, because I'm like, right now, like this week, I've been fully on building a programming language.

And so I went through this where it's like, I struggled with with with GPT where it's like, it just wanted to do traditional compiler. It's like, here's, here's these different type systems. So we say that's how I think, the way I think and also, you know, I think, you know, that's how I try to do a programming language in the way it refers to all of these different types

of programs. So that I'm trying to connect to this and that's how I think, I think that's how I can attribute them to a program. So you know, so I think, this is the same as that. So I think it's interesting is this like is why I think there's kind of like this very huge kind of market to train these models because it's not so much about

it's not so much about like information or intelligence. It's like we're encoding processes and what we've learned and what's the best way to do it. And so that changes with time as like because as we even encode the best practices in a model we'll then figure out like that really wasn't like there was downsize to that so then we modify that to behave a little differently

but you can extrapolate that to any domain. To some extent that is kind of why I'm excited about skills and for the record I think like most of the generic skills that you find online are utter garbage right. But if you really sit down and be like this is how I do just just as an example if we both will talk about unit testing I'm 100% sure we have different approaches to unit

testing. So sharing one skill for unit testing absolutely doesn't make sense. Maybe for like project level I could agree with or you could find a way to do this but like coding your way of how to do unit testing super valuable and a super good approach to like making these models closer or like getting better quality out of them in for what you ever consider quality.

But so I think you're right because like the the skills that are out there are pretty much garbage but it's like it's because it's kind of the nature of like what you're saying is like if I wanted to build one generic skill for everyone it gets down to the point that the skills somewhat useless because it's kind of what the model would do anyways. So the whole point of skills is encoding your

context is like anywhere like anyone who's got a software development job or whatever it's like how does the team run how do they do it right what's their weird interpretation of agile right like I think it's very similar because like I think when people talk about software factories right it's like I don't think it's going to be a one-size-like here plug in the software factory because it's like because

if you look at something like agile it's like what we have this methodology and idea it's a concept but has to be tweaked into it to how you want to do it because there's so I think that's what it's like skills are so important because they're they're they're codifying your specific behavior of how to do things and so I I use skills as like behavioral scripts like so my my like release process and how

how I um you know it's like you can create them for like bugs like like how do you triage a bug or whatever but it's not like how do you do it in general it's like no no like to triage a bug you like you know look at these things spin up this thing like the things are very context-specific to your application

So this is where I get kind of excited when for software development because like I hate PRs and I hate reviewing them I hate the personal conflict of like having to like tell someone where it's like My opinion is that you should do it this way And then and then we try to mask our opinions with no logically that's right, you know

So it's like I leaked that conflict of arguing with with engineers over how to do because I'm very opinionated So it's like uh-huh, so I have to like back said but anyways, so but like if you look at like um Formatters I loved it when the industry kind of we've just moved to this thing where it's like Just have the formatting be built into the tooling nobody argue about it

It is what it is and we move on right so you can start doing that with like Processing what now because like that's what I'm hoping to see with code reviews is like I don't want to nitpick like like Because I used to tell people and it is like look if you're gonna nitpick on a style Right a linter because I don't want to nitpick on south right a linter so someone can want it

It'll fix it. Yeah, yeah, yeah, I want to do the same thing with code reviews and stuff where it's like where it's like okay Well no no in our project we do it like this this this well then build it into a freaking scale or something and have a Rm4 set and we don't have to argue about it anymore 1000% agree on that Slight tension I already announced it

I had yesterday I think a conversation with someone on Twitter who was saying the Best engineers with AI are going to plan plan some more and then have I do it? I hate it so much. I hate it so much. Oh, I hate that

So that's also kind of how I reacted because and I might be slightly biased here But the way that I work with AI is I have a good enough understanding of the system that I can start working with it And then I kind of explore the solution space with AI so that I usually go more for like an iterative prompt approach I'm not saying this is the way to go

I'm just saying this works for the way that my brain works because I'm not Dilligent enough to like foresee hundred percent of the edge case or even 80 percent I'm just like have good enough I'm finding an understanding that I can explore this and then I I run it figure out like oh you forgot this edge case. Okay, let's figure this out together

That therefore like from my perspective like this planning approach is not as important as Having a solid understanding of Your system and what you're trying to accomplish with those two things I can move pretty fast Yeah, and so I don't think there's a one-size-fits-all answer to this and so and I think it's stupid to say the best engineers can be with it

A lot of this has to do with personality and the way you work and what you care about Because there's a lot of people who do very well with like they design the crap out of a system and they they figure it all out before they write code I don't do that. I've never done that I write code. I experiment That's how I accomplish things. I don't have a clear goal in mind when I start to me

Yeah, my screens that I don't know what like a screensaver went on but so Okay But for me like programming is it's kind of weird because like to me it's a creative outlet

So it's a creative process for me and so to me you know, it sounds like it's like molding a clay with you know So I cannot stand that idea of like I am going to Specify what it is and pump it out but but so people that they like that They like that's how their brain works and they they were specification and they you know You're more like an analyst your words like okay, I'm gonna go and

This is what it is and it just needs to match this contract you're fine But yeah, that's that's not what I'm doing like I to me there's like It just depends on where because like where I am like for me to build a good Product has a lot to do with the nuance of like taste and human being and so it's like it's a much more molding type thing

And so I so that's what I found is like I don't personally like these approaches where I'm gonna come up with Specification in front and then I'm gonna go and then it's gonna go and Because I mean maybe it's the nature of like the the systems I'm building They're just like they're too big or something because I can do that with a smaller thing like a smaller unit of work

But like for these bigger systems when I do that it creates a complete mess Because there's so many things I didn't realize that I had wrong and so I do not like that approach but Yes, but I won't I think it's gonna be Not the norm. I just really don't it Like maybe because there's a lot of people like software engineering where it's like I take three requirements I pump out the code and whatever you know, it's like

Okay, well that could probably be automated. There's just right specification and whatever But I don't know that that's it's a sad sad world to me if I'm not if I am not collaborating with AI And instead I'm just like write it go and then you know our view of it I I agree with that and but I the thing that where if I take a couple steps back where I'm glad about is that we finally start

To discuss more about workflows with AI and Spec-driven development was the first real workflow that came up for at least from my perspective where it was like okay Let's not just let's abstract this kind and kind of scrum the the same way in that way of like okay, let's establish ways that engineers work um and so I'm a little bit optimistic maybe again like spec-driven development absolutely doesn't work for me

It's not how my brain work. It's not how I used to develop But I think I'm somewhat optimistic that this is assets in industry maturing a little bit instead of like discussed model capabilities or something rather Let's see how this tool can complement our work and there are different ways of working like Developer advocacy is a fantastic way. I keep saying those thing over and over ways like not

Two developer advocates are doing the work the same way. It's just there's too much nuance too much individuality And then very similarly, it's the same for developers, right? If you look at a very abstractly like yeah, you take a ticket you implement it you test it yada yada yada But how do you get from HB is so different from I mean, I do like with spec-driven development one is don't like the process

But like I do have some qualms with the idea of like if you are effectively saying that like That like pretty much code is a generated asset from a spec That that like because like what I try to do right now is I try to document Because I realize there's an importance of documenting things the same reason why it's good for humans to document same good reasons For AI to document

But I try to keep documentation at the minimal amount because AI is just as efficient at reading the code So so in the code reflects reality of what it actually is So why have two pieces of information that conflict with each other? So try to keep the the information in one place and so Documentation should represent um a higher level

Kind of like more table of contents of your thing and then you can drill down to code So those were the I was saying like why are like ADRs because what you do with ADRs is Is that is specifically designed as a point in time decision of what you were thinking at that time And then at the end of the work you created design document which we let reflect current reality

So with this spec-driven development you have this kind of Well, I wrote all this information and then I created code What's the correlation between those two things? What's the source like what's the source of truth? I'm going to be a lot of people.

of this thing. I imagine they have quite a few engineers working on Claude Code now, right? You know, like, right. So it's like, no, no, that turned into like sure. One guy seeded the idea and prototype this thing. And we all know it was, you know, not a well put together prototype. And you know, they're like, there's nothing wrong with that. It's like,

so we put together this thing. But then you need like it, it turns into like real process and people doing things and making it better and increasing quality. So, so yeah. So it's like, so spec-driven development is like, well, what does that look like on day two? What does that mean by bringing the next feature? Like, how do I maintain that code going forward? Like, I don't know

if that makes sense anymore. Every project I work with, you had some point made a decision, oh, we implement feature X, Y, and then three months on the line, you're either like, oh, we don't need feature X, Y anymore, or we need to slightly change or to make bread that work better. And I've yet to show or see someone who give me a clear answer how to handle this in spec-driven development.

Unless you're willing to create two sources of it. So what's what's interesting because I've been doing this where it's like, I run this problem, for example, where I'm like, oh, I'm like, I'm struggling to effectively communicate and maintain design with AI. So then I'm like, oh, maybe I could write like a language or a new different blah, blah, blah, whatever. And then I

I just started asking AI like, well, what should I do? And and and so it just started pointing me back to traditional SDLC methods and whatnot. And like me historically, I hate process. Like I don't like documenting like I'm just I'm like the really obnoxious engineer that just wants to write code and not have to worry about the rest. And but like I'm beginning to realize like it's like, oh, all

of these these processes that I kind of hate it because there were some tedious and I don't like doing the well thought out they actually work. But now I can get AI. So it's so the thing is is like, I'm hesitant of like this this thing of like, we've created this brand new way to do it. And it's like, well, what about the last 30 years that we figured out how to command like how to get humans

to do this. And AI is just automating humans. So what if we take the things we already know like, like, because I started looking back at things like like, like, UML or a mermaid diagrams or there's another shoot. There's another thing that's like, it came after UML, which is like how to describe systems and stuff where it's like, we don't have to 100% where it's like, oh, I'm going to

I'm going to do UML like as it is, but it's like the concept was really good. Like so this idea is like, you know, something some type of, you know, so so all of these things that we've learned in the past, I kind of think like the solutions to going forward is kind of to look back and do like, oh, these these are really good things and I can get AI to do it now. So like, so now like something

like ADR like because I remember one of my engineering teams, the last company they adopted ADRs. And I'm just like, oh, I hate this so much. That's like, I don't want to write one. And then then you have to put it in the PR and people comment on it. And I just hate it. It's just this big long process because I'm just like, well, but but now it's a useful thing for me to discuss with AI

front about what I want to do. So yeah, so I think, yeah, I think a lot of these actually like a lot of these answers where it's like, so I'm always amazed like what I was saying, like I have my dad program computers like in the 60s or 70s is like, what I talked to him, of course, the technology is ridiculously different. He was doing like punch cards and bench poleball and stuff like that.

But we can relate on the same general problems that that I feel like the future of engineering is very similar to what we are doing now. But it's just the tooling that the things change. But it's I come back to this so often where it's like on the one hand, if particular, I'm way too much on social media and stuff, if you're on those platforms, you think like every day, everything changes

every fucking day, where it's like realistically, yeah, things are changing. But if we take a couple steps back, not astronomatically, obviously like social media amplifies these things. That makes it seem so arbitrary. But if I really look back, like I am not cranking out 10x code, I am making maybe working on like a couple of things in parallel, which I wasn't able to do before.

But that also has like cognitive limits, at least for me. So fundamentally, yes, the focus maybe goes a little bit more from like writing code to like reading code and understanding code. But every company that works with more than two people's had these problems before too. I want to have like this little bit of maybe it's optimism. I don't know. It seems weird. It doesn't sound like me.

Where it's like, I think it's really changing that much. Like, yes, the tools we're using to accomplish the work are changing. But that has been a thing for developers. Like if you're done that, that same or the thing about like the frog in a boiling pot, where it's like, if you have a boiling pot and you throw a frog in it, it's going to jump out. But if you put a

frog in a pot like warm water, it's just there and you slowly raise the temperature, it will boil, it will die. It will boil it and it will die. And so it's like this thing where it's like, it's like, I don't think we, like things are changing are going to change so much. But then at the same time, we don't recognize it at all that it kind of seems similar where it's like phones, for example,

the cell phone has drastically changed society, drastically changed society. And but thing you're like, well, what's the big, you know, it's like, I mean, people point to things like maybe I feel a little more busy or social media or whatever. But I mean, there's things where it's like, I can pick up a phone and call someone like in the middle of Africa because they have phones in the middle.

So it's like, so it's weird where it's like, it's like, well, what will the future look like, you know, in 10 years, 20 years? And it's with AI where it's like, well, I think things are going to be drastically different, but still very much the same. Like human bulls don't really change, but like we just start to take for granted a lot of what we have. Because it was interesting where it's

like, because it's like, oh, well, now I can do more things like I can build more systems. But I immediately push myself to like my cognitive limit or where it's like, oh, like I'm doing more, but I already hit that limit. So like I'm still struggling, right? It's like, I can do so much more. So shouldn't I work five hours a week and not 40 or a hundred or whatever,

but no, we're still like the odd thing about AI is with AI. Everyone's working more engineers are working more. They're putting in more hours with AI. So it's weird. So I am actually very optimistic in that like, it's like, it's like everything's gonna change, but at the exact same time, it's not gonna change. Like, like you look at you look at you always have like these high performers and then

kind of like the middle tier of people. And it's like that kind of large middle tier of people, it's not like suddenly overnight, those all become my performance. You're still gonna have people who go to work and they do their nine to five and they really care about something else, but you know, they're good people and they do their job. And so they're gonna come in and somehow use AI

to get their job done and they click and maybe they don't fall yet. So it's like, different the tooling will change and everything. And so I don't I don't know like are we still going to be looking at code or will we get away from looking at code. I don't really know but like I see that the technical challenge is still there of like because I don't look at assembly.

I've never looked at assembly so it's like does it does that bother me that like you know today the you know when I write you know it's like if you write let's say a go program because the amount of a binary is going to go is so huge where it's like if you were to actually look at the amount of assembly that gets produced I mean it's astronomical but but we stop caring about it so it's like well

so I don't know so maybe we do get to a point where we're like no it just doesn't really matter but I don't I don't know but I'd say it's I'm kind of to the point where it's like well like it doesn't matter like it just like you can try to be the one to predict the future and be right but you're most likely wrong. I'm having fun like I just kind of always go back to the fact where it's

like you I think AI is very much this existential crisis for engineers and actually everyone in the world we're all afraid of it to a certain degree but it's like well it's a scary thing I don't know what's going to happen I'm having fun right now so I mean maybe that's not you but like you know but yeah so this is a great question slowly wraps us up because I had Dillon on here last and he says

he doesn't feel the same level of joy coding with AI then he used to doing it by hand and to some extent that resonates with me too because like when you're coped by hand you have these feelings of success you accomplish something you solve the difficult problem whereas like AI takes that abstract set enough that it doesn't feel like an accomplishment really so where do you

source your joy from when you're um that's that's interesting um because I can definitely say it because like like I'll see someone like um like uh what's like ThePrimeagen like someone like that worries like you know obviously that that dude really really enjoys typing and producing code and like that kind of tactile feedback and and so it's like or you know lose that that joy right

and that might be true but for me the the joy comes out of it's it's solving a problem but then there's also just like the um just because like let's say like a personality wise of kind of like this like obsessive thing wanting to control things or whatever that as long as I feel like I uh understand and have control of the system then then I like it so so for me that's the thing

that I that I don't like about AI is is when I start feeling like I'm getting pulled away and I don't know what's going on and I get abstracted away and I get this uncomfortable feeling of like what's going on right so so I you know so it's like do I need to type the code or not I don't I don't know because because the typing the code is like to me that's that comfort level of I know exactly

what's going on can I build that same level of comfort with AI because because there's no saying it's like I I don't know when that method gets compiled with the assembly because at this point you trusted enough right and I'm not saying like you know we don't look at code but only trust AI but I'm seeing like I think you can get that same level of joy but I've been through the same thing he has and I

think like because you go in these waves of like with AI where it's like okay well I'm gonna do it the way you're supposed to do it or the way other people I mean you do it and you're yeah that's not as much fun and I would but I I think you know you can you can still get that but it's it just might be different but like I definitely what I enjoy now is for me personally I got to the point where

the problems I wanted to solve were too big I can no longer even prototype them because I'm not interested like I want to solve bigger problems and it was just like what's the point of even starting it because I know like I can't even fully prototype it even if I prototype it I need a team of like 20 people to go and manage it or whatever so I kind of got to this point where I'm just like

engineering's way too freaking difficult and I felt like my hands were tied but it's like I just couldn't so for AI it's like I feel like I can now do that again but it's a challenge that you would write it and I haven't figured it out yeah I can totally see where this motion is coming from when you like you found your value as an engineer in the coach you crafted I from my perspective the

most valuable engineers there's more to engineering than just crafting code so from that aspect I can see where he was coming from but from my perspective I very much look AI as a tool to a certain means and before that that was code now AI is in a spot to facilitate that so I also didn't feel this despair or whatever with AI might also be a naive but

from that aspect I think we kind of need to re-calibrate as an engineer where do resource draw from that's why I was asking you and where do we see our value proposition if it was cranking out code interesting in this purely speculation is like I'm sorry what was his name the guy was on oh no it's Dillon from Cloudflare but so is that you know there's like for example

like I love C I just think there's something kind of like poetic about well-written C but I don't write it professionally and I'm never going to write it professionally because it's just too dangerous or whatever right so it's like it's due it's just not the right thing so there's kind of like what you do in your free time and what you enjoy and that still exists because if you look

at your day-to-day job as an engineer most people's day-to-day job as an engineer is just a lot of crap right but but you have this longing for this thing that you loved that you got into it like when you were a kid or whatever where you learned how to per right so you have this longing thing but it's like so it's this thing where it's like oh I don't know if I enjoy this as much but it's like okay

but right before you picked up AI coding or whatever what you were doing in your job then were you getting that joy you know because like because I mean I wasn't at that at that time because I'm dealing with all the crap of uh yeah just being a professional engineer you know so before joining uh doing developer advocacy I was doing consulting and if I once I reflected

that I effectively for the last ten year book crud application and uh exil and a website for Fortune 500 companies I was like I can't keep doing this but that's what companies particularly in the consulting space pay money for that's what they need they need data management and that is a crud application on the backend and an exospecity on the front end that is what most Fortune 500

internal application works out to and they pay way too much money for that um that is there is absolutely a need for these there's also space to innovate and make people more efficient but did I saw a story from that apps so yeah I mean and and to a certain because it's like I mean I've always I'm I'm like I like to I mean I've always had these kind of hobbies and computing or whatever

they're not necessarily like turned in like that's what I do my my day job or whatever and so I don't think you should lose that like you should never you know like still programmed by hand and whatnot like if you stop doing that because I I literally it's funny because I oops So I, because I tried this, whatever it was, like I really haven't written pretty much any lines of code this whole year.

Like everything I write is AI. I tell it and it generates it and I look at it, right? But then the other day, I was like a week ago, I like pulled up an ID and I started typing code. And I'm like, ooh, this is fun. I forgot how fun this is. It's like, oh, it's like, because then it's like, but like in my mind, I had this kind of this weird thing where it's like, no, no, no, I shouldn't be, like,

it's like, no, no, I'm gonna do this because I should, like the better way is to not touch the code. And it's just like, no, why not? Like write some code you would have, you know, there's no like rigid way, but so you don't have to like, completely lose that, but like, you have to be just realistic that it's like, well, no, like just look at your regular job. Like, you know, I always thought of this step before,

which like, I don't know if it's true anymore, but it was like maybe 10 years ago, was like the average developer produced 10 lines of code a day. That's if you looked at their career like over a year, like you average it out, but it kind of makes sense if you think about it as you, because you like, you'll spend time writing a bunch of code, but then like you go periods where you're primarily in meetings

or you're troubleshooting a lot or whatever, it's like the amount of lines of code you actually produce are very, very small. So it's like, you know, so we have this idea, you know, this kind of idealistic view, and then there's the reality. And so I think the reality of this is hopefully gonna be better. And my one prediction for like AI is gonna be that, because quality is of course,

is like one of the big issues is that we're gonna cross this kind of this point where the only way that people are gonna trust the quality of code is that it was AI assisted or AI reviewed or whatever, is that there were no longer going to just trust handwritten code. I 100% that's gonna, and I don't think it's, it's like, it's this weird thing that happened because I saw this like with Docker for example,

was like when Docker came out, it was so insecure and like this will never work. And you know, because like VMs were the security thing at the time, it was like no, and now we're at this, we got to this strange point where it's like no, like the only way for software to be secure is that it first has to be contained. Like you have to put it in a container. Like we don't just trust throwing the software on a machine.

And so a lot of times the weird thing that happens like the number one like argument against the technology ends up being like the best thing. So I really do think that with AI, the level of quality of code is going to skyrocket. Because anybody's worked long enough in this industry, you look at the quality of code that actually goes to production, not what Silicon Valley or these elite people are producing.

I'm saying regular people, what they're putting into production, you know it's terrible. And so it's like it just makes sense that AI is gonna improve that significantly. And like the only way, like I saw this thing about security is like the only way to the new security methodology is it just basically reacts faster, right? It's like, and so it's just thing of just improve the process of how we do these things

and refine it. So I don't know. I think fall these gonna skyrocket. I think I agree with that because if I look at it, like yeah, the most engineers are average, if not below average, right? Not that a mathematical may extent, but you know what I mean. At the same time though, I also wholeheartedly believe that we see so many so sloppy software in the very near future

with like maybe even to the level that it will bring down companies that were very successful. Yeah, yeah, remember there was like back to the day with a, oh shoot, like one engineer took down a trading firm or whatever, they lost like $300 million in a day or something with one little bug. Yeah, so 100% level of like. So like you know when I say that like I'm like, I think the quality is gonna be,

I will 100% agree that like what we've witnessed over the last year is this like, is companies leaning into AI and destroying their products, just destroying the quality has gone down, everything's terrible. But that's not like, that's just like their stupidity of like basically like this holy crap, we need to dump all this money and we're just gonna put billions of dollars. Everyone go just do,

it's like it's this panic of not knowing what to do, have too much money and just like letting people going free, hoping that magic sprouts out of the crap that's being produced, right? So like yeah, that is the case, but that's why like it's strangely like, it's why I even think even more, where like it's like yes, you can absolutely point to that the quality is crap, it's gone down,

but it's going to, it's gonna end up being the exact opposite. Yeah, no, I think I agree. Thank you so much for joining this and particularly, thank you, I say this often on the podcast, but you are also fundamentally just as James on the internet accepting this podcast invite. So thank you very much, I appreciate that. And everyone out there, do do the like, subscribe, whatever, I don't think here.

Cool, see you next time.

Why AI agents belong in the sandbox | Darren Shepherd

Jan-Niklas Wortmann

Key Takeaways

Chapters

Mentioned In This Episode

Pull Quotes

Guest Bio

Full Transcript

Why AI Coding Made Me More Productive - And Less Happy | Dillon Mulroy

Dex Horthy - What Actually Gets You 2-3x With AI Coding

How To Ship Real Code With AI (Not Junk) ft. David Cramer

Key Takeaways

Chapters

Mentioned In This Episode

Pull Quotes

Guest Bio

Full Transcript

Related Episodes

Why AI Coding Made Me More Productive - And Less Happy | Dillon Mulroy

Dex Horthy - What Actually Gets You 2-3x With AI Coding

How To Ship Real Code With AI (Not Junk) ft. David Cramer