Papers for

automated testing engineers

Papers whose findings have a practical use for this group, as judged from the abstract. Open a paper to read what it means in practice.

Cortex governs coding agents to meet requirements through fixed-point theory

Cortex: A Fixed-Point Theory of Governed Coding Agents - Technical Report

Abstract: A coding agent combines a large language model (LLM) with a harness that plans, edits, and executes code. We study Cortex, a supervisory layer for pre-execution governance, requirement tracking, and iterative validation and repair. We formalize requirement closure on a finite lattice. For a fixed requirement set and a sound, monotone validation rule with persistent evidence, exhaustive iteration reaches the least fixed point with no more strict increases than there are requirements. Fair consequence scheduling reaches the same closure. A separate stochastic model bounds expected completion time under a uniform positive-progress assumption. These results depend on their stated assumptions; artifact repair, fallible validation, and finite execution budgets do not satisfy them automatically. We define Gauntlet's trajectory-similarity and build-gated scores, attack-success estimators, Wilson intervals, and case-cluster bootstrap summaries. Effective-feedback accounting counts newly certified requirements, rather than estimating their information value or utility. The five evaluation families support raw-versus-governed comparisons. We report retained benchmark observations, including rescoring of existing artifacts; constructed outcomes are excluded. Unequal observation sets and incomplete provenance prevent causal claims about governance or measured long-horizon scaling.

Fri 16 OctArtificial IntelligenceMachine Learning
The gist
When computer programs are made by combining large language models with code editors and testers, it’s hard to ensure they meet all requirements. The authors study Cortex, a system that checks and fixes code before it runs by continually validating and updating it until everything fits together. They use math to prove this process reaches a stable point without endlessly looping. The study also measures how long it might take on average, given some ideal conditions. However, the proofs depend on some assumptions that may not hold in real-world settings like with faulty checks or limited time.
Open → 2610.24255v1

Self improving llms risk overestimating gains due to noisy selection

The Winner's Curse in LLM Self-Improvement Loops: Selection Noise, Lock-in, and Acceptance Rules

Abstract: Self-improving LLM systems propose changes to themselves and keep those that score better on a small evaluation set. We treat this keep-if-better step as selection under measurement noise, model the correlated errors of the candidates in a single decision, and study empirically what happens when the evaluation set is reused. In runs where Qwen models rewrite their own instructions and every candidate is also scored on 600 held-out items, most proposals after the first are harmful, and the model gives the size of the winner's curse of a generation's best candidate. With a prior from a separate pilot, it matches the average overstatement of first-generation commits in native loops, though not setting by setting. In a pre-registered study, the final selection-set score of greedy loops exceeded held-out accuracy by 13 to 20 points with 16 selection items and by 1 to 5 points with 256. Held-out gains grew with the selection set on TREC but not on GSM8K, and the tested acceptance rules did not beat greedy acceptance over whole runs. Gains measured on the selection set also exceeded held-out gains when a current model refined a competent instruction, and in the validation scores of GEPA and MIPROv2. Scoring the starting and the current instruction on 64 items never used for selection removes the average bias of a loop's reported gain, but single estimates remain off by about 6 points. Self-improvement studies should report held-out gains with their uncertainty.

Wed 7 OctArtificial IntelligenceMachine Learning
The gist
When large language models (LLMs) try to improve themselves by picking the best changes based on small tests, they often overestimate how good those changes really are. The authors studied how noise and reusing the same test set can make models keep harmful changes even if those seem better at first. They found that evaluation scores on the chosen test set usually appear better than true performance on new data. The study suggests reporting results on separate test data to avoid this bias in self-improvement loops.
Open → 2610.09239v1

Causal graphs improve agent runtime task execution control

Causal Improvement Graph for Agentic Harness Optimization

Abstract: Agentic Harness is the runtime that constructs task context and controls execution flow, thereby shaping overall agent performance. Given a fixed model and external evaluation, automated Harness optimization seeks to improve this runtime through an iterative proposal--evaluation loop to better solve target tasks. Existing meta-harness methods mainly adopt proposer-centric discovery, in which an LLM-based proposer integrates accumulated experimental findings to determine subsequent Harness revisions. This places the burden of maintaining the evolving improvement state on the proposer as history expands and its underlying experimental logic becomes harder to discern. In this paper, we introduce the Causal Improvement Graph (CIG), a graph-governed meta-harness framework that externalizes the evolving improvement state in a persistent graph, allowing prior findings to directly govern subsequent Harness optimization through local proposer operations. CIG grows and links Evidence, Hypothesis, Intervention, and Outcome nodes to represent what was observed, how it may be explained, how to test that explanation, and what the evaluation reveals. Their structural relations preserve how the improvement state changes across iterations, allowing local proposers to build directly on relations among prior findings rather than recover them from raw history. Across various agent tasks, CIG discovers stronger Harnesses than previous meta-harness baselines and remains robust to the choice of task solver and proposer. Structural ablations further support the design of an explicit improvement state with graph-governed evolution.

Sun 4 OctComputation and Language
The gist
Optimizing how computer agents plan and perform tasks is hard because improving their control systems depends on remembering past experiments and learning from them. The authors propose a method called the Causal Improvement Graph (CIG) that keeps track of what was tested, why, and what happened in a structured graph instead of just raw history. This helps the system build on past findings more clearly and effectively to improve agent performance. Their experiments show CIG leads to better task-solving strategies than prior methods and works well with different underlying models.
Open → 2610.05039v1

Gtdd improves ai code testing with fresh adaptive test generation

GTDD: Generative Test-Driven Development for AI Coding Agents with Adversarial Testing

Abstract: Test-driven development gives AI coding agents executable requirements for implementing software. Because these agents can adapt their implementations to the examples they observe, passing a predetermined collection of tests can leave substantial parts of the intended behavior unimplemented. We propose Generative Test-Driven Development (GTDD), a formulation of test-driven development in which a separate testing agent generates new inputs after each candidate implementation is fixed, using a human-specified behavioral contract and the feedback from earlier rounds. A trusted evaluator checks these inputs, returns reduced counterexamples to the coding agent, and saves them for regression testing, so development continually confronts failures beyond the initial examples. We characterize the evidence that this process provides through a finite-population analysis of false acceptance under adaptive candidate selection. The resulting bounds quantify how test visibility and repeated feedback affect acceptance, and show that fresh random audits after candidate commitment control false acceptance across development rounds. In a paired experiment on a stateful key-value store, both policies that regenerated tests during development ended with lower mean failure rates than the policy whose tests were generated once by the same language model, and giving the tester the candidate's source produced no detectable additional improvement. Further conditions requesting equal numbers of tests did not isolate any single feature of the policies as the source of this difference. GTDD combines this adaptive development feedback with established regression tests and an independent acceptance rule.

Fri 2 OctSoftware EngineeringMachine Learning
The gist
Software developers often write tests first to guide coding, but AI coding agents can sometimes pass tests without fully solving the problem. The authors introduce GTDD, a process where a separate AI tester keeps creating new tests after each code attempt, catching more errors. This approach forces the coding agent to fix more issues systematically. Their experiments show that regenerating tests during development leads to better software quality than relying on a fixed set of tests.
Open → 2610.02952v1

Ai writes and tests 21000 lines of Python code with errors tracked

Between the Commits: Process, Error, and Claim Reliability in a Wholly AI-Authored Codebase

Abstract: We present: (i) a new dataset consisting of the full development history of a 21,000-line Python tool built entirely by Claude AI, with no human-authored code or tests, (ii) two code-provenance tracing tools, (iii) three taxonomies for instruction intent, commit provenance, and response reliability, (iv) application of these to analyse the dataset. We find that: (i) user coding agent CLI instructions differ in kind from IDE-chat instructions, with a greater focus on comprehension, planning and consultation, (ii) code development is mainly proactive, (iii) 14.3% of AI code-generation events contain a real error later caught by the AI-authored test suite, (iv) roughly 1 in 4-5 of the AI's interactive responses contains one or more factual errors.

Thu 24 SeptSoftware EngineeringArtificial Intelligence
The gist
This paper looks at a software project where an AI called Claude wrote all the Python code and tests, with no humans writing code. The authors studied the types of instructions given to the AI and how the code evolved over time. They found that about 14% of the AI-generated code had real errors that the AI’s own tests later caught, and about one in five interactive responses from the AI had factual mistakes. Their tools and analysis help us understand how reliable AI-written code and communication can be.
Open → 2609.29744v1