# Ralph Loop Economics and Agentic Engineering Strategy

**Podcast:** Dev Interrupted
**Published:** 2026-02-17

## Transcript

Welcome 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's slaying from 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, the 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 agentix 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.
We're just gonna do 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 I'm excited to uh to 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.
I follow a lot of your work and I learn from it too.
And so today we are taking things a little bit of a different speed, it's more Sunday drive mode, and we're gonna go on story time for sure.
I I want to start by framing it um about when you were with uh Jeff, because I think that's best framing for our listeners too.
Well, we recently had Jeff on the show and he was talking about the birth of the Ralph loop.
So he said that he he met you uh, or y'all were rocking out out of meetup together, and you know, ended up talking for a while.
What what what was the energy like and what what were the events that kind of led to deeper conversations with Jeff and what y'all were talking about building?
Yeah, so uh 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.
Uh and it was um 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 Kimmy K2 had come out, but people were running open source models.
It was not a lot of cloud code until one day it was all about cloud code.
Um, but it was just like gentic coding plus more generic AI stuff.
Um, 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 or 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 other day 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 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 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 it was the first time I saw Context 7, which was this tool that would let it's like now very popular.
I remember yeah, yeah.
And since then we've been using it, we're huge fans of Context 7.
So it's 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, and then I'll wake up and like check on the code.
Yeah, yeah.
Well, we were we were following, 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 uh lib in terms of like all these very structured rules and how he was building a system, and we were learning lock room here, and so uh I'm totally familiar with the whole just like okay, I'm gonna live stream this whole wacky thing.
And then um, and then and then ultimately kind of a you know, the little blew off of that really, it became pretty popular across the industry in terms of like, oh, here's a 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 the 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 uh unsolvable, it'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, and 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.
You 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's 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, uh a true hacker space, like and that's what they know, 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 another MCP night, another MCP night, another MCP, 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 um kind of like talking about so you Jeff comes in, this new character and shares this this this way of building with Ralph, and then afterwards y'all are talking more.
And um, 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.
It's something like that, yeah.
So, like uh 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.
And 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.
It was like, okay, could our Hacktay 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 things again.
They want you to do things again.
They want to use the product sponsor tools.
They want you the seven sponsors, and the more tools you could put together, the the better score you get from the judges and stuff, right?
Mm-hmm.
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, uh, which I think is the real challenge now.
There's a picture in the blog post of like the the CEO of browser use looking at it was 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, the shock factor, like the eyes getting big at the moment.
Like, those have been real left and right.
Like, I um like two weeks ago, I 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 um like uh you how you could build a 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 confused, and then I left, I got an Uber and 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 gonna show up at the hackathon and you're gonna use as a as a space to kind of sh flex what what is possible and and and how the economics of this all change.
Um, and and I definitely uh know what you mean.
But it I th I I I wanted to tie it too into something that I read, I think just yesterday, um, from Steve Eggy about uh his most recent piece, The AI Vampire, where he reflected on that one yet.
Oh, yeah.
So Alan 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.
When 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-reflective piece because Steve himself has already talked many times vocally about burnout.
Um in many organizations.
So um I'm just curious.
Like, I know you haven't read it, so I'm not gonna go press you on it, but I'm just curious what your thoughts are on like um how employees can maybe leverage more of that value.
If people like you and me can show up and like invent something overnight that like eats a 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 post 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 a unique lots of people were doing this.
We just put a lot of time into like a 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 people are like, oh, I'm building a new project, how do I use RPI for it?
It's like, what are you gonna re-there's nothing to research?
There's no code, it's greenfield.
So, like right if you're doing greenfield, just write the specs and use Ralph and maybe use Ralph to help you build the specs and things like that 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 Ralph that work for us building a software product that is.
I mean, it's not brown field, 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.
Exactly.
The way coming back to your first question, which is like, how did we get to the like 1042 an hour or whatever?
Is like we did this hackathon and we spun up basically like we spent until two in the morning where 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 think it was like something like six, seven hundred dollars in we had I had entered up my credits, so we just use my credits.
Uh but we did that matter okay, six servers, six seven or eight hours, six hundred.
It came out to about ten forty or eleven dollars an hour or something to run Sonnet in a loop forever.
As incredible, so you go and you're like, okay, I'm gonna spec out the machine, I'm gonna get the tokens and then I set it all up, and then I can just amortize it and be like, this is how much it's gonna cost to just print execution for me to create whatever this software idea is gonna 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 a reporting a project.
But you know, it actually actually bridges us a bit into the realities of using those um uh types of patterns on pre-existing projects and actually being successful as like a career engineer, someone who all I own a product, I ship things that are used by you know thousands or hundreds of thousands of people that are they're system critical.
Like, like I can't even risk things.
So I get page their challenges more different.
Yeah, yeah.
It's like if I get page at three in the morning, I'm not gonna 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, like 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 a using orchestrator types of patterns, but then also working with these um with these tools and pre-existing code bases, like uh something that you've really championed is the idea of the dumb zone.
And I love the dumb zone.
You you recently gave a talk, it was um uh at uh I think it was AIE, AI engineer was that without the name.
Yeah, that that that talk is amazing.
And uh, we've included it in our roundup before, it's definitely going to be accompany this episode as well.
Um, I've followed it very ridiculously because your uh ability to break down uh the way that like context like actually needs to get constructed and then utilized, and in 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 you call you call bare the real reality of it, or I'm like, I'm tired of cycling my my pro 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 1500 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.
But the the beauty of Ralph was this idea underneath it which is like everyone's got their I mean there was no gas town 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 in digestible tasks and resetting context all the time and everything else was like way overcomplicating and actually like quite simple problem.
Yeah.
And actually I it's 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.
A 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 landing one 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 came 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 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 just really good at triggering stuff can then execute on.
So, like what where do you like see that kind of thing going?
Uh, the dumb zone is obviously an optimization that you can solve for now.
Uh, 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.
Um, and the question was like, Well, when the models get smarter, do we still have to worry about all this stuff?
Right.
I mean, the answer is like as the models get smart.
Okay, so here's here was my experience.
In 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.
And I'm that was the turning point.
Yeah, November hit people, and everyone went a winter break, and everyone came back in January, and now GitHub can't even stay online.
So maybe they're doing too much routing.
Uh so the thing that the thing that I think happened is like it became possible to get this.
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, by a 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 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, and 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 it's like the human intelligence is the circle, then you got like the AI's intelligence, which is like all these spikes coming off.
That's those 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 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 I just like love the way that he had he had framed that.
But I 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 you, Dex.
And so, you know, what you're working on at human layer, I think is largely also tackling this issue of have 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 that existed before AI came on the scene.
How do we keep shifting 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 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 for the talk first the the talk that was like the precursor to the AI engineer talk and I was like we have this thing that'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'm just saying that because that's the responsible thing to do.
I didn't actually really even wasn't sure if it was true.
And then we woke up in like early December and we're 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 at 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 uh 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 of 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.
And 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 life cycle 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 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, and 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 the stuff and in 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 away buffering away the errors, the 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.
Cause like you said it's like somebody's gonna come in and um maybe get really down to like a nitty gritty level and then they're gonna like uh bury specifically kind of like do that brain surgery on top of the context.
Like that person is gonna be 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 gonna be um that they're gonna 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 won't 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've six Claude 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?
Yeah.
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 of, 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, is like people are like, how am I gonna know the right prompts to give?
It's like you gotta give the wrong prompts a hundred times, and then you build intuition and then you figure it out.
So precisely it's like you don't forget why you're burning those tokens.
It's like people who are like, Oh, I'm gonna burn as many tokens as available to me.
They're not burning it and then just gonna 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 are 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 then the 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 data 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 we actually backed away from that a little bit.
We do think you should read every line of the code, especially if you're working in 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 slot problem, and like, oh, we need to get AI to review the code.
I'm like, well, AI wrote the code.
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.
And 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.
Um, and then like here's the patterns in the code base that we think are relevant, and then here's a couple 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 the model arc 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 resteer 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 uh 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 that engineering teams about, you know, where's the mystery to the success and how do I find it?
It's you know, the 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 uh 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 a person that agent handoff, sure, and then, like, oh, are they on the right track?
Like, does this is this context cook in?
But then also, like, there's the person the 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 to 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 can I know I feel confident I can convert whatever plan I make into something atomic enough for a bunch of dumb agents to try probably figure out in some amount of way.
So because of that, it it inspires me to 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, like I'm using whisper flow, like everyone has their poison.
I picked one, right?
And I'm just I'm just brain dumping and going back and forth and churning this markdown 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 that on this.
Like, listen up.
Like, I'm gonna tell you what the teacher would need built, and then you're gonna build it.
You're not gonna make assumptions.
And so, like that way of working was really powerful.
Um, 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 even before I had heard the name Ralph or anything, the the best engineers I knew, and it gets into the like the back pressure idea as well.
Is like they would 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's 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 if 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 then it spent three days on that 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 like 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, Doug, 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.
I know Andrew is a fan.
If someone sent it to you and you had to watch it, I'm I'm sorry that happened to you.
Uh please.
It's it's it's a very very, very useful research, uh resource, and we will be pointing people towards it.
But um, I I think it's funny that I think it's funny that you say that because a lot so your your message there resonated.
It it resonated pretty deeply.
And I 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 I really want to just take a moment to also take a step back from like the so the social economics of it all, the planning stages of it all, uh, but also just talk a little bit about how does computing and how does engineering change like on a like a base and a primal level.
And there was something really interesting that a lot of minds on our show put in our 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 uh environment.
Like we 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 are at 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 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 or go the way of the dodo.
Yeah, it's interesting.
It's funny is 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 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.
And 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 gonna 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 uh this week.
I think Steve Yeege 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 uh thing I asked is that you like pass it on to at least one person.
That's right.
Um, 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 gonna 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 gonna 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 gonna 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 into like a 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, I'm an AI engineer.
And it's like anybody can make that transition.
It's like, sure, it's like it's like honestly, I'll I will admit for myself that like wrangling a classroom with kindergartners is a lot like teaching a bunch of agents how to do work for you.
And so will you have to figure out what is your, you know, wrangling kindergartners for whatever your skill background is, you 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 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 pass the torch to at least a few people.
Uh and uh, you know, yeah 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 I want to also get uh I want to poke your brain a little bit about the team sizes of tomorrow.
You'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.
Uh, I think we talk with a 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 and a lot of what they grapple with is like, you know, they're a big org and they gotta 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 green field problem with three people in an AI native space.
Like, what do you think?
I 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 I 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 re-jiggered our entire linear board.
We changed our SDLC, we changed what we looked at, we changed how we communicated, we changed how we spec'd out work, we changed how we decided what to work on.
Like all of this took eight weeks.
And you know, the G Vun'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 engineers, 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, just have one engineer per product instead of having like teams of people.
I read that stuff.
Yeah, they were like, we gave up.
We gave up on trying to figure out how to share context.
So one person per proc repo or something.
I I did see that.
Yeah.
Yeah.
So I 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.
Um, so I don't know how that's all gonna 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 the execute at an insane speed and level.
And like what what what does that look like?
So I mean, uh if this if 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 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, rout 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 Yeah, 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 motes, uh they're not just in the product they've built.
They're 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've found every single frickin' corner case in the world.
That's the thing.
It's like they have all this owned domain knowledge that like no competitor could come overnight and just owed and take.
And uh 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 with 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 and making software or anything at scale.
So I think that's like really good advice to end on.
And like it it goes to say that like you can't rough lube an SLA, right?
People will still have needs for what they would want from uh or something that they buy.
And I will ask to Rix that, like, I have, we have a three-person team, and we're trying to replace uh Google Docs, Notion, Jira, Linear, GitHub, and whatever IDE you're using all in one product.
So, like, on the other hand, like we're gonna see if it can be done.
Precisely.
And we're gonna 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 gonna share as well to our listeners.
And uh, I just think that this space is uh 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.
The 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 place with people like you who see that opportunity, but then also feel so inspired to teach and share that knowledge with others.
So uh 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 human layer and all the things you're working on?
Absolutely.
Yeah, if you go to humanlayer.dev, we've got our uh there's blog, there's content.
Um, all of the big conference talks are listed there.
There's a form to get in touch with us.
Uh the one plug I'll put out is like if uh if jumping in and disrupting all those products and bringing all in one place is exciting to you.
We are uh on the lookout for founding engineers and founding uh sort of product design engineers, especially.
Um, so uh would love to hear from folks who are excited about the mission, or if you're an engineering leader who is interested in uh helping speed up your team, this is what we do all day, and we love doing it.
Amazing.
Well, we're gonna put those links to those resources in the show notes.
Definitely will be plugging your job opening as well so folks can get involved with what y'all are building.
And to you listening, you know, thank you so much for joining us here on DevInterrupted for this really amazing episode.
Uh, join us definitely on LinkedIn and our DevInterrupted substaff, 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 will see you next time.
Fantastic.
Thanks, Andrew.
See y'all later.
AI helps your developers write more code faster.
But here's the problem.
Your review process hasn't sped up.
The queue grows, reviewers get burnt out, cycle time stalls.
Linear B changes that.
Our AI reviews every PR the moment it's created, catching bugs, security gaps, and performance issues before humans get involved.
It even writes the PR description automatically.
Your reviewers spend less time on first pass problems and more time on architecture and business logic.
Break the bottleneck.
See how Linear B accelerates your workflow.