The Maintenance Moat

There is a speech that gets given in every build-versus-buy meeting, and it has been given so many times that nobody examines it anymore. It goes like this: sure, your engineer can prototype this in a weekend, but who hardens it? Who handles the edge cases at scale? Who maintains it in three years when the person who built it has left and taken everything they knew about the codebase with them? The speech always wins, because everyone in the room has lived through the alternative — the internal tool that became load-bearing and then became unmaintainable, the spaghetti nobody dared touch. An entire industry was financed on that speech. The sticker price of enterprise software was never the price of the software. It was the price of not having to give a good answer to those questions.

The speech has quietly stopped being true, and the reason is simple enough to fit in a sentence: if the code was written by AI, it can be maintained by AI. There is no tribal knowledge to lose, because the knowledge was never tribal. Nothing walks out the door when the engineer leaves, because the thing that used to walk out the door — the undocumented assumptions, the private shortcuts, the mental map of why the module works the way it does — was never locked inside a person. The codebase is text, and reading text — holding all of it in view at once, tracing what depends on what — is precisely the thing these systems do better than any human ever has.

It is worth sitting with how completely this inverts the old logic. Human-written code was the hard kind to maintain, and not incidentally. It carried the fingerprints of whoever wrote it — their style, their cleverness, their era's conventions — and every fingerprint was a small tax on the next person who touched it. AI-written code trends the other way: toward the standard pattern, the documented interface, the shape the next model can parse without ceremony. The maintenance loop becomes machine-to-machine, with a human deciding what should change and why, which was always the part of maintenance that actually required a human. The battle-testing objection erodes the same way, because the model that drafts the system also drafts the tests, enumerates the edge cases, and explains itself to whatever comes next.

Once the maintenance story collapses, the full accounting on the buy side becomes visible for the first time, because nobody ever did the honest comparison while building was prohibitively expensive. The purchased platform was never just its subscription fee. It was the translation layer between the vendor's data model and yours, the eighty percent of features you paid for and never opened, the integrations that hardened into dependencies, the exit cost that compounded silently with every workflow that learned to live inside someone else's interface. Those costs were always there. They were simply invisible next to the one number everyone could see: what it would cost to build the thing yourself. That number is now falling fast enough that the comparison keeps flipping, category by category, and the crossover point only moves in one direction.

The early evidence will not look dramatic. It will look like churn that doesn't route anywhere — customers who leave and never show up on a competitor's logo slide, because they left for something internal, something that does exactly what they need and nothing else. That is a threat no roadmap answers, because you cannot out-feature a customer whose entire point is that they didn't want the features. What survives this are the vendors sitting on gaps that stay genuinely expensive to cross even with AI in hand: real infrastructure, regulated domains, network effects that live between customers rather than inside the product. Everyone else was selling a maintenance story, and the value, as usual, retreats to the one place it can't be generated on demand: knowing what to build, and knowing when it needs to change.