Dex Horthy on Ralph, RPI, and escaping the "Dumb Zone"

0:04Welcome back to Dev Interrupted. Earlier this year, we sat down with Jeff Huntley for a conversation that frankly set our community on fire. He introduced us to Ralph, the autonomous bash loop that made him want to Ralph, you know, that slang for vomit. And he realized that the moat of manual coding had just been drained and he had pulled the plug. But throughout that episode, one name kept coming up as a catalyst for many of these discoveries. you know the other person in the room he was in the garden kind of energy and that's dex horthy and dex was there in san francisco when the ralph meme was born you know he calculated the brutal unit economics of the new world famously on a napkin and today we're bringing dex on to pick up the story where jeff left it off and dive into what happens when the loop becomes the standard you take it to scale with an engineering team and you're not making something new but you're tackling those brownfield problems that are messy and are really hard to deal with with agentic stuff so dex welcome to the show we're so excited to dig into this with you i'm so excited i read the list of questions you prepped and i'm like oh good it was just your story time i'm i'm stoked i love i love story time podcasts so uh we'll get into the details we'll do some some tech stuff but yeah i'm excited to uh to riff with you and see where it takes us yeah exactly i know i i know I know you're typically, like you said, on the whiteboard and breaking things down, the complex agentic engineering patterns.

1:29I follow a lot of your work and I learn from it too. And so today we are taking things a little bit of different speeds, more Sunday drive mode, and we're going to go on story time for sure. I want to start by framing it about when you were with Jeff, because I think that's best framing for our listeners too. We recently had Jeff on the show and he was talking about the birth of the Ralph loop. So he said that he met you or y 'all were rocking out at a meetup together and, you know, ended up talking for a while. What was the energy like and what were the events that kind of led to deeper conversations with Jeff and what y 'all were talking about building?

2:07Yeah. So around, I think I want to say like February or March of last year, a buddy of mine who I'd worked with a long time ago dropped me in this like random Twitter group DM with about 50 people in it. And it was basically people riffing about models, about running their own models, about getting their GPUs to turn out more tokens per second, complaining. It was like before Kimi K2 had come out, but people were running open source models. It was not a lot of cloud code until one day was all about cloud code. But it was just like genetic coding plus more generic AI stuff. and the person who runs that group chat she put together basically like a small meetup for like the people who are live in sf and we hosted maybe like 10 12 people in person our office and then another like five or six people like joined over the google meet and we just did like five minute lightning talk show and tell of like what's your favorite agentic coding thing i think this was in like june of 2025 wow and it was the first time i saw a bunch of really cool tools that i actually haven't heard of in a while it's like some of the things are like yes you still hear about that every day and some of them are like i haven't heard of so things like spec story and taskmaster which were some of the early like mcps that people were using to do this kind of like thing that's now very in vogue which is like the beads or agent swarms thing where you give the the coding cli a tool to be able to like manage work you know what i'm talking about oh i mean i use beads yeah it's very okay right now yeah so there were like early things that were in the beads direction that were uh that never really caught on the way the beads did uh and so that that was super interesting to see um kind of those kind of things there was people's the first time i saw context seven which was this tool that would let it's like now very popular i remember super yeah yeah and since then we've been using it we're huge fans of context seven so just like people sharing tips and tricks of like here's this random thing that no one's heard of yet that we're playing with and um my buddy who had originally like introduced me to this crew he ended up showing up like two and a half hours late and he brought with him this guy jeff that no one had ever heard of uh and uh he came in and he was sitting and like took in the last couple talks and then we were like jeff do you want to go and like show us your thing and he just launched into this like 30 minute like deep dive into ralph and how it worked and showing us the live streams of like yeah literally i'll turn this thing on i'll go to bed in australia i'll leave the live stream on for 12 hours then i'll wake up and like check on the code yeah yeah we were we were followed we were in the church of jeff at that point i think and we were covering some of his articles because he had been building like the cursor standard lib in terms of like all these very structured rules and how he was building a system and we were learning a lot from him here and so i'm totally familiar with the whole just like okay i'm gonna live stream this whole wacky thing and then um And then ultimately kind of, you know, the little blew off of that, really.

5:07It became pretty popular across the industry in terms of like, oh, here's a way to describe something that we're all trying to do. And then here's some parts that we can play with. And that, I think, is the most exciting part about like your origin story you shared, because it's very real. It's kind of how these things happen. Like you're in that group chat with a bunch of other wacky people experimenting with things. You throw together some office space and you do some show and tell. Like that's how people are figuring out these primitives and how they scale and how to build with them. And it's not that it's like unsolvable.

5:41It's just that you have to be willing to get in there and get messy, you know? Well, and it's I think it's really hard to create those sorts of communities. Like I've been in SF for 15 months now. And the thing that I said, like we were building AI dev tools since like summer of 2024. And it was like, oh, my God, there's seven meetups a week. Like you can just literally go talk to users. They're everywhere compared to, I was in Chicago before. Like there's some good AI engineers there, but they're hard to find and they don't get together that often. And then within like a couple months, I was like very burned out on the SF meetup scene because it was just like literally every event is the same.

6:15You show up, you get some mediocre pizza, you hear some, you hear six talks. Three of them are like lightly veiled vendor pitches. Three of them are like full on vendor pitches. And so it was just like, I just noticed that like the people that were actually at the frontier were finding their own spaces to get together. And a lot of it was happening on like Twitter and like small discord groups. And so like, I don't know, I do a lot of organizing in SF now. And I think a lot about like, how can we create space that doesn't feel over commercialized or like you're the product. A true hacker space.

6:48Like that's what they exactly now. Right. Not the product pitch zone. I know exactly what you're talking about. Like there was a period of time for sure where it was like, God, like another MCP night, another MCP night, another MCP night, you know, like those kinds of deals. And so it's like, but that's not really where people were discovering these new kind of primitives. That's not where Ralph loops were getting born. That's not where they were getting shared either. And so kind of like talking about, so Jeff comes in, this new character and shares this, this, this, this way of building with Ralph.

7:17And then afterwards y 'all are talking more. And from what I understand, like in terms of how he put it, that, you know, y 'all started breaking down the economics of like, if you had a Ralph loop build for you, then what does that mean for the cost and that the value of a software developer? Like, what are your thoughts on that? I think the number he gave it was 1042 an hour for a Ralph loop to do software engineering work. Something like that. Yeah. So like a couple months later, I was talking to, it was like August. So like two months later, I was talking to a buddy of mine who had read the Ralph stuff, but had never tried it.

7:47and he said like let's go do this hackathon at y combinator uh and i want to do something about ralph like i want to learn to use it i want to build something cool we sat around riffing about what we could do and like okay could our hack tape project be like a tool that helps you create ralph loops or set them up and then we had this idea of like what if we just use ralph because when you do a hackathon they want you to do thing again they want you to do things they want to use the products or tools they want you to have the seven sponsors and the more tools you can put together the better score you get from the judges and stuff right but we decided to take a note if we were going to use jeff technique we would also highlight maybe some of his uh perhaps uh well-intentioned irreverence and so uh we decided to take all of the vendor projects that we could and spin up a bunch of ralph loops to clone them so it was like one of the sponsors was browser use which is this python library that's really good for browser automation we're like okay what if we ported the whole thing to typescript and so we just like literally set up a tool that would just run overnight and port all of that to typescript yeah so use the hackathon to build tools that eat them exactly yes exactly yeah which i think is the real challenge now there's a picture in the blog post of like the the ceo of browser you're just looking at it's like holy shit you guys did this overnight like without looking at it and it like kind of i mean it wasn't perfect i think the thing with the ralph stuff that people people say oh this doesn't work it's like yeah but it gets it like 90 % of the way there and like it's much better than if you tried to directly vibe code the whole thing or something like this yeah the sticker like the shock factor like the eyes getting big at the moment like those have been real left and right like I like two weeks ago I won an AI hackathon for the Atlantic which is like you know the journalism institute so you're exposing them to like how you can use like how you can build new technology on top of their pre-existing like archives and make them more accessible and digestible and like I had already built what I wanted to do by lunch and then I was helping other people because like my agents had done so much and then when I presented it with them it was like their eyes got so big because they were like this has been on our roadmap for years and you made it before lunch was served like they were and then I left I got a new burn left and didn't answer their questions and so it's like you know the mystery continues and so I think it's funny to hear like you know you're going to show up at the hackathon and you're going to use as a space to kind of flex what what is possible and and and how the economics of this all change um and and i definitely know what you mean but you know i i i want to tie it too into something that i read i think just yesterday um from cv egg you about uh his most recent piece the ai vampire where he reflected on that one yet oh yeah so that one just came out yesterday so he reflects in this one about um the experience of like being a 10x engineer 100x engineer and the insane value extraction pressure that happens when you're taking advantage of orchestration?

10:37When you're running a gas town and you have all these benefits, what does it mean for you and your teammates who captures that value? How would you keep yourself from burning out? It's like a really, you know, self-reflected piece because Steve himself has already talked many times vocally about burnout in many organizations. So I'm just curious, like, I know you haven't read it, so I'm not going to press you on it, but I'm just curious what your thoughts are on, like, how employees can leverage more that value if people like you and me can show up and like invent something overnight that like eats the company alive then how do you really work and preserve your value in that world yeah i um i don't know i mean i also i think i mean one thing i've i think i've said online months ago is like if you're working because we developed this methodology is like rpi research plan implement which is not like unique lots of people were doing this we just put a lot of time into like tooling and and kind of uh guardrails for doing it well prompts and all of this uh but it's really designed for like brownfield code bases and like hey you have an existing software thing that you can't just like throw out and rebuild i think but people like oh i'm building a new project how do i use rpi for it i was like what are you going to reach there's nothing to research there's no code it's greenfield so like right you're doing greenfield just write the specs and use ralph and maybe use ralph to help you build the specs and things like so like i think a gas town or ralph like looks really really good for like new stuff i we have a couple i'm happy to chat about a couple of like the applications of route that work for us building a software product that is i mean it's not brownfield it's you know six months old but it's you know 50 000 lines of code and like it has to continue to work we can't just i mean the thing with beads is like 250 000 300 000 lines of code it's great it's riff no one's ever looked at the code that's fine because no one's like paying money to use it and if it breaks it's like cool it's open source it's free like what do you want kind of thing versus production exactly the way coming back to your first question which is like how did we get to the like 10 42 an hour or whatever is like we did this hackathon and we spun up basically like we spent until two in the morning we're like setting up gcp vms and like getting the credentials put in and like setting up the tmux sessions and running these each ralph loop for each of the like six sponsor products to try to clone them and we i I think it was like something like six,$700.

12:55And we had, I didn't throw out my credits, so we just used my credits. But we did that math. It was like, okay, six servers, seven or eight hours, 600. It came out to about 10, 40 or$11 an hour or something to run Sonnet in a loop forever. That's incredible. So you go and you're like, okay, I'm going to spec out the machine. I'm going to get the tokens. I'm going to set it all up. And then I can just amortize it and be like, this is how much it's going to cost to just print execution for me to create whatever this software idea is going to be. And obviously it's like, that's one challenge when you're doing something for a hackathon or a greenfield kind of space or just replicating or reporting a project.

13:29But, you know, it actually bridges us a bit into the realities of using those types of patterns on pre-existing projects and actually being successful as like a career engineer, someone who I own a product. I ship things that are used by, you know, thousands or hundreds of thousands of people that are system critical. Like I can't even risk things. So, yeah, if I get paid, their challenges are different. Yeah. Yeah. It's like if I get page at three in the morning, I'm not going to just poke my Ralph loop a couple of times. I have to be able to get in the weeds and fix it, whether I'm using a coding agent or doing it by hand.

14:02Like it has to be I can't be like, yeah, I've never read this code. I don't know how it works. yeah precisely so um it even it even goes to a bit about like um i guess jumping from some of the origin of like okay you have ralph it allows people to kind of like loop this and and we've explored ralph here quite a bit and how the economics and the value changes but then when we talk about actually applying it that's where we get to some really interesting conversations about the applied engineering and the reality of being using orchestrator types of patterns But then also working with these tools in pre-existing code bases.

14:37Like something that you've really championed is the idea of the dumb zone. And I love the dumb zone. You recently gave a talk. It was, I think it was AIE, AI Engineer. Was that the company's name? Yeah, that talk is amazing. And we've included it in our roundup before. It's definitely going to accompany this episode as well. um i've followed it very religiously because your ability to break down uh the way that like context like actually needs to get constructed and then utilize and then how a lot of the patterns that we assume are like oh this will make me safe are actually like wasteful and they don't scale so you really kind of that was you call you call bear the real reality of it or i'm like i'm tired of cycling my my my specs and my proposals and my tests every single time i change my idea and so it's like you clearly felt the same yeah yeah i mean that that was also like the the the beauty of ralph when it came out is like you know i don't use it to build most software we have in our in our ide product there is a ralph inspired thing where you have like a parent agent that owns the implementation of you know a plan that might be up to a thousand or fifteen hundred lines of code and it like shells out this the faces as sub agents and that's how we do context isolation you have a dumb model write the code you have a smart model kind of check it and then re-steer and then launch the next one.

15:54But the beauty of Ralph was this idea underneath it, which is like everyone's got their, I mean, there was no Gastown at that time, but everyone had their like multi-agent system and super like complicated orchestrators and all this stuff. And it was like, no, as long, if you actually know how context windows work, like the only thing that really matters is like, how do you optimize for staying in the smart zone? How do you optimize for like small digestible tasks and resetting context all the time? And everything else was like way overcomplicating and actually like quite simple problem. Yeah, it actually is a really great way to phrase it that way, because ultimately what Ralph showed us is that the complexity is actually something you want to strip away and you want to get as simple as possible.

16:38a lot of people were using ai and ai engineering as an excuse to glom on more complexity and to handle these like levels of extreme complexity that they hadn't weren't able to do before but then they were ultimately creating these like crazy spike projects that would just fall over the second that angle would look at them weird and so like that's and it's like how can you that's not actually the benefit that you gain long term from it the benefit you gain from long term from it is how do you get smaller how do i make it to where it's fail proof to where this tiny little loop can't get it wrong and that's what i mean that's what i've loved about like cooking things with beads is because if i can make a whole bunch of little tiny atomic beads and then i can shove it to like you said a dumb agent like someone who doesn't need to know anything that can just execute something very clearly you start to get this division of roles and this is where you get like the orchestrator patterns where you have the smart agent you have the smart human operating the smart agent to very carefully construct these contexts you know rivers that then these like downstream, like very dumb agents that are naive, but doesn't really good at triggering stuff can then execute on.

17:41So like, where do you like see that kind of thing going? The dumb zone is obviously an optimization that you can solve for now. Do you think that's going to continue to be a primitive or do you think that there's something that goes beyond that? That's a great question. Yeah, I mean, we talked about this in the 12 factor agents talk back in June and this comes up. I would literally give a lunch and learn yesterday. and the question was like, well, when the models get smarter, do we still have to worry about all this stuff? I mean, the answer is like, as the models get smart. Okay, so here was my experience.

18:11In December, all of the good engineers who were kind of anti-AI, like OG infrastructure. I mean, Mitchell Hashimoto's the exception. He's been doing AMP stuff for six months or whatever. But a lot of engineers who were kind of skeptical of AI suddenly came around. Like Opus 4.5 was the turning point. That was turning point. Yeah, November hit. Everyone went on a break and everyone came back in january and now github can't even stay online maybe they're doing too much ralping uh so the thing that the thing that i think happened is like it became possible to get the model got smarter and so you could get good results without doing as much context engineering without having as much in text intuition for models without really knowing how all this stuff works yeah um or without like basically context maxing smart zone maxing whatever you want to call it those people are now getting the results that engineers the best engineers i knew people like jeff and many other people were able to get last summer with opus 4 and so it's like imagine what those people are able to do now with opus 5 opus 4.5 opus 4.6 buy up so it's like the models are going to keep getting smarter and the way that i think about it is really like the notebook lm team described this really really well they built a great product um and the way they did that it was like they found a thing that is like the only way to build great experiences in ai is to find a thing that is like right on the boundary of what the model is capable of it gets it right some of the time and then you find a way to context engineer your way into getting it right consistently and so even as that frontier expands as the models get smarter the hardest thing they can do and the thing they can only do reliably if you really think about it and are tasteful about it it gets bigger but imagine what the people who were rocking opus 4 and getting crazy good results are getting now with this even smarter models when they're willing to do this context engineering and frequent compaction and stuff like this absolutely it goes back to like the star-shaped intelligence we've all seen like the venn diagram where the human intelligence is the circle then you got like the ai's intelligence which is like all these spikes coming off that's the same kind of spikes can be built and then reinforced with context engineering which is in fact like what our jobs become as engineers and i think that's what I loved most about like when when Jeff came on the show talking about like well you know you're an engineer aren't you like engineer the problems away if like you're encountering these these systems capture the back pressure find ways to turn the problems into something that drives the solution and that really resets the conversation and brings engineers back to the table um and so I just like love the way that he had he had framed that but I also want to ask too just because you know we've talked a little bit talking about other people but I want to talk a little bit more about UDEX.

20:50And so, you know, what you're working on at Human Layer, I think, is largely also tackling this issue of having, it also goes back to like context engineering and having the information that you need to work on like things that, you know, code existed that existed before AI came on the scene. How do we keep shipping that code, but with AI? So like, what are like the, what are the problems that go through your head with all of this fast moving space you're moving in? And then like, how do you apply it into what you're building now? What opportunities do you see as a founder yeah um so i think the way i've been framing it recently um and we've evolved this stuff it's funny i got i got on stage in november and also in august when this first the talk first the talk that was like the precursor to the ai engineer talk and i was like we have this thing it's called rpi and i like the responsible thing to do is to say i don't know if these prompts are magic these are not the same prompts we'll be using in six months they probably won't even be three steps it'll be a different thing and i was just saying that because that's the responsible thing to do uh i didn't actually really even wasn't sure if it was true and then we woke up in like early december and we were like oh crap yeah we need to change the prompts and it needs to be like five steps instead of three steps and rebuilding the whole thing and like what it came down to is basically like how do we this circle and star metaphor you have where like there's things where the human is better than the ai and there's things that the ai is better than the human how do we build even more kind of opinionated and like meticulous workflows that enable the ai to do what the ai is really good at namely reading a whole crap ton of code and understanding it quickly and reading a like very specific set of tasks whether it's beads or just a big markdown file with a bunch of stuff to do and going and spraying that out on the code base running the test making sure they pass and then iterating with the user on it and making sure that the humans are in the driver's seat for the things that the AI is not as good at, which like making architecture decisions.

22:46And like the thing we say all the time is like, you cannot outsource the thinking. And so how do we put the human in the loop and basically create these intermediate artifacts along the software development lifecycle where the human can see into the coding agent's brain and do some little brain surgery to reset the context before we get so far that we're down on a trajectory that it's much harder to re-steer. And so, uh, we've taken RPI and we've broken it up into a more structured process based on just like, we would have people who are really good at AI coding and they picked up RPI and they loved it.

23:19And then they would give it to their team of a hundred engineers or 10 of the hundred engineers. And most people, most people who hadn't been like obsessed with AI content and following all this stuff. And then all the group chats, like just couldn't get good results and so we're like how do we dig deeper and like do the context engineering for people and making easier for them to do the right thing versus having to like really have deep intuition about Claude to get good results obviously that'll always get you better results or like needing to like sprinkle in magic words here and there to get the process to work properly like I would literally go to workshops with you know 100 engineering teams and I would say like okay cool during planning you want to sprinkle in these magic words otherwise you won't get as good results and i'm like i can't believe like we need to solve this in the product and so those are the kinds of things we're working on yeah and obviously those things evolve as you experiment with it more and what i think is fascinating about what you're describing is a lot of people are challenged with like okay capture that back pressure you know you're you're selling the back pressure you're you're getting it and then you're putting it right back on where they can use it and you're making it more painless and but also you're you're getting you're buffing or buffering away the errors the problems that people are going to encounter which then makes it easier to them for them to adopt and experiment and then finally maybe they can experience that kind of like slope-on-slope growth as those harnesses those training wheels come off right it's definitely like a realization learning moment because like you said it's like somebody's going to come in and um maybe get really down to like a nitty-gritty level and then they're going to like uh berry specifically kind of like do that grain surgery on top of the context like that person is going very different from a lot most engineers who are going to pick up the tool and just use it put it back down and whatnot like the needs for what people need in order to use that tool are different and so like when you build this like uh how do you think about like the engineer of tomorrow do you see them being this like like ultra bare metal i'm in here doing brain surgery on agents every day creating context out of nothing i've read 500 000 lines of context by breakfast kind of people or do you think that they're going to be um that they're going to just be more like oh i'm uh i use ai sometimes to code and the ai understands my code base and it's been solved away by smart people of the world and the dex horthys and the human layers have created these tools that i that i can use like where do you where do you see those engineers of tomorrow or would they be i mean i think um jeff huntley's advice is is really good here which is like just burn as many tokens as you can not like on on nothing one of the things i think is actually a little bit of an anti-pattern is this like i'm not fully bought into the like hyper engineering trope of like look how many tokens i spent like i have my thing running overnight and look i have six clawed max accounts and they're all maxed out every single day i'm using like all my tokens and i'm like cool but like what did you ship and like is anybody using it and Like, what did you build?

26:17Yeah, exactly. What did you actually build? And it's like, it's not about the inputs, it's about the outputs. And so, like, I think it's less about, but I will say that, like, the more you use these things and you work back and forth with them and you see the outputs and you try stuff, it's like, people are like, how am I going to know the right prompts to give? It's like, you got to give the wrong prompts a hundred times and then you build intuition and then you figure it out. Precisely. It's like, you don't forget why you're burning those tokens. People are like, oh, I'm going to burn as many tokens as available to me.

26:41They're not burning it and then just going to go play the Xbox. they're burning the tokens and they're staring at the terminal or they're multiplexing it and staring at four of them and they're figuring out why the tokens they're burning aren't giving them what they want and then they're doing it better next time that's like every time that i go in i'm burning tokens i see it as like i'm doing reps like i'm building muscle for tomorrow uh and i think that like that's how a lot of people not a lot of people like view it that way that's just like anything anything um the the other interesting thing i think like that we frame our like a lot of our a lot of our customers they look a lot at um the volume of prs coming in with ai now and the amount of slop and the amount of rework that needs either like people are burned out from reading it or they are burned out from uh just the volume and then they're not reading it and then having to go clean it up later because there's some slop or some bugs in it or whatever and like we definitely like did a our version of like hey we don't really read the code we just read the plans and like if it works then like we're gucci like i'll read the test and okay if this test passes then then it's good enough and like actually backed away from that a little bit we do think you should read every line of the code especially if you're working on like production systems regulated industries all this stuff like you owe it to your users and to your team members to read the code and make sure it's good and so i think people frame the like too many pr slop problem and like oh we need to get ai to review the code i'm like hey i wrote the code it's the we're all using the same freaking models so i think the idea that we like is like how do we minimize rework And the way we do that is like we move the alignment to a lighter weight, like part of the process.

28:21And so like the newest version of our tool generates this thing called the design discussion. And it's like a mini plan that is like, okay, here's the desired end state. Here's where we are now. Here's what's out of scope. And then like, here's the patterns in the code base that we think are relevant. And then here's a couple of design questions, like very deeply rooted in the code because this comes after the research of like, do you want to do it? this way or this way or like we found these three patterns which one do you want to use or like how should we architect this which repo should this thing live in um some of the questions are the model already has a recommendation and it's good and sometimes it doesn't ask quite but like this 100 200 line markdown doc is good for we talk a lot about mental alignment it's for like mental alignment between the user and the agent primarily right it's your it's your clawed brain trace this is your chance with 200 lines of markdown to re-steer it before you get more specific down the road with the actual like plan with the code changes but it's also the perfect document for teams to align and so we see these like intermediate markdown documents as the unit of work that is going to be critical to the sdlc going forward of like how do we get the agents to ship lots and lots of things with while maintaining humans in the critical points of the workflow where we get to do the thinking and the steering and that's how you get your team to work two to three x faster even in like big legacy code bases where you can't ship slop and you can't afford to just like yolo it out and not read the code right i think that's really great advice the engineering teams about you know where's the mystery to the success and how do i find it it's you know the the burden of the work of figuring out what needs to happen it's always been difficult to do it's a communication problem and ai makes that really bare and our biggest impact that we can do is leverage and pull as much of that decision making up into the beginning that way you're really crystal clear alignment not only it's like there's so many levels of handoff like there's eight person that agent handoff sure and then like oh are they on the right track like does this is this context cooking but then also like there's the person to person handoff um and then of course downstream there's the handoffs that we're not a part of there's the agent to agent handoff there's you know at the end the agent's given someone else does it even match what you said at the beginning we're all playing this game of telephone with tokens in the middle so it's like shows bear the amount of work that has to get done in the beginning like it even i even go back to like um when i use things like beads what beads are really great at for me is like being able to get that plan and then i know i feel confident i can convert whatever plan i make into something atomic enough for a bunch of dumb agents to probably figure out in some amount of way so because of that it inspires me that fires me up to work really hard on that proposal on that on that upfront thing that that markdown document that what you called is like an it's like an artifact and it becomes the most important thing that i make and like when i like for example when i was at the hackathon like i didn't even start coding until about an hour before lunch showed up right like all that whole time i'm literally holding down the talk button on my computer or like I'm using whisper flow.

31:28Like everyone has their poison. I picked one, right? And I'm just brain dumping and going back and forth and churning this markdown and really good ripping it back out when like no, you stupid machine, that's not what I mean. And then giving it to another one. And then until I finally had that like Smithed out really great view. And what that view was is it extracted my perspective as I used to be a classroom teacher. So I was like, I was like, Claude, I know more about you on this. Like, listen up. Like, I'm going to tell you what the teacher would need built. And then you're going to build it.

31:59You're not going to make assumptions. And so like that way of working was really powerful. And when I was there, like I was really opening people's eyes to like why so much of coding now is just planning. Yeah, I mean, even before I had heard the neighbor out for anything, the best engineers I knew, and it gets into like the back pressure idea as well, is like they knew they had to build a thing. It would be probably like 30 to 50 ,000 lines of code. They're building some like Kubernetes operator or something. and they explained their process to me. It was like they would spend three days designing the feedback mechanism, not designing the architecture of the system, not writing the code to test it, but just designing.

32:37If a coding agent was working on this, how would it be able to deterministically know whether it had done the thing correctly or not? And it would spend three days on that and whiteboarding and designing and then writing it up and voice riffing and all this stuff. And it would hand that to Opus. And this was like three, seven, probably days, maybe four. and they would come back two days later they would run something like a ralph loop i'm sure and they would come back two days later to 50 000 lines of perfect working code that they would ship to production and it's like yeah okay that's like the extreme and i don't think most people should do that but like it's just like it speaks to the power of the primitive it speaks to the power of the primitive and i think that's what exactly that's it's why that's why your talk at you know in new york was so popular like it has a you know that's the thing has over like 300 000 views on YouTube and it's like barely been out for like very any amount of time it's like people are really they're really trying to get aligned on what matters now and you're showing them that this like level of planning and execution which has always mattered but now it matters so much more it's your most important primitive to leverage um it's just like really good it's really good insight for anybody I think listening working with these tools um there is something else watch it I know Andrew is a fan if someone sent it to you and you had to watch it I'm sorry that happened to you.

33:52It's fine. Oh, please. It's a very, very useful research, resource, and we will be pointing people towards it. But I think it's funny that you say that because your message there resonated. It resonated pretty deeply. And I think it's because it speaks to, like, the new norms that people have to be operating within. But speaking of new norms, I really want to just take a moment to also take a step back from, like, the social economics of it all, all the planning stages of it all. But also just talk a little bit about how does computing and how does engineering change like on a base and a primal level?

34:29And there was something really interesting that a lot of minds on our show put in my head recently, the idea of like cutting out all of this human layer, this human space in computing and making it more of an agentic driven environment. Like we've spent decades adding all of these levels on top of programming to make it accessible to humans, you know going up the chain of abstraction to make it something that we can understand and push downward but now we're we had an opportunity where we could strip all that away and the agent can exist in this new kind of space with computing power so it's like i'm curious like what you think about how you think like the things that we take for granted today as engineers like maybe how they might go away um go the way of the dodo yeah it's interesting it's funny it's actually when i first met jeff i went to his personal website he has a blog i'm sure you've seen it but yeah when When I first pulled it up in like June of 2025, the picture at the front of the blog was like a sad man sitting on a bench looking really like sad and disappointed.

35:28And it kind of looked a little bit like Jeff, but it was like basically the like theme on the landing page of the blog is like everything is going to change and our profession is dead in many ways. And I'm kind of sad about it. But here's me like processing that in public with a bunch of posts and like what I'm learning. yes we were following depression era jeff for sure yes um i mean i saw there's a conversation i was in um this week i think steve yege posted this thing of like you're gonna have to fire half your team because half of them just don't want to learn this stuff and uh i think me and a bunch of people in my community are very aligned that like i will help anybody who wants to learn this um jeff's take is like i think he's like i will sit down with anybody and get you to the like holy shit moment if you are willing the only thing i asked is that you like pass it on to at least one person that's right i know other engineering leaders some of the best agentic coders who have like built a ralph based system for their team to leverage is like i will give everybody the chance to learn this because i care about everyone on my team and i want to make sure they make the transition to the next world because they're all very good engineers and i think we're going to need a lot of leaders and teachers who are bought in on helping people make this transition and there will probably be people just like when compilers came out there were people who said like wow that assembly sucks i'm never using a compiler i'm going to keep writing all my assembly by hand there will there will be people who choose to not make the transition and i don't know what's going to happen to them but i think um this whole like yeah either like get on board or like we're leaving you behind thing and like it's a five minute conversation is is a little bit uh drastic yeah yeah a little drastic for sure and i just think like i can't agree with you more that it's like if someone wants to learn i really want to teach them and that that's part of what we do here on dev interrupted it's why i talk about this topic until i go blue in the face every week and i i just hope that people pay attention and also then get expired inspired and want to learn and pick up the tools themselves and really understand that it's not something completely unachievable If I, you know, I used to be a classroom teacher.

37:34I'm an AI engineer. And it's like, anybody can make that transition. It's like, sure. It's like, honestly, I will admit for myself that like wrangling a classroom of kindergartners is a lot like teaching a bunch of agents how to do work for you. And so, well, you have to figure out what is your, you know, wrangling kindergartners for whatever your skill background is. Anybody, I think, can convert that into, I can convert my ideas into execution. everyone kind of just has to become responsible for that journey themselves but people like you know like they have the um coding abilities can teach others to get there too yeah i think it's uh everyone's job if you've if you've seen the future you should you should pass the torch to at least a few people uh and uh you know he it is it is kind of a scary thing so be be thoughtful about it and be human about it and maybe bring a little bit of yeah yeah and i i want to also So again, I want to poke your brain a little bit about the team sizes of tomorrow.

38:35You're talking about all these engineers that will make the transition, make the jump. And what are they jumping into? I think that tomorrow's engineering teams will look very different. I think we talk with like, you know, a lot of leaders on the show right now at really large companies, like we get huge logos on this show. And a lot of what they grapple with is like, you know, they're a big org and they got to make a big transition. and all of them opine for like, oh, I wish I was like a three-person startup team. Like everybody wants that like greenfield problem with three people in an AI native space.

39:06Like, what do you think, you're in San Francisco, you see these teams constantly and you see what they execute at. Like, what do you think tomorrow's engineering teams look like in terms of size? I mean, so there's two things here. Number one is like, when I first talked about our transition to writing 99 % of our code with AI, one of the points I made was like, it was incredibly uncomfortable. It was like a team of three. It took us like really six to eight weeks to get to the point where we were all happy with it. We rejiggered our entire linear board. We changed our SDLC. We changed what we looked at.

39:39We changed how we communicated. We changed how we specced out work. We changed how we decided what to work on. Like all of this took eight weeks. Uh, we were all very burned out at the end, like what we figured it out. And so my thesis in like company building was like, cool. like it took three people this much time like how long is it going to take a team of a hundred or a thousand uh and that was why i thought okay there's a huge opportunity here to help people do this um i will also say i have seen giant teams do incredible things i mean you look at like ramps in the news strong dms in the news these are large teams and you know the gvon's paradox like if you tripled the output of all your engineers like you wanted to hire one engineer uh so if you if all the whatever your desire to hire one engineer if you could hire three if they're outputting three times as much your willingness to hire engineers goes up not down right um there's a little bit of like flexibility i mean you talk about like i think it was every where they basically have like seven products and they in order to help people move fast they just have one engineer per product instead of having like teams of people i read that too yeah they were like we gave up we gave up on trying to figure out how to share context so one person per repo or something.

40:47I did see that. Yeah. So yeah, I don't know exactly what the teams of the future will look like. I mean, there's a trade off here of like, if you're moving really, really fast, it's nice to have like having more people depending on you and that you depend on create synchronization points, which slows you down. So I don't know how that's all going to shake out. But I think in general is like, if engineers are more productive, then we should be doing more engineering things. It's like no, no CEO is like, cool. Now we can do all the same projects with you know half the team it's like oh now we can do twice as many projects yeah yeah i agree with you there but then what do you think about like for a small team that can come in and like disrupt or dismantle a space that like before was like completely owned by an enterprise i mean there's there's plenty of instances of people who can run the run the ralph loop to clone the competitor overnight and execute at an insane speed and level and like what what does that look like so i mean if this if this was true that you could just triple your code output and you can do incredible things or like i don't know i have this theory of like it'd be really interesting to see if people could um like you know if you could just download every single page of the salesforce documentation and build a completely wire compliant copy of salesforce and then just give people a like cool migrate your data and now you have literally just if all you wanted was salesforce but with a nicer ui you could just lift and shift everything and move it over and now you have it and like you know ralph that for three months and now you have your salesforce clone the thing is is like there is more to building products that people love than just writing the code there's like spending a lot of time with customers and users and understanding what they want you cannot just build stuff in a vacuum most of the time maybe if you're steve you can but like most people can't do that there's a lot to be said about taste there's a lot to be said about like ecosystem and distribution and like there's there's more than just shipping the code to building a business and so like these people who have really good moats uh they're not just in the product they've built it's part of it you know the other thing i've heard is like you know they've been fixing bugs on salesforce for 20 years like yeah they found every single freaking corner case in the world that's the thing is like they have all this owned domain knowledge that Like no competitor could come overnight and just own and take.

43:06And that's such like a great way of putting it is that there's a lot of other problems in shipping code. Just like how we're learning as engineers. It's like, oh gosh, writing code is just one really small part of what we do. There's a lot of other bigger problems that we tackle every day. The same goes for selling and making software or anything at scale. So I think that's like really good advice to end on. And like it goes to say that you can't Ralph Lube an SLA, right? People will still have needs for what they would want from something that they buy. And I will asterisk that. Like, we have a three-person team, and we're trying to replace Google Docs, Notion, Jira, Linear, GitHub, and whatever IDE you're using all in one product.

43:44So, like, on the other hand, like, we're going to see if it can be done. Precisely. And we're going to keep following it, too, because, Dex, it's been amazing to have you on the show and dig into your head about how you've been thinking about AI engineering, even just since your very recent talk, which we've covered in the show and we're going to share as well to our listeners. And I just think that this space is evolving so fascinatingly. And I think there's so much to learn. And that's what's really encouraging and exciting to me as a lifelong learner and someone who came into engineering to learn and to experiment and build new and fascinating things.

44:14The idea that I could do that better and faster and execute at a level never before, it's really exciting. And it's really great to be here with people like you who see that opportunity, but then also feel so inspired to teach and share that knowledge with others. So Dex, thank you so much for coming on the show, covering a bit about how you work with AI. And I just want to end by saying, you know, where can folks go to learn more about you and HumanLayer and all the things you're working on? Absolutely. Yeah, if you go to HumanLayer.dev, we've got our, there's blog, there's content. All of the big conference talks are listed there.

44:47There's a form to get in touch with us. the one plug I'll put out is like if jumping in and disrupting all those products and bringing all in one place is exciting to you we are on the lookout for founding engineers and founding sort of product design engineers especially so I would love to hear from folks who are excited about the mission or if you were an engineering leader who is interested in helping speed up your team this is what we do all day and we love doing it. Amazing. Well we're going to put those links to those resources in the show notes. Definitely we'll be plugging your job opening as well so folks can get involved, but y 'all are building.

45:23And to you listening, you know, thank you so much for joining us here on Dev Interrupted for this really amazing episode. Join us definitely on LinkedIn and our Dev Interrupted sub stack where we distribute a newsletter as part of all of these interviews with a roundup of stories, continuing things just from our conversation here. And it's a great opportunity for you to jump in to the conversation with Dex and I both because we'll be tagged there as well on LinkedIn. So Dex, thanks again for chatting with me today. It's been a ton of fun. And everyone, we'll see you next time. Fantastic. Thanks, Andrew.