Essay: The Coming Code Apocalypse

In December 2025, Amazon’s own agentic coding tool — an integrated development environment (IDE) called Kiro — was given access to make changes to live systems. It decided, on its own initiative, to delete and recreate parts of its environment. The result was a thirteen-hour outage affecting cost explorer in AWS’ China region. According to news sources, three months later, in March 2026, Amazon Senior Vice President Dave Treadwell convened an urgent internal engineering meeting after a pattern of incidents was internally attributed to “GenAI-assisted changes” — described in internal documents as carrying a “high blast radius.” He mandated that senior engineers review all AI-assisted code produced by junior staff. Amazon’s own internal memos acknowledge that best practices and safeguards for generative AI in production simply haven’t been established yet.

The company that provides the infrastructure backbone for much of the internet is learning this lesson in real time. This is the future James Somers warned us about, nine years early.

In September 2017, The Atlantic published “The Coming Software Apocalypse” by James Somers. In it, Somers detailed the staggering volume of critical systems built on old, brittle code and illustrated his argument with examples that, when I first read the piece, gave me the shivers. What Somers described was a complexity crisis that had already outrun our ability to manage it. What has happened since is that we have bolted a force-multiplier onto that same unmanaged complexity and called it progress.

For years, one of the most terrifying words an IT professional could hear were: “I built an Access database tool connected to the [fill-in-the-blank] system.” These tools were often clever solutions created by clever people — but they had no documentation, no best practices, and no succession plan. When I worked as a CTO for a managed services provider, one of our most common engagements involved businesses whose entire operational model depended on an Access database or a series of Excel spreadsheets running on a Windows OS that had long since lost support. The person who built it was gone. The documentation didn’t exist. And the cost of maintaining something you can’t read is nothing compared to the cost of replacing something you can’t lose.

Now a new wave of euphoria has arrived. LLMs are leading on code, and with them come proclamations that developers are obsolete. In February 2024, NVIDIA CEO Jensen Huang told an audience in Dubai that anyone hoping for a career in technology shouldn’t bother learning programming. By June 2025, Huang was back at London Tech Week with a new eulogy: “There’s a new programming language. It is called ‘human.’” The movement even has a name: vibe coding — the practice of prompting your way to a working application without understanding what’s running underneath it.

Now here’s where Huang’s logic falls apart.

If you accept Huang’s premise — that AI will write the code, so don’t bother learning to code — then you must also accept the corollary: don’t bother learning to write. LLMs can write. They can draft your emails, your reports, your legal briefs, your marketing copy. So by Huang’s reasoning, there’s no longer any need to study English composition, rhetoric, or grammar — or for that matter any language at all.

But a lawyer who can’t read a contract doesn’t become a better advocate because an AI drafted it — they become dangerous. A doctor who can’t articulate a diagnosis doesn’t become competent because a model generated the notes — they become a liability. A developer who doesn’t understand what they’re building doesn’t become an engineer because an AI wrote the code — they become a risk.

This is the same failure mode I watched unfold for years in the “learn to code” wave — the nonprofits, the government workforce programs, the bootcamps promising to turn a six-week student into a developer. I am all for broadening access to technology, and I have mentored plenty of people who came into the field through nontraditional paths and became excellent engineers. But teaching someone to “code” without any of the underlying foundation — discrete math, logic, data structures, how a computer executes an instruction — is like teaching someone how to turn a stove up to high and expecting them to produce a five-course Michelin-grade meal. They learned how to operate the appliance. They did not learn how to cook. And when the stakes are larger than a side project, the gaps become obvious — to everyone except the people who had been told the gap didn’t exist.

Vibe coding will industrialize the same mistake, unless we are honest about what it is and what it isn’t. To be clear: I think AI-assisted coding is a major achievement that is and will have enormous, positive, impact for large and small businesses, nonprofits, and teams who need to move from an idea to a working prototype without a six-figure development budget. It lowers the cost of exploring an idea. It lets a founder validate a use case before hiring an engineering team. It lets an internal team build a tool that would otherwise never have been funded. That is real value, and it is not the thing I’m worried about. What I’m worried about is the leap from “I can vibe-code a prototype” to “I can vibe-code a production system that serves my members, my patients, my customers.” Those are not the same skills. And pretending otherwise is irresponsible.

The people getting the most out of large language models today are, without exception, those who think and communicate with precision. Good prompt engineering — simply put — is applied writing. It is clarity, logic, and specificity translated into instruction. A mediocre writer gives a mediocre prompt, gets a mediocre output, and calls it a platform. The quality of what you pull out of any AI is bounded by the quality of what you put in (0 x 0 = 0). You cannot delegate your way out of understanding. You can only amplify what you already have — which means if what you have is shallow, the AI just makes it louder.

Somers saw this coming from a direction most people missed. One of the quieter passages in his essay features Eric Bantégnie, founder of Esterel Technologies, describing the root cause of software unreliability, speaking about developers: “The people know how to code. The problem is what to code. Because most of the requirements are kind of natural language, ambiguous, and a requirement is never extremely precise, it’s often understood differently by the guy who’s supposed to code.”

Let that settle for a moment. The hard problem Somers identified was translating fuzzy human language into precise deterministic code. Humans were already bad at that. We have now taken the same humans — the ones who struggled to describe what they wanted — and asked them to feed their ambiguous natural language into a probabilistic system that produces plausible-sounding code. The front end is still ambiguous. The back end is now also ambiguous, statistical rather than deterministic, generated by a system that does not perform explicit symbolic reasoning (LLMs primarily compute probability distributions over tokens learned from their training data), does not plan, and does not know what it does not know. The middle has been automated into a black box. The failure mode Somers warned about has not been solved. It has been industrialized.

And this is where Leslie Lamport’s decade-old complaint becomes prophetic. Lamport — the Turing Award–winning computer scientist whose work underpins much of the modern web — spent years arguing that programmers were failing because they weren’t developing the mathematical precision required to manage the systems they were building. “In the 15th century,” he told Somers, “people used to build cathedrals without knowing calculus, and nowadays I don’t think you’d allow anyone to build a cathedral without knowing calculus. And I would hope that after some suitably long period of time, people won’t be allowed to write programs if they don’t understand these simple things.”

A decade later, we have handed those same programmers a tool whose output quality is almost entirely gated by precision of thought — and then told the next generation they didn’t need to learn any of it. Lamport was begging the field to develop the rigor required to think clearly about what software should do. The vibe-coding movement is the opposite answer: don’t think clearly, don’t think at all, just prompt and ship.

There is a deeper irony here worth noting. Somers’ essay spends most of its energy on proposed solutions — Bret Victor’s immediate-feedback environments, Esterel’s model-based code generation, Lamport’s TLA+. They all share a philosophy: force precision earlier in the process, then let the machine handle the code once the rules are unambiguous. Write the spec. Prove it correct. Then generate the code. Somers was championing a world in which the human got more rigorous and the machine got more reliable.

Vibe coding is the philosophical inverse. It lets the human defer precision indefinitely — describe what you want in whatever words come to mind, accept whatever code the model produces, and move on. One approach says be rigorous up front so the machine can be reliable downstream. The other says be loose up front and hope the machine is reliable downstream. Somers advocated for the first. I am warning about the second.