Picture Dave. Not a bad developer. Six years in, reasonably curious, catches most of the things that matter. Last Tuesday, Dave asked an AI to scaffold a feature. The AI wrote 340 lines in about four minutes. The code passed review. The tests passed. The feature shipped Friday.
The following Monday, the feature had a bug. Dave opened the file and stared at it for eleven minutes before typing a question back into the chat window.
That's the episode I made. Not about Dave specifically... Dave's a composite. But if you've been on a development team in the last two years, you've met Dave. Maybe you've been Dave.
The Cost Nobody's Tracking
There's a metric your team dashboard probably doesn't have: how long does it take a developer to answer a question about code they shipped?
Cycle time. PR count. Lines changed. Test coverage. Nobody's logging the eleven minutes. Nobody's logging it when "what does this do?" becomes "I'll ask the AI."
That's the hidden cost. Not the bugs. The bugs are findable. The cost is that finding them now requires a conversation with a prediction engine instead of a person who actually understands the system.
That compounds quietly. And then one day a senior developer leaves, and the AI doesn't remember what it meant when it wrote the thing, and neither does anyone else.
Where the Bottleneck Went
For most of software's history, the bottleneck was producing code. Senior developers were expensive, good ones were rare, and getting software out the door was genuinely hard.
That bottleneck is basically gone.
Claude Code can build a working feature in the time it takes you to make a pot of coffee. Junior developers can ship code that would have taken a senior developer two days. That's real, and it's not going away.
The new bottleneck is understanding what was produced. And the irony is that we've mostly just accepted it. The code ships, the feature works, and whether anyone on the team could reconstruct the reasoning behind it is a question we've stopped asking.
I think that's a problem that compounds.
Why DDD Isn't Overhead Anymore
I've spent years defending Domain-Driven Design against the "it's too much code" argument. That argument made some sense when every line was hand-written. It makes almost no sense now that the cost of writing a clean domain model is largely free.
DDD, Clean Architecture, Hexagonal Architecture. None of these were invented to make your codebase look impressive. They were invented to make complex systems understandable. To put the language of the business inside the code. To give future developers (and future you) a map.
When AI is writing the code, that map becomes more important, not less. The AI will write whatever you tell it to write. Give it a clean direction with clearly named concepts that match your domain, and you end up with code a person can actually read. Give it vague instructions inside a vague architecture, and you end up with 340 lines of passing tests that nobody can explain.
I've seen both outcomes. The difference isn't the AI. The difference is whether the developer understood the domain before writing the prompt.
The Five-Minute Habit
I cover this in the episode, and I won't give the whole thing away here, but the short version is this: before you prompt, write down what you're building and why. Not a ticket description, not a feature name. The actual intent. What domain concept is this touching? What is the expected behavior in business terms? What would make you confident this is correct?
Five minutes of that changes the code the AI produces. Significantly.
It also changes what happens when something breaks. Because the intent is written down, the debugging conversation is between you and the domain... not between you and an AI trying to guess what was meant.
That's staying in control of what you're building. In a year when the tooling can write faster than most of us can think, that habit is the job.
There's more in the episode. The hidden cost argument gets a fuller treatment there, and I talk through a specific exercise you can start on Monday morning.
I read every comment. Drop your war story below: the bug nobody could trace, the service nobody could explain. Those are worth hearing.
John Nickell — The Thinking Engineer
