RACE Programming
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. 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, forming a Pit Crew. Pit Wall covers quality gating until throughput justifies a dedicated Pit Crew Quality Engineer. 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 up to 5 Pit Crews. Add Pit Crews as demand grows.

Five Pit Crews = throughput of 10 Scrum teams with a 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.
  • AI Product. Gherkin acceptance scenarios, 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 Demo, non-negotiable.
How

The first Stint

Day 1
EPR session. Pit Wall + Team Principal. Build the Executable Product Roadmap: quarterly scope, Stint-projected, with delivery cost per item. Client approves before any coding.
Days 2–3
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 4–5
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
Pit Stop Demo. Client runs acceptance testing in staging. Go / No-Go on production deployment.

Team Principal: what you must lock in before Stint 1

  • Availability SLA in writing. Team Principal responds to prototype review and Pit Stop Demo 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
% where staging UAT passes on demo day
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's Stint 1, Day 2.

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 tops out at a Quality Engineer plus 2 Pit Crew Software Engineers and never grows past that. 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.