How RACE Will Scale, First Sketches
These are notes, not doctrine. The rest of this site states what RACE Programming is today, tested on delivered projects. This page is the opposite: an unfinished argument about where the scaling model goes next, written down while it is still moving. Read it as a sketch in pencil. Some of it will turn out to be wrong, and that is the point of writing it down early.
The scaled form we have, and why I no longer believe in it
The current answer to “how do you grow beyond one team” is to add Pit Crews. One Pit Wall pair can specify for several crews at once, so the engagement grows sideways: two crews, three, up to about five, and past that you split into independent streams with their own Pit Wall.
It is a reasonable model. It is also, I suspect, a transitional one, and it carries an assumption from the era it was designed in: that a Pit Crew is three people, and that more delivery means more crews of three people.
I do not think that assumption survives.
The Silicon Pit Crew
The direction things are moving looks different. Not more crews of three, but an execution tier whose composition you set rather than staff.
Call it the Silicon Pit Crew: an execution unit where the work is done by agents under supervision rather than by people at keyboards.
The important part is what this is not. It is not a swap, human crew out and silicon crew in. Scaling comes from blending the two, and the mix is the thing you tune. Some engagements run mostly human crews with a silicon one alongside; some invert that; most sit somewhere between, and the same engagement moves along that axis as it matures. Growth stops meaning “add three more people” and starts meaning “shift the mix and add capacity to a system already running”.
What sets the achievable mix is not preference. It is readiness, and it is measurable:
- How ready the project is. A codebase an agent can navigate, with environments it can run in.
- Discipline in the requirements work. The specification has to actually be executable, not a story with hopeful acceptance criteria attached.
- Project memory. The domain glossary, the rationale behind decisions, the architectural constraints, held somewhere an agent can read rather than in somebody’s head.
- Discipline in quality control. The four gates enforced without exception, because there is less human judgement in the loop to catch what slips.
- And above all, model maturity. This one is not ours to control, and it moves the ceiling more than the other four combined.
Where those are weak, the mix stays human. Where they are strong, it tilts silicon. That is the whole mechanism, and it is why this is a dial rather than a switch.
Note what does not change in either direction. The Pit Wall still holds the domain, still turns intent into a specification, still owns the client’s ability to decide and accept. The specification remains the artifact everything else hangs on, arguably more so, because the further the mix tilts silicon, the fewer people are left in the execution tier to quietly fix an ambiguity out of experience.
The role that does not exist yet
A silicon crew does not run itself, and here is where the sketch gets least certain.
Somebody has to build and maintain the machinery that lets agents execute reliably on this product: the pipelines, the guardrails, the evaluation harnesses, the environments, the security boundaries, the automation tuned to this codebase and this domain rather than to software in general.
Working title: AI DevSecOps. Not the classic DevOps role with AI bolted on, and not a platform team serving everyone. Something closer to an engineer who automates the Pit Crew’s work for a specific project or product, and keeps that automation honest as the product changes.
I am not confident about the name. I am fairly confident about the gap. When the execution tier is agents, the leverage moves to whoever configures the execution tier, and that is not the same skill as writing the code was.
What follows, if this holds
A few consequences worth writing down, precisely so they can be checked later.
The ladder stops being the growth path. Two crews, three, five, then split into streams: that sequence was built to add human throughput, and it assumes every increment is another three people. Once the mix is a dial, the first move is to change composition rather than to add another rung, and the ladder becomes one option among several rather than the route.
The ratio shifts, and how far is a readiness question. Today the Pit Wall is the small tier and the crews are where the headcount lives. As the five conditions above are met, headcount concentrates in the Pit Wall and the automation role while the execution tier grows without hiring. How far that goes on a given engagement is not a matter of ambition, it is a matter of which of those conditions actually hold.
Supervision becomes the scarce skill. Not writing code, and not reviewing individual diffs either, but knowing what to watch, what to sample, and when the system is drifting. Closer to running a factory line than to pairing.
The economics change shape again. The current triangle numbers come from comparing a five-person senior team against a ten-person Scrum team. That arithmetic assumes a fixed number of people in the execution tier. Once that number is a variable, one comparison stops being enough: the honest form is a curve across the mix, not a single ratio, and it has to be rebuilt rather than adjusted.
What I am deliberately not saying
I am not claiming this is RACE Programming. It is not in the framework, it is not on the roles page, and nobody should plan an engagement around it.
I am also parking the question of what to call the scaled form. There was a working name for it, and I am setting that aside rather than defending it, because naming a thing tends to freeze it, and this is not ready to be frozen.
And I am not putting a date on any of it. The honest position is that the pieces are visible and the sequence is not.
One wild guess, labelled as exactly that. Six months, give or take, before the first working versions of these teams exist. Not mature, not the default way anything is delivered, just the first ones that hold together on real work. I would not plan against that number, and I am writing it down so it can be held against me.
Why publish an unfinished thought
Because the alternative is publishing it late, after it has hardened into a position and stopped being examinable.
If you run delivery at any scale, you have an opinion about which half of this is wrong. That is exactly what I want. Tell me the part that does not hold, or the part I am missing, or the thing you have already tried that says otherwise.
Written by Pavel Khodalev, author of RACE Programming and CTO of First Line Software. Follow new essays via RSS.