The Hidden Axiom

I want to come back to the canonical image from the first chapter, because the argument of this chapter lives inside it.

You have already seen the three rows. The top row is waterfall: a wheel alone, then a wheel joined to an axle, then a chassis laid on top of the axle, then, at last, a finished sedan. Nothing between the first frame and the last is a car; the row is a story about assembly, not about progress. The middle row is agile: a skateboard, then a scooter, then a bicycle, then a motorbike, then the same sedan at the end. Everything along the middle row is usable. Each frame performs, at its own scale, the job the final frame performs at a larger one. The third row, which is the subject of this book, begins with a vehicle that is already driveable (an overbuilt prototype with a driver in the seat) and then removes things, frame by frame, until what is left is again the sedan. The top row assembles. The middle row iterates. The bottom row subtracts.

That is the left-to-right reading, and most people stop there. Each row is a methodology in motion; you follow the arrow from the first frame to the last and you see one way of getting from nothing to a working car.

The second reading is top-to-bottom, and it is the reading this chapter turns on.

Read those rows as a single column and they map onto the last forty years of software practice. Waterfall is the 1970s, 1980s and the long tail of the 1990s. Agile is everyone who came of age in the Manifesto’s wake, roughly 2001 onwards. Subtraction is the last two years: a model that arrived without a manifesto, as a set of tools placed in non-engineers’ hands. The column tracks which method the industry has believed in, decade by decade.

Now look at what the rows have in common, and what separates the last from the first two.

Both waterfall and agile begin with nothing. The top-row car starts with a wheel, which is not a vehicle; the middle-row car starts with a skateboard, which is a vehicle but one the team has to build from parts. In both rows the first frame is something the team has to construct before anything is visible to the customer. The bottom row begins differently. The first frame is already a working, running, ugly vehicle, and the team did not build it. The founder did, on a laptop, over a weekend.

Both of the old methodologies believed, in the unspoken way that methodologies believe the things they never have to defend, that building was the slow step.

Waterfall protected the build by planning it in meticulous detail before any code was written; the long discovery cycle, the signed specification, the sign-off meeting were devices to make sure that when the build finally happened, it happened once and correctly. Agile protected the build by slicing it into fortnights and sequencing it, so that no single stretch of construction drifted out of touch with what was wanted; the standups, the retros, the points were devices to manage a build that was still the heavy part of the work even when split into pieces. The methods differed on how to protect the build. They agreed entirely that the build was the thing requiring protection.

In 2015 I was running a Sliday engagement for a founder I will call Nadia — a composite of engagements from that period, with the details adjusted to anonymise everyone in them — who was a product director at a mid-sized financial-services firm in the Northern Hemisphere. She had a well-defined idea for a client-onboarding application for one of the firm’s specialist divisions. She had done her homework. She arrived with a deck of roughly forty slides, three interviews with internal stakeholders, a reasonable flow diagram and a budget. The work, as we wrote it into the statement of work, was three months of scoping and design before a line of production code was cut: two business analysts, a UX designer, a part-time developer for feasibility checks, a fortnightly client workshop, an interim prototype built in Balsamiq, user testing with six members of the operations team and a final signed specification running to eighty-four pages. The document had been reviewed by the firm’s head of risk before it left Nadia’s organisation. The figure on the statement of work was thirty-two thousand dollars, and we considered it fair because it was fair. The three months were what it took to derive a specification Nadia could sign. We did not write a line of shippable code until month four.

The thirty-two thousand dollars bought no software. It bought the specification for software. Under the hood, at the root of the contract, was the assumption that the specification was the precious artefact, because from specification to working code was another several months and more money again, and you did not want to be wrong about what you were asking the developers to build. You wanted to be sure. Sureness cost three months and thirty-two thousand dollars, and sureness was the product of the scoping phase.

Now set that against a conversation I had in February of this year.

The difference is physical before it is anything else. A decade after Nadia, a founder I will call Aneesh — also a composite, three or four founders of 2025 and 2026 compressed into one person — sent me his version of the same brief. Where Nadia’s engagement had taken three months to produce a bound specification, his arrived as a GitHub URL in an email without a subject line. That specification had sat on my desk like a small book I could weigh in my hand. Aneesh’s was clickable. One was heavy; the other weighed nothing.

He had sent it on a Monday morning with the note this is the thing I would like you to make actually work, built over the preceding forty-eight hours using Claude Code, a $10 top-up of API credits and a public template he had forked. The repository compiled, ran, served a landing page, took form input, wrote to a Postgres instance and pushed notifications to a Slack channel of his choice. It had approximately six of the ten features the final product would need; two of those six were broken on edge cases neither of us had noticed yet; and the UI was a set of Tailwind defaults tuned by someone who had never designed a form in his life. None of that matters. What matters is that the specification was the repository. There was no eighty-four-page document to sign. There was no Balsamiq mockup to revise. There was a working thing, and what Sliday had to do from there was decide what to keep, what to harden and what to throw away.

The cost column tells the story more plainly than any sentence I can write. In 2015, three months and thirty-two thousand dollars did not get Nadia to a working prototype at all. It got her to a document describing one. In 2026 the same gap cost Aneesh a weekend and ten dollars of credits; the other ten he spent on pizza. Nothing in the craft of scoping has become faster by a factor of a thousand. A tool has arrived that collapses the gap the scoping was there to cross.

This should have been good news for the methodologies, and for a while we wrote as though it would be. Put the new tools inside the old process, the reasoning went, and the old process would run faster. Waterfall with AI inside it would be faster waterfall. Agile with AI inside it would be faster agile. More throughput. More stability. All the standard metrics would move up and to the right.

They have not.

The 2024 DORA report, a survey of nearly three thousand professionals, is the industry’s longest-running empirical study of software delivery performance.¹ Its authors modelled AI adoption against their headline outcomes and found something nobody had been looking for. For each twenty-five per cent rise in adoption, the model showed delivery stability down seven point two per cent and throughput down one point five per cent. Higher reported adoption sat alongside slightly less frequent shipping and more instability. An association across a survey population, which is a weaker thing than a measured effect on any one team, and still not the direction anybody expected. In the 2025 edition of the same report, the authors wrote that AI amplifies a team’s existing practice rather than replacing it; a team with weak practice that adopts the new tools gets a weaker output, not a stronger one.² In that edition, nearly ninety per cent of surveyed professionals said they used AI tools at work. The amplification now applies to almost everybody.

The polite reading of that finding is that AI did not meet expectations. The less polite reading, which is the one this chapter argues for, is that the methodologies into which AI was inserted were built for a regime that no longer exists. Waterfall was rational when merely getting to a signed specification cost three months and thirty-two thousand dollars, and the build came after that; its rituals were there to protect the build. Agile was rational when the build cost two-week cycles and a team of four; its rituals were there to protect the build. Both were optimised around the same hidden axiom. When the build stops being the expensive thing (when, as in Aneesh’s case, the build is a weekend of a founder’s evenings and a $10 API top-up) the rituals no longer protect a valuable thing. They pile overhead on a thing that has become cheap, and they ignore the part of the work that is now genuinely hard.

The part of the work that is now genuinely hard is the part the old methodologies did not need a word for: deciding what to keep.

A founder who arrives with a weekend prototype has, in effect, delivered the artefact that used to take three months and thirty-two thousand dollars to produce. They have also delivered, attached to it, three things that now have to be handled: a set of features they were excited by at midnight on Saturday and which will not survive contact with a user; a handful of architectural choices the model suggested and that they had no reason to question; a set of assumptions about how production systems behave that are simply false. Somebody has to read that repository and cut from it. Nobody in either of the old methodologies was ever trained to cut. Neither had a vocabulary for removing code that was already working.

‘Harden’ is a specific, unglamorous list (input validation, auth, secrets, rate-limiting and the further items From Builders to Hardeners takes in detail; we are naming the gesture here rather than running the list, so that ‘harden’ is a thing a contract can be measured against). ‘Cut’ is equally concrete: opening the repository on Monday, deciding which three of twenty screens survive, and telling the founder which seventeen do not without bruising the weekend’s investment those screens represent. The Discipline of Subtraction is where the discipline is taught.

The methodologies did not disappear. They are still running, in large studios and enterprise IT departments, with AI tools bolted onto their sides. The methodologies are not wrong about the old world. They are simply not the map for this one: the compiler got cheaper, and the methodologies did not notice.

The bottleneck moved while the methodologies stood still.