The Next Discipline

Ask whoever is planning next year’s engineering conference to title the track that covers everything the last eleven volumes of this Library have described — curating what a model sees, specifying intent instead of writing code line by line, building a harness around a model, coordinating several agents on one codebase, treating verification as the actual job, measuring all of it, and reorganizing a team around it — and watch the sentence run out of room before a title arrives. "AI engineering" means model training to half the room. "Agentic development" reads like a vendor’s slide. Most organizers land on something like "building software with AI" and move on, because no sharper name is sitting there waiting to be picked up.

This Library has the same gap, and the honest move in a closing volume is to name it rather than paper over it with a confident coinage. Eleven prior volumes have each described a real, accumulating body of practice — context engineering, intent architecture, the harness, workflow engineering, multi-agent development, verification and trust, systems thinking, engineering knowledge, measurement, team and organizational structure — without once proposing a single name for what all of it, together, now constitutes. That gap is not an oversight. There is a real historical reason to think it should stay open a while longer.

A discipline gets named after it exists

By October 1968, programming had already been a paid profession for roughly two decades, and large systems were already failing in expensive, well-documented ways. IBM’s OS/360, the operating system for its System/360 mainframe line, is estimated to have consumed on the order of five thousand engineer-years and tens of millions of dollars a year, plagued by schedule slips and defects that shipped anyway. The gap between what organizations were attempting and what their development methods could reliably deliver had a name in the trade press: the software crisis. NATO’s Science Committee convened a conference in Garmisch, West Germany, from October 7 to 11, 1968, to confront it directly, drawing software researchers and practitioners from across Europe and North America — Edsger Dijkstra and C.A.R. Hoare among them.

The conference organizers, led by Professor Friedrich (Fritz) Bauer, gave the gathering a title that had barely been used before: software engineering. The published report explained the choice directly — the phrase was, in the editors’ own words, "deliberately chosen as being provocative, in implying the need for software manufacture to be based on the types of theoretical foundations and practical disciplines that are traditional in the established branches of engineering." Edited by Peter Naur and Brian Randell for the NATO Science Committee, the report did not claim the discipline already existed in mature form. It named roughly fifteen years of accumulated, increasingly strained practice, then used that name to argue for what the practice still needed to become.

The naming was never as clean as the label implies

The 1968 conference popularized the term; it did not invent it from nothing. Anthony Oettinger, then president of the ACM, used it deliberately in his President’s Letter in the August 1966 issue of Communications of the ACM, urging members to recognize themselves as belonging to "an engineering profession, be it hardware engineering or software engineering." Independently, at MIT’s Instrumentation Laboratory, Margaret Hamilton had been calling her group the Software Engineering Division since the mid-1960s while directing the on-board flight software for Apollo — not because the field had settled on the phrase, but, as she later put it, because she "fought to bring the software legitimacy so that it — and those building it — would be given its due respect." By her own account, colleagues found the phrase amusing at the time, an ongoing joke about her radical ideas.

I fought to bring the software legitimacy so that it — and those building it — would be given its due respect.

Margaret Hamilton, on why she called her Apollo team the Software Engineering Division, years before NATO popularized the phrase

The same pattern, smaller and more recent

The pattern is not unique to 1968, and a smaller, more recent case makes the same point with less distance to squint through. By 2009, a handful of engineers had spent roughly two years comparing notes on treating deployment as a shared, continuous discipline rather than a wall between development and operations — Andrew Shafer and Patrick Debois had been trading ideas on it since 2008, sharpened by a widely watched 2009 talk on Flickr’s deploy practice. Debois needed a name for a conference he was organizing that October in Ghent, and settled on "DevOpsDays" mainly, by his own account, because "Agile System Administration" was too long. He was blunt about it afterward: "there never was a grand plan for DevOps as a word." The practice came first, by at least two years; the name arrived to fit a conference program.

The caution this Library already applied once, one level up

This Library made close to this same argument already, at a smaller scale. Volume XI’s chapter on new engineering roles examined "Agent Ops" — the emerging cluster of duties around monitoring and governing fleets of coding agents — and concluded the label was real enough to track but not yet settled enough to declare a stable job family, since most job postings using the term described selling agent infrastructure to other companies rather than the internal role that chapter was describing. Coining a discipline name here would repeat that exact mistake one level up: branding a body of practice on the strength of a publication deadline rather than settled, widespread use. Both the NATO and DevOps cases above suggest that gap runs years, sometimes closer to a decade, not months.

What is already sitting on the table, unclaimed

None of this means no candidate names exist. A few have already surfaced, informally, inside this Library’s own structure, without ever being proposed as the definitive name for the whole. Naming any of them now, with confidence, would repeat the premature move this chapter is arguing against — but laying them out plainly, with what each gets right and what it leaves unclaimed, is a more honest way to close than silence would be.

Each framing captures something real and leaves something out, which is itself the evidence that none has won yet. The 1968 report did not arrive at a NATO conference by accident of scheduling; it arrived after roughly fifteen years of programming practice had produced a crisis specific enough to argue about, with named projects and named overruns. DevOps arrived after Debois and Shafer had two concrete years of shared practice to compare. Whatever eventually gets called by whatever name settles on the practice this Library has spent eleven volumes describing will very probably need a comparable runway — measured against the industry’s own accumulating use of these tools, not against this book’s publication schedule.