Aligning got nothing at all.
AI helps. I want to say that plainly up front, because what follows is not a “this is all hype” piece. It really helps. But the hard part of building software was never the part it helps with, and I think we’re about to spend a lot of money re-learning that.
Building got cheap. That changed everything and nothing.
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.
There were always three costs in shipping software: building it, deciding what to build, and aligning people around the decision. Agents crushed the first one. They did nothing to the other two. Hold onto that, because the cost didn’t vanish. It moved to the two places we’re not looking.
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.
So far, so much like every other AI take. Here’s where it stops being comfortable.
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. The discipline gap and the harness gap are the same gap, told twice. Speeding up production without shoring up either of them just gets you to the regression faster.
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.
The bottleneck didn’t move. It was always there. Building was just big enough to hide behind. Optimise the keystroke all you like; the loop still runs through people. That’s the second cost, deciding, and it’s now the expensive one.
Align: the part AI doesn’t touch
Which brings me to the third cost, and the one I actually want people to sit with. Building got cheap and deciding got expensive; aligning got nothing at all. It’s the hardest of the three, and the one that gets the least airtime.
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.
Here’s a question worth sitting with, one I’ve seen Smruti Patel pose and haven’t stopped thinking about. Two engineers, comparable impact; one leaned hard on AI, one barely touched it. How do you rate them? Every answer trips you. Reward the AI user and you’re paying for tool adoption, not outcomes. Reward neither and you’ve told the team outcomes don’t matter. And the uncomfortable one: if the engineer who didn’t use AI delivered the same impact, what does that say about the advantage your AI was supposed to give you? We optimise what we reward; it’s the oldest truth in managing people. So if you start rewarding “AI usage,” you’ll get usage. Dashboards full of it. Whether any of it turned into value is a different question, and it’s the only one that matters. We got very good at rewarding output, and output was never the hard part.
You don’t fix that with a better agent. (Unless the plan is to replace every human with an agent; if that’s your plan, this isn’t the post for you.) People remain the load-bearing part of the system. The work is the same unglamorous work it always was. Get aligned, decide well, and make the decision stick, then bring people with you. The agents make the building fast; they do nothing for any of that, and they raise the stakes on getting it right.
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. A factory decides once and builds forever. Software decides forever, and the more humans involved, the more deciding there is. There’s no line to build.
There’s a tempting answer to all this: run a proper change programme. 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-programme; 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. When the field redraws itself monthly, a slow disciplined rollout isn’t caution, it’s a bet that best practice is about to settle down. It isn’t. The muscle worth building isn’t a rollout plan; it’s the ability to re-decide quickly, because you’ll be doing it constantly.
Go fast alone, go far together — but winning is together.
There’s an old line: if you want to go fast, go alone; if you want to go far, go together. AI has made “go alone, go fast” almost trivially true. One person with the right harness can move at a pace that would’ve needed a team a year ago. That’s the shiny part, and it’s real.
But going fast alone doesn’t win. It gets you a POC, a spike, a strong opinion; three steps down a road nobody agreed to. Going far, building something that lasts, that a team can own and maintain and actually ship to customers, still needs the together part. And the together part is exactly the bit AI left untouched.
So here’s where I’ve landed. There are no silver bullets, and anyone selling you one is selling you the easy half; the building. The hard half is the same as it’s always been. None of us has the operating model for this yet. We’re all writing it live, in real time, and the best practices haven’t crystallised because there hasn’t been time. Waiting won’t help. What helps is comparing notes, stealing shamelessly from anyone a step ahead, and iterating on how you work with the same energy you’re putting into what you build.
Go fast where going fast is free. But the winning is still together, and that was always the hard part.