Chapter 8: Prose Is Not Content; Code Is Not an Asset
AI Did Not Create the Problem
There is a very popular narrative: AI has changed everything. Jobs will disappear, skills will become obsolete, humans must redefine themselves.
The direction of this narrative is not wrong, but it has the causality reversed.
AI did not create new problems. What it did is simpler, and more brutal — it took a pile of problems that had long existed but were always concealed, and spread them all out under the sunlight at once.
Prose has never equalled content. Code has never equalled systems thinking. Credentials have never equalled competence. Large systems have never been stable. These were true before AI appeared; it was just that because production costs were high and barriers were high, no one was ever forced to face them.
What AI did was drive production costs down to near zero.
When anyone can generate a grammatically correct, structurally complete passage of text in seconds, "being able to write" is no longer a scarce capability. When anyone can use AI to build a functional system in a few days, "being able to code" is no longer a source of differentiation. When anyone can use agents to automate an entire workflow, "being able to operate tools" is no longer a competitive advantage.
What remains is a naked question: once you strip away these media, what do you actually have in hand?
Chapter 7 shone its light on education — how anxiety is packaged into a commodity, how credentials conceal the absence of cognition. This chapter shines its light on the individual: of the things you believed were your abilities, how many were actually just the threshold of the medium?
Prose Has Never Been Content
Previously, writing fluent prose was a gated skill. Producing exquisite visuals was too. Editing rhythmically paced video, even more so. These skills required years of training, talent, and the accumulation of experience. Because the barrier was high, we long equated "being able to write" with "having something to say," and "drawing well" with "having something to express."
Prose was content. Draftsmanship was the work. Technique was thought.
But prose has never been content. Draftsmanship has never been the work. Technique has never been thought.
They are carriers of intention — pathways through which consciousness finds an outlet. A person who writes well does not necessarily have something to say; but a person who has something to say will find a way to say it — through text, through images, through sound, through whatever medium is available.
AI shattered this long-standing illusion in one blow. When the cost of generating fluent text drops to zero, the gap between "being able to write" and "having something to say" can no longer be hidden.
At the two ends of this crack stand two kinds of people. Chapter 11 will spend more time dissecting them — a seasoned writer guarding the gate, a power user burning tokens — and a third possibility more worth noting. For now, remember one thing: prose is a medium, not content. AI has not stolen anyone's livelihood; it has simply made it impossible for anyone to hide behind the medium any longer.
Frameworks Killed Architectural Thinking — AI Only Shovelled the Last Scoop of Dirt
Chapter 7 described a distortion in education: the examination system trains problems that require judgement into problems solvable by memory, so engineers learn to operate, not to think.
The same distortion played out in another form in software engineering, twenty years ahead of schedule. And the culprit was not AI — it was frameworks.
Around 2004, frameworks like Rails, React, and Spring began to spread. What is a framework, fundamentally? A pre-packaged set of design judgements. Using React means accepting its decisions on state management. Using Rails means accepting its MVC architecture and its philosophy of convention over configuration. You do not need to know why it was designed that way; you just need to follow.
What frameworks sell is: "You can produce something without needing a holistic view."
From that moment, "understanding the fundamentals" was demoted from an entry requirement to a senior bonus. Most developers no longer needed to make architectural decisions, because the framework had made them for them. They became operators of the framework — highly proficient, but the moment the framework updated or the technology pivoted, their experience reset to zero. They learned to operate, not to think. The educational distortion described in Chapter 7 played out twenty years earlier in software engineering, in the form of frameworks.
AI delivered the second blow. In the framework era, you at least still needed to judge "which framework to use," "how to connect frameworks," and "when not to use a framework." In the AI era, even this layer of judgement can be outsourced to an agent. You say two sentences to an agent and get runnable code; you never even have the chance to experience the deep understanding that comes from "why did it break."
Lay this timeline out, and you see a complete history of abstraction: compilers eliminated the need to write assembly language. Garbage collection eliminated the need to manage memory. Frameworks eliminated the need to do architectural design. AI eliminates the need to write code. Each round of abstraction is an outsourcing of holistic understanding. AI is not an anomaly; it is merely the latest node on this line.
But here is a cruel question: AI removed the pain, but pain was once the vehicle of education.
How did engineers of the past develop holistic understanding? By debugging until dawn, by breaking the system themselves and fixing it, by being tormented by legacy code, by watching a bad design decision explode three years later. All of these were friction. And what AI excels at is eliminating friction.
The result is a structural fault line: those with judgement grew up in an environment without AI — they went through that painful tempering. The next generation, growing up with AI, skips that tempering entirely. People with judgement will become fewer and fewer, yet market demand for judgement — because output volume has exploded and someone needs to judge quality and direction — is rising.
AI did not kill architectural thinking. Architectural thinking died at the hands of frameworks, and has been dead for over a decade. AI only shovelled the last scoop of dirt on the corpse, and only then did everyone notice the grave had been there for a long time.
Large Systems Will Not Die, but They Will Become Prisons
If frameworks killed the individual engineer's holistic understanding, then the acceleration of technological iteration is changing the nature of something else: large systems.
Previously, building a large system was worth doing. ERPs, CRMs, enterprise back-ends — these things had lifespans of five, ten, twenty years. Build costs were high, but maintenance costs were relatively low, and the systems became more stable with use. Enterprises were willing to spend heavily to build and maintain them, because the investment payback horizon was long enough.
Today, the pace of technological iteration has accelerated to the point of changing this equation. Models turn over every six months. Frameworks every year. Cloud platforms update APIs every quarter. You have not finished reading the last version's documentation before the next is released. Systems are not depreciating — they are evaporating — the same structure as the knowledge evaporation described in Chapter 7.
But large systems will not disappear because of this. Enterprises still need them. A bank's core transaction system cannot be assembled from microservices; a hospital's electronic health records cannot be rewritten every six months; a factory's MES cannot go offline because a cloud API was revised. Large systems will continue to exist, only their nature has changed — from an asset, they are gradually becoming an increasingly expensive prison. You cannot leave it, but maintaining it costs ever more; you want to replace it, but the risk and cost of replacement exceed those of maintenance.
"Increasingly expensive" is not rhetoric. Industry benchmarks from Gartner, Forrester, and Deloitte consistently indicate that legacy system maintenance accounts for 60–80% of enterprise IT total expenditure, leaving only 20–40% for innovation and new feature development. The US Government Accountability Office (GAO) 2025 report quantified an extreme case: of the federal government's annual IT budget exceeding $105 billion, 79% was allocated to operations and maintenance. And by 2026, maintenance costs are climbing at 18–25% per year — senior developers who understand legacy systems are retiring, and what they take with them is not syntax knowledge, which can be documented; they take decades of business judgement compressed into intuition — which corner cases will explode during month-end settlement, which field formats conceal a regulatory requirement from fifteen years ago, which seemingly redundant logic is actually stopping a bullet only they have ever seen. 70% of organisations still struggle to find multi-skilled mainframe talent (Kyndryl / BMC, 2025). The pressure of security-vulnerability patching mounts, and the interest on technical debt never stops accruing. This is not a metaphor for a prison. This is the prison's bill.
The prison bill is not even the cruelest part. The cruelest part: you cannot even use AI to escape.
Approximately 220 billion lines of COBOL remain in operation globally. It handles 95% of ATM transactions, 80% of in-person credit card transactions, and clears over $3 trillion daily. 43% of banking systems are built on COBOL (World Economic Forum; Open Mainframe Project, 2025). This is not a marginal issue — it is the baseplate of financial infrastructure.
Enterprises, of course, want to escape. AI-driven migration tools are being deployed at scale to address this, claiming extremely high business-logic preservation rates and 60–90% cost reductions. The quality of syntactic translation is indeed remarkable — AI-generated Java code is nearly always syntactically correct, structurally complete, and compilable. Then it crashes repeatedly during user-acceptance testing.
Where does it crash? On things AI cannot see.
A variable called TRN-LIMIT — not defined in the source file being translated, but buried in a COPYBOOK thousands of lines earlier in the execution chain — contains a REDEFINES clause. This is a COBOL construct: the same memory address, depending on a flag set in a completely different module, is interpreted as two different data types. AI treated it as an ordinary numeric field. The result: the Java application wrote corrupted binary data into a database field. The code compiled. The test environment ran. The data silently corrupted where no one was watching.
This is not an isolated case. Gartner noted that of mainframe exit projects initiated in 2026, over 70% are expected to fail to achieve their intended benefits — and the failure causes are almost entirely structural: hidden dependencies, shared memory mappings, mainframe-specific integration layers (CICS, Db2) — not syntax errors. The quality of translation was never the bottleneck. Code that compiles is the easy part. The hard part is the code the tool cannot see — compressed into COPYBOOKs, scattered across the execution chain, known only to people who have used the system for twenty years. AI translates syntax. But the real value of a COBOL system is not in its syntax. It is in decades of accumulated business judgement, in corner cases that were never documented. AI can perfectly translate what it can see, but what it cannot see is what the system is actually doing.
You are not merely unable to leave the old system. You cannot even use AI to escape — because AI translates code, not judgement.
This prison effect is being experienced across the industry. Some have tried to break free — over a decade ago, "microservices" were promoted as the cure, splitting large systems into dozens or hundreds of independent small services, each developed and deployed separately. It sounded beautiful. But in practice, most enterprises discovered that managing hundreds of microservices (service mesh, distributed transactions, observability, version compatibility) was even more painful than the original large system.
Numbers speak more clearly than metaphors. A 2025 CNCF (Cloud Native Computing Foundation) survey found that 42% of organisations that adopted microservices are consolidating services back into larger deployment units — citing debugging complexity, operational overhead, and network latency. Gartner's figures are bleaker: 60% of teams regret using microservices in small-to-medium applications; monolithic architectures save an average of 25% in costs. Even Amazon — the company that essentially invented modern cloud architecture — rolled its Amazon Prime Video monitoring service back from microservices to a monolith, reducing infrastructure costs by 90%. Segment rolled back from over 150 microservices to a single application. Service mesh adoption rates dropped from 18% to 8%. Microservices as a universal cure for enterprise architecture have essentially failed. Many companies are quietly retracing their steps — not because monoliths are trendier, but because the complexity tax of microservices costs more than the problems they solve.
So is the problem unsolvable?
One case provides a different angle of observation, but the reason it works is precisely because the conditions are extremely specific — what is worth dissecting is not the method, but the premises.
A few years ago, someone built a work system linking multiple small programmes together. He had originally considered building a large system — unified architecture, centralised management, one system to rule them all. But the revision speed of cloud platforms forced him to reassess that judgement. Google's GCP and Firebase kept updating APIs; he had to keep chasing documentation updates, keep feeding them to AI, keep adjusting. The effort spent keeping up was routinely nine or ten times the actual development effort. He thought he was maintaining a system; in reality, the cloud platform was leading him by the nose.
It was precisely this experience that led him to make a deliberate architectural decision: divide and conquer. Stop building large systems; instead, make every tool small enough to rewrite with AI at any time, small enough that if it expires, there is nothing to mourn. Later the master system expired, and he did not rebuild it — not because he could not, but because he had already judged it was not worth it. Those small programmes did not need a huge master system to coordinate them.
But the reason this works is two very specific premises: he is a single person, with no need for cross-team collaboration; and his workflow does not require a unified central system. In a ten-person team scenario requiring shared state and consistency guarantees, this approach simply does not work. Enterprises need large systems not because they are foolish, but because the collaboration complexity they face is completely different from that of one person.
So the real insight is not "small is better than big" — that proposition holds only under extremely specific conditions. The real insight is: when build costs approach zero because of AI, what is the real asset?
The answer is not code. Code expires. Not frameworks. Frameworks update. Not platforms. Platforms get revised.
The real asset is the judgement of knowing "what the system should look like." It is the ability, when facing infinitely many possible architectures, to know which one suits the current constraints, which one will hit a wall in three months, which one sacrifices what in exchange for what.
AI can generate ten architectural options in an hour. But who decides which one to pick?
This brings us back to the cognitive fault line described in Chapter 7. The person capable of making this judgement — their ability is not in any piece of code, not in any framework, not on any certificate. It is in their cognitive model — a system of trade-offs compressed from years of experience. This system is extraordinarily valuable, but in the language of résumés, KPIs, and training systems, it remains invisible.
What Is Exposed Is Not Weakness — It Is Truth
Place these things side by side, and a common pattern emerges.
AI exposed the truth about writing: prose is not content; consciousness is. AI exposed the truth about programming: operation is not competence; architectural thinking is — and architectural thinking was already declining before AI. AI exposed the truth about systems engineering: code is not an asset; the judgement of knowing what to build and what not to build is. AI exposed the truth about education: credentials are not cognition; judgement is.
In every domain, AI does the same thing: it drives production costs to zero, then forces everyone to face a fact that had long been concealed by high production costs — what is truly valuable has never been at the production layer.
Previously, you could hide behind "I can write," "I can draw," "I can code," "I have a certificate," because the scarcity of these skills alone was enough to sustain you. Now these shields have been removed, and the person standing behind them — whether they have something to say, whether they have judgement, whether they have cognitive depth — is fully exposed.
This is not a crisis. This is a demon-revealing mirror.
And what the mirror reveals is not only the substance and void of individuals. Every problem discussed above — the hollowness hiding behind prose, the operators hiding inside frameworks, the teams locked inside large systems — they do not happen in a vacuum. They happen inside companies. Inside meeting rooms. On performance review sheets and org charts.
The covers over individuals have been lifted by AI. But the covers over corporations — things that have operated for decades on discourse power, definitional authority, titles, and processes — lifting those requires not a better tool, but a larger mirror.
AI exposed the substance and void of individuals. But when the same mirror shines into the corporation, what it reveals is even harder to look at.