Code Review Pipeline Simulator

How does review speed and thoroughness affect the value your team actually delivers to users?

This is a queuing + quality model. Coding creates work-in-progress (WIP); review drains it. Low diligence lets defects escape to production, which generates rework that eats into coding capacity. Both failure modes compound: more WIP → slower reviews → more WIP; more defects → more rework → less coding → fewer features. Exception: pairing (review delay < 0.1 weeks). When a reviewer is present during coding there is no queue — WIP cannot accumulate and the review bottleneck disappears. This is why pairing + AI is qualitatively different from async + AI. All assumptions are adjustable below. Show model assumptions ▾

Main Controls
Developers 4
Number of developers. Each person codes and reviews — reviewer capacity scales with team size. Coding output = team size × AI multiplier × baseline productivity.
1× — Human baseline 1.0×
How much faster AI makes each developer. 1× = no AI. 1.5–2× = AI-assisted (GitHub Copilot studies). 3–5× = heavy AI / agent-driven coding. Does not affect review capacity — reviewers still read the same amount of code.
0.5× slow1× human2× AI-assist5× AI-heavy
team × multiplier × baseline 4.0
Weeks from done to approved 0.5
How long a finished feature sits waiting for review. Below 0.1 weeks (~half a day) = pairing mode: reviewer is present during coding, so no queue can form — WIP accumulation is disabled entirely. 0.5 = fast async (2–3 days). 2–4 = very delayed.
Fraction of defects caught 0.80
Probability a defect is caught during review. 0.2 = rubber-stamp. 0.8 = careful async. 0.95 = pairing-level thoroughness.
Simulation
Weeks to simulate 26
Features Delivered to Users
Cumulative features reaching production over time
Time-to-Value
How long users wait for a completed feature (weeks)
Defects Shipped to Users / Week
Bugs reaching production — customer-visible harm
Rework Fraction
Share of engineering capacity consumed by bug fixing (not features)
About this model
What kind of model this is

This is a systems dynamics model — it represents the pipeline as stocks (WIP, incidents) and flows (coding rate, review throughput, defect escape) governed by differential equations, and simulates how they evolve over time. It is not an empirical study or a fitted statistical model. It produces qualitative insight — which levers matter most and why — not precise numerical predictions for your specific team.

Key modeling choices
  • Pairing suppresses queue accumulation entirely — when D < 0.1w, the reviewer is present during coding so no backlog can form; this is a qualitative regime change, not a quantitative improvement.
  • Rework uses human baseline capacity as denominator — AI speeds up code generation but incidents still pull humans off work; dividing by AI-inflated throughput would falsely show rework shrinking as AI speed rises.
  • Reviewer capacity scales with team size, not AI speed — reviewers read the same code regardless of how fast it was written; AI coding multipliers do not increase review bandwidth.
  • Bugs per feature is a fixed assumption — in practice it likely increases with PR size and AI coding speed; you can adjust it in the assumptions panel to test sensitivity.
What this model cannot tell you
  • — Coordination overhead as team size grows (Brooks's Law)
  • — PR batch size effects on review quality and delay
  • — Incident severity distribution (one P0 can dominate all metrics)
  • — The actual AI speed multiplier for your team and codebase
  • — Whether your reviewers can sustain review bandwidth under load
Every assumption in this model is adjustable. If a number feels wrong for your context, open Model Assumptions and change it — the model updates immediately. The goal is to make the assumptions explicit enough to argue with.
Tools and process

Visualization: D3.js v7 for charts and DOM rendering. Simulation: plain JavaScript Euler integration (dt = 0.1 weeks), running entirely in the browser with no server.

The model was designed in a structured three-step session with Claude before any UI was written:

  1. Surface candidates. The session examined the domain and listed candidate stocks, flows, parameters, and coupling relationships — then paused for a human to confirm, prune, and redirect. The decision to focus on business outcomes (features delivered, time-to-value, defects, rework) rather than engineering metrics came from that exchange.
  2. Derive the model. Each equation was derived from a named assumption by a visible reasoning step — nothing was asserted. The two reinforcing feedback loops (WIP accumulation, rework spiral) were traced explicitly. Three scenarios were verified numerically before any code was written.
  3. Build the interactive. Only after the equations were confirmed did the session produce the UI — sliders, charts, and metric cards were built to expose the already-derived model, not to shape it.

Subsequent sessions refined the model in response to questions from early readers — including the pairing queue-suppression fix, the rework denominator correction, and this colophon.