AI made it cheap to write code. It did nothing to make it cheap to own.
That second cost is the one that matters, and it’s the one the velocity conversation keeps skipping. We talk about AI like the win is measured at merge time: the feature that used to take three days now takes an afternoon, so we shipped four of them this sprint instead of one. True, and worth something. But the afternoon was never the expensive part. The expensive part is every day after, for as long as the thing exists, and AI didn’t touch that number at all.
You pay rent on everything you ship#
A feature isn’t a one-time purchase. It’s a lease you can’t easily get out of. Once it’s in production, someone has to read it when it breaks, patch it when its dependencies move, page on it at 2 a.m., explain it to the engineer who joins next year and asks why it works the way it does. Every line you ship is a line someone now has to understand before they can safely change anything near it. That cost compounds quietly, and it doesn’t care how fast the line got written.
What AI changed is the ratio. Writing code used to be the slow, deliberate step, so the act of typing it functioned as a tax on bad ideas. If a feature was going to take you three days, you thought hard about whether it was worth three days. The friction was doing real work: it killed marginal features before they were born. Collapse the build cost to an afternoon and you don’t just build the good features faster. You also build all the marginal ones you’d previously have talked yourself out of, and now you’re paying rent on all of them.
The microservice you knock out between tickets#
A staff engineer I worked with could stand up a small service in an afternoon: a stakeholder in marketing operations needs a feed reshaped, a report generated on a schedule, a webhook that drops data somewhere useful. The kind of ask that used to mean a backlog ticket, a sprint, and a conversation about whether it was worth a sprint. Now it’s an afternoon wedged between two real feature tasks. The work is genuinely good, it solves a real problem, and the person who can knock it out looks like a hero. So why not?
Here’s why not. The service ships, and the org grows around it. The marketing-ops team wires it into their weekly process. Someone builds a dashboard that assumes its output. A downstream team starts treating its once-a-day run as a fact of nature, and three quarters later a person you’ve never met has a Monday routine that quietly depends on that one webhook firing. None of that lives in the code. It’s the processes and workflows that accreted around the code, and it’s load-bearing now in ways nobody wrote down.
Then something has to change. A field gets renamed upstream, the schedule has to move, the one engineer who held the whole thing in their head takes another job. The cost of that change was never the afternoon it took to build. It’s every process that silently took a dependency on the service, unwinding over months because each team has to first rediscover what it was leaning on. The build was an afternoon. The unwind is a quarter, sometimes a year, and it scales with how much came to depend on the thing while nobody was keeping track.
AI didn’t cause that. Bad scoping did. But the friction it removed had been doing real work: the dread of spending a sprint on a marginal service was the thing that used to make someone ask whether it should exist at all. Take the dread away and “should we build this?” quietly collapses into “can we build this?”, and the answer to can we is now always yes, and always soon.
Velocity doesn’t pay down debt; it lets you borrow faster#
This is the load-bearing point, so I’ll say it flat: AI velocity does not fix bad design or technical debt. A faster way to write code you’ll regret is still a way to write code you’ll regret. If anything it’s worse, because the code arrived faster than your understanding of it did, and debt you didn’t fully reason through is debt you don’t even know you’re carrying.
Tech debt was never primarily a typing-speed problem. It’s a decisions problem: the abstraction that didn’t fit, the coupling nobody pushed back on, the schema that assumed something that turned out to be false. Those are judgment calls, and judgment is exactly the part AI hands back to you. Generate a service three times faster and you’ve made three times as many of those calls in the same window, with less time between them to notice you’re getting them wrong. The plausible-looking code is the trap. It compiles, it passes the tests you thought to write, and it commits you to a shape you’ll be living inside long after you’ve forgotten why you chose it.
The counter-argument is real, and it has an edge#
The honest objection: cheap building is genuinely good for learning. Throwaway prototypes, spikes to de-risk an unknown, three versions of an interaction so you can feel which one is right — AI makes all of that nearly free, and that’s a real gift. I’m not arguing for artificial slowness.
But the gift only stays a gift if the cheap-to-write thing stays cheap to own, and there’s exactly one way that happens: you have to actually throw the throwaway away. A prototype that ships is not a prototype. It’s production code that skipped review. The discipline AI demands isn’t typing slower; it’s being ruthless about deletion, and being willing to answer “do we want to own this for the next three years?” with no even when the demo took twenty minutes and looked great.
The question that survived#
The skill that got more valuable this year, not less, is the one that decides what deserves to exist. That used to be partly enforced for us by how long things took to build. It isn’t anymore, which means it has to be a deliberate choice now, made out loud, before the afternoon of building starts.
So the question I make myself answer before I let AI build me something is no longer “how fast can we get this done.” It’s “are we willing to carry this for as long as it lives.” Faster to build was always going to be the easy part to celebrate. Cheaper to own is the only number the future actually pays.
