RACE Programming
By Pavel Khodalev · · Updated · framework · prescription · agile · 6 min

Prescriptive, not permissive

When Ken Schwaber and Jeff Sutherland formalized Scrum, they made a deliberate choice: they made it permissive. Scrum says there is a Product Owner, there is a Sprint, there is a Daily Scrum, and then it stops, handing the implementation details to the team. RACE Programming makes the opposite choice: it is a prescriptive framework. Same category, opposite stance on how much it leaves to chance.

Scrum’s permissiveness was correct for its moment. In 2001, when the Agile Manifesto was signed, code production was the bottleneck in software delivery. Teams varied wildly in context (embedded systems, enterprise Java, web apps), and any framework prescriptive enough to be useful for one context would be wrong for another. Permissiveness was a feature.

What changes when the bottleneck moves

RACE Programming makes a different claim: the bottleneck has moved. Not gradually, but in a single generational shift between the release of GPT-4-class models and the broad availability of AI coding systems that can implement, verify, and iterate on production code. Specifically, as argued in Theorem 1 and Theorem 3, the cost of writing code has fallen dramatically (coding speeds up ~20x), while the work of specifying what to write and verifying what was written has not.

The consequence is that permissive frameworks no longer work. Here is the pattern organizations discover when they try to stay process-agnostic:

  • They add AI coding tools to an existing Scrum process.
  • They measure developer productivity by lines of code per sprint.
  • The metric goes up by 30%. They declare partial victory.
  • The team output, measured in business value shipped, goes up by 5–15%.
  • The variance between teams explodes.
  • Six months later, they conclude “AI helps but not as much as the hype suggested.”

What happened is not that AI failed to deliver. What happened is that the team adopted the cheap, visible part of the shift (code-generation tooling) without adopting the expensive, invisible parts (role compression, specification discipline, verification-first workflow, context curation). In a permissive adoption, you cannot tell which parts are optional, so teams naturally optimize for the ones that produce visible short-term metrics.

Why half-adoption produces less than half the benefit

RACE Programming’s central claim is that its disciplines are not separable. The productivity gain validated at First Line Software, ~3× the output per dollar of a traditionally-organized team, requires all of the following:

  • A three-tier team structure (Team Principal → Pit Wall → Pit Crew)
  • Executable User Stories as the originating artifact, not as optional annotation on a ticket
  • Mandatory verification gates for AI-executed code, not as a preference
  • One-week Stint cycles ending in Pit Stops (production deployments), because stale context is toxic context
  • Everything as Code including the specification itself
  • A context-curation discipline that runs continuously, not per-ceremony

A team that implements four of these six does not get two-thirds of the benefit. It gets a small fraction, often less than 1.5× over baseline, because the disciplines are complements: each one covers a failure mode that the others would expose. Drop verbalization discipline and the AI generates the wrong thing fast. Drop the verification gates and the AI generates plausible-looking wrong things that pass review. Drop context curation and the AI makes decisions based on stale assumptions from last week’s architecture.

A framework that permits teams to skip any of these has built in a failure mode. That is the case against permissiveness, not against frameworks.

The choice is about prescription, not labels

This is why RACE Programming is published as a prescriptive framework. Not because prescription is intrinsically better; it is not, in general. Prescription is right here because the specific disciplines needed to realize the economic shift are tightly coupled, and permitting partial adoption guarantees partial failure.

That does not mean RACE Programming is rigid. It can be contextualized (team size above three, domain-specific acceptance criteria templates, integration with existing corporate Agile reporting), but the core disciplines are not negotiable. A team that wants to modify them is free to; it just isn’t doing RACE Programming anymore.

This is also why Agile has been drifting toward prescription for years. The Scrum Guide has been revised downward in size, but its prescriptions have gotten sharper. SAFe is more prescriptive than Scrum. LeSS is more prescriptive than Scrum. The industry has been drifting toward prescription as the complexity of delivery has grown. RACE Programming formalizes what that drift looks like in the AI-native era.

What this means for adopters

If your team likes choosing which elements of a framework to implement, RACE Programming is not the right match. Stay with Scrum or a scaled variant, and expect modest AI-augmentation gains in the 1.2–1.5× range.

If your team is willing to adopt a prescriptive framework in exchange for the ~3× production outcomes validated at First Line Software and documented in Theorem 3, then the prescriptions above are the ones. They are not a menu.

The permissive era of Agile was the right fit for its time. The prescriptive era is the right fit for this one.

Written by Pavel Khodalev, author of RACE Programming and CTO of First Line Software. Follow new essays via RSS.