What does the Pit Wall do?

It converts business intent into something an AI agent can build without re-interpreting it. The Pit Wall co-authors the Executable Product Roadmap and Backlog with the Team Principal, produces the Executable User Story (the minimum-sufficient spec), stands up a working prototype for the client to validate before production code is written, and hands the stable spec to the Pit Crew. It also buffers pace, absorbing the Team Principal’s changes so the Pit Crew can execute against a settled spec.

When does the Pit Wall step back?

When the frame of the solution is set: the business and technical answer to the client's problem, shown in prototypes and a phased plan the client agrees with. The Pit Wall keeps transfer notes from day one, so at that point it brings in the Pit Crew, onboards it and reduces its time. AI Product stays with the engagement; the Forward Deployed Engineer stays part-time, mostly on architecture and oversight.

How does the Pit Wall accelerate the Team Principal?

Because an AI-native team can produce software faster than the client can ideate and accept it, the Team Principal (their approvals and sign-offs) becomes the bottleneck that sets the pace. The Pit Wall resolves this on two fronts: ideation enablement, bringing 2-3 prototype options to each idea so decisions come faster, and acceptance enablement, bringing automation and AI teammates into acceptance testing (UAT) and owning review throughput so sign-off does not become the constraint. The delivery team adjusts to the client's speed and helps the client go faster, rather than expecting the client to keep up.

What is the difference between the Pit Wall and the Pit Crew?

The Pit Wall is the client-facing tier that specifies the work; the Pit Crew is the execution unit that ships it. The Pit Wall turns intent into an Executable User Story and a prototype. The Pit Crew (a Pit Crew Quality Engineer and Pit Crew Software Engineers, with the Silicon Software Engineer) takes that spec and delivers production software, story by story, through the Definition-of-Done gates. Explicit role boundaries stop the Pit Wall from reimplementing and the Pit Crew from re-scoping.

How does the Pit Wall map to Scrum roles?

The AI Product role collapses several Scrum roles, Product Owner, Business Analyst, Project Manager, UX, Test Lead, and Scrum Master, into one AI-native role. The Forward Deployed Engineer is a client-facing engineer with full SDLC ownership, closest to a lead engineer embedded with the client. There is no separate Scrum Master ceremony owner: coordination overhead built to synchronize a 7-9 person team is removed, because a small AI-augmented team does not need it.

Audio brief · 2 min

By Pavel Khodalev, CTO at First Line Software · July 29, 2026

Glossary · Definition

What is the Pit Wall in software delivery?

The Pit Wall is the client-facing tier of RACE Programming. It does Forward Deployed Engineering: two roles, a Forward Deployed Engineer and an AI Product, carried by one person or more, who sit with the business, turn its intent into an executable specification and a working prototype, set the frame of the solution, and hand a stable spec to the Pit Crew that ships it.

Where it sits

The three tiers

RACE Programming organizes delivery into three tiers, named after a racing team: Team Principal → Pit Wall → Pit Crew.

Team Principal (the client) owns product direction and decides what is worth building. In racing terms, they set the pace; their approvals are the new bottleneck.
Pit Wall is the client-facing tier, two roles that do Forward Deployed Engineering. It sits between direction and execution, calling strategy: translating what the business needs into what an AI agent can build.
Pit Crew is the execution unit that takes the specification and ships production software, story by story, released at each Pit Stop.

All contact is via the Pit Wall, and that holds for the work on the product. When several teams are involved, the expectations, awareness and alignment around the Team Principal (stakeholders, neighboring teams, outside resources, the sponsor) are coordinated by the TPM, who sits beside the Pit Wall, not inside it. Ideation and acceptance throughput with the Team Principal stay with the Pit Wall.

The name is deliberate. On a real pit wall, the strategists sit between the team owner and the crew in the garage, reading the race and calling the timing. The RACE Programming Pit Wall does the same: it buffers the Team Principal’s changes so the Pit Crew can execute against a settled spec.

The point of it

Accelerating the Team Principal

An AI-native team can now produce software faster than the client can ideate and accept it. That moves the constraint to the Team Principal: their own stakeholder approvals and sign-offs, not the delivery team, set the pace. Resolving that bottleneck is a core Pit Wall responsibility, on two fronts.

Ideation enablement. The Pit Wall brings 2-3 prototype options to each idea or review. Options help people decide faster, so the Team Principal can direct the work without stalling on a blank page.
Acceptance enablement. When the Team Principal is slowed by acceptance testing (UAT), the Pit Wall brings automation and AI teammates into the review and owns review throughput, so sign-off moves quicker instead of becoming the constraint.
Context continuity. The Silicon Software Engineer is stateless: it starts every task blank and carries nothing from the last one. The Pit Wall is the project's memory across stories and releases, holding the domain glossary, the rationale behind decisions and the architectural constraints. Without it, every new story reopens settled questions and the agent drifts from the architecture it agreed to.

The orientation is deliberate: the delivery team adjusts to the speed of the client and helps the client go faster, rather than expecting the client to keep up with the team.

The roles

Who is in the Pit Wall

Two human roles, both working with the Silicon Software Engineer, the AI agent present across the framework, which does not add human headcount. Roles are not people: one person can carry both, or several people can share them. The specification and the prototype belong to the Pit Wall as a whole, not to one role.

Forward Deployed Engineer, the engineer among the Pit Wall roles. Embedded in the client’s business context, they bring the engineering side of the work: they check feasibility, operate agentic tools natively (Cursor, Claude Code), and own the full pipeline: requirements, architecture, CI/CD, observability. Validation, judging AI output, is their senior skill. They also build and keep evolving the engagement’s delivery machinery, the agents, workflows and guardrails that let software get built without a human Pit Crew in the loop. The profile: a strong developer and technical lead with people skills. Across engagements, the RACE Engineer, the most senior form of the role, keeps evolving that machinery, rolls it out into engagements and helps each Pit Wall adopt, tune and improve it. The role is part-time and on request, like DevOps; its north star is one shared product across the organization. (Formerly the ACE Software Engineer; renamed to match the industry-standard Forward Deployed Engineer role.)
AI Product, which collapses Product Owner, Business Analyst, PM, UX, and Scrum Master into one AI-native role. It co-authors the Executable Product Roadmap and Backlog with the Team Principal and authors the Executable User Story, the minimum-sufficient spec an agent builds without re-interpreting intent.

The job

What the Pit Wall does

The Pit Wall does Forward Deployed Engineering: it converts business intent into something an AI agent can build without guessing. Its work is upstream of code:

Specification. Produce the Executable User Story: user story + working prototype + NFR (EARS) + architecture (ADR) + acceptance (Gherkin) + test data + a delivery estimate.
Prototype-first validation. Stand up 2-3 working prototype options so the client validates intent, and decides faster, before a line of production code is written.
Buffering pace. Absorb the Team Principal’s changes and hand the Pit Crew a stable spec, so execution runs against a settled target.
Pipeline ownership. Own the engagement end to end, never reimplementing the Pit Crew’s work and never letting the Pit Crew re-scope.

The frame and the handover

When the Pit Wall steps back

Forward Deployed Engineering has a result and an end. The result is the frame of the solution: the business and technical answer to the client’s problem, what used to be called solution architecture. In RACE terms it is the prototype the Team Principal accepted, the Executable Product Roadmap and the architecture decisions behind them, with a plan to implement it phase by phase and an indicative cost of the next phases.

Ready to hand over. Transfer notes are kept from day one, so the work can change hands at any moment.
The transition. Once the frame is set, the Pit Wall brings in the Pit Crew, onboards it and steps back.
After the handover. AI Product stays with the engagement and keeps authoring Executable User Stories; the Forward Deployed Engineer stays part-time, mostly on architecture and oversight.

Short engagements can run start to finish on the Pit Wall. Longer ones move to a Pit Crew once the frame is set, because holding the people who did the forward deployed work at full time until production is a poor use of scarce talent.

The Pit Wall is one tier of RACE Programming. See how it works with the Team Principal and Pit Crew from idea to Pit Stop.

Read the framework → · What is an agentic SDLC? → · Forward Deployed Engineering: the activity and the role → · RACE Programming vs Scrum →

FAQ

Frequently asked questions

What is the Pit Wall in software delivery?: The Pit Wall is the client-facing tier of RACE Programming, an AI-native software delivery framework. It has two human roles, a Forward Deployed Engineer and an AI Product, carried by one person or more. Together they do Forward Deployed Engineering: they sit with the business, take its problem apart, turn its intent into an executable specification and a working prototype, set the frame of the solution, and hand a stable spec to the Pit Crew that ships it. The name comes from motor racing, where the pit wall is where strategy is called: it sits between the Team Principal, who owns direction, and the Pit Crew, who execute.
Who is in the Pit Wall?: Two human roles working with the Silicon Software Engineer (the AI agent). Roles are not people: one person can carry both, or several people can share them. Together the roles do Forward Deployed Engineering, and the Pit Wall as a whole turns intent into an AI-executable spec and a working prototype. The Forward Deployed Engineer brings the engineering side: embedded in the business context, they own feasibility and the full pipeline (requirements, architecture, CI/CD, observability). They also build and keep evolving the engagement's delivery machinery, so software gets built without a human Pit Crew in the loop; the profile is a strong developer and technical lead with people skills. The AI Product collapses Product Owner, Business Analyst, PM, UX, and Scrum Master into one AI-native role and authors the Executable User Story. Neither sits in the Pit Crew.
What does the Pit Wall do?: It converts business intent into something an AI agent can build without re-interpreting it. The Pit Wall co-authors the Executable Product Roadmap and Backlog with the Team Principal, produces the Executable User Story (the minimum-sufficient spec), stands up a working prototype for the client to validate before production code is written, and hands the stable spec to the Pit Crew. It also buffers pace, absorbing the Team Principal’s changes so the Pit Crew can execute against a settled spec.
When does the Pit Wall step back?: When the frame of the solution is set: the business and technical answer to the client's problem, shown in prototypes and a phased plan the client agrees with. The Pit Wall keeps transfer notes from day one, so at that point it brings in the Pit Crew, onboards it and reduces its time. AI Product stays with the engagement; the Forward Deployed Engineer stays part-time, mostly on architecture and oversight.
How does the Pit Wall accelerate the Team Principal?: Because an AI-native team can produce software faster than the client can ideate and accept it, the Team Principal (their approvals and sign-offs) becomes the bottleneck that sets the pace. The Pit Wall resolves this on two fronts: ideation enablement, bringing 2-3 prototype options to each idea so decisions come faster, and acceptance enablement, bringing automation and AI teammates into acceptance testing (UAT) and owning review throughput so sign-off does not become the constraint. The delivery team adjusts to the client's speed and helps the client go faster, rather than expecting the client to keep up.
What is the difference between the Pit Wall and the Pit Crew?: The Pit Wall is the client-facing tier that specifies the work; the Pit Crew is the execution unit that ships it. The Pit Wall turns intent into an Executable User Story and a prototype. The Pit Crew (a Pit Crew Quality Engineer and Pit Crew Software Engineers, with the Silicon Software Engineer) takes that spec and delivers production software, story by story, through the Definition-of-Done gates. Explicit role boundaries stop the Pit Wall from reimplementing and the Pit Crew from re-scoping.
How does the Pit Wall map to Scrum roles?: The AI Product role collapses several Scrum roles, Product Owner, Business Analyst, Project Manager, UX, Test Lead, and Scrum Master, into one AI-native role. The Forward Deployed Engineer is a client-facing engineer with full SDLC ownership, closest to a lead engineer embedded with the client. There is no separate Scrum Master ceremony owner: coordination overhead built to synchronize a 7-9 person team is removed, because a small AI-augmented team does not need it.

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