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" \u2014 patterns, naming rules, tidy architecture \u2014 was not engineering necessity. It was a tax. And I was not the one paying it. The client paid it. We paid with ourselves.<\/p>\n
<\/p>\n
People are ready to burn me at the stake for this, and I understand my colleagues \u2014 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.<\/p>\n
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.<\/p>\n
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 \u2014 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.<\/p>\n
And the primary goal of code \u2014 to work and produce the expected result \u2014 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.<\/p>\n
A revealing contradiction is this. Programmers do not like writing tests \u2014 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 \u2014 we are clinging to the part of the job that gave us a sense of control and mastery.<\/p>\n
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<\/em> helped formalize the culture of readable, maintainable code.<\/p>\n The interpreter does not care what you named a variable \u2014 AI changes this arrangement because it lowers the cost of reading, modifying, or regenerating code.<\/p>\n 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 \u2014 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 \u2014 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.<\/p>\n 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 \u2014 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.<\/p>\n 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\u201315 deploys per day \u2014 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 \u2014 Askona \u2014 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.<\/p>\n The harder implication is about developer incentives \u2014 what this forced me to reconsider about my own work.<\/p>\n A large share of many programmers\u2019 work \u2014 and a major expense for clients \u2014 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 \u2014 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.<\/p>\n 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 \u2014 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 \u2014 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 \u2014 just without the layer of ritual beauty.<\/p>\n It is understandable that many developers react defensively. I was burning too \u2014 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.<\/p>\n","protected":false},"excerpt":{"rendered":" For ten years I wrote and defended beautiful code. Now I can admit what it actually was: a tax on future maintenance convenience, billed to the client.<\/p>\n","protected":false},"author":0,"featured_media":140,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-141","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-uncategorized"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\torder_sum<\/code> or x<\/code>. The code runs identically. But the human labor cost of maintenance is incomparable. So we write "good" code that looks easy to maintain \u2014 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 \u2014 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.<\/p>\nWhat AI Did<\/h2>\n
The Tax We Hid for Twenty Years<\/h2>\n