Cows, Men, Paddocks
Part VI The Claim · Chapter 21

Sculpting

Opening illustration for Chapter 21: Sculpting

In February of this year, about fifty people drove up into the mountains to Deer Valley, Utah, sat in a room Martin Fowler had booked and spent two days talking about what software development is becoming.1 The location was not accidental. Twenty-five years earlier, seventeen people had met in the same mountains, at Snowbird, and walked out with the Agile Manifesto. The 2026 group included Kent Beck, who had been in the room the first time; it included Gene Kim, Laura Tacho and Steve Yegge, who had not; and it included, by all reports in the weeks afterwards, a polite and productive disagreement about almost every noun on the whiteboard. No successor manifesto was drafted. No four-line values statement. No twelve principles. The attendees went home, wrote summary posts, and the Pragmatic Engineer newsletter ran the most widely circulated account a few weeks later. The field that produced agile in a weekend did not produce its successor in two days.

That is the opening this chapter walks through.

Everyone at Deer Valley knew the old methodology had stopped describing what their teams were doing, and nobody had landed on the word for what the teams were doing instead. The gap between we know this is different and we have a name for it is the gap I want to spend this chapter in. We have been working inside the gap for two years at Sliday. We named it twice before landing on what we will now spend the remaining chapters calling by its proper name.

The name is Sculpting.

I want to defend the word, because the book lives inside it.

There are four candidate names that turned up repeatedly in our internal conversations between late 2024 and the end of 2025. The four were Subtractive Development, Prototype-First Development, Reverse Agile and Sculpting. Five criteria, arrived at by argument rather than by design: translatability (does the word survive being said in a second language), T-shirt-test (can a studio employee wear it to a conference without wincing), vendor-neutrality (is it free of any specific tool, company or model in 2026), metaphor-depth (does the word, when pulled on, produce more of itself) and, the criterion that mattered most in practice, what the founder says on the phone when she rings the studio on a Tuesday morning with a GitHub URL and wants to know what happens next.

Subtractive Development won on accuracy and lost on everything else. It describes the work — The Discipline of Subtraction walks it in detail — but reads like a procedure code on a hospital invoice. Soustractif in French and субтрактивный in Russian both sound like industrial machining. Subtraction stays in the book as the verb, not the name. Prototype-First Development is where we lived for about three months in 2025 and most nearly made a wrong decision. It is descriptive and survives translation, but it names the input to the method rather than the method itself. An architect who calls her practice blueprint-first architecture is telling you what arrives on the table, not what she does with it. Reverse Agile is useful shorthand in a conference bar. It defines itself by negation, which is a confession the author could not say what the work was, and it depends on agile remaining the shared reference point a decade from now. It will not.

Sculpting survives all five. I watched three founders pick it up on the same call in a single week in November and use it back to me unprompted before the end of the hour. One of them, a Melbourne founder building a fleet-maintenance tool, said, “so you’re sculpting it, basically.” We had not said the word yet in that call. She had read a Sliday blog post from a month earlier that used it once, in passing, and she had held it and produced it back in a context where the word did work. The founder who volunteers the word back to you has told you the word is correct. It survives translation — sculpter, esculpir, ваять, chōkoku-suru all mean roughly the same thing and carry the same craft connotation. It survives the T-shirt. It is vendor-neutral. And it pays compound interest as a metaphor, which the other three do not.

The metaphor is what the rest of this chapter has to earn.

The metaphor has four moving parts and each one carries weight.

The quarry is the founder. This is the first place the image does work the others cannot. A quarry is a place where raw material comes from, produced by geological processes over a long time, and released by careful labour. A founder has spent ten, fifteen, thirty years accumulating the frustration and the domain knowledge and the precise picture of what the product ought to be that produces the prototype. She did not write the prototype on a Saturday; she wrote the prototype on a Saturday after twenty years of noticing what was missing. The quarry produced the marble long before the sculptor arrived.

The marble is the prototype. The Mad-Max v2, the weekend build, the repository that arrived in our inbox on Monday morning with seventeen features and a README written by the model. Marble is not a finished object, but it is also not raw stone. It has been quarried, which means a great deal of work has already been done to bring it out of the ground and put it on a flatbed. A block of Carrara marble arriving at a sculptor’s studio in 1500 was the product of twenty quarrymen, a winch, a road and about six weeks. The prototype is that block. What the studio receives is not nothing (it is specifically not nothing, and the chapter on scoping-against-an-artefact was written to say exactly that) but it is also not the statue.

A sculpture studio with a rough block of marble on a plinth, chisel marks on one face; taped to the top is a small paper slip printed GIT REPOSITORY and a hash string, held down by a single vermillion pin.

The sculptor is the studio. The sculptor removes material. A sculptor’s working tools are a mallet, a chisel in several sizes, a rasp and, for the last few per cent, a cloth and a bucket of water. None of those tools add marble. The tool metaphor lines up with the working practice of Parts III and IV — the hardening checklist, the deletion sprint, the justification review — because those are tools of subtraction and finishing, not of generation. The studio’s labour in 2026 is closer to a sculptor’s than to a builder’s. That describes what the working week actually contains.

The same classical bust produced three ways: on the left, a hand placing the final LEGO-style brick on an assembled plastic-brick bust; in the middle, hands shaping a clay bust of the same figure on a potter's wheel; on the right, a chisel knocking a vermillion chip off an over-ornate marble sculpture to reveal the same classical bust inside. Same statue, three methods, opposite directions.

The statue is the shipped product, and this is the part of the metaphor that did the most work for us once we stopped resisting it. Michelangelo is supposed to have said, in a line every schoolchild in a European country has heard, that the statue was already inside the block and his job was to reveal it. The wording is almost certainly a later embellishment. But it carries the operative claim of this book better than any of the modern ones. The founder’s prototype already contains the product; the studio’s work is to let it out. This is a commercial fact about what the founder hands over on day one. The prototype contains too many features, but among the features it contains is the one the market will pay for. Nobody will add that feature later. It is already there. The work is to remove the ones that are not.

The metaphor pays rent in both directions. When the studio pushes back on a feature cut, the working question is would the sculptor have left that there. When a founder resists deletion, the working reframe is we are revealing, not removing. When an engineer argues for rewriting a module, the diagnostic is are we sculpting or are we re-quarrying. The vocabulary produces the questions; the questions produce the decisions; the decisions produce the ship date. A name that keeps producing working questions a year after you adopted it is a good name.

None of the other three candidates produced a second question.

A name that keeps producing working questions a year after you adopted it is a good name.

I should name the competitors. The field is not silent, and three serious proposals are already in circulation.

George Vettath, founder of the low-code platform vendor Stragiliti, proposed Generative Software Delivery (GSD) in a December 2025 post, After Agile, The Next Big Shift: Generative Software Delivery.2 The diagnostic of the post-agile condition is close to ours; the point of departure is the emphasis. GSD puts generation at the centre: what the model produces, what the founder produces, what the pipeline produces. Our observation in every engagement since 2024 has been the opposite — generation has stopped being scarce. A founder with a laptop on a Saturday now produces more code than the studio can usefully ship on the Monday. The defining operation of the new regime is selection, and GSD puts the spotlight on the wrong half of the week. It is a name for a different book.

Hassan and colleagues’ 2025 arXiv paper, Agentic Software Engineering: Foundational Pillars and a Research Roadmap, labels the coming era SE 3.0 and proposes Structured Agentic Software Engineering — SASE — as its programme, and goes further in the other direction.3 Their unit of analysis is the orchestration of agents: how teams of agents and the humans directing them coordinate to produce working software. It is careful academic work and will probably find its audience inside research groups and tooling vendors. For a founder on a phone on a Tuesday morning, the word agentic is a word she will ask you to define before the conversation can continue. SASE will not pass the T-shirt-test. More materially, it names the infrastructure, not the craft. A studio is not primarily an orchestrator of agents; it is a practice. The word has to describe the practice first.

The P3 Group’s September 2025 whitepaper, From Sprints to Swarms: Navigating the Post-Agile Future in the Age of AI, on Autonomous Agent Swarms and Orchestrated Specialist Pipelines sits alongside the other two.4 It is a thoughtful survey of the post-agile landscape and names several patterns the book agrees with. Its problem, as a candidate name, is the one every noun-plus-adjective label has: the phrases describe a topology of work rather than a verb the studio does. Swarms and pipelines will age the way waterfall aged, because the tooling they describe is exactly what changes every eighteen months. The cluster — GSD, SASE, Swarms — is itself the evidence. When three serious groups propose three incompatible names in the same eighteen months, the space is unsettled. All three were in circulation by the time people walked into Deer Valley in February, and the room still did not draft the successor. The opening has not closed.

The book walks into that opening and puts down a word.

Before committing to a methodology name in a proposal or in public writing, run it against three working questions: does it survive being said in a second language, does a founder use it back to you unprompted within an hour, and does pulling on the word produce more vocabulary or stop at the label itself? If two of the three fail, the word is not ready. Keep it internal until it passes.

A name is a claim to the part of the room the author has stood in long enough to describe with his own vocabulary. Sliday has been standing in this part of the room for two years. The word we use for what we do there is Sculpting. Other studios, standing in other parts of the room, will land on other words; some will be better. The field will settle, eventually, the way agile settled, not by vote, but by use. Use the word that produces the work. If a better one arrives, use it. We have no vested interest in the syllables.

If a methodology name is new to your studio, use it internally for four weeks before putting it in a proposal. Those four weeks will show whether the vocabulary produces working questions or whether it is shorthand hiding the same old debate. Adopt it publicly only when it makes client conversations shorter, not longer.

What we have an interest in is that the work now has a word, because the word is what makes the work askable. A founder who knows the word can ring a studio and ask for it. A studio that knows the word can price it. An engineer can put it on a CV. A conference can put it on a lanyard. A client brief can specify it. None of those motions are possible while the work is still being described as the thing we do that is not quite agile any more and is definitely not waterfall. The phrase is accurate. The phrase does not produce a purchase order.

Once you have the word, you can ask for the work; before you have the word, you can only describe the absence of it.