For ten years I wrote beautiful code. Aligned things on shelves, argued about variable names in code review, defended patterns as if a plane would fall out of the sky without them. And I was good at it. That is why it hurts to be the first to say it out loud: almost everything we called "clean code" — patterns, naming rules, tidy architecture — was not engineering necessity. It was a tax. And I was not the one paying it. The client paid it. We paid with ourselves.
People are ready to burn me at the stake for this, and I understand my colleagues — I stood on the same stake a year ago. But if you want to stay useful as AI changes software work, you have to separate which parts of your work create client value and which parts mostly serve developers.
Who Actually Needed the Beauty
Start with a practical fact: most software is changed many times after release. Software is not written once and forever. By its nature it lives through edits: it gets extended, modified, owned as an asset for years. Enterprise teams understood this early and sat down to figure out how to make owning that asset cheap.
Over time, maintainability became framed not only as a cost concern but as a moral virtue. Well-structured systems give most programmers pleasure. It is simply more pleasant when everything is aligned, neatly organized, and logically connected — not because the code runs better, but because it is more comfortable to hold its mental model in your head. I know this from the inside: a tidy codebase gave me near-physical satisfaction. It had nothing to do with the client's actual problem.
And the primary goal of code — to work and produce the expected result — quietly got swept under the rug. Some teams overvalued internal code aesthetics compared with externally visible behavior, and testing became a separate discipline partly because developers are not always good judges of whether software satisfies users. Think about what that construction is: many programmers are trained to focus on implementation details before user outcomes. So we hire separate people who do not understand code and are not infected by this distortion. In many teams, testers provide an independent check before release. Independent testing helps counterbalance implementation bias.
A revealing contradiction is this. Programmers do not like writing tests — I did not either. But the moment AI appeared, many developers started arguing that its output must be read through by human eyes. You would think it should be the other way around: hand the routine to the machine, save the eyes for problem definition. This suggests that part of the resistance may be about control, not only quality — we are clinging to the part of the job that gave us a sense of control and mastery.
The Maintenance Incentive Loop
Companies then had a straightforward incentive: a satisfied, happy programmer means a sharp drop in total cost of ownership. So they deliberately took away our need to think about the result and built management practices that rewarded maintainability and developer satisfaction. Books like Clean Code helped formalize the culture of readable, maintainable code.
The interpreter does not care what you named a variable — order_sum or x. The code runs identically. But the human labor cost of maintenance is incomparable. So we write "good" code that looks easy to maintain — and therefore it is easy to maintain. Because readable code is easier for humans to modify, teams reward the practices that make code feel readable. The incentive reinforces itself: the programmer revels in the elegance of the mental model, the tester forces them back to the result, the manager maintains the coziness — and the arrangement can satisfy developers, testers, and managers while still hiding cost from the client. For years I was a happy link in that loop and sincerely believed it was engineering.
What AI Did
AI changes this arrangement because it lowers the cost of reading, modifying, or regenerating code.
As coding models improved enough to handle larger maintenance tasks, it turned out that some maintenance practices became less economically necessary. The code works and solves the client's problem — and, for some categories of software, internal elegance matters less when fixes are cheap and fast. To the client, the immediate business impact of a failure may be similar regardless of how the code was produced. From the client's perspective, crashed vibe-code from a junior is indistinguishable from crashed pristine code from a senior — neither in process nor in consequence. The beauty inside stopped being visible from the outside at the exact moment when rewriting a misbehaving piece cost pennies and almost no human involvement.
In some cases, AI can sharply reduce maintenance cost. AI does not care what you named a variable or how many indentation levels you have — it does not read code like a human. Yes, accurate names and clean logic give it an advantage: they are a semantic hint. But not the critical advantage that would make a human either refuse to fix someone else's chaos or charge triple. AI may be able to infer enough context to propose a fix, especially when failures are well specified.
An honest caveat, to avoid overstating the claim. I have one strong case in front of me, not a statistical law. An engineer single-handedly rewrote a legacy codebase roughly ten years old; at 10–15 deploys per day — zero production incidents over six months. This is one case, and I am not presenting it as a proven pattern. But it shows that the possible productivity gain may be large, not incremental. In another context, at a large enterprise client — Askona — AI-assisted development of real microservices (next best offer, warehouse recalculation) runs directly inside the legacy landscape: modernization without a "big bang." These examples suggest AI-assisted development is already being used in production contexts.
The Tax We Hid for Twenty Years
The harder implication is about developer incentives — what this forced me to reconsider about my own work.
A large share of many programmers’ work — and a major expense for clients — was financing future maintenance convenience. Not the code working. The convenience of editing it later. Whether that edit would ever be needed; whether the same person or someone else would make it — it was considered good form to ensure in advance that making a change six months later would be comfortable and cheap, with the cost passed to the client. We called this professionalism. In many cases, maintainability work also protected developer comfort, not only client value.
AI weakens the case for paying as much of this cost upfront. AI can often help parse or rewrite code cheaply enough to change the maintenance trade-off — well, it will spend a few more tokens. No one wants to pay for a programmer's ability to build an elegant mental model in their head: code can be generated from rough requirements, then refined through tests and acceptance criteria, and AI can assist with requirements, architecture sketches, and test generation. The engineer's role does not disappear — it shifts. Not reading someone else's output with your eyes, but setting the task precisely and formulating acceptance criteria. Which, by the way, is exactly what a good engineer was always valued for — just without the layer of ritual beauty.
It is understandable that many developers react defensively. I was burning too — because admitting this means admitting that part of my skill was never about the machine. It was about my comfort and my status. Developers should reassess which skills remain economically valuable before clients force that reassessment. Some clean-code practices were partly developer-comfort costs presented as engineering value. Engineers who can define problems, risks, and acceptance criteria will remain valuable even if code aesthetics become cheaper to produce.