Builder, Defender, Breaker: Measurable Independence and Bounded Autonomy When Generative Models Build, Defend and Test Software
Not on the map. Why?
Abstract (arXiv)
Generative models now write application code, harden and monitor it, and probe it for exploitable flaws, so that one family of models increasingly plays builder, defender and breaker at once. The prevailing view treats full autonomy as the natural end point of assistance. This article argues for a narrower and more defensible position than a blanket requirement for human oversight. We define the shared generative substrate as the set of upstream dependencies (training corpus, model family, alignment procedure, vendor, toolchain) that induce correlated errors, and we define independence as a measurable property of pairs of lifecycle roles rather than an attribute of any participant. A coincident-failure model in the tradition of Eckhardt and Lee shows why organisational independence, the proxy on which verification standards have relied, no longer implies statistical independence once roles share a substrate; it also shows that heterogeneous models, deterministic analysers and formal verification can restore independence for the fault classes they cover. What remains for humans is specific: authority over the specification against which every machine oracle is judged, accountability that current governance instruments do not permit to be delegated, and last-resort authority to halt. We translate this into an operational framework with five autonomy levels, three distinct human roles and five decision criteria (consequence, reversibility, time-criticality, verifiability and adversarial exposure), apply it to build, defend and test actions, and specify how independence and oversight effectiveness can be measured. The central claims are stated as testable hypotheses with a protocol for refuting them.
Key facts. No citing papers in the map yet (data through 7 Oct 2026). Builds on 19 of its 43 references that are in the map. First posted on arXiv 3 Jul 2026.
Builds on
19 of 43 references.
References · 19
- 2024LLM Evaluators Recognize and Favor Their Own Generationscited by 651
- 2024Sleeper Agents: Training Deceptive LLMs that Persist Through Safety Trainingcited by 478
- 2021Asleep at the Keyboard? Assessing the Security of GitHub Copilot's Code Contributionscited by 417
- 2017Wild Patterns: Ten Years After the Rise of Adversarial Machine Learningcited by 411
- 2025The Illusion of Thinking: Understanding the Strengths and Limitations of Reasoning Models via the Lens of Problem Complexitycited by 298
- 2023Poisoning Web-Scale Training Datasets is Practicalcited by 276
- 2022Do Users Write More Insecure Code with AI Assistants?cited by 186
- 2024Cybench: A Framework for Evaluating Cybersecurity Capabilities and Risks of Language Modelscited by 156
- 2024Vulnerability Detection with Code Language Models: How Far Are We?cited by 133
- 2024LLM Agents can Autonomously Exploit One-day Vulnerabilitiescited by 125
- 2020You Autocomplete Me: Poisoning Vulnerabilities in Neural Code Completioncited by 112
- 2023LLMs Cannot Reliably Identify and Reason About Security Vulnerabilities (Yet?): A Comprehensive Evaluation, Framework, and Benchmarkscited by 94
7 more
- 2022Picking on the Same Person: Does Algorithmic Monoculture lead to Outcome Homogenization?cited by 89
- 2018Adversarial Examples that Fool both Computer Vision and Time-Limited Humanscited by 73
- 2025Great Models Think Alike and this Undermines AI Oversightcited by 53
- 2023TrojanPuzzle: Covertly Poisoning Code-Suggestion Modelscited by 47
- 2024How secure is AI-generated Code: A Large-Scale Comparison of Large Language Modelscited by 23
- 2026N-Version Programming with Coding Agentscited by 2
- 2026A Systematic Methodology for Evaluating Failure Independence in LLM-Generated Codecited by 1
Built on by
Not cited yet.