The unit of maintenance moves
from code to context.

The story that coding got faster is the tip of the iceberg. What is happening below the waterline is a structural change in the maintenance phase itself.

1-01 established that AI became the strongest SIer. It does not only write code; it understands context and designs. The first consequence to derive from that is not the often-told "coding gets faster." It is that the structure of maintenance rearranges. This chapter looks at that rearrangement.

In the life of software, coding is only the first few months. The long remainder is maintenance. And maintenance eats *40 to 80 percent of software cost, 60 percent on average* (Robert L. Glass, "Frequently Forgotten Fundamental Facts about Software Engineering," IEEE Software 18(3), 2001). It was written up a quarter of a century ago, and measured before that.

Maintenance today turns entirely around code

What gets talked about with AI is that code gets written faster. That is true, but it is only the tip of the iceberg. The dominant cost of software development is not in writing but in what comes after writing. It has been measured, again and again, since the 1980s. The body hidden below the surface is this.

• Reading existing code — the dominant activity within maintenance
• Fixing without breaking existing behavior
• Keeping tests in sync — gets deferred
• Keeping docs in sync — usually left to drift
• Spec going implicit — unrecoverable once the people are gone
• Technical-debt accumulation — slowly and surely, every year

Traditionally, the unit of maintenance was code. A bug appears. You read the code. You fix the code. You write the test. You fix the docs. Everything turns around code. The single largest cost among these is reading existing code.

There are numbers here. Glass writes that the dominant activity within maintenance is "understanding the existing product," taking roughly 30 percent of maintenance time (cited above). There is a measurement, too. A field study that logged 3,148 working hours from 78 professional developers found that about 60 percent of that time went to comprehending code — and the less experienced the developer, the higher the share (Xin Xia et al., "Measuring Program Comprehension: A Large-Scale Field Study with Professionals," IEEE Transactions on Software Engineering, 2018).

Decoding a predecessor's intent along with their code is work that no amount of time fully recovers. Being unable to touch the legacy is what forced whole systems to be kept alive well past their time, because most of the cost of rewriting was the cost of reading.

Why does everything turn around code in the first place? Because the design document could not keep up with reality. The customer cannot put every fine-grained request into words for the SIer. They only realize "this should be like that" once they see something running. And the SIer, for whom updating the design document on every change is a chore, fixes the code rather than the document. So the design document is left un-updated, and the only artifact that keeps up with reality is the code. The common sense that reading the code is the primary source was born right here.

And this common sense breeds vibe coding. If code is the primary source, the mindset becomes: as long as you can write code, you are done. If it runs, if it produces output, it counts. But that is meaningless. Code with no design, no spec, and no context behind it leaves no one able to say what it does or why, even when it runs. Not the author, not the next reader. What piles up is a heap of code no one can read, fix, or trust. Being able to write code is, in itself, worth almost nothing.

Because AI understands context, maintaining at the code level stops being necessary

Here is where 1-01's point bites. The core of design is understanding context, and AI has reached it. AI can read the context of a whole system: its structure, its intent, and its history.

And the context it understands, AI can render into two forms. One is a manual for humans, covering how to use and operate the system. The other is a design document for machines, covering the structure and the spec. That document is what AI itself reads to generate code. The design document that humans, finding it tedious, stopped updating and let die is now written and kept by AI, from the context. Humans read the manual. The machine, the AI, reads the design document and generates and regenerates the code.

Where does that design document live? If the unit of maintenance moves to context, then where the context is kept becomes the foundation of maintenance itself. The Independence part settles it: hold it as text, like a manuscript, and commit it to git (link:/en/ai-native-software/code/[2-06: Bring Code In-House] and link:/en/ai-native-software/documents/[2-07: Take Documents Back]). As text, humans and AI read the same thing, and the diffs and the history stay. A design document dies when it is kept somewhere that is not text and keeps no history.

From here follows one large consequence. *Anyone who can understand the manual and fit it to their own reality can do both development and maintenance.* There is no need to read code and no need to write it. There are no difficult decisions to make. You read the manual and fit it to your own reality, and that is all. A coding background stops being a prerequisite. 1-05 develops this point as "the customer builds it themselves."

The checking side is the same. Reviewing the design document and auditing the code for security are both within reach of Mythos/Fable-class AI. The ability to assemble the structure of an attack (1-01) is, flipped over, the ability to find and close the weaknesses. And that level exceeds the major SIers. There is no longer a reason to outsource review or security checks. The structure by which commissioning itself stops holding is taken up in the Shift part.

Design, spec, and context become the first spec you hand to an AI

If the unit of maintenance moves to design, spec, and context, then what you have to write is settled too. What you use, and what you do not. Where it goes, and how much of it you hold yourself. Where borrowing begins. Hold those decisions as text. That is the first spec you hand to an AI.

What you hand over is not code. The AI already knows how to write code. What it does not know is what this company chose, and what it chose against. That part, and only that part, stays on the human side.

The Independence part of this series is written in that shape. Each chapter is a list of decisions, not a demonstration of steps. Hand a chapter to an AI as it is and the work can start. Maintenance returns to the same chapter: when a decision changes, you change the decision rather than the code, and have the AI rebuild.

Summary

Maintaining at the code level stops being necessary, and maintenance can be done on-site, by the field itself. The unit of maintenance has moved from code to design, spec, and context. The single largest cost, reading legacy code, evaporates.

This change presses two questions. For the individual: what happens to the role whose center is writing code itself, the coder? For the organization: is the SIer, which took on development, still needed?

The next chapter takes up the former, the coder role itself. The latter, the SIer becoming unnecessary, is taken up in the Shift part.

Related articles

• 1-01: AI Solves the World's Hardest Coding Problems
• 1-03: AI Now Does the Software Engineer's Work
• 1-04: The Builder Role
• 2-04: Write the Logic — Own Your Tools with Python and Flet
• Structural analysis 08: Subtracting the enterprise-IT tax