Trunk-Based & Continuous Delivery

Integrating to mainline daily and shipping continuously in small, safe increments — the delivery backbone that AI-assisted development depends on.

Also known as: trunk-based development, Trunk-based development, continuous delivery, continuous deployment, CD, release frequency, deploys på dagtid / 'alle på jobb', daily releases, illusory safety

How authors use it

Oldest first (extraction date when no publication date is known).

Documents (15)

• Article: Modular Edge Computing at Multi-Tenant SaaS Scale on Cloudflare Workers Chintan Tank · 2026-09-23 Reader 🖥️
  At multi-tenant SaaS scale, a monolithic edge worker's deployment coupling and unbounded blast radius stop being tolerable, so the fix is to decompose it into a thin composing gateway plus independently owned, tested, and staged-release feature workers connected by Cloudflare's same-isolate service bindings — the one primitive that makes this decomposition free of the network-hop cost that normally makes splitting a backend monolith expensive — while treating multi-CDN portability, per-feature configuration, and graceful failure as first-class, non-negotiable design constraints rather than afterthoughts.
• AI-Assisted Software Development: Team Profiles and Capabilities for Putting Research into Action Ben Linders · 2026-07-30 source ↗ Reader 🖥️
  DORA's 2025 research reframes AI adoption in software development as an organizational-system problem rather than a tooling problem: AI amplifies whatever team dynamics already exist, and the return on AI investment comes from developing identifiable, data-derived capabilities (from a clear AI stance to quality internal platforms) matched to your team's actual profile, not from adopting the technology itself.
• Jimmy Nilsson's Post — reflections after the Thoughtworks 'Future of Software Development' retreat Jimmy Nilsson · 2026-07-07 source ↗ Reader 🖥️
  Reflecting on Thoughtworks' 'Future of Software Development' retreat, the author reports that leading practitioners have moved past the hype-versus-doom polarisation about agentic coding toward nuanced 'when, where and how' thinking, converging on the view that enduring engineering fundamentals (DDD, XP, TOC, TDD, BDD, CD) plus a renewed 'Extreme Humanism' matter more than ever in the agentic age — which is why he is optimistic.
• Is AI coding on average 17.3x faster or 1.3x faster? Both. — LinkedIn post by Fabrice Bernhard Fabrice Bernhard · 2026-06-06 Reader 🖥️
  The headline 17.3x speedup that AI async agents produce at the start of the software value stream collapses to a 1.3x increase in release frequency at the end of the stream — because human and organisational bottlenecks (unclear business needs, organisational dependencies) dominate end-to-end throughput; therefore AI creates real value only when it is targeted at the actual bottleneck, and identifying that bottleneck is what Lean Tech is for.
• 18) Vipps: Fra app til verb til nordisk infrastruktur Truls Jørgensen og Audun Fauchald Strand — Heis Podcast · 2026-06-01 source ↗ Reader 🖥️
  Vipps's evolution — from a 2015 DNB-internal P2P app built under an IT freeze, through three successive mergers (MCash 2017, BankAxept 2018-ish, MobilePay 2023), three markets, and a near-decade of platform rewrites — shows that becoming Nordic critical infrastructure is less about visionary architecture than about repeatedly choosing momentum over perfection: small monoliths first, big-bang cut-overs when integration matters more than iteration, and a relentless willingness to throw away technology, organisation and product features that no longer serve the next size of company.
• On Pair Programming Nina Siessegger · 2026-06-01 source ↗ Reader 🖥️
  Pair programming should be the team's sensible default for production code because the live, four-eyes, two-modes-of-thinking collaboration produces continuous code review, knowledge spread, and team-flow benefits that asynchronous pull-request reviews cannot match — and pull requests are best reserved as the exception for the cases when someone must change production code without a pair.
• Four Eyes Without Pull Requests Andrea Laforgia · 2026-05-04 source ↗ Reader 🖥️
  Pair programming teams can satisfy ISO 27001 and SOC 2 audit requirements for four-eyes review without pull requests by constructing a composite control of five pieces — written policy, structured commit trailers, automated enforcement, supplementary telemetry, and a sampling audit protocol — which together produce stronger evidence of real review than the PR approval artefact they replace.
• Henrik Kniberg's Post Henrik Kniberg · 2026-04-20 Reader 🖥️
  A system of specialized AI agents collaborating with human engineers — handling not just coding but backlog management, release management, and stakeholder requests — enables daily releases and lets humans focus on higher-level design, architecture, and UX.
• T*D Andrea Laforgia · 2026-04-10 Reader 🖥️
  When software teams genuinely pursue speed, quality, and shared ownership simultaneously, they naturally converge on three mutually reinforcing practices — test-driven development, trunk-based development, and team-focused development (pairing/mobbing) — which the author brands as T*D.
• Fragments: February 18 Martin Fowler · 2026-02-18 source ↗ Reader 🖥️
  AI-assisted software development is best understood as an amplifier of a team's existing practices rather than a disruptive break, so the field's real work is rebuilding the human-era practices that are predictably breaking—through emerging disciplines like the supervisory middle loop, risk tiering, TDD-as-prompt-engineering, and platform 'bullet trains'—amid far more shared uncertainty than settled answers.
• Pair Programming Fixed Our Pull Request Bottlenecks Modern Software Engineering (Dave Farley) — clip from The Engineering Room podcast · 2025-07-11 source ↗ Reader 🖥️
  Pair programming did not just make pull-request review faster for this team — it made the pull-request gate itself unnecessary, because the review, the four-eyes compliance requirement, and the knowledge-sharing that PRs exist to provide were already satisfied continuously by working together, which let the team drop branches entirely and move to minutes-long commit-to-production cycles.
• Mob Programming – key issues it can solve, benefits, and learnings futurice.com · 2022-08-08 source ↗ Reader 🖥️
  Asynchronous, feature-branch-and-pull-request software development ('soloing') generates Lean process waste — delays, queues, defects, big batches, overproduction, and rework — because it structurally separates writing code from reviewing it; mob programming (the whole team working synchronously on one task at a time) eliminates this waste by collapsing the hand-off entirely, and on one real six-month engagement its benefits (faster flow, continuous review, shared knowledge, trunk-based delivery, psychological safety) outweighed the new problems it introduced (remote-tooling friction, flow-state overwork, loose-specification discomfort).
• Why your team doesn't need to use pull requests infrastructure-as-code.com (Kief Morris) · 2021-01-02 source ↗ Reader 🖥️
  Pull requests were designed to vet contributions from untrusted outside contributors, so applying them to a trusted team's own code sacrifices Continuous Integration's fast feedback and flow for no corresponding risk-reduction benefit; teams should instead integrate continuously and get code review through pairing, periodic group reviews, or post-integration pipeline approval gates.
• Post-Commit Reviews != Post-Deployment Reviews Cindy Sridharan · 2020-07-14 source ↗ Reader 🖥️
  Mandatory pre-commit code review trades developer velocity for a quality guarantee that is weaker than assumed, because review's real value is mostly knowledge transfer rather than defect detection and automated post-commit testing already catches most of what unit tests miss -- so teams should default to post-commit review (reviewing after merge to trunk, but still before or shortly after deploy), which is a distinct and more flexible choice than the commonly conflated 'post-deployment review,' and which preserves the four-eyes control while restoring developer and reviewer focus, provided the team has the trust and automation investment to make reverts safe.
• Software Engineering at Google Fergus Henderson · 2019-02-19 source ↗ Reader 🖥️
  Google sustains software velocity and quality at extreme scale (2+ billion lines, one repository, thousands of engineers) not through any single tool or policy but through a mutually reinforcing system of technical infrastructure (a single trunk-based monorepo, hermetic reproducible builds, and mandatory same-day code review) and organizational design (separated engineer/manager career tracks, OKRs deliberately decoupled from pay, 20% time, and periodic full rewrites) that together manufacture trust, ownership, and continuous renewal.

Propositions touching this concept (14)

By publication month, oldest first (extraction month when no publication date is known).

2022-08

• explicitSwitching from long-running feature branches to trunk-based development (a shared development branch with daily merges to mainline, pull requests retained only to trigger release pipelines) was both enabled by and necessary for mob programming's continuous-integration benefits.
  Mob Programming – key issues it can solve, benefits, and learnings · p9

2025-06

• explicitThe Aligned Autonomy pattern — leadership sets a clear goal and objective progress metrics, teams get full autonomy over how to hit it, leadership backs that with organizational support — is the right vehicle for AI adoption because it already worked for prior waves of change (DevOps, test automation, observability, microservices, cloud, continuous delivery) and doesn't require inventing a new change-management playbook for AI specifically.
  Leading your engineers towards an AI-assisted future · p2

2026-01

• explicitcorroboratedThe slow-down-to-speed-up requirement for AI adoption is measured in months, not weeks, especially in environments without continuous delivery infrastructure.
  9) Nils Brede Moe om AI-paradokset, autonomi, læringskultur og fremtidens team · p10
• explicitThe good practices of the continuous delivery era — automated tests, monitoring, observability, deployment pipelines — become more important under AI assistance, not less.
  9) Nils Brede Moe om AI-paradokset, autonomi, læringskultur og fremtidens team · p11

2026-04

• explicitGood engineering practices (continuous delivery is the named example) have been well-described since the early 2000s but only patchily lived; AI raises the incentive enough that organisations now have to actually live them.
  14) Øystein Ulseth pendler mellom å lede og levere · p15
• explicitLong-lived feature branches provide illusory safety; frequent integration into trunk is less risky than deferred merges.
  T*D · p4
• explicitTrunk-based development is compatible with — and even beneficial in — regulated industries, despite common assumptions to the contrary.
  T*D · p5
• explicitYounger developers trained on GitFlow-style workflows are a significant source of resistance to trunk-based development.
  T*D · p9

2026-05

• explicitestablishedHigh-performing teams favour smaller batches, more frequent integration, and trunk-based development — patterns that continuous pairing review fits better than long-lived branches.
  Four Eyes Without Pull Requests · p8
• explicitClassical engineering practices (TDD, DDD, agile, continuous delivery, simple refactored code) are simultaneously (a) what produces the kind of code agents themselves work best with and (b) the developer's existential anchor against alienation.
  KI, utvikling og følelser · p7

2026-06

• explicitRelease frequency is only up by 1.3x when teams adopt the same tools.
  Is AI coding on average 17.3x faster or 1.3x faster? Both. — LinkedIn post by Fabrice Bernhard · p2
• explicitcorroboratedPair programming and trunk-based continuous integration are complementary practices: with trunk-based development, delayed PR reviews are even less effective because the code already merged.
  On Pair Programming · p3

2026-07

• explicitGrowing backlogs despite continuous delivery, teams working around the platform, and being unable to tell whether what was built is used, are the diagnostic signals that the project model has failed.
  Shifting Platform Development from Projects to Products · p5
• explicitTeams with well-engineered systems — low build times, modular architecture, and high test coverage enabling continuous delivery — benefit most from agentic engineering.
  Looking back at the Future of Software Engineering unconference · p3

Tensions

Open gaps (36)

• incompletePocock conflates two definitions of 'done': (a) feature shipped with QA-imposed taste, and (b) commit produced by the Ralph loop with passing tests. The transitions between (a) and (b) — especially the merge-and-conflict-resolution at the end of multiple parallel sandbox branches — are sketched (the Sandcastle merger agent) but not interrogated for what happens when the merger itself produces semantically broken code. This is exactly where small-PR discipline matters and where he admits he doesn't have the answer.
  [FULL WORKSHOP] AI Coding For Real Engineers - Matt Pocock, AI Hero — read next: Beck on incremental design and TCR; trunk-based development literature; the smallcode failure-mode catalog if it covers merge-stage failures.
• incompleteThe "degrade to origin" rule is presented as unconditionally safe, but the article never considers cases where the unoptimized origin response is itself unacceptable — a client device that genuinely cannot render the origin format, or a tenant whose cost/bandwidth contract depends on the optimization having actually run. The fallback's own failure mode is left unexamined.
  Article: Modular Edge Computing at Multi-Tenant SaaS Scale on Cloudflare Workers — read next: Would benefit from engaging with graceful-degradation literature that treats the fallback path itself as a design surface with its own failure modes, not an automatically safe default.
• incompleteThe article names the observability loss caused by decomposition (diagnostics captured inside a downstream feature worker are not propagated back through the gateway) but never describes how the team actually debugs a failing request in production once it crosses a service-binding boundary — the fix for the gap it identifies is left unstated.
  Article: Modular Edge Computing at Multi-Tenant SaaS Scale on Cloudflare Workers — read next: Distributed-tracing / observability practice for chained service-to-service calls (e.g., correlation IDs threaded through headers, structured logging aggregation) would close this.
• incompleteThe talk assumes a small, highly skilled team that can make and evaluate architectural decisions rapidly. No discussion of how these practices scale to larger organizations where most engineers are not senior architects.
  Presentation: Engineering at AI Speed: Lessons from the First Agentically Accelerated Software Project — read next: Team Topologies (Skelton & Pais); research on scaling agile and continuous deployment in large organizations
• incompleteThe post claims release frequency is 'the only number that matters' but doesn't argue why — and Lean's own toolkit would suggest cycle time, quality, and customer outcomes belong alongside release frequency. The reduction of 'real value' to a single metric is rhetorically clean but theoretically thin.
  Is AI coding on average 17.3x faster or 1.3x faster? Both. — LinkedIn post by Fabrice Bernhard — read next: DORA's four-key-metrics literature; Reinertsen on cost of delay; Steve Yegge / Gene Kim on quality-vs-speed under AI; Beck's recent newsletters on what to measure when AI changes throughput.
• incompleteTheodo's consultancy context is a selection bias engine that Bernhard doesn't address. Consultants typically work on greenfield engagements or on well-bounded modernisation projects where business needs are pre-scoped by a client brief. The very bottlenecks Bernhard names (unclear business needs, organisational dependencies) are precisely the bottlenecks consultancy contracts pre-filter for. Whether the 3x result transfers to in-house teams operating in the muck is the load-bearing open question.
  Is AI coding on average 17.3x faster or 1.3x faster? Both. — LinkedIn post by Fabrice Bernhard — read next: Compare to Anthropic enterprise PDF findings on in-house deployments; Cutler on internal-team organisational drag; case studies of in-house legacy modernisation at scale (e.g. NAV, Entur reports already in corpus).
• incompleteLegacy modernisation is presented as 'a' bottleneck-aligned use case but Bernhard doesn't enumerate what makes it bottleneck-aligned and what other use cases would qualify. A more complete argument would name the properties (translation-heavy, human-comprehension-bound, well-specified target, measurable acceptance criteria) that make AI bottleneck-effective.
  Is AI coding on average 17.3x faster or 1.3x faster? Both. — LinkedIn post by Fabrice Bernhard — read next: Mary Poppendieck on Lean software value-stream mapping; Theory-of-Constraints applied software literature; specific case studies of AI-driven greenfield vs migration projects.
• incompleteThe post takes the MIT/UPenn paper as authoritative but doesn't disclose the dataset, sample, or timeframe. Async agents in 2024-25 (the likely study window) are not the same product category as 2026 long-running harnesses — the 1.3x number may understate what later-generation tooling can do at the release-frequency end, OR may be optimistic if the study captured the early enthusiasm phase.
  Is AI coding on average 17.3x faster or 1.3x faster? Both. — LinkedIn post by Fabrice Bernhard — read next: The Demirer/Musolff/Yang paper itself; recent METR / RCT-style AI productivity studies; Pocock workshop on what changes with harness-level tooling.
• incompleteThe 'we generate better learnings' claim is asserted without describing Theodo's actual learning mechanisms — internal write-ups, retros, replication across client engagements, etc. For an audience interested in adopting the approach, the learning infrastructure is the load-bearing part.
  Is AI coding on average 17.3x faster or 1.3x faster? Both. — LinkedIn post by Fabrice Bernhard — read next: Theodo's engineering blog (theodo.com / padok.fr); Mike Rother's Toyota Kata on learning routines; A3 thinking literature.
• uninformedThe post predates / doesn't engage with the harness-engineering thread that this corpus has been tracking (Anthropic harness paper, Pocock workshop, Cloudflare Mythos). Harness-level tooling specifically aims at the integration between code generation and release — exactly the gap Bernhard names. Whether harness engineering is a third path (between 'roll out Copilot' and 'consultancy-led bottleneck targeting') is an obvious adjacency.
  Is AI coding on average 17.3x faster or 1.3x faster? Both. — LinkedIn post by Fabrice Bernhard — read next: Pocock workshop extraction; Anthropic harness design paper; Cloudflare Mythos extraction; the Anthropic enterprise PDF extraction.
• evidentialNo empirical data on how auditors actually respond to the composite control. The article is confident about audit acceptance but relies on the author's reading of standards and general audit theory, not reported outcomes.
  Four Eyes Without Pull Requests
• practicalThe sampling audit protocol is specified in detail but its operational cost is not estimated. For small teams the overhead of quarterly interviews may be significant relative to the team's capacity.
  Four Eyes Without Pull Requests
• assumptionThe argument that detective controls compensate for self-attestation weakness assumes the dominant threat is process drift, not adversarial insiders. In environments with higher insider-threat risk, this assumption may not hold.
  Four Eyes Without Pull Requests
• emergingNo discussion of how the composite interacts with AI-assisted coding (e.g., Copilot, Claude Code). If one 'pair' is an AI, do the four-eyes semantics still hold? The article's framework implicitly assumes both participants are human.
  Four Eyes Without Pull Requests
• incompleteThe claim that AI raises the incentive to live good engineering culture is asserted but not mechanised. Continuous delivery has been well-described for 20 years and only patchily adopted. Why will AI succeed in changing this where the prior decade's tooling, DORA reports, and platform engineering did not? A causal story is missing.
  14) Øystein Ulseth pendler mellom å lede og levere — read next: DORA 2025/2026 specifically on AI's interaction with delivery practices; Birgitta Böckeler and Martin Fowler on AI-coding feedback loops; Kent Beck's TCR work as the practice end of the same idea.
• incompleteVendor positioning is conspicuous: the story is told entirely from the survivors' chair. MobilePay engineers are quoted only as having insisted their tech was 'objectively better', MCash veterans get one similar line, and no failures are attributed to Vipps leadership specifically. The MCash 2017 carve-out is treated as smoothly inevitable; the operational chaos is named ('brannslukningsarbeid') but never traced to a decision.
  18) Vipps: Fra app til verb til nordisk infrastruktur — read next: MobilePay engineering blog posts from 2023–2024; the Danish fintech press's coverage of the merger; Kristian Pinsel Halvorsen interviews (his name is dropped as the host's 'old boss' from FINN, suggesting a counter-perspective on big-bang migrations in Schibsted/FINN territory)
• incompleteThe role of DNB through the entire history is underexamined. Vipps was DNB's first public-cloud workload, DNB's CEO drove the founding, MCash brought the other Norwegian banks in, and yet the bank-shareholder governance — including how decisions like 'use Vipps's platform, not MobilePay's' actually get taken — is essentially a black box.
  18) Vipps: Fra app til verb til nordisk infrastruktur — read next: Norwegian financial press on Vipps AS ownership changes; Rune Bjerke's memoir/interviews; the prior Heis episode with Kari Olrud Moen (ep 15, 'strategi tydelig og skråsikker') — Moen is Vipps's CEO context
• incompleteTap to Pay is celebrated as a success, but the speakers stop short of explaining what economic margin Vipps captures from international card schemes vs. domestic BankAxept on in-store transactions. Given that the entire European sovereignty argument hinges on dependency on American card schemes, the cost/risk picture matters strategically.
  18) Vipps: Fra app til verb til nordisk infrastruktur — read next: Norwegian card-scheme regulator (Finanstilsynet) cost analyses; EU Digital Markets Act / Payment Services Directive 3 documentation; ECB reports on European payments sovereignty
• incompleteThe 'verb-status' achievement is mentioned but not problematised. Mobilepay is also a verb in Danish; both verbs are now inside one company. What happens to brand neutrality and to user expectations when a Norwegian verb is owned by a Nordic company that wants to be European? The speakers laugh it off ('det tror jeg ikke vi skal prøve å spørre' about Finnish usage).
  18) Vipps: Fra app til verb til nordisk infrastruktur — read next: Sociolinguistics of brand-verb status; comparable post-merger brand consolidations in payments (Klarna, Wise); MobilePay marketing material from the merger announcement
• incompleteAI in regulated production code is left as an open problem. The 'humanize ser på koden' (humans review code) regulatory expectation is named, but the speakers don't engage with how Norwegian Finanstilsynet, the EU AI Act, or DORA-style governance frameworks will actually treat AI-generated code in financial production.
  18) Vipps: Fra app til verb til nordisk infrastruktur — read next: Finanstilsynet guidance on AI in financial services; EU AI Act high-risk system requirements for payments; DORA 2025 findings on AI-assisted development in regulated industries
• incompleteArchitecture is described as never planned ('aldri hatt et stort arkitekturprosjekt') but the result is a mature multi-cloud, multi-region, regulated platform with 35 product teams and 170+ engineers. The gap between 'we never planned it' and 'we ended up here' is unexamined — what is the actual feedback mechanism that lets a no-architecture-project culture not drift into mush?
  18) Vipps: Fra app til verb til nordisk infrastruktur — read next: Cutler's writing on emergent architecture and operating-system design; Beck's Tidy First essays on iterative architecture; the prior Heis episode with Greger Teigre Wedel (ep 12, 'når sjefen har svaret') for a Norwegian counter-perspective on top-down architecture
• incompleteThe speakers describe weekly releases and trunk-based-ish development for the app, but back-end deploy cadence and the cross-team coordination model when 35 product teams plus a payments backbone plus an AI platform team all ship at different speeds is not described in detail.
  18) Vipps: Fra app til verb til nordisk infrastruktur — read next: DORA 2024–2025 reports on deploy frequency and change-failure rate in financial services; NAV's 'fast flow' writeup that Kjetil has already saved (per persona)
• incompleteGeneralizability: Abundly is a small AI-native startup building an agent platform. Their incentives, team size, codebase complexity, and regulatory environment are unusual. No acknowledgment that this setup might not transfer to larger, more constrained organizations.
  Henrik Kniberg's Post — read next: Case studies of multi-agent adoption in larger organizations; enterprise AI adoption literature.
• incompleteThe 'exception' category for PRs is asserted but not characterized. What counts as 'someone has to change production code without pairing'? Hotfixes? Solo time-zone hours on a distributed team? Documentation-only changes? Without criteria, 'PR for exceptions' can drift back into 'PR by default with a rationale attached.'
  On Pair Programming — read next: Look for engineering blogs on trunk-based-development discipline (e.g. Hammant, DORA reports) and post-PR workflows; also Beck on what XP teams actually do for solo edge cases.
• incompleteNo engagement with AI-accelerated code generation. The author's load-bearing claim — that the navigator's strategic mode is what one person cannot supply alone — is exactly the claim AI assistants put in play. An AI can act as a tactical driver to a human navigator (Strong-Style inversion), or as a tireless reviewer. The article cannot help with whether this changes the default.
  On Pair Programming — read next: Read Anthropic/Cursor/Aider research on AI-pair patterns; Beck's recent writing on AI and XP practices; thoughtful critiques of solo-with-AI productivity claims.
• incompletePair rotations are treated as the mechanism for collective ownership, but the article admits opinions diverge on frequency and concedes costs (context switch, lost tacit knowledge). It does not give a decision procedure, so 'pair + rotate' as a substitute for PR-mediated cross-team review remains under-specified.
  On Pair Programming — read next: Mob programming literature (Llewellyn Falco, Woody Zuill); engineering org studies on knowledge silo formation.
• incompleteAsynchronous/distributed-team pairing is treated as a tooling problem (screen share, low-latency). The harder organizational question — can pair-by-default work across time zones at all, or does that environment structurally demand PR-by-default — is not engaged.
  On Pair Programming — read next: GitLab/Automattic/Basecamp on fully-async engineering; recent material on remote-first XP.
• incompleteThe economics rebuttal ('we are wary of attempts to scientifically prove pairing effectiveness') is rhetorically convenient. It immunizes the practice from quantitative challenge without offering an alternative evaluation criterion beyond 'try it.' For the syntopical question, this matters: managers comparing pair-by-default vs. PR-by-default + AI need some way to choose.
  On Pair Programming — read next: DORA / SPACE / DX framework material on developer productivity measurement; serious cost-of-quality literature.
• incompleteThe article notes Anthropic deliberately keeps feature flags minimal because 'feature flags slow the team down,' but never examines whether this is sustainable given the growth-driven monitoring load the same article describes (alerts firing 'pretty much every day' simply from rapid growth) — nor what happens to blast-radius risk as Claude Code's external user base keeps scaling well past where it is today.
  How Claude Code Is Built — read next: Read against async-code-reviews-choking-throughput's discussion of trunk-based development and feature flags as an alternative risk-mitigation mechanism the article doesn't engage with directly.
• incompleteThe entire safety case for post-commit review rests on automated revert/rollback being reliable, but the article never asks what happens when that automation itself has a false negative -- a bad change that neither the (deferred) human reviewer nor the automated tests catch before other commits build on top of it. The risk isn't addressed as a risk, only as an engineering cost (SubmitQueue-level complexity) to be paid once.
  Post-Commit Reviews != Post-Deployment Reviews — read next: Corpus material on CI gates and agent-driven churn (e.g. the deterministic-CI-gates argument) addresses exactly this residual-risk question for a world with far higher commit volume than this 2020 piece assumed.
• scope limitationThe article never addresses contexts where T*D may not apply or may need significant adaptation — solo developers, open-source projects with asynchronous contributors, research/exploratory coding, or very early-stage prototyping.
  T*D — read next: Investigate when trunk-based development or pairing breaks down (e.g., distributed open-source, 1-person teams, spike work).
• missing causal mechanismThe three practices are presented as a unified triad (T*D) but the article never explains why these three specifically, or how they causally reinforce each other. The mutual reinforcement is implied but not argued.
  T*D — read next: Look for literature on the interaction effects between TDD and CI/CD, and between pairing and TDD adoption success.
• survivorship bias riskThe 'natural emergence' argument draws on teams that succeeded. Teams that tried these practices and failed, or high-performing teams that use different approaches, are not discussed.
  T*D — read next: Examine DORA data more carefully for whether TBD is necessary or merely correlated; look at high-performing teams using different workflows (e.g., Linux kernel's patch-based model).
• evidence selectivityThe pairing research cited (Williams & Kessler 2000) is over 25 years old. More recent and nuanced studies on pair programming effectiveness are not referenced.
  T*D — read next: Review recent meta-analyses on pair programming effectiveness, particularly in remote/distributed settings.
• is-ought gapThe article moves from 'these practices emerge naturally' (descriptive) to 'these are the only sensible way to work' (prescriptive) without bridging the logical gap. Natural emergence does not entail optimality.
  T*D — read next: Consider evolutionary arguments: not all convergent outcomes are optimal; they may reflect local optima or shared biases in the practitioner community.
• incompleteThe batch-size regression is flagged as an 'active regression needing industry attention' but no countermeasures are proposed beyond general governance reform.
  The Future Of Software Engineering — read next: DORA State of DevOps reports; continuous delivery literature on changeset sizing with AI tools