A few months ago I watched a sprint board do something I’d never quite seen before. Story cards weren’t stacking up in In Progress. They were stacking up in Ready for Review. On every project I’d ever worked on, the bottleneck was writing the code. Suddenly, on this project, it wasn’t.
So how’d we get here?
We had a feature with a generous estimate and a runway that was definitely not generous. So we decided to try spec-driven development with Get Shit Done (GSD), an open-source tool that turns research and context into structured, executable development plans. Pair that with Claude Opus 4.6 as the coding agent and a disciplined review process, and you get a workflow where the agent writes the first draft of an implementation, and the team takes it the rest of the way. What surprised me wasn’t the speedup. It was where the slow part went.
The thing about getting faster
When people talk about AI making software development faster, they usually mean writing the code. That’s the part you can put on a stopwatch. Our shortest time from pickup to pull request was 21 minutes. Great headline.
And it’s true. We saw it. The writing part got dramatically faster. So fast that work the team had estimated in months came together in weeks. We finished in a fraction of the time the original plan called for, and that wasn’t a rounding error. The time savings were real, and they were big.
Here’s the part no one warned me about. When writing gets that fast, it stops being the longest part of the work.
On our team, the median time from picking up a story card to having a pull request open dropped to about a day. And then? The PR sat for three days waiting on review. Then it sat for three more days in QA. Writing time collapsed. Review time didn’t. So even as the whole pipeline got faster, the shape of where time goes flipped completely.
The bottleneck didn’t go away. It moved.
What it feels like from inside
This is the part I didn’t expect to be a feeling thing, but it absolutely was.
I’m a developer. I’ve spent two decades writing software. I love writing software. When the agent started producing the first draft of every implementation, what was left for me was reviewing, redirecting, testing, and refactoring. All of those are skills. All of those are valuable. None of them feel the same as writing the code yourself.
The word that came up for me, once I sat with it, was grief. I was mourning the job I used to have. The craft I’d built over years of writing code. The skills I’d worked hardest to build, and was proudest of, suddenly weren’t the ones the work was asking for. Watching an agent do the part you used to be best at, faster than you can, is not nothing. It’s a real loss, even when you know the trade is worth making.
You can’t wave that off. What I’ll say is the work didn’t go away. It became different work. Reviewing agent-generated code well is its own craft. You have to know what good looks like, what your team’s standards actually are, and where the agent’s blind spots tend to be. Spoiler: it has plenty.
The hard parts didn’t disappear. They just stopped being the initial generation.
When the bottleneck moves, look at it honestly
Here’s the thing about a bottleneck. When you remove the one in front of you, you don’t get a frictionless world. You get a new bottleneck. And usually it’s one you’d never had reason to look at, because the old one was bigger.
For us, the new bottleneck was the review pipeline. Code review, QA, the back-and-forth between developers and reviewers. It was fine before, because writing the code took longer than reviewing it. Now? The review pipeline was the constraint.
That’s actually useful information. The writing speedup is real, and it showed up in our cycle times. What it also did was make the review pipeline the biggest chunk of time left. Not as a problem, but as the new place where humans add the most value.
What stays the same
The work changed shape. The principles underneath it didn’t.
Every line of code we shipped, a human signed off on. Reviewed it. Ran it. Tested it against the running application. Pushed back when something wasn’t right. That’s two agile principles holding their ground at once: individuals and interactions still matter more than the tools we hand them, and continuous attention to technical excellence still defines what’s worth shipping. If anything, both got more important.
Spec-driven development pushed the thinking earlier and the judgment later. The thinking part (what are we building, why, what does done look like) has to be done up front, because the agent is going to take you at your word. The judgment part (is this what we actually want, does it hold up, would I be proud to ship it) has to happen on every PR, because the agent will happily produce code that’s technically correct and contextually wrong.
It’s still humans, top to bottom. It’s just humans doing different things.
The honest takeaway
We delivered the feature in a fraction of the estimated time. That’s the headline, and I’m not going to pretend it isn’t.
The quieter thing we learned, and the thing I’m carrying forward, is what the work has become. The typing got cheap. The judgment didn’t. Knowing what good looks like, holding the bar, catching what the agent gets wrong. That’s the developer’s work now. The team that wins isn’t the one that writes the most code. It’s the one that knows what to do with it.
Speed was the prize, and we got it. What’s stuck with me is a clearer picture of where the work actually lives now.