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: people only to complete one Pit Crew, then growth through the machinery.

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 people only to complete one Pit Crew, and only when the current configuration is provably saturated. Past that, the stages raise the share of the backlog the machinery clears. Each stage is a complete, functional delivery system, not a partial team waiting to be filled.

Stage 1

Start with the Pit Wall alone

The Pit Wall (Forward Deployed Engineer + AI Product, two roles carried by one person or more) 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 and steps down to part-time oversight as the frame of the solution stabilizes.

When to move on: Still not enough throughput → do not add a second Pit Crew under the same Pit Wall. Raise the share of the backlog the machinery clears.

Stages 3 to 5

Raise the machinery's share

The Forward Deployed Engineer owns the delivery machinery of the project: the swarm of agents, its integrations with every system the project uses, and the workflows, guardrails and pipelines that clear backlog correctly. The Pit Wall keeps tuning the project environment, the flow of requirements in and results out, and the machinery, so the engagement takes more of what the Team Principal pushes into the backlog.

The number to watch is the share of the backlog the machinery clears. The rest is cleared by hand: the Forward Deployed Engineer pulls it onto themselves, or passes it to the people in the Pit Crew. How far the machinery goes depends on model maturity and on how ready the project is.

Stage 6

Call in a RACE Engineer

If building the machinery absorbs the Forward Deployed Engineer → do not split the backlog into streams. Call in a RACE Engineer, part-time and on request, the way DevOps works today, to help raise the share of the backlog the machinery clears.

Genuinely separate products are separate engagements, each with its own Pit Wall, coordinated by the TPM, not a split of one backlog. See How RACE Scales.

People are added only to complete one Pit Crew. Past that, each stage raises the share of the backlog the machinery clears, not headcount.

Who

Who you need, and when

Pit Wall (Stage 1 minimum)

  • Forward Deployed Engineer (Pit Wall lead). Architecture decisions (ADR), feasibility of the prototypes the Pit Wall builds, 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 roles. 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 and do not add Pit Crews under the Pit Wall; raise the share of the backlog the machinery clears.
  • Qualification: AI-native execution. All 4 DoD gates green before every Pit Stop, non-negotiable.

TPM (organizes the start)

  • TPM (Technical Program Manager). Assigned by leadership, usually part-time on a single greenfield team. Organizes the start: the plan to the first release, the sponsor's and stakeholders' expectations around the Team Principal, the risk register and escalation.
  • Does not decide what to build or how: the roadmap and the Executable User Stories stay with the Pit Wall and the Team Principal.
How

The first story

Day 0
EPR session. Pit Wall + Team Principal, once before the first story starts. Build the Executable Product Roadmap: quarterly scope, projected onto Pit Stops at the client's release cadence, with delivery cost per item. Client approves before any coding.
Before the Pit Crew pulls the story
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 story
Pit Crew executes. Pit Crew receives approved EUS. Builds against the prototype. 4-gate DoD: unit ≥ 80%, integration, E2E, acceptance, all automated.
Day 2 or 3, then the Pit Stop
UAT and Pit Stop. The Team Principal runs acceptance testing; the story is production-ready on day two or three. Go / No-Go at the next Pit Stop, the release on the client's cadence, which takes it to production.

Team Principal: what you must lock in before the first story

  • 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. The TPM agrees it with the Team Principal and their sponsor.
  • 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 on the first stories.
  • 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; the TPM logs it in the risk register and takes it up with the Team Principal.
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 Pit Stops shipped with UAT green and no rollback or hotfix
Target: > 70% in the first 3 Pit Stops
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: move to the next stage (complete the Pit Crew, then raise the machinery's share)
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 day one of the first story.

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 the Pit Wall alone, two roles (Forward Deployed Engineer + AI Product) carried by one or two people, 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 people only to complete one Pit Crew, and only when the current configuration is provably saturated; past that, the engagement grows by raising the share of the backlog the machinery clears.
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 that Pit Crew is provably saturated, do not add people: not inside the Pit Crew, not as another Pit Crew under the same Pit Wall, not as a split into streams. The Forward Deployed Engineer raises the share of the backlog the machinery clears, with a RACE Engineer called in part-time and on request when the build is heavy.
What is the ceiling for one Pit Wall in a greenfield project?
In RACE Programming, one Pit Wall serves one Pit Crew, the fundamental unit. The ceiling is not a number of Pit Crews: more Pit Crews under one Pit Wall, then a split into streams, is not how RACE Programming grows. The engagement grows by raising the share of the backlog the machinery clears, and the ceiling is the cognitive focus of each person left in the loop. Genuinely separate products are separate engagements, coordinated by the TPM.