Why RACE Programming exists
For three years we have delivered software with AI agents. Not as a pilot, not as a side experiment, but as the way the work actually gets done. For most of that time the honest answer was “useful, with supervision.” Then, over the last year and especially the last six months, the tools crossed a line. An agent can now be trusted with complex production code, and it gives serious leverage on analytical work too. The question stopped being whether the agent can do the work and became how you organize a team around one that can.
That is the moment a new teammate joined. We call it the Silicon Software Engineer. The name is deliberate. It is not a tool you point at a problem and put down. It is a member of the team: it produces, it has strengths and sharp limits, and it has to be directed, reviewed, and held to a standard like any other engineer. Treat it as autocomplete and most of the value stays on the table. Treat it as a teammate and that is the unlock.
Once you accept that, the human job changes. People stop competing with the machine on the thing it is now good at, writing code. Their work moves to two skills. The first is AI fluency: knowing what to delegate, how to specify it, and how to tell good output from confident-but-wrong output. The second is management: directing a Silicon Software Engineer the way a strong tech lead gets the best from a team. Neither skill is about typing faster.
And here is the part that surprises people. The methods we trusted for twenty years broke overnight. Agile, Scrum, XP, and their ceremonies were built to coordinate people, because people were the bottleneck. Stand-ups, sprints, and estimation exist to synchronize a group of humans. The moment the main producer of code is an agent, a method for managing people is managing the wrong thing. It optimizes a constraint that has moved.
RACE Programming is the rebuild. It is a delivery process re-architected around one question: how do you manage a Silicon Software Engineer to ship production-grade software, every time? The answers are specific. Small accountable teams instead of large ones. Executable specifications the agent can build without re-interpreting intent. Continuous flow instead of sprint ceremony. And verification built in as a hard gate, because when code is cheap and confident-but-wrong output is the dominant risk, the thing that proves the work is correct cannot be an afterthought, and cannot be written by the same agent that wrote the code.
None of this is theory we hope is true. It was built and measured on real client delivery before it was written down. The economics hold on the project triangle: with quality fixed, the same budget buys materially more scope, or the same scope costs less, or it ships faster. Pick the corner the engagement needs.
So if you are new here, this is where you have arrived and what it rests on. AI-First Theory describes what changed. The AI-First Manifesto names the values that follow. RACE Programming is the prescription: what to actually do about it. The rest is detail.
Written by Pavel Khodalev, author of RACE Programming and CTO of First Line Software. Follow new essays via RSS.