What a Green Test Proves

To try before episode 7

• With code: Take a test an agent wrote and deliberately break exactly the line it is supposed to protect. If it does not turn red, you have found a blind spot.
• In the office: Plant a deliberate mistake (a wrong number, a swapped date) in a document the AI has checked for you, and have it checked again. Then ask of the most important assumption: where does it come from?
• As a team: Add the field "Which tests were changed, and why?" to your template for proposed changes.

Tool tips from the episode

• Lock test files in Claude Code: a deny rule in the project settings (.claude/settings.json), for example "permissions": { "deny": ["Edit(/tests/**)"] }. Deny rules take precedence over allow rules. Limit according to the docs: the rule covers the built-in file tools and recognized commands such as sed or tee, not scripts that open files themselves. Enable the sandbox for additional protection against indirect file access; its exceptions and commands run outside the sandbox still need to be accounted for. https://code.claude.com/docs/en/permissions and https://code.claude.com/docs/en/sandboxing
• Finer control with a hook: a PreToolUse hook with the matcher Edit|Write can block a change (exit code 2 or permissionDecision: "deny"), for example only for existing tests. https://code.claude.com/docs/en/hooks
• For the team as well: a CODEOWNERS file on GitHub automatically requests a review from the designated people for changes in the test folder; with the branch protection rule "Require review from Code Owners", their approval is mandatory. https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners
• Mutation testing for changed code only: Stryker.NET (C#) with --since:<branch> tests only code that changed since that Git reference. https://stryker-mutator.io/docs/stryker-net/configuration/ · StrykerJS (JavaScript/TypeScript) with --incremental reuses suitable results from the last stored run and reruns mutants when changes to code or tests require it. https://stryker-mutator.io/docs/stryker-js/incremental/ · PIT for Java: https://pitest.org · cargo-mutants for Rust with --in-diff: https://mutants.rs/in-diff.html

Sources

Foundation of the series

• Healthy AI First Software Development, version 2 (October 1, 2026), chapter 8 "Verification architecture" and chapter 9 "Human review and preserved understanding". The risk classes and the pattern for a second reviewer are explicitly labeled there as a process proposal, not a validated method.

Agents that bend tests

• Anthropic (February 2025): Claude 3.7 Sonnet, announcement and system card (section on reward hacking / special-casing of tests). https://www.anthropic.com/news/claude-3-7-sonnet and https://assets.anthropic.com/m/785e231869ea8b3b/original/claude-3-7-sonnet-system-card.pdf
• METR (June 5, 2025): Recent Frontier Models Are Reward Hacking. https://metr.org/blog/2025-06-05-recent-reward-hacking
• Zhong, Raghunathan, Carlini (2025, ICLR 2026): ImpossibleBench: Measuring LLMs' Propensity of Exploiting Test Cases. https://arxiv.org/abs/2510.20270

What tests really check

• Just, Jalali, Inozemtseva, Ernst, Holmes, Fraser (FSE 2014): Are Mutants a Valid Substitute for Real Faults in Software Testing? https://homes.cs.washington.edu/~rjust/publ/mutants_real_faults_fse_2014.pdf
• Inozemtseva, Holmes (ICSE 2014): Coverage Is Not Strongly Correlated with Test Suite Effectiveness. https://cs.ubc.ca/~rtholmes/papers/icse_2014_inozemtseva.pdf
• Madeyski, Orzeszyna, Torkar, Józala (IEEE TSE 2014): Overcoming the Equivalent Mutant Problem. Equivalent mutants keep the program's behavior unchanged and cannot be detected by any test suite. https://madeyski.e-informatyka.pl/download/Madeyski14TSE.pdf
• Petrović, Ivanković, Fraser, Just (IEEE TSE 48(10), 2022, 3900-3912; first published online in 2021): Practical Mutation Testing at Scale: A view from Google. Only changed code is mutated during code review, irrelevant mutants are filtered; more than 24,000 developers, more than 1,000 projects. https://arxiv.org/abs/2102.11378
• Petrović, Ivanković (ICSE-SEIP 2018): State of Mutation Testing at Google. https://research.google/pubs/state-of-mutation-testing-at-google/
• Petrović, Ivanković, Fraser, Just (ICSE 2021): Does Mutation Testing Improve Testing Practices? Almost 15 million mutants. https://arxiv.org/abs/2103.07189

A second model as reviewer

• Anthropic: Best practices for Claude Code (writer/reviewer pattern, fresh context: "A fresh context improves code review since Claude won't be biased toward code it just wrote."; "A reviewer prompted to find gaps will usually report some, even when the work is sound"). https://code.claude.com/docs/en/best-practices
• Kim, Garg, Peng, Garg (ICML 2025): Correlated Errors in Large Language Models. More than 350 models; on one leaderboard data set, the same wrong answer in about 60% of the cases where both models were wrong. https://arxiv.org/abs/2506.07962
• Jin, Chen (University of Sydney, 2026): Are LLMs Reliable Code Reviewers? Systematic Overcorrection in Requirement Conformance Judgement. https://arxiv.org/abs/2603.00539
• GitHub Docs: About GitHub Copilot code review ("Copilot is not guaranteed to spot all problems or issues in a pull request." "Supplement Copilot's feedback with a human review."). Checked October 16, 2026. https://docs.github.com/en/copilot/concepts/agents/code-review
• More on this (not in the episode): Kohli (preprint, May 28, 2026): Nine Judges, Two Effective Votes. 9 models, 7 families, natural language inference instead of code, effective jury size about 2.18. https://arxiv.org/abs/2605.29800 · Panickssery, Bowman, Feng (NeurIPS 2024): LLM Evaluators Recognize and Favor Their Own Generations. https://arxiv.org/abs/2404.13076 · Microsoft (July 14, 2025): AI review on more than 90% of internal PRs, practice report without causal evidence. https://devblogs.microsoft.com/engineering-at-microsoft/enhancing-code-quality-at-scale-with-ai-powered-code-reviews/ · Google Engineering Practices: What to look for in a code review. https://google.github.io/eng-practices/review/reviewer/looking-for.html

Human review

• Parasuraman, Manzey (2010): Complacency and Bias in Human Use of Automation: An Attentional Integration. Human Factors 52(3). https://journals.sagepub.com/doi/10.1177/0018720810376055
• Perry, Srivastava, Kumar, Boneh (CCS 2023): Do Users Write More Insecure Code with AI Assistants? 47 participants analyzed, codex-davinci-002. https://arxiv.org/abs/2211.03622
• Buçinca, Malaya, Gajos (CSCW 2021): To Trust or to Think: Cognitive Forcing Functions Can Reduce Overreliance on AI. N = 199. https://arxiv.org/abs/2102.09692

Preserving understanding and skills

• Bainbridge (1983): Ironies of Automation. Automatica 19(6), 775-779. Quotes in the episode taken from the original. https://gwern.net/doc/sociology/technology/1983-bainbridge.pdf
• Casner, Geven, Recker, Schooler (2014): The Retention of Manual Flying Skills in the Automated Cockpit. Human Factors 56(8). 16 airline pilots, Boeing 747-400 simulator. https://journals.sagepub.com/doi/10.1177/0018720814535628
• FAA (January 4, 2013): SAFO 13002, Manual Flight Operations. https://www.faa.gov/sites/faa.gov/files/other_visit/aviation_industry/airline_operators/airline_safety/SAFO13002.pdf
• Budzyń et al. (2025): Endoscopist deskilling after exposure to artificial intelligence in colonoscopy: a multicenter observational study. The Lancet Gastroenterology & Hepatology. Detection rate without AI fell from 28.4% to 22.4%; before/after comparison without a control group. https://wrap.warwick.ac.uk/id/eprint/191005
• Shen, Tamkin (2026): How AI Impacts Skill Formation (preprint, Anthropic Fellows). https://arxiv.org/abs/2601.20245