Pull Requests & Async Code Review

The batch-and-wait review workflow built on pull requests, its throughput/quality trade-offs, and alternatives that satisfy the same four-eyes control.

Also known as: pull request, pull requests, PR, async code review, Async code review, code review, Code Review (the PR kind), code review on-the-go, LGTM syndrome, four-eyes principle, PR batch transaction cost, wait time per size, humanize ser på koden

How authors use it

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

Documents (45)

• AI Development Patterns Paul Duvall · 2026-10-08 source ↗ Reader 🖥️
  Organizations should adopt this catalog's AI-development patterns selectively and in an order diagnosed from their own team size, project type, and technology stack — not uniformly or in catalog order — because the coordination problems a solo developer needs to solve (rapid iteration, tool-matching) are categorically different from, and the patterns designed for them can actively mismatch, what a two-pizza team or a multi-team organization needs (parallel-agent isolation and conflict resolution, cross-team traceability, automated review of agent output at volume).
• Agentic AI and Code Reviews Zach Davis, Michelle Gill, Elisabeth Hendrickson, Angie Jones, Sha Ma, Randy Shoup, James Wickett · 2026-09-14 source ↗ Reader 🖥️
  As AI agents generate code faster than human attention can scale to review it, code review must be reorganized from a single human merge-time gate into a layered, risk-tiered verification system — deterministic checks, continuous author/review-agent loops, structurally independent adversarial review, and specialist multi-agent review — with human judgment deliberately reserved for intent, strategic risk, and accountability rather than mechanical inspection, and every automated decision recorded as a durable, auditable artifact.
• Brownfield Agentic Engineering Addy Osmani · 2026-09-14 source ↗ Reader 🖥️
  Agentic engineering in an old (brownfield) codebase succeeds by making hidden, undocumented constraints explicit and the cost of a wrong change cheap and visible — through human-drawn risk zones, durable research artifacts, characterization tests, migrations completed as whole units, and review that scales with blast radius rather than code volume — not by maximizing agent autonomy or parallelism first.
• Practices I Abandoned with Agents: An Ode to Test-Driven Development Adam Tornhill · 2026-09-03 source ↗ Reader 🖥️
  Granular, human-cognition-scaled Test-Driven Development does not survive the transition to agentic coding and should be replaced by a coarser, feature-level practice — tests (especially end-to-end) as the human/agent abstraction boundary, with failing-test discipline retained but no longer organizing work into small red-green-refactor steps.
• The AI-Native SDLC playbook Louis Claxton · 2026-08-21 source ↗ Reader 🖥️
  Once agentic coding collapses the build phase to hours, the traditional SDLC's human-speed controls (committees, meetings, line-by-line review) become the bottleneck and stop matching reality, so organizations should rebuild the lifecycle as a non-linear loop of six stages (plan, design, build, test, deploy, maintain) where every stage commits a version-controlled artifact the next stage reads, human judgment concentrates at artifact-acceptance gates rather than at the point of production, and governance is enforced as code (hooks, branch protection, managed settings) rather than through periodic human review bodies.
• GitHub Brings Stacked Pull Requests to Public Preview Craig Risi · 2026-08-18 source ↗ Reader 🖥️
  GitHub's native stacked pull requests matter because they attack code review — not code generation — as the increasingly binding bottleneck of AI-accelerated software development, by structurally shrinking what each PR asks a reviewer to understand rather than by making review itself faster.
• Stop being skeptical about AI for development with Charity Majors Gergely Orosz (interviewing Charity Majors, CTO/co-founder of Honeycomb) · 2026-08-12 Reader 🖥️
  AI skepticism about software development, though rational as recently as 2025 given the industry's track record of over-promised transformative technologies, has become irrational in 2026 because the model-plus-harness combination (Opus 4.5 running inside Claude Code) crossed a genuine, cloud-computing-in-2010-scale capability threshold — so the live question for engineers is no longer whether to adopt AI but how to build the validation discipline (tests, evals, conformance checking, observability) that makes shipping AI-written, unread code safe.
• Grafana's gcx and MCP Server Reach GA for Telemetry-Driven Agent Development Claudio Masolo · 2026-08 source ↗ Reader 🖥️
  As AI coding agents let engineers generate diffs faster than they (or reviewing agents) can build genuine understanding of them, Grafana's newly-GA gcx CLI and MCP server let those same agents query live observability data (metrics, logs, traces, SLOs) during development, so that implementation and testing decisions are grounded in and checked against actual system behavior rather than training-data assumptions or a code review that has become unreliable.
• Dropbox Integrates MCP and Dash to Close the Gap Between Security Design and Code Review Leela Kumili · 2026-07-31 source ↗ Reader 🖥️
  AI-assisted code review only enforces security intent reliably if the review agent is grounded, at the moment of implementation, in the organization's own design-time security artifacts via a permission-aware retrieval layer exposed through a standardized protocol (MCP) — and even then the system must stay traceable and advisory rather than authoritative, because retrieval without reasoning-and-restraint just relocates the staleness problem instead of solving it.
• 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.
• How building software is changing at Anthropic The Pragmatic Engineer · 2026-07-28 Reader 🖥️
  Inside Anthropic, AI has not eliminated the traditional structure of software engineering (planning, PRDs, cross-team alignment, code review) so much as relocated where the effort and the bottleneck sit — from writing code to verifying it, and from one engineer working alone to fleets of parallel AI agents whose output is checked, merged, and increasingly re-reviewed by other AI, while every design assumption must now be re-tested at each new model generation.
• The Kubernetes Approach to AI-Assisted Maintainership Prioritises Human Accountability Olimpiu Pop · 2026-07-09 source ↗ Reader 🖥️
  The Kubernetes community has formalized an AI-governance framework that treats AI strictly as an advisory productivity tool while making human maintainers solely and permanently accountable for code quality, security, and the project's historical record.
• Presentation: The Multi-Agent Approach: Building Reliable and Controllable Software Development Automation Itamar Friedman · 2026-07-08 source ↗ Reader 🖥️
  To break through the AI 'productivity ceiling' in software development you must stop pouring investment into faster code generation and redirect it toward verification and context — building an adaptive, quality-grounded multi-agent system with an arbiter to resolve agent disagreements, human-observable inter-agent communication, first-class governance, and continuous learning of what quality means for your organization.
• AWS Expands DevOps Agent with AI-Powered Release Management to Validate Code Before Production Craig Risi · 2026-07-07 source ↗ Reader 🖥️
  AWS's expanded DevOps Agent — adding Release Readiness Review and Autonomous Release Testing — reflects, and is offered as the industry's answer to, a shift in the software-delivery bottleneck from writing code to validating and releasing it safely at AI-accelerated volume.
• Agentic Code Review Addy Osmani (addyosmani.com) · 2026-07-06 source ↗ Reader 🖥️
  Because agents made writing code nearly free while understanding it stayed exactly as costly as ever, code review has become the binding constraint on shipping software — and since review must now reconstruct an intent that never existed in any human mind, the right amount of human review is not a fixed rule but a dial set by each change's blast radius.
• AI coding creates two kinds of debt. You're only measuring one Antonija Bilić Arar · 2026-06-18 source ↗ Reader 🖥️
  AI-generated code creates a second, largely invisible kind of debt — cognitive debt, the erosion of shared team understanding of what a system does and why, distinct from ordinary technical debt in the code itself — and it is a genuine measurement blind spot: satisfaction scores, NPS and mentor ratings can hold steady or rise while it accumulates, so organizations must replace satisfaction-based signals with trajectory-based skill measurement and deliberate team-level questions to catch it before it becomes irreversible.
• Spec-Driven Production Grade Development In The Age Of Vibe Coding Lee Boonstra · 2026-06-18 Reader 🖥️
  Because agentic coding has eliminated the implementation bottleneck and shifted it downstream to the humans who must review, integrate, and govern AI-generated output, production-grade development requires treating specifications as a disposable-code-enabling source of truth, redesigning team review culture (risk-bundled PRs, conditional approval, no-blame norms, tiered continuous reviewers) around that volume, and backing both with defense-in-depth technical guardrails (sandboxing, policy servers, context hygiene) rather than relying on speed of writing or any single control.
• AI isn't making developers more productive – it's making them busier Chris Stokel-Walker · 2026-06-11 source ↗ Reader 🖥️
  A large-scale study of 100,000+ GitHub developers reframes the AI-coding story as redistribution rather than acceleration: AI makes developers busier by ballooning code output, but net shipped value barely moves because fixed human review/integration capacity is the binding downstream constraint.
• From Async Code Reviews to Co-Creation Patterns Dragan Stepanović (published via Ben Linders / InfoQ) · 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.
• 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.
• How I Use Agents Without Stopping My Own Growth Jared Currie · 2026-05-27 source ↗ Reader 🖥️
  Agentic coding tools are safe to lean on only if the developer deliberately keeps exercising the judgment they would otherwise outsource — by planning before delegating and reviewing generated code as if reconstructing its reasoning themselves — because the tools amplify whichever posture the developer brings to them.
• Writing Code vs. Shipping Code: Productivity Effects Across Generations of AI Coding Tools Mert Demirer, Leon Musolff, Liyuan Yang · 2026-05-27 source ↗ Reader 🖥️
  Across three successive generations of AI coding tools, large task-level productivity gains (up to 180% more commits) attenuate sharply as they propagate up the software production hierarchy to final shipped output (only 20-30% more releases), because AI and downstream human effort are strong complements rather than substitutes (estimated elasticity of substitution of about 0.25) — so increasing automation of code-writing alone yields only bounded gains in what actually reaches users, a pattern that also shows up in aggregate GitHub activity and across four app marketplaces, where new app releases have risen but end-user usage has not.
• Using AI to write better code more slowly Nolan Lawson (Read the Tea Leaves) · 2026-05-25 source ↗ Reader 🖥️
  LLMs are flexible enough to produce either fast, unvetted slop or slower, carefully reviewed and understood code, and deliberately choosing the latter — running multiple different models to hunt for bugs, personally validating and triaging what they find, and refusing to ship a PR you don't fully understand — is a better way to use AI for programming, even without a velocity payoff.
• NodeJS Proposes Built-In Virtual File System, Sparking Debate Over AI-Generated Contributions Daniel Curtis · 2026-05-25 source ↗ Reader 🖥️
  A proposal to add a built-in virtual file system to Node.js core — a large (~19,000-line) change that its author, TSC member Matteo Collina, built with heavy AI assistance while reviewing every line himself — has become a flashpoint for an unresolved governance question facing critical open-source infrastructure: whether AI-generated contributions should be accepted at all, given that reviewers cannot easily verify a human's claim to have adequately reviewed machine-generated code at that scale, even as the underlying feature draws strong independent technical support and has already been adopted by Vercel and LangChain.
• 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.
• Podcast: The AI Joy Gap: Why Some Developers Thrive While Others Struggle Michael Parker · 2026-04-20 Reader 🖥️
  AI-assisted development is creating a polarized experience — joyful for greenfield builders, miserable for legacy-code maintainers — and closing this 'joy gap' requires better planning and review tooling, organizational structures like AI platform teams, and cultural practices that reconnect developers with each other and with the customer problems they are solving.
• The Acceleration Whiplash Faros · 2026-04-09 Reader 🖥️
  AI coding tools have crossed, without any deliberate organizational decision, from assistant to primary author of code, and two years of telemetry from 22,000 developers show that this shift is producing a widening gap between throughput (up) and production quality (down) that holds regardless of engineering maturity -- so organizations must raise code quality at the point of AI authoring rather than add more downstream review.
• Head of Claude Code: What happens after coding is solved | Boris Cherny Lenny's Podcast · 2026-02-19 source ↗ Reader 🖥️
  A year after Claude Code's launch, coding itself is — in Boris Cherny's own, carefully qualified words — 'largely solved' for the kind of programming he does, which has pushed both the bottleneck and the interesting work for Anthropic's Claude Code team upstream: from writing code to reviewing/prioritizing it, from engineering as a distinct discipline to a convergence of engineering/product/design, and from building for today's model to deliberately betting on, and designing for, the model that will exist six months from now.
• Linear’s CEO just described the biggest shift in product team... Aakash Gupta · 2026-01-04 source ↗ Reader 🖥️
  As coding agents collapse the 'middle' translation step between product intent and working code, leverage shifts to the two points that don't automate away — forming and externalizing clear intent before execution, and reviewing agent output after it — so the teams that build structured, context-rich systems usable by both humans and agents will gain a durable structural advantage.
• How AI will change software engineering – with Martin Fowler The Pragmatic Engineer · 2025-11-19 source ↗ Reader 🖥️
  AI's defining change to software engineering is not primarily a jump in abstraction level but a shift from deterministic to non-deterministic systems — and the disciplines that make software durable and legible to teams over time (small reviewable steps, tests, refactoring, shared vocabulary, mentorship) matter more, not less, as a result, even as the field has not yet worked out how teams — as opposed to individuals — should operate with AI.
• How Claude Code Is Built Gergely Orosz · 2025-09-23 source ↗ Reader 🖥️
  Claude Code is built by a small team that treats the Claude model itself — not its own surrounding code — as the real product, deliberately minimizing scaffolding, choosing an "on-distribution" tech stack the model already masters, deleting code whenever a new model release subsumes it, and restructuring code review, testing, incident response, and prototyping around AI doing the first pass; Orosz presents this as a plausible preview of how "AI-first" engineering teams will operate, while flagging that Anthropic's unlimited, cost-free access to its own frontier model and its identity as a research lab (not a product company) limit how directly the specifics transfer elsewhere.
• 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.
• How AI will change software engineering Kari McMahon · 2025-04-14 source ↗ Reader 🖥️
  Generative AI is changing software engineering fast enough that confident predictions about the field's future are themselves unreliable, so engineers and organizations should focus less on forecasting the end-state and more on adapting skills, protecting junior pipelines, and treating the engineering team (not the individual) as the unit that has to stay productive.
• Cognitive Surrender AddyOsmani.com · 2025-01-01 source ↗ Reader 🖥️
  When software engineers stop forming independent views of AI-generated outputs — crossing from cognitive offloading to cognitive surrender — they accumulate comprehension debt that compounds invisibly until a crisis reveals that no one on the team can reconstruct the system from first principles; the antidote is not refusing AI tools but cultivating a posture of mutual amplification: thinking *with* the model rather than delegating thinking *to* it.
• Transcript for Cursor Team: Future of Programming with AI | Lex Fridman Podcast #447 Lex Fridman · 2024-10-06 source ↗ Reader 🖥️
  AI coding tools should be built to maximize the human programmer's speed, control and agency over their code — not to replace programming with natural-language delegation to an autonomous agent — because the hardest and most valuable part of engineering is the dense sequence of small judgment calls that specifying intent upfront cannot capture, and because verifying AI-generated code is at least as hard a problem as generating it.
• Technology Radar: An opinionated guide to today's technology landscape (Volume 30) Thoughtworks (Technology Advisory Board) · 2024-04-03 source ↗ Reader 🖥️
  As AI assistance shifts from an individual developer's tool to something that must be engineered at the team level, organizations need deliberate, disciplined practices (team-shared prompts and RAG-grounded knowledge over ad hoc fine-tuning, and reformed PR/CI practices to absorb AI-increased throughput) rather than either overenthusiastic LLM adoption or business-as-usual team process.
• Automated Bug Fixing at Facebook Scale ByteByteGo · 2024-03-05 source ↗ Reader 🖥️
  SapFix demonstrates that an end-to-end automated program-repair pipeline — combining mutation- and template-based patch generation (fed by patterns from Getafix), automated test design (Sapienz), and static-analysis fault localization (Infer) — can operate at industrial, multi-million-line-codebase scale, but even at Facebook's scale the system is deliberately stopped one step short of full autonomy: it proposes tested candidate patches and routes every one through a specific, context-qualified human reviewer rather than deploying any fix on its own.
• How soon AI will start firing programmers? Yegor Bugayenko · 2023-09-04 source ↗ Reader 🖥️
  Writing in September 2023, weeks into the ChatGPT era and before any coding agent existed, Bugayenko predicts that AI 'robots' will progressively absorb a widening list of software-engineering tasks — starting with low-stakes, assistive work (bug reporting, pull-request review, refactoring, documentation, backlog grooming) and ending, as the furthest-off and most consequential item, with AI monitoring individual programmers' activity to appraise their productivity and determine 'which human contributors are most valuable to their projects' — so that the title's question about firing programmers is answered not by a date but by a position in the list: last.
• How Coders Can Survive—and Thrive—in a ChatGPT World IEEE Spectrum · 2023-07-03 source ↗ Reader 🖥️
  Programmers remain relevant in an LLM-centered coding world not by out-generating AI at writing code, but by doubling down on what AI does not supply — problem-solving, software-engineering fundamentals, structural judgment, precise communication of intent, and critical scrutiny of AI output — while treating AI tools themselves as a fast-moving, interchangeable part of the workflow rather than a fixed skill to master once.
• 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.
• How do software development teams manage technical debt? - An empirical study Jesse Yli-Huumo, Andrey Maglyas, Kari Smolander · 2016-08-08 Reader 🖥️
  Software development teams manage technical debt unevenly and mostly informally -- across eight distinct activities (identification, measurement, prioritization, prevention, monitoring, repayment, documentation, communication) teams sit at different maturity levels (unorganized, received, organized), and the key differentiator is not tooling but whether TD communication and documentation are treated as first-class practices, since every other activity depends on TD being visible and discussed rather than left in individual developers' heads.

Propositions touching this concept (129)

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

2016-08

• explicitTD prevention practices (coding standards, code review, Definition of Done) are well understood, cheap, and already set up in most teams, yet applied only occasionally because they are optional and compete with time spent on new features.
  How do software development teams manage technical debt? - An empirical study · p8

2018-06

• explicitSystems being internally open (any team may submit a pull request) does not weaken architectural governance, because approval authority for major changes stays with the custodian regardless of who authored the change.
  What good software looks like at REA · p8

2019-02

• explicitCode review is most effective when performed as the code is being developed, not after the fact — which is why the 'experimental' section where review isn't enforced is discouraged for anything beyond throwaway exploration.
  Software Engineering at Google · p3

2020-07

• explicitMandatory pre-commit code review hinders developer velocity almost invariably, because CI plus review turnaround routinely takes minutes to days rather than the seconds required for review to be effectively free.
  Post-Commit Reviews != Post-Deployment Reviews · p1
• explicitCode review's actual, measured benefit is mostly knowledge transfer, team awareness, and improved solutions -- not defect detection, which comprises only a small proportion of review comments.
  Post-Commit Reviews != Post-Deployment Reviews · p2

2021-01

• explicitPull requests were designed to let maintainers vet contributions from untrusted outside contributors, not to review work from trusted teammates.
  Why your team doesn't need to use pull requests · p1
• explicitUsing pull requests to review your own team's code is like making family members pass through airport security to enter your home — a costly control applied to a problem (untrusted actors) that doesn't exist on your own team.
  Why your team doesn't need to use pull requests · p2
• explicitA pull request introduces a delay between finishing a change and getting it integrated and tested with the rest of the team's current work, which Continuous Integration is designed to avoid.
  Why your team doesn't need to use pull requests · p3
• explicitThe typical PR workflow — one pull request per completed feature or story, taking more than a day — violates Continuous Integration's requirement to integrate everyone's work into the mainline at least daily.
  Why your team doesn't need to use pull requests · p5
• explicitPairing, periodic (e.g. weekly) group reviews, and post-integration pipeline-approval gates each provide meaningful human code review without delaying the CI integration/feedback loop, and can be combined.
  Why your team doesn't need to use pull requests · p8

2022-08

• explicitCode review conducted asynchronously, days after the code was authored, forces the reviewer to reconstruct context the author already had, which both slows review and increases the risk that logical defects pass unnoticed while reviewers fixate on surface style issues.
  Mob Programming – key issues it can solve, benefits, and learnings · p1
• explicitCode review is inherently a synchronous, face-to-face activity, and most advice for optimizing asynchronous code review fails because it doesn't recognize this.
  Mob Programming – key issues it can solve, benefits, and learnings · p5
• 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
• explicitPer Theory of Constraints, any local improvement that isn't applied at the actual system bottleneck is illusory — most attempts to fix asynchronous code review (better PR tooling, more reviewers, bigger batches with less frequent release) fail for this reason, because none of them address the real constraint of hand-off-induced queueing.
  Mob Programming – key issues it can solve, benefits, and learnings · p15

2022-11

• explicitcorroboratedContinuous, real-time code review by the whole team — an inherent side effect of working together rather than a scheduled step — drives both defect rates and the transaction cost of review toward zero.
  Software Teaming: A Mob Programming, Whole-Team Approach · p13

2023-02

• explicitAs AI coding tools get integrated into more parts of the development workflow (code review, defect fixes, test writing), developers' work shifts toward spending more time assessing AI suggestions relative to the task than doing the task themselves.
  Papers on the UX of AI programming assistants · p6

2023-07

• explicitAI-generated code can contain security vulnerabilities, and the experienced-engineer skill of recognizing common vulnerability patterns and 'red flags' — reinforced by code review and strong test pipelines — is becoming a more important part of the software-engineering skill mix, not a less important one.
  How Coders Can Survive—and Thrive—in a ChatGPT World · p14

2023-09

• explicitAI will review pull requests from both humans and other AI, leaving annotated line-level critique and persisting its suggestions, to the point that a PR author may not know whether their reviewer was human or robotic.
  How soon AI will start firing programmers? · p2
• explicitAI will autonomously select and submit micro-refactorings as pull requests, without compromising functionality or making sweeping changes, incrementally improving code primarily for machine (not human) readability over time.
  How soon AI will start firing programmers? · p3
• explicitAI will generate fixes for registered bugs and submit them as pull requests that explain the fix's rationale, urgency, and alternatives, with the expectation that human developers will simply integrate the changes rather than author them.
  How soon AI will start firing programmers? · p4

2024-04

• explicitWith AI coding assistants increasing individual coding throughput, teams tend to produce larger pull requests, which puts more pressure on the already-strained batch-and-wait async code review process that substitutes for true continuous integration.
  Technology Radar: An opinionated guide to today's technology landscape (Volume 30) · p3

2024-10

• explicitdevelopedAI adoption is now broad and fairly uniform across industries (75.9% of respondents rely on it for at least one daily task), and it measurably improves individual-level outcomes (flow, productivity, job satisfaction) and process measures (code quality, internal documentation quality, code review speed, approval speed) and team/organizational performance.
  2024_final_dora_report · p1
• explicitWhen the author of a code change is a language model rather than a person, the review interface no longer needs to serve the author's experience at all — it can be designed entirely around making the reviewer's job fast, easy and productive, which is a more creative design space than imitating GitHub-style code review.
  Transcript for Cursor Team: Future of Programming with AI | Lex Fridman Podcast #447 · p10

2025-01

• implicitCode review as currently practiced in most organizations is structurally unable to catch surrender artifacts, because the reviewer may also be surrendering.
  Cognitive Surrender · p12

2025-02

• explicitEven when an agent fully implements a change and opens a pull request on its own, a human should still review the code before merging; the agent does the grunt work, but merge authority stays human ('I'm not going to merge this... human in the loop').
  The Future of Work by Henrik Kniberg · p8
• explicitAt the activity level, time spent on coding, documentation, and code refactoring positively predicts both productivity and satisfaction, while time on development-environment setup and communication negatively predicts both; security & compliance and PR/code review specifically depress satisfaction without a statistically significant productivity effect.
  Time Warp: The Gap Between Developers' Ideal vs Actual Workweeks in an AI-Driven Era · p4
• explicitDevelopers who feel highly productive but dissatisfied are disproportionately spending time on PR/code review, monitoring & dashboards, communication, and mentoring/onboarding — marking these as the best candidates for automation because the work is valuable but not wanted.
  Time Warp: The Gap Between Developers' Ideal vs Actual Workweeks in an AI-Driven Era · p5

2025-06

• explicitFor production work, the author reviews and tests every agent-generated pull request himself before merging, treating the human who merges a change as responsible for it regardless of whether a human or an agent wrote it.
  Coding agents have crossed a chasm · p3

2025-07

• explicitWorking in pairs made large pull requests unnecessary because review happens as the work is produced, not after it's finished.
  Pair Programming Fixed Our Pull Request Bottlenecks · p1
• explicitThe team satisfies its 'four eyes' compliance requirement through pairing itself, not through genuine PR review; the pull request has become a compliance formality rather than a real review gate.
  Pair Programming Fixed Our Pull Request Bottlenecks · p2

2025-09

• explicitAI-enabled parallelism (Faros AI's July 2025 telemetry across 10,000+ developers in 1,255 teams: +9% tasks, +47% pull requests per developer per day) trades typing time for more context-switching, orchestration, and validation overhead across more parallel workstreams, canceling out much of the apparent speed-up.
  The productivity paradox of AI coding assistants · p5

2025-11

• explicitEvery AI-generated code slice should be treated as a pull request from a highly productive but untrustworthy collaborator, reviewed carefully before being trusted.
  How AI will change software engineering – with Martin Fowler · p7

2025-12

• descriptivecorroboratedTechnologists' ability to depersonalize critique is the trained product of code review — a daily practice of giving and receiving feedback on work invested in over time selects for people who can hear 'this isn't good enough' without identity-collapse.
  6) Catherine Janson og Kjerstin Wester: The power of two! · p11
• explicitDevelopers want 'background agents' — the ability to queue tasks for agents to complete autonomously, even overnight, and return only to review finished pull requests ('fire and forget').
  10 Things Developers Want from their Agentic IDEs in 2025 · p2
• explicitcontestedThe real function of code review is 'mental alignment' — keeping the whole team synchronized on how and why the codebase is changing — not primarily correctness-checking; as AI-generated code volume grows past what any individual (including a technical lead) can read, review should shift to the plan/research artifact level rather than the code-diff level to preserve that alignment.
  No Vibes Allowed: Solving Hard Problems in Complex Codebases – Dex Horthy, HumanLayer · p10

2026-01

• explicitThe task-implementation phase should be scoped so the agent works autonomously from ticket assignment through to a complete, quality-passing, mergeable pull request, surfacing to the human only when finished or genuinely blocked.
  Coding Agent Development Workflows · p1

2026-02

• explicitDespite Claude authoring 100% of his code since November, a human review layer still exists over AI-generated work at Anthropic: Claude performs automatic review on 100% of pull requests, but a human layer still follows that, except for pure, throwaway prototype code that will never run anywhere.
  Head of Claude Code: What happens after coding is solved | Boris Cherny · p1
• explicitThe team mechanically enforces the knowledge base's integrity: dedicated linters and CI jobs validate that documentation is up to date, cross-linked, and structured correctly, and a recurring 'doc-gardening' agent scans for documentation that no longer reflects real code behavior and opens its own fix-up pull requests.
  Harness engineering: leveraging Codex in an agent-first world · p7
• explicitThe team's working answer to agent-driven entropy is to encode 'golden principles' (opinionated, mechanical rules) directly into the repository and run a recurring background-agent cleanup process that scans for deviations, updates quality grades, and opens small, fast-reviewable (under a minute), often auto-merged refactoring pull requests — paying down resulting technical debt continuously in small increments rather than letting it compound into painful bursts.
  Harness engineering: leveraging Codex in an agent-first world · p14
• explicitCode review serves four bundled functions (mentorship, consistency, correctness, trust) that each need a separate replacement mechanism
  The Future Of Software Engineering · p13

2026-03

• implicitdevelopedAI-assisted code review is more effective than non-AI alternatives for identifying supply-chain risks.
  CNCF and Kusari Partner to Strengthen Software Supply Chain Security Across Cloud-Native Projects · p8
• explicitThe process of extracting these instructions through structured interviews with senior engineers has value beyond the resulting artifact — it surfaces previously unarticulated disagreements among the seniors themselves, as when two senior engineers were found to have silently held different thresholds for a 'critical' versus 'important' security concern, a disagreement that had never surfaced because each reviewed different pull requests.
  Encoding Team Standards · p4
• explicitestablishedAI amplifies existing engineering practice: DORA-style guardrails (tests, CD, code review) become more important, not less, with AI-assisted development.
  12) Greger Teigre Wedel: Når sjefen har svaret, tier resten · p14

2026-04

• explicitcorroboratedDevelopers are now doing more code review than ever; there is no clean way to reconcile small-PR discipline with parallel AFK loops — accept the increased review burden.
  [FULL WORKSHOP] AI Coding For Real Engineers - Matt Pocock, AI Hero · p14
• explicit⚡ disputed & corroboratedAI has absorbed the creative, enjoyable parts of development (architecture, structure decisions) and left developers with the least enjoyable part: code review
  Podcast: The AI Joy Gap: Why Some Developers Thrive While Others Struggle · p2
• explicitdevelopedExisting code review tooling and pull request workflows are not designed for the volume and nature of AI-generated code, and need fundamental redesign
  Podcast: The AI Joy Gap: Why Some Developers Thrive While Others Struggle · p4
• explicitOver-editing makes code review dramatically harder and risks quiet degradation of codebase quality
  Coding Models Are Doing Too Much · p3
• explicitestablishedCode generation was never the real bottleneck in software development; code review, planning, and organizational readiness are the actual constraints.
  Measuring AI impact, assessing readiness, and new data trends · p1
• explicitcorroboratedAs models become cheaper and more capable, intelligence ceases to be the bottleneck; the real constraints become code review, distribution, production readiness, and operational governance.
  AAIF's MCP Dev Summit: Gateways, gRPC, and Observability Signal Protocol Hardening · p6
• explicitAll agentic interactions with GitHub should rely on first-class platform primitives (agentic code review, an agent chat primitive, agent mailboxes) rather than being bolted onto the existing product via GitHub Actions — and GitHub itself should be a platform other agents build on, not an agent competing with them.
  Does GitHub still merit "top git platform for AI-native development" status? · p9
• explicitTeams should build products that are 'on the edge of working' -- Claude Code's code review product failed repeatedly because earlier models weren't accurate enough, but because the prototype already existed, the team could immediately swap in Opus 4.5 and then 4.6 to test whether the capability gap had closed; teams that wait for the model to be ready first will always be a cycle behind those who build ahead of readiness.
  Lenny Rachitsky's Post · p4
• explicitWhen maintainership transfers, the buyer inherits commit access, reputation, and the implicit trust of every user who enabled automatic updates — no code review is triggered and no change-of-control notification is sent.
  Attacker Bought 30 WordPress Plugins on Flippa and Backdoored All of Them · p2

2026-05

• implicitcorroboratedReviewing the exceptions an agent created (suppressed warnings, increased thresholds) is a more efficient entry point for human code review than reading the whole diff.
  Maintainability sensors for coding agents · p7
• implicitSystem design intuition, recognizing over-complex abstractions, weighing trade-offs, and critical code review are judgment capacities that cannot be acquired by observing an agent's output — they require the developer's own active exercise.
  How I Use Agents Without Stopping My Own Growth · p8
• explicitThese task-level gains attenuate sharply moving up the production hierarchy: the 180% cumulative commit effect falls to roughly 50% for the number of projects and to about 30% for actual releases; for sync agents specifically, a 741% increase in lines of code translates into only a 65% increase in pull requests and just a 20% increase in releases.
  Writing Code vs. Shipping Code: Productivity Effects Across Generations of AI Coding Tools · p2
• explicitcorroboratedISO 27001 and SOC 2 require a control objective for change review, not a specific mechanism like pull requests.
  Four Eyes Without Pull Requests · p1
• explicitA pull request approval artefact does not, on its own, constitute evidence that real review occurred.
  Four Eyes Without Pull Requests · p2
• explicitcorroboratedMost teams keep pull requests not because they are the best review mechanism, but because they assume audit compliance demands them.
  Four Eyes Without Pull Requests · p7
• explicitCoupling metrics' best use is triage of human (or agent) attention during code review — surfacing changes whose blast radius is large — not autonomous quality judgement.
  Three more static code analysis sensors · p10
• implicitOff-the-shelf 'skills' from named experts (Khononov's Modularity Skills) raise the floor of LLM code review enough that organisations need not author their own modularity prompts.
  Three more static code analysis sensors · p19
• explicitLarge agent-generated pull requests are not merely harder to review — they are review-defeating, because honest review exceeds available cognitive capacity, which means agent-coded systems systematically erode the review function.
  KI, utvikling og følelser · p5
• explicitMatteo Collina proposed adding a first-class virtual file system module (node:vfs) to Node.js core via a ~19,000-line, 100-file pull request, built largely with Claude Code over Christmas 2025, with Collina stating he 'pointed the AI at the tedious parts' while personally handling architecture, API design, and reviewing every line.
  NodeJS Proposes Built-In Virtual File System, Sparking Debate Over AI-Generated Contributions · p1

2026-06

• explicitdevelopedProductivity gains attenuate sharply as work climbs the organizational hierarchy: a 741% increase in lines of code written translates to only a 65% increase in pull requests and just a 20% increase in actual software releases.
  AI isn't making developers more productive – it's making them busier · p2
• 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.
  From Async Code Reviews to Co-Creation Patterns · p1
• explicitdevelopedLarge PRs reduce reviewer engagement per line of code, leading to 'LGTM syndrome' and unsteered code reaching main.
  From Async Code Reviews to Co-Creation Patterns · p3
• 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.
  From Async Code Reviews to Co-Creation Patterns · p14
• implicitestablishedThe primary purpose of code review is to build in quality and accelerate learning — not to gate, audit, or enforce separation-of-duties.
  From Async Code Reviews to Co-Creation Patterns · p15
• explicitAs AI-generated commit volume grows, code review should shift from line-by-line style nitpicking toward verifying architectural integrity, supported by bundled AI-generated risk-assessment summaries attached to each PR, automated style enforcement, and a 'Conditional LGTM' (approval contingent on automated tests passing) to remove cross-timezone review delays.
  Spec-Driven Production Grade Development In The Age Of Vibe Coding · p8
• explicitAt the largest scale (hundred-million-line legacy codebases), effective automated code review requires a knowledge graph combining structural (graph traversal), semantic (vector), and exact (full-text) retrieval, because flattening code into a vector store destroys the structural relationships — class-to-file, function-call-to-requirement — that answer 'what breaks if I change this?'
  Spec-Driven Production Grade Development In The Age Of Vibe Coding · p12
• explicitestablishedA team-scale agent harness must do three things a personal harness never needed to: remember decisions across people and sessions, coordinate several agents working in parallel without collision, and give a human a checkpoint for judgment calls — the same role a reviewer plays on a pull request.
  Git real: AI agents aren’t just for solo developers anymore · p3
• explicitA team's coding-agent pain sorts into exactly one of three distinct problem types — coordination (too many agent-generated pull requests), management (too many different agents to run), or control (agents deploying ungoverned apps) — and each of the three June launches was purpose-built for one type, not the others.
  Git real: AI agents aren’t just for solo developers anymore · p5
• explicitMost steps of most operational processes (e.g. routine code review, routine ticket triage) can be fully automated for their base case with a good-enough harness and domain context, while a minority of higher-risk steps still require human judgment; failing to distinguish base case from edge case creates unnecessary risk.
  Revised rules of engineering leadership. · p5
• explicitestablishedMature agentic engineering practice routes tasks to different models by cost/complexity — large frontier models for requirements/architecture/complex implementation, smaller cheaper models for deterministic work like test generation, code review, and CI/CD monitoring — to avoid paying premium token prices for trivial tasks.
  The New SDLC With Vibe Coding: From ad-hoc prompting to Agentic Engineering · p13
• explicitAI amplifies the engineering culture it lands in: organizations with strong testing practices, clear architectural standards, and healthy code review processes get dramatically more value from AI-assisted development than organizations without those practices.
  The New SDLC With Vibe Coding: From ad-hoc prompting to Agentic Engineering · p15
• explicitAsynchronous code review is not an adequate substitute for pair programming, because the dynamics around it (mutual deferral, sunk-cost reluctance, reviewer-as-bottleneck, context switching) systematically produce sloppy or superficial reviews.
  On Pair Programming · p2
• explicitcorroboratedPairing functions as continuous, live code review ('code review on-the-go'), catching errors and improving design as code is written rather than after.
  On Pair Programming · p4
• explicitWhen a team must exempt work from pairing, they should still monitor pull request lifetimes carefully to preserve continuous integration.
  On Pair Programming · p8
• explicitKeeping agent-generated pull requests small (around 500 lines) is a hard discipline because review, not generation, is the bottleneck; a PR that reaches 10,000 lines means the process has failed, since no one reviews that properly.
  We don't write code anymore · p4
• explicitestablishedBecause AI cannot be held accountable, the human who reviews and merges bears full responsibility for what ships — exactly as if an anonymous human contributor's pull request had caused the same harm.
  Should You Still Become a Software Engineer in 2026? GitHub VP · p3

2026-07

• explicitcorroboratedCode review used to keep pace only by a 'happy accident of relative speed' — a reviewer could read faster than an author could write — and that precondition no longer holds; the team also absorbed how the system fit together as an unplanned side effect of that reading.
  Agentic Code Review · p2
• explicitHuman brains are not well-suited to the validation/quality-gate role that code review assigns them; humans are 'the weakest link' when it comes to catching errors through inspection.
  AI Demands More Engineering Discipline, Not Less · p6
• explicitAWS's expanded DevOps Agent moves AI validation earlier in the software lifecycle — from post-deployment incident response into pre-merge code review (Release Readiness Review) and pre-production test generation (Autonomous Release Testing).
  AWS Expands DevOps Agent with AI-Powered Release Management to Validate Code Before Production · p1
• explicitdevelopedEnforcing the architecture's dependency direction at the build-tool level (Gradle module dependency configuration) is more reliable than relying on developer discipline or code review, because violating code will not compile at all.
  Presentation: Clean Architecture for Serverless: Business Logic You Can Take Anywhere · p6
• explicitcorroboratedAI puts pressure on DORA's long-standing finding that small batch sizes improve delivery performance, because models tend to suggest large change sets or pull requests that are harder to review and carry more risk; the remedy is collaborating with AI to decompose large changes into smaller, independently deployable units.
  AI-Assisted Software Development: Team Profiles and Capabilities for Putting Research into Action · p7
• explicitAgent Skills, invoked via natural language or a slash command, let developers and an LLM collaborate conversationally to generate code, validate configs, run applications locally, and create pull requests for streaming pipelines.
  Kafka App? There's a Skill for That · p2
• explicitLightweight telemetry — a hook that fires a 'started' event when a Skill is invoked, and a wrapper that fires a completion event when the agent opens a pull request, both flowing through an existing company event pipeline into a BigQuery table — lets a platform team measure which Skills are used, how often they reach a PR, and where developers still need support.
  Kafka App? There's a Skill for That · p8
• explicitdevelopedThe emerging industry pattern is 'policy-as-config': guardrail, segmentation, and routing rules declared as version-controlled configuration, reviewed in a pull request, and deployed independently of the applications behind the gateway.
  An Evolutionary Architecture Pattern for Managing AI's Pace of Change · p8
• explicitA colleague (Jigar Jani) does almost all of his coding with Qwen 35B MoE (4BIT) on a 48GB MacBook against a real-world Python and React codebase by continuously enhancing his harness with skills (Graphify, Understand Anything), while stressing that code review is essential.
  Experiences with local models for coding · p15
• explicitThis shift is not confined to education: a polished memo no longer proves real thinking behind it, a working prototype no longer proves product sense, and a passing pull request no longer proves the developer changed the code carefully — so evaluation in code review, hiring, and performance management must also move toward observing how people think, choose, revise, and recover.
  Teaching Coding When AI Can Write the Code · p12
• explicitAn interactive Copilot CLI session presents tabs across the top — a default Session tab, a Gists tab, and, when run inside a repository, Issues and Pull requests tabs scoped to that repo — navigable by Tab key or mouse and reorderable/hideable.
  GitHub Copilot CLI Gets Tabs and No-Config-File Tool Setup in Redesigned Terminal UI · p2
• explicitDevelopers can act on GitHub issues and pull requests without leaving the CLI: pressing c drops a reference into the prompt (to investigate/fix/comment/review), o opens the item in the browser, and / runs a custom GitHub search.
  GitHub Copilot CLI Gets Tabs and No-Config-File Tool Setup in Redesigned Terminal UI · p3
• implicitBringing GitHub objects (issues, pull requests, gists) into the terminal reduces the need to switch to a browser and keeps developers working in a single surface.
  GitHub Copilot CLI Gets Tabs and No-Config-File Tool Setup in Redesigned Terminal UI · p8
• explicitThe agent's context window is itself its attack surface: any content it reads — issues, pull requests, comments, or files — can be weaponized if the agent treats that content as instructional input, regardless of the content's original purpose.
  GitLost: How We Tricked GitHub's AI Agent into Leaking Private Repos · p6
• explicitA team's testing norm can be installed by a leader modeling the identity claim ('we write tests') before it's fully true, then sustained by reinforcing the payoff in code review — pointing out missing tests, not bugs — until every caught bug becomes proof the practice works.
  How Do You Know That? · p5
• explicitSecurity requirements are typically defined during design review but enforced and verified much later, during code review, often without full context — a persistent, recurring gap in large engineering organizations.
  Dropbox Integrates MCP and Dash to Close the Gap Between Security Design and Code Review · p1
• explicitIn interactive code review, developer trust in an AI-surfaced finding depends more on relevance, traceability, and restraint (a few grounded findings) than on retrieval depth or exhaustiveness.
  Dropbox Integrates MCP and Dash to Close the Gap Between Security Design and Code Review · p8
• explicitDependabot now waits at least three days by default before opening a pull request for a non-security dependency update.
  GitHub Introduces Default "Cooldown" Policy for Dependabot Version Updates · p1
• explicitcorroboratedThe most valuable measurement layer is DevEx: flow-state signals (reopened commits, change requests, commits per pull request) combined with continuous, open-ended personal feedback — because two correlated-looking numbers can be coincidental, and only direct conversation reveals real user experience.
  Presentation: Platform Engineering for Everyone - Success Can’t Be Coded · p12
• explicitAs AI-generated pull requests flood engineering teams, the limiting skill shifts to leadership and human attention — reviewing, deciding what deserves scrutiny, and using AI deliberately rather than for speed alone — not to generating code faster.
  Radar Trends to Watch: July 2026 · p6
• explicitThe skills now compose a complete lifecycle: Grill -> Spec -> Tickets -> Implement -> Code Review.
  mattpocock/skills v1.1: does /wayfinder beat grill-with-docs? · p5
• implicitCode review should be driven by named, catalogued refactoring smells rather than ad hoc reviewer judgement.
  mattpocock/skills v1.1: does /wayfinder beat grill-with-docs? · p7
• explicitConsequently, the majority of investment in an AI-assisted SDLC should shift to verification (testing plus code review) and the context engine, not to code generation.
  Presentation: The Multi-Agent Approach: Building Reliable and Controllable Software Development Automation · p3
• explicitcorroboratedHuman code review has quietly collapsed at AI volume — a large share of PRs merge with no human review (~80%) — driven both by review moving off-platform (only ~60% discuss reviews in GitHub/GitLab/Bitbucket) and by reviewers rationing attention inversely to diff size (5 lines get 50 comments, 500 lines get 'looks good to me').
  Presentation: The Multi-Agent Approach: Building Reliable and Controllable Software Development Automation · p9
• explicitIf code review is the bottleneck limiting how much autonomy an agent can safely be given, the correct response is to invest in sharpening the review skill itself, not in expanding the agent's unsupervised scope.
  Addy Osmani's Post (Agent Skills 0.6.3 release) · p1
• explicit⚡ disputed & corroboratedBecause engineers can no longer personally read all the AI-generated code now being merged at high volume, trust in that code must instead come from layered automated, out-of-process verification — AI code review, a dedicated security scanner, and fuzz testing — rather than from a human reading every diff.
  How building software is changing at Anthropic · p10
• explicitAn implementation skill should be deliberately thin, leaning on the agent's priors and the harness rather than encoding detailed instructions: /implement is 'very, very simple' ('implement the work described... use TDD where possible at pre-agreed seams, run type-checking and single test files regularly and the full suite once at the end, then code review, then commit') and earns its place mainly by naming and anchoring a stage in the flow, not by adding instruction volume.
  New Skills! v1.1 brings /wayfinder, /research, /implement, /to-spec, /to-tickets · p4
• explicitCode review should run as independent concerns in parallel: a standards axis (does the code conform to the repo's documented coding standards) and a spec axis (does the code faithfully implement the originating spec/issue), each a separate sub-agent — and coding standards belong in a separate coding-standards file, kept out of the always-loaded AGENTS.md and pulled in at review time, where they are most useful.
  New Skills! v1.1 brings /wayfinder, /research, /implement, /to-spec, /to-tickets · p6
• explicitAt roughly 10x velocity, every node in the developer ecosystem hits limits it never had to face — build times, test compute (grows quadratically with code size), code review, version-control performance, and internal APIs that suddenly need public-grade hardening.
  SWLW #710: Revised rules of Eng Leadership, When AI costs more than the engineer, and more. · p6
• explicitScott Hanselman treats AI-generated code with the same zero-trust, adversarial review he would give an anonymous stranger's open-source pull request — cross-checked with multiple models — rather than extending AI any presumption of competence.
  SWLW #711: The laws of this world (game theory), Should you still become a Software Engineer in 2026, and more. · p1

2026-08

• explicitQuality control relocates into the harness, environment, and operating system surrounding the agent, rather than residing in the code or in code review.
  Addy Osmani's Post · p4
• explicitManual architectural review does not scale down to the granularity of every pull request, contract change, workflow trace, or AI-generated patch — this capacity gap is the underlying justification for the agentic layer.
  Article: Agentic Fitness Functions: Extending Evolutionary Architecture Beyond Deterministic Rules · p11
• explicitCode review is overrated and the least valuable part of what humans contribute to software engineering, because humans are good at conversation and deciding what to build, not at reading code to check correctness, syntax, and bugs.
  Stop being skeptical about AI for development with Charity Majors · p8
• explicit⚡ disputed & corroboratedStacked pull requests reduce the code-review bottleneck by shrinking the scope of what each PR asks a reviewer to understand, not by making review itself faster.
  GitHub Brings Stacked Pull Requests to Public Preview · p2
• explicitCode review has become the primary control point determining whether AI improves or degrades software quality.
  GitHub Brings Stacked Pull Requests to Public Preview · p7
• explicitThe shape of a pull request is changing under agentic coding: instead of just a diff and a description, a PR now carries links to dashboards showing the local build under realistic load — and this shifts the reviewer's central question from 'did the agent understand the ticket?' to 'does the running system match our expectations?'
  Grafana's gcx and MCP Server Reach GA for Telemetry-Driven Agent Development · p6
• explicitReview capacity, not technology, is reported in the discourse as the practical bottleneck: nightly agent-opened pull requests can outpace what teams can review, turning the human review gate into a 'rubber stamp' while the pipeline still reports green.
  Loop Engineering: Building Blocks, Adoption, and Impact · p9
• explicitThe large productivity claims attached to loop engineering (e.g., Stripe's internal 'Minions' system producing ~1,300 agent-written pull requests per week; a loop pointed at Firefox producing 423 security fixes in one month) rest entirely on self-reports and anecdotes, with no published study or dataset the authors could find supporting either figure.
  Loop Engineering: Building Blocks, Adoption, and Impact · p10

2026-09

• explicitManual, human-only code review cannot scale with AI-generated code volume, but the solution is neither simply adding more human reviewers nor removing humans entirely — it is redistributing review into a layered, continuous, risk-tiered system (deterministic checks, author/review-agent loops, adversarial and multi-agent AI review, selective human judgment).
  Agentic AI and Code Reviews · p1
• explicitcorroboratedCode review's value substantially exceeds defect-finding: citing a Microsoft study and two further empirical papers, most review activity addresses maintainability, style, alternate-solution discovery, and knowledge sharing — 'evolvability' risk — rather than catching functional bugs, which means any redesign of review must preserve these non-defect functions, not just correctness checking.
  Agentic AI and Code Reviews · p2
• explicitdevelopedSpec-Driven Development relocates the primary review gate from implementation to the plan: once intent is reviewed and hardened up front, code review's job shifts from trying to catch what went wrong to verifying that a trusted, already-approved plan was faithfully executed — because by the time code exists, the most consequential (and hardest to reverse) decisions have already been made.
  Agentic AI and Code Reviews · p7
• explicitcorroboratedFunctional correctness throughout the refactor was verified by a replay-trace harness comparing rollback-state hashes frame by frame, not by human code review alone — automated, deterministic equivalence checking was the actual safety mechanism that made large-scale agentic refactoring trustworthy.
  Case Study: Refactoring at Scale with Agents · p3
• explicitAs a harness matures, human code review shifts from reading every diff to auditing verdicts and sampling deeply where the evidence looks thin — the same quality bar held at a higher operating altitude, not a lowered one.
  From AI Code to Trusted Software: Harness Engineering in Practice · p12
• explicitCode review practice has shifted toward attaching the full prompt history (including failed approaches) to large AI-generated PRs, so reviewers can judge how much exploration went into the change rather than guessing how well the author understands a 10,000-line diff.
  How Anthropic Builds And How Engineering Will Change Soon | Thariq Shihipar · p21
• explicitModeling infrastructure-as-code at too fine a grain (separate node pools per technology, multiplied across clouds, environments, geographies, and customer product sets) is what turned a routine task — rolling an OS image for a CVE — into what was effectively a full-time job of generating and merging hundreds of pull requests.
  Presentation: How To Run on Three Clouds at Once, and When Not To · p9
• explicitcorroboratedBuilding a custom operator (the Cluster Lifecycle Operator, CLO) that manages node pools at a higher level of abstraction — letting an engineer specify one target image for an entire platform — collapsed what had been hundreds of pull requests into one PR per platform.
  Presentation: How To Run on Three Clouds at Once, and When Not To · p10
• explicitAs individual developers use agent orchestration to run spec-driven work across many tickets in parallel, the resulting surge in pull requests strains shared platform infrastructure (e.g., CI runners), shifting scale pressure from human pace to agent pace.
  Presentation: Platform Engineering in the Age of AI · p16
• explicitCode review functions as a mentorship investment reserved for contributors who can grow into skilled, long-term core team members ('contributor poker'); AI-assisted contributors are reliably in the 'drive-by' category and are not learning, so investing review time in them is not worthwhile.
  Andrew Kelley Interview: Why He Built Zig, Banned AI Contributions, and Moved Zig off GitHub · p3

2026-10

• explicitCurrent personal practices for managing cognitive debt: normalize throwing away code (especially proof-of-concepts), spend more time planning upfront to build a solid mental model before the agent starts writing code, and use pull requests as the specific checkpoint to 'repay' cognitive debt when feeling overwhelmed.
  Guillaume Barrois' Post · p4
• explicitWritten guides for culture and communication norms (e.g. when to use email vs. Slack, how to run code review) function as a shared source of truth that lets teams agree on process upfront, reducing reliance on oral tradition as the organization outgrows the scale at which tacit knowledge transfer alone works.
  Guide to scaling engineering organizations · p9

Tensions

Open gaps (85)

• incompleteThe article generates AFK volume — it concedes a loop can 'pile dozens of commits into a repo in hours' and Tip 11 has each iteration open a PR — yet treats review as trivially 'review the commits when you return' / 'you review when you're ready', never grappling with the review-jam / orchestration-tax that this volume creates. Notably, the SAME author's own workshop states plainly that 'developers are now doing more code review than ever' and that there is 'no clean way to reconcile small-PR discipline with parallel AFK loops — accept the increased review burden'; the tips article underplays what its author elsewhere admits, leaving human review capacity as the unexamined binding constraint.
  11 Tips For AI Coding With Ralph Wiggum — read next: Work on the human-review bottleneck and orchestration tax under agent volume: the busier-not-more-productive weak-link finding, the developer-as-evaluator role shift, and the same author's workshop treatment of the irreducible review burden.
• incompleteThe piece advocates video demos as the way to show an agent's work, but never addresses that a scripted storyboard exercises a predetermined happy path — it even stubs navigator.clipboard via injected JavaScript — so it demonstrates 'the flow runs as scripted', not 'the feature is correct'. The adjacent sqlite-utils story is the counter-example the piece doesn't connect: its release-blocking data-loss bug was invisible to any demo and caught only by code review. Demos verify liveness and UX, not correctness.
  Have your agent record video demos of its work with shot-scraper video — read next: Read on evals and property-based testing as complements to demos, and Geoffrey Litt's 'understand to participate' (quoted later in this same newsletter) on why watching output cannot substitute for conceptual understanding of the change.
• incompleteReview's knowledge-distribution function is named as real ('the team absorbed how the system fit together as a side effect of reading each other's diffs') but never re-examined. Once humans stop reading most diffs, the question of whether AI reviewers, evidence-gates or written intent can carry that team-comprehension role — or whether it simply erodes — is left open, even though it is a distinct job of review from bug-catching and intent-reconstruction.
  Agentic Code Review — read next: Empirical code-review research (Greg Wilson) on what review actually accomplishes; distributed-cognition literature (Hutchins, 'Cognition in the Wild') on knowledge spread as a side effect of shared reading.
• tensionThe talk argues that (1) AI amplifies whatever practices you have, and (2) pair programming is essential for reviewing AI output. But if your practice is already strong enough to benefit from amplification, why is the review burden so high? The high review burden suggests the AI is generating output that doesn't match team standards — which is the amplification-of-weakness problem the talk warns about.
  Presentation: AI-First Software Delivery: Balancing Innovation with Proven Practices — read next: Research on AI code quality vs. human code quality at different experience levels; studies on code review effectiveness for AI-generated code.
• incompleteParker frames the joy gap as greenfield vs. legacy but never examines whether the 'joy' experienced by greenfield developers is sustainable or genuine. Rapid AI-assisted prototyping may produce initial excitement that fades as technical debt accumulates or as developers realize they've lost depth of understanding.
  Podcast: The AI Joy Gap: Why Some Developers Thrive While Others Struggle — read next: Research on skill atrophy in automation-heavy domains (aviation, healthcare); Bainbridge's 'Ironies of Automation' for the classic formulation
• incompleteThe AI platform team concept is asserted but not developed. How does it differ from existing developer experience (DX) or platform engineering teams? What skills does it require? How does it avoid becoming a bottleneck itself? The analogy to Docker containers is gestured at but not followed through.
  Podcast: The AI Joy Gap: Why Some Developers Thrive While Others Struggle — read next: Team Topologies (Skelton & Pais) on platform team design patterns; internal developer platform literature
• 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.
  From Async Code Reviews to Co-Creation Patterns — read next: Cursor / Copilot / Claude Code workflow studies; AI-as-pair-partner literature; any post-2024 work on continuous AI review folded into authoring.
• 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.
  From Async Code Reviews to Co-Creation Patterns — 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.
  From Async Code Reviews to Co-Creation Patterns — read next: Threat modeling literature; architecture decision records; literature on outside-in review for security and design coherence.
• incompleteNo evidence (adoption numbers, incident-rate change, false-positive rate) is offered that this preview actually improves release safety or speed — the piece is a product announcement, not a study.
  AWS Expands DevOps Agent with AI-Powered Release Management to Validate Code Before Production — read next: Case studies or retrospectives after general availability.
• incompleteThe paper is written entirely from a Google/Antigravity-and-Gemini-CLI vantage point — every tool, product reference, and worked example (Antigravity, Gemini CLI, ADK, Spanner Graph, Vertex AI Agent Engine) is a Google product — so every claim about what 'coding agents' or 'AI' can or should do is implicitly a claim about this specific toolchain's current behavior, never flagged as distinct from more general, vendor-neutral claims about agentic coding.
  Spec-Driven Production Grade Development In The Age Of Vibe Coding
• incompleteThe three-tier continuous-review spectrum and the 'Where to start' closing section both frame tier adoption as a single team's own choice, but never address who decides and pays for a Tier 3 investment (knowledge-graph infrastructure, dedicated evaluation/observability, on-call ownership) when the triggering codebase or compliance requirement crosses several teams' boundaries — the same single-team vantage point as the first gap, applied specifically to the review-tooling investment decision.
  Spec-Driven Production Grade Development In The Age Of Vibe Coding
• uninformedThe approval-fatigue/burnout claim ('frequent AI users are 45% more likely to experience high burnout') is sourced to a single press report of industry survey data (CNBC citing Quantum Workplace) rather than a peer-reviewed study or the author's own organization's data, and the proposed remedies (Digital Quiet Hours, Agent Insight Sessions) are asserted without any evidence that they specifically reduce AI-approval-driven burnout, as distinct from general workplace wellness practices.
  Spec-Driven Production Grade Development In The Age Of Vibe Coding
• incompleteThe article never specifies what criterion separates a 'nearer-term' prediction from a 'further-off' one — is it required context window, required access to organizational/behavioral data, required trust from humans, or something else? Without a stated criterion, the ordering reads as intuition rather than a model, and it is impossible to tell whether Performance Appraisal is placed last because it is technically harder or because it is more consequential and uncomfortable to automate.
  How soon AI will start firing programmers? — read next: This corpus's material on AI-as-amplifier and AI-labor-disruption, for frameworks that do distinguish technical-capability constraints from organizational/social-adoption constraints on which AI capabilities actually get deployed.
• incompletePerformance Appraisal is described purely as a measurement-and-ranking capability ('determine which human contributors are most valuable') with no engagement with whether the underlying metrics (activity volume, comment sentiment, CI/CD failure correlation) would be a reliable basis for that determination — the article treats measurability as equivalent to validity.
  How soon AI will start firing programmers? — read next: extract-lenny-forsgren-measure-ai-developer-productivity, which argues at length that individual productivity metrics are easily gamed and often misleading in the AI era — directly undercutting the premise that an AI monitoring 'each programmer's activity' would produce a trustworthy appraisal.
• uninformedWritten before any agentic coding tool existed (ChatGPT 3.5 only, no tool use, no autonomous execution loop), the article has no way to anticipate that several of its 'assistive' predictions (PR review, bug fixing) would later be delivered not by discrete bot contributions to a repo but by persistent, scheduled, multi-run agent loops — a structural form this corpus's loop-engineering material shows is now central to how such capabilities are actually deployed.
  How soon AI will start firing programmers? — read next: extract-lulla-loop-engineering-building-blocks-adoption-impact and extract-osmani-loop-engineering, for how 'AI does code review' or 'AI fixes bugs' predictions cashed out structurally three years later.
• incompleteThe adoption results report that 131 of 165 generated patches passed all tests and 55 were reported to developers, but never say how many of those 55 were actually accepted and merged to production — the single number that would most directly validate (or undercut) the claim that automation plus human gatekeeping is working well. 'Reported' and 'adopted' are conflated throughout.
  Automated Bug Fixing at Facebook Scale — read next: Later Facebook/Meta engineering retrospectives on SapFix or its successors, if any exist in the corpus or elsewhere, for merge/acceptance-rate data.
• incompleteThe piece never explains why mutation-based repair is limited to Null Pointer Exceptions specifically, beyond noting that Facebook 'plans to cover more mutation strategies' — leaving open whether NPEs were chosen because they are mechanically easiest to patch via mutation, most frequent in the crash population, or safest to automate, each of which would carry different implications for which bug classes are good candidates for automated repair generally.
  Automated Bug Fixing at Facebook Scale — read next: extract-what-survived-contact#p5 and this corpus's agentic-testing material, for how today's systems reason about which categories of defect are safe to hand to automated remediation versus which require a human-authored fix.
• incompleteThe 'code review is overrated' claim is offered as a contrarian one-liner with no supporting evidence (defect rates, incident postmortems, comparative studies of eval-only versus human-reviewed pipelines), and does not address what happens to junior engineers' skill formation if review — historically a primary mechanism by which junior engineers learn to read and critique code — is deprioritized. This gap is made sharper by the episode's own timestamps listing a 'Junior engineers' segment (1:16:31) that this takeaways article does not summarize at all.
  Stop being skeptical about AI for development with Charity Majors — read next: The podcast's own 'Junior engineers' segment (unsummarized here); this corpus's systemic-apprenticeship material on skill transmission mechanisms.
• uninformedNo mention of how auto mode interacts with existing version control, code review, or CI/CD safety nets. In practice, auto mode operates within a broader development safety stack, and understanding the layered defense matters.
  Inside Claude Code Auto Mode: Anthropic's Autonomous Coding System with Human Approval Gates — read next: Anthropic's Claude Code documentation on integration with git workflows
• incompleteThe Undercover Mode discussion lacks any serious ethical analysis. A feature designed to let AI contribute to public repos without disclosure has implications for open-source trust, code review practices, and the integrity of contribution records. The thread treats it as either 'cool' or briefly 'an ethical landmine' without following up.
  Claude Code Source Leak Megathread — read next: Open source governance literature; existing policies on AI-generated contributions (e.g., Linux kernel policy)
• incompleteEvery play redefines the human's role (from author to reviewer, from implementer to orchestrator, from on-call responder to incident-queue triager) but the piece never addresses the human cost of that shift — skill atrophy from no longer writing code directly, morale effects of reviewing AI output all day, or how an organization trains new engineers who never practiced the skills the plays assume a senior reviewer already has.
  The AI-Native SDLC playbook — read next: Look for practitioner accounts (not vendor playbooks) of how teams that have run this kind of pipeline for a year or more describe the experience of the reviewer-not-author role, and whether junior engineers develop judgment without first doing the work themselves.
• uninformedThe piece is presented as consolidating 'real best practices our Applied AI team executes on a daily basis for our customers,' but every quantitative claim (leading/lagging indicators, 'elapsed time falls from weeks to hours') is prescriptive guidance on what to measure, not a reported result; no outcome data from an actual deployment appears anywhere in the piece.
  The AI-Native SDLC playbook — read next: Look for independent case studies, post-mortems, or DORA-style empirical measurement of organizations that adopted this specific stage structure, as distinct from vendor-authored playbooks.
• unaddressed questionNo discussion of how surrender dynamics change with model capability over time. As models improve and surface-correctness signals become even stronger, the offloading/surrender line presumably shifts — but the essay treats the distinction as static.
  Cognitive Surrender
• untested assumptionThe prescriptive heuristics (construct expectations, argue against self, etc.) are presented without evidence of their effectiveness. They may themselves be susceptible to surrender: an engineer could go through the motions of the heuristic while still surrendering.
  Cognitive Surrender
• unaddressed tensionNo treatment of the economic/game-theoretic pressure: if surrender increases short-term throughput and organizations reward throughput, then the equilibrium may favor surrender regardless of individual awareness. The essay gestures at this ('the org rewards both equivalently in the short run') but does not resolve it.
  Cognitive Surrender
• scope limitationThe mutual-amplification frame assumes the engineer has enough domain knowledge to ask good questions and evaluate answers. For truly novel domains or junior engineers, the entry point into the amplification loop is unclear.
  Cognitive Surrender
• incompleteThe article treats finite senior-reviewer capacity as the crisis that pushed conformance checking onto automated fitness functions, but never asks whether spec-authoring capacity is symmetrically finite. The social practice it prescribes for spec-anchored SDD — "the spec is authored and reviewed like code, with diffs and approval, and amended when reality diverges from intent" — reintroduces a human bottleneck at the intent layer even as it removes one at the structural layer. If spec review cannot keep pace with AI-generation speed any better than code review currently does, the context store risks simply relocating the reviewer-capacity crisis from PRs to specs rather than resolving it.
  Comprehension at AI Speed: Building a Context Store for Evolutionary Architecture — read next: Read against extract-eisele-ai-coding-agents-need-clear-specs' U-shaped cost curve of specification completeness (heavier specs front-load human effort) and extract-agentic-code-review's documentation of reviewer capacity already collapsing under AI-generated PR volume, to test whether spec-authoring is next in line for the same collapse.
• incompleteThe essay is written entirely from an individual-contributor, single-developer vantage point with no discussion of team or organizational context — code review by others, shared coding standards, pairing, or whether colleagues can tell from the outside whether a given PR reflects genuine understanding or the described discipline having quietly lapsed on a busy day.
  How I Use Agents Without Stopping My Own Growth — read next: extract-agentic-code-review (on how review itself has to change when agent-written code has no human intent behind it to reconstruct) and extract-ai-coding-two-kinds-debt (on cognitive debt as a team-level property invisible to individual self-report)
• uninformedEvery pattern in the catalog is presented with the author's own prescriptive worked example as its sole evidence; the catalog never cites an external case study, a controlled comparison, or independent practitioner validation for any individual pattern, despite the patterns ranging from simple (constraint-based prompting) to organizationally significant (atomic task decomposition coordinating parallel work across multiple teams).
  AI Development Patterns
• incompleteThe team-size framework (Solo / Two-Pizza / Multi Two-Pizza) treats team size as the organizing variable for pattern adoption but never addresses the transition itself — there is no migration path described from, say, a two-pizza team's Human-AI Handoff Protocol to a multi-team organization's Atomic Task Decomposition, only separate, static recommendations for each size category.
  AI Development Patterns
• scopeThe demonstration covers exactly one genre (persuasive long-form essay) by one expert writer. No evidence is offered that the quadrant assignments would hold for other knowledge work types -- technical documentation, code review, strategic memos, creative writing -- where risk and differentiation profiles differ.
  Eating My Own Dog Food: How I Used the Framework to Write the Post About the Framework — read next: Apply the framework to diverse knowledge work outputs and check whether quadrant assignments remain stable.
• incompleteTreating the PR approval as 'pretty much a compliance thing' is asserted as sufficient, but the guest never describes an actual external auditor's reaction to this substitution — only that it satisfies the team's own internal sense of the requirement.
  Pair Programming Fixed Our Pull Request Bottlenecks — read next: extract-four-eyes-without-pull-requests.json's own g1 names this same unresolved question (no empirical data on auditor response) for its more elaborate composite control — this video's informal version has the identical evidentiary gap.
• 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 article never asks whether splitting one large review into a stack of N smaller ones increases the total number of discrete review transactions (and their coordination/context-switching cost) faster than it decreases the size of any one review. This is the same systems-dynamics critique the corpus applies to plain 'write smaller PRs' advice: PR size is not free to shrink independent of the transaction cost of review, so packaging alone may not relieve the bottleneck the article names.
  GitHub Brings Stacked Pull Requests to Public Preview — read next: extract-async-code-reviews-choking-throughput (its central thesis is exactly this trade-off, including 'inventory expands to match transaction cost' and 'exhortations to write smaller PRs without changing review cost will fail'); extract-osmani-orchestration-tax-is-you ('throughput equals the throughput of the slowest serial stage').
• illogicalThe piece calls stacked PRs both 'dependent' and reviewable/mergeable 'independently' in the same sentence without resolving the tension: a reviewer evaluating PR 3 of a 5-PR stack needs to already know what PRs 1-2 changed to judge it correctly, so review is not actually independent of the rest of the stack — only the diff each reviewer sees is smaller.
  GitHub Brings Stacked Pull Requests to Public Preview — read next: GitHub's own stacked-PR documentation and Graphite's product docs, to see how (or whether) they surface cumulative stack context to a reviewer looking at just one layer.
• uninformedNo mention of the maintenance cost specific to stacked-diff workflows: when an early PR in the stack receives review feedback that changes its code, every downstream PR in the stack typically needs to be rebased and its own review is often invalidated. This is a well-documented operational cost of the very tools (Graphite, Sapling) the article names as prior art, yet it is never raised.
  GitHub Brings Stacked Pull Requests to Public Preview — read next: Graphite and Sapling documentation and practitioner writing on stack-rebase cost and review invalidation on rebase.
• incompleteNo discussion of failure modes: hallucinated SQL passing validation, MRs that look correct but introduce regressions, automation bias in reviewers, drift as the platform changes under the agents' indexed context.
  Designing a Multi-Agent System for Engineering Support at Scale: A Case Study From Grab — read next: Literature on automation bias in code review; Google's 'AI in software engineering' DORA findings on review burden.
• incompleteThe only evidence offered that telemetry-grounded verification actually improves outcomes is a single vendor-sourced internal anecdote (the Tempo squad) and a hypothetical worked example (the payment provider). No data compares defect rates, review time, or actual reviewer engagement between dashboard-linked PRs and plain diff-plus-description PRs. Given that the article's own diagnosis is that reviewers already rubber-stamp ('LGTM syndrome'), it is not shown that a dashboard link gets scrutinized any more carefully than a diff did — the same failure mode could simply migrate one layer up.
  Grafana's gcx and MCP Server Reach GA for Telemetry-Driven Agent Development — read next: Independent, non-vendor telemetry on whether richer PR context (dashboards, traces) measurably changes reviewer behavior or defect escape rates; the corpus's existing LGTM-syndrome and PR-review material.
• incompleteThe entire pattern presupposes an organization already has OpenTelemetry instrumentation, defined SLOs, and a Grafana-compatible observability stack to query — this is unglamorous infrastructure work that many teams have not done. The article treats 'point the agent at your telemetry' as a drop-in capability rather than naming the maturity precondition, so teams without that substrate get no guidance on how to get from zero to telemetry-grounded agent development.
  Grafana's gcx and MCP Server Reach GA for Telemetry-Driven Agent Development — read next: Observability-maturity and adoption-sequencing literature; the corpus's own material on trace validation as future/hard infrastructure work.
• incompleteTorrissen acknowledges he's about to participate in a recursive case (reviewing code that was itself generated agentically) and only jokes. The methodology gap — how does code review change when the developer's intent is partially encoded in prompts, ADRs, and context files rather than commit history — is left for next time.
  13) Tobias K. Torrissen om kodekvalitet, konferanser og AI — read next: Anthropic 'harness design' talk and the Pocock workshop already in this corpus.
• 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)
• incompleteThe paper's code-review model assumes human authorship at roughly human pace; it never considers what happens once a single engineer can direct an agent to produce far more reviewable code than they could write by hand, which breaks the 'small changes, author-chosen reviewer, review during authorship' model's load-bearing assumption that review capacity roughly tracks authorship capacity.
  Software Engineering at Google — read next: See extract-horthy-no-vibes-allowed-complex-codebases and extract-boonstra-spec-driven-production-grade-development for how review is being pushed up to the plan/verdict level specifically because code-diff-level review no longer scales against AI-generated volume.
• incompleteThe article flags regulated environments as an exception ('having each change reviewed by a second person is required') but doesn't say how to produce an audit-grade review record without reintroducing the PR gate it argues against for everyone else.
  Why your team doesn't need to use pull requests — read next: extract-four-eyes-without-pull-requests.json (Laforgia) resolves exactly this, five years later, with a five-piece composite control (policy, commit trailers, automated enforcement, telemetry, sampling audit) that satisfies ISO 27001/SOC 2 four-eyes requirements without a PR approval artefact.
• incompleteWritten in 2021, the piece has no notion of AI-generated code volume — it assumes a human author producing a human-scale rate of changes. It doesn't anticipate that when an agent can produce a day's worth of code in minutes, the CI-vs-PR delay math it relies on (humans reviewing within 30 minutes vs. 'minutes' for CI) changes shape entirely.
  Why your team doesn't need to use pull requests — read next: extract-agentic-ai-and-code-reviews.json and extract-dora-2025-state-of-ai-assisted-software-development.json address how review must reorganize when code-generation volume outpaces human attention.
• incompleteNo metrics are given anywhere in the piece — no false-positive rate, no override/dismissal rate, no measured change in reviewer behavior or time-to-catch for security issues — after deploying Dash+MCP in code review. Every claim about avoiding 'a false sense of security correctness' and about developer trust is a stated design principle, never an evaluated outcome.
  Dropbox Integrates MCP and Dash to Close the Gap Between Security Design and Code Review — read next: The linked Dropbox engineering blog post (dropbox.tech/security/dropbox-mcp-dash-design-code-security) or a follow-up post, if one exists, with adoption/precision data.
• incompleteNo enforcement mechanism is described for the disclosure mandate — it reads as an honor-system requirement with no stated detection method or consequence for omission.
  The Kubernetes Approach to AI-Assisted Maintainership Prioritises Human Accountability — read next: Read the source Kubernetes governance docs (kubernetes.dev PR guide, the linked kubernetes.io blog post) directly for enforcement detail; compare against how other OSS projects enforce comparable declarations (e.g. Developer Certificate of Origin sign-off enforcement) as a precedent for what 'works'.
• incompleteThe 'architectural drift' audit cycles are named as a goal but not specified — no cadence, owner, tooling, or success criteria given.
  The Kubernetes Approach to AI-Assisted Maintainership Prioritises Human Accountability — read next: Follow the Kubernetes SIG (e.g. sig-contributor-experience or sig-architecture) governance docs or future KEPs for concrete audit-cycle design once published.
• uninformedThe article doesn't consider whether disclosure incentives could be gamed — a contributor motivated to avoid scrutiny has reason to under-report AI assistance, and no technical detection is mentioned.
  The Kubernetes Approach to AI-Assisted Maintainership Prioritises Human Accountability — read next: Look for research or precedent on self-reported compliance regimes in software governance (e.g. license/IP disclosure, security disclosure norms) to see how other communities handle the gap between stated policy and verifiable practice.
• incompleteBoris states Claude reviews 100% of PRs and a human layer still exists 'after' that, but the interview never specifies what the human reviewer is actually checking for that Claude's own review doesn't already catch, nor how often the human layer actually changes or blocks something Claude approved. Without that detail, '100% AI-written, 100% AI-reviewed, plus a human layer' could describe either a meaningful independent check or a rubber stamp.
  Head of Claude Code: What happens after coding is solved | Boris Cherny — read next: Look for more granular accounts (internal engineering blog posts, case studies) of what Anthropic's human PR-review layer actually catches or overturns after Claude's automated review.
• incompleteBoris's firsthand account gives a concrete, affirmative answer to whether AI-driven role blurring favors smaller, cross-functional teams over specialized roles (yes, at the Claude Code team) — but neither Boris nor Lenny engages the two other sub-questions this corpus has separately flagged as open about the same shift: how career ladders change when junior engineers no longer accumulate manual code-review reps, and how interpersonal trust between human teammates is affected when most review traffic is now mediated by an agent rather than by colleagues reading each other's code.
  Head of Claude Code: What happens after coding is solved | Boris Cherny — read next: Look for accounts specifically addressing junior-engineer skill formation and team trust dynamics under agent-mediated review, as distinct from the team-structure question this interview does address.
• incompleteThe 'cognitive rot' / skill-atrophy finding rests entirely on self-perception ('my brain is rotting,' 'my work feels worse') rather than any objective quality measure (e.g., code review defect rates, output audits, before/after task performance).
  How tech workers actually feel about AI in 2026 | Annual AI sentiment survey (Noam Segal) — read next: Empirical studies attempting to measure AI-assisted output quality or skill atrophy objectively rather than via self-report — e.g., the Simon Willison conversation referenced in the episode, or controlled studies of AI-assisted vs. unassisted task quality.
• incompleteThe article never explains how a reviewer (or the TSC) could concretely verify a self-report like Collina's 'I reviewed every line' at this scale — it reports the dispute over whether verification is possible without reporting any proposed verification mechanism from either side (e.g., line-by-line attestation tooling, provenance diffing, or a required second human reviewer for AI-heavy PRs).
  NodeJS Proposes Built-In Virtual File System, Sparking Debate Over AI-Generated Contributions — read next: extract-deepseek-v4-openai-microsoft-agi-clause#p16 and extract-agentic-code-review#p16 engage the underlying 'review capacity vs. contribution scale' problem more generally; neither is specific to the DCO angle this petition raises.
• incompleteNo information is given on the actual correctness or quality of the generated node:vfs implementation itself (test coverage, bug reports, independent security review) — the entire debate as reported is about process and authorship, not about whether the 19,000 lines are good code.
  NodeJS Proposes Built-In Virtual File System, Sparking Debate Over AI-Generated Contributions — read next: Follow the PR (nodejs/node #61478) for review comments and any post-merge incident reports once the TSC policy vote resolves.
• uninformedThe piece does not report what specific policy options the TSC is actually considering (outright ban, disclosure requirement, scale threshold, mandatory second reviewer, etc.), so the 'pending vote' framing has no visible menu of outcomes to evaluate against the two positions it does report.
  NodeJS Proposes Built-In Virtual File System, Sparking Debate Over AI-Generated Contributions — read next: Track the Node.js TSC's published AI-contribution policy once adopted, and compare it against the positions staked out by Indutny's petition and its critics.
• 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 piece describes human review as optional ('Humans may review pull requests, but aren't required to... we've pushed almost all review effort towards being handled agent-to-agent') but never says what determines which PRs actually receive a human look versus none, or what happens when agent-to-agent review systematically misses the same class of issue because both the authoring agent and the reviewing agent share the same model's blind spots.
  Harness engineering: leveraging Codex in an agent-first world
• incompleteNo quantitative comparison is given between outcomes under Claude-Code-first-pass review/testing/incident-response and Anthropic's own prior, pre-Claude-Code baseline. Every improvement cited (67% PR throughput increase, faster incident root-causing, two-week migrations) is self-reported by Anthropic insiders or by customer companies with an interest in the tool's success, with no external or controlled measurement.
  How Claude Code Is Built — read next: Read against extract-dx-measuring-ai-impact and extract-five-studies-ai-software-engineering, which raise the same self-selection and construct-measurement concerns for AI-engineering-impact claims generally.
• 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 author treats unrestricted, cost-free access to the most expensive Claude model as a structural advantage unique to Anthropic, but never asks what Claude Code's own internal practices (TDD renaissance, 60-100 releases/day, 5+ prototypes/day) would look like, or whether they would remain viable, under the token-cost and usage-quota constraints that every other company — including Claude Code's own external users, per a reader comment quoted in the discussion thread — actually operates under.
  How Claude Code Is Built — read next: Compare against practitioner reports from non-Anthropic teams operating under real token budgets, to see which of these practices survive a hard cost constraint.
• incompleteThe 67% PR-throughput increase coincides with, but the article never disentangles from, the fact that new joiners during Anthropic's hiring surge were likely disproportionately experienced senior engineers already fluent with Claude Code's own on-distribution stack (TypeScript/React) — leaving open whether the throughput gain is attributable to Claude Code itself or to who Anthropic was able to hire.
  How Claude Code Is Built — read next: Look for engineering-productivity research that isolates tool effect from hiring-composition effect during headcount-doubling periods.
• uninformedThe reporting draws entirely on four named individuals inside Anthropic (a platform-org engineering head, one high-profile external contractor turned employee, one cross-functional engineer, one applied-AI/sales-engineering role) with no comparison to Anthropic teams operating under tighter constraints, no former-employee or outside-critical perspective, and no acknowledgment that access journalism inside the very lab that sells the tools being praised may select for best-case, showcase-ready stories.
  How building software is changing at Anthropic — read next: Look for outside-in or critical accounts of Anthropic engineering culture (former-employee retrospectives, competitor comparisons, or the promised follow-up piece comparing Anthropic and OpenAI) to check whether practices like the 11-day Bun rewrite are typical internally or a cherry-picked outlier.
• incompleteFowler explicitly names 'how do we best operate with AI in the team environment' as an open question his own organization is 'still trying to figure out' — but the entire conversation's concrete advice (vibe-coding boundaries, PR-style review of AI output, building a shared vocabulary, thin specs) is framed at the level of one developer and one LLM. No team-level operating model (shared context across team members, division of review labor, how a team maintains a common mental model of a codebase that multiple AI-assisted people are editing) is even sketched.
  How AI will change software engineering – with Martin Fowler — read next: Look for emerging practitioner accounts of team-scale (not individual-scale) AI coding workflows: shared harness/context conventions across a team, how code review scales when every team member is AI-accelerated, and how a team keeps a common mental model of a codebase multiple people are editing with AI assistance.
• incompleteOrosz raises, and Fowler does not resolve, the problem of reviewer fatigue and vigilance as AI multiplies the volume of code to review — the conversation's only answer ('treat it like a PR from a dodgy collaborator, review everything carefully') does not address the structural throughput problem of more code arriving faster than humans can review it carefully.
  How AI will change software engineering – with Martin Fowler — read next: This is a near-direct match to the corpus's own treatment of PR-review throughput breakdowns and co-creation alternatives — see the review-fatigue proposition recorded above and its relation to extract-async-code-reviews-choking-throughput.
• uninformedFowler attributes the current software-industry downturn and job losses primarily to the end of zero-interest-rate financing rather than AI, but does not engage with the counter-evidence elsewhere in the discourse that some of the layoff wave is genuine AI-driven restructuring (not merely macroeconomic or a cover story) — he states his view confidently without weighing the split causation other commentators report.
  How AI will change software engineering – with Martin Fowler — read next: Compare against corpus accounts that split the layoff wave into AI-washing/cover-story and genuinely AI-driven restructuring components.
• 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.
• incompleteThe 'developer focus' argument for post-commit review implicitly assumes the author is a single human whose commit rate is bounded by typing speed, so batching reviews relieves interruption for both sides. If the author is a coding agent capable of producing many small, well-formed post-commits per hour, the same batching logic may not relieve reviewer load -- it may simply convert interruption cost into volume overload, since the reviewer side of the equation doesn't scale down just because commits arrived post-merge instead of pre-merge.
  Post-Commit Reviews != Post-Deployment Reviews — read next: extract-agentic-code-review's finding that reviewer capacity, not author speed, is now the binding constraint directly tests whether this article's focus benefit survives when authorship is agentic rather than human.
• incompleteThe 'knowing how and when to use LLMs' recommendation (generation vs. completion vs. manual coding) is framed entirely as an individual developer's moment-to-moment choice. The paper never addresses team-level process design — code review policy, CI gating, pairing, or testing discipline — for catching these specific bug patterns at the scale of many AI-authored changes landing across a team, which is the organizational question the rest of this corpus's 2025-26 material is working through.
  Bugs in Large Language Models Generated Code: An Empirical Study — read next: extract-agentic-ai-and-code-reviews.json's layered, risk-tiered review system is the organizational-scale answer this paper's individual-developer recommendations don't attempt.
• incompleteThe claim that OpenClaw's contributor 'Peter' submitted roughly 600 pull requests in a day because of the proof-required review culture is offered with no independent verification, no baseline for comparison, and no accounting for PR size or quality — the same self-reported-evidence problem the corpus has flagged in other vendor/practitioner production-metrics talks.
  Presentation: The Agent Harness: Control Planes, Invariants, and Approval Boundaries for Production AI Agents — read next: Read alongside extract-anthropic-details-how-it-contains-claude#g4, which raises an identical evidentiary-independence gap about self-reported production security metrics, to see whether unverified headline numbers are a systemic weakness across 'here is our production agent's numbers' talks.
• incompleteThe theme on dragging PRs closer to proper CI names AI-increased throughput and larger PRs as a growing strain on async review, and surveys several mitigations (gitStream, merge queues, stacked diffs, PR metrics) in the same breath — but does not analyze which of these actually addresses the AI-specific mechanism (more code per unit time) versus merely repackaging the same total review burden into more numerous smaller transactions.
  Technology Radar: An opinionated guide to today's technology landscape (Volume 30) — read next: Later corpus material on stacked pull requests and on DORA's AI/changelist-size findings examines this mechanism more directly.
• incompleteThe 'AI team assistants' blip offers no account of adoption barriers, measured outcomes, or how a team-shared-prompt-and-RAG approach differs in practice from a team that already had strong individual tool adoption plus good informal knowledge-sharing habits — it is reported as a promising direction from a single internal case, not evaluated.
  Technology Radar: An opinionated guide to today's technology landscape (Volume 30) — read next: Later Radar volumes or practitioner reports that follow up on team-level AI tooling outcomes specifically (as opposed to individual-developer AI productivity studies).
• uninformedThe piece never engages security, compliance, or audit-trail requirements for the autonomous pipeline — who is accountable when the agent's autonomous fix-loop makes a change that passes all automated gates but is substantively wrong, and whether 'green and ready for review' review is itself adequate given how little a human reviewer may actually re-verify once a PR already shows all-green checks.
  Coding Agent Development Workflows — read next: extract-agentic-ai-and-code-reviews.json's risk-tiered, durable-audit-trail framing and extract-four-eyes-without-pull-requests.json's compliance-control framing both treat this as a central design question this workflow leaves open.