Verify

The bottleneck has moved.

For most of software’s history, the slow step was producing code. You had a problem, you understood it, you typed. The typing took weeks. You hired more typists, you used better languages, you bought faster keyboards — but you were still optimising the same step. Production. The thing that came out the bottom.

AI broke that. The cost of producing code is now a rounding error. What used to take a week takes an afternoon. Sometimes an hour. The bottleneck didn’t get smaller. It moved.

It moved to verification.

---

What’s slow now¶

You can produce a thousand lines of code in fifteen minutes. You cannot read a thousand lines of code in fifteen minutes. Not in a way where you’d stake your name on what you read. The asymmetry is the whole story. Production is fast. Comprehension is unchanged.

For a substrate team, this is the central problem. A pair, an AI multiplier, and an output rate that’s gone vertical — but only as good as the team’s ability to look at what came out and say, with confidence, this is right. The team that can’t verify quickly is just generating expensive landfill.

So verification becomes the craft. Not “did the tests pass” — that’s the floor. Real verification is: do I understand what this code is doing, do I recognise it as good, do I trust it does what we wanted, would I be willing to deploy it in front of the customer tomorrow. The first question takes seconds with AI help. The second takes a minute. The third takes a conversation. The fourth takes everything you have.

That last one is the new craft. Not writing the code. Standing behind it.

Stack as a verification decision¶

Here’s where stack choice becomes interesting again.

In the old world, stack was a productivity decision. Pick the language and framework that let your big team ship fast. There was a “right” stack for the company. Sometimes a “right” stack for the industry. We argued about it a lot, mostly in retros nobody enjoyed.

In the substrate world, stack is a verification decision. Pick the language and framework where your specific team — these two people, with their specific experience — can look at the AI’s output and know whether it’s good. The Rails veteran spots a slow query in three seconds. The Go person smells a goroutine leak. The Postgres lifer knows a bad index when they see one. That kind of recognition is the new productivity.

So a substrate team picks the stack it knows best, not the stack the architecture committee thinks is correct. This isn’t lazy. It’s the opposite of lazy. It says: we have to verify what AI produces, fast, and we can only verify what we’re aggressively familiar with.

The stack is no longer a company decision. It’s a team decision, made by the team, in service of the verification their work depends on.

Mobility¶

The objection writes itself. Aren’t we creating a fragmented mess? A different stack for every team?

Sort of. And it doesn’t matter the way it used to.

AI made stacks portable. The thing your team built in Rails this year can be rewritten in Go next year, by a different team, in a fraction of the time it would have taken before. The cost of moving a system from one stack to another has collapsed alongside the cost of producing the system in the first place.

Which means stack choice is no longer a forty-year decision. It’s a now decision. Pick the stack that lets this team, on this problem, verify their work today. If next year a different team takes it on with different familiarity, they can move it. The substrate doesn’t care about the building. It cares about the people in it.

It used to be that the stack was the building, and the team was the tenants. Now the stack is the clothes, and the team wears what fits.

Internal substrate teams¶

Not every customer is external. The platform team’s customer is the engineers on the product teams. The infrastructure team’s customer is the platform team. The design system team’s customer is everyone who imports the design system.

Internal substrate teams. Same shape — small, light, AI-multiplied — and probably already closer to their customer than most product teams are to theirs. The Slack channel for the platform team is full of the platform’s users. The bug reports come from people you eat lunch with. Customer-on-site happened by default.¹

What changes for them is the verification load. Their AI produces as much code as anyone else’s. Their stack is as much of a verification choice. They can move faster than most because the trust loop with their customer was already short. But the loop still has to close.

Trust between teams¶

Now the cultural piece, which is the bit most orgs underestimate.

Once you accept that each team picks its own stack, its own patterns, its own pace — you need a culture that holds it together. Not coordination. Trust.

A substrate org runs on the assumption that every other team is making good decisions, in their context, with information you don’t have. You don’t audit them. You don’t second-guess their stack. You don’t ask them to justify why they chose Rails when you chose Go. You don’t pull them into a meeting to defend their pattern choices. You assume they know their work, you know yours, and the judgement they made was the judgement that produced the best outcome for their team and their customer.

It runs the other way too. When another team’s choice doesn’t make sense to you, the first move is to ask, not to argue. They probably saw something you didn’t. The team standing in front of the work tends to know more about it than the team writing critical Slack messages from the sidelines. Default to charity. The substrate runs on it.

This is harder than it sounds. The instinct to standardise is strong. There is comfort in everyone using the same things. But standardisation is just trust outsourced to a process — we trust the standard so we don’t have to trust each other. And processes aren’t substrate. People are.

The culture is pioneering. Each pair, or trio, is out at the edge with their customer, making calls. They share what they learn. They borrow each other’s patterns when the patterns travel. The shared thing isn’t the stack or the framework. It’s the standard — what good looks like, what shipping means, what we tell the customer.

That standard is the only architecture that scales.

---

The pattern, if it is one:

The substrate is people. The work happens close to them. It gets verified by the team standing in front of it. It holds together because each team trusts the others to do the same.

Code gets cheaper. Verification doesn’t. Trust really doesn’t. The substrate is still us — and now, also, the team next to us.

Footnotes¶

1. Customer-on-site was one of XP’s original twelve practices and, at the time, a heroic stretch. For an internal substrate team it isn’t a stretch — the work already happens next to the people doing it. ↩