RACE Programming
Reliable Agentic Coding Excellence. An Agentic SDLC Framework that is engineer-led, agent-executed. An integrated transformation of organizational structure, delivery process, and technological stack, derived from AI-First Theory and the AI-First Manifesto and pioneered at First Line Software. The AI-era realization: SDLC is no longer just a quality process. It is the skill of delivering ideas to production at the client's idea-generation speed: 2–3 days from idea to enterprise-grade production.
Agile, Scrum, XP were built to coordinate people
Agile, Scrum, and XP were built for one job: to coordinate people, to align a group around the customer's intent and keep them aligned, because every person is full, unpredictable complexity. Big teams, two-week sprints, and estimation rituals all exist to manage that human coordination problem.
The job changed. The team member we now coordinate is a Silicon Software Engineer, an AI agent. Different problem → different framework. The old defaults (big teams, two-week sprints, story-point estimation) were sized for coordinating humans and no longer fit.
So RACE Programming keeps the useful pieces and drops the whole; it does not reinvent the wheel. The parts of Agile that still serve delivery are retained; Agile as a holistic framework, built for a problem we no longer have, is what's replaced.
The Silicon Software Engineer
Not a tool. Not a co-pilot. A new team member, the AI agent. Design your process for this profile, because it behaves nothing like a human engineer. It is present in both the Pit Wall and the Pit Crew, and it does not add human headcount: a Pit Crew is still three people.
Strengths
Speed ×1000
Senior/mid-grade code in seconds. At this level it is economically indefensible not to use it.
Zero friction
Perfect obedience. No ego, no burnout, never argues. Zero autonomy in business decisions.
Tireless throughput
Works in parallel, around the clock. Many tasks at once, no fatigue, no context-switching cost.
Limits
Text-only
Works only on what's written. Mocks, video, voice: all media converts to text first.
Stateless
No memory across sessions. Starts blank every task. Precise, minimum-sufficient context, not excess.
No judgment
Compliance is not understanding. It executes a wrong spec exactly as written.
The bottleneck shifts
Execution is instant, so the constraint is now specification: the scarce skill is describing exactly what to build, precisely enough to delegate. Opting out is like stepping out of an F1 car to go hiking: you can't cover the distance anymore.
The Agentic Agile Manifesto
The four Agile values still hold, rewritten for teams where AI executes. The left column endures; the right is how AI-augmented teams actually deliver. The thread through all four is AI fluency: the ability to delegate to AI and validate its output, kept current as models change.
Read the Agentic Agile Manifesto: all four values, Classic 2001 → Agentic 2026 →
AI Fluency
A subscription to ChatGPT, Claude, or Gemini is access. Fluency is different, and the skill is cognitive, not technical.
Know your Silicon Engineer
What can it do, and what can it not? A new team member: 1000× faster at code, confident, stateless, no ego, no context beyond what you give it, no judgment on ambiguous specs. Fluency starts with mapping that profile accurately.
Calibrate your trust
Three constant questions: delegate without checking, delegate but verify hard, or not delegate at all? That cognitive map, kept current, is the skill.
Practice, not certification
Your calibration expires. Models update regularly; capabilities change, for better or worse. Behavior calibrated last month may not hold today. Fluency is ongoing practice, not a one-time adoption.
Three tiers, three speeds
F1 metaphor, not corporate hierarchy. Each tier protects the others' rhythm; discipline beats prohibition. Team Principal sets the pace; Pit Wall buffers; Pit Crew keeps the inner cycle intact.
Team Principal
Client's pace.
Vision, budget, acceptance (UAT); decides which races to run.
Strategy only · talks only to Pit Wall · the new bottleneck.
Pit Wall
Days.
Intent → AI-executable spec; prototype on synthetic data (1–2 days, before the Stint opens).
Stable handoff · no reimplementation of Pit Crew's work.
Pit Crew
Hours · 2×/day.
Build inside guardrails; QE owns the executable Gherkin (Chinese Wall).
Kanban, no sprints · never talks to Team Principal directly.
What the Pit Wall owes the client
Everyone pictures the Pit Wall working downward: intent in, specification out, code built. It works upward just as hard, and that half is what keeps the client from becoming the bottleneck.
- Deciding faster. Never one prototype. The Pit Wall brings two or three working options to every idea and every review, so the Team Principal chooses between things they can see rather than deciding against a blank page. AI makes the extra options nearly free, which is why one is no longer the right number. Those options often exist before the engagement does: the conversation happens in the language of a working prototype, built on synthetic data before or between the first calls.
- Accepting faster. The Pit Wall owns the Team Principal's review throughput, not just their availability. It brings automation and the agent into UAT itself, so the time from "ready for acceptance" to "live in production" shrinks. Sign-off is a delivery step the Pit Wall answers for, not something it waits on.
- Context continuity. The agent is stateless: it starts every task blank and remembers nothing from the last one. So the Pit Wall carries the project's memory across Stints, the domain glossary, the rationale behind decisions, and the architectural constraints. Without it every Stint reopens settled questions.
How a crew of three holds
- Domain is borrowed, not learned. The Pit Wall holds the long-lived subject-matter knowledge. The Pit Crew delegates the domain to the agent per task and governs what comes back. That is how a crew audits a three-hundred-page set of industrial standards and works credibly in a regulated account within days, instead of hiring for years of sector experience.
- Small is not fragile. Ownership stays separate, but skills deliberately overlap: AI Product can prototype, and a Pit Crew engineer can step into Pit Wall duties. Because the specification lives as code, a substitute picks up any ticket from the story itself: about fifteen minutes to get going for the originator, about thirty-five for a stand-in.
- Tokens are a delivery constraint. Running the agent costs money, so spending it well is an explicit discipline: scope the context, rotate sessions before limits, track burn per feature.
Who does what
The Pit Wall is the client-facing pair; the Pit Crew is the execution unit. The Silicon Software Engineer, the AI agent, works inside both. Three people plus AI tools deliver a nine-person Scrum team's output, with almost none of the ceremonies: no stand-ups, no planning poker. The retrospective is the one ceremony RACE kept, because inspect and adapt is how the framework came to exist.
Pit Wall
AI Product
- Co-authors the Executable Product Roadmap + Backlog with the Team Principal
- Authors NFR in EARS and the Gherkin acceptance tests in the EUS, and owns them as the test source of truth
- Key output: the Executable User Story, a minimum-sufficient spec AI builds without re-interpreting context
- Stays in the Pit Wall; never sits in the Pit Crew
- 50–100% per engagement
Forward Deployed Engineer
- Embedded in the client's business context (colocated or remote): turns business intent into an AI-executable spec and a working prototype
- Operates Cursor / Claude Code / agentic tools natively: prompts, reviews, iterates with AI
- Owns the full pipeline: requirements, architecture, CI/CD, observability
- Validation is the new senior skill: judging AI output beats producing it
- Primarily forward-deployed in the Pit Wall; can drop into the Pit Crew to execute alongside AI tools
- One per Pit Crew; 50–100% per engagement
Pit Crew
Pit Crew Quality Engineer
- Automates AI Product's Gherkin tests and applies expert quality judgement to agent output
- Owns test design and coverage; validates every AI output against it
- Sets the guardrails the AI agents cannot modify: a Chinese Wall between spec and execution
- Runs the AI-evaluation discipline: LLM-as-Judge, eval-driven development, golden datasets, hallucination/faithfulness checks
- Builds and configures the testing agents · one per Pit Crew
Pit Crew Software Engineer
- Implements against the EUS with AI tools
- Owns unit (≥ 80%), integration, and end-to-end coverage; prevents AI drift across Stints
- Executes inside the Quality Engineer's guardrails; never re-scopes mid-cycle
- 2 per Pit Crew
Present in both tiers
The Silicon Software Engineer
- Not a tool but a teammate: senior/mid-grade code in seconds
- Text-only, stateless between tasks, zero business autonomy
- Executes in both tiers: prototyping + spec with the Pit Wall, implementation under guardrails with the Pit Crew
- Adds no human headcount; multiplies what the people deliver
Role Transitions
Every old role has a path forward. Add AI fluency and expanded responsibility, and climb. Roles are absorbed and redrawn around what AI executes, not renamed. (The Team Principal is not shown here: that seat belongs to the Product Manager or the business customer, client-side, and it is not an engineering path.)
Once inside, the ladder keeps going: Pit Crew SWE → Forward Deployed Engineer and Pit Crew Quality Engineer → AI Product.
The proportions invert as you climb. The old engineering job was mostly translation: roughly eighty percent of the effort went into detailing an idea down to code, and only about twenty percent was creative. Now maybe two percent is the translation, delegated to the Silicon Software Engineer, and something like ninety-eight percent is the creative half: understanding the human need, exercising taste and judgement, working with other people. Orchestrating agents is itself creative work, because you can now build several architectures in parallel and see which one actually holds.
This is the moment to choose your branch: decide what you want to build creatively, and actively grow into the path that excites you most.
Executable User Story
The core unit of the Executable Product Backlog. Anyone can write a user story. Almost no one produces one that AI agents execute without re-interpreting context. The EUS gives AI minimum-sufficient context to execute without drift, in seven components:
User Story
Classic "As a [role], I want [outcome], so that [value]." The intent: what we're trying to achieve and for whom.
Acceptance / Gherkin
Functional behavior + acceptance criteria in Given/When/Then format. AI Product authors and owns these tests, the test source of truth; the Pit Crew Quality Engineer automates them as Playwright / unit / end-to-end gates and brings expert judgement to what the agent actually produced.
Working Prototype
Built on synthetic data, in a stand-alone module (not a branch of main). Shows the experience before implementation begins.
Architecture / ADR
Constraints captured as Architecture Decision Records, versioned with the code. Where this fits, why this choice. Prevents AI drift across Stints.
NFR / EARS
Measurable system constraints in EARS format, one of five sentence types: ubiquitous, event-driven, state-driven, optional, unwanted. "The system shall respond in under 200ms with 1,000 concurrent users." EARS, not Gherkin: a constraint written as Given/When/Then comes out untestable.
Test Data
Pit Wall declares what data is needed (client + synthetic). Pit Crew curates and stages the actual fixtures.
Estimate
Delivery cost in dollars, the client-facing component, not abstract Story Points. The date and cost the client approves before scope locks. The Pit Crew estimates, not the Pit Wall: the number comes from whoever will do the work, not from whoever wrote the spec. It is the one component that arrives on the way back, priced at handoff when the Pit Crew reviews the story.
Executable Product Roadmap + Backlog
Not a Gantt chart, not a Jira board, but a machine-readable delivery contract co-authored with the client.
Executable Product Roadmap (EPR)
The backlog projected onto Stints at the client's release cadence. Every item is an EUS package with a delivery date and an estimated cost. The client approves scope before budget commits, so there are no surprises. Pit Wall co-authors with Team Principal; revised each Stint.
Executable Product Backlog (EPB)
A prioritized stack of EUS refined to AI-executable quality. Priority = business importance × delivery cost (in dollars). Nothing enters the Pit Crew without all seven EUS components present. Pit Wall owns it; Pit Crew pulls. A single source of truth.
Everything as Code
If AI operates the SDLC, every artifact must be machine-readable and versioned in Git. RACE Programming places the Executable User Story as the upstream originating artifact across eight layers:
Executable User Story
User Story + Prototype + EARS + ADR + Tests + estimate. The upstream originating artifact.
Executable Product Backlog
Prioritized EUS stack, AI-ready.
Executable Product Roadmap
Backlog projected onto Stints at client release cadence.
Code
Every commit AI-assisted, reviewed for context fit.
Tests
AI-readable Playwright / unit suites, auto-generated.
Infra
Terraform / Pulumi. Pit Wall owns; Pit Crew operates.
Architecture
ADRs versioned with code. Pit Crew SWEs prevent AI drift.
Handover Doc
Agent-maintained: systems, environments, first-day scenarios.
Conversation Knowledgebase
An agent-maintained base spanning all eight: every client touch-point, decision note, call recording and agreement. The shared memory across Stints and team changes. If it's not in Git, it doesn't exist.
From idea to Pit Stop: the EUS lifecycle
The Pit Wall → Pit Crew handoff is a full artifact transfer, with no verbal context. All feedback is mediated by Pit Wall; Team Principal and Pit Crew never communicate directly.
Principal
What Pit Wall produces
Three executable artifacts. Pit Crew starts production work the moment it receives any one of them. Anyone can write a Product Vision; almost no one produces an Executable Product Backlog; that is what Pit Wall sells.
Executable Product Roadmap
Backlog projected onto Stints; the throughput (EUS / week) to buy each Stint.
Executable Product Backlog
Prioritized backlog ready for AI delivery; priority = importance × delivery cost.
Executable User Story
The hero artifact: User Story + Prototype + EARS + ADR + Gherkin + test data + estimate, giving minimum-sufficient context for AI to execute without drift.
What Pit Crew returns: the four-gate Definition of Done
Input: EARS + Gherkin + ADR + Prototype. Output: a demo of working software plus four green gates. All four green = EUS closed. No partial delivery. AI Product authors the EARS (NFR) and the Gherkin acceptance tests and owns them; the Pit Crew Quality Engineer automates and runs them, alongside the ADR, as Playwright / unit / integration / end-to-end gates, and brings expert quality judgement to the agent's output.
Gate 1 · Unit coverage ≥ 80%
Automated on every commit; the deterministic baseline and primary engineering investment. 80% is not a round number picked out of habit: it is the threshold past which agent-generated code becomes reliably verifiable without a human reading it line by line.
Gate 2 · Integration
Closed-loop; used where the integration point is the source of business risk.
Gate 3 · End-to-end
Full user journey; each test maps to a Given/When/Then scenario in the executable Gherkin owned by the Pit Crew Quality Engineer.
Gate 4 · Automated acceptance
Every Gherkin scenario in the EUS is a passing test. AI Product authors and owns those scenarios; the Pit Crew Quality Engineer automates and runs them. Formal closure of the acceptance contract.
Stint and Pit Stop
The Stint is the two-to-three-day iteration cycle in RACE Programming, replacing the two-week sprint of Scrum. Shorter cycles are required because stale plans are toxic context: AI executes against whatever context it is given.
Every Stint ends with a Pit Stop: a production deployment. That is why idea to production is measured in days, the length of one Stint.
Two to three days is the floor, not the ceiling: the fastest a Stint runs, and the pace the team holds by default. From that floor it stretches upward to whatever cadence the client can absorb, a week, a month, a quarter. The constraint is how fast the client can accept what ships, never how fast the team can build it.
| Event | Cadence |
|---|---|
| Inner cycle (Spec → Build → Align) | 2× per day |
| Pit Crew demo to Pit Wall | When an EUS is ready |
| One Stint | 2–3 days at the floor; stretches up to the client's cadence |
| Pit Stop (production deployment) | End of every Stint |
| UAT cycle | 2–3 days (~1 Stint) |
The triangle moves
Scope, time, budget: the three sides of every project. Quality is the area inside; it is not a lever, and you don't shrink it. So you only ever set two sides, and RACE Programming moves the third.
more finished software, for the same budget and the same deadline.
to a business result: each piece ships the moment it is ready, not gated to a sprint.
the same scope, on the same clock.
Where the numbers come from
The multipliers are not a claim to take on faith. They fall out of two team shapes, measured in Story Points purely so the two are comparable.
- Scrum team: 10 people delivering 400 Story Points per two-week sprint, so 200 points a week, at a cost of C per week.
- RACE team: 5 people, senior only, delivering the same 400 points in one week, so 400 points a week, at 0.75C. Fewer people, and each one costs about 1.5× more, yet the team is cheaper.
- Per dollar: the Scrum budget buys 1.33 RACE teams. 1.33 × 400 = 533 points a week against 200, which is the ~3× figure.
And the triangle is a floor, not a ceiling, the same way the Stint is. Past a point the constraint stops being engineering capacity at all and becomes client absorption: how fast demos get reviewed and UAT comes back. That is the number to watch once these multipliers are in hand.
Conservative figures, measured on delivered projects, not projections. Story Points appear only as an apples-to-apples ruler against Scrum; the client-facing unit is the Executable User Story, priced in dollars.
RACE Programming pioneered at First Line Software. Organizational structure, process, and technological stack built as an integrated system, not assembled from parts. First to prove the economics in production. The reference implementation.