AI has made a first implementation much cheaper, and I use it a lot. Deciding what to build and getting people aligned around it still take time. I think we’re underestimating those costs because the building now feels so fast.
How cheaper implementation changes when we decide
I’ve been doing this for twenty-odd years, and one trade-off never moved the whole time: building was expensive, so you aligned first. You argued it out, you decided once, and you built it once; building it twice was a luxury nobody could afford. Every process we have is downstream of that one fact. Design docs, ADRs, sprint planning, the lot.
Shipping software means building it, deciding what to build and getting people aligned around the decision. Agents have made the first part much cheaper. We still have to do the other two, and they account for more of the work now.
Agents flipped it. First-pass code is nearly free now. And that breaks an instinct a lot of us still lean on: get it right and get it optimal before we commit. That instinct was rational when building was the expensive bet. It isn’t now. When building is cheap, holding out for optimal is fighting the last war; good enough and iterate beats it, most of the time.
We shipped more AI code. Regressions went up.
We’ve got more AI-written code going through, and our regressions rose. Not catastrophically, but measurably, and in the wrong direction.
The agents didn’t invent a new problem; they widened one that was already there. First-pass code being free doesn’t make working code free. That still depends on your harness: your tests, your CI, your validation environments, all the scaffolding that turns a plausible diff into something you’d actually ship. If that scaffolding was thin, agents don’t paper over the gap. They pour more code through it, faster, and now you can see exactly where it’s thin.
People stopped testing the UI, too. The agent felt authoritative and the work felt done, so people stopped checking. We gave the agent too much autonomy, and our automated checks weren’t enough to catch what people had stopped looking for.
You can POC in an afternoon what took a sprint. And still spend three weeks getting buy-in.
This changed how I think more than anything else here.
We sped up the building and we sped up nothing else. I can now have a proof of concept ready before the meeting where we’d previously have debated whether to build it at all. On paper that’s a gift. In practice it throws the real bottleneck into sharp relief, because the POC was never the hard part. Getting a room of people to agree was the hard part, and that got no cheaper.
There’s an interesting shift buried in here. Garry Shutler has written well about ADRs moving after the build rather than before it; you used to reason your way to a decision on paper, now you spike three versions and decide on evidence. And he’s right that the rigour goes up. The decision is better for being grounded in things you built rather than things you imagined. I’ve felt that. It’s real.
But we haven’t priced it. We’re building three solutions to write one ADR, and nobody’s asked whether that’s cheaper than the early alignment it replaced. Sometimes it clearly is; the argument evaporates when you can just look at the three options running. Sometimes you’ve spent three lots of build cost, plus the tokens, to arrive somewhere a ten-minute conversation would have taken you. Just because I can build it three ways doesn’t settle whether I should. We’ve swapped a known cost (argue first) for one we haven’t measured yet (build first, decide after); and we’re calling it progress because the building part feels fast.
Deciding was already slow. It was less obvious when implementation took so much longer, and faster code generation hasn’t shortened the conversations we need to have.
Getting people aligned still takes time
Every hard problem I’ve had in twenty years of shipping software was, underneath, a people problem: alignment, buy-in, someone’s mental model of the system being subtly out of step with someone else’s. Change management, getting a team to actually adopt the new way rather than nod along and carry on as before, has always been harder than the technical work, and it’s never been close.
None of that got cheaper this year. If anything it got harder, because the surface area moved faster than the humans did. When one person can now do what a team used to do, they can also get three steps down a path everyone else disagrees with before anyone’s noticed. Individual speed went up and organisational alignment took a step back. The tooling raced ahead; the coordination didn’t.
Smruti Patel posed a question I haven’t stopped thinking about. Two engineers have comparable impact; one leaned hard on AI and one barely touched it. How do you rate them? If we care about outcomes, comparable impact should count equally. Rewarding the AI use itself encourages more usage without telling us whether it produced more value.
You still need people to agree what matters and follow through on the decision. (Unless the plan is to replace every human with an agent; if that’s your plan, this isn’t the post for you.) Faster building makes that work more urgent, because someone can get much further before anyone else has agreed to the direction.
This is where I part ways with the “software factory” framing that’s everywhere at the moment. It’s the wrong metaphor, for two separate reasons. A factory produces identical widgets, and its whole economic logic depends on that sameness; software’s value is precisely the bespoke part, and not every pull request is the same. If it were, you’d buy it off the shelf instead of building it. And a factory line runs without a human standing in it; software doesn’t. Even the impressive solo-dev setups doing the rounds, the ones turning Linear into an agent control board, keep a human firmly in the loop for the decisions that matter. That’s the tell. Those systems work beautifully right up until there’s a second human. With one operator the alignment cost is zero; it all lives in one head. Add a team and “decide” and “align” stop being something one person handles between agent runs and become the whole job, happening in parallel, across people who each think their branch is the agreed one.
There’s a tempting answer to all this: run a proper change program. Stage it. Crawl, walk, run; experiment for a month, evaluate for a month, educate, then expand over a couple of quarters. I understand the appeal, and the thinking behind these playbooks is often good. But a six-month structured rollout quietly assumes the ground stays still for six months, and right now it doesn’t. The tools you’re carefully evaluating in week eight have changed by the time you finish; the models jump a tier mid-program; half your “validated practices” are stale before they’re rolled out. That’s the same “get it optimal first” instinct from earlier in this piece, just applied to process instead of code, and it’s fighting the same last war. A rollout needs room to change as the tools and our understanding change. We should expect to revisit decisions during it.
We don’t have a settled operating model for this yet. What helps is comparing notes, stealing shamelessly from anyone a step ahead, and changing how we work as we learn what faster building does to the rest of the organisation.