I ended this essay with a pattern rather than a prediction. Someone raises the level of abstraction so that more people can build more things with less ceremony. The people who mastered the older, lower level object that the new level hides too much and understands too little. The new level turns out to be useful anyway, its rough edges get sanded down over a few years, and it becomes the unremarkable ground that the next generation stands on. Then someone proposes to raise the floor again.

I am watching the floor rise now, in my own career, and this time the pattern has a wrinkle I did not fully sit with before. Every earlier layer still expected a programmer to write the layer above it. FORTRAN expected formulas. C expected C. The compiler translated what a person had already composed. The layer arriving now inverts that. The artifact a person hands down is a description in something close to English, and the thing standing on that description and turning it into running behavior is not a junior engineer but a machine that read a great deal of code and can write more.

That wrinkle changes the question. For seventy years the interesting argument was about capability. Could the higher level be made fast enough, expressive enough, trustworthy enough to use? That argument is mostly settled in the new layer’s favor, the same way it settled for every layer before it. The argument I care about now is not what we can build. It is what we owe the foundation we are pouring, because for the first time the foundation is made of the one thing engineers have always treated as optional: the words around the code.

The Spec Becomes the Program

The clearest sign of the shift is that the specification is turning back into the primary artifact. A recent survey of the practice calls this spec-driven development, and it inverts the usual order by treating the specification as the source of truth and the code as a generated or verified secondary artifact (From Code to Contract). The same paper puts the reason plainly. Language models are excellent at pattern completion and poor at mind reading, so a loose request like “add photo sharing to my app” forces the model to invent a dozen unstated decisions about formats, permissions, and limits, most of them silently wrong.

This is not a new idea so much as an old one finally made literal. In 2008, in the first chapter of Clean Code, Robert C. Martin answered the people who thought code was about to disappear. Specifying requirements in such detail that a machine can execute them, he wrote, is programming, and such a specification is code (Beyond Code-Centric). He meant it as a refutation. It reads now as a description. When you write a precise enough account of what a system should do, you have written the program, whatever language the account happens to be in.

The tools have taken the point seriously. Amazon’s Kiro, to pick one example, turns a prompt into requirements, a design, and a sequence of tasks before it writes anything, then checks the result against the stated intent (Kiro). The practice has even grown a vocabulary of rigor. One useful framing describes three levels: spec-first, where the specification launches the work and then is discarded once code exists; spec-anchored, where the specification is maintained alongside the code for the life of the system and tests enforce their agreement; and spec-as-source, where humans edit only the specification and machines generate everything below it (From Code to Contract). The middle option is the one most production teams should want, and it is worth noticing why. It keeps a human answerable for the durable description while letting the machine handle the translation.

Writing for Readers Who Are Not Human

The specification is only the most visible part of a larger change. We are starting to write a whole category of documents whose primary reader is a machine.

Consider AGENTS.md, a plain Markdown file placed at the root of a repository to tell coding agents how the project is built, tested, and conventionally styled. It is deliberately not the README, which stays aimed at human contributors. It is a separate, agent-facing account of the same project, and by its own count it has been adopted by more than forty thousand open-source projects, with support from the coding agents shipped by OpenAI, Google, and others (AGENTS.md). Consider llms.txt, proposed by Jeremy Howard in 2024, a curated Markdown file that gives a language model a concise, expert-level map of a website because a model’s context window cannot hold the whole thing (llms.txt). Both are small conventions. Both point the same direction. The documentation is no longer a courtesy extended to the next human. It is load-bearing input to the thing that does the work.

Larger organizations are formalizing this. Cloudflare recently described a governed body of engineering standards it calls the Codex, which its AI agents consume across the development lifecycle, turning what used to be passive documentation into an actively enforced control system (Cloudflare). Read that against the arc of “The Long Climb of Abstraction.” Grace Hopper wanted managers to be able to read business logic in near-English sentences. Seventy years later a company is writing its engineering standards in near-English sentences so that a machine will read and enforce them. The craft is moving from the code into the prose that surrounds it, and the prose is starting to run.

What We Owe the Foundation

Here is where the wrinkle stops being interesting and starts being an obligation. If the words are load-bearing, then the quality of the words is a safety property, and the people who write them are back in familiar professional territory whether they think of themselves as engineers or not.

The two codes of ethics my field already has were written for exactly this moment, even though they predate it. The ACM Code of Ethics asks practitioners to contribute to human well-being, to avoid harm, to give comprehensive and thorough evaluations of systems and their risks, and to design systems that are robustly and usably secure (ACM Code of Ethics). The Software Engineering Code, maintained jointly by the ACM and the IEEE Computer Society, opens with the principle that engineers act consistently with the public interest, and holds that professional judgment must not bend to commercial pressure. Those documents assign duties to a person, not to a tool. The duties do not lapse because the person’s hands left the keyboard. Three of them press hardest right now.

The first is the Product duty: the work must meet a real standard of quality and security. The evidence that this is not automatic is already in. A 2026 benchmark built to test whether models can generate correct and secure backend code found that sixty-two percent of the best model’s solutions were either incorrect or insecure, and that roughly half of the solutions that were functionally correct were still insecure (BaxBench). A system can pass its tests and still be unsafe, which is precisely the failure a comprehensive evaluation is supposed to catch. The obligation is not to distrust the machine’s output on principle. It is to keep a real evaluation in the loop, and to write specifications that state the security properties out loud rather than hoping the model infers them.

The second is the Judgment duty, and it is quieter and more corrosive to ignore. Automation has a well-documented effect on the people who supervise it. In a review of dozens of studies across aviation and medicine, Parasuraman and Manzey described automation bias, the tendency to accept an automated system’s output without enough scrutiny, and the complacency that grows as most of its outputs turn out fine (Parasuraman and Manzey, 2010). Software is now living the same experiment. A 2026 developer survey found that ninety-six percent of developers do not fully trust AI-generated code, yet only forty-eight percent always verify it before committing, even as that code climbs toward a majority of what gets shipped (Tianpan, 2026). The gap between what we say we will check and what we actually check is the whole risk. Judgment is not a fixed trait. It is a muscle, and a muscle that reviews plausible output all day without ever building anything from first principles is a muscle quietly going slack.

The third is the Public duty, which shows up as a question about access, and it has two faces that are easy to confuse. The barrier to building something has never been lower. A person with domain knowledge and no formal training can now describe a working tool and watch it appear, which is the same democratizing promise Hopper made for COBOL and Kay made for Smalltalk. But the barrier to entering the profession may be rising at the same time. The routine implementation work that used to be a junior engineer’s apprenticeship is exactly the work being automated first, and early reporting describes a measurable contraction in entry-level developer opportunities and open worry from industry leaders about the drag this puts on early-career engineers (The Register, 2026). If the apprenticeship path closes, we have a supply problem that no model solves. The reviewers who keep the Product and Judgment duties alive are grown, over years, from the juniors we are now tempted to skip hiring. A profession that stops training its next generation of skeptics is spending a foundation it did not pour.

The Floor Is Still Curing

None of this is settled, and I want to resist the pull to pretend it is. The people building the practice are still arguing about basic questions. A recent O’Reilly piece warns that a specification can quietly become a second codebase, a pile of Markdown as tangled and unmaintained as the code it was supposed to replace, and argues for small change briefs and native engineering artifacts instead of ever-growing prose (O’Reilly Radar, 2026). That is the sound of a layer whose rough edges have not been sanded down yet. Every layer sounded like this once. FORTRAN’s overhead was a scandal until Backus proved it was cheap. Structured programming was a fight before it was a default.

The difference this time, the one I named in the earlier essay, is that the new layer is probabilistic rather than deterministic, so it can be confidently wrong and wrong in a different way tomorrow. That is not a reason to stay off the new floor. It is the reason the human duties matter more here, not less. A deterministic tool lets you learn its failures once. A probabilistic one asks you to keep watching.

Grace Hopper spent her career fighting the sentence “we’ve always done it this way,” and she would recognize the new tools least of all the ones carrying her argument forward. But she would recognize the obligation exactly. She did not just build the compiler. She wrote the manuals, ran the training, and spent years convincing people to trust automatic programming responsibly rather than blindly. The floor she poured held because she treated the words around the machine as part of the machine. That is the whole job now. We are higher up the slope than we have ever been, the foundation under us is still curing, and the most useful thing an engineer of my generation can do is make sure it sets true before the next generation stands on it without a second thought.

References