Ten Years of Edge Cases Don't Compress

A question comes up often in build-versus-buy conversations now: if AI can write a custom solution in weeks instead of quarters, why pay for a specialized tool built by someone else? The pitch used to be that you don't have time to build it yourself. AI just took most of that argument away.

What AI actually sped up

AI collapsed the time it takes to write code. The time it takes to have already been wrong ten thousand times in ten thousand small ways, and to have quietly fixed each one, hasn't moved at all.

A tool built for one narrow job usually isn't valuable because of what it does on day one. It's valuable because of what got added on day 4,000: the regulatory filing quirk that only surfaced in production, the edge case a real customer hit in year 3, the workaround for an integration that was never documented properly the first time. None of that shows up in a requirements document. It shows up over years, one incident at a time, in a place a fast build can't reach no matter how fast the build is.

Why faster isn't the same as sooner

A custom build written this quarter starts at zero on that account, regardless of how capable the AI writing it is. It will hit its own first edge case at some point, the same way every mature tool once did. The difference is that a specialized tool already survived that moment, years ago, quietly, for someone else.

This is the same drift I've written about in the recovery essays, just showing up somewhere new. Delivery drifted because speed removed the pause that used to catch it. Testing drifted because the same AI that wrote the code also wrote the tests. Here, the drift is in judgment: speed makes it easy to mistake "we can build this now" for "we already know what this needs to do."

What actually changes the calculus

AI can usually build it. The useful question is who has already paid the cost of being wrong in the specific ways this kind of problem usually goes wrong.

• Buy when the edge cases are generic to the job and someone else has already absorbed them.
• Build when the edge cases are specific to your business and a vendor has no reason to have seen them.
• Be honest about which category you're actually in, because "we can build it faster now" tempts both sides toward the wrong answer.

The "ten years" in the title is a shorthand for the compounding effect of small corrections, not a literal claim about any specific tool. Each edge case is cheap to fix the first time it appears, and expensive once a system has hardened around it.

Speed used to be the excuse for skipping the real build-versus-buy question. AI removed the excuse.

The fast layer can write the code in an afternoon. The slow layer is whoever already knows, from years of getting it wrong, what that code actually needs to do.