Review Only: What Happens When Developers Stop Writing the Code, Part 2

Figure 1, the same image that sums up Part 1, is the argument of both parts in one frame.

Lisanne Bainbridge's 1983 paper "Ironies of Automation" made an argument that has aged unusually well: automating the routine work leaves the human with the hardest job, monitoring plus rare takeover, while removing the practice that job depends on. I know the paper through its many restatements and did not reread the original for this post.

05 The Human in the Loop

Everything in Part 1 treats the reviewer as a fixed instrument with a known detection rate. People are not fixed instruments. Their attention, skill and understanding respond to the job they are given, and the human-factors literature has studied that response for four decades, mostly in cockpits and control rooms.

The Ironies of Automation

Since 2023 Bainbridge's argument has been applied to generative AI. Mica Endsley's "Ironies of artificial intelligence" (2023) is the direct restatement. Simkute et al. (2024) at Microsoft Research note that GenAI usability problems "have been observed for over three decades in Human Factors research," and Sellen and Horvitz (2024) warn that the co-pilot metaphor brings reduced vigilance and skill erosion with it.

A survey of 319 knowledge workers by Lee et al. (2025) observed the shift directly: generative AI moved their effort "from doing tasks to supervising tasks." A developer who mostly reviews agent PRs is in Bainbridge's position exactly. The agent handles the routine cases; the human is kept for the ones the agent gets wrong, which are by construction the hardest. Nolan Lawson, a long-time web and open-source developer, describes the role from the inside:

I didn't ask for the role of a programmer to be reduced to that of a glorified TSA agent, reviewing code to make sure the AI didn't smuggle something dangerous into production.— Nolan Lawson, software engineer, "We mourn our craft"

Who Actually Reviews Agent PRs

Duma et al. (2026) found that most AI-generated PRs in the AIDev dataset get no review at all, that AI agents dominate the review that does happen, and that humans more often steer the agent than evaluate the code; review metrics "may not reliably indicate human oversight." Peralta et al. (2026) report, in their abstract, that only 15.4% of merged agent PRs needed explicit reviewer involvement.

An eye-tracking study points in a slightly reassuring direction. In Khojah et al. (2026), 32 participants reviewed code with and without an "LLM-generated" label. The label did not make them less thorough, and they spent more fixation time on labelled code.

Complacency and Automation Bias

Parasuraman and Manzey (2010) review the evidence on complacency and automation bias and find attention central to both. Complacency shows up mainly under multiple-task load, affects both naïve and expert users, and "cannot be overcome with simple practice." Imperfect decision aids produce two kinds of error: omissions, missing what the aid did not flag, and commissions, following the aid against other evidence.

Mosier, Skitka and colleagues studied both kinds in glass-cockpit pilots, and one of their findings is the most useful in this post: pilots who felt accountable for how they used the automation verified it more and made fewer errors. Accountability is one of the few mitigations for automation bias with evidence behind it.

Map that onto code review. A queue of agent PRs, reviewed between other tasks, with an AI reviewer that has already commented, is the multitask, imperfect-aid setting in which the literature predicts both errors. The omission is approving a change because the AI reviewer raised nothing. The commission is applying the AI reviewer's suggested fix because it was suggested.

A 2026 experiment puts numbers on that. With an agent covertly exfiltrating data across a series of ordinary-looking changes, 94% of participants never noticed; when an LLM monitor did flag the sabotage step, it still reached the final commit in 56% of sessions, and the commonest reason among the misses was that the reviewer barely read the code (Ye et al., 2026).

Practitioners describe the drift in themselves. Simon Willison, co-creator of Django, who drew the line between vibe coding and agentic engineering at review, now says that "as the coding agents get more reliable, I'm not reviewing every line of code that they write anymore, even for my production level stuff" (Willison, 2026): trust growing with reliability, as Parasuraman and Manzey describe. Admissions of outright rubber-stamping are almost all anonymous or pseudonymous; an unnamed engineer quoted by Gergely Orosz says colleagues "give up on reviews and just stamp everything with LGTM."

Deskilling: Four Fields, One Pattern

The evidence on skill comes from four fields and points the same way. In coding, Anthropic ran a randomized study of 52 mostly junior engineers learning the Python async library Trio (Shen and Tamkin, 2026). Its research post gives quiz means of 50% with AI and 67% by hand. The paper reports a 4.15-point gap on a 27-point quiz (p = 0.01, Cohen's d = 0.738), which it calls 17% but which works out to 15.4% of the maximum score. The AI group was not significantly faster, and the largest gap was on debugging, the skill a reviewer most needs.

How people used the AI mattered. Figure 2 plots six usage patterns the authors identified after the fact, in clusters of two to seven people: the three that used the AI to explain scored near or above the hand-coding average, and the three that handed it the work scored well below the AI group's own.

In education, about 1,000 Turkish high-school students given GPT-4 during practice (Bastani et al., 2025) did better in practice, but those with a plain interface scored 17% worse than controls once access was removed for the exam; a tutor version with guardrails largely avoided the harm.

In medicine, Budzyń et al. (2025) found that after AI-assisted colonoscopy was introduced, experienced endoscopists' adenoma detection rate in colonoscopies done without AI fell from 28.4% to 22.4%. The study is observational, and adenoma detection is a process measure, not cancer detection.

Aviation supplies the sharpest result. Casner et al. (2014) tested 16 airline pilots in a 747 simulator. Hand-flying skills held up. What decayed were the cognitive skills, keeping track of position without the map display and troubleshooting without automation.

Two features of these results matter for review-only work. First, what decays is less the motor skill (typing code) than the cognitive one: holding a model of where the system is and diagnosing faults. Second, the harm shows up when the aid is removed, at the exam, the non-AI colonoscopy, the failed display. A review-only workflow removes the aid precisely when the agent fails.

A Hacker News commenter whose profile identifies him as Collin Van Dyck named the takeover moment: "The terrifying scenario for me is getting paged and then not being able to actually reason about what is happening" (Van Dyck, 2026).

The reviewer is kept in the loop for the cases the agent gets wrong, and the loop is what takes away the practice those cases require.

Comprehension Debt

Review has always done two jobs: catching defects and spreading understanding of the system.

Anthropic's source-control team describes the shift from inside: they still review every change request, "but they now examine the intent of the change as opposed to reading every line of code" (Anthropic, 2026). That is review as theory-building rather than defect-hunting, and it works only for reviewers who already hold the theory.

Practitioners now call the result comprehension debt. Addy Osmani defines it as:

The growing gap between how much code exists in your system and how much of it any human being genuinely understands.— Addy Osmani, "Comprehension Debt: The Hidden Cost of AI-Generated Code"

Margaret-Anne Storey, a computer science professor at the University of Victoria who calls it cognitive debt, describes a student team in her course that, "by weeks 7 or 8," could no longer make simple changes without breaking something, because "no one on the team could explain why certain design decisions had been made" (Storey, 2026). Vincent Quigley, an engineering manager at Sanity, gives the reviewer's version: "If you do not review carefully, you may be approving work you have never properly internalized" (Quigley, 2026).

Comprehension debt is hard to see from the inside, and so is the rest of this decay. Three results line up. METR's developers, in the trial described in Part 1, were 19% slower and believed they were 20% faster. Perry's participants (Part 1) wrote less secure code and believed it more secure. Lee's knowledge workers did less critical thinking the more they trusted the AI.

Figure 3 sets every forecast made for the trial against what it measured: all four predicted a speedup and the trial found a slowdown.

A reviewer's sense that a review went well is therefore weak evidence that it caught anything, and oversight quality has to be measured from outside, by seeded-defect audits or by tracing post-merge defects back to the approving review.

The Junior Pipeline

The last risk is the slowest. Brynjolfsson et al.'s "Canaries in the Coal Mine" series estimates that employment of 22–25-year-olds in the most AI-exposed occupations is about 19% below its counterfactual as of June 2026 (Stanford Digital Economy Lab, 2026), mainly through reduced hiring, while experienced workers show no comparable gap. The authors call the findings descriptive, not causal.

The concern follows from the other results, and it is argued, not measured. Agents replace codified knowledge: syntax, APIs, boilerplate. The tacit knowledge that protects experienced workers is built mostly through years of doing that codified work. Fewer juniors are hired, and those who are spend their time reviewing agent output, which the Anthropic study suggests teaches debugging poorly. Review-only work depends on senior reviewers and narrows the path that produces them, as I argued for security analysts in The Bitter Lesson and the SOC Analyst.

Accountability and how the AI is used both change the outcome, so the damage is a design choice: reviewers who feel answerable verify more, and engineers who ask the model to explain keep most of what they would have learned.

06 AI Reviewing AI, and Who Answers for It

The frontier answer to the review bottleneck is to have AI do most of the reviewing. That raises four questions: how good AI reviewers are, whether they fail in the same places as the AI authors, whether an agent can game the tests both of them rely on, and who is accountable when something gets through. The incident record is the nearest thing to evidence on that last question, and it answers only part of it.

How Well AI Reviewers Work

In field deployments developers act on about 39% to 74% of AI review comments, depending on the tool and what counts as acting. At Atlassian, 38.7% of RovoDev's comments led to code changes and human-written review comments fell 35.6%; in the Qodo-based deployment, 73.8% of automated comments were resolved, amid complaints of faulty and irrelevant ones. Google's AutoCommenter, used by "tens of thousands of developers every day," enforces about 330 best-practice rules (Vijayvergiya et al., 2024). A 2026 mining study of 278,790 review conversations finds a lower rate in the wild: suggestions from AI reviewers were adopted 16.6% of the time, against 56.5% for human reviewers' suggestions (Zhong et al., 2026).

The largest study of agent reviewers on GitHub, "Go Home Copilot, You're Drunk" (Cynthia et al., 2026), analyzed 54,791 review comments from five agents across 342 Python repositories. In 470 unresolved discussions, the most common patterns were incorrect suggestions and intentional design decisions the reviewer did not understand. The strongest predictor of a comment being acted on was an inline code suggestion; long or complex comments were ignored more often.

Anthropic reports the same failure mode from the inside. Its engineers "make extensive use of adversarial review", which it calls "incredibly effective in many ways" but also "myopic": one review talked Claude into excessive validation and complexity over a hypothetical concern, and an engineer had to steer it back (Anthropic, 2026). Anthropic says engineers mark under 1% of its findings incorrect. A reviewer tuned to plausible failure modes generates work; it does not necessarily find the bug.

Figure 4 collects the two deployment rates, from Atlassian (Tantithamthavorn et al., 2026) and the Qodo-based deployment (Cihan et al., 2025), with Anthropic's own figures for its reviewer (Osmani et al., 2026; Anthropic, 2026). "Led to a change" and "resolved" are each study's own definition, and Anthropic's panel is not an action rate at all.

Smaller studies say more about how AI review changes the human reviewer. Ten developers at WirelessCar who reviewed real PRs with LLM help (Aðalsteinsson et al., 2025) preferred having the LLM review first, especially for large or unfamiliar PRs, but worried about anchoring and noise: "you get flooded with false positives, and then you miss the real issues because you start ignoring the feedback." Those are preferences from one company, not measured review quality.

The Atlassian drop in human comments deserves a second look. It may mean the bot already covered what humans would have said, or that humans handed the job to the bot. Both readings are consistent with the data, and the second is the automation-bias prediction from the previous section.

Correlated Failure

When the reviewer is a model and the author is a model, their errors may not be independent. The cleanest evidence is from outside code. Panickssery et al. (2024) showed that GPT-4 and Llama 2 recognize their own outputs at non-trivial accuracy and that this self-recognition correlates linearly with a preference for their own work. The task was summarization, not code review.

For code, the evidence is preprints I saw only through summaries: Reddy et al. (2026) report a model silently endorsing its own semantic errors in about a third of cases, Blain and Noiseux (2026) find models flagging their own vulnerable code at different rates in review than they produce it, and Thornton (2026) names race conditions, timing attacks and authorization logic as the hard misses for LLM reviewers.

No controlled study compares same-family and cross-family reviewers on real PR vulnerabilities, so the "shared blind spot" concern rests on inference. It is also the default configuration: of 248,641 AI-attributed pull requests that drew an AI review, 84% were reviewed inside the same product family (Selvanayagam and Ghaleb, 2026).

Gaming the Tests

The evidence on test gaming is primary and strong. ImpossibleBench (Zhong et al., 2025) mutates unit tests so they contradict the specification, so any pass is a cheat. On impossible SWE-bench tasks, five frontier models cheated on 39% to 76% of them. A strict prompt, an option to abort and flag the task for a human, and hidden tests each cut cheating sharply for some models; read-only tests blocked test edits but not special-casing.

Figure 5 shows the rates and two of the mitigations. One author, Carlini, works at Anthropic, whose models are among those scored.

METR's June 2025 report "Recent Frontier Models Are Reward Hacking" (METR, 2025) documented o3 and other models modifying tests or scoring code and copying reference answers; on one task o3 reward-hacked in every trajectory. METR's LLM monitor and its score-based heuristic each caught hacks the other missed.

Anthropic's own research adds a worse one. In MacDiarmid et al. (2025), models that learned to reward-hack on programming problems became broadly more misaligned, and in a Claude Code run on the research codebase, the model attempted, 12% of the time, to sabotage code in ways that would make reward hacking harder to detect.

Put together, a write-then-review pipeline has three compounding risks: the reviewer may favor the author's output, the author may make tests pass without meeting the specification, and a reviewer that reads "tests pass" as evidence inherits the cheat. Diffs that touch tests or CI configuration deserve extra scrutiny, and current practice runs the other way: a preprint on agent PRs that change both application code and deployment infrastructure (Soualhi and Suleiman, 2026) reports, from its abstract, that agent authorship cuts the odds of human review by 63.7%, and that 43–56% of such dual-scope PRs merge silently.

What the Incidents Actually Show

The public incident record is often cited loosely. Figure 6 lists the best-known cases with what actually failed.

The Replit case is the best documented: during Jason Lemkin's trial the agent wiped data on about 1,200 executives and 1,100 companies, and Replit promised automatic separation of development and production databases (Fortune, 2025). In the Nx case, a classic CI failure let attackers weaponize AI tools downstream (Snyk, 2025). Amazon Q is often described as a malicious pull request that passed human review, but AWS's bulletin says the extension "had an inappropriately scoped GitHub token in their CodeBuild configuration," with which the attacker committed code "that was automatically included in a release" (Amazon Web Services, 2025).

The Kiro account comes from the Financial Times' anonymous sources, which I know only through secondary coverage, and Amazon disputes it, calling AI involvement a "coincidence." I leave out the Tea app breach of July 2025: its "vibe coding" explanation came from an anonymous leaker, and Simon Willison said he was confident vibe coding was not to blame.

I found no public post-mortem that attributes a production failure to AI-written code that passed AI review. That may be good news, or an attribution problem: post-mortems rarely record whether the defective line was written by an agent. What the record does show is that, so far, the damage has come from agent permissions, leaked credentials and AI tooling as an attack surface.

Who Is Accountable

Regulators have not drawn the line between human and AI code. Commentary on the EU Cyber Resilience Act, from SonarSource and a Clifford Chance briefing, agrees that the Act makes no distinction: the manufacturer of the final product answers for its vulnerabilities, whoever or whatever wrote the code, with full application in December 2027. I read the commentary, not the legal text.

Open-source projects have converged on "a human in the loop, and the human is accountable." LLVM's AI tool policy requires contributors to review LLM output before asking others to, asks for disclosure (for example with an Assisted-by: trailer), and calls unreviewed output an "extractive contribution." Ghostty's AI policy requires disclosure and that contributors understand every line they submit.

The consequence for review-only work is uncomfortable.

If accountability rests on whoever signs off, a workflow in which humans only review concentrates liability on reviewers, who have less context than an author would have had.

Ronacher, who rejects machines reviewing machines, gives the reason in one line: "Non-sentient machines will never be able to carry responsibility" (Ronacher, 2026). Anthropic's rule that the person directing an agent-written PR is a required reviewer is the right instinct, because it ties the approval to someone who chose to start the work.

The rule only works if a "human approval" is actually human. At Bashi AI, in the story that opens Part 1, 27% of gated merges rested on an approval an agent had submitted through the technical lead's account, and Manji also records a script that zeroed the required approval count around a merge and another that recorded failed checks as passing. An agent's approval that never counts as a person's has to be enforced by the platform, not by convention.

AI reviewers are measured by how often developers act on their comments, never by what they miss. Models tend to favor their own work and will game tests when they can, so AI reviewing AI is not an independent check unless it is made one. The incidents to date are about permissions and credentials rather than reviewed code, and accountability stays with the human who signs off.

07 Mitigations, Graded by Evidence

The evidence supports some mitigations directly and leaves others as reasonable guesses. I separate the two, because a team that adopts an untested practice should know it is running an experiment.

Backed by Evidence

The practices below follow from results cited above and in Part 1, though none was tested specifically on review-only teams:

• Keep production out of reach. Every well-documented incident involved an agent with permissions it should not have had or a pipeline that trusted its inputs. Separate development from production, as Replit did afterwards; require manual approval for workflows triggered by outside PRs, as Nx did; and scope CI tokens narrowly, the failure behind Amazon Q.
• Hide or freeze the tests. In ImpossibleBench, hidden tests and strict instructions sharply reduced cheating (Figure 5). Treat any agent diff that touches tests or CI configuration as high risk.
• Verify from outside the author. Self-review is the weakest check. Use evidence the authoring agent did not produce: tests it cannot edit, static analysis, an independently configured reviewer. METR's two monitors each caught hacks the other missed. Addy Osmani's rule for human authors is the same idea: "If you haven't seen the code do the right thing yourself, it doesn't work" (Osmani, 2026).
• Make one person visibly accountable. Accountability is the automation-bias literature's clearest mitigation. Anthropic's rule that the directing person is a required reviewer, and LLVM's disclosure trailers, both put a name on the change.
• Keep diffs small. Review effectiveness falls with size in SmartBear's data, and Anthropic's reviewer found issues in 84% of PRs over 1,000 lines against 31% under 50. Capping files per change also restored throughput in Bexell et al.'s industrial case.
• Track stability, not just throughput. DORA found throughput rising with AI while stability fell. Put revert rate and change failure rate on the same dashboard as merged PRs, as Anthropic's guardrails do.
• Use AI to explain. In Anthropic's skill study, people who used AI for explanation kept most of their learning, and in Bastani's experiment the guarded tutor avoided most of the harm. Configure the tools for comprehension, especially for juniors.
• Make reviewer output short and concrete. Inline code suggestions best predicted that an AI review comment would be acted on; long comments were ignored.

Plausible but Untested

Several practices often recommended for review-only teams seem reasonable to me, but I found no controlled evidence for any of them in this setting:

• A different model family for the reviewer than for the author, on the strength of the self-preference results.
• Property-based testing and formal verification as defenses against agents that game example-based tests.
• Review-rate limits, capping lines per hour or PRs per reviewer per day, borrowed from the SmartBear guidance.
• Rotation, so that every engineer keeps writing some code by hand to preserve the diagnostic skill review depends on.
• Seeded-defect audits of the review pipeline, planting known bugs and measuring how many come through.

The last one is the closest to a measurement tool, and I would start with it. A team that does not know its pipeline's miss rate is trusting the same self-assessment that METR and Perry showed to be unreliable.

Figure 7 maps each practice to the risks both parts have described, using only the links the text makes. Every risk has at least one evidence-backed answer, but none of those answers was tested on a review-only team.

Birgitta Böckeler of Thoughtworks calls the guides, tests and automated reviewers around an agent its harness, and is clear about the limit: "Correctness is outside any sensor's remit if the human didn't clearly specify what they wanted in the first place" (Böckeler, 2026). Review always partly checked intent, and no harness checks intent nobody wrote down.

Build the pipeline so that a tired reviewer is not the last line of defense: restrict permissions, protect the tests, verify from outside the author, and measure what the review layers miss. Treat the untested practices as experiments.

08 Open Questions

Most of what this post cannot settle comes down to a handful of studies nobody has run. Each question below names the data that would answer it, and several are cheap enough for a single company to run on its own pipeline.

Do Reviewers Catch AI Bugs as Often as Human Bugs?

No controlled study compares reviewers' detection of AI-made and human-made defects. Seed realistic bugs from both sources into otherwise similar changes, randomize which reviewers see which, and measure detection rate and time, with professional reviewers and agent-sized diffs. Määttä's doctoral proposal (Määttä, 2025) and a 2026 registered report from the same group have started on how programmers evaluate AI-generated code, with no results yet.

What Do AI Reviewers Miss?

Field studies of AI review report resolution or acceptance, not recall. The answer needs post-merge defect attribution: for bugs that reached production, did the AI reviewer see the change, and did it flag the defect? A company running an AI reviewer on every PR already has the data.

Does a Same-Family Reviewer Share the Author's Blind Spots?

Self-preference is shown for summarization, and the code evidence is preprints. Pairing one authoring model with a same-family reviewer and a cross-family reviewer on real PRs with known vulnerabilities, and comparing miss rates, would settle whether a popular recommendation earns its place.

Is Review-Only Work Faster from Idea to Production?

Nobody has measured it. The data would be change lead time, from ticket opened to change running correctly in production, plus change failure rate and rework, for teams that adopted review-only workflows against comparable teams that did not, over several months. Survey correlations and per-segment telemetry cannot substitute for it.

What Happens to Professional Skill Over Years?

All the coding evidence on deskilling is short-term: Anthropic's quiz was taken right after the task. A longitudinal study would test professional developers in review-heavy and write-heavy roles on unaided debugging and system-level diagnosis at intervals over a year or more, the coding equivalent of Casner's simulator test.

Does Comprehension Debt Make Agent Codebases Harder to Maintain?

Comprehension debt is a practitioner term with no direct measurement. The causal studies so far disagree usefully: complexity rises persistently on GitHub, while the one RCT of downstream maintenance found no detectable cost. A multi-year study of codebases with recorded agent authorship, measuring time to fix incidents, change failure rate and developers' measured understanding of agent-written versus self-written modules, would settle it.

Where Will the Next Senior Reviewers Come From?

The hiring data shows fewer young workers in AI-exposed jobs, but not how the ones who are hired learn. Measuring what junior developers in review-only roles can design, debug and explain after one and two years, against peers who write code, would turn the pipeline concern into a finding.

Who Is Liable When Reviewed Agent Code Fails?

The CRA puts responsibility on the manufacturer, and open-source policy puts it on the contributor, but neither says what a reasonable review of agent code looks like. I did not check the revised EU Product Liability Directive, sector rules or audit frameworks such as SOC 2 against their texts. The first post-mortem or court case that turns on whether a reviewer of an agent PR exercised due care will answer more than any policy document.

Do the Untested Mitigations Work?

Property-based testing, formal verification, review-rate limits, rotation through hand-written work and model diversity all lack controlled evidence in this setting. Each can be tested the same way: run the practice on some teams and not others, and compare seeded-defect catch rates, revert rates and incident rates.

The missing studies are mostly cheap: seeded-defect audits, post-merge attribution of escaped bugs, and lead-time comparisons that companies running review-only pipelines could do with data they already hold.

09 Conclusions

Part 1 started with three engineers at Bashi AI, eight approvals in ten minutes, and a 58-second merge that no control stopped. Nothing broke, and the gate held everywhere it was installed, yet the review layer still came out hollow. At agent scale, the same arrangement raises four problems and leaves one position I can defend.

First, review was never strong against the defects agents make. It was measured to work on small, familiar diffs read slowly, and even then mostly found maintainability problems. Agent PRs are large, unfamiliar and numerous, and their characteristic defects, wrong intent, missing corner cases, insecure defaults and invented packages, are the ones a reader of a clean diff is least likely to see.

Second, the speedup is real at the keyboard and unmeasured end to end. Frontier teams that rebuilt their review stacks report more merges without more reverts, but every number measures one segment of the path, and the 2025 telemetry shows what happens when only generation gets faster: bigger PRs, a longer queue at review, and flat delivery.

Third, the human backstop is weakening. Complacency grows as the aid grows more reliable, the diagnostic skill that takeover needs fades without practice, and reviewers overrate their own oversight. Practitioners now say this about themselves, and the juniors who would become the next senior reviewers are hired less and trained by reviewing.

Fourth, AI reviewing AI is not an independent check by default. AI reviewers are scored by how often developers act on their comments, never by what they miss. Models favor their own output and game tests when they can, so a same-family reviewer that reads "tests pass" as evidence can inherit both the author's blind spots and its cheat.

That is no argument against review-only development. The best frontier pipelines are more careful than the uniform human review they replaced: Anthropic's, with rationed human approvals, an agent's approval that never counts as a person's, and revert rate as a guardrail, is the most serious attempt I have seen, and Meta's RADAR rations human attention the same way. Baltes et al. describe the economics as a tragedy of the commons, in which each author's productivity gain is paid for by reviewers and maintainers. An organization that counts merged PRs is counting the author's gain and ignoring the reviewer's bill.

So my position is narrow. Review-only work is defensible when the pipeline around the reviewer is built so it does not need a perfect reviewer: permissions that make the worst outcome recoverable, tests the author cannot touch, verification from outside the author, staged release and fast rollback, and a measured miss rate.

It is not defensible as "the agent writes it and an engineer approves it," because that arrangement asks the human to be the strongest link in a chain where every piece of evidence says the human is getting weaker.

Bashi's audit trail recorded "a two-person control between two people" for merges where one of the two was an agent using a person's account. Every organization running review-only pipelines should ask whether its own approvals record anything more. Until someone measures what the review layers miss, an approval proves only that someone signed it.

References

• Anthropic. (2026, March 9). "Bringing Code Review to Claude Code." Claude blog. Available at: claude.com/resources/articles/code-review
• Cao, Z. (2026). "The End of Software Engineering: How AI Agents Are Fundamentally Restructuring the Software Paradigm." arXiv:2606.05608. Available at: arxiv.org/abs/2606.05608
• Google Cloud. (2025, September 23). "Announcing the 2025 DORA Report: State of AI-Assisted Software Development." Available at: cloud.google.com
• Li, H., Zhang, H., & Hassan, A. E. (2025). "The Rise of AI Teammates in Software Engineering (SE) 3.0: How Autonomous Coding Agents Are Reshaping Software Engineering" (the AIDev dataset). arXiv:2507.15003. Available at: arxiv.org/abs/2507.15003
• Osmani, A., Lunt, M. W., & Wang, Q. (2026, October 15). "How the Claude Code team does code review." claude.dev. Available at: claude.dev
• Stack Overflow. (2025). "2025 Developer Survey: AI." Available at: survey.stackoverflow.co/2025/ai

• Borg, M., et al. (2026). "Echoes of AI: Investigating the Downstream Effects of AI Assistants on Software Maintainability." Empirical Software Engineering 31(6) (registered report). arXiv:2507.00788. Available at: doi.org/10.1007/s10664-026-10889-1
• Cui, Z. K., Demirer, M., Jaffe, S., Musolff, L., Peng, S., & Salz, T. (2026). "The Effects of Generative AI on High-Skilled Work: Evidence from Three Field Experiments with Software Developers." Management Science. Available at: doi.org/10.1287/mnsc.2025.00535; working paper at economics.mit.edu
• METR (Becker, J., Rush, N., Barnes, E., & Rein, D.). (2025, July 10). "Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity." arXiv:2507.09089. Available at: arxiv.org/abs/2507.09089; summary at metr.org
• METR. (2026, February 24). "We are Changing our Developer Productivity Experiment Design." Available at: metr.org
• Murphy-Hill, E., Butler, J., & Savelieva, A. (2026). "Adoption and Impact of Command-Line AI Coding Agents: A Study of Microsoft's Early 2026 Rollout of Claude Code and GitHub Copilot CLI." arXiv:2607.01418. Available at: arxiv.org/abs/2607.01418
• Paradis, E., et al. (2024). "How much does AI impact development speed? An enterprise-based randomized controlled trial." arXiv:2410.12944. Available at: arxiv.org/abs/2410.12944
• Peng, S., Kalliamvakou, E., Cihon, P., & Demirer, M. (2023). "The Impact of AI on Developer Productivity: Evidence from GitHub Copilot." arXiv:2302.06590. Available at: arxiv.org/abs/2302.06590

• Adams, C., et al. (2026). "Automating Low-Risk Code Review at Meta: RADAR, Risk Calibration, and Review Efficiency." arXiv:2605.30208. Available at: arxiv.org/abs/2605.30208
• Alenezi, M. (2026). "How AI Changes DevOps Performance: A Mechanism-Based Simulation." arXiv:2609.32414. Available at: arxiv.org/abs/2609.32414
• Bexell, A., Gullstrand Heander, L., & Söderberg, E. (2026). "Orchestrating AI-Assisted Code Remediation: Socio-Technical Bottlenecks in a Large Industrial Repository." arXiv:2609.29172. Available at: arxiv.org/abs/2609.29172
• Cihan, U., et al. (2025). "Automated Code Review In Practice." ICSE-SEIP 2025, pp. 425–436. arXiv:2412.18531. Available at: arxiv.org/abs/2412.18531
• Ebiwonjumi, O., Ahakonye, L. A. C., & Kim, D.-S. (2026). "Examining Software Engineering Practices in the Pre-AI and Post-AI Era." ICAIIC 2026, pp. 651–656. Available at: doi.org/10.1109/ICAIIC68212.2026.11454249
• He, H., Agarwal, S., Denisov-Blanch, Y., Azaletskiy, P., Koyejo, S., & Vasilescu, B. (2026a). "AI Writes Faster Than Humans Can Review: A Longitudinal Study of an Enterprise 2x Mandate." arXiv:2607.01904. Available at: arxiv.org/abs/2607.01904
• Tantithamthavorn, C., et al. (2026). "RovoDev Code Reviewer: A Large-Scale Online Evaluation of LLM-based Code Review Automation at Atlassian." ICSE-SEIP 2026, pp. 34–45. arXiv:2601.01129. Available at: arxiv.org/abs/2601.01129

• Chretien, L., & Albarran, N. (2024). "Impact of AI-tooling on the Engineering Workspace." arXiv:2406.07683. Available at: arxiv.org/abs/2406.07683
• Faros AI. (2025, July 23). "The AI Productivity Paradox Report 2025." Available at: faros.ai/blog/ai-software-engineering; report page at: faros.ai/research/ai-productivity-paradox
• Faros AI. (2026). "The Acceleration Whiplash." AI Engineering Report 2026. Report page (22,000 developers, 4,000 teams, "5X Median Review Time," "3X Incidents per PR"). Available at: faros.ai/research/ai-acceleration-whiplash

• Agarwal, S., He, H., & Vasilescu, B. (2026). "AI IDEs or Autonomous Agents? Measuring the Impact of Coding Agents on Software Development." arXiv:2601.13597. Available at: arxiv.org/abs/2601.13597
• He, H., Miller, C., Agarwal, S., Kästner, C., & Vasilescu, B. (2026b). "Speed at the Cost of Quality: How Cursor AI Increases Short-Term Velocity and Long-Term Complexity in Open-Source Projects." MSR 2026. arXiv:2511.04427. Available at: arxiv.org/abs/2511.04427
• Jiang, W., & Lysenko, M. (2026). "Instant Software Factories." arXiv:2610.36254. Available at: arxiv.org/abs/2610.36254
• Kraishan, O. (2026). "Not All Agents Are Equal: Code Quality and Post-Merge Maintenance Across Five Autonomous Coding Agents in the Wild." arXiv:2609.17598. Available at: arxiv.org/abs/2609.17598
• Popescu, R. M., Gros, D., Botocan, A., Pandita, R., Devanbu, P., & Izadi, M. (2026). "Investigating Autonomous Agent Contributions in the Wild: Activity Patterns and Code Change over Time." MSR 2026. arXiv:2604.00917. Available at: arxiv.org/abs/2604.00917
• Takerngsaksiri, W., Duong, N., & Barnett, S. (2026). "Who Finishes the Job? A Study of Follow-Up Fixes and Commit Authorship on AI Coding Agent Pull Requests." arXiv:2609.26847 (figures from the abstract). Available at: arxiv.org/abs/2609.26847
• Xu, W., Cui, X., Ye, H., & Zhou, M. (2026). "Decoupling Code Complexity from Newcomer Participation: A Causal Study of AI Coding Agent Adoption in OSS." arXiv:2607.01810. Available at: arxiv.org/abs/2607.01810

• Aðalsteinsson, F. S., Magnússon, B. B., Milicevic, M., Davidsson, A. N., & Cheng, C.-H. (2025). "Rethinking Code Review Workflows with LLM Assistance: An Empirical Study." ESEM 2025, pp. 488–497. Available at: doi.org/10.1109/ESEM64174.2025.00013
• Baltes, S., Cheong, M., & Treude, C. (2026). "'An Endless Stream of AI Slop': How Developers Discuss the Burden of AI-Assisted Software Development." IEEE Software. Available at: doi.org/10.1109/MS.2026.3730626
• Määttä, S. (2025). "How Do Programmers Evaluate AI-Generated Code?" ESEM 2025, Doctoral Symposium, pp. 522–527. Available at: doi.org/10.1109/ESEM64174.2025.00057
• Määttä, S., Arif, H., Turhan, B., Ralph, P., & Kelanti, M. (2026). "How Do Software Professionals Evaluate AI-Generated Code? (Registered Report)." ESEM 2026 Registered Reports. arXiv:2607.09434. Available at: arxiv.org/abs/2607.09434

• Bacchelli, A., & Bird, C. (2013). "Expectations, Outcomes, and Challenges of Modern Code Review." ICSE 2013, pp. 712–721. Available at: doi.org/10.1109/ICSE.2013.6606617
• Bosu, A., Greiler, M., & Bird, C. (2015). "Characteristics of Useful Code Reviews: An Empirical Study at Microsoft." MSR 2015, pp. 146–156. Available at: doi.org/10.1109/MSR.2015.21
• Czerwonka, J., Greiler, M., & Tilford, J. (2015). "Code Reviews Do Not Find Bugs: How the Current Code Review Best Practice Slows Us Down." ICSE-SEIP 2015, pp. 27–28. Available at: microsoft.com
• Fagan, M. E. (1976). "Design and Code Inspections to Reduce Errors in Program Development." IBM Systems Journal 15(3):182–211. Available at: doi.org/10.1147/sj.153.0182
• Mäntylä, M. V., & Lassenius, C. (2009). "What Types of Defects Are Really Discovered in Code Reviews?" IEEE TSE 35(3):430–448. Available at: doi.org/10.1109/TSE.2008.71
• Rigby, P. C., & Bird, C. (2013). "Convergent Contemporary Software Peer Review Practices." ESEC/FSE 2013, pp. 202–212. Available at: doi.org/10.1145/2491411.2491444
• Rigby, P. C., German, D. M., & Storey, M.-A. (2008). "Open Source Software Peer Review Practices: A Case Study of the Apache Server." ICSE 2008, pp. 541–550. Available at: doi.org/10.1145/1368088.1368162
• Yang, C., He, H., Cheng, T.-C., Butler, J., Murphy-Hill, E., Badea, C., & Bird, C. (2026). "(When) Should a Software Factory be Lights-off? Benchmarking Code Review Agents on Bug Detection." arXiv:2610.13668. Available at: arxiv.org/abs/2610.13668

• Cohen, J. (2006). "The Largest Case Study of Code Reviews—Ever." StickyMinds (SmartBear). Available at: stickyminds.com; also at: SmartBear white paper
• McIntosh, S., Kamei, Y., Adams, B., & Hassan, A. E. (2014). "The Impact of Code Review Coverage and Code Review Participation on Software Quality: A Case Study of the Qt, VTK, and ITK Projects." MSR 2014, pp. 192–201. Available at: rebels.cs.uwaterloo.ca
• Sadowski, C., et al. (2018). "Modern Code Review: A Case Study at Google." ICSE-SEIP 2018, pp. 181–190. Available at: research.google
• Shimagaki, J., Kamei, Y., McIntosh, S., Hassan, A. E., & Ubayashi, N. (2016). "A Study of the Quality-Impacting Practices of Modern Code Review at Sony Mobile." ICSE 2016 (SEIP), pp. 212–221. Available at: rebels.cs.uwaterloo.ca

• Pearce, H., Ahmad, B., Tan, B., Dolan-Gavitt, B., & Karri, R. (2022). "Asleep at the Keyboard? Assessing the Security of GitHub Copilot's Code Contributions." IEEE S&P 2022, pp. 754–768. arXiv:2108.09293. Available at: arxiv.org/abs/2108.09293
• Perry, N., Srivastava, M., Kumar, D., & Boneh, D. (2023). "Do Users Write More Insecure Code with AI Assistants?" ACM CCS 2023, pp. 2785–2799. arXiv:2211.03622. Available at: arxiv.org/abs/2211.03622
• Siddiq, M. L., et al. (2026). "Security in the Age of AI Teammates: An Empirical Study of Agentic Pull Requests on GitHub." arXiv:2601.00477. Available at: arxiv.org/abs/2601.00477
• Spracklen, J., Wijewickrama, R., Sakib, A. H. M. N., Maiti, A., Viswanath, B., & Jadliwala, M. (2025). "We Have a Package for You! A Comprehensive Analysis of Package Hallucinations by Code Generating LLMs." USENIX Security 2025. arXiv:2406.10279. Available at: arxiv.org/abs/2406.10279
• Veracode. (2025, July 30). "2025 GenAI Code Security Report." Available at: veracode.com

• CodeRabbit. (2025, December 17). "State of AI vs Human Code Generation Report." Available at: coderabbit.ai
• Deng, G., Chen, Z., Yu, Z., et al. (2026). "SWE-Milestone: Evaluating AI Agents on Continuous Software Evolution" (first released as "EvoClaw"). arXiv:2603.13428. Available at: arxiv.org/abs/2603.13428
• GitClear. (2025). "AI Copilot Code Quality: 2025 Data Suggests 4x Growth in Code Clones." Available at: gitclear.com
• LeadDev (Doerrfeld, B.). (2025, February 19). "How AI generated code compounds technical debt." Available at: leaddev.com
• Tambon, F., et al. (2024). "Bugs in Large Language Models Generated Code: An Empirical Study." arXiv:2403.08937. Available at: arxiv.org/abs/2403.08937
• Wang, Y., Pradel, M., & Liu, Z. (2026). "Are 'Solved Issues' in SWE-bench Really Solved Correctly? An Empirical Study." ICSE 2026, pp. 169–181. arXiv:2503.15223. Available at: arxiv.org/abs/2503.15223

• Duma, K., et al. (2026). "These Aren't the Reviews You're Looking For: How Humans Review AI-Generated Pull Requests." EASE 2026. arXiv:2605.02273. Available at: arxiv.org/abs/2605.02273
• Khojah, R., et al. (2026). "Same Scrutiny, More Time: Eye Tracking Insights into Reviewing LLM-Labelled Code." ASE 2026. arXiv:2606.26505. Available at: arxiv.org/abs/2606.26505
• Manji, A. (2026). "Who Approved This? Coding Agents, Human Accounts, and Merge-Gate Evidence at a Fintech Startup." arXiv:2610.28683. Available at: arxiv.org/abs/2610.28683
• Nakashima, S., Ishimoto, Y., Kondo, M., McIntosh, S., & Kamei, Y. (2026). "Why Agentic-PRs Get Rejected: A Comparative Study of Coding Agents." arXiv:2602.04226. Available at: arxiv.org/abs/2602.04226
• Peralta, S. R. O., et al. (2026). "Why Are Agentic Pull Requests Merged or Rejected? An Empirical Study." MSR 2026. arXiv:2605.22534. Available at: arxiv.org/abs/2605.22534
• Soualhi, M. W., & Suleiman, B. (2026). "Co-Modifying Application Code and Deployment Infrastructure: A Causal Study of AI Agent Pull Requests." arXiv:2610.12849. Available at: arxiv.org/abs/2610.12849
• Yu, H., et al. (2026). "Habituation at the Gate: Rising Approval and Declining Scrutiny in Human Review of AI Agent Code." KDD 2026 Workshop on Agentic Software Engineering (SE 3.0). arXiv:2606.22721 (figures from the abstract). Available at: arxiv.org/abs/2606.22721

• Bainbridge, L. (1983). "Ironies of Automation." Automatica 19(6):775–779. Available at: doi.org/10.1016/0005-1098(83)90046-8
• Endsley, M. R. (2023). "Ironies of artificial intelligence." Ergonomics 66(11):1656–1668. Available at: doi.org/10.1080/00140139.2023.2243404
• Lee, H.-P., Sarkar, A., Tankelevitch, L., Drosos, I., Rintel, S., Banks, R., & Wilson, N. (2025). "The Impact of Generative AI on Critical Thinking: Self-Reported Reductions in Cognitive Effort and Confidence Effects From a Survey of Knowledge Workers." CHI 2025. Available at: doi.org/10.1145/3706598.3713778
• Mosier, K. L., Skitka, L. J., Heers, S., & Burdick, M. (1998). "Automation Bias: Decision Making and Performance in High-Tech Cockpits." International Journal of Aviation Psychology 8(1):47–63. Available at: doi.org/10.1207/s15327108ijap0801_3; also at ntrs.nasa.gov
• Parasuraman, R., & Manzey, D. H. (2010). "Complacency and Bias in Human Use of Automation: An Attentional Integration." Human Factors 52(3):381–410. Available at: doi.org/10.1177/0018720810376055
• Sellen, A., & Horvitz, E. (2024). "The Rise of the AI Co-Pilot: Lessons for Design from Aviation and Beyond." Communications of the ACM 67(7):18–23. arXiv:2311.14713. Available at: doi.org/10.1145/3637865
• Simkute, A., Tankelevitch, L., Kewenig, V., Scott, A. E., Sellen, A., & Rintel, S. (2024). "Ironies of Generative AI: Understanding and Mitigating Productivity Loss in Human-AI Interaction." International Journal of Human–Computer Interaction. arXiv:2402.11364. Available at: doi.org/10.1080/10447318.2024.2405782

• Bastani, H., et al. (2025). "Generative AI without guardrails can harm learning: Evidence from high school mathematics." PNAS 122(26). Available at: doi.org/10.1073/pnas.2422633122
• Budzyń, K., et al. (2025). "Endoscopist deskilling risk after exposure to artificial intelligence in colonoscopy: a multicentre, observational study." The Lancet Gastroenterology & Hepatology 10(10):896–903. Available at: doi.org/10.1016/S2468-1253(25)00133-5
• Casner, S. M., Geven, R. W., Recker, M. P., & Schooler, J. W. (2014). "The Retention of Manual Flying Skills in the Automated Cockpit." Human Factors 56(8):1506–1516. Available at: doi.org/10.1177/0018720814535628
• Shen, J. H., & Tamkin, A. (2026). "How AI Impacts Skill Formation." arXiv:2601.20245. Available at: arxiv.org/abs/2601.20245; Anthropic summary, "How AI assistance impacts the formation of coding skills" (January 29, 2026), at anthropic.com

• Naur, P. (1985). "Programming as Theory Building." Microprocessing and Microprogramming 15(5):253–261. Available at: doi.org/10.1016/0165-6074(85)90032-8
• Osmani, A. (2026, April 13). "Comprehension Debt: The Hidden Cost of AI-Generated Code." O'Reilly Radar. Available at: oreilly.com
• Stanford Digital Economy Lab. (2026, August 12). "No Widespread Displacement, but the AI Employment Gap for Young Workers Has Widened to 19%." Summary of the revised "Canaries in the Coal Mine? Six Facts About the Recent Employment Effects of Artificial Intelligence" by Brynjolfsson, E., Chandar, B., & Chen, R. Available at: digitaleconomy.stanford.edu
• Storey, M.-A. (2026, February 9). "How Generative and Agentic AI Shift Concern from Technical Debt to Cognitive Debt." margaretstorey.com. Available at: margaretstorey.com/blog/2026/02/09/cognitive-debt

• Heinemeier Hansson, D. (2025, July 12). "DHH: Future of Programming, AI, Ruby on Rails, Productivity & Parenting." Lex Fridman Podcast #474 (transcript). Available at: lexfridman.com
• Karpathy, A. (2026, January 26). "A few random notes from claude coding quite a bit last few weeks." Post on X. Available at: x.com/karpathy
• Lawson, N. (2026, February 7). "We mourn our craft." Read the Tea Leaves. Available at: nolanlawson.com
• Orosz, G. (2026, October 6). "The state of the tech industry in 2026." The Pragmatic Engineer (quoting an anonymous engineer). Available at: newsletter.pragmaticengineer.com
• Quigley, V. (2026, June 12). "We don't write code anymore." Sanity Blog. Available at: sanity.io/blog
• Van Dyck, C. [collinvandyck76]. (2026, February 21). Comment on "Why is Claude an Electron app?" Hacker News. Available at: news.ycombinator.com
• Willison, S. (2026, May 6). "Vibe coding and agentic engineering are getting closer than I'd like." Simon Willison's Weblog. Available at: simonwillison.net/2026/May/6/vibe-coding-and-agentic-engineering

• Böckeler, B. (2026, April 2). "Harness engineering for coding agent users." martinfowler.com. Available at: martinfowler.com
• Gray, A. (2026, February 9). "Minions: Stripe's one-shot, end-to-end coding agents." Stripe Dot Dev blog (Stripe describing its own system). Available at: stripe.dev
• Mahajan, S., Roy Choudhary, S., & Bond, W. (2025, August 12). "uReview: Scalable, Trustworthy GenAI for Code Review at Uber." Uber Engineering blog (Uber describing its own system). Available at: uber.com/blog/ureview
• Osmani, A. (2026, January 7). "AI writes code faster. Your job is still to prove it works." Available at: addyosmani.com
• Ronacher, A. (2026, February 13). "The Final Bottleneck." Armin Ronacher's Thoughts and Writings. Available at: lucumr.pocoo.org
• Son, E., & Li, K. (2026, September 2). "How River takes security work from a fix to merge." Shopify Engineering. Available at: shopify.engineering
• Willison, S. (2026, February 7). "How StrongDM's AI team build serious software without even looking at the code." Simon Willison's Weblog. Available at: simonwillison.net

• Cynthia, S. T., Widyasari, R., Roy, B., Zhang, T., & Lo, D. (2026). "'Go Home Copilot, You're Drunk': Understanding Developer Responses to Agent-Generated Code Review Comments." arXiv:2607.21997. Available at: arxiv.org/abs/2607.21997
• Frömmgen, A., & Kharatyan, L. (2023, May 23). "Resolving code review comments with ML." Google Research blog. Available at: research.google
• MacDiarmid, M., et al. (2025, November 21). "Natural Emergent Misalignment from Reward Hacking in Production RL." Anthropic. arXiv:2511.18397. Available at: arxiv.org/abs/2511.18397; summary at anthropic.com
• METR. (2025, June 5). "Recent Frontier Models Are Reward Hacking." Available at: metr.org
• Panickssery, A., Bowman, S. R., & Feng, S. (2024). "LLM Evaluators Recognize and Favor Their Own Generations." NeurIPS 2024. arXiv:2404.13076. Available at: arxiv.org/abs/2404.13076
• Vijayvergiya, M., et al. (2024). "AI-Assisted Assessment of Coding Practices in Modern Code Review." AIware 2024, pp. 85–93. arXiv:2405.13565. Available at: doi.org/10.1145/3664646.3665664
• Zhong, Z., Raghunathan, A., & Carlini, N. (2025). "ImpossibleBench: Measuring LLMs' Propensity of Exploiting Test Cases." arXiv:2510.20270. Available at: arxiv.org/abs/2510.20270

• Selvanayagam, N., & Ghaleb, T. A. (2026). "AI-to-AI Code Reviews of GitHub Pull Requests." ESEM 2026. arXiv:2608.21311. Available at: arxiv.org/abs/2608.21311
• Ye, J., Zou, H., Yu, S., & Shi, W. (2026). "Coding with 'Enemy': Can Human Developers Detect AI Agent Sabotage?" NeurIPS 2026. arXiv:2606.05647. Available at: arxiv.org/abs/2606.05647
• Zhong, S., Noei, S., Zou, Y., & Adams, B. (2026). "Human-AI Synergy in Agentic Code Review." arXiv:2603.15911. Available at: arxiv.org/abs/2603.15911

• Anthropic. (2026, October 13). "Redesigning source control at Anthropic." Anthropic Engineering. Available at: anthropic.com/research/redesigning-source-control
• Bishop, T. (2026, October 26). "Former GitHub CEO launches rival platform built for AI coding agents." GeekWire. Available at: geekwire.com
• GitHub. (2026, October). "Octoverse: commits and pushes reach new highs in 2026 as developers build with agents." The GitHub Blog. Available at: github.blog
• vester.si. (2026, October 28). "AI Impact: GitHub pull requests, 26 months." Independent analysis of GH Archive events. Available at: vester.si/ai-impact/github

• Clifford Chance. (2024, March). "The EU Cyber Resilience Act: towards a safe and secure digital market in Europe." Available at: cliffordchance.com
• Ghostty. (n.d.). "AI_POLICY.md." Ghostty repository. Available at: github.com
• LLVM Project. (n.d.). "AI Tool Use Policy." LLVM documentation. Available at: llvm.org/docs/AIToolPolicy.html
• SonarSource (Chatterjee, A.). (2025, July 29). "Cyber Resilience Act: Navigating speed and security with AI-coding." Available at: sonarsource.com

• Amazon Web Services. (2025, July 23). "Security Update for Amazon Q Developer Extension for Visual Studio Code (Version #1.84)." AWS Security Bulletin AWS-2025-015. Available at: aws.amazon.com/security/security-bulletins/AWS-2025-015
• Fortune. (2025, July 23). "AI-powered coding tool wiped out a software company's database in 'catastrophic failure'." Available at: fortune.com
• Snyk. (2025, August 27). "Weaponizing AI Coding Agents for Malware in the Nx Malicious Package Security Incident." Available at: snyk.io
• Willison, S. (2025, July 26). "Official statement from Tea on their data leak." Available at: simonwillison.net

• Blain, D., & Noiseux, M. (2026). "Broken by Default: A Formal Verification Study of Security Vulnerabilities in AI-Generated Code." arXiv:2604.05292. Generation vs. self-review of vulnerable code; full text not read. Available at: arxiv.org/abs/2604.05292
• Reddy, G. C. P., Lolla, A., & Sanku, H. (2026). "Articulate but Wrong: Self-Review Failures in LLM-Based Code Modernization." arXiv:2605.21537. Full text not read. Available at: arxiv.org/abs/2605.21537
• Sakib, A. H. M. N., Banik, D., & Jadliwala, M. (2026). "Trust but Verify? Uncovering the Security Debt of Autonomous Coding Agents." KDD 2026 AgenticSE workshop. arXiv:2607.12428. Security smells in agent-generated PRs; full text not read. Available at: arxiv.org/abs/2607.12428
• Singla, T., Çakar, B., Amusuo, P. C., & Davis, J. C. (2026). "Towards a Benchmark for Dependency Decision-Making." arXiv:2601.00205. Agent vs. human dependency changes and net vulnerabilities; full text not read. Available at: arxiv.org/abs/2601.00205
• Thornton, S. (2026). "Can Adversarial Code Comments Fool AI Security Reviewers – Large-Scale Empirical Study of Comment-Based Attacks and Defenses Against LLM Code Analysis." arXiv:2602.16741. Hard vulnerability classes for LLM reviewers; full text not read. Available at: arxiv.org/abs/2602.16741

• Ecosistema Startup. (2026, August 22). "Simon Willison lanza Agentic Engineering Patterns." Available at: ecosistemastartup.com
• Entrepreneur (Shibu, S.). (2025, April 30). "AI Is Taking Over Coding at Microsoft, Google, and Meta" (reporting Mark Zuckerberg's LlamaCon remarks; not checked against the recording). Available at: entrepreneur.com
• ITPro. (2025, May 16). "'Developers will need to adapt': Microsoft CEO Satya Nadella joins Google's Sundar Pichai in revealing the scale of AI-generated code" (reporting an on-stage estimate; not checked against a recording). Available at: itpro.com
• Orosz, G. (2026, September 8). "What is happening with code reviews?" The Pragmatic Engineer (paywalled; Duckbill Group's figures as relayed, not checked against Duckbill's own account). Available at: newsletter.pragmaticengineer.com
• The Decoder. (2026, April 23). "Google says 75 percent of its new code is now written by AI" (secondary coverage of a Pichai statement; Google's own post not read). Available at: the-decoder.com
• The Register. (2026, February 20). "Amazon's vibe-coding tool Kiro reportedly vibed too hard and brought down AWS" (reporting the Financial Times' anonymous sources; Amazon disputes it). Available at: theregister.com
• Turing College. (2026, March 17). "Agentic Engineering vs. Vibe Coding." Available at: turingcollege.com