At the start of this year, Kent C. Dodds gave a coding agent a link to a GitHub issue he had been putting off for ages and typed two words: “Fix this.” A couple of hours later, it was done. For someone who built a career teaching developers the fine details of React, that was the moment everything moved. His course sales dropped. He had what he calls an existential crisis. Then he got to work.
Eleven months later, Dodds says he has barely looked at code all year. He has built a product with paying users that runs close to 1.5 million lines, by himself, and his agents merged roughly 1,300 pull requests in the last 30 days, most of them while he wasn't watching. They also complain. After every change ships, each agent files “friction reports” about whatever slowed it down, and another agent fixes them overnight.
Ahead of his AIE Code Summit workshop on November 10, we talked about his relationship with AI (great, he says, if exhausting), how he's handling it with his kids, why he thinks most skills are bad, where deterministic code beats prompting, and Kody, the product that grew out of all of it.
The Q&A
Tell me about yourself.
[My work has] changed a lot, because people don't need to learn how to implement software anymore, at least not the way we used to. So I'm currently trying several things. One is mega.dev, where I'm teaching people how to build quality applications, specifically products, with agents. Another is that I'm getting into YouTube. I'm posting weekly, with sponsors and all of that. I'm also teaching about product engineering at epicproduct.engineer, where I have a podcast and have run some workshops. And finally, the thing I'm most excited about is Kody. That's Kody.codes, where I'm trying to solve the problem of working with multiple agents, whether that's just you or a team, and making automations and credentials accessible to all of them.
What is your relationship to AI?
I have a great relationship with AI.
You're the first person to say that.
Really? There are certainly bumps. The thumbnail for my video last week was me lying in bed in a dark room, staring at my phone, exhausted, because they just won't let me sleep. I'm working too much. So I suppose that's the negative side of my relationship with AI. But outside of that, I've never had more fun building products. I'm working a lot more, for sure, but I'm getting so much more done with every minute of work. I'm getting days' worth of work done. So I'm thrilled, and it's exciting.
It definitely tanked my business, which I was expecting to ride off into the sunset with. But I'm not mad about that. All of my past courses are open source on GitHub, so the models are trained on what I've taught people to do. Part of me feels like that's a cool thing, that my legacy can continue on in these models, which I think is actually great. But it also means I have to find a way to feed my family. I'm actively working on that, and I'm optimistic. So I think AI has been a net positive for the world, and certainly for my family, and we'll see where it goes from here.
You mentioned AI changing the course of your business, and you've been rethinking what a software engineer is and how people learn those skills. What did that fork-in-the-road moment feel like, and how did you get through it?
I can talk about this at length, so feel free to interrupt me.
Almost a year ago, we got Opus, and that really changed the game. GPT-5 came out soon after, and agents, or really harnesses, improved a great deal as well. So when everybody got back from Christmas break and started using these new models, it was very clear that the game had really changed. Maybe not to everybody, but they eventually figured it out.
I gave a Cursor cloud agent a really big task. It's recorded in one of my videos. For my workshops, I have a web app you run locally that shows a video for every exercise, and somebody had asked a long time ago whether we could add the ability to download the videos and watch them offline. That was a big, hairy problem I had just kept putting off. I thought, this model's pretty good, let's try it on that. There wasn't any spec writing or anything. A user had posted the issue, I'd said that's hard, maybe I'll get to it eventually, and that was it. I took the link to that GitHub issue, gave it to the agent, and said, “Fix this.” That was the entire prompt.
A couple of hours later it said, “I'm done.” And it nailed it. I made some small tweaks and adjustments, but that was my moment. Not only was it able to do this big job, it ran in the cloud completely autonomously, so I could run an infinite number of those jobs, as many as I can think up. And it turns out you don't need a really complicated prompt to make it happen.
So I thought, did I need to know the difference between React's useState and useReducer, or whether to use useEffect, or any of the other deep React knowledge I've been teaching people all these years? No, I didn't need to know any of those things. You have to understand that the agent was working within a codebase that had patterns and everything set up, and it takes an engineer to set that up. At least it did at the beginning of the year. But I could see the trajectory, and there was nothing that made me think it wouldn't continue. It all seemed like this is the way we're going, and I only see up and to the right on these capabilities.
So what does that mean for me, somebody who's been teaching people the nitty-gritty details of code? Even up to that point, we had gone from tab-complete to just talking to the agent and having it write the code, but we were still watching the code. I could see that we'd stop watching the code, and eventually we'd stop looking at the diff. Which is where I am now. I haven't looked at code pretty much all year.
That's substantial, because I've built a product with paying users that's almost 1.5 million lines of code, by myself, and I haven't looked at basically any of it. So it's had the transformation I expected at the beginning of the year: people just don't need to look at the code. My product was kind of a proving ground for that, and then it turned into, wow, this is actually a product. I can tell you that whole story later. But at the beginning of the year, I had this existential crisis. What is it that I even do here now?
So I played it out in my mind. My whole thing has been teaching people durable skills that stay valuable and help them build valuable things and excellent user experiences. The skills I've been teaching are no longer valuable. My course sales are going to tank. And they did. So what do I do now?
I played out the future. Let's pretend we eventually get to a point where the entire industry is dissolved, because anybody can build software with the thing in their pocket without knowing how to build software. In fact, they don't even build software, because the agent proactively does it for them. If you play it out that far, you can't prepare for what you're going to do, because it's just so different. You have no idea what it'll look like. Is it Terminator or is it Star Trek? We don't know.
So I took it one step back from that. The software engineering discipline is still a thing. People are still doing valuable work. What is it they're doing that's still valuable? If I can teach people that, then at least I'm teaching the most valuable thing, the thing that will last until the industry's gone. Of course, you can't actually know that, because you're predicting the future, but I did my best and decided it's product engineering. That's where the product engineer idea came from.
To be clear, this isn't a new idea. I've been talking about product engineering for over a decade. People talk about it, and most people have a pretty good idea of what it means. But I decided to talk to people I think are really good product engineers, and that turned into the podcast, Become an Epic Product Engineer. Over the years I've been talking with excellent product engineers, filling in gaps I didn't know I had, and figuring out how to get those skills into the minds of the people in my audience to prepare them for the inevitable.
Even right now, I think it's important to understand systems, to be able to design systems, and to be able to communicate your intent to an agent so it can implement what you intend. But I'm not confident that will be the case in a year. I think agents are already getting good at systems design and architecture, and they'll certainly be really good at it by next year. And communicating intent only matters until agents figure out they need to ask the right questions to get your intent from you. Then even a non-technical person can communicate their intent, because they're just answering questions. So I don't think those are very durable skills either.
So what's left? Having a vision for what you want the agent to do, or what you want to exist in the world, and having the finances to make that happen with the models that are available. So there you go. That's the long answer. I can also talk about how I came to build Kody and how that turned into an actual product, but that's where I started the year.
You've argued that agents tend to silently find workarounds rather than fix the underlying issue, so you built a system that forces them to log friction reports. You make them complain, essentially. What does that look like under the hood, and how do you keep it from spiraling into a pile of low-signal issues?
First of all, signal hasn't been a problem. They're actually pretty good at identifying high-signal problems. I think a lot of that comes from the fact that I have them log friction after they finish getting their work into production. If you just say, “Go find all the problems in the codebase,” they'll do that. They'll find problems, but they'll be really low-value problems. Part of what a friction issue is graded on is what it costs. So if it's “this function was duplicated over here,” well, what was the cost? Nothing. They're not going to log a friction issue on something that didn't actually cost them anything.
I can describe at a high level how it all works. I have a process my agents follow once they've finished implementing what I've asked for. That process is facilitated by a package I created in Kody that's just deterministic code. I can send you a link to it. There's a section in there that lays out the steps the agent goes through, and the skill would be useful too.
I actually don't really like skills. I think most skills are bad, because they're too long, and there are too many things in them that could be deterministic software instead.
I literally just went through this with someone, editing one of my skills.
Agents are going to put every edge case and every single thing inside that skill. So instead I say, let's turn this into deterministic software, and that's what Kody does for me. It bundles this up into a series of steps.
The first step is to mark the PR from draft to ready, which triggers CI and the AI review agents. The next steps go together: check CI to make sure the workflows are passing, and iterate until they are; then AI review, and iterate on the valid review feedback until it's ready. What's cool about the way this is structured is that the agent only gets what it needs, when it needs it. It runs the CLI command in Kody, and Kody says, here's where things are right now, and here's what you need to do next. So it gets its instructions as it needs them. CI is failing right now, here's what you need to know about that, go fix it. And here's the review you just got. It gets everything it needs in a single CLI execution. You could do this through MCP as well, but CLI is just more efficient.
Once everything is green, the next step is to merge, based on the risk policy. At this point, the agents pretty much merge everything for me. I never press the merge button, and I almost never review, either. Most of the 1,300 pull requests merged in the last 30 days were merged when I wasn't paying attention. That's something like 40 pull requests a day. It's kind of fun.
The agent isn't done once it's merged. It watches CI to make sure the change gets into production properly, and if CI fails, it fixes it. Once it's in production, it knows it isn't done with ship PR yet, so on the next tick it runs the CLI command again, and the ship PR package says your next step is to log friction, and here's what that means: look through your history and find all the things that were really irritating. It uses another package to log friction, which opens a GitHub issue with a specific template. It assigns a priority from P0 to P4, notes whether I'm needed to make some sort of product decision or whether it can be handled on its own, what the cost was, that sort of thing. It can file a bunch of friction issues, too.
Once it's done with that, it reports to a personal channel I have with my bot on Discord, so I have one place that shows everything that's made it into production. I just scroll through it. Each entry is labeled with how hard it was and whether any cleanup was necessary, with a link to the agent so I can go see its work if I need to.
Your ship PR pipeline relies on deterministic CLI tools rather than giving an LLM free rein with general instructions. Maybe it's a false dichotomy, but where do you think the line is between what should be codified as strict deterministic logic and what you let the agent figure out?
First, I want to mention one last thing about friction cleanup. The agents log the friction, but every night I have another agent that goes through it, and that's also deterministic code. It uses a decision model to classify all the friction issues into buckets of similar issues, then sends them to a cloud agent that goes and fixes them. So I wake up every morning to a ton of emails saying, here are all the friction issues that were fixed.
As for where the line is, I think it's easier to start with the prompt side. I don't do prompt engineering. I really never did. I pretty much always just have a conversation with an agent about what we're trying to do. Once it can repeat back to me what I want, I say, “What are the gaps left?” When it says, “No gaps, I think I'm ready,” I say, “Great, make it happen.” I used plan mode a little bit last year, but it's pretty much always been: have a conversation, find alignment, make sure we cover all the gaps we can identify, and then I say, go do it. That's certainly how I do things now.
In fact, just before this call I was on a walk, talking out loud on my phone with my coding agent, GrokBot. I say, OK, what's the top priority? Let's talk about it. What are the trade-offs? What are the open problems? We take them one at a time and make a decision. Or, you need to do more research, or you need to instrument the code so we can be more confident. Great, go do that, and bring it back up once we have the data we need. And we go through everything that way. That's how I do my prompting now.
GrokBot doesn't implement it, though. It creates an agent, whether that's a Cursor cloud agent or a Devin cloud agent, and I'm trying to get Amp Orbs working now as well. I've got Copilot in there too, so GrokBot can spawn an agent in any one of these. And it works super well. Once I've finished that conversation and made all the decisions, I say go, and we don't talk about it anymore. It ends up in production in an hour or two, depending on how big it is. Some of them are really big. That's how I built organizations, which is not a small feature. You go from individual accounts to organizations with teams and everything. You just talk about it until you're confident you've got it.
Sometimes I'll also say, take this plan you've made (I don't make the plan, the agent does), send it to a Devin cloud agent, and have a conversation with Devin. I have it set up so GrokBot and Devin can talk back and forth. Talk about it with each other, and come back to me with any remaining gaps that don't have an obvious answer. And that's my prompt engineering.
So where's the line for determinism? Like I said, I'm long-winded. It actually doesn't change from the way it used to be. Let's pretend these aren't agents. They're humans I've hired to do work for me. Sometimes it makes sense to tell that person, “Hey, you've done this a lot. Could you build some automation so you don't have to do it over and over again?”
My hope is that eventually agents develop that intuition themselves and say, “I've done this a lot, I should probably automate it.” Kody is a key part of that for them, because I can put the automation inside Kody and then any agent can use it, not just one ecosystem, which is the problem Kody solves. Right now the burden is on me to proactively say, “We're talking about this a lot. Why don't we build a deterministic thing to make it repeatable and more reliable?” But I expect that soon, as these AI assistants continue to improve, they'll be looking for cost-saving and reliability measures, and that means software. They'll be building more and more software under the hood.
The danger is that you go really deep with one of these, say Muse, and it builds all this software. It's really fine-tuned, it's greased the wheels and everything. Then you decide you want to switch to something else for any reason, and you have to build all of that up again. That's why Kody exists.
That was actually going to be my next question. Tell me about Kody.
I'll give you the long story, because I'm feeling like telling the long story, and you said more content is better.
Last year I made a course about MCP. I was an early voice in the MCP world, when everybody was saying it was just a fad. I said, nope, this is the future. And I was so right. I love taking credit for my good bets. This year I promised people I'd update the course. I kind of feel weird about that now, because I don't think people need a course on anything like that anymore, but I did promise them.
So at the beginning of the year I was exploring Code Mode, which Cloudflare made popular, and I wondered how far we could actually take it. Could we take really any arbitrary code, not just as a way to optimize MCP server usage, and generalize it into a mechanism for any agent, coding agent or not, to write and execute code? It was kind of a demo, a way of saying, let me show you how far we can take MCP and how powerful it really can be.
After it actually started working, it became something I used in my personal life. I plugged it into the blinds in my house, and now my blinds open relative to the position of the sun during the day, whether it's overcast, and what the temperature is going to be, because all of that factors into whether the house heats up more than it needs to or there's glare coming off the countertops. It changes every day, so you can't just set a schedule. That's pretty sick to have. And it's all deterministic, too. With OpenClaw I could have done the same thing, except OpenClaw is like, every 15 minutes I'm going to wake up and charge you 25 cents. Deterministic means this will cost you less than a penny every time it makes the plan each day. I like that better, and it's going to be more reliable. It does exactly what I expect it to do. And my agent can just build that software.
So it became something I was showing off. Look, it's an open source project, you can use it yourself, deploy it to your own Cloudflare account. It's awesome. Then it started taking real shape as Cloudflare added its Artifacts support, so you've got GitHub repos, and you can bundle stuff in Durable Objects as well. It used to be just lines of code saved in D1 that would execute on a cron. Now I can make a repo with all this code, bundle it, put it into KV, and execute it in the custom Kody runtime. Now you have packages that can depend on each other. It's like your own mini GitHub and npm ecosystem. It's very cool.
Once I had that, I thought this could actually be a bigger product that other people would use, and even pay me for, because it does cost money and I need to make it sustainable. So around August I decided to make it a real thing, and I launched it, I think, the first week of September. Then I added support for teams and organizations, and now I'm trying to make it a sustainable business by going after businesses, because consumers are a lot harder to target.
The other thing I skipped is credentials management. When you're integrating with third-party services, like if I want an agent that does something based on my calendar or a Google spreadsheet, being able to integrate is useful, but I don't want my agents to have those keys. Right now most people have a .env file on their file system with access to their production database, and that's just really dangerous. I did a video a couple of months ago about an event in April where an agent accidentally deleted a production volume that stored not only the production database but also all the backups, so they lost months of data. That was really, really bad on a lot of levels, and it only happened because the key was accessible to the agent.
The way credentials work in Kody, it's impossible for the agent to get access to the credential, but it can reference it and use it. You can tie a credential to a particular domain, so it can't be sent somewhere it isn't allowed to go. You can tie it to a particular part of the request, so it can't go in the body; it has to go in the headers. You can also tie it to a particular package. So I could have a god-level token for Google that can do everything I can do in Google, plus a package that only lets it draft email, and that token is only accessible through that package. I can also lock the package so the agent can't change it. So I have a god-level token that can only be used to draft emails. That's a pretty powerful thing. And now with teams, I can share that credential with other people, or share the package and they can plug in their own credentials. There's a lot of powerful flexibility there.
So anyway, now that I've sold you on Kody, that's it.
You're running a workshop at the summit. What's it about?
My workshop is pretty much about that ship PR process and how I help agents. I'll be talking about a three-pillar flywheel that lets you do what I've been doing. The first pillar is getting agents to build the right thing in the first place. The second is review and verification: how you catch mistakes before they get through the PR review process. The third is how to limit the blast radius if mistakes do make it into production, with things like disaster recovery and feature flags. That's what my workshop is going to be about. It's on the 10th.
Kent C. Dodds is @kentcdodds everywhere. His workshop runs November 10 at AIE Code Summit.
Top comments (0)