Papers for

software testing teams

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.

LLM agent performance drops under controlled noisy interactions

AgentPerturb: Evaluating LLM Agent Robustness under Controlled Interaction Perturbations

Abstract: Real-world tasks are often complex and noisy, posing substantial challenges for LLM agents. Yet existing evaluations lack a systematic framework for jointly characterizing potential perturbation targets and types. We use this two-dimensional view to conduct a unified study that quantifies the robustness of current frontier models, traces the mechanisms behind perturbation-induced failures, and draws implications for robustness-oriented training. Through controlled evaluations on APEX-Agents and Toolathlon, we find that perturbations consistently degrade performance, while the dominant vulnerabilities vary across task environments. Trajectory-level analysis reveals that agents rarely recognize altered inputs and often propagate corrupted information without verification. A focused cost analysis further shows that successful perturbed trajectories can require substantially more computation. These findings motivate training objectives that cover diverse forms of noise and reward verification, uncertainty awareness, and recovery. We provide a rigorous benchmark-construction pipeline. Code and data will be released at https://github.com/xuyj233/AgentPerturb.

Thu 15 OctArtificial Intelligence
The gist
Computers using large language models (LLMs) perform complicated tasks but can get confused when their inputs have small changes or mistakes. The authors studied how these AI agents react to different kinds of disturbances during interaction and found that their performance often gets worse. They discovered that agents usually do not notice when inputs are changed and tend to keep using bad information, which wastes time and computing power. Their work suggests training methods that teach agents to check their information and handle uncertainty better to make them more reliable.
Open → 2610.21624v1

Probe and resume improves agent success in terminal tasks

Probe-and-Resume: When and How to Evaluate Agent Execution

Abstract: Test-time search can improve agent performance by exploring alternative actions and using a critic to select promising branches. We study this approach in terminal-based computer-use environments, which expose only a partial view of a large underlying state, and find that the Monte Carlo tree search (MCTS) configuration we evaluate does not significantly improve task success. We identify two sources of poor critic performance: the agent's observations omit environment state needed for evaluation, and intermediate states offer limited evidence of whether a trajectory will succeed. At intermediate states, critics rank continuations only modestly better than chance, and environment access improves this little. We study when to invoke a critic and what access to give it to evaluate a node. Our findings motivate a policy that invokes the critic only at nodes the agent believes are final, rather than during partial progress. Further, the policy gives the critic read, write, and execute access to a fork of the computer's current and initial state, allowing it to probe and perform potentially destructive actions to surface any hidden state the trajectory omits. We call the resulting design Probe-and-Resume: when the agent claims to be done, the critic probes a fork of its state, and a rejected agent resumes where it stopped. On Terminal-Bench 2.1, this raises success by 8.4 percentage points over MCTS with conventional critics, and approaches the success rate of the Codex CLI agent with the same underlying model at less than half its cost.

Thu 15 OctArtificial IntelligenceMachine Learning
The gist
Computer programs called agents sometimes struggle to finish tasks when they can only see part of the computer's state. The authors found that usual methods to check the agent’s progress aren’t very good when the agent isn’t done yet. Instead, they created a method called Probe-and-Resume that lets the agent check its final answer more thoroughly by testing on a copy of the computer state. This helps the agent avoid mistakes and improves success rates significantly without much extra cost.
Open → 2610.21088v1

Coding agents fix more bugs by choosing whole files without compression

Skip the Compressor: Coding Agents Fix More Issues When They Pick Whole Files

Abstract: A coding agent works on repositories that can be far larger than its context window can hold. Prompt compressors and retrievers offer solutions to this problem, but patching an issue needs two things at once: the files that must change, and their code exactly as written, since the model must reproduce the lines it edits. Retrievers rank code by its similarity to the issue rather than by whether it must change, and compressors delete text to fit the budget. We show that at an equal token budget, an agent resolves more issues when the budget goes to choosing which files to show verbatim, as our simple selector CQ2-CARE does, than when it goes to pruning tokens or retrieving chunks. We fit every context to the same per-issue budget on 300 recent SWE-rebench issues and grade each patch with the benchmark's tests. With GPT-5.6 and Claude Opus 5, CQ2-CARE resolves 43.7% and 46.7% of the issues, 6.3 points more than the best of three compressors with either model, and 9.3 and 12.7 points more than the best of three retrievers. CQ2-CARE even resolves more issues than two methods trained for issue resolution, SweRank (by 0.7 and 1.7 points) and SWE-Pruner (by 2.0 and 7.3). Our analysis shows the defects of the baseline methods: retrievers often miss the files to edit, and compressors keep them but alter their text, so fewer patches apply. Exact-file selection needs no compression model and shows every line as the repository has it, so the model can quote the code it edits.

Thu 15 OctSoftware Engineering
The gist
When AI coding helpers try to fix software bugs, they can only look at a limited amount of code at once. Many methods try to pick parts of code to show by cutting or ranking pieces, but this can miss important changes or alter the code in ways that make fixes harder. The authors show that picking entire files exactly as they are, using a simple selection method called CQ2-CARE, helps these AI helpers fix more issues than other ways. This approach works better because it shows the AI the exact code it needs to edit, without missing files or changing code.
Open → 2610.21073v1

Rust security tools get better tests with new evaluation methods

Building Sound Evaluation Practices for Rust-Based Security Frameworks

Abstract: Background: Rust is a modern programming language known for its focus on usability, concurrency, and security. However, empirical studies reveal that Rust is still affected by software vulnerabilities, with hundreds of memory safety issues found in Rust programs, including Rust's standard library. As a result, additional tool-assisted security testing is crucial to enhance the security of Rust code. Evaluating such tools, however, is highly complex. While there is substantial research on evaluating C/C++ security frameworks, including test sets, serious issues in published evaluations have been identified, undermining their scientific soundness and reproducibility. In practice, selecting an inadequate implementation (e.g., a fuzzer) can lead to missed vulnerabilities ultimately compromising a program's security. Aims: Our methodology aims to help researchers to conduct scientifically sound evaluations in order to prevent similar issues with the evaluation of security tools and frameworks in the Rust ecosystem. Method: We systematically analyze existing evaluation literature to develop the first sound methodology for Rust based evaluations. Our guidelines provide enough flexibility to support a variety of use cases. To quantify the performance of a security tool, we introduce an automated approach to inject unsafe code coverage oracles, which require no forward porting, avoid overfitting, and allow updating test sets in the future. We also present methods to quantify the diversity of a Rust test set, ensuring that the results are applicable to a large set of existing Rust programs. We practically apply our methodology in our evaluation of the most popular Rust fuzzers. Results: We show the practical applicability of our design and conduct an evaluation with a diverse test set of 20 Rust projects. [...]

Wed 14 OctCryptography and Security
The gist
Rust is a programming language designed to be safe, but security problems still happen in Rust programs. The authors found that testing tools made to find these problems often have flaws in how they are evaluated. They developed a new method to test Rust security tools more reliably, including ways to automatically check coverage of risky code and measure how varied the test programs are. They tried this method on popular Rust testing tools and showed it works well with real Rust projects.
Open → 2610.20315v1

Large language models often produce flawed smart contracts despite compiling

SolBehave: Evaluating the Behavioural Correctness of LLM-Generated Smart Contracts

Abstract: Large language models increasingly generate Solidity smart contracts that, once deployed, can never be patched, making a single latent fault permanent and exploitable. Yet current evaluations mostly ask only whether generated code compiles. We introduce SolBehave, a benchmark for evaluating the correctness of model-generated contracts at scale, moving beyond ad hoc unit tests. Across 250 real, reproducible Ethereum contracts, we apply three complementary tests of behavioural fidelity: differential fuzzing, historical-transaction replay, and, as our core contribution, synthetic-transaction replay guided by a Dynamic Condition Response (DCR) graph that enumerates the space of legitimate function-call sequences. Differential fuzzing compares each generated function with the original on automatically generated inputs; historical replay compares the whole contract on the transactions it actually received on-chain; DCR-guided replay compares it on sequences of calls that follow its intended usage, including orderings that never occurred on-chain. We evaluate seven state-of-the-art open-weight models after one round of automated repair. Compilation success ranges from 26.4% to 92.7%, but under differential fuzzing only 31.4% of all generated function bodies that compile, pooled over models and samples, are equivalent to the original. Divergence at the contract level is the norm rather than the exception: for six of the seven models, between 13% and 31% of the generated contracts that compile diverge from the original under historical replay, and between 13% and 44% under DCR-guided replay; only Gemma-4-31B stays below 3% on both. Compilation is therefore a necessary condition for correctness and far from a sufficient one.

Tue 13 OctSoftware EngineeringArtificial Intelligence
The gist
Smart contracts are programs on blockchain that cannot be fixed once they are running, so mistakes in their code can cause permanent problems. The authors found that just checking if these programs compile is not enough to ensure they behave correctly. They created SolBehave, a tool that tests smart contracts more thoroughly by replaying real and possible transactions to see if the generated contracts act like the original ones. Their tests showed that many contracts generated by AI differ in behavior, which could lead to errors or vulnerabilities. This work highlights the need for better checking methods beyond compilation to trust AI-generated smart contracts.
Open → 2610.18745v1

Protocol tests if AI agents truly improve from experience traces

Trace Evolution Bench: Measuring Whether Agents Improve from Their Own Environment Traces

Abstract: Self-evolving agents are usually scored by endpoint Gain: held-out success after an update minus success before. That difference can credit a frozen rescore as evolution. We introduce Trace Evolution Bench (TEB), a protocol that separates that rescore from a context or weight update, together with three frozen 80/20/40 packs. An update is accepted only when validation does not fall, held-out identifiers never enter the update, and a text update is not ranked with a weight update. The primary scoreboard is coding, graded by hidden unit tests in a closed workspace. On that pack (40 held-out tasks, one family), DeepSeek v4 Pro under no_evolve never changes its policy yet moves 7.5, 5.0, and 12.5 percentage points across three seeds. Of nine text-update cells inspired by GEPA, ACE, and ExpeL, seven have positive excess above that seed's own band, and one gepa_llm seed moves down by the width of its band (-12.5, regression 0.48). GLM and MiniMax do not reproduce that seven-of-nine pattern. No method stays above its own band on every seed of all three models: GLM has two paired cells above their own bands, and MiniMax expel_llm seed 44 is a third (regression 0.30). The methods were fixed on a validation screen before held-out was read. Office, graded by rule-bounded delivery, and manufacturing table QA are separate packs: office DeepSeek does not exceed its own bands (widest 17.5 points), and manufacturing has no paired positive excess beyond its seed band.

Sat 10 OctArtificial Intelligence
The gist
Checking if AI agents actually get better by learning from past experiences is tricky because sometimes systems look improved without changing. The authors introduce a way to measure real improvement by separating simple rescoring from actual updates to the AI's behavior. They test various update methods on sets of coding and office tasks, finding mixed results where some improvements appear but are not consistent across all tests. This helps clarify which methods genuinely evolve AI performance from their own past interactions.
Open → 2610.15055v1

Re-executing llm coding tests confirms patch grading stability and unresolved risks

Re-executing Coding-Agent Evaluations: Unchanged Decisions and Unresolved Policy Risk

Abstract: Executable tests grade large language model (LLM) coding-agent patches for leaderboards, rewards and self-improvement. Two preregistered re-execution studies returned negative results. SWE-bench Pro v1's offline option rejected none of 59 accepted Go patches whose grading configuration changed. Their exploratory, unweighted upper confidence limit is 4.95% under candidate independence, leaving a 3% exposed-patch risk unresolved; the preregistered estimator uses inverse sampling-probability weights. An extension was inconclusive. In a selected stratum, a reconstructed module cache built from the reference solution's dependencies rejected accepted alternatives from four models that passed with their own dependencies. Re-executing 1,929 selected agent-version/task evaluations from the Darwin Gödel Machine's archive preserved best-agent selection and system-variant ranking, with search history and scores of evaluations not rerun fixed. Exploratory host, image and adapted-grader comparisons also preserved them. Seven of 23 disagreements with archived verdicts did not recur on a second host; rebuilt images changed 16 three-run majority verdicts (0.83%) under four-CPU execution. We provide an evidence-to-claim summary, lessons for grader audits and an anonymous replication package. These results concern accepted patches and fixed-history decisions; general policy safety and adaptive-learning robustness require broader evaluations.

Sat 10 OctSoftware EngineeringComputation and Language
The gist
The paper looks at how tests that grade code written by large language models (LLMs) perform when run again. The authors found that most decisions about which code patches are accepted or rejected stayed the same upon re-execution, showing grading is generally stable. However, there remains some uncertainty about whether some patches might be mistakenly accepted. Their work highlights the importance of careful testing but also shows that some risks in automated grading decisions remain unresolved.
Open → 2610.14460v1

Coding agents struggle to generate strong test suites from detailed specifications

TestSuiteBench: Coding Agents Struggle to Generate Strong Test Suites from Specifications

Abstract: Coding agents are increasingly used to create large software projects. While code-generation benchmarks have scaled accordingly to full applications, test-generation benchmarks remain limited to individual functions or bug fixes. In particular, generating complete test suites for complex software from scratch remains unexplored. To address this gap, we introduce TestSuiteBench, a benchmark of 165 open-source applications, each with a structured and detailed specification of intended behavior, a reference implementation, a reference test suite, and on average 74 mutants. Each mutant is generated from a single requirement of the specification and refined to isolate that behavior: 73\% are killed by exactly one reference test and, on average, by only 0.2\% of the remaining tests. We find that even frontier coding agents struggle to generate strong test suites given our specifications, achieving mutation scores below 60\%, despite their suites being largely valid and 88\% of their tests passing on the reference implementation. We observe that generated test suites often lack relevant input combinations and are smaller than reference test suites. Meanwhile, implementations generated for the same specifications pass 82\% of the reference tests. These results show agents can build software they cannot verify, a gap that directly limits fully autonomous software development.

Fri 9 OctSoftware Engineering
The gist
Creating complete test suites—collections of tests to check if software works as intended—is hard for AI coding agents even when given detailed instructions. The authors built TestSuiteBench, a set of 165 open-source apps with clear behavior rules, code, tests, and variations. They found that these AI agents produce test suites that miss important cases and don't catch many hidden bugs, although the generated code itself passes most reference tests. This shows that while AI can write software, verifying it thoroughly is still a challenge.
Open → 2610.13065v1

Improved lower bounds for complex network colorings in Ramsey theory

Lower bounds for Ramsey numbers: $\mathrm{R}(6,8)\ge 135$ and $\mathrm{R}(8,10)\ge 345$

Abstract: We prove the lower bounds $\mathrm{R}(6,8)\ge 135$ and $\mathrm{R}(8,10)\ge 345$, improving the bounds 134 and 343 listed in the April 2026 revision of Radziszowski's dynamic survey. We give explicit red/blue colorings of $K_{134}$ with no red $K_6$ or blue $K_8$, and of $K_{344}$ with no red $K_8$ or blue $K_{10}$, and verify them with two independently written exhaustive clique checkers. Starting from published colorings, we find these witnesses by adding vertices and repairing the resulting monochromatic cliques through local search. The search uses exact conflict counts, preparation moves aimed at making remaining cliques cheaper to break, and mutations followed by repair. A loss based on the largest monochromatic clique containing each edge yielded a useful intermediate state for the $\mathrm{R}(6,8)$ construction. Guided by the author, an AI coding agent wrote and ran the search code; we describe the methods and document the ancestry of the resulting colorings.

Thu 8 OctDiscrete Mathematics
The gist
Ramsey numbers are a way to understand how orderly or messy connections among points must become. The paper proves that two specific Ramsey numbers, R(6,8) and R(8,10), are bigger than previously known, meaning larger groups can avoid certain patterns of connections. The authors created explicit examples showing these larger sizes and used computer programs, some written by an AI assistant, to check them carefully. They improved known values by adding points and adjusting the connections using specialized search methods.
Open → 2610.12122v1

Benchmark reveals challenges in predicting exact program outputs and states

Evaluating Exact Output and Checkpoint-State Prediction in Real Programs

Abstract: We present a benchmark for predicting final output and checkpoint state from source and input alone. It extends CRUXEval-style output prediction with paired shorter- and longer-trace inputs and checkpoints inside and after a loop. The benchmark contains 400 cases from 371 Python and C++ programs, evaluated under seven settings from four model families without tools or code execution. Of 11,200 planned predictions, 11,151 produced gradable responses. Reasoning-enabled settings outperform their off counterparts by 33.1 to 55.2 percentage points on completed responses. The strongest setting scores 93.0% on shorter-trace final output, 77.0% on longer-trace final output, and 65.5% and 63.5% on the two state tasks; these scores also hold when missing responses count as wrong. Across 2,397 matched Python comparisons with identical source, changing to the longer-trace input yields 528 correct-to-wrong changes and 147 reversals. Source-clustered analyses preserve this accuracy gap, while adjusted Python models give no evidence of a positive incremental association between cumulative state load and error. Changed inputs and checkpoint tasks alter several factors together, so the gaps do not isolate trace length or an internal state-tracking mechanism. The benchmark exposes errors hidden by short-output scores alone.

Thu 8 OctSoftware EngineeringArtificial Intelligence
The gist
Predicting the exact final results and intermediate memory snapshots of computer programs just from their source code and inputs is hard. The authors created a new test set of real Python and C++ programs, with different input scenarios and checkpoints during loops. They tested several AI models that try to guess these outputs without running the code. Models that use reasoning do much better, but accuracy still drops for longer or more complex program traces. This benchmark helps find errors that simpler tests miss.
Open → 2610.11889v1

Error propagation modeling improves fault finding in multi agent AI systems

Error-Propagation Modeling for Failure Attribution in LLM-Based Multi-Agent Systems

Abstract: LLM-based multi-agent systems (MASs) are increasingly used to solve complex tasks through coordinated reasoning, tool use, and interaction with external resources. However, attributing failures in such systems remains challenging because the observed outcome often does not directly reveal the error responsible for the failed execution. In this work, the attribution target is the decisive error, defined as the agent--step pair whose correction would recover the failed execution. Existing approaches largely identify suspicious steps without explicitly modeling how errors propagate across interactions or persist in unresolved loops, making decisive errors difficult to distinguish from downstream failure symptoms. We propose \textbf{E}rror-Propagation \textbf{M}odeling for \textbf{F}ailure \textbf{A}ttribution (\textbf{EMFA}). EMFA constructs a structured representation of the failed trajectory, models both cascading propagation and persistent interaction loops, and uses propagation-aware candidate screening followed by counterfactual verification to identify the decisive agent--step pair. On the Who\&When benchmark, EMFA achieves state-of-the-art step-level attribution accuracy and remains competitive at the agent level. It improves the previous best step-level results by 3.45 and 4.40 percentage points on the Hand-Crafted and Algorithm-Generated subsets, respectively.

Thu 8 OctArtificial Intelligence
The gist
Multi-agent AI systems, where multiple AI agents work together, can sometimes fail, but it's hard to figure out which agent or step caused the problem. The authors introduce EMFA, a new way to track how errors flow and persist across interactions, helping pinpoint the exact agent and step responsible. This method uses structured error modeling and tests fixes virtually to find the key mistake. It performed better than previous methods on a known benchmark.
Open → 2610.11600v1

Vulvalidate improves accuracy of function vulnerability labels with runtime tests

VulValidate: Auditing Function-Level Vulnerability Labels with Executable Evidence

Abstract: Reliable learning-based vulnerability detection requires high-quality labels, yet datasets built from vulnerability-fixing commits may label functions as vulnerable simply because they were changed by a security patch. We present VulValidate, a framework that uses LLM agents to coordinate dynamic analysis tools and construct vulnerability-triggering experiments from runtime feedback. Given a labeled function and its fixing patch, VulValidate reconstructs vulnerable and fixed revisions, selects suitable tools and execution paths, refines triggering inputs, and compares runtime behavior to assess function-level attribution. We audit all 35,849 instances originally labeled vulnerable in BigVul, PrimeVul, and DiverseVul. We confirm 20,510 (57.2%), correct 6,819 labels (19.0%), leave 7,981 attacked but undecided (22.3%), and cannot successfully measure 539 (1.5%). After conflict resolution and byte-exact deduplication, the corrected release contains 15,890 distinct confirmed vulnerable function bodies. In a blinded review of 581 sampled decisions, expert consensus supports 90.0%--92.0% of confirmations and 92.6%--99.0% of label corrections. With model parameters fixed, corrected evaluation lowers F1 for all five tested detectors on both BigVul and DiverseVul; retraining with corrected labels improves F1 for four of five detectors on each dataset. We also release a reusable VulValidate skill, corrected datasets, and reproducible evidence for future vulnerability-detection research.

Sun 4 OctCryptography and SecurityArtificial IntelligenceSoftware Engineering
The gist
Many datasets that flag pieces of software as vulnerable do so only because those parts were changed during a security fix, which can be misleading. The authors created VulValidate, a system that runs actual tests on software to confirm if a function was truly vulnerable. By applying VulValidate to large vulnerability datasets, they found many labels were wrong or uncertain and produced corrected and verified labels. This helps make vulnerability detection tools more reliable and trustworthy.
Open → 2610.05103v1

Component replacement impact on local and task decisions in language model agents

What Can Component-Replacement Evidence Establish? A Critical Scoping Review of Local Decisions in LLM Agents

Abstract: Background. A component replacement in a language-model agent changes an execution trajectory, potentially altering later observations, resource use, and recovery opportunities. Different evidence is needed to assess its task-level benefit and the contribution of local decision quality. Methods. This critical scoping review maps 348 studies and examines 90 comparison records: 88 from 40 included studies and two from supplementary studies. Eight purposively selected cases structure the synthesis around the replaced decision, executed conditions, measurement comparability, controls, and remaining explanations. Results. Of 222 studies reporting local decision metrics, 142 also report measured task endpoints and 49 report proxies. These counts identify studies that report both types of measurement, without establishing that the measurements come from matched comparisons. Outcome Monitors reports a package-level completion gain whose attribution to detector quality remains limited; First-chunk selection reports a local improvement assessed against an offline proxy endpoint; Evidence-Carrying Termination reports fewer premature unsupported terminations and completion non-inferiority, without establishing completion superiority. Cross-case analysis identifies three candidate mechanisms involving recovery and disruption, intervention timing, and downstream use. Attribution and deployment depend on the comparison controls, label definitions, and information available to the controller. Conclusions. The review distinguishes the task-level benefit of a component replacement from the contribution of local decision quality and derives eight claim-specific reporting items. Neither online execution nor simultaneous gains in local and task metrics alone establish that better local decisions explain the task-level gain.

Wed 30 SeptArtificial Intelligence
The gist
This paper looks at how changing one part of a language model agent affects how it does tasks later on. The authors reviewed many studies and found that simply showing improvements in small decisions or in task outcomes does not prove that better small decisions cause better overall results. They explain that understanding these effects needs clear methods and controls. They also provide guidelines for reporting claims about these replacements.
Open → 2609.39989v1

Evaluating false memory in AI agents using counterfactual reasoning

Beyond the Shadows of Plato's Cave: Evaluating False Memory in Autonomous Agents via Counterfactual Reasoning

Abstract: Autonomous agents increasingly rely on memory to generalize beyond their training environments. However, agents are bounded by what they have seen and believed, and leveraging such memories in unseen environments can introduce biases into their internal beliefs. We formalize this phenomenon as \textit{false memory}, which can arise from spurious correlations, environment shifts, and knowledge conflicts. Despite its importance, false memory is difficult to evaluate because it stems from agent internal beliefs and is easily confounded with ordinary generalization failures. Therefore, we propose FAME, a training-free framework that evaluates false memory through the evolution of agent beliefs under counterfactual reasoning. Specifically, counterfactual scenarios reveal how beliefs change as the latent concept of memory shifts under hypothetical interventions; thus, measuring the resulting concept drift provides a signal for distinguishing faithful versus false memory. Such concepts can be estimated from agent hidden states before answer generation, avoiding the need for reward design or answer sampling. Empirical experiments reveal that simply monitoring answers often fails to detect false memory, while FAME achieves AUROCs of 76.2% - 96.7% across false-memory settings, and outperforms the best baseline by 3.4% - 23.3% across realistic benchmarks, spanning math reasoning (GSM-Symbolic), code generation (GitChameleon), and complex reasoning (BigBench-Hard). We further release corresponding counterfactual templates and facilitate future research on false memory.

Wed 30 SeptArtificial IntelligenceMachine Learning
The gist
AI agents use memory to solve problems beyond what they have directly experienced, but sometimes their memories can be wrong or misleading, called false memory. The authors introduce a tool called FAME that checks for these incorrect memories by imagining 'what if' scenarios to see how the AI’s beliefs would change. This approach helps detect false memory better than just looking at the AI’s answers. They tested it on tasks like math, coding, and complex reasoning and found it works well across different situations.
Open → 2609.39473v1

Agent improves video games by playing testing and learning from experience

RSIGame: Autonomous Agentic Game Development with Recursive Self-improvement

Abstract: Recent advances in large language models have made automatic game generation increasingly feasible, yet reliably improving generated games beyond a playable version remains challenging. Naive iterative refinement can easily overfit a small set of test cases, producing fragile games with unresolved bugs, missing behaviors, and poor generalization to broader player interactions. We introduce RSIGame, an autonomous agentic game development framework with recursive self-improvement. RSIGame organizes development into complementary local and global loops. Concretely, a local explore-diagnose-improve loop broadly explores the executable game, diagnoses and prioritizes discovered issues, and performs evidence-grounded revision, where an evolving checklist continually accumulates new testing and improvement guidance. A global loop tracks overall quality, preserves the best checkpoint, and detects saturation or regression over long-horizon development. Beyond test-time improvement, RSIGame further internalizes successful development experience into the generator through training. Across 140 GameCraft-Bench tasks, two game engines, and five generators, RSIGame consistently improves game quality under matched development budgets. Notably, experience internalization enables Qwen3.8-27B to reach 61.38 on Godot and 58.53 on Phaser, exceeding GPT-5.5 one-shot scores while reducing Qwen's generation tokens by 11 times.

Wed 30 SeptComputation and LanguageComputer Science and Game TheoryMachine Learning
The gist
Making video games automatically with AI is getting better, but fixing bugs and making games fun for many players is still hard. The authors designed RSIGame, an AI system that keeps playing and checking the game to find problems, fix them, and remember what worked well. RSIGame uses detailed step-by-step loops to spot issues and improve game quality over time, even training itself to get better at making games. When tested on many game design tasks, RSIGame consistently made games better than previous methods.
Open → 2609.39045v1

Adaptive evaluation finds more impactful failures with fewer tests

Risk-Aware Adaptive Evaluation: Finding High-Impact Failures Under Limited Budgets

Abstract: Evaluating interactive agents is expensive. Agent behavior is stochastic, so reliability must be measured over repeated trials, but failures are rare and differ widely in how much they matter. Standard benchmarks spend this budget uniformly: a read-only lookup is sampled as often as an irreversible payment action. We instead formulate evaluation as a sequential allocation problem. Given a fixed trial budget and a set of scenarios whose failure behavior is unknown, which scenarios should be run, and run again? We propose a risk-aware contextual Thompson Sampling policy that combines a pre-execution scenario context vector and a fixed impact score with the failure outcomes observed during evaluation, and we test it by offline replay over 70 $τ$-bench airline scenarios and 824 recorded trials. Our main result is at the smallest budget: with only 50 trials ($6\%$ of the corpus), the policy recovers $86\%$ of the impact-weighted failures an oracle could find, compared to $25\%$ for uniform allocation. It discovers $3.5\times$ more impact-weighted failures (215.4 vs. 62.2) with the same number of trials, delivers $5\times$ the discovery per dollar, and cuts the budget wasted on scenarios that never fail from $34\%$ to $2.8\%$. The rest of our analysis demonstrates and qualifies this result: a budget sweep shows the advantage shrinks as the budget approaches the corpus size, and paired significance tests show that scenario context helps mainly at small budgets while posterior-based exploration helps at moderate ones. Risk-aware adaptive allocation therefore helps most exactly where evaluation budget is scarcest.

Wed 30 SeptArtificial IntelligenceMachine LearningMultiagent Systems
The gist
Testing interactive agents to find failures can be very expensive, especially because failures are rare and differ in importance. The authors propose a smarter way to decide which test scenarios to repeat, using a technique that considers the risk and expected impact of failures. Their method finds many more significant failures using far fewer tests compared to testing all scenarios equally. This approach works best when testing resources are very limited.
Open → 2609.38914v1

Mubric improves evaluating large language model answers with mutation testing

Mubric: Mutation Testing-Guided Rubric Generation for LLM Evaluation

Abstract: Rubric-based evaluation is widely used to assess LLM-based systems by decomposing response quality into task-specific scoring criteria. However, automatically generating rubrics that reliably capture task-specific quality requirements remains challenging. We introduce Mubric, a mutation testing-guided approach to rubric generation. Mutation testing, a classic software testing methodology, evaluates a test suite by injecting faults into programs and checking whether the tests detect them. We draw an analogy between test suites and rubrics: if a rubric captures an important quality requirement, introducing a corresponding defect into an otherwise high-quality response should reduce its score. Mubric first mines common defects from real pairs of preferred and dispreferred responses and abstracts these defects into reusable mutation operators, each specifying how to introduce a particular type of response defect. For a new task, it applies relevant operators to a reference response, checks whether the injected defects reduce response quality, and uses insufficiently penalized defects to refine the rubric. We evaluate Mubric on 703 tasks across four representative domains against six advanced rubric generation methods. Mubric achieves the highest overall evaluation accuracy, outperforming the strongest baseline by 7.48 percentage points.

Tue 29 SeptArtificial IntelligenceSoftware Engineering
The gist
Evaluating the quality of AI-generated responses can be tricky because it's hard to create good scoring guides automatically. The authors propose Mubric, a method that uses mutation testing—a way to check test quality by introducing faults—to improve rubrics for scoring AI answers. Mubric learns common mistakes from real examples and uses them to test if the rubric properly penalizes these errors. Their tests show Mubric works better than previous automated methods across many tasks.
Open → 2609.37322v1

LLM evaluation method improves software engineering test reliability

SafeLLM4SE: Statistical Evaluation and Reporting for LLM-based Software Engineering Systems

Abstract: Large language models (LLMs) are increasingly used for software engineering tasks, yet their stochastic behavior challenges the validity, reproducibility, and comparability of their evaluations. Conventional practices such as reporting a single output, an average score, best-of-N, or pass@k performance can obscure variability and estimation uncertainty, potentially leading to misleading conclusions about system reliability. This article presents SafeLLM4SE, a practical methodology and reporting standard for statistically principled evaluation of LLM-based software engineering systems. Rather than treating generated outputs as deterministic artifacts, SafeLLM4SE treats them as realizations of a stochastic process and distinguishes quality, stability, and estimation uncertainty. It combines adaptive sampling with confidence intervals, distribution-aware statistical comparisons, effect sizes, and a minimum reporting standard covering model configuration, reproducibility, evaluation procedures, and resource usage. SafeLLM4SE is also provided as an open-source software package available on PyPI, enabling researchers and practitioners to reproduce and extend the methodology. We illustrate its application by comparing two LLMs on HumanEval, a benchmark of programming problems assessed through functional tests.

Tue 29 SeptSoftware EngineeringMachine Learning
The gist
Software tools powered by large language models (LLMs) can produce different outputs each time they run, making it hard to judge how reliable they are. The authors introduce SafeLLM4SE, a way to measure and report these tools' results statistically, showing not just average performance but also variability and uncertainty. This helps developers understand and compare LLM-based software testing more clearly. They also provide a free software package so others can use this method easily.
Open → 2609.37294v1

Llm reviews are less reliable than static tests suggest

Breaking the Illusion of Review Reliability under Static Evaluation: SCOPE Fuzzing for LLM-based Scientific Reviewers

Abstract: The rapid growth of submissions and reviewing workload has accelerated the use of large language models (LLMs) in peer review. Prior studies suggest that LLM-based reviewers can penalize content perturbations, such as overclaiming, indicating a certain degree of reliability. Yet these conclusions are largely based on a narrow set of perturbation strategies instantiated with static templates, providing limited evidence of actual reliability. In this paper, we construct a three-level evaluation framework covering perturbations to surface presentation, argumentative logic, and value judgment. Experiments on representative LLM-based reviewers reveal two limitations of static evaluation: stratified vulnerability, where perturbation effects depend on whether the paper's original review score is high or low, and perturbation undercoverage, where a single template misses vulnerabilities exposed by diverse realizations. To address these limitations, we propose SCOPE-Fuzzer, a strategy-aware fuzzer that combines feedback-driven strategy selection with adaptive mutation of paper content. By iteratively probing reviewers with dynamic perturbations, SCOPE-Fuzzer consistently uncovers vulnerabilities overlooked by static evaluation and other baselines.

Tue 29 SeptArtificial Intelligence
The gist
The paper shows that big AI models used for reviewing scientific papers may not be as reliable as previously thought. Previous tests only changed small, predictable parts of papers to see if the AI noticed problems. The authors find this method misses many hidden weaknesses and that AI reviews can be biased depending on the paper's initial score. They built a new tool called SCOPE-Fuzzer that changes papers in smarter, more varied ways to reveal these hidden problems. This tool helps better understand when and how AI reviewers might make mistakes.
Open → 2609.37097v1

VStress improves repeated verifier accuracy with adaptive budget allocation

VStress: Correlation-Aware Auditing and Adaptive Budget Allocation for Repeated Verifiers

Abstract: Repeated verifier calls are useful only when they contribute conditional information. We introduce VStress, an auditable replay contract, and VStress-CA, a correlation-aware allocation policy that estimates the conditional marginal information of an unqueried verifier on a sealed calibration split, discounts uncertainty, normalizes by call cost, and stops or abstains when the next call is not informative. The controller freezes its decision and cost ledger before joining the clean oracle; a dependence-shift alarm disables channel preference and falls back to exact-stop. The controlled audit gives the mechanism boundary: at 35% symmetric corruption, majority-5 improves balanced accuracy from 0.6578 to 0.7739, whereas at 65% it loses 0.1226 points. In the matched fixed-budget comparison, breadth, redundancy, and adaptive allocation obtain balanced accuracies 0.6048, 0.6375, and 0.6538, with 3.4216 calls per item and an RLVR score of 0.6417 for VStress-CA. Dependence diagnostics also increase from same-model repeats to cross-family channels, with conditional marginal gains of 0.0126, 0.0462, and 0.0913. These measurements turn correlation from a post-hoc warning into an auditable allocation decision.

Tue 29 SeptMachine LearningArtificial IntelligenceComputation and Language
The gist
Repeatedly checking a system is only helpful if each new check adds useful new information. The authors introduce VStress, which smartly decides when and how often to ask verifiers for checks to get the best information without wasting resources. VStress uses a method that understands how verifiers' results relate to each other and stops asking when no new useful information can be gained. This approach improves accuracy in identifying errors and works well even when some checks are unreliable or corrupted.
Open → 2609.36958v1

PrecogUI improves user interface agents by predicting problems early

PrecogUI: Proactive GUI Agents via Pre-cognitive Simulation and Experience Retrieval

Abstract: Existing reactive Graphical User Interface (GUI) agents often fail in long-horizon, dynamic scenarios, where unexpected disturbances trigger attention-diverting and cascading failures. To address this, we propose PrecogUI, a pre-cognitive architecture that shifts the paradigm from reactive execution to proactive decision-making. Specifically, we design a Proactive Experience Pool (PEP), which caches recurring anomaly and success patterns as "state-action-result" tuples in a dual-memory repository. Furthermore, we introduce a Proactive Simulation Executor (PSE) that learns to forecast the next symbolic UI layout given a candidate action, enabling early anomaly avoidance and ranking candidate actions by predicted reliability. Finally, a Pre-cognitive Execution Controller (PEC) fuses these priors and predictions, prioritizes handling of foreseen anomalies, and ensures execution robustness through a closed-loop error correction mechanism. For robust evaluation, we develop AutoTraj, an automatic data-generation engine, to construct InterfereBench, a benchmark for long-horizon tasks with strong disturbances. Experiments demonstrate that PrecogUI surpasses state-of-the-art methods on InterfereBench while maintaining competitive performance on public benchmarks. The code will be publicly available.

Tue 29 SeptArtificial Intelligence
The gist
Graphical user interface agents usually react to changes after they happen, which can cause problems over long tasks when unexpected issues arise. This paper introduces PrecogUI, a system that helps these agents think ahead by predicting possible problems before they occur. It learns from past successes and failures, simulates future screen layouts after potential actions, and chooses the best steps to avoid errors. Tests show that PrecogUI works better than current methods in challenging scenarios with many disturbances. This approach helps make automated UI agents more reliable for complex tasks.
Open → 2609.36923v1

Models struggle to predict code changes impact on software behavior

CTE-Bench: Counterfactual Trace Evaluation for Stateful Software Simulators

Abstract: Coding agents change running software: they patch a service's code or overwrite its stored state, and then act on their own expectation of how the service will respond afterwards. A wrong expectation may surface only several calls later. Function-level code-execution benchmarks omit persistent service state, and agent benchmarks score the actions an agent takes or the final state it reaches. We introduce CTE-Bench, which measures whether a model can predict how an intervention changes a stateful service's future behavior, without asking it to choose actions. Each scenario gives the model Python service code, the calls and responses observed before the intervention, the intervention itself (a source edit or a state overwrite), and 40 fixed future calls; the model predicts every future response, and predictions are checked by executing the service. Three memory protocols control whether the model sees the correct earlier responses, none of them, or its own earlier predictions. CTE-Bench-Core-v1 contains 255 scenarios over six deterministic Python services, giving 10,200 predictions per model. The main score is effect-step value match (VM): exact response equality on the 2,476 future calls whose response the intervention changes. With correct earlier responses revealed, four API-hosted models (DeepSeek V4-Flash, Kimi K2.5, Qwen3.6-35B-A3B, and Claude Sonnet 4.6) reach 54.3%-61.5% effect-step VM. Hiding those responses lowers effect-step VM to 23.2%-28.9%; conditioning on self-generated predictions gives 24.8%-33.2%, and at most 1.2% of scenarios are predicted exactly end to end. Current models thus track intervention effects mainly when correct feedback is supplied, and their errors compound over a rollout. We release CTE-Bench-Core-v1 with its executable oracle, evaluation scripts, and an evaluation card mapping each claim to its protocol.

Tue 29 SeptSoftware Engineering
The gist
When software is changed or its state is altered, predicting how it will behave afterward is difficult. The authors created CTE-Bench, a test that checks if models can guess how these changes affect future software responses. The test shows that current models only do well when given correct past responses, and their predictions get worse over time. This reveals challenges in building AI that understands stateful software changes reliably.
Open → 2609.36647v1

Benchmark reveals gaps in test generation across programming languages

Multi-SWT-Bench: A Multilingual Benchmark for Reproduction Test Generation

Abstract: Reproduction test generation translates a natural-language issue description into executable tests that fail on the original code and pass after the issue is resolved, providing executable evidence for verifying candidate patches. Existing benchmarks are constructed for individual programming languages, preventing a unified evaluation across diverse programming ecosystems. To address this limitation, we introduce MULTI-SWT-BENCH, a multilingual benchmark for reproduction test generation consisting of 1,963 instances across eight programming languages: Python, Java, TypeScript, JavaScript, Go, Rust, C, and C++. Using this benchmark, we conduct an empirical study of state-of-the-art LLMs with four representative methods (MSWE-agent, MOpenHands, Codex, and Claude Code) and perform a failure analysis across programming languages. Our evaluation reveals a systematic language gap. Across every evaluated method and LLM, the success rate on Python exceeds the aggregate success rate across all languages, while C++ exhibits particularly low success rates. Our failure analysis identifies both language-specific challenges arising from repository testing conventions and cross-language challenges in inferring implicit setup requirements and preserving the target behavior through iterative revisions. These findings demonstrate the importance of multilingual evaluation and provide actionable directions for developing reproduction test generation methods that generalize across software ecosystems and reliably capture issue-specific behavior.

Mon 28 SeptSoftware Engineering
The gist
This paper looks at how tools can automatically create tests from bug reports in many programming languages. The authors made a large benchmark with nearly 2,000 examples in eight languages like Python, Java, and C++. They found that current AI methods work best for Python and struggle the most with C++. Their study highlights specific challenges both unique to certain languages and common across all languages when creating these tests. This work helps improve tools that verify software fixes across many programming environments.
Open → 2609.34752v1

Dual perspective test input prioritization improves dnn fault detection

When Ambiguity Meets Atypicality: Dual-Perspective Test Input Prioritization for DNNs

Abstract: While Deep Neural Networks (DNNs) have achieved remarkable progress in cutting-edge domains, their inherent brittleness has become a growing concern. To ensure the reliability and safety of DNN-enabled software, DNN testing has emerged as an indispensable practice. Within this context, test input prioritization is essential for early fault detection and reducing labeling costs. However, it remains challenging to accurately identify failure-inducing inputs. Although decision ambiguity and distributional atypicality are two widely adopted perspectives for characterizing inter-class competition and intra-class typicality respectively, relying on either perspective in isolation inevitably introduces blind spots. In this paper, we propose DuFP (Dual perspective Feature space Prioritization), a KNN density-based test input prioritization approach for DNNs that jointly incorporates both inter-class and intra-class perspectives. The prioritization framework of DuFP is built upon class-conditional density estimation. Based on the estimation results, prediction correctness is characterized by an ambiguity score and an atypicality score, with the former reflecting decision ambiguity and the latter quantifying distributional atypicality. A hybrid uncertainty score is then constructed by integrating both scores to guide the final prioritization. We evaluate DuFP on prioritization and selection tasks across image and text datasets under clean, corrupted, and adversarial scenarios. Experimental results demonstrate that DuFP effectively and efficiently prioritizes fault-inducing inputs and outperforms state-of-the-art approaches.

Mon 28 SeptSoftware Engineering
The gist
Deep neural networks can sometimes make unexpected errors, which is a problem for software relying on them. The authors propose a new way to find test cases that are likely to cause errors by combining two ideas: how unsure the network is about its decision and how unusual the input is compared to what it normally sees. Their method, called DuFP, uses these ideas together to better spot tricky inputs that might cause failures. They tested DuFP on images and text under different conditions and found it works better than other similar methods.
Open → 2609.34703v1

Coding agents face new puzzle test requiring deep program reasoning

Codoku: Renewable Program-Reasoning Challenges for Frontier Coding Agents

Abstract: Existing program-reasoning benchmarks ask large language models to predict a program's behavior on a given input. Coding agents break two assumptions on which these benchmarks rest: an agent can recover the answer by executing the program instead of reasoning about it, and fixed task sets drawn from existing programs are increasingly exposed to contamination, yet costly to renew. We introduce Codoku (code sudoku), a renewable benchmark in which a solver fills typed cells in a partial program to satisfy global static and dynamic constraints, such as a prescribed control-flow graph and execution path. Because a partial program cannot be executed and valid fillings are sparse in an exponentially large space of interdependent choices, neither tool use nor enumeration can substitute for program reasoning. Puzzles are synthesized from scratch via semantic reification, so fresh puzzles of controllable complexity can be generated on demand, each with a witness that guarantees solvability. We evaluate five frontier models on 300 puzzles through a coding agent free to use any tool within a fixed budget. Small puzzles already challenge open-weight models, whereas even proprietary models solve only about half of the large ones. Codoku thus offers a renewable testbed for program reasoning that can keep pace with rapidly improving coding agents. GitHub: https://github.com/connglli/Codoku.

Mon 28 SeptSoftware EngineeringArtificial Intelligence
The gist
Existing tests for coding AI mainly ask models to guess what a program will do, but these tests assume the AI can't run the program to check. The authors created Codoku, a puzzle game where AI must fill in missing parts of a program without being able to run it, forcing it to think through how the pieces fit together. Because puzzles are generated fresh each time and have guaranteed solutions, Codoku stays challenging and fair as AI gets better. Tests show even strong models struggle with the harder puzzles, showing this is a useful new way to measure coding reasoning skills.
Open → 2609.34661v1

Coding agents build and repair games with limited accuracy

SWE-Game: Can Coding Agents Build the Games We Want?

Abstract: We introduce SWE-Game, a benchmark of 247 tasks grounded in 41 executable reference Godot games spanning 13 gameplay categories in 2D and 3D. Five task types cover development from a brief, implementation from a game design document, skeleton completion, repair of 83 injected-fault cases, and Godot-to-Unity porting. Reference materials specify the intended gameplay, while a shared instrumentation interface lets evaluator-owned drivers and probes execute actions and observe independently implemented games. Evaluation combines engine-state checks, certified reference-input replay, and agent-authored feature demonstrations to assess mechanic correctness, demonstrated playability, and behavioral restoration and preservation after repairs. Game-specific vision-language rubrics separately assess presentation. Across six models, Opus5 achieves the highest overall score in all five task types. Best overall scores remain below 60 out of 100 across the three construction tasks, with Brief-to-Game reaching 50.38. Analysis of reviewed submissions identifies requirement omissions and gameplay logic errors as predominant implementation problems. On human-labeled behaviors from 100 agent-built games, executable checks achieve 92.59% balanced accuracy, compared with 78.41% for a video-based VLM judge. Rubric-based visual scores reach a Spearman correlation of 0.829 with human ratings of 200 gameplay clips. Together, these results characterize current agent capabilities across game-development activities and support combining runtime evidence with visual assessment.

Sun 27 SeptArtificial Intelligence
The gist
Making video games is hard and requires careful coding to work right. The authors created SWE-Game, a set of tasks and tests where computer programs try to make or fix games following specific instructions. They tested different AI models and found that while some can build playable games, their accuracy is still below 60 out of 100, with many mistakes in following requirements and gameplay logic. The study also developed ways to check if the games work as intended by replaying inputs and using visual checks that match human judgments fairly well.
Open → 2609.33678v1

Benchmark measures collaboration in asynchronous multi-agent coding tasks

AsynCodeBench: Benchmarking Collaboration of Asynchronous Multi-Agent Systems in Software Engineering

Abstract: Multi-agent coding has emerged as an increasingly active direction in software engineering, where complex development tasks are decomposed across multiple specialized agents working on different parts of the problem. Despite the shift from individual problem solving to distributed collaboration, multi-agent systems still lack a direct measure of collaboration and are largely evaluated through task-level outcomes inherited from single-agent coding, conflating individual coding capability with cross-agent coordination. We introduce AsynCodeBench, a dependency-centric benchmark for asynchronous multi-agent software engineering that represents each task with an explicit dependency graph and executable Dependency Checkers. Through this dependency-tracking process, we propose two complementary measures: Asynchronous Dependency Pass Rate (ADPR), which measures how many cross-agent dependencies are ultimately satisfied, and Dependency Resolution Step (DRS), which measures when each dependency first becomes satisfied during execution. AsynCodeBench comprises 19 tasks from real-world repositories, exposing 52 directed dependencies as explicit units for evaluating cross-agent collaboration. Experiments across model families, scales, and generations reveal a clear gap between coding and collaboration capability: improvements in coding performance do not necessarily translate into stronger collaboration, and task-level metrics can diverge substantially from dependency-level collaboration measures. Dependency-trajectory analysis further reveals that successful coordination often emerges not gradually, but through concentrated bursts in which many dependencies become resolved over a short portion of the execution trajectory, a pattern we term a hopping window.

Sat 26 SeptSoftware EngineeringArtificial IntelligenceMultiagent Systems
The gist
When many computer programs work together to write code, it can be tricky to tell how well they actually coordinate with each other versus just how good they are individually. The authors created a new way to measure teamwork by breaking coding tasks down into smaller parts that depend on each other. They track when and how these parts get completed to see how well different agents work together. Their experiments show that just being good at coding alone does not mean the agents collaborate well, and teamwork often happens in sudden bursts rather than gradually.
Open → 2609.32662v1

NeuroTestGen combines symbolic reasoning and AI to improve software test coverage

NEUROTESTGEN: Neuro-Symbolic Guided Test Generation with Large Language Models

Abstract: Ensuring high structural coverage remains a fundamental challenge in automated test generation, particularly for complex software systems where reaching specific lines or branches requires satisfying intricate control- and data-flow constraints. Large Language Models (LLMs) have recently demonstrated strong capabilities in producing human-like test cases; however, they often struggle to generate inputs that satisfy precise path conditions. Conversely, symbolic execution can systematically derive such constraints, but it often fails to construct realistic, executable test cases and is constrained by scalability limitations. In this paper, we introduce NEUROTESTGEN, a hybrid approach that integrates symbolic execution with LLM-driven test synthesis to generate test cases targeting on-demand code coverage. Given a set of target statements within a method, NEUROTESTGEN first employs a symbolic analysis engine (i.e., the Z3 SMT solver) to extract path-specific constraints and construct a symbolic guidance specification for the desired coverage goal. This specification is then used to guide an LLM in synthesizing concrete test cases that are both structurally valid and semantically meaningful. For paths involving complex object-related constraints that are difficult for SMT solvers to handle, NEUROTESTGEN leverages LLMs to infer plausible constraints. Furthermore, NEUROTESTGEN incorporates an iterative feedback loop that validates LLM-generated tests and provides corrective guidance until the target line or branch is covered or a limit is reached. Our empirical evaluation on a widely used benchmark demonstrates that NEUROTESTGEN significantly outperforms the state-of-the-art approach across multiple LLMs, including Llama 3.3 70B1, GPT-4o Mini, Claude 3.5 Haiku3, and Claude Sonnet 4.6.

Thu 24 SeptSoftware Engineering
The gist
Testing software to cover all parts of the code is hard, especially when tests need to follow complicated rules. The authors created NeuroTestGen, which uses smart software reasoning with symbolic tools and large language AI models together. This combo helps make tests that reach specific parts of code more often and that actually run properly. Their system checks and fixes test cases until the goal is met or tries run out. Tests showed it works better than current methods on common coding benchmarks.
Open → 2609.30178v1

Agent skill testing reveals limits of plugin migration advice

Evaluating Agent Skills for Version-Specific Plugin Migration: A Retrospective Study

Abstract: Agent skills package version-specific maintenance knowledge for coding agents, but a higher diagnostic score does not by itself show that the resulting migration advice satisfies the target version's contract. We study a shipped plugin-upgrade skill through an archive of 64 reports on 16 static migration tasks, with two attempts per condition and 328 criterion decisions. With the skill, mean recorded reward rises from 93.83 to 98.75, a gain of 4.92 points (95% task-bootstrap interval [0.31, 10.86]); the gain is concentrated in one task, and eight task pairs are at the ceiling. Tracing every decision to its contract domain and reviewing ten reports in depth exposes grading errors that favor either arm; in one, a containment predicate that accepts the parent directory still receives full credit. Executable probes confirm this defect and show that a working teardown repair is excluded only by a narrower lifecycle rubric. Replacing the reviewed decisions keeps the estimate positive (4.61 to 5.39 points) but moves its interval to or across zero. Re-grading all 64 reports with judges from two other model families, without arm labels or prior scores, agrees with the original judge on 91.8% and 95.7% of decisions (weighted $κ=0.64$ and $0.72$) and gives gains of 10.63 and 6.09 points. The study contributes a traceable evaluation that connects aggregate reward to contract-level evidence and judge sensitivity, together with concrete review checks for migration advice. Executable end-to-end repairs, independent human annotation, and other frameworks are left to future work.

Thu 24 SeptSoftware Engineering
The gist
Keeping software plugins up to date is tricky because new versions have different rules. The authors studied how an AI helper performs advice on moving plugins to new versions by examining many test cases and detailed reports. They found the AI improved scores somewhat but had errors that gave too much credit in some cases, and other reviewers saw similar patterns. The work links overall performance scores to detailed checks, helping future improvements but leaving actual automatic fixes and new testing methods for later.
Open → 2609.30120v1

Specification-driven approach improves program repair benchmarking control

Specification-Driven Benchmarking for Automated Program Repair From Static Corpora to Executable Specifications

Abstract: Automated Program Repair (APR) benchmarks have traditionally been constructed as static datasets whose characteristics are inherited from the defects they contain. While this paradigm has enabled decades of progress, finite corpora provide limited experimental control, become increasingly susceptible to contamination as they are reused, and cannot be systematically regenerated or adapted as evaluation requirements evolve. We propose specification-driven benchmarking, a paradigm in which benchmarks are defined by executable specifications and realized through benchmark generation. The specification explicitly declares the intended properties of the benchmark (including program context, fault taxonomy, difficulty, validation strategy, and corpus constraints) while a generation pipeline realizes those requirements through independent generation, validation, and corpus management components. We develop the conceptual foundations of this approach by introducing a taxonomy of benchmark specification dimensions, establishing how each specification dimension maps to deterministic architectural responsibilities, and arguing that independent validation is a structural requirement for trustworthy benchmark generation. An end-to-end example illustrates how specification choices propagate through the pipeline to produce benchmark instances whose properties are independently verifiable. By treating the benchmark as an executable specification rather than a static dataset, the proposed paradigm shifts benchmark construction from artifact curation to declarative experimental design.

Thu 24 SeptSoftware Engineering
The gist
Benchmarks for testing automated program repair tools have usually been fixed collections of real defects, which limits how much you can control experiments and reuse benchmarks safely. The authors propose making benchmarks from detailed, executable specifications that describe exactly what kinds of bugs, difficulty, and validation methods should be included. This lets benchmarks be generated on demand, verified independently, and adapted to new testing needs instead of relying on old, unchanging datasets. Their approach turns benchmark creation into a clear, repeatable design process rather than just curating examples.
Open → 2609.28896v1

Large language models struggle to predict program execution behavior

Can LLMs Reason About Runtime Behavior? A Repository-Level Dynamic Benchmark

Abstract: Large language models (LLMs) are increasingly used in coding tasks, but their ability to reason about code execution remains unclear. Existing repository-level QA benchmarks mainly evaluate static code understanding and often rely on LLM-based evaluation, while execution-reasoning benchmarks are mostly limited to snippets or functions. We introduce SWE-Flux, a repository-level benchmark for dynamic execution reasoning containing 480 execution-grounded instances across 12 real Python repositories, with gold answers automatically harvested from instrumented test executions rather than written manually or judged by LLMs. The benchmark covers singletest and multi-test questions over control flow, loops, program state, dataflow, exceptions, and program invariants. Evaluating five LLMs shows that this task remains challenging. The best model achieves only 37% accuracy. Models perform better on localized behavior such as invariants, intra-procedural control flow, exceptions, and simple loops, but struggle with dataflow, inter-procedural execution, precise state reasoning, and suite-level aggregation. Finally, we show that the oracle-harvesting pipeline can generate fresh benchmark variants using input perturbation. It successfully harvests valid variants for almost 90% of the selected instances, and the resulting variants are substantially more challenging for the evaluated models.

Wed 23 SeptSoftware EngineeringArtificial IntelligenceComputation and Language
The gist
Figuring out how computer programs actually run is hard for AI models. The authors created a new test to see if language models can understand what code does when it runs, not just what it looks like. This test uses real Python projects and automated checks from running tests, making it more accurate. Even the best models got less than 40% right, especially struggling with complex parts like how data moves through a whole program. The test can also make harder new problems automatically to better challenge these models.
Open → 2609.28449v1

Neuroevolution improves game test agents using scenario models

Scenario-Driven Neuroevolution: Using Models to Guide Test Generation for Games

Abstract: Automatically generating test inputs for games is challenging, as test generators must master the game to reach advanced program states while also ensuring robustness against the heavy program randomisation inherent to games. The test generator Neatest therefore optimises test suites consisting of neural networks that reach advanced program states and are robust to program randomisation, as they generate test inputs dynamically based on the current program state. Neatest is a white-box testing approach that aims to generate a network agent for each yet-uncovered statement or branch of the code using neuroevolution. Due to this iterative test generation approach, the algorithm does not scale well to larger programs that may contain thousands of branches. Furthermore, covering every statement or branch in a game often does not correspond to playing the game as intended. To alleviate these shortcomings, we propose combining Neatest with a model-based testing approach that allows game testers to define test scenarios via abstract game models. The test generator then no longer optimises networks to reach all branches or statements of a program, but instead trains networks to replicate the concrete desired testing behaviour expressed by the abstract game model. An evaluation on 13 Scratch games across varying genres demonstrates that Neatest, combined with model-based testing, is able to optimise agents that replicate the desired gameplay behaviour defined in the game models while increasing achieved branch coverage by 7% compared to the traditional code-guided Neatest approach.

Wed 23 SeptSoftware EngineeringNeural and Evolutionary Computing
The gist
Testing video games automatically is hard because the tests need to understand the game well and handle random changes. The authors improved an existing method, Neatest, by letting testers create simple models that describe how the game should be played. Instead of trying to cover every part of the game’s code, the new approach trains test agents to follow these desired behaviors. This method helped create better test agents for 13 different games and also covered more of the code than before.
Open → 2609.28130v1

WhatWorkedBench tests AI agents on understanding experiment effects

WhatWorkedBench: Benchmarking Experimental Understanding in AI Agents

Abstract: AI research agents need reliable knowledge of how their experiments change outcomes. We introduce WhatWorkedBench to measure experimental understanding, the accuracy of predictions about component changes after budgeted experimentation. Agents inspect code, select measurements, and submit a response surface, a table predicting scores for every configuration of component settings. Exhaustive CPU execution supplies reference effects for changing each component while holding the others fixed. These effects capture combinations of changes across 36 tasks from 30 data sources and 8 workflow types, with 1248 configuration records. Core evaluation combines 4,206 numerical-control records across all eight families and 108 agent episodes across the original six. At eight new measurements, pair-effect ridge selects an optimum on 15 of 22 sources and limits every effect error to 10% of score range on three. Fitting a Gaussian process (GP) to the same agent observations raises effect recovery, accuracy relative to true effect magnitude, from 0.632 to 0.698 in the original Flash cohort and from 0.621 to 0.720 in an additional cohort. On six completed beat-detection and graph submissions, the same-observation GP raises family-macro recovery from 0.303 to 0.455. On six workflows with six binary options at 20 new measurements, encoding code equivalences, configurations with identical behavior, raises GP recovery from 0.248 to 0.462. WhatWorkedBench supports research on experimental agents, adaptive experimental design, numerical inference, and use of program structure.

Wed 23 SeptArtificial IntelligenceMachine Learning
The gist
AI agents need to understand how changing parts of their experiments affect the results. The authors created WhatWorkedBench, a tool that checks if AI agents can accurately predict outcomes after testing different settings. By running many tasks and comparing agent predictions with real results, they found ways to improve these predictions using advanced statistical models. This helps build smarter AI systems that learn better from experiments.
Open → 2609.27490v1

Compile rate is unreliable metric for fixing code vulnerabilities

Metrics Failure in LLM-Based Code Vulnerability Repair: An Empirical Study and a Change-Aware Screen

Abstract: Large language models (LLMs) are increasingly applied to the automated repair of C/C++ security vulnerabilities, and compile rate is a commonly reported proxy for progress: whether the generated patch compiles. We argue that compile rate is a scientifically unreliable metric for single-function vulnerability repair, and we support this with five controlled experiments over 203 vulnerable functions from Big-Vul, three open-source code LLMs (350M to 6.7B parameters), and three prompting strategies. Compile rate (i) barely responds to an intervention that substantially improves the generated code; (ii) is dominated by evaluation-harness and dataset artifacts rather than model quality, with about 64% of compile failures not attributable to the model, a share that is nearly invariant across models; (iii) shifts by 1.8 to 2.7 times on identical patches under a single compiler-standard flag, with zero regressions; (iv) ranks the three models in the opposite order to reference-similarity metrics; and (v) rewards non-repairs when used as an optimization target, since a compiler-feedback loop raises compile rate while similarity to the human fix falls, with manual inspection finding deletion- and placeholder-style non-repairs among the newly compiling outputs. The natural fallback, whole-function CodeBLEU, also fails: an unchanged copy of the vulnerable input outscores every model. We also examine diff_F1, a change-aware screen that scores only the edited region. It gives exactly zero credit to a no-op and near-zero credit to some, though not all, of the deletion-based gaming patches we observed, while still crediting genuine partial edits, so it may serve as a cheap screen before deeper, execution-based analysis. It is not a repair-quality metric, and we report where it falls short. Our findings argue for change-aware, execution-grounded evaluation of LLM-based vulnerability repair.

Tue 22 SeptSoftware EngineeringArtificial IntelligenceCryptography and Security
The gist
Fixing security problems in C or C++ code using AI models usually checks if the fixed code can compile as a way to tell if the fix works. The authors show that this way of measuring is often misleading because many compile errors come from things outside the AI model’s control and sometimes the 'fixes' aren’t real fixes at all. They suggest using a method that looks only at the actual changes made to the code called diff_F1, which better avoids false credit for no improvement. However, they say even this isn’t perfect and deeper checks that run the code are needed for trustworthy validation.
Open → 2609.26749v1

Symbolic finite state machines tested and learned using finite input sets

Testing and Learning Symbolic Finite State Machines

Abstract: Symbolic finite state machines (SFSMs) describe input/output behaviour using guards and output assignments with possibly infinite data domains. We study deterministic and completely specified SFSMs whose guards and output assignments depend only on the current input. We define finite representative input sets that contain witnesses for relevant guard overlaps and separating witnesses for output assignments that differ on those overlaps. Our main theorem shows that language equivalence of the finite instantiations implies language equivalence over the full input domain. This result transfers complete testing methods for deterministic finite state machines (DFSMs) to SFSMs, provided finite sets of admissible guards and output assignments and an upper bound on the number of distinguishable reachable states are known. Under these assumptions, a DFSM learner with complete testing can learn a finite instantiation, which is then lifted to an equivalent SFSM. We establish a bound on the size of representative input sets and give an SMT construction whose correctness and termination hold under stated solver assumptions.

Tue 22 SeptFormal Languages and Automata TheorySoftware Engineering
The gist
Testing and learning systems that handle inputs with infinite possibilities is tricky. This work focuses on symbolic finite state machines (SFSMs), which are models using symbolic conditions and outputs rather than fixed values. The authors show that by carefully choosing a finite set of representative inputs, one can test and learn SFSMs as effectively as traditional finite state machines. This approach helps build and verify these machines without needing to explore every possible input individually.
Open → 2609.25603v1

Shaker shows no advantage over rerunning flaky tests in python projects

Evaluating Shaker for Flaky Test Detection in Python Projects

Abstract: Flaky tests pass or fail non-deterministically on unchanged code, eroding trust in test suites and inflating the cost of every failure. Shaker detects them by injecting resource contention (CPU, memory, and I/O stress) to amplify non-determinism caused by concurrent execution, and was reported to detect 95% of the flaky tests in a Java and Android benchmark against 37.5% for plain re-execution (ReRun). We present the first empirical evaluation of Shaker for Python. Drawing non-order-dependent flaky tests from the ground-truth dataset of Gruber et al., we compare Shaker against a budget-matched ReRun baseline in a paired design, giving both techniques the same number of test executions: Each of 137 tests is run 100 times under each. As configured for Java and Android, Shaker provides no statistically significant detection advantage over plain re-execution (37.2% vs. 35.8%; McNemar exact p = 0.84). Two findings explain why. First, fewer than half of the ground-truth flaky tests reproduce as flaky at all on independent hardware under either technique, and most of the tests that fail to reproduce never diverge once across 100 runs. Second, the tests that do reproduce are dominated by flakiness from network interactions and randomness rather than the concurrency Shaker targets. Beyond the tool, this exposes a broader hazard for the field: reusing a flaky-test ground truth across execution environments silently converts genuine flaky tests into apparent true negatives, deflating any tool's measured recall.

Tue 22 SeptSoftware Engineering
The gist
Flaky tests sometimes pass and sometimes fail even when nothing changes, which causes confusion and extra work for developers. The authors looked at a tool called Shaker, which was good at finding flaky tests in Java but did not work better than simply running tests multiple times in Python projects. They found that many flaky tests don’t show flaky behavior consistently on different computers, and when they do, it’s mostly due to networking or randomness, not the concurrency problems Shaker tries to detect. This means tools evaluated on flaky tests from other setups might seem less effective than they really are.
Open → 2609.25528v1

Trajectory embeddings improve software testing efficiency by 90 percent

Trajectory-Aware Benchmark Subset Selection for Cost-Efficient Software Engineering Agent Regression Testing

Abstract: Autonomous software engineering agents (SWE-agents) automate coding tasks. Each agent update may require re-running the full benchmark to detect regressions and improvements, at a cost of hundreds of millions of LLM tokens per run, which makes evaluation a bottleneck. One solution is to evaluate only a subset of benchmark instances. Yet, simple approaches, such as random sampling or stratified random sampling based on past pass/fail outcomes, risk producing high variance and unrepresentative subsets. We turn to agent trajectories, the step-by-step record of the actions an agent took. We propose a trajectory-aware subset selection approach that replaces random sampling with deterministic selection based on trajectory embeddings. We first group test set instances by their test outcome in a recent full test run to preserve the historical pass/fail rate, then select the subset using the trajectory's embedding space. We evaluate 76 subset selection configurations, including random sampling, embedding-based selection, clustering-based selection, and hybrid shortlist-then-subsample strategies, across three regression scenarios: same-configuration reruns, model and configuration changes, and agent framework changes. Our best trajectory-aware method is the one selecting benchmark instances closest to the centroid of each outcome group in the embedding space. It achieves the lowest estimation error among all methods we evaluate. For instance, when evaluating a given agent version on a selected subset of 5% or 10% of the test instances, our approach reduces the average estimation error by 3--11% and the worst-case error by 4--11% relative to the typical draw and 38--46% relative to the 95th-percentile draw of the strongest baseline. Our results show that a 10% trajectory-aware subset keeps the median estimation error below 5% while cutting token cost by roughly 90%.

Mon 21 SeptSoftware Engineering
The gist
Testing software agents that write code can be very expensive because it requires checking many examples each time the agent improves. The authors show that instead of testing randomly, using a method that looks at the detailed steps agents took in previous tests helps pick smaller but more representative test sets. This new method reduces the testing cost by about 90% while keeping the error in test results very low. This approach helps developers make sure software improvements really work without spending too much time or resources.
Open → 2609.24928v1

Graph method improves confidence estimates for reasoning and acting agents

GRUET: Quantifying Uncertainty of Agentic Reasoning-and-Acting Processes

Abstract: Agents have attracted considerably increasing attention due to the power of executing both Reasoning and Acting (ReAct) in open and dynamic environments. The ReAct process typically exhibits a multi-turn trajectory in which one drives Large Language Models (LLMs) to generate both reasoning chains and task-specific actions in an interleaved manner. However, agents often suffer from significant uncertainty, where identical tasks yield divergent trajectories; trajectories with higher uncertainty often produce incomprehensible behaviors, severely undermining agent credibility. This work conjectures that such trajectory-level uncertainty frequently stems from cumulative turn-level reasoning uncertainty induced by LLMs; the latter often exhibits a collection of branches of divergent reasoning chains and their resulting actions. Built upon this, we present the Graph-based Reasoning UncErtainty in Trajectories (GRUET) method for the uncertainty quantification of ReAct, comprising turn-level reasoning uncertainty quantification and trajectory-level uncertainty aggregation; the former precisely quantifies reasoning uncertainty via modeling the reasoning space spanned by potential reasoning branches as a graph and then approximating the reasoning space complexity with graph complexity, while the latter employs simple aggregation strategies for quantifying the overall trajectory credibility. Empirical evaluations across nine LLMs and five benchmarks validate the effectiveness of our proposed GRUET in terms of selective generation performance, measured by AUROC, AUPRC, and AUARC.

Mon 21 SeptArtificial Intelligence
The gist
Agents that use large language models to think and act in steps often show uncertain behavior, making their actions hard to trust. The authors found that this uncertainty often comes from unclear reasoning at each step, which builds up. They created a new method called GRUET that uses graphs to measure how complex the reasoning options are at each step and combines this to estimate overall confidence in the agent’s actions. Tests across many language models and tasks showed that GRUET can effectively predict when an agent’s behavior might be unreliable.
Open → 2609.24831v1

ChatGPT enhancements in automated program repair vary widely by benchmark

Towards the Generalizability of Leveraging ChatGPT in APR via Self-enhancing: An Empirical Study

Abstract: Automated Program Repair (APR) increasingly relies on Large Language Models (LLMs). ChatGPT-enhanced APR uses techniques such as self-correction and autonomous agents to improve repair without modifying model parameters. Although these approaches report strong results on Defects4J and SWE-bench, the stability of enhancement gains across benchmarks remains under-explored. We evaluate three ChatGPT-enhanced APR methods on three representative, long-standing benchmarks. With GPT-3.5-Turbo, SRepair achieves a larger absolute gain on HumanEval-Java than on Defects4J, while SRepair and FixAgent without extrinsic information yield negative gains on BugsInPy. With GPT-5.4-mini, the evaluated methods achieve larger absolute gains on Defects4J than on HumanEval-Java, while gains on BugsInPy are non-negative but limited. We investigate benchmark-related factors through code transformations and benchmark-specific fine-tuning. Code transformations reduce enhancement gains on Defects4J, while benchmark-specific fine-tuning increases gains on BugsInPy. Directly supplying GPT-3.5-Turbo with error messages and triggering tests yields more correct repairs than the evaluated ChatGPT-enhanced APR methods on BugsInPy. These findings highlight the need to evaluate generalizability across benchmarks and models using multiple metrics, and suggest that directly providing repair-specific extrinsic information may be more effective than enhancement methods when their gains are limited.

Sat 19 SeptSoftware Engineering
The gist
Fixing computer programs automatically using AI like ChatGPT works differently depending on the specific test set used. The researchers found that some advanced techniques that improve repairs on certain benchmarks did not work well on others. They showed that giving the AI extra information about the errors directly was often more effective than using complex self-improving methods. This means tools based on AI should be tested on many different types of program bugs to know when they really help.
Open → 2609.22844v1

Large language models assist industrial test failure root cause analysis

Supporting Industrial Test-Failure Analysis with LLM-Based Systems: An Experience Report

Abstract: This study examines tool-augmented Large Language Model (LLM) systems for supporting Root Cause Analysis (RCA) of nightly test failures at Westermo Network Technologies AB. Nightly test executions produce heterogeneous test data and logs that practitioners currently inspect manually across multiple sources. We implemented an RCA workflow in single-agent and orchestrated multi-agent configurations, both with access to test metadata and logs. An exploratory industrial case study used two real failure scenarios. Six practitioners evaluated the scenario reports through a survey and focus group, and operational measurements were collected from 120 repeated executions. The evaluation covered practitioner-perceived correctness, reasoning quality, fix realism, clarity, usefulness, and trust, as well as cost, duration, and consistency. Neither configuration showed a consistent practitioner-perceived quality advantage across the two scenarios. The single agent system generated reports faster and at lower cost, making it the more practical baseline in this context. The potential benefits of agent architectures require further evaluation in more complex scenarios.

Fri 18 SeptSoftware Engineering
The gist
Companies run lots of automatic tests each night to find problems in their software, but figuring out why tests fail can be slow and hard because the information is scattered in different files. The authors tried using smart AI helpers, called Large Language Models, to automatically analyze these test failures by reading test details and logs. They tested two setups: one where a single AI agent worked alone, and another where multiple AI agents worked together. Both helped, but the simpler single-agent system was faster, cheaper, and just as good at explaining test failures in the cases they studied.
Open → 2609.21843v1

LogicTrack audits reasoning steps of language models with logic solvers

LogicTrack: Auditing Reasoning Trajectories of Large Language Models with Formal Logic Solvers

Abstract: Chain-of-Thought (CoT) reasoning has been shown to improve the performance of large language models (LLMs), yet existing optimization methods largely rely on outcome-based feedback, leaving the logical validity of intermediate reasoning steps largely unverified. To address the gap whereby LLMs arrive at correct final answers through logically flawed intermediate reasoning chains, we propose LogicTrack, a neuro-symbolic framework that audits reasoning trajectories by auto-formalizing each reasoning step into symbolic representations and verifying it with automated theorem provers. LogicTrack introduces Solver-Based Backtracking Reward (SBR), a step-wise scoring mechanism that quantifies logical soundness and guides backtracking tree search at inference time. We further extend LogicTrack to construct supervised fine-tuning (SFT) data with backtracking traces from its trajectories, enabling fine-tuned models to internalize step-wise auditing as an intrinsic capability. Extensive experiments across 8 reasoning benchmarks and 7 LLMs demonstrate that LogicTrack effectively improves both the verifiability of reasoning chains and final answer pass rate, thereby enhancing overall CoT quality and trustworthiness in high-stakes domains.

Fri 18 SeptArtificial IntelligenceLogic in Computer ScienceSymbolic Computation
The gist
Large language models can explain their answers step-by-step, but those steps might have mistakes even if the final answer is right. The paper introduces LogicTrack, a tool that checks each reasoning step by turning it into formal logic and verifying it automatically. It also helps fix mistakes during reasoning by backtracking when errors are found. This method improves the trustworthiness of language model answers, especially in important areas where errors matter.
Open → 2609.21492v1

Benchmark measures software accuracy in automated game creation tasks

GameASG-Bench: Benchmarking Autonomous Software Generation for Game Development

Abstract: Autonomous software generation (ASG) aims to turn human requirements into executable applications, but delivering these applications does not necessarily establish that their interacting components satisfy the specified behavioral requirements. We introduce GameASG-Bench, a benchmark that makes behavioral testability part of the generation task for game development. Our design declares an evaluation interface specification before generation, fixing legal starting scenarios, player-level actions, stable snapshots, rejection behavior, and invariants while leaving private implementations open. Concretely, we include: (i) static L1 checks that assess source-level compliance; and (ii) browser-executed L2 checks that combine semantic observations with real input and runtime evidence. We implement this protocol as 47 browser-native game-generation tasks spanning 12 primary genres and both 2D and 3D interaction, each with executable checks and an independently verified reference implementation. Our experiments answer four key questions about end-to-end agent performance, tool access and nominal turn budget, reasoning effort, and harness choice. Across nine agent stacks, the highest observed mean L2 check pass rate is 93.2%, yet the highest observed strict task success rate, requiring all L1 and applicable L2 prerequisite and core requirement checks, is only 55.3% (26/47 tasks). For DeepSeek-V4-Flash, full tool access and larger nominal turn budgets yield more strict task successes, while the strict task success rate is not monotonic in reasoning effort. Both tested harnesses achieve 18 strict task successes, but only ten tasks succeed under both. These results expose task-level compliance gaps that high average check pass rates actually obscure.

Fri 18 SeptArtificial IntelligenceSoftware Engineering
The gist
Software that writes computer games automatically struggles to fully meet all the detailed behavior rules expected in games. The authors created a benchmark called GameASG-Bench to test how well such software meets those rules during development. They tested 47 different game-making tasks with various types of games and found that while most individual checks pass often, full task success that meets every rule is much lower. Their findings show that average scores can hide important gaps in software quality.
Open → 2609.21293v1

Estimating how often your software encounters failures in practice

How Often Does Your Program Fail?

Abstract: Software in production encounters inputs shaped by how it is used in practice. We study distribution-aware reliability estimation: given a program, its operational input distribution, and a condition of interest, determine how often that condition holds and certify the result with a guaranteed error bound. Symbolic and statistical methods offer two ways to answer this question. Symbolic methods reason about entire regions of the input space and can certify rates exactly, but often struggle with complex arithmetic or loops. Statistical methods instead sample inputs and apply concentration bounds. They are broadly applicable, but can require many samples when failures are rare. We bring these approaches together in a framework that includes both as special cases. Each estimator has three components: a mass estimator, a per-leaf confidence bound, and a symbolic closure rule. We prove that any instantiation satisfying three invariants returns an interval containing the true rate with confidence 1-delta, regardless of when it stops. The certified error has two parts: a statistical term, reduced by sampling, and a structural term, reduced by symbolic closure. Pure sampling and pure symbolic execution each reduce only one of these terms. Alternative choices of the components also allow the framework to support rare-event variance-reduction methods.

Thu 17 SeptProgramming Languages
The gist
When software runs, it gets all kinds of inputs that depend on how people use it. This paper studies how often a certain condition, like a failure, happens given those real inputs. The authors combine two methods: one that looks mathematically at all inputs and another that tests lots of sampled inputs. This mix lets them provide a guaranteed range where the real failure rate lies, using fewer tests than before and handling complex programs better.
Open → 2609.20037v1

Gui grounding improves accuracy and speed with smart crop ranking

RankGround: Efficient High-Resolution GUI Grounding via Lightweight Reranker-Guided Crop Selection

Abstract: Graphical User Interface (GUI) grounding is a fundamental perception task for multimodal agents, enabling them to interpret natural language instructions and interact with digital interfaces. Existing methods face a fundamental trade-off between accuracy and efficiency: direct full-image inference often fails to capture small or visually similar UI elements, while multi-crop strategies improve localization at the cost of multiple expensive Vision-Language Model (VLM) calls per query. To address this challenge, we propose RankGround, a two-stage framework that achieves accurate GUI grounding with a single VLM call per query. Central to our approach is GroundRanker, a lightweight multimodal reranker that identifies the most promising crop from a dense candidate set. Because no off-the-shelf ranking dataset is available, we construct ranking supervision data from existing grounding datasets. A strict containment criterion and boundary-aware positive augmentation improve alignment and spatial coverage in cluttered layouts. GroundRanker is then trained with a two-stage curriculum: a pointwise objective first learns coarse containment, and a listwise objective refines subtle semantic and spatial distinctions among visually similar crops. Experimental results show that RankGround consistently outperforms strong baselines while reducing computational cost. It achieves 1.4 times faster inference and improves localization accuracy by 5.5% on average over the second-best method across all backbones and screen scales, establishing a new state of the art in both efficiency and precision for GUI grounding.

Wed 16 SeptComputer Vision and Pattern RecognitionComputation and LanguageHuman-Computer Interaction
The gist
Understanding and interacting with graphical user interfaces (GUIs) from natural language instructions is tricky because important small or similar-looking elements are hard to spot. The authors develop a two-step method called RankGround that first picks the best area of a screenshot to focus on using a lightweight reranker, then uses an expensive model just once to find the UI element. They train this reranker carefully to tell subtle differences between similar elements. This approach makes finding the right UI parts faster and more accurate than previous methods.
Open → 2609.18690v1

Cost-efficient large language models struggle to produce correct enterprise code

An Empirical Evaluation of Cost-Efficient Large Language Models on Algorithmic Programming Tasks

Abstract: This study empirically evaluates whether cost-efficient Large Language Models (LLMs) can be trusted to generate enterprise code to a written specification. Three models (Gemini Flash 3, GPT-5.4 mini and Claude Haiku 4.5) were asked to solve 992 algorithmic problems as Java Spring Boot service methods conforming to a mandated signature and data-transfer-object specification, crossing four model and agentic coding tool combinations with two prompt variants to yield eight configurations, with iteration forbidden and hardcoded answers explicitly prohibited. Eight problem statements were withheld to probe how models respond to missing input. The 7,593 resulting methods were classified by an eight-class outcome taxonomy describing what each does about producing an answer, then deployed and executed, giving 7,936 measured requests joined to that classification. Structural conformance approached ceiling, yet 38.4% of methods do not compute the value they returned and only 12.9% of returned answers were correct. Conditioning on outcome class shows that response reliability and correctness are inversely related, whereas genuinely computing methods answered least often and were correct 19.3%. Limitations include single generation runs per configuration, partial harness coverage, single-pass timing, syntactic classification, and probable corpus contamination.

Wed 16 SeptSoftware EngineeringArtificial Intelligence
The gist
This paper tests three affordable large language models to see if they can write accurate software code from instructions. The authors gave the models almost 1,000 programming tasks in Java and checked the results carefully. While most code looked like it fit the rules, many did not actually work properly or gave wrong answers. The study shows these models often guess answers rather than truly compute them, and correct solutions were quite rare. The authors also note some limits to their testing approach.
Open → 2609.18052v1

Benchmark evaluates safety and refusal in long tool-using AI agents

BLINDSPOT: A Benchmark for Safety and Refusal Calibration in Long-Horizon Tool-Using Agents

Abstract: Large language model (LLM) agents increasingly operate over long-horizon interactions involving tool use, persistent state, evolving authorization, and external environment feedback. In such settings, safety failures may emerge only after multiple turns, yet existing evaluations often reduce agent behavior to task or attack success, obscuring whether an agent acts, refuses, or remains appropriately calibrated as the interaction evolves. We introduce Blindspot, a benchmark for trajectory-level safety calibration of long-horizon tool-using agents. Blindspot evaluates complete user-agent-environment trajectories through adaptive adversarial interaction, stateful tool execution, and execution-grounded adjudication. Its current instantiation contains 22 attack families and 35 scenarios across seven domains, yielding more than 2,500 long-horizon trajectories with an average interaction length of 14.7 turns. Each trajectory is assigned one of five outcomes: Safe Completion, Correct Refusal, Unsafe Completion, Over-Refusal, or Indeterminate. Unlike fixed attack datasets, Blindspot is an extensible live-simulation framework in which attacks, scenarios, tools, policies, domains, and agent configurations can be added without redesigning the evaluation pipeline. We evaluate 13 proprietary and open-weight LLMs using eight metrics covering unsafe completion, appropriate refusal, benign utility, over-refusal, repeated-run robustness, and post-refusal failure. Preliminary results reveal substantial differences in safety-utility calibration across models and show that failures can emerge only after several initially safe interaction steps. These findings motivate treating agent safety as a trajectory-level property rather than a single-turn or binary success criterion.

Mon 14 SeptArtificial IntelligenceComputational Engineering, Finance, and ScienceComputation and Language
The gist
Some AI agents use tools and have long conversations or tasks, which can lead to safety problems that only appear after many steps. The authors created Blindspot, a new way to test how well these AI agents act safely, refuse unsafe requests, or go too far refusing over time. Blindspot uses many different tricky scenarios and tools, measuring outcomes beyond just success or failure. They tested several AI models and found big differences in how safely and usefully these agents work over time. This shows it’s important to watch AI safety as a whole ongoing interaction, not just a single moment.
Open → 2609.16305v1

Interactive benchmark measures quality of AI-generated web apps

IWC-Bench: Evaluating Web Application Generation from a Software Testing Perspective

Abstract: Human evaluation provides a direct measure of the quality of LLM-generated web applications. However, fitting human judgments through automated evaluation remains challenging. Static benchmarks can credit functionality that exists in source code but is unreachable at runtime. Interactive benchmarks exercise the application, yet incomplete exploration can cause them to miss implemented functionality and confound application defects with agent execution failures. To address these limitations, we propose IWC-Bench, an interactive benchmark for evaluating web application generation from a software testing perspective. IWC-Bench instruments each generated application and uses code coverage to guide an agent in exploring its functionality through user-simulated interactions. It then abstracts the interaction trace into a state-transition graph and evaluates the application along three dimensions: visual aesthetics, usability, and requirement alignment. By separating exploration from scoring, IWC-Bench collects runtime evidence without constraining exploration to predefined acceptance criteria. IWC-Bench comprises 369 real-world user requirements and 5,088 acceptance criteria. Evaluation of 16 frontier LLMs reveals distinct strengths across the three dimensions, with no model leading on every dimension. On 197 validated sessions sampled from an internal arena, IWC-Bench achieves 85.3\% agreement with human preferences, with agreement generally increasing as the score difference between paired applications grows. Further experiments show that coverage guidance improves exploration coverage and the model rankings remain stable when the judge model is replaced.

Mon 14 SeptSoftware EngineeringArtificial Intelligence
The gist
Testing how well AI can build web applications is hard because simple checks may miss problems or unused features. The authors created IWC-Bench, a tool that tests AI-generated web apps by simulating real user actions to explore all features and then scores the app based on look, ease of use, and how well it meets requirements. This approach avoids missing hidden bugs or features and better matches what humans think about app quality. Their tests show IWC-Bench agrees well with human judgments and works consistently across different AI models.
Open → 2609.15387v1

Model learns from reliable negatives to improve GUI coordinate mapping

Learning from Reliable Negatives: Confidence-Anchored Test-Time Adaptation for GUI Grounding

Abstract: Graphical User Interface (GUI) grounding is essential for autonomous agents to map natural language instructions to precise screen coordinates. However, existing supervised fine-tuning and reinforcement learning methods are constrained by the high cost of annotation, creating a scalability bottleneck. In this paper, we introduce a label-free test-time training paradigm driven by two key insights: (1) confidence patterns in coordinate tokens are a better indicator than full-sequence confidence, and (2) in sparse GUI coordinate spaces, negative samples offer more reliable learning signals than potentially noisy positive ones. We first propose Confidence-Anchored Learning (CAL), which utilizes coordinate-token confidence to filter pseudo-labels and assign distance-based binary rewards. Building on this, we develop Confidence-Anchored Negative Learning (CANL), which exclusively optimizes the model using negative samples to bypass the risks of incorrect positive samples. Experimental results demonstrate that CANL-7B achieves 92.1% on ScreenSpot-V2. On more challenging ScreenSpot-Pro, CANL-7B reaches 33.8%, an 8.9% absolute improvement over the base model. Our findings establish coordinate-token confidence as a powerful alternative to manual annotations for scalable GUI agent development.

Mon 14 SeptComputer Vision and Pattern Recognition
The gist
Mapping natural language instructions to exact screen points is tough because manual labeling is costly. The authors found that focusing on how confident a model is about parts of the answer helps more than looking at the whole answer. By training only on examples where the model is confident something is wrong (negative samples), they avoid learning from bad guesses. This approach improves the accuracy of tools that help computers understand and interact with user interfaces without needing extra human labels.
Open → 2609.15307v1

Large language models improve testing for natural language code libraries

Enhancing Automated Unit Test Generation for NLP Libraries Using Large Language Models

Abstract: Automated unit test generation tools like EvoSuite perform well on general-purpose software but often struggle with domain-specific software such as Natural Language Processing (NLP) libraries, where inputs must follow semantic, syntactic, and structural constraints. Large Language Models (LLMs) can generate domain-relevant test code, but tests produced by LLMs alone often fail to compile or achieve sufficient coverage. We propose LLMSuite, a hybrid test generation framework that integrates self-refinement prompting with class-level LLM reasoning into the search-based testing process. In this mechanism, the LLM iteratively improves its test snippets based on feedback from previous generations. This enables the model to produce increasingly precise, domain-consistent code fragments that steer the evolutionary search toward exercising complex and otherwise hard-to-reach behaviors. When no objective improves over multiple generations in the underlying evolutionary algorithm, these refined snippets are parsed and injected into EvoSuite's population to expand the search space. To support our evaluation, we constructed a new dataset comprising 100 classes drawn from five widely used Java NLP projects. We also re-implemented CodaMOSA, a recent hybrid SBST-LLM technique, in Java to enable a direct comparison. Across this dataset, LLMSuite improves branch and line coverage by approximately 10% and 8%, respectively, and achieves an 11% higher mutation score than CodaMOSA-J. Compared to EvoSuite, LLMSuite yields roughly 15% higher branch and line coverage and 5% higher mutation score. Against an LLM-only baseline, it improves structural coverage by 36% and mutation score by about 24.7 percentage points. Finally, LLMSuite complements manually written test suites by exercising domain-specific behaviors that are often left untested.

Sun 13 SeptSoftware Engineering
The gist
Automatically creating tests for software that works with language is hard because inputs must make sense and follow special rules. The authors combined large AI language models with existing search methods to make testing better and more accurate. Their new system, called LLMSuite, helps find tricky bugs in natural language processing libraries by improving test code over multiple tries. LLMSuite made tests that covered more of the code and caught more issues than previous methods, including tests done only by AI or traditional tools. It also tested parts of the software that human-written tests often miss.
Open → 2609.14784v1

Machine referee changes code agent work by raising verification cost

SaltBench: A Referee-Gated Protocol for Measuring Method Effects in Machine-Checked Software Work

Abstract: SaltBench is a benchmark protocol for one question: How does a machine referee change the way a coding agent works? A machine referee --- a proof kernel, a program verifier, or a withheld test suite --- decides what an agent's work is worth, and the agent cannot argue with it. Here we report a protocol that makes the referee's effect measurable and whose answers cannot be narrated afterwards: every outcome is decided outside the agent's own toolchain; the agent is walled off from the network, the reference solutions and the harness itself, and the wall is tested by probes that try to breach it before any scored run, so the isolation is observed rather than assumed; every run is authorized by a dated freeze with its predictions registered; and a budget stop is a halt, never a failure. In this study, the subject of the benchmark is a ``seat'', meaning an agent session in its standard harness. We tested five systems components, all authored in Rust under a pinned Verus toolchain, with a withheld test suite as the referee for each. Four arms are tested: a plain agent; an agent that is also instructed to create a specification and verify the code against it, in a reduced rendering of the method, as registered; and two arms where the specification is provided a priori, extended under a dated amendment to $k=4$, where the registered sign test reached no verdict (3 of 4, $p = 0.3125$, every premium below the resolvable floor). We found that the arm instructed to specify and verify cost more on all five components, and by a practical margin: across these five components no premium exceeded $2.8879\times$ under either reading of the declared set, and the three cheapest sat below $1.4\times$. That bound is a property of this population and not a promise about larger ones: the premium runs near $1$ on the smallest components and rises with size. We publish the complete record.

Thu 10 SeptSoftware EngineeringLogic in Computer Science
The gist
This paper studies how having a machine judge, or referee, influences the way a computer program writes code. The referee can be a proof checker or a test set that decides if the program's work is correct, with no argument possible. The authors created a strict test protocol to measure exactly how much extra effort is needed when an agent must prove its code correct as judged by this referee. They found verifying the code adds a measurable cost in time or effort, but it varies by component size. This helps understand the trade-offs when requiring machine verification in software.
Open → 2609.11076v1

Retrofitting code with large language models to add exception handling

Retrofitting Code Using LLMs to Support Exceptional Behavior

Abstract: Exception Related Code (ERC), which includes throw statements, conditions (if statements) that guard those throw statements, and try/catch blocks, is an essential component of software systems, allowing developers to detect and handle exceptional states that deviate from the expected program behavior. However, manually writing ERC across large codebases is tedious. We propose a novel task: retrofitting existing code with ERC. Namely, given code (without ERC) and Exceptional Behavior Tests (EBTs) (e.g., check if method throws InvalidArgumentException if null is given as the value to the argument) we aim to automatically generate missing ERC, such that the given tests pass. We design and implement Exception Coder (EXCODER) that performs context engineering to help Large Language Models (LLMs) tackle this task. EXCODER integrates static and dynamic program analysis with LLMs by providing the extracted contextual information to the LLMs. To evaluate EXCODER, we build a benchmark constructed from GitHub Java repositories, where we systematically remove ERC in 304 methods from 75 projects. Our results demonstrate that EXCODER provides an effective, though imperfect, solution to this problem in automated code generation, offering developers the first way to implement ERC following test-driven development. When combined with Qwen 2.5 Coder 32b, EXCODER achieves pass@1, 5, and 10 rates of 85.92% (12.56 percentage points over baseline), 86.18% (12.82 p.p. over baseline), and 86.51% (13.15 p.p. over baseline), respectively, on developer-written test suites. Our manual inspection of the generated code further reveals limitations of EXCODER, pointing to directions for future work.

Wed 9 SeptSoftware EngineeringComputation and Language
The gist
Software often needs special code to handle unusual or error situations, but writing this code can be boring and time-consuming. The authors created a method called EXCODER that helps large language models add this special exception-handling code automatically to existing programs when given tests that expect errors. EXCODER works by combining static analysis (looking at the code structure) and dynamic analysis (running code) with language models to better understand where and how to add these corrections. Their tests show EXCODER does a good job, though not perfect, of generating this code to pass developer-written tests.
Open → 2609.10397v1

GraphDroid improves mobile app testing by exploring apps more effectively

GraphDroid: Asynchronous LLM-Based Mobile App GUI Testing via History-Aware Exploration and Hybrid Intent Fulfillment

Abstract: Automated GUI testing is a widely adopted technique for ensuring mobile application quality by simulating user interactions to exercise functionalities. Despite the research breakthroughs in the past decades, covering complex functionalities that require multi-step action sequences still remains challenging. Traditional tools lack semantic understanding capability and can rarely synthesize such action sequences. Recent LLM-based tools can generate test intents describing target functionalities and leverage the LLM to fulfill the intents, but suffer from three key limitations: 1) loss of historical context for identifying uncovered functionalities, 2) synchronous intent generation that blocks exploration, and 3) per-step LLM-driven fulfillment incurring high cost and latency. To address these limitations, we propose GraphDroid, an intent-driven GUI testing framework that integrates a cluster-based memory mechanism to effectively identify uncovered functionalities from historically visited states for comprehensive application testing. For improving testing efficiency, GraphDroid adopts an asynchronous intent generation paradigm that eliminates the latency bottleneck and a hybrid intent fulfillment strategy that reserves the LLM for fulfilling complex intents while delegating simple intents to a lightweight heuristic algorithm. We evaluate GraphDroid on 41 real-world Android apps against six state-of-the-art baselines. Results show that GraphDroid outperforms all baselines, achieving up to 36.4% higher code coverage while incurring less than one eighth of the cost of the best pure LLM-based baseline. GraphDroid also exposes 19 bugs in the 41 apps and detects 13 of 52 crashes in the Themis bug benchmark, surpassing all the six baselines. Seven of the 19 bugs were previously unknown and we reported them to the developers. So far, four bugs have been confirmed and fixed.

Wed 9 SeptSoftware Engineering
The gist
Testing mobile apps automatically is hard when you need to try complicated sequences of actions to find all the important features and bugs. The authors created GraphDroid, a system that remembers what parts of the app it has explored, plans new actions without waiting too long, and uses both fast rules and AI to carry out tests efficiently. This approach lets GraphDroid cover more of the app’s code and find more bugs than other recent tools, while using fewer expensive AI calls. The authors tested it on many real Android apps and found new bugs that developers fixed.
Open → 2609.10031v1

Cross repository knowledge graph improves code generation accuracy

Beyond Repository Boundaries: Cross-Repository Graph Retrieval for Code Generation

Abstract: Repository-level code generation requires generated code to be compatible not only with the target repository but also with its dependency environment. Existing retrieval-based methods mainly retrieve context from the local repository, leaving external API usage dependent on the model's pretrained knowledge, which can be insufficient for unseen or version-specific APIs. Moreover, current retrieval strategies largely focus on one-hop evidence and overlook the structural relationships among code components. We propose CrossCoder, a cross-repository code generation framework that explicitly incorporates external libraries into the retrieval context through a unified knowledge graph over repository and library entities. CrossCoder identifies important nodes via planning and semantic retrieval, then selectively expands neighboring nodes to retrieve richer multi-hop contextual evidence for generation. To further evaluate dependency-version compatibility, we introduce VersionExec, an execution-based benchmark derived from BigCodeBench that evaluates generation under different dependency versions. Experimental results on RepoExec, DevEval, and VersionExec demonstrate that CrossCoder consistently improves both functional correctness (up to 6.3% on pass@1) and robustness to dependency-version changes.

Wed 9 SeptSoftware Engineering
The gist
Generating code that works well with other software libraries can be tricky because code often depends on things outside its own project. The authors created CrossCoder, a tool that looks beyond one project to include relevant parts from other libraries using a knowledge graph. This helps the system find important connections in the code and dependencies, making the generated code more accurate and compatible with different versions. They also made a new test called VersionExec to check how well the generated code works with various library versions. Their experiments show better code correctness and robustness with their approach.
Open → 2609.09987v1

Code generation leakage detection improved with new membership inference method

Keep Evaluation Fair: Detecting Data Leakage in Code Generation Benchmarks via Membership Inference Attacks

Abstract: Code generation benchmarks are widely used to evaluate Large Language Models (LLMs), but benchmark data leakage into training sets can inflate performance and undermine evaluation validity. DetectLeak, a method specifically designed for code generation benchmark leakage detection, relies on perplexity scores to identify likely leaked samples. However, perplexity mainly reflects general familiarity with code patterns and may perform poorly on complex or rare samples. It also overlooks other useful signals, such as code similarity, functional correctness, and semantic representations. To address these limitations, we propose CGMIA (Code-Generation-specific Membership Inference Attack), a method for detecting leakage in code generation benchmarks. CGMIA fine-tunes a shadow model on a subset of benchmark samples to construct labeled member and non-member data. For each sample, it collects the input prompt, generated code, and reference solution, and extracts expert features, including CodeBLEU, edit distance, test pass rate, and perplexity, together with semantic features from CodeBERT embeddings. An integrated learning module combines these features to capture both surface-level memorization signals and deeper behavioral patterns, enabling a classifier to predict whether a sample was included in the target model's training set. Experiments on eight code generation benchmarks show that CGMIA outperforms eight existing membership inference methods in most cases. It also effectively detects known leaked APPS samples in StarCoder-7B's training data.

Wed 9 SeptSoftware Engineering
The gist
Evaluating AI models that generate code can be tricky when test examples accidentally appear in training data, making results seem better than they really are. The authors created a method called CGMIA that uses many clues—like how similar codes are, how well the code works, and language model scores—to spot leaked test examples. This new approach works better than previous methods and found leaked samples in a popular AI model’s training data. Detecting such leakage helps make AI code evaluations fair and trustworthy.
Open → 2609.09865v1

Traditional test criteria struggle to find bugs in AI generated code

How effective are traditional test criteria at detecting bugs in large language models generated code?

Abstract: Test adequacy criteria are widely used to evaluate and guide software testing. Although prior research has extensively examined these criteria using human-written programs, faults, and tests, the increasing adoption of Large Language Models (LLMs) for code generation raises important questions about their effectiveness in detecting LLM-induced faults. To investigate this, we conduct an empirical study involving 5 LLMs and 4 benchmarks, simulating end-to-end workflows in which both code and tests are automatically generated. We collect 6,000+ faulty program instances and evaluate the effectiveness and efficiency of 3 widely used adequacy criteria: statement coverage, branch coverage, and mutation testing. Our findings reveal several key insights. First, most faults introduced by LLMs are relatively trivial to catch. Second, the challenging faults are difficult to trigger using either traditional coverage-based or mutation-based criteria. Third, actual fault detection rates remain extremely low, often near zero, because test oracles fail to capture faulty behavior triggered by the generated test prefixes, exposing a critical limitation of automated test generation. Fourth, prompt-aware oracles can improve fault detection, but their overall effectiveness remains limited, highlighting the need for users to manually reason about test assertions. We further observe that mutation testing only marginally outperforms traditional coverage criteria in both triggering and detecting faults, raising questions about whether its significantly higher application cost is justified in this context.

Tue 8 SeptSoftware Engineering
The gist
The paper looks at how well common software testing rules catch bugs in code written by AI models. They found that many bugs are actually easy to detect, but harder problems slip through unnoticed because tests can't always spot them. Even stronger testing methods only do slightly better and may not be worth their extra effort. The authors say people still need to carefully check test results manually to find tricky mistakes.
Open → 2609.09315v1

DJPlus reduces redundant test steps for faster system testing

DJPlus: Generating minimal test suites for strong coverage criteria in graph models

Abstract: Automated test generation from graph models is essential to model-based testing. In this type of testing, graph coverage ensures test suite strength but also results in long test cases that take time to execute on the system under test. We propose a novel optimization-driven method, DJPlus, which generates reduced test suites while satisfying given graph-based test requirements. We implement DJPlus and show the feasibility of edge-pair criterion, a stronger coverage criterion than vertex or edge criteria, on four realistic systems, while prime path criterion poses scalability issues. Our evaluation reveals that the alternative methods generate 2 to 26 times more redundant test steps than DJPlus and DJPlus decreases test execution times by reducing the number of test steps. These results show that DJPlus is a positive step towards tackling the challenges of model-based testing at an industrial scale.

Tue 8 SeptSoftware Engineering
The gist
Testing software systems can take a long time when tests cover all possible paths, which leads to very long test scenarios. The authors created DJPlus, a method that reduces the number of test steps while still meeting strict testing goals based on graphs that model software behavior. DJPlus produces much shorter test suites that run faster than other methods, enabling more efficient testing without losing important coverage. This helps companies test complicated systems quicker and with fewer redundant steps.
Open → 2609.08953v1

Code driven framework improves handling of evolving information in conversations

EvolveScaler: Synthesizing Information-Evolution Contexts via Executable State Machines and Natural-Language Rendering

Abstract: In persistent interactions, long contexts may encode an evolving process rather than a fixed record: later events can revise or revoke earlier information, changing what remains valid and what conclusions follow. We call this setting information evolution (IE). Solving IE requires identifying valid records, applying updates in order, and reconstructing the query-relevant state from the event history. Existing text-first synthesis pipelines make such data difficult to verify because state transitions and answer logic remain implicit. We introduce EvolveScaler, a code-driven framework that defines information evolution before rendering it as natural language. Human-authored operational specifications define state transitions, record validity, difficulty controls, and executable answer logic; a strong LLM then synthesizes a self-contained simulator from each specification. Executing validated simulators produces natural-language multi-turn event histories, while deterministic replay computes reference answers and atomic checklists. We instantiate EvolveScaler with 117 task prototypes and 159 final-question operators across five difficulty levels spanning approximately 7 to 1,200 events per instance, yielding about 35,100 training examples and 585 validated evaluation instances. On the very_long tier, the strongest model reaches 59.3% avg@5, while six models score below 10%. Training an internal A3B model on 6,000 EvolveScaler examples improves performance over its base checkpoint on all eight independently constructed out-of-distribution benchmarks, with a 5.25-point average gain. These results show that code-driven IE synthesis provides both challenging evaluation and transferable training supervision.

Tue 8 SeptArtificial IntelligenceSoftware Engineering
The gist
Sometimes, when information changes over time, earlier facts get updated or erased, making understanding the full story harder. The authors created EvolveScaler, a method that first defines these changing facts using clear, computer-readable rules before turning them into natural language stories. This approach helps test and train computer models better by simulating events and checking answers precisely. Their tests show this method creates challenging examples and helps improve model performance on new situations.
Open → 2609.08435v1

FPScan finds critical errors in floating-point programs automatically

FPScan: An Automated Constraint-Based Analyzer for Floating-Point Anomaly Detection

Abstract: Writing error-free floating-point programs is a challenging task, especially for programmers who lack a strong background in numerical analysis and rounding-error propagation. State-of-the-art techniques typically aim to bound such errors using static or dynamic analysis. However, only a few tools explicitly address critical floating-point pitfalls such as absorption and catastrophic cancellation. These anomalies represent situations in which rounding errors are significantly amplified, causing the semantics of the finite-precision computation to deviate substantially from the real-number semantics. In this article, we present FPScan, a novel tool to formally define and detect both catastrophic cancellation and absorption in floating-point programs. Our approach starts with a custom static analyzer based on abstract interpretation to infer the order of magnitude of all program variables. This magnitude information is then used to build a set of first-order constraints that model error propagation and numerical precision within the program. Finally, we employ an off-the-shelf SMT solver to determine whether the program exhibits any of these critical numerical pitfalls. Experiments were conducted on FPBench, a well-known benchmark suite of floating-point programs, to evaluate the effectiveness of our tool. We also present a comparison with state-of-the-art tools regarding soundness and analysis time.

Mon 7 SeptSoftware Engineering
The gist
Floating-point programs, which use numbers with limited precision, are tricky to write correctly because tiny rounding mistakes can become large problems. FPScan is a new tool that helps find two types of serious errors where these small rounding issues get magnified. It works by analyzing the sizes of numbers in a program and setting up math constraints to check where errors could get very bad. The authors tested FPScan on standard benchmarks and compared it with other tools to show how well it detects these problems.
Open → 2609.07492v1

Surrogate models speed up multi-objective software architecture optimization

A Surrogate-based Approach for Fast Multi-objective Architectural Refactoring Optimization

Abstract: Software model optimization is a process that generates architecture alternatives aimed at improving quantifiable non-functional properties of software systems, such as performance and reliability. Multi-objective evolutionary algorithms are commonly used to explore the search space and help designers identify trade-offs among competing non-functional properties (e.g., through a Pareto front). However, such algorithms face efficiency challenges in complex software models and large design spaces, since evaluating the fitness (i.e., the quality) of each architecture requires analysis tools that become computationally expensive when repeatedly invoked during the search process. In this paper, we explore the construction of surrogate models based on regression techniques to approximate the outputs of these analysis tools at significantly lower computational cost, while maintaining reasonable output accuracy. Our experimental results suggest that surrogate models provide savings of up to $30\%$ in computational time and maintain the Pareto front quality provided by evolutionary algorithms. Also, we observed some differences in the architectural models produced by our approach. Overall, surrogate models constitute a promising approach for scaling multi-objective architecture optimization to larger spaces and complex architectural models.

Mon 7 SeptSoftware Engineering
The gist
Optimizing software architecture to improve things like speed and reliability often requires testing many design options, which can be very slow. The authors tried using shortcut models that approximate the testing process to save time. These shortcut models can reduce computation time by about 30% while still finding good design trade-offs. This approach helps handle more complex designs more efficiently.
Open → 2609.07389v1

Limits of single-run safety monitors for large language models revealed

The Oversight Gap: What LLM Safety Monitors Miss, and Why It Is Not Capability

Abstract: Several properties safety monitors are asked to certify, among them cross-tenant noninterference, sandbagging and evaluation awareness, are 2-safety hyperproperties, witnessed only by two executions. The standard consequence is a binary impossibility: one trace cannot decide them. We replace the binary with a measurement. A tight bound puts the balanced accuracy of any single-trace monitor at $\tfrac12+\tfrac12\,TV(P_0,P_1)$, turning undecidability into a graded detectability frontier and defining an oversight gap: a monitor's shortfall below it. On a leak family with closed-form $TV$, nine LLM monitors are optimal at $TV=0$ but capture little signal as $TV$ grows; at $TV=1$, where a 20-line membership check scores $100\%$, they average $60.9\%$. That shortfall is mostly not capability: naming what to check closes $61\%$ of it while leaving the $TV=0$ control at chance. The same split runs through a $2{\times}2$ factorial: an imagined second run leaves monitors at chance ($50.4\%$) while the same rule on an executed second run reaches $90.0\%$, and a stored oracle without a comparison procedure yields only $68.2\%$. Information and procedure are each necessary and neither is capability. Under nondeterminism, replay tracks a closed-form $k$-replay curve only under the right projection, and a projection frontier shows the resulting dilemma is forced: narrow misses $98.6\%$ of off-channel leaks, broad flags $75.7\%$ of clean traffic, and attainable accuracy decays like $1/(qm)$ in the benign-variation rate and the channel count. Finally, two frontier LLM judges certified an earlier version of our own benchmark as sound while a sign test found a directional bias ($p=2.7\times10^{-5}$) that invalidated three of our findings. Construction validity for hyperproperty benchmarks should be proved mechanically, not audited by models.

Mon 7 SeptMachine LearningCryptography and Security
The gist
Checking the safety of large language models (LLMs) by looking at just one run or interaction is often not enough. The authors show that certain safety properties can only be reliably detected by comparing multiple runs, not by examining a single run. They measured how well current safety monitors work and found that they miss many signals especially when leakage between runs grows. The missing signals are not because the models lack capability but because of what and how we check safety. The authors suggest safety tests should be mechanically verified instead of relying on human or model audits.
Open → 2609.07162v1