Nobody Knows Anything Anymore (and the Bill Is Coming Due)

AI writes average code. The expensive part is that nobody understands it — and maintenance is 60 to 80 percent of the cost.

The interesting thing about the AI-coding panic is not whether the machine writes good code. It is what happens to everything nobody bothered to understand in the first place.

This week a short post on ssp.sh caught fire on Hacker News — 317 points, 204 comments as of Monday afternoon, posted by zazuke — with a thesis that lands sideways against most of the debate. The problem, it argues, is not AI code. It is that nobody knows anything anymore: not the system architecture, not the intent behind why choices were made. The author reports a discussion where the counterpoint ran that AI writes roughly average code — “so if your code base was below average AI can easily improve it up to average.” His answer: average code was never the threat. The threat is a team that ends up with no plan whatsoever, because everyone just asks Claude.

The post’s centerpiece is an account, quoted from an engineer’s post online, of life inside a big company where middle management is pushing AI hard. Specs, code, tests, PRDs, tickets, resolution of those tickets, reports — everything is made by Claude Code. People are working 12 to 13 hours a day just to press enter. Nobody is reading anything. From L1 to L7, the author writes, everyone is doing the same thing: talk to Claude. Nobody is resolving bugs. In reality, nobody is thinking anymore. Everything is done by LLMs.

That sounds like hyperbole. It isn’t the whole story. But the interesting part of the story is not the code that comes out — it is the bill that comes due later, and who gets to pay it.

The bill arrives at maintenance time

Software-engineering economics has one of its least contested findings: maintenance consumes roughly 60 to 80 percent of a software system’s total lifecycle cost. That figure comes from decades of cost research, repeated in textbooks and course notes — post-deployment work (fixing bugs, adapting to new environments, adding features) is where the overwhelming majority of the money goes.

And what is maintenance, exactly? It is reading someone else’s intent. You are staring at a module trying to reconstruct why it exists, what it was allowed to do, what it was never supposed to do. Architectural knowledge and design intent are not decoration on top of code. They are the only thing that makes the expensive phase possible.

So run the arithmetic for the team described in that account. If nobody on the team knows why anything was built, and every artifact — the spec, the PRD, the tests, the resolution — was itself generated by a model, then you have optimized the cheap phase (initial generation) and maximized the cost of the expensive one (maintenance). A codebase that nobody understands is not a codebase; it is a liability wearing a codebase’s clothes. You pay full maintenance price with zero comprehension discount.

The ssp.sh post gets this exactly right in its closing section: “the final boss is, and always will be, maintainability. The easier it is to generate a quick pipeline, app, or BI dashboard, the more you have to maintain. And if nobody knows a thing, that can get really hard.”

The counterargument is half right

The Hacker News discussion, to its credit, did not simply nod along. The most substantive pushback was that this was already the state of things before AI. Leaders followed internal committees that followed consultants’ recommendations that recommended whatever everyone else was doing, plus a Gartner slide. The motivation was equally dubious; most developers already had problems with management and product direction, and many did not bother to question it. AI, on this view, did not invent intent-free software development. It just made it obvious.

That is only half the decision, though. The other half is velocity. Pre-AI, the gap between understanding and shipping was bounded by how fast humans could type, review, and rubber-stamp. A committee could produce incomprehensible architecture, but it took quarters to do it. Now an L1 engineer can generate a month of uncomprehended architecture before lunch. The disease is old; the transmission rate is new. Technical debt used to accumulate at human speed. It now compounds at machine speed — while the one asset that pays it down, human comprehension of the system, stays exactly as scarce as it ever was.

Another commenter on the thread coined the phrase of the week: “commitment laundering.” People pass around AI artifacts that nobody has necessarily read or considered, and the invented assumptions and tagalong commitments just keep piling up. They look like they have real provenance. Nobody can say what is being done or why. That is the cost mechanism stated plainly: every generated artifact carries implied decisions, and those decisions have to be understood and owned eventually — at maintenance rates, by people who did not make them.

The thread’s top comment made the same point by tracing a lineage. The code was stamped by Claude, driven by a prompt, for a ticket generated with the Atlassian AI integration, which digested docs made with AI, from strategy memos the commenter was “90% sure were written entirely by Claude,” chosen by execs who now communicate mostly via AI-written memos. “Nobody in this ecosystem, I thought, is actually in control here.” Ironically, as the commenter noted, it resembles exactly the kind of misaligned superintelligence we were supposed to be avoiding — except it was built out of org charts.

What survives

The original post ends where the serious builders end up: intent, taste, design, and architecture are “killer features in today’s world.” And there is one line that deserves to be framed: “AI can’t prompt itself.”

That is the asymmetry the whole debate keeps circling. Generation is infinite and cheap. Direction is scarce. The engineer who can say why a system is shaped the way it is — the one who holds the architectural intent in their head, or better, in a written record that outlives the sprint — is now the most expensive person in the building, because they are the only one who can make the maintenance phase work.

For builders, the takeaway is practical: write down the why, not just the what. Architecture decision records, design docs with the alternatives considered and rejected, the boring paperwork of intent. These were always good practice. Now they are the only insurance policy against a codebase whose generation cost was near zero and whose maintenance cost is about to be 60 to 80 percent of everything. A model can write the code. It cannot decide what the code is for, and it cannot take responsibility for the answer.

The post quotes one more line worth keeping: the team where nobody reads anything is described as “soul-sucking” not because the work is automated, but because the engineer is reduced to pressing enter for 13 hours. The victory condition disappeared. Nobody is resolving bugs, because resolving a bug requires knowing what the system is supposed to do — and that is the one artifact nobody generated.

If that sounds less like a technology problem than an accounting problem, that is because it is one. The invoice for code nobody understands is simply mailed to the future.

Source: The Problem is not the AI Code, but Nobody Knows Anything Anymore