From Async Code Reviews to Co-Creation Patterns
Dragan StepanoviΔ (published via Ben Linders / InfoQ) Β· article Β· 2026-06-01 source β Reader π₯οΈ
Pull-Request-based async code review forces teams to trade off quality against throughput β small PRs incur exponentially worse wait-time-per-size and large PRs degrade reviewer engagement β and the only way out of the trade-off is to make code review continuous and synchronous via co-creation patterns (Pair and Mob Programming), which drive the transaction cost toward zero and let teams have both throughput and quality.
practical Β· argumentative β StepanoviΔ argues for adopting Pair/Mob programming over PR-based async review. Uses theoretical scaffolding (Lean, Theory of Constraints, Little's Law, DORA) and empirical data (40,000+ PRs across 40+ repos) to back a prescriptive recommendation. The ultimate aim is action: change how teams work.
Structure
| Part | Role |
|---|---|
| Historical framing of PRs | context |
| Description of async PR workflow (Ema and Luka) | context / narrative setup |
| Study on 40,000+ PRs from 40+ repos | evidence |
| Big PRs inhibit building in quality (LGTM syndrome, sunk-cost, context decay) | argument step 1 β one horn of the dilemma |
| Benefits of small PRs (DORA metrics) | argument step 2 β apparent escape from horn 1 |
| Small async PRs have lower throughput (wait time and flow efficiency curves) | argument step 3 β second horn of the dilemma |
| Inventory expands to match transaction cost (Lean / Reinertsen / shipping analogies) | mechanism / theoretical scaffold |
| Little's Law and WIP inflation (Ema pulling more work while waiting) | mechanism extension |
| Co-creation patterns introduction (Pair, Mob) | prescribed alternative |
| BOTH throughput AND quality (DORA stability+throughput parallel) | conclusion |
| Common misconceptions (remote β async, schedule flexibility, learning curve, Woody Zuill workshop anecdote) | defense against objections |
| Summary | restatement |
Key terms
- Async code review Pull Requests & Async Code Review
Code review where the author finishes a batch of work, raises a PR, and waits for a separate reviewer to provide feedback at some later time β a workflow whose defining property is the time delay between authoring and feedback - Co-creation patterns Pair & Mob Programming
Pair and Mob Programming β ways of working where multiple people start together, work together, and finish together on the same problem at the same time; the defining property is continuous, in-context, synchronous review folded into authorship - PR batch transaction cost Pull Requests & Async Code Review
The cost (real or perceived) of pushing a batch of work through the code review stage β when high, it incentivizes batching more inventory in front of the stage (bigger PRs) - Wait time per size Pull Requests & Async Code Review
The PR queue time normalized by lines-of-code changed β empirically observed to grow exponentially as PR size shrinks under async review - Flow efficiency DORA & Engineering Metrics
Time spent actively working on an item as a percentage of its total lead time; under async with small PRs the wait component balloons and flow efficiency takes a nosedive - LGTM syndrome Pull Requests & Async Code Review
The pattern where reviewers, facing a large PR they cannot meaningfully steer, capitulate and approve with 'Looks Good To Me' rather than do the costly work of substantive review - WIP (Work In Process) DORA & Engineering Metrics
Items started but not finished; the author notes that under async, real WIP is typically 2x or more the visible WIP because each waiting author pulls in additional work - Little's Law DORA & Engineering Metrics
Average cycle time = average WIP / average throughput; invoked to explain why the WIP inflation caused by async review structurally degrades cycle time - Quality-enabled speed Lean & Toyota Way
The state where building in quality is not a cost paid against speed but a precondition for it β achievable when course correction happens at the smallest possible unit of change - DORA metrics DORA & Engineering Metrics
Deployment Frequency, Lead Time for Changes, Change Failure Rate, Time to Restore Service β the author cites DORA's stability-AND-throughput finding as parallel to his own throughput-AND-quality claim - You Burn, I'll Scrape Lean & Toyota Way
Deming's metaphor for make-and-inspect systems where authorship and inspection are separated; the author uses it to characterize the incentive structure of async review and contrast with co-creation - Flow resiliency
The team's ability to keep work flowing despite individual unavailability β when pairing breaks down because one person is unavailable, the answer is to add more people to the session (mob), not to revert to async
Propositions
- explicitestablishedPR-based async code review forces a trade-off between throughput (favors big PRs) and quality (favors small PRs) that cannot be escaped within the async paradigm.conf: highsupports βHow AI will change software engineering Β· p6 β Independently corroborates the code-production-outpaces-review-capacity bottleneck with a different named source (Frank Licea vs. that document's sources).supports βHow AI will change software engineering β with Martin Fowler Β· p8 β Orosz's observation that AI inflates code volume faster than reviewers can stay vigilant corroborates, from a different angle, the claim that PR-based review's throughput/quality trade-off breaks down under volume; this video does not offer the co-creation alternative that doc proposes.
- explicitcorroboratedAs PR size decreases, wait-time-per-size grows exponentially under async review.conf: highsupports βPair Programming Fixed Our Pull Request Bottlenecks Β· p3 β The guest explicitly cites Dragan StepanoviΔ's research on PR wait-time-per-size as the framework for understanding their own near-zero (2-3 second) review overhead under pairing β an explicit, named cross-reference between these two sources.
- explicitdevelopedLarge PRs reduce reviewer engagement per line of code, leading to 'LGTM syndrome' and unsteered code reaching main.conf: highextends βGrafana's gcx and MCP Server Reach GA for Telemetry-Driven Agent Development Β· p6 β Extends 'LGTM syndrome' into the agentic-coding context specifically, and proposes dashboard links as a concrete (if unvalidated) remedy for reviewer disengagement rather than only naming the failure mode.
- explicitcontestedInventory (PR size) in the system expands until it matches the transaction cost of review β making the cost of review the upstream cause of large batches.conf: highextends βThe Acceleration Whiplash Β· p7 β Faros's data (PR size up 51.3%, median review time up 441.5%) is a real-world instance of the 'inventory expands to match review transaction cost' dynamic that the async-review critique predicts.contradicts βGitHub Brings Stacked Pull Requests to Public Preview Β· p8 β The corpus argues PR size is endogenous β it expands to match the transaction cost of review β so merely enabling smaller PRs via stacking doesn't remove the upstream cause; the InfoQ piece treats size reduction as the fix rather than a symptom.
- explicitcorroboratedPair and Mob Programming reduce review transaction cost to effectively zero, dissolving the throughput/quality trade-off.conf: highsupports βSoftware Teaming: A Mob Programming, Whole-Team Approach Β· p13 β Same claim from the originating source: continuous whole-team review collapses the review step's transaction cost toward zero.
- explicitcorroboratedUnder async review with even modest delay (e.g. 10 min author work, 2 hour reviewer response), flow efficiency drops to ~7.7% β work is waiting 92.3% of its lead time.conf: highsupports βWhy your team doesn't need to use pull requests Β· p4 β Morris's informal 30-min-vs-minutes delay comparison is the same mechanism the later article formalizes into a ~7.7% flow-efficiency figure under modest async delay.
- explicitReal WIP on async teams is typically 2x or more the visible WIP because each author waiting on review starts new work.conf: high
- explicitTeams that co-create experience at least an order of magnitude less rework, bugs, and production problems than teams using async PR review.conf: medium
- explicitCo-creation reduces processing time (not just wait time) because peers contribute faster solution paths.conf: medium
- explicitRemote work and async work are orthogonal β teams can be remote AND co-create.conf: high
- explicitcorroboratedWhen a team cannot make pairing work due to schedule slippage, the correct response is to add people to the session (mob) for flow resilience, not to revert to async.conf: highsupports βReinventing team flow within AI uncertainty Β· p6 β Both treat pairing/ensemble work as a team-level practice under pressure from AI-era changes to flow, rather than an individual productivity technique.
- explicitThe argument 'code should be reviewed by someone not involved in the building' is a disadvantage masquerading as an advantage β out-of-context delayed feedback is empirically lower-quality than in-context immediate feedback from the same reviewer.conf: high
- explicitcorroboratedPR workflows were invented for open-source contexts (asynchronous strangers, intermittent maintainer attention) whose optimization targets do not match those of product development teams.conf: highsupports βWhy your team doesn't need to use pull requests Β· p1 β Both independently locate the root problem in the same historical mismatch: PR workflows were built for asynchronous strangers (open source), not product teams with shared norms.
- implicitcorroboratedContinuous code review (built into authoring) is a strictly stronger form of review than delayed batch review, because the same human eye supplied earlier produces equal-or-better feedback with lower integration cost.conf: highsupports βSoftware Engineering at Google Β· p3 β Henderson's 2017 observation that review is most effective done as code is developed (not afterward) is the same claim later generalized and argued more rigorously as 'continuous review is strictly stronger than delayed batch review.'
- implicitestablishedThe primary purpose of code review is to build in quality and accelerate learning β not to gate, audit, or enforce separation-of-duties.conf: highsupports βSoftware Engineering at Google Β· p4 β Henderson's author-chosen-reviewer, review-during-development model treats review as a quality/learning mechanism rather than a gate β consistent with the later proposition that review's primary purpose is building in quality and accelerating learning, not gating.supports βNo Vibes Allowed: Solving Hard Problems in Complex Codebases β Dex Horthy, HumanLayer Β· p10 β Both sources converge on the same reframe: the primary purpose of review is building in quality and team alignment/learning, not gating or correctness-auditing in isolation.supports βUsing AI to write better code more slowly Β· p7 β Lawson's description of review-as-a-side-quest that teaches him a codebase's failure modes is a first-person instance of code review functioning as a quality-building, learning-accelerating practice rather than a gate.
- explicitcontestedBehavior in software teams is governed by the system's incentive structure, not by individual virtue; therefore exhortations to write smaller PRs without changing review cost will fail.conf: highcontradicts βGitHub Brings Stacked Pull Requests to Public Preview Β· p8 β The InfoQ piece assumes shrinking PR size (via stacking) is sufficient to relieve review load; the corpus's systems-dynamics analysis argues explicitly that exhortations to write smaller PRs will fail unless the underlying transaction cost of review itself changes.
- explicitAsync review structurally suppresses refactoring and incremental development because the transaction cost makes small atomic changes economically irrational.conf: high
Arguments
Async code review forces an unwinnable trade-off between throughput and quality. strength: high
Explicit premises:
- Big PRs degrade reviewer engagement per size and produce LGTM-syndrome merges (quality loss).
- Small PRs under async review incur exponentially growing wait-time-per-size and collapsed flow efficiency (throughput loss).
- Both observations are persistent across 40+ repositories and 40,000+ PRs.
Implicit premises:
- Engagement-per-size is a valid proxy for review quality.
- Wait-time-per-size is a valid proxy for throughput loss.
- The two failure modes are the only available regions on the async curve β there is no goldilocks PR size that escapes both.
Inferences:
- Optimization within the async paradigm is structurally limited; the paradigm itself must change.
- Teams reporting 'we're doing PRs well' are likely operating at the throughput-loss end or the quality-loss end without noticing.
Reducing PR review transaction cost toward zero (via Pair/Mob) is the only way to recover small batches without losing throughput. strength: high
Explicit premises:
- Inventory expands to match transaction cost (Lean / Reinertsen).
- Pair/Mob make reviewer availability immediate and review cost effectively free.
- Therefore optimal batch size shrinks to ~1 line of code.
Implicit premises:
- Reducing transaction cost via tooling/automation alone (e.g. faster CI, AI-assisted review) cannot match the cost reduction achieved by physical co-presence β this is not argued but assumed.
- Human availability is the dominant cost driver in review, not artifact comprehension time.
Inferences:
- Any intervention that reduces review wait time without changing the work model (e.g. SLAs on PR response) is a partial fix that will plateau before reaching the co-creation regime.
- AI-assisted review, if it provides immediate in-context feedback, may be a partial substitute for human co-creation on the transaction-cost axis.
Co-creation delivers BOTH throughput AND quality (not a trade-off). strength: medium
Explicit premises:
- DORA research showed stability and throughput have an AND relation, not OR.
- Co-creation eliminates wait time AND reduces processing time AND reduces rework.
- Pair/Mob reduce WIP from ~2N (async) to 2 (pair) or less (mob).
Implicit premises:
- The DORA finding (stability+throughput AND-relation) generalizes to throughput+quality β these are treated as analogous without argument.
- The reduction in rework outweighs the doubled (or higher) people-cost of pairing/mobbing β an economic claim never quantified.
Inferences:
- Teams measuring developer productivity by lines/PRs per individual will systematically under-credit co-creation.
- If rework reduction is an order of magnitude, even pair programming at 2x people-cost is net positive on throughput.
Objections to co-creation (schedule flexibility, remote work, individual preference) are mostly mis-framed and dissolve under closer inspection. strength: medium
Explicit premises:
- Remote and async are orthogonal β co-creation works remotely.
- Schedule slippage signals low flow resilience, not a need for async β mob increases resilience.
- Failed pair/mob attempts are typically failures to learn the practice, not failures of the practice (Woody Zuill anecdote).
Implicit premises:
- Five hours of working-hours overlap is achievable for most teams β author asserts as a 'good target' without defending.
- Individuals who prefer solo work after genuine exposure are rare enough to treat as edge cases.
Inferences:
- Distributed teams across many time zones either need restructuring or are accepting a real cost.
- 'This isn't for us' is often premature β but the author allows it as a legitimate landing point.
Narratives
- Ema and Luka β Ema raises a PR, Luka is busy, Ema starts something else to feel productive, by the time Luka reviews Ema is no longer in context, the ping-pong drags on for days.
β Embodies the WIP-inflation argument β shows in human terms why async review structurally produces more WIP than the headcount suggests, and why context decays. - Amazon Prime / shipping cost analogy β when shipping is $3 you batch your basket; when it's free (Prime) you order single items as needed.
β Supports the proposition that batch size expands to match transaction cost; transfers the reader's everyday economic intuition onto the unfamiliar PR domain. - Slow test suite β if tests take 20 minutes, I won't run them after every line change, so I batch up changes before getting feedback.
β Generalizes the transaction-cost argument beyond code review to any feedback loop; primes the reader to see the same mechanism in CI, deployment, etc. - Online clothing same-day vs. one-week delivery β under slow delivery you order multiple sizes; under fast delivery you order one and iterate.
β Reinforces the transaction-cost-drives-batch-size point with a second consumer-economics analogy. - Production outage response β everyone jumps on a call together to resolve it.
β Used as a Goldratt-style 'emergency rules are actually good rules' argument β co-creation is what teams already do when stakes are high; the question is why it isn't the default. - Woody Zuill's Mob Programming workshop β first whole day spent on working-together principles (kindness, consideration, timely contribution).
β Supports the proposition that co-creation is a learnable skill teams typically lack, and that 'we tried it and it didn't work' often means 'we didn't actually try it.' - 40,000+ PRs across 40+ very active product development repos β the author's own study.
β Empirical backbone of the engagement-per-size and wait-time-per-size claims; differentiates this argument from prior opinion-based critiques of PRs.
Questions addressed
- β
How does PR-based async code review actually perform on throughput and quality in product development teams?
Empirically poorly on both axes: large PRs lose engagement per size; small PRs lose throughput via exponential wait-time-per-size; flow efficiency collapses below a threshold size. - β
Why does shrinking PR size β the conventional Lean advice β fail to deliver throughput gains under async review?
Because review transaction cost stays constant while batch size shrinks, the wait-to-work ratio explodes and flow efficiency tanks. - β
Is there a way to have both small batches and high throughput?
Yes β drive review transaction cost toward zero via continuous synchronous review (Pair/Mob). - β
Is co-creation compatible with remote work and individual schedule flexibility?
Yes β remote/async orthogonality; mob programming provides flow resilience for schedule slippage; flexible start/end times can be an advantage. - β What is code review actually FOR?
Author assumes it's for building in quality and providing human judgement in a learning loop. Never engages with audit/gatekeeping/separation-of-duties/compliance framings. - β Can tooling (AI-assisted review, faster CI, response-time SLAs) reduce review transaction cost enough to make async viable?
Not addressed. Article predates widespread AI coding agents and treats human availability as the only lever on transaction cost. - β What is the actual economic cost of pairing/mobbing relative to its rework reduction?
Claimed 'order of magnitude less rework' but no comparison to the doubled (or higher) people-cost; net economics asserted, not shown.
Gaps
- incompleteThe article treats human co-presence as the only lever on review transaction cost. It does not consider AI-assisted in-IDE review or AI pair-programmers as potential substitutes for some of the human availability cost. Given the explicit framing ('inventory expands to match transaction cost'), AI review tools that provide immediate, in-context feedback are a direct theoretical implication the author doesn't draw.
Read next: Cursor / Copilot / Claude Code workflow studies; AI-as-pair-partner literature; any post-2024 work on continuous AI review folded into authoring. - incompleteNo engagement with audit, compliance, separation-of-duties, or regulatory framings of code review. For teams in regulated industries (finance, healthcare, defense), the 'PR as gate / paper trail' function may be the dominant requirement β not the learning function the author optimizes for.
Read next: DORA's discussion of change approval; SOX/PCI-DSS code review requirements; literature on continuous compliance and pairing as audit substitute.closed byAgentic AI and Code Reviews β Directly engages the audit/compliance/regulated-industry framing that gap flagged as missing: DryRun Security's SOC 2-driven tenant-isolation controls and the paper's closing argument that agentic systems can produce a durable, queryable record of 'which policies were applied, how evaluations were conducted, and why decisions were made' β a potentially stronger audit foundation than traditional human review, provided the records are treated as durable artifacts rather than transient logs. - incompleteTrunk-based development and feature flags are notably absent. The article frames the alternative to async-PR review as Pair/Mob, but the modern stack often combines trunk-based + feature flags + small commits + light async review. The author doesn't engage with this hybrid.
Read next: Accelerate (Forsgren/Humble/Kim); trunk-based development primary sources; Paul Hammant on TBD; Pete Hodgson on feature flags.closed byWhy your team doesn't need to use pull requests β Morris explicitly describes the trunk-based-plus-light-review hybrid that gap asks about: continuous integration to mainline combined with post-integration review (periodic group reviews, or a pipeline approval gate placed after code is already integrated and tested) β rather than framing Pair/Mob as the only non-PR alternative. Feature flags specifically are still not addressed. - incompleteNo quantitative analysis of pairing/mobbing's people-cost vs. rework savings. The 'order of magnitude less rework' claim is anecdotal; whether 2N developers paired produces > N solo developers' net throughput is asserted, not shown.
Read next: Williams/Kessler on pair programming productivity; Allan Kelly's mob programming case studies; any controlled studies comparing pair vs. solo throughput.closed bySoftware Teaming: A Mob Programming, Whole-Team Approach β The 'Won't This Cost Too Much?' chapter supplies a cited (if explicitly non-rigorous) quantitative defect-cost model β Williams & Erdogmus and Rico et al. putting paired-work defect rates at 6%-40% of solo rates, against an estimated ~4.8 hours of rework per hour of solo-written code β directly responding to that gap's call for a people-cost vs. rework-savings analysis, while candidly admitting it is not a controlled study of ensemble/mob programming itself. - incompleteReviewer-as-knowledge-distributor function is largely unaddressed. PRs serve as a passive knowledge-sharing mechanism for team members not involved in authoring. Mob covers this for participants but raises the question of those NOT in the session.
Read next: Codebase ownership patterns; bus factor / knowledge silos; mob rotation strategies for cross-team knowledge. - incompleteThe article assumes review is primarily about correctness/quality of code-as-written. It doesn't address review's role in architectural drift, dependency hygiene, security review, or other concerns where a fresh reviewer's distance from the work might be a feature, not a bug.
Read next: Threat modeling literature; architecture decision records; literature on outside-in review for security and design coherence. - uninformedThe article predates and doesn't engage with the AI-accelerated coding context where a developer can produce a working diff in minutes that previously took hours. If authoring time collapses dramatically, the time-cost ratio between authoring and review shifts β possibly making async review even more dominated by wait, OR potentially making AI-assisted self-review viable in ways that change the calculus.
Read next: Beck/Grinich on AI coding agents; Karpathy and Gartner-style claims about AI-native development workflows; empirical work on PR throughput in AI-heavy teams.closed byAgentic Code Review β Supplies the AI-accelerated analysis that gap flagged as missing: when authoring time collapses toward zero while human reading speed is fixed, the authoring/review ratio inverts and async review becomes the dominant, wait-heavy bottleneck rather than the cheap step β quantified by 2026 telemetry (median review duration up 441.5%, zero-review merges up 31.3%). It also answers the gap's second branch β AI-assisted self-review is viable but only as a sensor, since a model cannot reconstruct intent.
Related documents
- Mob Programming β key issues it can solve, benefits, and learnings
- AI coding creates two kinds of debt. You're only measuring one
- Pair Programming Fixed Our Pull Request Bottlenecks
- Software Teaming: A Mob Programming, Whole-Team Approach
- AI isn't making developers more productive β it's making them busier
- Writing Code vs. Shipping Code: Productivity Effects Across Generations of AI Coding Tools
- AI-Assisted Software Development: Team Profiles and Capabilities for Putting Research into Action
- The Acceleration Whiplash
- Four Eyes Without Pull Requests
- 5) Vidar Moe: Det eneste Vidar vil er Γ₯ ha det lett