The Discipline of Subtraction

On a shared video call, with my standing desk in Kraków and his in a shared workspace in Melbourne, I told a founder we were cutting the activity feed, the whole module — the schema, the websocket, the nine screens, the two widgets on the home view and the notifications badge that drove it all. Cut today, merged tomorrow, live Friday. He looked at me, and for about eleven seconds said nothing. Then he said, “I built that in a weekend,” which is a sentence every studio owner working this way will hear roughly once a month for the rest of their career.

The feed made up nineteen per cent of the codebase, a second database the rest of the app did not use, four cron jobs and an empty state that eighty-three per cent of new users saw for their first forty seconds in the product. It was also the feature the founder would have named, unprompted, as his favourite. Cutting it doubled thirty-day retention over the following quarter.

That conversation is the work. Nothing in twenty years of my training as an engineer prepared me to do it well.

Engineers are taught to add. Every intro tutorial, every coding-bootcamp exercise, every interview rubric, every green commit in every contribution graph measures addition. Lines written. Features landed. Pull requests merged. The profession’s entire reward loop fires on the forward stroke. Subtraction fires nothing. You delete two thousand lines on a Tuesday and the graph shows a flat grey bar; a junior engineer will ask, tentatively, whether you had a quiet day.

I want to slow down on the AI row of the canonical visual, because it is the part of the picture I have not yet earned the right to describe in detail. The Hidden Axiom walked all three rows top to bottom. Here I want to walk one row, left to right, and name each removal as a decision a person had to make.

The first frame, which the founder hands you on Monday morning, is the green Mad-Max car. You have met it already: too much of everything. Welded-on weapons — the bolt-on LLM integration, the unnecessary OAuth provider, the Stripe webhook for a pricing model the founder has not yet decided on. A roof rack, heavy with cargo nobody will ever unload — a full events schema when the product has two events, a plan table with fourteen rows when the landing page offers three. A second antenna beside the first — the GraphQL layer on top of the REST API, or vice versa, duplicated from the template the founder forked and never reconciled. Junk on the bonnet — dead imports, a folder of one-off scripts from the weekend, a README written in a voice that is not the founder’s because the model wrote it. A cartoon driver in the front seat — the placeholder avatar, the Lorem Ipsum testimonials, the fake user with the email address elon@musk.com. And the wrong colour — the Tailwind defaults tuned by someone who had never designed a form in their life.

The second frame removes the weapons. This is the easy removal, because the weapons are obviously welded on; they do not pretend to be load-bearing. The studio reads the repository on Monday morning and names them: the unused OAuth, the half-wired Stripe. Cut. The third frame removes the roof rack. This is harder, because a schema that holds only two events today is cheap to keep, and the argument for keeping it is that the third event is coming in six weeks. You will have this argument often. The correct default is to cut. The fourth frame removes the second antenna. You cannot have two opinions about your API surface and survive a security audit. The fifth frame removes the junk on the bonnet — the dead imports, the one-off scripts, the machine-generated README. The sixth frame removes the cartoon driver; the placeholder data goes, the fake testimonials go and the elon@musk.com account is purged from the seeds. The seventh frame repaints. The Tailwind defaults, which got the prototype in front of users, will not survive the first investor deck.

Six removals. Each one is an editorial decision, argued between two adults, one of whom built the thing.

The thousand are not enemies. They are the founder who wrote the feature; the engineer who completed it ahead of the sprint and is keen to ship; the investor who asked about AI pricing at the pitch; the blog post the founder read at midnight three Sundays ago; the cousin who said the product “could also do this one thing”; the version of the founder who wants to be known as the person who thought of it; the model that suggested it; and the ordinary human preference for keeping a thing that works over removing it. Subtraction’s advocate, in our working model, is the studio. Usually one specific person in the studio. Sometimes, on a hard week, an exhausted one. One of our designers described the shift plainly: two years ago she spent forty per cent of her hours on original design and none editing AI output; now those proportions are roughly reversed, with editing AI output taking the largest share. The new skill she named for it is, paraphrased, a triple-pass tidy, surfacing the main thing, hiding what is secondary, cutting navigation down, and doing that cycle three times until the prototype stops fighting the user.

The empirical case for subtraction from an AI-built prototype is not an aesthetic one. The CodeScene study mentioned earlier, by Borg, Tornhill and colleagues, measured how often model-written refactorings broke code of varying health.¹ Their numbers are modest until you notice what they are measuring: depending on the model, refactorings broke fifteen to thirty per cent less often in code above the CodeScene health threshold than in code below it, and some models showed no significant gap. They did not test weekend prototypes. Every founder repository we have audited has landed below that threshold, which is our observation rather than theirs. The studio that reads it and ships it unchanged is accepting a risk that CodeScene’s refactoring benchmark says deserves a closer look. A trial METR published in July 2025 caught sixteen experienced open-source developers nineteen per cent slower on their own repositories when they added early-2025 AI tools to their existing flow, a slowdown the self-reports did not show.² Neither study tested subtraction, and I am not going to pretend otherwise. What they establish is narrower and still useful: the tools slowed experienced developers who believed they were faster, and model refactorings broke more often in unhealthy code, which is where, in our experience, a weekend prototype sits. Cutting it back is our inference from that, drawn from our own engagements rather than from either paper. The prototype’s problem is that nobody cut the code AI wrote.

The closest everyday analogy I have found for this work comes out of a kitchen fit-out. Three years ago we had a fitter at my house installing a set of cupboards against a supporting wall the previous owner had painted to look straight. He arrived at half past eight, ran his level along the wall and told us, before unpacking anything, that the wall was out by fourteen millimetres over two metres, that two of the six cupboards we had ordered would not close against it and that if he fitted them as specified we would be calling him back within a month. He then drew, on the back of the invoice, a version of the kitchen with one fewer cupboard and a scribe against the wall, and said that was the one that would hold. We argued for five minutes, because we had paid for six cupboards and wanted six cupboards. He waited. He had watched more kitchens than we had. We fitted five.

The fitter was doing domain expertise. He had seen enough walls to know which lies they tell and what the consequences of believing them were. A studio that reads a founder’s prototype well is doing the same job. The wall is not flat. The cupboard will not close. Here is the version that will hold.

A discipline requires ritual. We run three of them now, and have run them long enough to describe them without embarrassment.

The deletion sprint runs for half a day, on the first Monday of every engagement and the first Monday of every month thereafter. It is attended by the studio’s Sculptor on the project, the founder and one engineer who has read the repository end to end in the preceding week. Nobody else. The agenda is a single shared document listing every route, every table, every third-party integration, every feature flag and every cron job in the codebase, with three columns: keep, harden, cut. The half day is spent filling the third column. Decisions are recorded in the same document with a one-sentence rationale per cut; the document lives in the repository under /docs/deletions and is referenced by commit message on every deletion PR. We do not overrun the half day. If the columns are not filled, the remainder is cut by the Sculptor in the week that follows, and the founder is told which items were cut and why at the next standup.

The justification review is lighter. Once a week, any feature added to the repository in the preceding seven days must be justified in writing by the person who added it — one paragraph, two if they feel strongly. The review is read aloud in a thirty-minute meeting. Features that cannot be justified in a paragraph are candidates for the next deletion sprint. The meeting is not a gate; it is a writing discipline. Engineers who do not want to write the paragraph stop shipping the feature.

The third ritual I will name only because I have watched it work, not because it has a satisfying name. In April two years ago, after cutting the activity feed I opened this chapter with, we wrote — literally wrote, each of us in our own notebook in our own city, the pages later photographed and posted to a shared thread — what that feed was going to do for the founder, what it had done in fact and what it had taught the team about how users in his segment did not behave. Three paragraphs per person. Ten minutes. We called it a feature funeral afterwards, because one of the designers, a week later, said the room had felt like one. The name stuck. I am reluctant to recommend it to studios who have not had the experience, because a funeral without a body is a branding exercise. If you delete enough features honestly, you will eventually need a ritual for grieving what the team learned from them. If you do not, you will not. Do not hold the ritual until you have earned the right to hold it.

The activity-feed example is composite — three engagements condensed into one, names and numbers adjusted to anonymise all three. The pattern is not composite. In each of the three, the feature the founder had spent the most time on was the feature whose removal moved the engagement metric the most. That is not a general law; two other engagements from the same period saw the opposite. It is a warning. The founder’s attention is an unreliable guide to the user’s attention, and the founder cannot, in the moment, know which is which.

There is a second argument for subtraction which is not commercial. The hardening checklist from From Builders to Hardeners gets cheaper with every feature deleted. Every cut feature is one fewer authentication flow to audit, one fewer state machine to seed test data for, one fewer endpoint on the attack surface. A regulator reading your codebase six months from now will not thank you for the seventeen features your founder loved. They will read what is there.

For the engineer reading this and looking for the name of the skill: the clean version is prototype triage lead. The more honest version is deletion-sprint facilitator. Either is defensible in a CV, in a promotion review and in a conversation with a recruiter who will ask what it means. The name matters because the skill has not existed long enough to have a track record, and a track record is built on a word. Use the word. The same shift is happening on the design side: one of our designers put it that a designer’s eye is still the job, but the first decision is now more often which half of an overloaded screen to remove than what to add.

The studio that masters this is uniquely useful for a reason the earlier IKEA-effect chapter named: the person who built the thing is not the person who can read it clean. The founder who stayed up on Saturday to make the prototype is exactly the founder who will, on Monday, argue the ninth route back in. The studio’s job, on that Monday, is to be the outside reader — the one who did not build it, did not love it at two in the morning and can therefore see it for what it is.

The most expensive line of code in any prototype is the one nobody can bring themselves to delete.