RACE Programming
Audio brief · 2 min
Practice Guide · Greenfield

Starting RACE Programming from day one

No legacy constraints. No existing rituals. Build the RACE Programming system right, adding headcount only when each configuration is provably saturated.

Why

Why greenfield is the best starting point

Greenfield is where RACE Programming's economics are strongest (~3× the output for the same budget): no legacy constraints, no team rituals to unlearn, no brownfield coordination overhead. From day one the bottleneck is specification quality and Team Principal availability, not code volume.

The failure mode in greenfield AI projects is scaling prematurely, adding engineers before the Pit Wall is proven, before the Executable User Story cadence is stable, before Team Principal availability is locked. The six-stage model below prevents it.

What

The six scaling stages

Add headcount only when the current configuration is provably saturated. Each stage is a complete, functional delivery system, not a partial team waiting to be filled.

Stage 1

Start as one pair

Pit Wall pair (Forward Deployed Engineer + AI Product) acts as both Pit Wall and Pit Crew. At this stage there is no Pit Crew and no separation between specification and execution yet; both arrive with the Quality Engineer at Stage 2. They author EUS, build prototypes, execute.

When to move on: Team Principal's required pace exceeds two-person capacity → add the first Pit Crew Software Engineer. Pit Wall keeps executing alongside the new engineer.

Stage 2

Split roles, add crew

Still insufficient → add a second engineer and a Pit Crew Quality Engineer, forming the Pit Crew: Quality Engineer + 2 Pit Crew Software Engineers, working with the Silicon Software Engineer. At low throughput that roster is fractional (the Quality Engineer at 50%), never incomplete: the wall between specification and execution exists from the first Pit Crew. The Forward Deployed Engineer shifts to Pit Wall only (50% allocation).

When to move on: Still not enough throughput → move to the scaled form: one Pit Wall serving 2–5 Pit Crews simultaneously.

Stages 3–5

Grow to 5 Pit Crews

The scaled form: one Pit Wall serving 2–5 Pit Crews. Add Pit Crews as demand grows.

Five Pit Crews is the most EUS per week one Pit Wall can specify for, against a single synchronized backlog. Unreachable with a classic delivery approach.

Stage 6

Split streams

If demand still exceeds one Pit Wall's capacity at 5 Pit Crews → split with Team Principal into 2 independent streams, each with its own Pit Wall.

The pattern repeats from Stage 1 within each stream.

Each stage adds headcount only when the previous configuration is provably saturated.

Who

Who you need, and when

Pit Wall (Stage 1 minimum)

  • Forward Deployed Engineer (Pit Wall lead). Architecture decisions (ADR), prototype build, Pit Wall execution oversight.
  • Both directions, not just downward. The Pit Wall does not only turn intent into a spec. It brings 2 or 3 working prototype options to every decision, so the Team Principal chooses between things they can see, and it owns the Team Principal's review throughput, bringing automation and the agent into UAT so acceptance does not become the constraint. On a greenfield engagement this is what keeps the client from becoming the bottleneck in month two.
  • AI Product. Gherkin acceptance tests (owned here; the Quality Engineer automates them), EPB management, EARS NFR, client communication.
  • Silicon Software Engineer (the AI agent). Prototyping and spec authorship alongside the human pair. Not headcount: the AI teammate.
  • Both human roles required. One person may cover both in early-stage engagements.
  • Qualification threshold: AI Fluency at senior level. Prototype build time ≤ 2 days. EUS acceptance rate > 80% first pass within 2 months.

Pit Crew (add when Pit Wall saturated)

  • Pit Crew Quality Engineer + 2 Pit Crew Software Engineers + the Silicon Software Engineer (the AI agent, not headcount).
  • No ceremonies. No standups. Inner cycle 2×/day.
  • Rule: do not add people inside a Pit Crew; add Pit Crews.
  • Qualification: AI-native execution. All 4 DoD gates green before every Pit Stop, non-negotiable.
How

The first Stint

Day 0
EPR session. Pit Wall + Team Principal, once before the first Stint opens. Build the Executable Product Roadmap: quarterly scope, Stint-projected, with delivery cost per item. Client approves before any coding.
Before the Stint opens
First EUS + prototype. Pit Wall authors the highest-priority Executable User Story. Builds prototype on synthetic test data. Client validates intent; no production code yet.
Days 1–2 of the Stint
Pit Crew executes. Pit Crew receives approved EUS. Builds against the prototype. 4-gate DoD: unit ≥ 80%, integration, E2E, acceptance, all automated.
End of Stint
UAT and Pit Stop. The Team Principal runs acceptance testing, then the work deploys to production. Go / No-Go on production deployment. The whole Stint closes on day two or three.

Team Principal: what you must lock in before Stint 1

  • Availability SLA in writing. Team Principal responds to prototype review and UAT within 1 day. An engagement-level SLA, not a courtesy ask. Missing feedback blocks Pit Wall and compounds.
  • Feedback calibration. "I don't like it" is not feedback. Train Team Principal to answer: Is this what I meant? What business rule is missing? What would my user say? Calibrate in Stints 1–2.
  • No direct Pit Crew contact. If Team Principal bypasses Pit Wall and tasks Pit Crew directly, intervene immediately. First occurrence: address. Second: escalate as engagement risk.
How to measure success

Metrics from week one

EUS acceptance rate
% of EUS accepted without revision after prototype review
Target: > 80% first pass within 2 months
Prototype build time
Days from EUS authoring start to client prototype delivery
Target: ≤ 2 days consistently
Pit Stop pass rate
% of Stints that reach the Pit Stop with UAT green
Target: > 70% in first 3 Stints
Rework rate
Stories returned to Pit Crew after delivery
Target: < 10% after month 2
Pit Wall saturation signal
Team Principal feedback response > 1 day, OR Pit Wall cannot deliver EUS before Pit Crew is idle
Trigger: add next stage headcount
The first step
Identify your highest-priority story. Author the Executable User Story. Build the prototype. Show the client before writing a line of production code. That is Stint 1, day one.

See the Framework overview for full role and artifact specifications. If your team is migrating from Scrum, the From Scrum guide covers the transition mechanics in detail.

FAQ

Frequently asked questions

How do you start a greenfield project with RACE Programming?
Start with a Pit Wall pair (Forward Deployed Engineer + AI Product) acting as both Pit Wall and Pit Crew. They author the first Executable User Stories and build the first prototype before writing any production code. Add headcount only when this configuration is provably saturated.
When do you add more people in a greenfield RACE Programming project?
Add the first Pit Crew Software Engineer when the Team Principal's required pace exceeds two-person capacity. Add a second when still insufficient: a Pit Crew is a Quality Engineer plus 2 Pit Crew Software Engineers, working with the Silicon Software Engineer, and that roster is fixed rather than a maximum. When one Pit Crew is provably saturated, add another Pit Crew under the same Pit Wall (the scaled form). Add a second Pit Wall only when one Pit Wall is saturated across its Pit Crews. Never add people inside a Pit Crew; add Pit Crews instead.
What is the ceiling for one Pit Wall in a greenfield project?
In RACE Programming, one Pit Wall pair serves one Pit Crew, the fundamental unit. When capacity is insufficient, the engagement moves to the scaled form: one Pit Wall serving 2–5 Pit Crews simultaneously. That scaled form, one Pit Wall serving several Pit Crews, is how RACE Programming grows into larger engagements.
Developed in the open

Help develop this

RACE Programming is a working framework, not a final answer. If this was useful, I would like your feedback: what you think is right, what you think is wrong, and what you would change. Disagree with any part, send a better version, or use it in your own work and tell me how it went. It improves faster when people develop it together.

Write to me: paul@raceprogramming.com