Code Is Cheap. Judgment Isn't.

AI Didn't Lower Your Costs. It Just Moved Them.

The Cost You Don't See

I've been talking to a lot of founders lately who are thrilled about what AI has done to their velocity. And they should be. Writing code has never been cheaper. A single engineer with the right tools can now produce in a week what used to take a small team a month. If you're a founder watching your burn rate, this feels like a gift.

It is a gift. But it's also a trap, and most teams don't see the trap until they're already standing in it.

Here's the trap: the cost of writing code has collapsed, but the cost of owning code hasn't moved. If anything, it's gone up. And because these two costs used to be roughly correlated, a lot of smart people are making decisions today based on an assumption that quietly stopped being true.

Let me explain what I mean, because this isn't an anti-AI argument. I'm not interested in being a skeptic for its own sake. I'm interested in making sure the teams I work with are making decisions with their eyes open.

Two Teams

Picture two startups, both about eighteen months old, both with product-market fit, both scaling their engineering org from five people to fifteen.

Team A has fully embraced AI-assisted development. Every engineer is shipping faster than ever. The backlog is getting crushed. The CEO is in investor meetings, pointing at velocity charts. Features that used to take a sprint now take two days. Everyone feels great because everyone is used to measuring engineering health by output.

Team B has also embraced AI-assisted development, but they've made one different choice. Before anything ships, someone senior asks a question that Team A stopped asking: Does this belong in the system, and who is going to own it in a year?

Six months later, Team A is in trouble. Their codebase has tripled in size. Nobody can tell you with confidence what half of it does, because a lot of it was generated in an afternoon by someone who has since left, or by an engineer who accepted a plausible-looking suggestion without fully understanding it. Every new feature takes longer to build than the last one, not because the AI got worse, but because the surface area the AI and the humans both have to reason about keeps growing. Onboarding a new engineer now takes three weeks instead of one. Incident response is slower because nobody has a mental model of the system anymore, just a collection of parts that were each individually easy to produce.

Team B is not shipping as fast as Team A was six months ago. But they're shipping faster than Team A is shipping now. Their codebase grew too, but it grew the way a well-tended garden grows, not the way a vacant lot grows.

This is the story I keep seeing play out, in different forms, across the companies I work with. And it comes down to a single confusion: teams are optimizing for the cost of creation when the cost that actually determines their fate is the cost of ownership.

Why This Confusion Is So Easy to Fall Into

For most of the history of software development, the costs of writing code and owning code were entangled. If code was expensive to write, someone had usually thought hard about it before writing it, which meant it tended to be more thoughtfully architected, which in turn meant it tended to be cheaper to own. Scarcity forced discipline.

AI broke that entanglement. Now you can generate code faster than you can think about whether you should. The discipline that used to be forced on you by the cost of typing is gone, and very few teams have replaced it with a deliberate discipline of their own choosing.

This is the part that worries me most. It's not that AI writes bad code. Often, it writes perfectly reasonable code. The problem is that reasonable code, written without a clear owner and without a clear understanding of how it fits into the broader system, accumulates into something nobody can reason about. You don't get one catastrophic failure. You get a slow, compounding tax that shows up as everything simply taking longer than it should and nobody being able to say exactly why.

The Decision Costs More Than the Fix

Here's something I've noticed that doesn't get talked about enough: as the cost of writing code drops toward zero, the cost of deciding whether to write it becomes, by comparison, enormous.

Think about what a good decision actually requires. Someone has to understand the current system well enough to know where a new piece of functionality belongs. Someone has to think through the edge cases, the failure modes, the way this will interact with three other features six months from now. Someone has to decide whether this is a one-off or the first instance of a recurring pattern, and architect accordingly. None of that gets faster because AI can write the implementation in ten minutes instead of two days.

If anything, the decision gets harder because the volume of decisions you're now capable of acting on has gone up. When it took two days to build something, you had a natural filter. Only the ideas that survived two days of friction made it into the codebase. Now that filter is gone. Every idea that seems reasonable in the moment can be in production by the afternoon, and the actual cost of that decision, the cost of maintaining it, testing it, explaining it to the next engineer, reasoning about it during an incident, doesn't show up until much later.

I've started telling product leaders that the scarce resource has shifted. It used to be engineering hours. Now it's judgment. Specifically, the judgment required to say no to a perfectly buildable thing because it isn't worth what it will cost to own.

This is uncomfortable because judgment doesn't compress the way code generation does. You can 10x your code output with a good AI tool. You cannot 10x your output of good decisions about what belongs in your system, because good decisions require understanding, and understanding still takes the time it takes.

Bloat Is the New Technical Debt

We used to talk about technical debt as the primary risk of moving fast. Technical debt was a reasonably well-understood concept: you cut a corner, you knew you cut it, and you'd pay it back later with interest.

What I'm seeing now is different, and I think it deserves its own name, because "technical debt" implies a conscious tradeoff, and this isn't always conscious. Call it bloat. Bloat is what happens when a system accumulates capability faster than it accumulates understanding. Nobody made a deliberate bad trade-off. Nobody said, "Let's cut this corner." Instead, twenty small, individually reasonable additions got made by twenty different people, or by one person twenty different times, none of whom had the full picture, and the aggregate result is a system that is more complex than any single person's mental model of it.

Bloat is more insidious than debt because debt announces itself. You know where you cut the corner, even if you don't fix it. Bloat doesn't announce itself. It shows up as a gradual, hard-to-diagnose slowdown. Your team feels like it's working just as hard, but the same relative velocity now moves less. Nobody can point to the single decision that caused it, because the cause is not a decision, it's an accumulation.

The uncomfortable truth is that AI is very good at helping you add capability and not particularly good at helping you decide whether that capability should exist at all. It will happily generate a new endpoint, a new configuration option, a new special case, and a new abstraction layer, all matching your existing code style. All are reasonable in isolation. AI has no opinion about whether your system needs one more of anything. That opinion has to come from a human, and it has to come before the code gets written, not after.

The Maintenance Bill Always Comes Due

Every line of code you own, however it got written, carries a maintenance obligation for as long as it exists. It needs to be understood by whoever touches it next. It needs to be tested when adjacent things change. It needs to be considered during every architectural decision from that point forward. It needs to be explained to every new hire who will be working near it.

This obligation doesn't care how the code was produced. Code generated by AI in ten minutes carries exactly the same maintenance burden as code a senior engineer labored over for two days, and in practice it often carries more, because the person who "wrote" it, in the sense of typing the prompt, frequently understands it less deeply than someone who built it line by line would have.

This is the part that CEOs and boards tend to miss, because the metrics they're used to watching, velocity, feature output, sprint completion, all measure the cost of creation. None of them measure the cost of ownership directly. That cost shows up later, in engineering headcount that has to grow faster than it should just to keep the lights on, in bug rates that creep up, in the growing gap between how fast the team feels like it should be moving and how fast it actually is.

If you want a leading indicator rather than a lagging one, ask a different question in your engineering reviews. Not "how much did we ship this quarter." Ask "How much of what we shipped could a new engineer understand and safely modify within their first month?" That second number tells you what your real velocity is going to look like a year from now.

What This Means for How You Lead

None of this is an argument against using AI to write code. That would be like arguing against the printing press because it made it easier to publish bad books. The tool is not the problem.

The problem is treating the drop in the cost of creation as a drop in the cost of ownership. It isn't. The two have decoupled, and the leaders who understand this are the ones who will actually benefit from the speed AI offers, because they'll spend it on the right things.

Practically, this means a few things. It means the review that matters most isn't the code review; it's the decision review, the conversation about whether this should exist at all, and that conversation has to happen before the AI starts generating, not after. It means treating your codebase's simplicity as an asset you actively protect, the same way you'd protect runway or customer trust, rather than a side effect you hope works out. It means measuring your team's health by how well a new person can navigate the system, not by how much the system produced last quarter.

The founders who get this right won't be the ones who move fastest in year one. They'll be the ones who can still move fast in year three, because they spent their AI-driven speed on judgment instead of just accumulation. That's the real advantage available right now, and it has almost nothing to do with how fast anyone can write code.