How do you start a greenfield project with R ACE P rogramming?

Start with a Pit Wall pair (ACE Software 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 R ACE P rogramming project?

Add the first engineer when the Team Principal's required pace exceeds two-person capacity. Add a second engineer when still insufficient. Promote to ACE TL and add a second Pit Crew when one Pit Wall can no longer absorb one Pit Crew's output. Never add people inside a Pit Crew — add Pit Crews instead.

Practice Guide · Greenfield

Starting RACE Programming from day one

Q: What is the ceiling for one Pit Wall in a greenfield project?

One Pit Wall pair (in ACE Technical Lead mode) can serve up to 5 Pit Crews simultaneously. Five Pit Crews = throughput equivalent of 10 Scrum teams with a synchronized backlog. Beyond that ceiling, split with the Team Principal into two independent streams, each with its own Pit Wall.

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

Why

Why greenfield is the best starting point

Greenfield projects are where RACE Programming's 4× throughput case is strongest: no legacy constraints, no existing team rituals to unlearn, no brownfield coordination overhead. The bottleneck from day one 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 this.

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 (ACE Software Engineer + AI Product) acts as both Pit Wall and Pit Crew. They author EUS, build prototypes, and execute.

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

Stage 2

Split roles, add crew

Still insufficient → add second engineer. AI Product serves both Pit Wall and Pit Crew. ACE SWE shifts to Pit Wall only (50% allocation).

When to move on: Still not enough throughput → promote ACE SWE to ACE TL, add Pit Crew 2. Evaluate AI Product coverage per crew.

Stages 3–5

Grow to 5 Pit Crews

One Pit Wall pair in ACE Technical Lead mode can serve up to 5 Pit Crews simultaneously. Allocation: 20% per Pit Crew.

Five Pit Crews = throughput equivalent 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.

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)

ACE Software Engineer (Pit Wall lead). Architecture decisions (ADR), prototype build, Pit Wall execution oversight.
AI Product. Gherkin acceptance scenarios, EPB management, EARS NFR, client communication.
Both 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)

AI Product (Context Manager) + 1–2 AI Fluent engineers.
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 must respond to prototype review and Pit Stop Demo within 1 day. This is 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? Run this calibration in Stints 1–2.
No direct Pit Crew contact. If Team Principal bypasses Pit Wall and tasks Pit Crew directly — intervene immediately. One 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.