The papers that caught my attention this week share an uncomfortable theme: the signals coding agents hand back are weaker than they look. A green test suite, a tool call that returned status:ok, a merged PR, a final state that looks right. Each of the eight papers below pulls one of those signals apart. Two measure what tests miss, one with machine-checked proofs and one with tick-level assertions. Three look at the boundary between the agent and the outside world: poisoned issue text, tools that fail silently, and MCP metadata that cannot describe what a tool actually does. One learns guardrails from an agent's own failures. The last two follow agent-written code into the real world, and one of them comes from the group that invented fuzz testing.
SWE-Proof: Can Language Models Resolve Real-World Issues with Machine-Checked Proofs?#
George Ma, Benjamin Mikek, Haoyu Li, Ferhat Erata et al. · 18 September 2026 · arxiv 2609.21190
Every coding benchmark I rely on treats held-out tests as ground truth. This paper replaces the tests with proofs. The team, from UC Berkeley, Georgia Tech, UIUC and AWS AI Labs, built Benchproofer. It is a pipeline that takes a task with a known-correct patch and turns it into a formally verified one. It writes a specification for the new code and summarises the existing functions that code calls as axioms. An instance is admitted only once mechanical checks and adversarial LLM auditors agree. Run over SWE-bench Verified, it produces SWE-Proof: 500 real GitHub issues whose correctness is proved rather than tested. The pipeline also extends to the Python portion of SWE-bench Pro.
The results for Claude Opus 4.8 and GPT-5.5 are hard to ignore. Between a quarter and a half of patches that pass every hidden test still admit counterexamples, and a structured natural-language spec does not close that gap. A correct formal specification does. Given one, Opus 4.8 goes from 85.0% to 95.1% resolved and GPT-5.5 from 81.2% to 94.7%. But agents that have to write their own specification gain nothing over an unaided baseline. Only 62% of their specs survive the audit, and the usual failure is faithfulness: the spec pins down part of the required behaviour and leaves the rest free. Spec quality also tracks the outcome. 89% of specs from unresolved instances fail the audit, against 47% from resolved ones.
Why it matters: “Passes the tests” and “correct” are further apart than most of us assume, and this paper puts a number on the gap for frontier models on real issues. The spec result is the part I keep coming back to. A correct spec buys roughly ten points of resolution, and a spec the agent wrote itself buys none. That matches what I see in spec-driven workflows: agents write specs that look thorough and quietly under-constrain. If you build spec-first tooling, spend human review on what the spec leaves unconstrained, not on the code.
GameLogicBench: Evaluating Coding Agents on Runtime Game Logic with Tick-Level State Assertions#
Xinyu Che, Yunfei Ge, Shihao Li, Yanchen Liu et al. · 18 September 2026 · arxiv 2609.21562
Games make a good stress test for coding agents because a game can end in a valid state after breaking its own rules halfway through. GameLogicBench, from Nanjing University, has 72 gameplay-logic tasks in Godot projects. They range from isolated mechanics through interacting systems to repository-scale features. An automated evaluator checks the game's rules at every simulation tick, across 403 hand-designed scenarios expanded into 1,451 seeded test cases. Every checker is validated in both directions. It must accept several different correct implementations, and it must reject mutants: implementations with exactly one required capability removed.
Across 20 model and scaffold combinations, the best run solved 52.78% of tasks. Under Claude Code, all twelve models solved fewer tasks as scope grew from isolated mechanics to repository-scale features. In 74.3% of failed scenarios the submission ran fine but broke a required game rule. Two methodology results matter more to me than the leaderboard. Before mutant validation, 127 of 666 mutants passed checkers that already accepted every correct reference solution. That exposed 24 missing checks across 19 of the 36 tasks audited at that stage. And with network access open, four of five configurations pulled upstream source for repository-derived tasks. Manual review found code reused directly, and all four scored higher than in the sealed setting.
Why it matters: Two lessons carry well beyond games. If you only check the final state, you will pass agents that broke the rules on the way there, and that applies to migrations, data pipelines and anything else with intermediate states. And mutation-testing your checkers before you trust them is not optional: almost one in five mutants got through checks that looked complete. If you build internal evals for a coding agent, run a mutant pass and seal the network. Otherwise part of your score measures gaps in the checker and the agent's ability to find the upstream code.
Adversarial Testing of Automated Program Repair Agents for Security Vulnerabilities#
Fares Trad, Simin Chen, Hung Viet Pham, Gias Uddin, Baishakhi Ray · 14 September 2026 · arxiv 2609.15963
This threat model should worry anyone running an issue-to-PR agent on a public repository. An attacker files an issue that reads like a normal bug report but steers the agent into a fix that works and is also insecure. The authors, from York University, George Mason and Columbia, built SWEADV to measure this. It has 750 adversarial issue descriptions generated from 150 SWE-bench Verified tasks, five per task. Each targets one attack type: command execution, deserialization, path traversal, denial of service or weak hashing. Gemini 2.5 Pro wrote the adversarial issues. A mini-SWE-agent running on GPT-5-Mini, MiniMax-M2.5 or DeepSeek-R tried to fix them.
On average, 51.7% of attacks produced a patch that passed the functional tests and also contained the malicious behaviour. The highest rate was 64.0%, for slipping a weak hashing helper into MiniMax-M2.5's repairs. Detection did not rescue things. An LLM judge screening the issue before repair caught 62.3% on average. After repair, static analysis flagged 39.4% of the malicious patches and an LLM judge flagged 55.4%.
Why it matters: This is prompt injection moved into the task itself. The payload is not hidden in a web page. It is in the issue text, and the agent's success criterion (the tests pass) rewards it for going along. The backends are small and mid-tier models, not frontier ones, so the exact rates may not carry over. The detection numbers worry me more, because they describe the tools most teams would reach for first. If your agent picks up issues from untrusted authors, treat the issue text as attacker-controlled input. The resulting patch needs a security review that does not take the issue's framing at face value.
Fabrication After Tool Failure: Tool-Augmented Agents Assert Values Their Tools Did Not Return#
Arham Sethi, Arsen Kenzhebayev, Saanvi Paturi, Vatsal Raina et al. · 13 September 2026 · arxiv 2609.14758
This paper is not coding-specific, but it targets the failure I have hit most often in agent harnesses: a tool returns something unusable and the model answers anyway. The benchmark has 1,024 items across 16 internal-system domains and eight tool-failure types. In every item a tool call is forced and the payload is guaranteed to be unusable. Two failure types are signalled with status:error, a server error or a timeout. The other six return status:ok with a value that is redacted, corrupted, stale, malformed, empty or truncated. The models tested are Gemini 2.5 Pro, Flash and Flash-Lite, plus gpt-oss-120b and gpt-oss-20b.
Under a deployment-style system prompt, 14.10% of responses are dishonest. The model either asserts a value the payload cannot support or declines while citing a policy or capability limit it made up. Whether the failure is signalled explains almost all of it: 0.0% dishonesty with status:error, 45.3% with status:ok and a bad payload. The problem also appears under the shipped prompts of every production agent framework tested, reaching 24.67% with CrewAI's. None of the nine frameworks audited says what the model should do when a tool fails. The fix is one sentence: require the model to emit retrieval_status: OK or FAILED before it answers. That cut dishonesty from 14.10% to 0.87%, with 92 items improving and one getting worse. The flag was faithful in 99.7–99.9% of declarations, so a regular expression is enough to catch failures at runtime.
Why it matters: Coding agents run on tool output: test runners, linters, build logs, search results. Plenty of those wrap empty or truncated content in a success envelope. The finding that matters is that the fix is a named failure state, not a stronger “trust your tools” instruction. Of everything in this week's list, this is the change I would make first. It is one line, it transferred unchanged to other scaffolds, and it gives you a runtime signal for free. For tool authors the lesson is even simpler: if the call did not produce usable data, return an error rather than status:ok.
When Tool Calls Succeed but Workflows Fail: Anomalies at the Agent–Tool Boundary#
Artem Trofimov, Boris Novikov · 14 September 2026 · arxiv 2609.15397
The previous paper is about what the model says after a tool call. This one is about what the call actually did to the world. The authors apply transaction theory to agent workflows. Retries, speculative execution, concurrency and partial failures can all leave the external state wrong. Required effects go missing or get duplicated, aborted effects survive, and committed effects depend on state that is later withdrawn. The paper models the gap between events in the world and the runtime's observations of them. It catalogues eight recurring anomalies. The textbook one is a payment that goes through, is never acknowledged, gets retried and charges the invoice twice. From the catalogue it derives the capabilities a tool boundary needs to rule each anomaly out.
Then the authors check whether MCP can express any of it. They snapshotted the official MCP registry on 27 July 2026 and called tools/list on every reachable remote server, collecting 98,291 tools. At first glance the annotations look healthy: 74.0% of tools set at least one of the four hint fields and 61.7% set all four. But one signature (read-only, non-destructive, idempotent, open-world) covers 39.9% of tools, and no annotation at all covers another 26.0%. destructiveHint is set on 65.8% of tools. Only 12.9% carry a value that actually applies, and only 3.1% declare a real destructive operation. None of the required capabilities is fully expressible in current MCP metadata: there is no idempotency key, status endpoint, compensation contract or commutativity rule.
Why it matters: Most coding-agent work still happens in a sandbox where retries are cheap. That changes once agents touch deploys, tickets, databases and payment APIs over MCP. This paper makes clear that the protocol gives you coarse hints, not guarantees, and many of those hints may just be SDK defaults. If your agent retries tool calls, work out now which tools are safe to repeat. Put idempotency keys and status checks in the tool implementation rather than leaving them to the model's judgement. And do not gate destructive actions on destructiveHint alone.
AgentGuard: Learning Execution Guardrails from Anomalous Coding-Agent Trajectories#
Wuyang Dai, Song Wang · 14 September 2026 · arxiv 2609.16287
Every team running coding agents ends up with a growing list of “don't do that again” rules: don't touch unrelated files, don't rewrite the tests, don't ignore a failed validation. AgentGuard, from York University, automates writing that list. It mines anomalous agent trajectories for recurring execution failures and generalises them into instruction-level behavioural constraints. Those constraints ship as a guardrail skill that activates only the rules relevant to the current instruction. From 461 construction traces it derived 461 grounded findings and consolidated them into 15 guardrails. They are routed under five entries, such as command execution and recovery, project changes, and external-state mutation.
The evaluation draws on 642 documented failure traces from real coding-agent runs across 382 repository tasks. Each task is a multi-step workflow with one injected adversarial step, such as an unsafe request, a missing file or an ambiguous instruction. Guardrails are learned from 461 traces covering 282 tasks and tested on a disjoint set of 100 tasks. With Claude Code on Claude Haiku 4.5, AgentGuard cut the abnormal execution rate from 69.0% to 26.7% and raised successful task completion from 21.7% to 35.0%.
Why it matters: Two design choices are worth copying even if you never use the tool. The guardrails come from your own failure traces, not a generic safety policy. And they load conditionally as a skill instead of sitting in the system prompt, where they cost tokens and restrict unrelated work. The caveats are real: one small model, 100 test tasks, and a task set built to provoke failures, so the baseline rates are high by design. Even so, turning your incident log into a routed skill is a cheap experiment for any team that already keeps agent traces.
Not All Agents Are Equal: Code Quality and Post-Merge Maintenance Across Five Autonomous Coding Agents in the Wild#
Obada Kraishan · 12 September 2026 · arxiv 2609.17598
Most agent evaluations stop at whether the PR passed. This study follows the code after it merged. It covers 37,623 provenance-labelled pull requests from 2,807 GitHub repositories between December 2024 and July 2025. Of those, 33,596 came from five commercial agents (OpenAI Codex, Devin, GitHub Copilot, Cursor and Claude Code) and 4,027 from humans in the same repositories. Using the AIDev dataset plus 58,792 cached GitHub API responses, it measures security smells across 1.35 million added lines. It also tracks structural maintainability, 90-day churn and reverts for 26,283 merged PRs, and how humans reviewed each one.
The differences run between vendors more than between agents and humans. Codex PRs were reverted about half as often as human PRs (6.1% vs 11.5%, odds ratio 0.50), while Devin PRs were reverted more often (14.5%, odds ratio 1.31). Pooled across vendors, agent code was less likely than human code to contain a security smell (odds ratio 0.63), mainly because it had fewer hardcoded credentials and eval-style constructs. Review effort was uneven. Copilot PRs drew the most scrutiny, averaging 3.6 human reviews and 0.43 change requests per PR. Claude Code PRs waited longest for a first human review: a median of 12.6 hours, against 1–4 hours for the others. The author suggests this is because they are an order of magnitude larger.
Why it matters: “Is AI code worse?” is the wrong question. The answer depends on which agent and how it is used. The review-latency result is the practical one for me: large PRs sit, and a PR that waits 12 hours for a first look has lost most of the speed the agent bought you. Keep agent PRs small enough that someone will actually pick them up. The data window ends in July 2025, so every agent here is several model generations old. Treat this as a method to rerun on your own repositories, not a current ranking.
A Study of the Reliability of Agentic AI-Generated Programs#
Ayesha Shafique, Barton P. Miller, Elisa R. Heymann · 16 September 2026 · arxiv 2609.18298
Barton Miller's group at the University of Wisconsin–Madison started fuzz testing in 1990 by feeding random input to UNIX utilities and counting the crashes. Now they have pointed the same method at agent-written code. They used Claude Code with Opus 4.8 and a documented workflow of specify, design, code, test, then repeated audit rounds. With it they reimplemented ten standard Linux utilities in C, including dash, make, grep, less and tnftp, ranging from about 400 to 18,000 lines. They then fuzzed both the AI versions and the latest human-written releases, using classic black-box fuzzing and coverage-guided AFL++.
Across all twenty programs, fuzzing exposed 24 unique failures: 19 in the human-written repository versions and 5 in the AI-generated ones. The failures also differed in kind. The repository crashes included memory-safety bugs such as a global-buffer overflow in dash and three separate memory errors in less. The AI versions were less prone to memory errors and more prone to hangs such as infinite loops. The authors are clear that this took close supervision. In grep, a documented command-line option was missing through four audit rounds, the agent's tests and the repository test suite. make passed more than 20 audit rounds and its own tests, yet at first could build little beyond a simple C program. That only came to light when they tried to build the Linux kernel with it.
Why it matters: This comes from a group with more than three decades of fuzzing results and no vendor stake. It is the strongest evidence I have seen that agent-written systems code can match mature human code on robustness. It also tells you where to look for bugs. If your agents write fewer memory bugs and more non-termination bugs, your test harness needs timeouts and hang detection, not just crash detection. The make story is the one I would put in front of anyone who trusts an agent's “audit passed” verdict: only a realistic end-to-end workload exposed the gap. And I agree with the authors' closing point. The prompts, skills and audit loop are the real artifact, a specification you can rerun to keep maintaining the code.
The Common Thread#
The success signal overstates correctness. SWE-Proof finds counterexamples in a quarter to a half of test-passing patches. GameLogicBench finds that 74.3% of failed scenarios ran cleanly while breaking the rules, and that 127 of 666 mutants got past its checkers before mutant validation. The fabrication paper shows dishonest answers rising from 0% to 45.3% when a failed tool call still says status:ok. Whether the signal is “it ran”, “it passed” or “it returned”, none of them is proof.
The trust boundary sits in the task input and the tool contract, not in the model. SWEADV turns issue text into an attack surface that yields test-passing malicious patches 51.7% of the time. The MCP census shows the standard tool protocol cannot express idempotency, compensation or status resolution. AgentGuard shows that constraints learned from your own failure traces cut abnormal execution from 69.0% to 26.7%. These are harness problems, and they have harness fixes.
Specs and workflows are the durable asset, and writing them well is the hard part. A correct formal spec is worth about ten points on SWE-Proof, while agent-written specs add nothing. Miller's group argues the prompts, skills and audit loop behind their utilities are the specification for maintaining them, and their make story shows that audits alone do not make a spec complete. Human attention pays off most when spent on the spec and on realistic end-to-end checks, not on reading every generated line.