Beliefs deserve
pressure.

Name

No Faster Than Understanding — Team Operating Model Experiment

Purpose

Test whether a team can use AI-assisted engineering to reduce delivery time without increasing review burden, rework, production risk, or loss of system understanding.

The experiment is not intended to prove that AI is good or bad.

It is intended to discover where the constraint moves when implementation becomes cheaper.

Primary question

When code is no longer the main scarce resource, what becomes the limiting factor in our engineering system?

Likely candidates include:

• product decision latency;
• review capacity;
• CI feedback;
• environment availability;
• system understanding;
• coordination;
• production verification.

The experiment should expose these constraints rather than hide them.

Duration

Recommended execution:

Preparation / historical baseline: 1–2 weeks
Experiment:                      6 weeks
Final synthesis:                 1 week

If reliable historical data already exists, do not delay the experiment only to manufacture a new baseline.

Scope

Start with one team and one meaningful product or platform value stream.

Prefer a scope where the team:

• owns production;
• can deploy frequently;
• can observe outcomes;
• performs normal maintenance and feature work;
• already has at least basic automated validation.

Avoid beginning with a one-off greenfield prototype where normal coordination and maintenance costs are absent.

Hypotheses

H1 — Low WIP will matter more as AI increases execution capacity

If AI reduces implementation time, increasing the number of simultaneous tasks will create queues downstream.

Expected signal:

• WIP remains flat or decreases;
• queue time decreases;
• throughput can increase without proportional review congestion.

H2 — Smaller batches will reduce AI-induced review amplification

If authors constrain AI-generated work into small independently reviewable changes, reviewer effort should not grow in proportion to generation capacity.

Expected signal:

• smaller change size;
• lower review wait;
• lower review amplification;
• no increase in escaped defects.

H3 — Tight XP feedback loops will constrain AI errors earlier

If agents operate through tests, CI, contracts, and frequent integration, incorrect assumptions should be discovered closer to creation.

Expected signal:

• more failures found before review or production;
• less late rework;
• shorter time from incorrect change to corrective feedback.

H4 — Explicit assumptions will reduce confident but invalid implementations

If important assumptions are recorded and validated, the team should identify more invalid premises before they become expensive changes.

Expected signal:

• assumptions converted into tests/contracts/observability;
• fewer incidents or rework items caused by hidden assumptions.

H5 — AI will move the bottleneck rather than eliminate it

Expected signal:

A constraint becomes visibly dominant in one or more of:

problem definition
review
CI
environment
product validation
deployment
production learning

Finding the new constraint counts as a useful result even if throughput does not increase.

Experimental changes

During the experiment, apply the following operating policies.

1. Use pull instead of pushing new work into the system.
2. Keep explicit WIP limits.
3. Prefer trunk-based development.
4. Prefer changes that can be integrated within hours rather than days.
5. Use feature flags or compatibility techniques when incomplete work must coexist with production.
6. Keep AI work inside technical feedback loops.
7. The author remains responsible for reviewability and understanding.
8. Important assumptions are made explicit when they materially affect correctness or architecture.
9. Production feedback is part of the change, not an optional postscript.
10. AI usage itself is not a performance metric.

What remains uncontrolled

This is an engineering-system experiment, not a laboratory experiment.

Do not attempt to artificially control:

• exact prompt style;
• exact AI model;
• number of AI interactions;
• individual developer AI preference;
• task complexity;
• production incidents unrelated to the experiment.

Record major confounders instead of pretending they do not exist.

Success criteria

Do not define success as "AI increased velocity."

Consider the experiment promising if, compared with the available baseline:

• median cycle time improves or stays stable;
• review queue time does not materially worsen;
• batch size decreases;
• escaped defects and change failure rate do not materially worsen;
• rework does not materially worsen;
• team reports no material loss of system understanding;
• at least one previously hidden system constraint becomes measurable;
• the process does not require significant new manual bureaucracy.

A throughput increase is valuable only if it does not externalize cost into another part of the system.

Failure criteria

Treat the experiment as failing or requiring redesign if one or more persist:

• review becomes the dominant queue and keeps growing;
• generated work repeatedly exceeds team comprehension;
• change failure or rework rises materially;
• WIP expands because agents can "keep working";
• engineers become reviewers/operators of code they cannot explain;
• artifact maintenance becomes a significant portion of engineering time;
• metrics are gamed as individual productivity measures;
• product learning does not improve despite increased implementation output.

Stop-the-line conditions

The team may suspend part of the experiment if:

• production risk materially increases;
• a critical incident reveals insufficient ownership or understanding;
• a security or compliance requirement conflicts with the operating model;
• the team cannot reliably reproduce or validate agent-produced changes;
• a metric is being used to rank individual engineers.

Stopping is evidence, not failure.

End-of-experiment output

The final result must separate:

Observed

What actually happened.

Inferred

What we think explains the observation.

Unproven

What remains plausible but unsupported.

Adopt

Practices worth keeping.

Modify

Practices worth another iteration.

Reject

Practices that did not justify their cost.

Do not update the manifesto automatically from the experiment results.