May 13, 2026 · 7 min read

What Dies

A carpenter can build a house alone now.

Not a small one. A real house — frame, roof, plumbing, wiring, finish. With cordless tools, prefab trusses, panel systems, glue-laminated beams, a battery nailer that does what three labourers used to do between them. The build takes longer than it would with a crew, but it happens. And the carpenter doing it isn’t a different kind of carpenter. Same training, same craft. What changed is the equipment.

The crew didn’t disappear because anyone declared it obsolete. It disappeared because most of what the crew was for — lifting heavy things, holding heavy things, hitting things many times — became one person’s job.

Software is doing the same thing. The tools and the materials have reached the point where one or two engineers can do what eight used to. The crew is going away. The crew rituals haven’t caught up.

Most of it was scaffolding¶

Most of what we currently call “engineering practice” was scaffolding for the crew. Big teams, slow tools, distance from the customer’s room, expensive coordination — that was the building site, and the practices were the props that held the work up while the crew did its thing.

Take the building site away and a lot of the props don’t have anything to support. They keep standing on inertia, on muscle memory, on the fact that nobody wants to be the one who says we should stop doing the standup.

This essay names them. Not to declare them dead — substrate teams aren’t a methodology, and the right answer is rarely “stop completely”. The right question is: what was this practice actually for, do we still have that problem, and if not, what — if anything — now does the work?

If you can’t answer the first question, that’s the problem, regardless of whether you keep doing the practice.

The translation layer¶

The detailed spec was for handoff. Someone who’d talked to the customer wrote down what they thought was true; someone who hadn’t turned it into code. The spec was the bridge, lossy and slow, but the only way to scale shared understanding across a crew. With two engineers in the customer’s room, the bridge has nothing to bridge. The spec becomes slower talking.

The architect-as-blueprint was the same problem one level up. One senior person held the system in their head; the rest of the crew built the parts they were given. That arrangement requires a crew. A substrate pair holds the system between them in conversation. The architect role doesn’t disappear — coordination across teams still needs someone — but the version where the architect is the author of the design and the engineers are the typists doesn’t survive the move.

What replaces both: conversation, repeated, with the customer in the room. Not a document.

Estimation theatre¶

Story points and planning poker were for forecasting a big team’s throughput across many small tasks. The whole apparatus — the velocity charts, the burndown, the “we deliver thirty-eight points per sprint” — was a way of reducing a crew’s output to a number you could plan against.

Substrate teams aren’t pushing through many small tasks. They’re holding a small number of bigger questions in their head and finishing them. Asking them to estimate next week’s work in points is dressing up “I’m not sure yet” as a number, then optimising for the number, then being shocked when the number turns out to be a poor measure of whether anything good got built.

The twelve-month roadmap is the same trick at a longer time horizon. It was for letting non-engineers count on dates from engineers who couldn’t change direction quickly. Substrate teams change direction in the customer’s office on Tuesday. A Gantt chart that pretends otherwise is fiction the customer doesn’t believe either.

What survives: directional clarity. What are we trying to learn this quarter, what bet are we making, what would change our minds. All useful. The number isn’t.

The quality gate¶

The four-eyes pull request review was for catching the mistakes a tired junior engineer made on Friday afternoon. It was gatekeeping. With AI catching most of the obvious mistakes faster than a human reviewer would, the gatekeeping reads of a review become noise — and the noise crowds out the only kind of review that actually mattered, which was a more senior engineer asking whether the design itself was right.

That second kind of review survives. It survives in a different shape — closer to Verify’s definition of standing behind the work — and it doesn’t require the rest of the team to rubber-stamp every line of every change.

Test coverage targets were a proxy for “did this engineer think about edge cases”. When you couldn’t trust the engineer to think about edge cases, you wanted a number that approximated whether they had. Now AI generates edge cases the engineer wouldn’t have thought of unprompted. The coverage target becomes Goodhart’s-law theatre¹ — a measure that stops being a measure once it becomes a target.

What survives: the question of whether you’d deploy this in front of the customer tomorrow. That question doesn’t have a number.

The standup and the silo¶

The eight-person standup was for synchronising people who couldn’t see each other’s work in flight. A substrate pair synchronises constantly because they’re sitting next to each other, or one Slack message away. The standup persists as a calendar habit. Sometimes useful at the team-of-teams level, where coordination across substrate teams genuinely matters. Rarely useful inside a substrate team that’s already in continuous conversation.

The functional silo — frontend team, backend team, mobile team, ops team — was for managing the cost of context-switching across specialities. AI dropped that cost to almost nothing. The silos persist on social inertia and on org charts that haven’t caught up. The substrate team is end-to-end by design, and “end-to-end” is no longer a heroic stretch; it’s the default mode.

What survives: cross-team coordination when the work genuinely spans multiple substrates. That isn’t a standup. That’s a conversation between two teams who actually need to talk.

What survives¶

The substrate’s principles. Proximity. Verification. Judgement. Trust. Problem-finding. The four lines from the first essay survive the way they always do — they were never tied to a tool or a team size.

A handful of the practices survive too, in altered forms. Pair programming, when the pair is working on a hard design question and AI is the third in the room. Code review, when it’s about design rather than gatekeeping. Retros, when the team is actually changing what they do based on them. Roadmaps, when they’re a statement of intent rather than a commitment.

The pattern: the practice survives if it serves a problem the team currently has. It dies if it serves a problem the team used to have.

The carpenter still has tools, jigs, working drawings, finishing standards. They aren’t building without method. They’re building without the crew, and the methods that survive are the ones that fit a single craftsperson with the right equipment. The methods that don’t fit got left in the back of the truck.

Software is in the same moment. Most of the practices we treat as engineering essentials are crew practices. Some will survive in a smaller form. Most won’t.

The rule of thumb: if you can’t say what problem a practice is solving for your specific team this week, you’re probably watching scaffolding hold up empty air.

The substrate isn’t the scaffolding. It’s what stood underneath.

Take it down.

Charles Goodhart, 1975, observing that any statistical regularity collapses once pressed into service as a target. The crisper restatement in the body — “when a measure becomes a target, it ceases to be a good measure” — is Marilyn Strathern’s, 1997. ↩