Was ein grüner Test beweist

Zum Ausprobieren bis Folge 7

• Mit Code: Nehmt einen Test, den ein Agent geschrieben hat, und macht absichtlich genau die Zeile kaputt, die er schützen soll. Wird er nicht rot, habt ihr einen toten Winkel gefunden.
• Im Büro: Baut in ein Dokument, das eine KI für euch geprüft hat, absichtlich einen Fehler ein (eine falsche Zahl, ein vertauschtes Datum) und lasst es noch einmal prüfen. Fragt danach bei der wichtigsten Annahme: Woher kommt sie?
• Im Team: Nehmt das Feld "Welche Tests wurden geändert, und warum?" in eure Vorlage für Änderungsvorschläge auf.

Werkzeug-Tipps aus der Folge

• Testdateien in Claude Code sperren: eine Verbotsregel in den Projekteinstellungen (.claude/settings.json), z. B. "permissions": { "deny": ["Edit(/tests/**)"] }. Verbote haben Vorrang vor Erlaubnissen. Grenze laut Doku: Die Regel gilt für die eingebauten Dateiwerkzeuge und bekannte Befehle wie sed oder tee, nicht für Skripte, die selbst Dateien öffnen. Für zusätzlichen Schutz gegen indirekte Dateizugriffe lässt sich die Sandbox aktivieren; dabei müssen auch Ausnahmen und Ausführungen außerhalb der Sandbox berücksichtigt werden. https://code.claude.com/docs/en/permissions und https://code.claude.com/docs/en/sandboxing
• Feiner mit einem Hook: Ein PreToolUse-Hook mit Matcher Edit|Write kann eine Änderung blockieren (Exit-Code 2 oder permissionDecision: "deny"), etwa nur für bestehende Tests. https://code.claude.com/docs/en/hooks
• Im Team zusätzlich: Eine CODEOWNERS-Datei auf GitHub fordert für Änderungen im Testordner automatisch eine Prüfung durch die festgelegten Personen an; mit der Schutzregel "Require review from Code Owners" ist deren Freigabe Pflicht. https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners
• Mutationstests nur für Geändertes: Stryker.NET (C#) mit --since:<branch> prüft nur Code, der sich seit diesem Git-Stand geändert hat. https://stryker-mutator.io/docs/stryker-net/configuration/ · StrykerJS (JavaScript/TypeScript) mit --incremental verwendet geeignete Ergebnisse des letzten gespeicherten Laufs wieder und prüft Mutanten erneut, wenn Änderungen am Code oder an den Tests dies erfordern. https://stryker-mutator.io/docs/stryker-js/incremental/ · PIT für Java: https://pitest.org · cargo-mutants für Rust mit --in-diff: https://mutants.rs/in-diff.html

Quellen

Grundlage der Serie

• Healthy AI First Software Development, Fassung 2 (01.10.2026), Kapitel 8 "Verifikationsarchitektur" und Kapitel 9 "Menschliche Prüfung und erhaltenes Verständnis". Die Risikoklassen und das Muster für einen zweiten Gutachter sind dort ausdrücklich als Prozessvorschlag gekennzeichnet, nicht als validiertes Verfahren.

Agenten, die Tests verbiegen

• Anthropic (Februar 2025): Claude 3.7 Sonnet, Ankündigung und System Card (Abschnitt zu Reward Hacking / Special-Casing von Tests). https://www.anthropic.com/news/claude-3-7-sonnet und https://assets.anthropic.com/m/785e231869ea8b3b/original/claude-3-7-sonnet-system-card.pdf
• METR (5. Juni 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

Was Tests wirklich prüfen

• 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. Äquivalente Mutanten ändern das Verhalten nicht und können von keinem Test entdeckt werden. https://madeyski.e-informatyka.pl/download/Madeyski14TSE.pdf
• Petrović, Ivanković, Fraser, Just (IEEE TSE 48(10), 2022, 3900-3912; online veröffentlicht 2021): Practical Mutation Testing at Scale: A view from Google. Nur geänderter Code wird im Code Review mutiert, irrelevante Mutanten werden gefiltert; über 24.000 Entwickler, über 1.000 Projekte. 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? Fast 15 Millionen Mutanten. https://arxiv.org/abs/2103.07189

Ein zweites Modell als Gutachter

• Anthropic: Best practices for Claude Code (Schreiber/Gutachter-Muster, frischer Kontext, Hinweis zu Gutachtern, die immer Lücken melden). https://code.claude.com/docs/en/best-practices
• Kim, Garg, Peng, Garg (ICML 2025): Correlated Errors in Large Language Models. Über 350 Modelle; auf einem Leaderboard-Datensatz gleiche falsche Antwort in etwa 60 % der Fälle, in denen beide falsch lagen. 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. https://docs.github.com/en/copilot/concepts/agents/code-review
• Mehr dazu (nicht in der Folge): Kohli (Preprint, 28. Mai 2026): Nine Judges, Two Effective Votes. 9 Modelle, 7 Familien, Sprachlogik statt Code, effektive Jurygröße etwa 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 (14. Juli 2025): KI-Review bei über 90 % der internen PRs, Praxisbericht ohne Kausalnachweis. 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

Menschliche Prüfung

• 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 ausgewertete Personen, 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

Verständnis und Fähigkeiten erhalten

• Bainbridge (1983): Ironies of Automation. Automatica 19(6), 775-779. 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 Linienpiloten, Boeing-747-400-Simulator. https://journals.sagepub.com/doi/10.1177/0018720814535628
• FAA (4. Januar 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. Erkennungsrate ohne KI von 28,4 % auf 22,4 %; Vorher-Nachher-Vergleich ohne Kontrollgruppe. 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