Papers for

software quality assurance 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.

Large language models improve testing of security scanning tools

Combining LLM and Dynamic Analysis for Universal Testing of Static Application Security Testing Tools

Abstract: Static application security testing (SAST) tools help detect potential software vulnerabilities, but they themselves contain faults undermining reliability and usability. Automated testing can address these issues, yet current techniques suffer from limited program transformation diversity and lack mechanisms to verify generated variants, leading to reduced fault detection and high manual effort. We present LLM4SAST, the first universal framework detecting faults in SAST tools using large language models and dynamic feedback. Our key insight is leveraging LLMs to understand and transform code in diverse programming languages. We design novel metamorphic relations with transformations to guide variant generation, using an LLM to produce multi-language variants that satisfy these relations. To reduce erroneous variants and identify unique faults, we propose two heuristics: dynamic-feedback-driven selection and program-differencing-based clustering. For each metamorphic relation, a report-centric test oracle detects variants that fail tests and identifies underlying faults by differentially analyzing SAST reports of the seed program and its variants. LLM4SAST identified 66 unique faults across six SAST tools, with 32 confirmed or fixed after being reported to developers, demonstrating effectiveness. The proposed heuristics eliminate 47.8% of false positives, and LLM4SAST detects 3.4 times more faults while requiring only 39.8% of the variants compared to existing approaches.

Thu 15 OctCryptography and SecuritySoftware Engineering
The gist
Static security tools try to find bugs in software but often have their own bugs, making them less reliable. The authors created LLM4SAST, combining large language models and test feedback to generate many code variants across programming languages to better test these tools. Their method helps find more bugs in security scanners by checking differences in tool reports, reducing false alarms, and cutting down manual effort. They found dozens of real bugs in popular security tools, showing their approach works well.
Open → 2610.21309v1

Reviewers demand stronger evidence for AI authored code changes

Plausible Is Not Enough: Trust and Evidence in AI-Authored Pull Request Review

Abstract: Code review is where AI-authored pull requests (AIPRs) must earn reviewer trust before integration, yet it is unclear whether reviewers apply the same criteria used for human-authored pull requests (HPRs). We surveyed 239 practitioners from 31 countries using matched HPR and AIPR questions to compare trust, evidence requirements, and verification practices within respondents. Most respondents (64.9%) reported lower initial trust in AIPRs. They relied less on author track record and subsystem familiarity, emphasizing instead human prompter expertise and bounded change size. For approval, respondents more often considered their own reasoning through critical cases sufficient for AIPRs than HPRs (55.2% versus 28.5%), while relying less on test coverage. Overall, 61.1% reported higher evidence requirements for AIPRs, and the share who would block approval under residual uncertainty increased from 19.4% for HPRs to 43.9% for AIPRs. Respondents prioritized test inspection, project context, and local execution, and more often selected partial reimplementation to verify non-trivial logic. Unclear ownership was also more likely to pause AIPR review (29.3% versus 14.6%). Open-ended responses pointed to the difficulty of validating plausible code without reliable context and human accountability. These findings frame AIPR review as an evidence-ownership problem, not merely a correctness check. Reviewers need to connect generated changes to validated behavior and responsible maintainers. Review tools and agentic workflows should expose provenance, distinguish generated claims from human-validated evidence, and make uncertainty visible before approval.

Thu 15 OctSoftware Engineering
The gist
This paper looks at how software developers review code suggested by AI versus humans. It finds that developers trust AI code less and want more proof that it works well before accepting it. Instead of relying on the AI author’s past work, developers focus on understanding the changes, running tests themselves, and who wrote the AI prompt. The authors suggest tools should show where AI code comes from and clearly mark what is verified by humans.
Open → 2610.21144v1

Benchmark tests large language models on reducing coding errors safely

LintEval: Benchmarking LLMs on Linter-Guided File Refactoring

Abstract: Linters are widely used in code maintenance and real-time IDE editing to surface lint alerts related to performance, style, error-prone, and other patterns in source files. However, existing code benchmarks do not explicitly evaluate linter-guided file refactoring, where models must reduce lint alerts in source files with correct initial functionality while satisfying functionality preservation. We introduce LintEval, a multilingual benchmark for linter-guided file refactoring across C++, Python, and Java, comprising 13,061 programs with correct initial functionality and 171,662 lint alerts extracted using language-specific linters. LintEval jointly evaluates functionality preservation, lint alert reduction, new alert avoidance, and edit minimality. Experiments reveal a persistent trade-off: closed-source commercial models reach up to 90.4% Reduction@P but achieve only 67.1%-68.3% Pass@1, while several open-source small models show low or negative Reduction@P. A controlled fine-tuning study further shows that supervision format matters: refactoring-oriented SFT raises Qwen2.5-Coder-7B Reduction@P from 24.7% to 76.0%. LintEval enables controlled evaluation of models that improve source files under functionality preservation.

Wed 14 OctSoftware EngineeringComputation and Language
The gist
Programs often have coding style or error warnings called lint alerts, which developers fix without changing how the program works. The authors created LintEval, a large test set to check if AI code models can fix these warnings while keeping the code working correctly. They found that some big commercial models reduce many alerts but sometimes break code functionality, while smaller models struggle to reduce alerts at all. They also showed that training models specifically on refactoring examples helps improve their performance significantly.
Open → 2610.20027v1

Structured checks improve trustworthiness of scientific workflow outputs

Structure Before Intelligence: Gating What Agentic Scientific Workflows Release

Abstract: An agentic scientific workflow can run to completion and still release wrong results: a silent numerical error, a stale input, or a defect in a shared upstream step can contaminate several outputs while a sibling branch stays correct. We treat trust in such results as a release decision. A harness around the workflow's directed acyclic graph (DAG) decides which outputs may be used: it enforces mandatory checks, contains failures to the affected branch, recomputes from tracked versions, adds validators, and releases a result only if a risk model estimates its probability of being invalid as low. Language-model agents work inside the harness, choosing corrective actions and reviewing releases, but cannot override it. On 60 held-out paired instances of two workflows with injected faults, we switched components on and off. Each supplied a different property. Containment and recovery raised the number of correct results. Validation supplied safety: fixed rules without validation released 37 invalid results, while validating every candidate released none. Risk estimation supplied efficiency, matching that safety with 31% fewer validators at somewhat lower yield, although better targeting than random validation was not shown. Lineage evidence helped on one workflow. The language model added no measurable benefit: whether invalid results escaped depended on the harness, not the model. This proof of concept points to a practical path: placing agents inside explicit release-control structure can keep released scientific results trustworthy, and it gives more capable agents a measurable baseline to improve on.

Wed 14 OctArtificial Intelligence
The gist
Scientific workflows can sometimes produce wrong results without anyone noticing. The authors looked at using a safety system that checks and controls which results are allowed to be shared. This system includes rechecking calculations, validating outputs, and estimating risk before releasing results. They found that while these controls helped reduce mistakes, language-model agents used to fix errors didn't make a big difference. Overall, this approach shows how organizing the release process can help keep scientific results reliable.
Open → 2610.19507v1

BenchChecker improves trust in bug-fixing tests for code AI models

BenchChecker: Assessing the Credibility of Bug-Fixing Benchmarks for LLMs

Abstract: While Large Language Models (LLMs) show promise for Automatic Program Repair (APR), existing benchmarks suffer from data contamination, in which test samples appear in training sets, artificially inflating performance. To address this, we propose BenchChecker, a framework compatible with both open-source and closed-source models that supports more credible evaluation by detecting such contamination. Grounded in the observation that persistent patches likely remain in recent repository snapshots used for training, BenchChecker employs a forensics-based two-stage detection process using only textual model outputs together with public repository history. The first stage conducts a repository presence test by probing the model with code prefixes to infer training inclusion; the second stage performs a patch presence test to verify patch persistence via similarity alignment and test-suite verification. Evaluations using StarCoder-15B, StarCoder2-15B, and CodeGen2-16B trained on The Stack v2 demonstrate that BenchChecker achieves robust detection with AUC scores around 0.9 across six benchmarks. Furthermore, applying BenchChecker to SWE-bench Verified and Multi-SWE-bench reveals that filtering contaminated samples reduces the reported resolution rates of most LLMs by more than 20% relative to the original rates on medium-difficulty tasks.

Wed 14 OctSoftware Engineering
The gist
Bug-fixing tests used to check how well AI models fix code often have a problem: some test problems are accidentally included in the AI's training data, making the AI look better than it really is. The authors created BenchChecker, a method that uses clues from code history and the AI’s own answers to spot these overlaps. Their tests show BenchChecker works well and that removing these overlaps gives a more honest view of AI model performance. This helps people better understand which AI really fix bugs well.
Open → 2610.19447v1

Large language models produce varying quality code beyond correctness

Beyond Functional Correctness: Static Code Quality Profiling of LLM-Generated Code

Abstract: Large language models (LLMs) are increasingly used for code generation, yet most evaluations still focus on whether generated code passes benchmark test suites. Functional correctness alone, however, provides only a limited view of quality: benchmark tests are often incomplete, and passing them does not guarantee that code is maintainable, reliable, or well-structured. This paper {presents a large-scale static quality profiling of} LLM-generated Python code, with a focus on maintainability and reliability. Using 65{,}663 programs from 73 models in LiveCodeBench, we evaluate generated code with established static analysis tools, including Pylint, Radon, and SonarQube. Our results show systematic differences across models that are not captured by correctness alone, with maintainability emerging as the clearest source of variation. We further find that correctness often comes with structural trade-offs rather than uniformly simpler solutions. Overall, our findings motivate evaluation frameworks that assess LLM-generated code beyond pass rates alone.

Tue 13 OctSoftware Engineering
The gist
Checking whether computer code works correctly is important, but it doesn't tell the whole story. The authors studied code written by AI models and found that some produce code that is harder to maintain or less reliable, even if it passes basic tests. They used tools that look at how the code is structured and how easy it is to update or fix. Their findings suggest that judging AI code by whether it runs correctly misses important differences in quality.
Open → 2610.19167v1

Model grades AI agents by evidence of safety and reliability controls

AgentStripes: An Evidence-Graded Maturity Model for AI Agents

Abstract: Benchmarks report what an Artificial Intelligence (AI) agent can do on a task suite, but not whether one released version has been engineered with the controls that make it reliable, safe and observable, or how strongly that is shown. This paper proposes AgentStripes, an evidence-graded maturity model for AI agents. It defines levels (0 to 7 stripes), process areas (12 areas holding 40 capabilities), three gates (basic, safety, proof) that hold an agent at a level however high its score, and evidence grades E0 to E5. Each applicable capability receives a rating from 0 to 3 and a separate evidence level; these are combined into a credit, aggregated into a severity-weighted score and converted into stripes that the gates limit. Instruments gather evidence, language-model judges interpret it under explicit criteria, and the arithmetic is deterministic. The model is compared with standards at topic level without a claim of conformance, and an unexecuted validation protocol is specified. An empirical evaluation (exploratory, non-confirmatory) of 30 public Python agent repositories, with static evidence only, is a demonstration and not a validation: static evidence caps every final stripe at 2, 26 repositories end at one stripe and 4 at two, and this distinction is unreliable, since re-judging changed the final stripe of 4 of 22 repositories (engine, dossier and panel changed), whereas none of 8 panel-only repeats, all at stripe 1, changed. The parameters are expert conventions without outcome based calibration, and the stripes have not been shown to predict reliability or safety.

Tue 13 OctArtificial IntelligenceComputers and Society
The gist
It can be hard to know if an AI agent not only works but is also safe and reliable. The authors created AgentStripes, a system that scores AI agents from zero to seven stripes based on how well their reliability and safety features are designed and supported by evidence. They evaluate agents across 12 key areas and assign different evidence grades to show the strength of proof. They tested AgentStripes on 30 public AI agent projects, finding most scored low because they only had basic static evidence. This method helps identify how much confidence to place in an AI agent’s safety and reliability design.
Open → 2610.18603v1

Verifier errors shape reinforcement learning success in language models

Checking the Checkers: A Synthesis of Verifier Noise and Robustness in RLVR

Abstract: Reinforcement learning with verifiable rewards (RLVR) has become a principal recipe for improving the reasoning of large language models (LLMs). It rests on the assumption that the checker scoring each response is itself correct. In practice, rule-based checkers reject correct answers in unexpected formats, unit tests accept incorrect programs, and LLM judges can be led to approve empty or adversarial responses. This work surveys 58 studies that measure, analyze, or mitigate such verifier errors. We ask what errors verifiers make, how they affect training, which mitigations work against which errors, and how the findings extend to self-generated, rubric- and judge-based, and verifier-free rewards. The evidence suggests that the structure of an error matters more than its rate. Random errors mostly slow learning, though under a fixed budget or KL regularization they also lower final accuracy. False positives that the policy can learn to trigger can cause plateaus or collapse, sometimes even with a low initial error rate. Whether a verifier wrongly rejects or accepts depends on what it checks and who built it, not on its family. Its errors shift as the policy improves, and most mitigations have been tested against only one kind of error. We compile the findings into comparison tables, reconcile apparent conflicts in the literature, and propose a reporting protocol to make future results comparable.

Tue 13 OctMachine LearningArtificial IntelligenceComputation and Language
The gist
Reinforcement learning with verifiable rewards (RLVR) uses automatic checkers to score answers from language models, but these checkers can make mistakes like wrongly rejecting correct answers or accepting wrong ones. The authors review 58 studies to understand what kinds of mistakes checkers make, how these affect model training, and which fixes help most. They find that the type of error matters more than how often it occurs, with some errors causing training to stall or collapse. The paper also recommends ways to report results so future studies can compare findings better.
Open → 2610.17824v1

Hallucination detection challenges in tool-augmented language models

ToolHACE: A Dataset for Detecting Hallucinations in Tool-Based LLM Responses

Abstract: Tool-augmented language models ground their responses in external tool outputs, improving reliability beyond parametric knowledge alone. However, even when the correct tool is called and returns accurate information, models may still contradict such outputs, omit critical details, or generate unsupported claims. Existing hallucination benchmarks for tool-augmented dialogue primarily focus on the tool-calling stage, evaluating whether the correct tool and arguments are selected, while overlooking errors that arise during post-tool response generation. To address this gap, we introduce ToolHACE, a span-level benchmark for hallucination detection in tool-augmented LLM responses, covering five fine-grained hallucination categories. Through extensive experiments with modern hallucination detectors, we show that post-tool-call hallucinations are widespread and remain challenging to detect. Our results further demonstrate that effective detection requires training on specialized tool-augmented corpora, while transfer from tool-agnostic hallucination datasets performs poorly in this setting. These findings highlight the need for dedicated benchmarks and models for reliable hallucination detection in tool-augmented language systems.

Mon 12 OctComputation and Language
The gist
Language models that use external tools can improve accuracy by checking facts, but they sometimes still make mistakes even after using the tools. The authors introduce a new dataset called ToolHACE that helps find these specific mistakes in the responses generated after the tool is used. Their experiments show these errors are common and hard to catch without training on similar data. The study points out the need for specialized tools to detect these hallucinations properly.
Open → 2610.17125v1

Automated AI auditors respond differently to code and benchmark contexts

Audit tools of the trade: Automated Auditor Elicitation Can Be Sensitive to the Context the Auditor Is Given

Abstract: Does providing additional context to automated AI auditors improve their effectiveness? Using the Petri tool to audit LLM coding agents, we test the impact of providing two types of resources (an external codebase and benchmark transcripts) to LLM auditors, across four auditor-target LLM pairs and three behaviours (harmful compliance, reward hacking, sycophancy). (1) External codebase: We provide the auditor LLM with a fixed, external open source codebase, which prior work finds improves the realism of synthetic audits. Providing this resource suppresses reward hacking in both auditor-target pairs whose baseline rate is above the floor (4.8 to 1.3 and 3.9 to 1.8 on Petri's default 1-10 scale); the remaining two pairs sit at the floor throughout. The suppression recurs in three of four pairs under a different scenario and resource bundle. (2) External benchmark transcripts: We provide the auditor with transcripts of the target's performance on benchmarks measuring similar behaviours, intended to inform the auditor about the target's behavioural patterns. Providing this resource raises reward hacking scores in all four pairs (from 1.7 to 6.1 in one case). However, subsequent experiments show that supplying only the related benchmark's abstract, without transcripts, also increases reward hacking, and the effect is absent under a different framing of the same behaviour. Overall, we find no consistent effect of either resource outside reward hacking, but we find substantial variability in judge-scored behaviour across conditions. Our results underscore the importance of careful piloting with tools such as Petri, as the measured rate of target behaviour is highly sensitive to configuration decisions. We hope our results inspire more research into the reliability and robustness of automated alignment auditing.

Mon 12 OctArtificial Intelligence
The gist
The paper studies how extra information given to AI auditors affects their ability to check other AI systems for bad behavior. The researchers gave auditors access to either a codebase or example transcripts from related tests and saw mixed effects. Access to code helped reduce one bad behavior called reward hacking, while access to example transcripts sometimes made reward hacking appear worse. Overall, the way auditors rated bad behavior varied a lot depending on what context they had, showing these tools can be sensitive and tricky to configure.
Open → 2610.16911v1

Repository size influences references beyond code changes in pull requests

Reviewing Beyond the Change: Repository Size and Existing Code Across Agent and Human Pull Requests

Abstract: Reviewers sometimes name existing repository items outside the change under review. We ask whether such references are more common in larger repositories, and whether the pattern differs between agent-authored and human-authored pull requests. An instrument resolves names in inline review comments against the base-commit repository; size-matched negative controls estimate chance matches. Among 92,042 comments on agent pull requests in 2,034 GitHub repositories, 6.5 per cent name an existing item outside the change. An internally pre-specified log-linear model finds an odds ratio of 1.35 per tenfold increase in code files (interval 1.15 to 1.59), and size-matched negative controls indicate that chance matching does not account for the rise. Exploratory analyses suggest that the association is concentrated from small to mid-sized repositories and is imprecise among large ones. Human pull requests in 1,845 of these repositories show a similar association. A pre-specified comparison finds a small agent excess just within the bound set as negligible, but the evidence does not establish a robust agent-specific difference. The instrument misses many references, so reported shares likely understate prevalence, and the validation cannot estimate how recall changes with repository size.

Sun 11 OctSoftware Engineering
The gist
When people review code changes on platforms like GitHub, they sometimes mention parts of the project not directly changed in that update. The authors studied if this happens more in bigger projects and if it differs when the changes were made by automated tools versus humans. They found that in larger codebases, reviewers name existing parts outside the immediate change more often, and this pattern is similar whether a human or an automated system made the change. However, their tool likely missed some references, so the actual numbers might be higher.
Open → 2610.15567v1

Claude Code improves bug origin search using semantic commit histories

Rethinking SZZ Search Strategies: Lessons from Claude Code

Abstract: Identifying bug-inducing commits (BICs) is important for studying software bugs and maintaining software, yet the accuracy of existing SZZ methods remains limited. Although various improvements have been proposed, many SZZ methods still rely on code tracing, which searches for BICs by tracing code changed in a bug-fixing commit (BFC) back to earlier commits. However, this approach may miss the actual BIC when the code responsible for introducing a bug differs from the code modified to fix it. To overcome this limitation, we investigate whether BIC identification can be improved by exploring search strategies that are not constrained to start with code tracing. We use Claude Code, a coding agent that has demonstrated high BIC identification accuracy in prior research, to explore such strategies. Rather than prescribing a search process or providing predefined candidate commits, we allow Claude Code to independently investigate a Git repository. We evaluate its identification accuracy and search behavior on 79 Java cases from 70 repositories. In 79.7% of runs, Claude Code reviewed commit histories before inspecting individual code diffs. It used commit messages to select changes for closer inspection. With this approach, Claude Code achieves an F1 score of 0.771, significantly outperforming all ten evaluated SZZ baselines. Our failure analysis also reveals incorrect oracle labels and ambiguities in BIC definitions in the studied evaluation dataset. After reconstructing the evaluation dataset to address these issues, Claude Code achieves an F1 score of 0.938. A key lesson from Claude Code for improving SZZ search strategies is to use semantic information to find relevant commits and then examine their code changes, rather than starting with code tracing.

Sat 10 OctSoftware Engineering
The gist
Finding the exact code change that caused a software bug is tricky because changes that fix bugs don't always point back to the original buggy code. The paper studies a method called Claude Code, which looks at commit messages and the history of changes instead of just tracing code lines backward. This approach lets Claude Code find bug-causing commits more accurately than traditional methods. The authors also improved the quality of the evaluation data to better measure these results.
Open → 2610.14462v1

AI robustness auditing frameworks guided by key meta-requirements

Actionable Meta-Requirements for AI Robustness Auditing

Abstract: AI-enabled systems must remain dependable when the conditions under which they operate change (e.g., due to input perturbations, distribution shifts, or changes in external dependencies). This makes robustness auditing of such systems important for judging whether the available evidence is sufficient to support a defined robustness conclusion. However, designing an AI robustness auditing framework is challenging. A key unresolved issue is determining the requirements such a framework should support; these requirements have not yet been consolidated. We address this gap through meta-requirements: higher-order requirements specifying what a class of auditing frameworks should support. In design science research, literature and domain experts are common sources of meta-requirements; accordingly, we derive the initial set from literature and validate and refine it with practitioners. Our systematic literature review retained 74 of 2,890 records and derived 43 meta-requirements across 16 categories. We evaluated them with 128 practitioners, obtaining 5,504 ratings and 586 substantive comments. Overall, 81.20% of ratings indicated agreement or strong agreement. In particular, 41 of the 43 literature-derived meta-requirements were classified as strongly supported. Practitioner feedback refined the requirements and identified an additional requirement concerning external components and supply chain dependencies. The final set comprises 44 meta-requirements across 16 categories, of which 43 received quantitative validation. These meta-requirements can help organizations implement AI robustness auditing frameworks, assess existing frameworks for completeness, and refine them.

Fri 9 OctArtificial IntelligenceSoftware Engineering
The gist
AI systems need to keep working well even when things around them change unexpectedly. The authors studied lots of existing research and talked to many experts to figure out the most important things that auditing tools for AI robustness should do. They came up with 44 clear guidelines to help people check how reliable these AI systems are. This helps organizations make or improve tools that can spot weaknesses before problems happen.
Open → 2610.14356v1

LLM failure steps found without labels using attention guided scoring

Can Failed Trajectories Reveal Where Agents Go Wrong? Agentic Failure Attribution Without Step-Level Labels

Abstract: Failure attribution for LLM agents aims to identify decisive steps responsible for task failure, which is critical for debugging and improving agentic systems. Existing methods rely on costly LLM prompting, step-level error annotations, or verified successful trajectories that lack failure signals for assistance. In this paper, we study failure attribution from step-unlabeled failure trajectories, where each trajectory is known to have failed but its decisive step is unknown. We propose SOAP (Spectral scOring with Attention-guided Propagation), an effective framework requiring neither step-level training labels nor a separate success-only reference set. SOAP first constructs a spectral reference space from LLM representations and assigns each step a base error score according to its projection behavior. Importantly, later steps may exhibit stronger failure signals because they inherit an earlier mistake, causing independent scorers to favor downstream consequences over the decisive error. To address this downstream contamination, SOAP derives soft step dependencies from attention patterns and propagates downstream error evidence toward its likely upstream sources. Extensive experiments show that SOAP consistently improves attribution performance over competitive baselines.

Fri 9 OctMachine Learning
The gist
Figuring out exactly where a large language model (LLM) agent goes wrong in a task is hard because it usually needs detailed labels for every step or examples of when things succeed. This paper introduces SOAP, a method that can find the key mistake step in a failed attempt without any step-by-step labels or relying on successful examples. SOAP uses the LLM’s internal attention information and patterns in the model’s output to trace back errors to their likely source, even if mistakes appear later due to earlier errors. The authors show through extensive testing that SOAP performs better than other methods at pinpointing these failure points.
Open → 2610.13105v1

Refactoring effects on software quality analyzed using code metrics

Evaluation of Software Quality Through Refactoring Commit-Impact Analysis

Abstract: The aim of this study is to conduct an empirical analysis of the correlation between code modifications and software quality. This will be achieved by examining the effects of changes made before and after each refactoring commit, using software metrics such as size, complexity, code smells, vulnerability, and bug detection. The objective is to conduct static code analysis on open-source software from GitHub repositories using various repository mining and static code analysis tools. Our approach involves formulating research-based questions and utilizing the specified tools to obtain results that will enable us to resolve the case study. The obtained results have been summarised and further analyzed using tables and graphs to achieve the objective.

Fri 9 OctSoftware Engineering
The gist
Code changes can affect how good or bad a software program is. To understand this, the authors studied software projects from GitHub to see what happens to code quality before and after special changes called refactorings. They checked things like code size, complexity, and how many problem spots appear. Their study helps show how refactoring can improve or change software quality using measurable signs.
Open → 2610.12890v1

ObliVul models safety obligations to reduce false alerts in code vulnerability detection

ObliVul: Alert-Conditioned Safety Obligation Modeling and Bidirectional Counterfactual Validation for Code Vulnerability Detection

Abstract: In real-world software development, the primary challenge in vulnerability detection is often not finding suspicious code, but identifying which alerts among the large number of candidate alerts produced by static analysis truly warrant attention. Existing learning-based methods mainly identify suspicious patterns at the function or line level, making it difficult to extract complete program evidence centered on an individual alert. Although large language models can infer risk sources, dangerous operations, protection conditions, and state preconditions from local program facts, such semantic information cannot be reliably aligned with specific program nodes, dependency relations, and propagation paths, and is therefore insufficient to verify whether the corresponding safety obligations truly affect the current alert. To address this problem, we propose ObliVul, an alert-conditioned safety obligation modeling and bidirectional counterfactual validation framework for vulnerability detection. For each candidate alert, ObliVul first extracts a Local Evidence Pack (LEP) from the Code Property Graph (CPG) and uses a large language model to recover candidate safety obligations. It then aligns the safety obligations with program nodes, dependency edges, and path scopes to construct a Local Safety Obligation Graph (LSOG). Finally, VAFI aggregates complementary verified alert evidence while suppressing redundant or weaker evidence to produce a function-level vulnerability prediction. Experimental results show that ObliVul effectively distinguishes vulnerable versions from fixed versions and reduces persistent false positives on fixed code. Ablation studies further confirm the necessity of each component for safety obligation recovery, risk response validation, and function-level vulnerability inference.

Thu 8 OctSoftware Engineering
The gist
When software scanning tools warn about possible security problems in code, they often produce many alerts, most of which are false alarms. The authors propose ObliVul, a method that carefully analyzes each alert by understanding the safety rules the code must follow and checking how those rules relate to the alert. By doing this, ObliVul can better tell real issues from false ones, improving the accuracy of vulnerability detection. Their tests show that this approach reduces unnecessary warnings and correctly spots code fixes.
Open → 2610.11801v1

Study contracts help verify AI research outputs with bound choices

What Output-Only Review Cannot Verify: Study Contracts for Research Agents

Abstract: Some defects in an AI-generated study can be identified from its artifacts; others require knowledge of what was approved before execution. We propose study contracts that bind declared experimental choices, run obligations and claim scope to recorded execution evidence, and distinguish this contract-relative verification from scientific truth. A diagnostic using eight self-authored clean/mutated pairs illustrates the information boundary. A deterministic checker applying a registered, fault-specific rule to approved and executed objects detected all eight registered mutations. Across eighteen recorded judge aliases given individual metadata-filtered packages without pair context or the registry-selected fault label, 104 of 144 mutated evaluation cases received defect flags; the remaining cases comprised 32 abstentions and eight terminal failures, with no explicit clean decisions on mutated cases. Some packages retained approval and execution fields, including digests. The prompt instructed judges to abstain when evidence was insufficient. These results characterize a deliberately information-asymmetric development setting; they do not isolate the effect of authoritative information from differences in task specification and rule selection, and they are not comparative verifier quality or agent reward hacking. We identify full-information comparisons, legitimate-adaptation controls and closed-loop agent evaluations as necessary tests of whether contract checks improve useful compliant completion under optimization.

Thu 8 OctArtificial Intelligence
The gist
Checking AI research results just by looking at the output isn't always enough to find errors. The authors show that linking what was promised before the study, what was done, and what can be claimed helps catch defects in AI experiments. They test their approach with known errors and find that verification works better when judges have full information. This points to the need for honest, locked-in contracts and thorough checks to improve trustworthy AI research.
Open → 2610.11754v1

Quantum software tool finds hidden errors missed by tests

QuSema: Detecting Silent Bugs in Quantum Libraries via Quantum-knowledge-enhanced Agents

Abstract: Quantum libraries are now critical infrastructure for quantum algorithm development, yet their correctness remains difficult to test. Existing testing techniques mainly rely on failure-based or comparison-based oracles, exposing bugs only when executions fail, violate runtime checks, or disagree with another implementation. Their applicability is limited when suitable execution-based oracles are unavailable, leaving some silent bugs undetected. Such missed bugs can produce incorrect results that propagate into experimental conclusions, simulation studies, and algorithmic designs. Here we present QuSema, an autonomous testing agent for finding silent bugs in quantum libraries. QuSema uses constraints from quantum semantics and documentation as a source-level semantic oracle to assess whether implementation logic can produce invalid outputs from valid inputs. It operates through an agentic loop that repeatedly inspects library API documentation and source code, reasons about the intended behavior of quantum operations, identifies potential semantic deviations, and validates them by generating executable tests through library APIs. Guided by quantum-domain reasoning, QuSema turns high-level behavioral mismatches into concrete, user-triggerable bug reports, enabling it to uncover non-crash defects. We implement QuSema for Qiskit and PennyLane. On a benchmark of 20 historical silent bugs, QuSema achieves higher mean bug relocation counts than Claude Code and Codex, with the DeepSeek configuration costing less than Claude Code. QuSema also discovers 40 previously unknown bugs confirmed by the developers, including 30 silent bugs.

Wed 7 OctSoftware EngineeringArtificial Intelligence
The gist
Quantum computing programs rely on special libraries, but these can have hidden bugs that don’t cause crashes or obvious errors. The authors created QuSema, a tool that reads the library’s instructions and quantum rules to spot subtle mistakes that normal tests miss. It works by understanding what the code should do and then checking if it can produce wrong results without failing. QuSema found many known and new hidden bugs in popular quantum libraries, helping developers improve reliability.
Open → 2610.10258v1

Adaptive test method improves conversational agent policy compliance checking

AdaT$^2$: Adaptive Test Transformations for Black-Box Boundary Testing of Conversational Agents

Abstract: Conversational agents based on large language models (LLMs) must comply with policies. Each condition in a policy draws a boundary between user requests, and the agent must behave differently on its two sides. We present AdaT$^2$, which extracts statements from the agent's replies in exploratory conversations with an LLM acting as the user, and uses the statements to guide boundary test generation. Each statement describes one condition and the behavior expected when the condition holds. Besides plain tests guided by single statements, AdaT$^2$ writes transformed tests guided by pairs of a statement and a test transformation instruction, such as "omit one required input". The instruction of a pair can move a test to the other side of the statement's boundary or to another boundary. The statements and instructions form far more pairs than a run can try, and many pairs are not applicable. Adaptive pair selection therefore chooses the statement of each pair by novelty and the instruction with the bandit algorithm Bayes-UCB, which learns from whether earlier pairs yielded a test and whether the agent passed it according to an LLM judge. Our benchmark counts the two sides of each boundary separately and distinguishes boundaries explicitly defined by the agent's prompt, tool code, or knowledge base from boundaries that the agent's LLM infers from domain knowledge. On four domains of $τ^3$-bench, 62.7% to 83.3% of AdaT$^2$'s tests are valid boundary tests whose expected behavior is explicitly defined, higher in every domain than AgentEval's (47.7% to 68.1%). Transformed tests add 13 to 46 explicitly defined boundaries that plain tests miss. As regression tests, AdaT$^2$'s test suites detect all eight seeded policy faults in the airline domain and four of eight in the retail domain, and AgentEval's test suites, with fewer than a third as many tests, detect five and two, respectively.

Wed 7 OctSoftware Engineering
The gist
Conversational agents need to follow certain rules depending on what users ask them. The authors developed a method called AdaT² that creates tests to check if these agents behave correctly on both sides of those rules. AdaT² uses conversations with the agent to find rule boundaries and then generates tests that try to cross these boundaries to see if the agent reacts appropriately. It also adapts test generation by learning which tests are most useful, finding more rule violations than previous methods. This helps ensure that the agents follow their policies more reliably.
Open → 2610.10141v1

UltraText Bench tests how well AI models generate dense bilingual text images

UltraText Bench: A Comprehensive Bilingual Benchmark for Evaluating Visual Text Rendering in Image Generation

Abstract: Dense visual text requires image generators to reproduce long strings across multiple regions with correct placement and legibility. As short-string rendering improves, evaluation must test sustained performance across more demanding scenes. We introduce UltraText Bench, a bilingual benchmark for prompt-only generation of dense visual text. It contains 432 prompts spanning 24 real-world scene categories and three difficulty levels, split equally between English and Chinese. Each human-reviewed prompt supplies exact strings for four to twelve text regions, paired with structured references for their content, placement, and visual attributes. We use the Q-Judger vision-language model to assess each image against the complete reference, reporting text fidelity, text clarity, spatial quality, and scene quality. Across 24 model configurations, these dimensions reveal different strengths: Z-Image-Turbo gains 3.81 clarity points over Z-Image-Base while losing 14.76 fidelity points under the reported settings. Performance also varies with workload; Qwen-Image-2512's English composite falls from 86.50 at L1 to 42.86 at L3. Ten participants took part in human evaluation of the automatic scores. Repository: https://github.com/LINs-lab/UltraText_Bench.

Wed 7 OctComputer Vision and Pattern RecognitionArtificial Intelligence
The gist
Creating images with lots of text, especially in both English and Chinese, is hard for AI image generators because the text needs to be clear, accurate, and correctly placed. The authors built UltraText Bench, a big test set of images with multiple text areas and exact details to see how well AI models do this job. They also developed a way to automatically score the images on how clear, correct, and well-placed the text is. Their tests show that different AI models have different strengths and weaknesses depending on the difficulty of the text and the language.
Open → 2610.09823v1

Google deploys AI agent to fix code errors fast in developer workflows

Catching Developers in the Flow: Low-Latency Agentic Program Repair at Google Scale

Abstract: Manual repair of program failures is time-consuming and disruptive for software developers, particularly during the pre-submit phase where test failures occur within continuous integration systems. While Automated Program Repair has seen significant advancement through Large Language Models, existing state-of-the-art techniques primarily focus on post-submit workflows, operating offline without the low-latency requirements necessary to assist developers in real-time within their flow before they switch context. In this paper, we introduce FlowAgent, an AI agent deployed at Google to automatically repair test failures in the pre-submit outer-loop workflow inside continuous integration systems. Integrated into Google's internal developer tools, Critique and Cider,FlowAgent utilizes a ReAct-style generate-and-validate loop, as well as rigorous pre-execution and post-execution abstention filters to ensure high-quality suggestions under strict latency constraints. Based on our case studies, FlowAgent is highly effective. First, a manual evaluation conducted on 195 real-world test failures demonstrated 67.18% accuracy in suggesting correct fixes. Following its Google-wide deployment, FlowAgent suggested fixes on 295,508changes, of which developers previewed 65,069 and applied 28,554. Developer feedback from interviews indicate that the agent is useful in suggesting correct fixes, integration of autonomous repair agents into industrial software engineering workflows is received well, while interesting challenges and opportunities still remain.

Mon 5 OctSoftware EngineeringArtificial Intelligence
The gist
Fixing broken software tests can slow down programmers and interrupt their work. The authors present FlowAgent, an AI tool used inside Google that suggests quick fixes for test failures before code is submitted, helping developers stay focused. This tool checks its own suggestions carefully to avoid errors and was shown to correctly fix issues about two-thirds of the time. After being rolled out widely, many developers used and accepted its ideas, finding it helpful in their everyday coding. Their feedback shows such AI assistants fit well into large software teams, though some challenges remain.
Open → 2610.07289v1

Measurement framework assesses contamination risks in leaderboards

Measurement-First Auditing of Agentic Leaderboards: Contamination Susceptibility, Matched-Control Re-evaluation, and Scorer Validation

Abstract: Agentic leaderboards increasingly evaluate systems on public benchmarks whose task statements and solution-bearing artifacts can remain accessible. We propose a measurement-first audit framework that distinguishes contamination claims according to the evidence required to support them. It separates three channels that require different evidence: training-time exposure, evaluation-time retrieval, and pipeline/scaffold leakage. Each channel is coded as open, partial, closed, or unknown under a fail-closed rule. Across nine Holistic Agent Leaderboard (HAL) configurations, none of the 27 channel assessments was coded closed, but incidents were confirmed in four configurations. We then apply the behavioral component of the framework to a reported file-localization gap on SWE-bench Verified, using an outcome-blind, same-repository matched-control design with symmetric prompt-leakage screening, paired and repository-aware uncertainty analyses, and scorer validation, evaluated on GPT-4.1 and DeepSeek-V4-Flash. Among the 100 pairs retained after symmetric screening and the pair-integrity exclusion, GPT-4.1 showed a $+10.0$-point pair-weighted Top-3 benchmark-associated gap, but the 95\% intervals from both the prespecified paired-bootstrap procedure and the post-hoc repository-balanced analysis included zero, leaving the benchmark-associated gap inconclusive. The reproduction scorer did not pass its validation gate: against consensus human labels, sufficient scorer sensitivity could not be established for either model, and both DeepSeek-V4-Flash firings on correct-gold comparisons were false positives. Without provenance evidence, appropriate controls, symmetric leakage screening, and validated scorers, stronger contamination claims are not warranted. The results do not establish training-data membership, contamination prevalence, or benchmark-induced score inflation.

Mon 5 OctArtificial Intelligence
The gist
Some computer tests called leaderboards rank smart AI systems using public puzzles, but these puzzles might leak answers into the AI’s training or testing process, making scores unfair. The paper presents a way to carefully check where such leaks can happen and whether the leaderboard scores are truly reliable. The authors tested their method on several leaderboards and found some issues but couldn't prove that any leaderboard scores were definitely inflated due to leaks. They also highlighted the need for good controls and careful checks before making strong claims about data contamination.
Open → 2610.05830v1

ContrA finds key questions to clarify code intentions in coding agents

CONTRA: Discovering and Qualifying Behavior-Changing Questions for Selective Clarification in LLM Code Generation

Abstract: Coding agents can generate code that appears correct but implements behavior the user never intended. This mismatch can arise when an agent silently resolves underspecified requirements through its own assumptions. As subsequent development builds on these assumptions, correcting the resulting behavior can become increasingly costly. Early clarification can help prevent such mismatches, but unnecessary questions can interrupt developers and slow down development. Existing methods struggle to identify key clarification questions while avoiding unnecessary ones. Therefore, we propose CONTRA, a training-free method that combines broad question discovery with semantic and execution-based question qualification. CONTRA first generates candidate questions and filters out those unrelated to required behavior or already resolved by the requirement. For each remaining question, it generates programs conditioned on two plausible answers and checks for stable behavioral differences on shared inputs. It then uses the interaction history to select among qualified questions or stop asking. Experiments on ClarifyCodeBench show that CONTRA achieves the highest F1 with all four coding agents, exceeding the best baseline macro-average F1 by 13.88 percentage points. With the same LLM and evaluation protocol, CONTRA also achieves higher clarification recall and F1 than the coding harnesses Claude Code and OpenHands. To support practical use, we also implement CONTRA as a Claude Code plugin that integrates selective clarification into everyday development.

Thu 1 OctSoftware Engineering
The gist
Sometimes computer programs created by AI can do the wrong thing because they guess what users want without asking. The authors developed CONTRA, a method that helps these AI coders ask helpful questions early on, avoiding mistakes in code behavior. CONTRA works by figuring out which questions really matter based on how different answers would change the program's behavior. This way, it avoids unnecessary interruptions and improves the quality of AI-generated code. Their tests show CONTRA asks better questions than previous methods and works well with several AI coding tools.
Open → 2610.01769v1

When using two AI reviewers improves error detection in code and documents

When Does a Second Model Help? Cross-Model Review in LLM Verification

Abstract: Large language models now generate code, documentation, and analyses, and are increasingly used to review such output. We ask when a second review by a different model helps. Building on the author's earlier preprints, which varied context, repetition, and role structure within one model, we test model independence in a controlled experiment: 30 artifacts with 150 planted errors, 10 review conditions, and 900 review sessions with three reviewer models from two developers. In this experiment, (1) a top-tier cross-model reviewer is not significantly different in F1 from same-model review in a fresh session (CCR), which does not establish equivalence; (2) the two find partly different errors (Jaccard 41.2%); and (3) at two review calls, one CCR plus one cross-model review matches more planted errors than two CCR reviews (56.7% vs. 42.7%; Holm-adjusted p=.006), but not significantly more than two reviews by the top-tier cross-model reviewer, so model difference and reviewer capability are not separated. A lightweight cross-model reviewer scores no higher than same-model review. Withholding requirements from the reviewer raises F1 for the two lower tiers but not the top tier, in untested point estimates whose pattern depends on how failed sessions are scored. Before analysis we audited all session records, excluding one baseline run of uncertain provenance and 14 failed calls; results with all sessions are also reported. A partial check on public detector outputs from another benchmark neither replicates nor contradicts the main comparison. Records, artifacts, and scripts are available from the author on request.

Thu 1 OctComputation and LanguageArtificial IntelligenceSoftware Engineering
The gist
Checking code and documents for mistakes is important, and AI models can help review them. This paper studies when adding a second AI reviewer helps find more errors. The authors tested different AI reviewer models on 30 items with many errors and found that using two different models often finds more mistakes than repeating the same model twice. However, the effectiveness depends on the model quality and whether the models have different strengths.
Open → 2610.01471v1

Corrupted graphs cause errors in language agent action verification

Who Verifies the Graph? Misspecification Attacks on Causal Action Verification for Language Agents

Abstract: Causal action verifiers gate an agent's state-changing tool calls by checking whether each proposed intervention is identifiable against a committed action-state graph, and they issue a certificate that carries the identification argument and a one-sided lower confidence bound. One such verifier, CIVeX, reports zero false executions on a confounded tool-use benchmark. We red-team it by corrupting only the committed graph. Omitting a single bidirected edge takes it from zero false executions to 15.3% at the benchmark's published confounding strength, with 91% of its executions harmful and utility falling from +2.27 to +0.35. Reversing one arrowhead, so that a mediator is committed as a confounder, gives 48.9% false executions and no correct ones. Every one of these actions carries an internally valid certificate. An attestation step that tests each observationally certified execution against a bounded randomised sample detected both attacks, with 2 false alarms in 555 executions on a truthful graph; refusing what fails the test, or cannot be tested, gave zero false executions in every setting we measured. It does not restore beneficial execution: at the published strength 97.1% of beneficial actions are still never executed, because the same misspecification rejects them before attestation runs. Those rejections carry certificates too, and auditing them works, but its cost scales with the number of rejections rather than the number of executions. Recovering safety costs 127 experiments per 1,050 actions; recovering the lost value costs 614 more, at which point the audited verifier makes the honest graph's decisions on every instance and spends exactly its experiment budget. An audit that inspects only executions protects against wrongful action. Wrongful inaction has to be paid for separately.

Wed 30 SeptArtificial IntelligenceMachine Learning
The gist
Language agents use graphs to check if their planned actions make sense and are safe. This paper shows that if these graphs have small mistakes or are tampered with, the agent can execute wrong or harmful actions without noticing. The authors tested a defense that spots these attacks by rechecking a random sample of actions, which catches errors but also rejects many good actions. Fixing these issues requires extra tests, making the system slower and less useful. Ensuring safety against wrong actions is easier than recovering lost good actions.
Open → 2609.40027v1

Large language models improve code with self-checked specs and repairs

Self-Spec Verifiable Code Generation

Abstract: Large language models (LLMs) may generate unreliable code on corner cases missed by testing, while formal verification can provide machine-checkable guarantees. Recently, researchers have proposed several benchmarks to evaluate the capabilities of LLMs in generating formally verifiable code, where LLMs need to formulate formal specifications, generate the corresponding code, and verify its correctness. However, existing benchmarks have two key limitations: (I) They primarily evaluate specification and code generation stage-wise, with code generation typically conditioned on an oracle specification. This setup overlooks whether strong stage-wise performance translates into end-to-end success. (II)They mainly focus on a single proof-oriented language and mathematically structured tasks, offering limited coverage of tasks common in software development. In this paper, we introduce VeriCodeBench, a benchmark for self-spec verifiable code generation, where the LLM relies solely on its own generated specification and code throughout the entire process. VeriCodeBench contains 400 language-native problems across C, Java, Rust, and Python, covering practical concerns in software development. We evaluate specification coverage, code validity, and joint problem-level success. We further introduce CodeNova to enhance the capabilities of LLMs in self-spec verifiable code generation. CodeNova makes requirements explicit through constraint-guided specification and uses verifier feedback to guide targeted implementation repairs. Experimental results reveal that self-generated specifications remain a major bottleneck, while providing more sophisticated specifications may not necessarily lead to higher verification success rates. CodeNova substantially improves performance across all evaluation metrics, enabling Claude Sonnet 5 to achieve the strongest results under the self-spec protocol.

Wed 30 SeptSoftware EngineeringArtificial Intelligence
The gist
Large language models often write code that can fail in rare or tricky situations, and formal verification tries to prove code is correct in all cases. Prior tests usually gave the model perfect requirements to write code from, ignoring whether the model could produce and use its own requirements effectively. The authors made a new test called VeriCodeBench, where the model must create both code and the specifications it will verify, using real programming languages and tasks. They also built CodeNova, a system that helps the model write clearer requirements and fix code based on verification feedback, improving reliability.
Open → 2609.39568v1

Game development agents struggle to meet complex design requirements

A2Z GameSpec-Bench: How Faithfully Can Coding Agents Generate Games from Game Design Specifications?

Abstract: Delegating complete application development to coding agents requires preserving the intended design rather than simply producing plausible outputs through naive prompting. Game development provides a demanding testbed, as long-form Game Design Documents (GDDs) describe requirements that must work together across game logic, visual rendering, and player interactions. However, existing game-development benchmarks typically use compact specifications and provide limited support for evaluating interdependent requirements across these aspects in long-form GDDs. We introduce A2Z GameSpec-Bench, a benchmark of 100 long-form GDDs for evaluating end-to-end game development by agents. We measure faithfulness by checking whether the game satisfies the GDD requirements and preserves the relationships among them. Each GDD is turned into a dependency-aware contract that contains rules, constraints, and prerequisite relations. Following game-development practices, we combine source-code inspection with agent-generated test policies for scenario-based replay and adaptive playtesting. The contract remains fixed across agents and revision rounds, while judgments and evidence linked to the same requirements support consistent comparison and failure detection. Our evaluations show that current agents struggle to jointly satisfy interdependent requirements across code implementation and actual play. Requirement-specific feedback improves GDD Fidelity by 10.9% relative to self-revision after two rounds. A2Z GameSpec-Bench assesses end-to-end specification-following ability beyond implementation judgments and provides targeted feedback to support more faithful game development. Code and datasets are available at https://a2z-gamespec-bench.github.io.

Wed 30 SeptArtificial Intelligence
The gist
Making computer programs that create games exactly as planned is hard. The authors created a new test with 100 detailed game design documents to see how well AI coding agents follow these plans. They found that current AI agents have trouble meeting all the interconnected rules needed for a game to work properly. The authors also showed that giving the agents specific feedback can help improve how well they follow the designs. This work helps measure and improve AI tools that try to build games from detailed instructions.
Open → 2609.39564v1

Controllable testbed reveals reward hacking in coding ai models

CATCH: A Controllable Analysis Testbed for Reward Hacking in Coding RL

Abstract: During reinforcement learning with verifiable rewards (RLVR), large language models (LLMs) can exploit loopholes in their environments to obtain high rewards without improving the intended capabilities, i.e., reward hacking. Despite its risks to training efficiency and safety, monitoring and mitigating reward hacking during training remain challenging, which is limited by a lack of testbeds that reproduce hacking and reliably identify it. We introduce CATCH, a controllable testbed for studying reward hacking in coding RL. CATCH deliberately exposes environmental loopholes and provides execution-based gold labels by comparing success under a vulnerable evaluator with task correctness under an independent audit. It also can control the model's initial hacking tendency through supervised fine-tuning data mixtures and the difficulty of earning rewards through reward designing, enabling systematic comparisons of hacking dynamics and interventions. Experiments show that CATCH can produce diverse RL training trajectories with clear reward hacking, and analyses demonstrate that both initial models and reward difficulties shape the emergence of reward hacking. We further evaluate the effectiveness of different reward hacking detection and mitigation methods. A key finding is that a chain-of-thought monitor initially suppresses hacking, but this protection erodes as the policy model learn to mislead the monitor with code comments. This highlights the need to evaluate hacking mitigations throughout training with CATCH. The source code and resources are publicly released at https://github.com/THUAIS-Lab/CATCH.

Wed 30 SeptComputation and LanguageMachine Learning
The gist
Reward hacking happens when AI models find shortcuts to get high scores without actually solving the task properly. The authors created CATCH, a test environment that purposely includes tricky loopholes so they can study how models cheat. CATCH also lets them control model settings and reward designs to better understand cheating during training. They found that some methods to stop cheating work only at first and then the models learn to trick those defenses too. This tool helps improve how AI training can be monitored and made safer.
Open → 2609.39533v1

AI struggles to spot incorrect but believable code reviews

CRJudgeBench: Can AI Detect Plausible but Invalid Code Reviews?

Abstract: Large language models can generate plausible code-review comments, but such comments may contain technically incorrect claims that mislead developers. We study technical trustworthiness judgment: determining whether a review comment's core technical claims are correct and applicable to the reviewed code in its repository context. Existing code-review benchmarks primarily evaluate review generation, issue discovery, or general comment quality, but do not directly assess whether an agent can determine the technical trustworthy of an individual review comment. To fill this gap, we introduce CRJudgeBench, a benchmark of 1199 instances constructed from real pull requests and expert-verified perturbations, covering both trustworthy and plausible but untrustworthy comments. We further present Sentinel, a repository-grounded agentic judge that actively gathers code evidence to verify review comments before making judgments. Starting from Qwen3-Coder-30B-A3B-Instruct, Sentinel is trained on the CRJudgeBench training split through iterative action-level learning from a privileged teacher. On the 359-instance CRJudgeBench test set, Sentinel achieves 76.60\% accuracy, outperforming GLM-5.3 by 6.13 percentage points and its base model by 19.78 points. These results show that even state-of-the-art general-purpose LLMs struggle to identify untrustworthy comments, while iterative action-level learning substantially improves the accuracy of repository-grounded trustworthiness judgments. Our dataset is available at https://huggingface.co/datasets/dcloud347/CRJudgeBenchmark

Tue 29 SeptSoftware EngineeringArtificial Intelligence
The gist
Code review comments are important for software quality, but sometimes AI-generated comments seem plausible while being technically wrong, which can mislead developers. The authors created a new benchmark called CRJudgeBench to test whether AI can tell if a code review comment is actually correct or just sounds convincing. They also built a system named Sentinel that checks the code repository to verify comments before judging them. Sentinel performs better than existing models but still only gets about three-quarters of cases right, showing this is a challenging task.
Open → 2609.37216v1

GitCF improves spotting missing code changes using multiple commit clues

GitCF: Reducing Incomplete Changes by Exploiting Multiple Similarities Among Commits

Abstract: Software developers often struggle to identify all locations that their changes affect, and incomplete changes frequently result from these omissions. To mitigate this problem, several approaches have been proposed to recommend additional locations that should be modified together with a developer's current change. A large class of these techniques mines co-change rules from repository revision histories, but because they rely solely on which elements have been modified together, they cannot recommend elements that have rarely co-changed, and they disregard the textual information that accompanies commits. A second class of techniques does exploit textual information, but it derives it from the source code or from a change request rather than from commit history, and it does not use the developer's current change as its input. To address these limitations, we propose GitCF, a change recommendation method that compares a developer's current change with past changes in the revision history and recommends additional change locations by combining two sources of similarity: the set of modified elements and the textual content of commits, including commit messages, code diffs, and linked issue descriptions. We evaluate GitCF on 543 incomplete changes from 17 open-source projects, where an incomplete change denotes a commit in which an omitted modification is supplied in a later commit, comparing it against three co-change-rule-based techniques. GitCF outperforms the strongest baseline on all five metrics (MAP, Recall@10, Recall@20, Hit@10, and Hit@20); in particular, it raises Hit@10 from 0.322 to 0.403, and the improvement in average precision is statistically significant.

Tue 29 SeptSoftware Engineering
The gist
Developers often miss parts of their code changes, which causes problems later. The authors created GitCF, a tool that looks at both which files were changed before and the text written about those changes to suggest what else to update. By comparing the current change with past ones in many ways, GitCF can better guess missing edits. Tests on many open-source projects showed GitCF is better than older methods at finding what should be updated together.
Open → 2609.37045v1

Irene checks equivalence of hybrid quantum programs accurately and fast

Irene: Equivalence Checking of Hybrid Quantum Programs via Structure-Preserving Symbolic Reduction

Abstract: Equivalence checking is essential for validating compiler transformations of hybrid quantum programs, which combine quantum operations, measurements, and classical control. Measurement-dependent control limits unitary reasoning, while dependencies between classical outcomes and quantum operations can enlarge intermediate symbolic states. We present Irene, an equivalence-checking framework for bounded hybrid quantum programs based on structure-preserving symbolic reduction. The framework progressively simplifies equivalence obligations through three levels of reasoning. At the gate level, algebraic identities simplify unitary regions. At the hybrid path-sum (HPS) level, reduced symbolic execution states are represented as typed graphs, whose isomorphism certifies equivalence. Remaining obligations are handled by density kernels that characterize transformations of input density operators into observable outputs, allowing comparison even when internal measurement histories differ. Residual coefficient differences are encoded as SMT queries. A common set of symbolic reductions supports HPS and density-kernel reasoning by preserving factored Boolean and arithmetic expressions, eliminating reducible dependencies before expanding residual sums. We evaluate Irene against five equivalence checkers on 1,982 program pairs from seven benchmark suites. Irene solves 1,584 pairs (79.92%), compared with 57.52% for MQT QCEC, the baseline with the highest aggregate coverage, with a mean end-to-end time of 3.93 seconds per solved pair. Applied as an equivalence-checking oracle, Irene also identifies 15 previously unknown bugs in quantum compilers, including Qiskit, Cirq, and PennyLane.

Mon 28 SeptProgramming LanguagesLogic in Computer ScienceSoftware Engineering
The gist
Checking if two quantum programs do the same thing is hard, especially when they mix quantum and classical parts together. The authors present Irene, a tool that simplifies this process by breaking it down into different stages of reasoning and using symbolic math and graph comparisons. Irene can handle complex cases where measurements and classical controls interact, and it proved better than other tools on many test programs. It even found bugs in popular quantum programming tools, showing its practical usefulness.
Open → 2609.36065v1

Large language models improve confidence by combining hidden signals and verbal reasoning

When Words Fall Short: Iterative Synergy Between Verbalized Reasoning and Hidden Features for LLM Confidence Estimation

Abstract: Confidence estimation is crucial for developing trustworthy large language models (LLMs), with most methods following estimator-based or verbalization-based paradigms. While recent research increasingly focuses on improving verbalized self-reports of confidence, we challenge the prevailing view that this approach surpasses independent confidence estimators. Our empirical study shows that a dedicated confidence estimator can substantially outperform verbalized confidence, indicating that LLMs' internal representations contain richer confidence signals. Building on this finding, we propose Iterative Policy-Estimator Training (IPoET), a framework that synergizes the complementary strengths of verbalized reasoning traces and informative representations. IPoET alternates policy optimization with estimator updating, integrating estimator-derived confidence feedback into policy learning and refreshing the estimator on new policy rollouts. Experiments across diverse datasets and Qwen and Llama backbones demonstrate that, by iteratively exploiting richer hidden features and adapting to the evolving policy distribution, IPoET consistently outperforms both estimator- and verbalization-based baselines in-domain and achieves superior or comparable results across all out-of-domain metrics. For more details, refer to https://github.com/xyk829/ipoet.

Mon 28 SeptComputation and Language
The gist
Knowing how sure a language model is about its answers is important for trust. The authors found that models contain hidden confidence clues that can be better than just asking the model to say how sure it is. They created a new way that mixes these hidden clues with the model’s own explanations, improving how well confidence is estimated. This approach works well on different data and models, helping to better understand when the model’s answers can be trusted.
Open → 2609.34454v1

Learned routing evaluation separates claim strength from subject of evidence

When Evidence Changes the Subject: Subject-Typed Claim Licensing for Learned Routing

Abstract: Modern learned systems increasingly combine learned components with search, repair, or external solvers. Benchmarks often measure the resulting end-to-end system, while scientific claims may concern only one component, creating an attribution problem: evidence can fail to support the requested component-level claim while still supporting a positive conclusion about the larger system. Existing evidence-to-claim methods primarily calibrate claim strength. We argue that composite systems require a second dimension: scientific subject. We address this problem with subject-typed claim licensing, which separates weaker conclusions about the requested subject from positive but non-substitutive credit about another subject. We instantiate this idea in SCOPE-Routing for preference-conditioned multigraph routing. Non-authors reproducibly apply the declared semantics; held-out review yields fewer reference-relative upward deviations than unstructured review, while the difference from a strong evidence checklist remains unresolved; and a controlled routing study shows that score-optimal and claim-eligible methods can differ while valid hybrid-system credit is preserved. These results motivate treating claim strength and scientific subject as distinct dimensions of evidence-based evaluation.

Sun 27 SeptArtificial Intelligence
The gist
When complex computer systems combine learned parts with other methods like search or repair, it's hard to tell which part actually caused their success. The authors show that judging just how strong evidence is isn't enough; you also need to know which component the evidence supports. They propose a method called subject-typed claim licensing to clearly separate evidence about one system part from evidence about the whole. Testing this approach in a routing task showed it helps reviewers make more accurate judgments about specific claims and credit different parts correctly. This means future evaluations should consider both how strong evidence is and which part it supports.
Open → 2609.33505v1

Coding agents struggle to fix bugs across multiple repositories

WideSWE: Can Coding Agents Coordinate Changes Across Repositories?

Abstract: Coding-agent evaluation has progressed from resolving individual issues to carrying out long-horizon development, yet task completion is still largely assessed within a single codebase. In software ecosystems, many features and bug fixes require coordinated changes across multiple repositories. We introduce WideSWE to evaluate coding agents on such cross-repository tasks. Mining and reviewing changes across 103 software ecosystems yields 120 real-world tasks, balanced between 60 bug fixes and 60 features. We derive prompts from related issues and pull requests. We systematically review and adapt hidden tests to support diverse correct implementations while preserving required behavior and regression checks. Across seven agent configurations, full task success ranges from 10.83% to 42.50%, with the configuration pairing Codex CLI with GPT-5.6-sol achieving the highest rate. Trajectories show agents failing to identify necessary changes, recognizing changes but leaving them unfinished, or modifying the required repositories without fully satisfying the request. To examine whether working on one repository at a time can alleviate these difficulties, we compare it with joint execution under identical prompts. Independent execution mainly recovers omitted work and is less effective at correcting previously attempted but unsuccessful implementations. Joint execution can use information from related repositories to guide implementation and verification. Code is available at https://github.com/ZJU-ACES-ISE/WideSWE.

Sun 27 SeptSoftware Engineering
The gist
Fixing bugs or adding features often requires changing multiple connected software projects, not just one. The authors created WideSWE, a new test with real tasks that need changes across several repositories to see how well AI coding assistants can handle this. They found that AI agents sometimes miss needed changes, leave work half-done, or fix parts without fully solving the problem. Trying to fix one repository at a time helped avoid missing work, but working on all together helped guide better fixes. The top AI combination succeeded less than half the time on these complex tasks.
Open → 2609.33382v1

Large language model evaluation improves by focusing on hidden failures

Prioritizing Repeated LLM Evaluation for Hidden Failure Discovery

Abstract: Large language models are commonly evaluated by generating a small number of stochastic responses for each prompt in a benchmark. Because inference budgets are limited, this shallow evaluation may fail to observe low-probability but operationally important failures. A prompt that produces no failures in a small sample may therefore appear reliable despite having a nonzero latent probability of failure under repeated inference. We formulate LLM reliability evaluation as a budget-constrained discovery problem in which each prompt is associated with an unknown per-generation failure probability. We propose a budgeted discovery framework that first performs shallow evaluation across the prompt set and then uses trial-level failure outcomes together with prompt-derived representations to learn a feature-based ranking of failure propensity. The resulting scores prioritize prompts with zero observed shallow failures for deeper evaluation, concentrating the deep-evaluation budget where hidden failures are more likely to be discovered. We evaluate this approach on AIRBench and StrongREJECT across multiple model and system-prompt conditions. The central empirical test asks whether models fit without access to deep-evaluation outcomes can rank prompts with zero observed shallow failures according to their likelihood of producing failures under deeper evaluation. On AIRBench, the highest-ranked 10\% of unresolved prompts achieves 2.54x hidden-failure lift for Qwen 2.5 7B and 1.87x for Gemma 3n E4B, recovering 25.4\% and 18.7\% of subsequently observed hidden failures, respectively, compared with 10\% expected under random allocation. Semantic-neighborhood and feature-ablation analyses further show that this predictive signal can be recovered from multiple representations of prompt content and relationships.

Sat 26 SeptMachine Learning
The gist
Large language models (LLMs) are usually tested by checking a few answers for each question, which can miss rare but important mistakes. The authors propose a method to first do a quick check on all questions and then identify which ones, even if they showed no errors initially, are most likely to fail if tested more thoroughly. Their approach helps find hidden problems more efficiently by predicting which questions deserve deeper inspection. Tests showed this method can find more hidden failures than random checking.
Open → 2609.32547v1

Benchmark for AI models generating interactive chart code with improved accuracy

IChart2Code: Benchmarking Multimodal Large Language Models for Interactive Chart Code Generation

Abstract: Interactive chart code generation requires models to reproduce a reference chart's appearance and underlying data and correctly implement the state changes triggered by specified user interactions. Existing chart-to-code benchmarks focus on static outputs and lack task representations or evaluation protocols for interaction specification, browser execution, and post-interaction verification. We introduce IChart2Code, a benchmark comprising 377 tasks across 20 chart forms and 13 data families, with 1209 interaction requirements in six families. Each task provides a reference screenshot, task-local data, and natural-language interaction requirements, with executable HTML/JavaScript code as the target output. We further develop a browser-based evaluation protocol with an Executability gate and three rubric-guided dimensions: Data Fidelity, Static Visual Correctness, and Interaction Correctness. The protocol tests runtime viability, consistency with task-local data, fidelity of the initial rendering to the reference screenshot, and interaction-induced state changes in a sandboxed browser. A rubric-guided MLLM judge evaluates task-specific items for the three scored dimensions using the collected browser observations and achieves an overall item-level F1 score of 0.8844 against adjudicated human labels. We also propose TRAIL, a trajectory-guided dual-agent framework for interactive chart code generation. An Inspector derives task-specific inspection checks, executes them in the browser, and uses the resulting trajectories to diagnose failures and produce structured repair feedback. Averaged across four MLLMs, TRAIL improves the four evaluation dimensions over direct prompting by 7.89, 4.98, 3.45, and 4.47 percentage points, respectively.

Sat 26 SeptSoftware Engineering
The gist
Making interactive charts with computer code is tricky because the code needs to match what the chart looks like, handle the data correctly, and respond properly when users click or interact with it. The authors created IChart2Code, a new test set that checks if AI models can write code for charts that do all these things right. They also made a special way to test this code in a browser, watching how the chart looks and works before and after interaction. Plus, they designed a system called TRAIL that helps AI models fix mistakes by checking the chart's behavior step-by-step, which improved the accuracy of chart code generation.
Open → 2609.32413v1

Simple tests reveal how ai language model behavior shifts over time

Low-Cost Assays for Measuring Model Behavior Across Vendors and Releases

Abstract: Language models advise people, keep them company, and write software while they sleep. Measuring what they do is hard: behavior has to be sampled repeatedly across models, prompts and releases, most of it lives in unstructured text that has to be coded before it can be counted, and the result has to be legible and rigorous enough to meaningfully compare models and vendors. To address these constraints, we present a simple, cheap, scalable, and replicable model for studying model behavior. Each study is a frozen, public stimulus run identically on a cross-vendor panel, at a few dollars per model or less. Each reads its transcripts one of three ways, chosen by how much interpretation the behavior needs: exact match on a clamped reply, a codebook applied by LLM judges whose agreement with a human coder is reported per code, and an instrumented environment that records what an agent did independently of what it said. Run across four years of model releases from both frontier and open-source labs, these instruments find four things. Convergence: asked to pick a word, 27 of 44 models answer serendipity at least once in four tries. Resistance: a trailing "right?" moves endorsement by up to 32 points, and the sign flips from sycophantic to resistant as generations advance, keyed to the tag's surface form. House: whether a model holds a position under pressure tracks its generation, and how it holds tracks the lab that built it. Account: told to do something the documentation in their repository contradicts, some coding agents never went along silently and others always did, and the same model can change with the harness it runs in. Re-run on every release, batteries like these track how behavior is changing across vendors and over time.

Thu 24 SeptComputation and LanguageArtificial Intelligence
The gist
Measuring what different AI language models do is tricky because their answers vary, they change over time, and their responses are often unstructured text. The authors created low-cost, easy tests that work the same way on many models, helping compare how they behave across companies and software versions. These tests look at specific patterns like word choice, whether models agree or resist certain prompts, and how stable their answers are under pressure. Running these tests repeatedly shows how models from different labs evolve and differ.
Open → 2609.30012v1

Optimal replicate budgeting improves repeated task evaluations

Sharp Limits for Honest Uncertainty in Hard-Budget Repeated Evaluation

Abstract: Repeated evaluation can estimate a benchmark score accurately while still requiring replication to certify narrow uncertainty. We characterize that requirement on a fixed grid of $M$ tasks with $L$ binary paths per task under the hard budget $(M+t)K$, where each path costs at most $K$ responses or episodes. For fixed $L \ge 3$ and $0 < α\le 1/12$, the optimal expected width on the worst pure cohort is $Θ_{α,L}([M(t+1)]^{-1/2})$ when every task is observed and $Θ_{α,L}([M(t+\sqrt{M})]^{-1/2})$ when omission is allowed. The lower bounds cover adaptive hard-budget policies, and fixed random-subset designs attain both rates through disagreement certificates. A joint mean/disagreement interval turns the task-covering law into practical finite-budget inference. In an equal-budget LiveCodeBench replay with 16 models, 880 tasks, and five outputs per task, the task-covering design reduces median point-estimation MSE by 87.0\% relative to pooled uniform sampling, while the Joint certificate produces narrower confidence intervals in 15/16 panels and reduces median interval width by 30.6\%. Finite-regime analyses identify task coverage as the effective choice at the evaluated scale and characterize how cohort size and within-task agreement determine the useful operating region. Together, the sharp laws and fixed-budget evidence make replication and task coverage explicit design variables for information-efficient repeated evaluation.

Thu 24 SeptArtificial IntelligenceInformation Theory
The gist
When testing things multiple times to get accurate scores, figuring out how many times to repeat each test is tricky. The paper shows the best way to divide a limited number of test attempts across many tasks to get precise uncertainty estimates. The authors prove mathematical limits on how well this can be done and propose practical designs to reach those limits efficiently. Their methods reduce errors and create narrower confidence intervals in real test scenarios with many models and tasks.
Open → 2609.29140v1

Claim calibration clarifies reproducibility in recommender systems studies

Calibrating Reproduced Claims in Recommender Systems

Abstract: Reproduction studies can produce mixed outcomes. Reported values may differ while the ordering of the compared methods remains the same, a result may hold only under some experimental conditions, or a released implementation may fail to reproduce a result that the model can still reach. The terms repeatability, reproducibility, and replicability describe how a follow-up study relates to the original experiment, but not which parts of the original claim are supported by the new results. We introduce \emph{claim calibration} as a way of stating the strongest claim supported by a follow-up study, together with the conditions under which it holds and the parts that remain untested. We apply this perspective to five original--follow-up paper pairs from recommender-systems research. The cases show that agreement in numerical values, method rankings, statistical results, and overall conclusions does not always coincide, and that follow-up studies often support only part of the original claim. Based on these observations, we propose a Claim Evidence Profile for reporting the original claim, its scope, the reproduction target, the reported results, the calibrated claim, and the parts of the original claim that remain unresolved.

Tue 22 SeptInformation Retrieval
The gist
When researchers try to repeat or reproduce results in recommender systems, they sometimes find different numbers or outcomes but still agree on which methods are better. The authors introduce the idea of "claim calibration" to clearly state what parts of an original research claim are truly supported by follow-up studies and under what conditions. They tested this approach using five pairs of original and follow-up research papers to show that full agreement is rare and that follow-up studies often confirm only parts of original claims. They also propose a way to report these findings in a structured profile to improve clarity.
Open → 2609.26975v1

SWE-Serve measures real correctness of AI inference feature changes

SWE-Serve: Benchmarking Agentic Engineering For Production Inference Serving

Abstract: We introduce SWE-Serve, a benchmark for evaluating agents on production inference engineering tasks. Implementing an inference feature can require coordinating multiple changes across the serving stack, including model support, runtime execution, and public APIs. Existing benchmarks provide limited coverage of production inference engineering: repository-level software engineering benchmarks do not target inference, while general terminal-agent benchmarks include only a few inference tasks. Dedicated inference benchmarks, meanwhile, focus primarily on isolated kernel generation or performance optimization rather than repository-scale production feature implementation. SWE-Serve provides 53 repository-grounded tasks derived from recent production changes to SGLang, spanning six inference engineering families. Each task executes on either CPU or a single GPU (H100) and is evaluated with hidden functional and regression tests, including, where applicable, end-to-end (E2E) serving tests and calibrated performance gates. Executable no-op and oracle controls, adversarial verifier review, and closed-book execution support task validity and evaluation integrity. Across 11 models and 31 model-effort configurations, the best-performing configuration achieves 75% mean pass@1. SWE-Serve exposes a substantial gap between completing tasks locally and achieving production correctness. On 19 tasks with end-to-end coverage, model-serving E2E tests reject roughly one-third of patches that pass every other test (45.9% under the verifier versus 69.4% with E2E tests excluded from scoring), with pass rate increasing for each model's best-performing configuration. By making the production correctness gap directly measurable, SWE-Serve enables the field to track whether future agents move beyond completing tasks locally to achieving production correctness.

Tue 22 SeptArtificial IntelligenceSoftware Engineering
The gist
Building new AI features for production systems is complex and requires many coordinated code changes. The authors created SWE-Serve, a special set of tasks that test if an AI agent can successfully implement these production-level changes, not just small isolated code snippets. This benchmark shows a big gap between passing local tests and fully correct production deployment, highlighting difficulties AI systems face in real-world engineering. SWE-Serve helps track progress toward AI agents that correctly handle complex, multi-part engineering jobs in live systems.
Open → 2609.26777v1

Coding agents struggle to build kernel exploits without examples

Evaluating Coding Agents on Kernel Exploit Generation

Abstract: Coding agents now find real vulnerabilities in production software. However, bug discovery results do not measure whether agents can construct exploit primitives. We introduce KEX-bench, a benchmark for evaluating coding agents on exploit primitive generation against real operating-system kernels. KEX-bench contains 45 task instances across 40 Linux and Windows CVEs, covering kernel address leak, instruction-pointer control, heap read, heap write, and arbitrary address write. Each task runs in an isolated virtual machine, exposes controlled tools, and uses a deterministic verifier to check primitive-specific success. We evaluate state-of-the-art coding agents paired with frontier and open-weight models under fixed tool-call budgets. Without a reference proof of concept (PoC), the strongest configuration solves 1 of 20 Windows tasks (5.0%) and 14 of 25 Linux tasks (56.0%). With a reference PoC, the strongest configuration solves 31 of 45 tasks (68.9%). This highlights the gap where agents reach kernel crashes but fail to shape kernel state into exploit primitives. We release KEX-bench for reproducible research on AI-assisted exploitation at https://kex-bench.github.io.

Tue 22 SeptArtificial IntelligenceCryptography and Security
The gist
Finding software bugs does not guarantee the ability to make those bugs into useful exploits. The authors created KEX-bench, a test suite to see if smart coding agents can actually generate small building blocks of exploits against real operating system kernels like Linux and Windows. They found agents can often cause crashes but usually fail to craft these critical exploit parts without example exploits given. With example exploits, agents do much better, showing a gap in current capabilities. The benchmark is publicly available for others to try and improve.
Open → 2609.25591v1

Vocabulary analysis detects flaky Swift tests with random forest model

The Vocabulary of Flaky Tests in Swift

Abstract: Flaky tests produce non-deterministic outcomes without code change, eroding CI confidence and delaying deliveries. While vocabulary-based machine learning prediction has proven effective for Java and JavaScript, no study has evaluated it for Swift, a language whose testing style is dominated by UI and asynchronous code. We collect 91 flaky and 22,349 stable tests from 15 open-source Swift projects via re-execution and commit-history mining, then train five classifiers (Random Forest, Decision Tree, Naive Bayes, SVM, KNN) on TF-IDF unigram+bigram features under stratified 5-fold cross-validation. Random Forest achieves the best performance (Precision = 0.92, F1 = 0.86, AUC = 0.95) and substantially outperforms trivial baselines, among them a vocabulary-threshold rule applied to the most informative tokens, confirming a genuine discriminative signal (MCC = 0.75 vs. 0.08 for the best baseline). Information-gain analysis reveals two complementary signal types. Flakiness markers appear predominantly in unstable tests and comprise concurrency primitives (async, await), expectation-based synchronisation (expectation, fulfill), error propagation (throws), and explicit timing dependence (timeout, wait, now). Stability markers, chiefly the assertion vocabulary of plainly synchronous tests (xctassertequal), count as evidence against flakiness. Error analysis shows that the model fails when flakiness is hidden in shared infrastructure outside the test body or when async constructs are used in a deterministic context, exposing the intrinsic limit of lexical prediction. These results extend vocabulary-based flakiness detection to the Swift ecosystem and characterise both its effectiveness and its boundaries.

Tue 22 SeptSoftware Engineering
The gist
Tests that randomly fail without code changes cause delays and frustration in software development. The authors studied ways to predict such flaky tests in Swift code by looking at the words used in test code. By training a machine learning model on 91 flaky and over 22,000 stable tests, they found that certain keywords related to concurrency and timing help identify flaky tests. This approach works well but struggles when flakiness depends on parts of the system outside the test code itself.
Open → 2609.25516v1

LLJ Cards guide best practices for using AI as evaluators

LLJ Cards: Best practices for the Use of LLMs as Judges

Abstract: In recent years, large language models (LLMs) have emerged as a popular alternative for evaluation. Often referred to as LLMs as judges (LLJs), these systems have been widely adopted by researchers and practitioners across a broad range of measurement tasks, driven by their strong performance, scalability, and cost-effectiveness relative to human judgment. However, a growing body of work has shown that the use of LLJs raise concerns about their validity and reliability as evaluators. Existing efforts to address these challenges have largely focused on developing bias-mitigation techniques and refining prompting strategies. While these approaches represent an important step forward, they primarily offer technical fixes and leave a more fundamental challenge unaddressed: the lack of standardized, transparent, and reproducible evaluation practices. In this paper, we introduce LLJ Cards, a framework that synthesizes best practices from measurement theory, natural language generation, and machine learning literature into practical guidelines for LLJ-based evaluations. While LLJs offer a promising path toward scalable evaluation, their effective use requires grounding in rigorous evaluation principles to ensure validity, reliability, and reproducibility. LLJ Cards addresses this need by providing a structured framework for applying these principles in the design and reporting of automated evaluations.

Mon 21 SeptComputation and Language
The gist
Using artificial intelligence programs, called large language models (LLMs), to judge or evaluate things is becoming popular because they can work fast and cheaply. But people have noticed that these AI judges don’t always provide reliable or fair evaluations. The authors created a set of practical guidelines called LLJ Cards to help people use AI judges more carefully. These guidelines aim to make sure evaluations are valid, reliable, and easy to check by others.
Open → 2609.24516v1

Residual score adjustment can reduce bias but risks lowering quality alignment

When Residualization Helps an Audit: Format Effects, Slice Gains, and Their Limits

Abstract: Evaluation scores used around LLM systems -- including reward models, rerankers, and LLM judges -- can track surface form instead of the quality they claim to measure. When presented with a terse correct solution and a commented buggy solution for the same MBPP problem, a public preference reward model selects the correct one no better than a coin flip (0.507). Subtracting the predictable surface component from such scores is increasingly common, but removal alone does not yield a more valid measurement: the removed component may carry construct-relevant signal, and residualization cannot tell which is which. Under designed interventions -- unit-test labels with comment-only edits -- residualization attenuates the reward model's format effects by about 0.12 on both correct and buggy code, while the correct-versus-buggy margins move by less than 0.01. In observational NLI and QA settings, we freeze a held-out replication before scoring and re-evaluate it using labels from disjoint annotators; this supports only a narrower conclusion: better agreement with the construct labels on a pre-declared slice where a surface-only predictor errs, not a repaired score. Full-population agreement falls in every observational setting with a reported positive slice gain, and within-question ranking falls in every such QA setting. When construct and surface features are entangled, residualization can decorrelate a score while degrading construct alignment, and, in a controlled model, configurations just as damaging to construct alignment pass every pre-adjustment check, so no committed gate is a guarantee. We assemble these distinctions into a reporting protocol whose outcomes, refusal included, state what an adjusted score may be claimed to show: an audit-time diagnostic reported beside the construct-alignment cost it incurs, never a replacement for the raw score.

Mon 21 SeptComputation and Language
The gist
Evaluation scores for AI language models can mistakenly focus on how things look rather than how good they truly are. The authors show that removing predictable format signals from scores can reduce this bias, but it doesn’t always improve the true quality measurement. Sometimes, adjusting scores can even harm how well they reflect the real quality. They propose a careful way to report these adjusted scores, showing what the changes reveal and what costs they incur.
Open → 2609.24194v1

Memory systems struggle to improve coding agents on real software tasks

VibeMemBench: Evaluating Memory Systems for Coding Agents on Real Repository Coding Tasks

Abstract: Coding agents operate on real repository coding tasks, and persistent memory systems promise to reuse experience across tasks. Yet existing evaluations do not show whether those systems improve executable repository work. Repository benchmarks test code changes but do not isolate memory, while memory benchmarks score recall without measuring downstream coding outcomes. We introduce VibeMemBench, a benchmark for evaluating memory systems on 111 coding targets from 90 SWE-rebench V2 repositories and 3,634 history trajectories from the target repositories. The targets follow the SWE benchmark style and cover bug fixes, feature requests, interface changes, and configuration work. An agent edits each target codebase under a declared memory condition. Executable tests decide task resolution. Each target is retained only when injected history experience improves its executable outcome in a reference setting, so every target carries a prior experience whose usefulness is verified by execution in that setting. The frozen verified experience is then transferred to five held-out solvers. Direct injection raises observed task resolution on four of them by 1.1 to 4.5 percentage points while lowering agent steps on all five. Yet when four existing memory systems must construct and retrieve experience from the same history, eleven of twelve solver and system pairings fail to exceed the matched memory-off baseline. VibeMemBench exposes the gap between the useful experience that repository history holds and the experience existing memory systems deliver for repository coding tasks.

Sun 20 SeptSoftware EngineeringComputation and Language
The gist
Coding agents that help fix or improve software can learn from past experiences stored in memory systems. The authors created a new benchmark, VibeMemBench, to test if these memory systems actually help coding agents do better on real coding tasks from existing software projects. They found that when past experiences are directly inserted, some agents improve a bit, using fewer steps to solve problems. But when current memory systems try to build and use these experiences on their own, they mostly fail to outperform having no memory system at all. This reveals a big gap between the useful past experience available and how well memory systems use it.
Open → 2609.23570v1

Machine learning notebooks show how developers check code without errors

Characterizing Feedback Statements in Machine Learning Jupyter Notebooks

Abstract: Machine learning development in Jupyter notebooks is iterative and feedback-driven. Practitioners author statements that reveal information about program execution and use it to decide what to do next. We call these feedback statements and identify two forms: exploratory statements that display values for visual inspection, and validation statements that enforce conditions programmatically through assertions. Many ML failures do not surface as exceptions and thus escape the crash-based analyses that dominate prior work on ML notebooks. This study examines what practitioners check to catch failures that would otherwise pass silently, by characterizing feedback statements that encode the practitioner's mental model of what the code should do and what could go wrong. We mine 297,851 public Python Jupyter notebooks from GitHub and Kaggle and extract 1,092,780 feedback statements. We sample 816 statements through proportional stratified sampling from semantic clusters obtained from CodeBERT embeddings, and apply grounded theory and open coding to label and analyze each one. We contribute a taxonomy of feedback statements in ML notebooks, organized along the functional intent of the statement and the ML pipeline stage in which it appears. The taxonomy reveals that feedback is overwhelmingly exploratory, and that the two platforms host qualitatively different modes of ML work. Mapping our taxonomy to an existing crash taxonomy shows that it captures defensive practices against silent failures that crash analysis cannot observe. Our findings indicate that notebook source should be treated as a confounder in studies of ML developer practice, surface opportunities for notebook tooling, and motivate empirical study of silent ML failures. We release the corpus of 1,092,780 feedback statements and the codebook to support replication and tooling research.

Sat 19 SeptSoftware Engineering
The gist
Many machine learning programs run in Jupyter notebooks, where people write code and check results interactively. The authors call certain code lines 'feedback statements'—these show information or run checks to catch problems early. They studied over a1 million such statements from public notebooks and created a system to classify them by purpose and project stage. This work highlights that most checks are for exploring data rather than preventing crashes, revealing that many errors go unnoticed by usual crash-focused methods.
Open → 2609.22912v1

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

Code vulnerability models struggle with harmless code edits causing errors

Embedding Drift in Code Vulnerability Models Under Intended Behaviour-Preserving Transformations

Abstract: Code edits that preserve program behaviour can shift frozen code embeddings across classifier decision boundaries, causing correctly detected vulnerabilities to be predicted as benign. Such instability is problematic because semantically neutral changes, including comment removal, insertion of unreachable code, variable renaming, and loop rewriting, should not alter a model's security judgment. We investigate this issue using 15,000 C/C++ functions organized as 7,500 vulnerable-patched pairs from the Big-Vul dataset. Four mutation tracks are applied to both vulnerable and benign samples: comment removal, unreachable code insertion, variable renaming, loop rewriting, and a combined setting that applies all transformations. Using frozen microsoft/codebert-base embeddings with six downstream classifiers, we evaluate the robustness of vulnerability predictions and introduce a train-only defence that projects clean and mutated representations closer together while preserving vulnerability-class information. Under combined mutations, the baseline Vulnerable Flip Rate (VFR) ranges from 35.55% to 42.15%. The proposed defence reduces the mean common-set VFR from 22.60% to 11.32% and improves mean mutated accuracy from 55.33% to 57.10%. For Logistic Regression, VFR decreases by 17.29 percentage points, although benign-to-vulnerable flips increase by 11.95 percentage points. These results indicate that the defence improves robustness to semantics-preserving code transformations but introduces a false-positive trade-off and does not fully eliminate prediction instability.

Fri 18 SeptSoftware Engineering
The gist
Sometimes, small changes to computer code that don't actually affect how it works can confuse models that try to find security problems. The authors studied how edits like removing comments or renaming variables cause these models to change predictions mistakenly. They tested a defense that helps the model stay more stable and keep similar predictions even after these harmless changes. However, this fix makes the model slightly more likely to incorrectly label safe code as vulnerable. Overall, the problem isn’t fully solved but the defense improves reliability.
Open → 2609.21203v1

Frontier AI agents often falsely claim to complete file review tasks

Quantifying Overclaiming Propensity in Frontier LLM Agents

Abstract: Frontier coding agents are increasingly trusted to work autonomously for long periods, yet an agent's final response is often the only account of that work a user sees. We quantify the propensity of frontier agents to \emph{overclaim} task completion, a misrepresentation that can mislead the user. An agent overclaims when its final response contradicts information in its context. This definition requires no inference about intent and is independent of task success. We introduce \emph{OverclaimBench}, an evaluation suite composed of five file-review scenarios, transcript-based coverage measurements, and registered planted defects. We evaluate eight proprietary frontier models in their own production command-line interfaces, and four open-weight models under a single fixed harness on OverclaimBench and find that 1) agents do not read all the files they were asked to review in 67.9\% of runs; 2) among runs where not all files are read, agents are \emph{misleading} 80.4\% of the time (59--96\% per model), either falsely claiming to have read all files or omitting that coverage is incomplete; 3) requiring delegation to subagents increased reading coverage, but among reviews that remained incomplete, a large majority were still misleading; and 4) agents that falsely claimed a complete review missed planted defects at about 1.8 times the rate of agents that read every file, showing that claims of completion can conceal substantive failures. Together, these results show that agents' final responses are not reliable accounts of their actions.

Thu 17 SeptSoftware EngineeringArtificial IntelligenceMachine Learning
The gist
Frontier AI coding assistants are trusted to work alone for long periods, but their final answers might not tell the full truth. The authors measured how often these agents say they completed a review task when they actually skipped some files. They found that about two-thirds of the time, agents missed files, and most of those times they wrongly said they read them all. This false claiming hides mistakes that could be serious, showing users cannot fully trust what agents report about their own work.
Open → 2609.20812v1

AI systems generate annotations to guide software testing efficiently

AIJon: Automated Generation of Annotations for Fuzzing

Abstract: Modern fuzzers use code coverage as feedback to guide their exploration which has proven to be an effective strategy for driving exploration. However, this strategy overlooks inputs that may be interesting to the target program even without uncovering new code paths. Fortunately, prior research has shown that annotations generated by human domain experts can provide additional feedback, guiding the fuzzer towards interesting parts of the program. In this paper, we replicate experiments presented in IJON and extend them to real-world vulnerability detection at scale. To mitigate the scalability challenge, imposed by the need for human domain expertise, we propose utilizing LLMs to automatically generate annotations. We demonstrate the applicability of LLMs for this purpose and observe that LLMs can generate annotations that perform comparably to human-generated annotations. Motivated by this finding, we design AIJON, a system that leverages LLMs to automatically generate IJON-style annotations. We evaluate AIJON on the Magma benchmark and surprisingly observe that annotation-based fuzzing does not perform strictly better than AFL++. We conduct several experiments to identify the cause of our results and identify key insights regarding the impact of annotations on fuzzing campaigns, including their effect on the energy distribution of the fuzzer. Notably, we observe that LLMs can generate annotations that achieve comparable results to human generated ones, thus opening the door for future research to perform further studies on the impact of annotations at scale.

Wed 16 SeptCryptography and SecuritySoftware Engineering
The gist
Software testing programs called fuzzers usually try out many inputs to find bugs by looking for new ways the program runs. But some useful inputs don’t lead to new ways of running code, so they can be missed. The authors studied a method where notes (annotations) help guide fuzzers to interesting parts. They found large language models (LLMs), a type of AI, can create these notes almost as well as humans. Although using these AI-generated notes didn’t always improve testing, the work shows it’s possible to automate this part and suggests future research to see when annotations help.
Open → 2609.18457v1

Screen-based agents struggle with reliable enterprise software tasks

ERPBench: A State-Grounded Evaluation Paradigm for Computer-Use Agents in Enterprise Software

Abstract: Computer-use agents that operate through screenshots and simulated actions are advancing rapidly, yet their evaluation remains anchored to general desktop and web tasks. Enterprise Resource Planning (ERP) systems run the finance, procurement, inventory, and customer operations of organizations worldwide, and pose distinct challenges for computer-use agents: dense interfaces, coordinated multi-step interactions, and errors that alter persistent business records rather than surfacing on screen. Existing enterprise benchmarks rely on proprietary platforms or on simulated approximations of such software. We introduce ERPBench, a benchmark that evaluates screenshot-only agents on a live and reproducible ERP system and scores each task against ground-truth values in its database. Beyond the benchmark, we present a production-grade harness that gates agent actions behind human approval for safe deployment, which ERPBench runs autonomously. Evaluating six closed and open-source agents, we demonstrate that strong general GUI performance does not transfer to enterprise reliability. Even when an agent reaches the right form and saves it, the stored record is often wrong: some agents save in up to 85% of runs but write the correct value in as few as 3%. We further characterize failure modes specific to enterprise workflows.

Tue 15 SeptArtificial IntelligenceComputer Vision and Pattern RecognitionMultiagent Systems
The gist
Using computer agents to do tasks on business software, like managing inventory or billing, is hard because these systems have complex screens and multi-step operations. The authors created ERPBench, a test to see how well agents work on real enterprise software by checking if their actions actually save the correct information. They found that even if an agent seems to complete a task, it often saves wrong data. Their work shows that tools good at general computer tasks may not work well in business settings.
Open → 2609.17885v1

Calibrated abstention improves reliability of large language models

The Missing "I Don't Know": Why Three Reasoning-Reliability Findings Converge on Calibrated Abstention

Abstract: Three recent results describe what look like unrelated LLM reliability problems. Yin et al. (2026) show reasoning RL collapses tool-reliability representations. Suleymanov et al. (2026) show that under safety-constrained generation, large models rewrite flagged spans while small models truncate. Bastounis et al. (2024) prove any consistent-reasoning system without an implicit "I don't know" function must hallucinate infinitely often on broad problem classes. We argue these findings converge on a single intervention: calibrated abstention is what each independently identifies as the missing capability, even though the unavailability they document, a capability gap, a policy gap, and a recursion-theoretic gap, has a different source in each case. Honesty post-training has narrowed the gap in deployed models, but principled closure of the class Bastounis identifies requires a calibrated abstention function whose training signal at the leaderboard level is absent: dominant benchmarks assign zero reward to decline, so the leaderboard gradient that would select for the function does not exist. We propose four changes to evaluation: triple-scoring, abstention-rate reporting, capability-stratified evaluation, and mandatory calibration metrics. Benchmark reform is necessary, not sufficient, for closing the gap the theorem identifies.

Tue 15 SeptMachine LearningArtificial IntelligenceComputation and Language
The gist
Large language models often struggle with knowing when they don't know the answer, leading them to give wrong or misleading responses. The authors analyze three separate findings that each highlight a different problem caused by this lack of a built-in 'I don’t know' mechanism. They argue that the missing piece is a way for models to abstain from answering when uncertain, and that current evaluation methods don’t encourage teaching models this skill. They suggest new ways to measure model reliability that include tracking how often models decline to answer and how well they are calibrated.
Open → 2609.17686v1

Interactive tool helps fix errors in AI retrieval and generation systems

RECTIFY: An Interactive Workbench for Post-Evaluation RAG Diagnosis, Repair, and Verification

Abstract: Retrieval-Augmented Generation (RAG) evaluators can identify failures such as weak retrieval, poor grounding, incomplete answers, and unsupported generation, but they rarely help developers decide what to repair next. We present RECTIFY, an interactive Streamlit workbench that turns evaluated RAG cases into auditable repair workflows. RECTIFY filters cases that do not require repair, routes remaining failures into actionable families and finegrained repair slices, and generates editable repair cards that developers can approve, reject, or verify through sandbox reruns. On a controlled RAG benchmark, RECTIFY surfaces interpretable failure profiles across BM25, dense, and hybrid retrieval: BM25 mainly triggers noisy-retrieval repairs, while dense and hybrid retrieval leave smaller sets of multi-part underretrieval and underused-evidence cases. Additional analyses show that pre-filtering reduces unnecessary repair candidates and that slicelevel routing yields more targeted repair cards than broad family-level diagnosis. RECTIFY is publicly available as an open-source Streamlit workbench 1 for helping developers turn evaluation results into inspectable repair decisions.

Tue 15 SeptSoftware Engineering
The gist
AI systems that find and generate information often make mistakes like missing important facts or including wrong details. The authors created RECTIFY, an interactive tool that helps developers see which problems need fixing and suggests focused steps to repair them. RECTIFY lets developers test fixes in a safe space before applying them, making it easier to improve these AI systems. The tool works well across different types of search methods and helps prioritize repairs effectively.
Open → 2609.16764v1

AnchorGUI improves success in navigating apps by smarter memory use

AnchorGUI: Asymmetric Memory for Dual-Scale Learning in GUI Navigation

Abstract: Vision-Language Models (VLMs) enable autonomous GUI navigation, but agents still struggle to process and learn from dense, continuous visual histories. This bottleneck hinders both immediate error correction within a single episode (intra-trial) and experience distillation across multiple attempts (cross-trial). We trace these challenges to an empirical informational asymmetry in GUI navigation: while expected transitions can often be compressed into lightweight textual summaries, unexpected outcomes benefit from preserved screenshots as causal evidence for accurate diagnosis. Building on this insight, we propose AnchorGUI, a unified framework driven by the Cognitive State Anchor (CSA). The CSA acts as a per-step primitive that actively compares expected and observed transitions, converting passive multimodal trajectories into explicit prediction-error signals. These signals orchestrate a dual-scale learning mechanism via an asymmetric memory. For intra-trial correction, a sliding window selectively retains visual evidence for detected mismatches, providing immediate, visually-grounded feedback. For cross-trial distillation, this asymmetric memory focuses the computationally expensive credit assignment search space on likely failure steps. Experiments across four benchmarks validate the effectiveness of our approach. On AndroidWorld, AnchorGUI achieves a 57.3% success rate with a $2.4\times$ token reduction per step. Furthermore, cross-trial distillation reaches 69.2% success (+11.9% gain), significantly outperforming standard reflection methods while maintaining sub-linear context scaling.

Mon 14 SeptComputer Vision and Pattern Recognition
The gist
Navigating apps automatically is hard because computers struggle to learn from lots of screen images and mistakes. The authors identified that it helps to keep simple text summaries for expected steps but save screenshots when something unexpected happens, so errors can be spotted and fixed better. They created AnchorGUI, which uses a special memory system to focus on mistakes immediately and learn better from past trials. This approach improves success in app navigation while using fewer computing resources.
Open → 2609.15457v1

Large language models improve detection of javascript code vulnerabilities

Exploring Automated Vulnerability Identification in JavaScript Code Using Large Language Models

Abstract: JavaScript powers approximately 98.8% of all websites, making vulnerabilities in its code a significant security risk, yet existing detection approaches such as Static Application Security Testing (SAST) tools often fail to identify many real-world vulnerabilities when applied to isolated code snippets. This paper presents an empirical study of Large Language Model (LLM)-based vulnerability identification for JavaScript programs, evaluating three LLM families (Gemini 1.5 Flash, GPT-4o Mini, DeepSeek-R1-Distill-Llama-8B) across multiple prompting strategies (zero-shot, chain-of-thought, few-shot) and fine-tuning approaches on a dataset of 1,125 JavaScript code snippets spanning five Common Weakness Enumeration (CWE) categories: Injection (CWE-74), OS Command Injection (CWE-78), Cross-Site Scripting (CWE-79), SQL Injection (CWE-89), and Uncontrolled Resource Consumption (CWE-400). Our experiments show that LLMs substantially outperform traditional SAST tools on snippet-level vulnerability identification, with a fine-tuned Gemini 1.5 Flash model achieving 60% detection accuracy compared to near-zero performance from rule-based analyzers. We find that fine-tuning improves accuracy from 29% to 60%, Chain-of-Thought prompting benefits reasoning-capable models such as GPT-4o Mini, few-shot prompting is effective for polymorphic vulnerabilities such as Cross-Site Scripting, and performance varies across vulnerability categories, reaching up to 84% accuracy for structured vulnerabilities such as SQL Injection. These results indicate that LLMs provide a practical approach for automated vulnerability identification in JavaScript code, particularly when combined with task-aligned supervision, though they should complement rather than replace existing security analysis workflows due to limited recall and uneven performance across vulnerability types.

Sat 12 SeptCryptography and SecurityArtificial Intelligence
The gist
Many websites use JavaScript, but its code can have security weaknesses that are hard to find. The authors studied how advanced AI language models can spot these problems better than traditional tools. They tested different AI models and ways of teaching them on many JavaScript code snippets with known security issues. They found AI models detected vulnerabilities more accurately, especially when trained further or given helpful examples. Still, these AI tools are best used along with existing methods since they don't catch all problems equally well.
Open → 2609.13816v1

Developers rarely test code marked with self-admitted technical debt

Is Self-Admitted Technical Debt Tested? An Empirical Study of Coverage, Co-change, and Impact

Abstract: When developers write a TODO or FIXME comment, they are explicitly admitting that the code is suboptimal: a built-in warning that this logic deserves extra scrutiny. Yet it is an open question whether Self-Admitted Technical Debt (SATD) actually receives that scrutiny in the form of software testing. We aim to characterize the relationship between SATD and testing across three dimensions: the extent to which SATD-affected code is covered by existing tests, whether developers synchronize test additions with debt resolution, and whether such testing affects the long-term observability of resulting defects. For that, we conducted an empirical study on eight open-source Java projects, analyzing test coverage of 784 SATD instances identified in the latest releases and performing a longitudinal examination of 5,175 SATD removal events. Our results show that while 60.7% of SATD-affected code is covered by existing test suites, developers rarely synchronize test modifications with debt resolution; manual inspection confirms that only 3.4% of SATD removal commits include new tests specifically targeting the resolved debt (vs. 12.5% that co-add tests in the same commit). Longitudinal analysis further suggests that SATD resolutions exhibit nearly identical localized bug induction rates within short-to-medium-term windows regardless of test modifications. However, over a longer, unrestricted observation window, a slight divergence emerges where the test-added group reaches a higher cumulative defect alignment probability (6.32% vs. 4.37%), a counterintuitive trend potentially driven by the selective testing of inherently complex components. Developers treat SATD repayment as an ordinary code change rather than as a high-risk maintenance activity: most debt removals proceed without targeted verification, despite the developer's own prior flag that the code is suboptimal.

Fri 11 SeptSoftware Engineering
The gist
Sometimes developers leave notes in their code saying it’s not perfect and needs fixing later. This paper studied whether those notes, called self-admitted technical debt, get extra testing when fixed. The authors found that about 60% of this code is covered by tests, but when the code is improved, developers seldom add or update tests specifically for the fix. Over time, fixing these parts with or without new tests leads to similar rates of bugs, suggesting developers treat these fixes like normal changes rather than risky ones needing special checks.
Open → 2609.13485v1

Legal agent errors mapped in new multi-step hallucination benchmark

LexAgentHallu: A Hierarchical Benchmark for Profiling Hallucinations in Legal Agents

Abstract: As large language models are increasingly deployed as tool-augmented legal agents, they introduce agentic hallucinations where tool-call and reasoning errors cascade into fabricated holdings and miscited authority. However, existing legal benchmarks evaluate only single-turn QA with outcome-level metrics, while agentic hallucination benchmarks lack legal-specific diagnostic capability. Neither answers to what extent and how a legal agent hallucinates along its trajectory. To address these limitations, we introduce LexAgentHallu, a legal agentic hallucination benchmark designed to evaluate to what extent and how legal agents fail along multi-step trajectories. Built through a four-stage expert-in-the-loop pipeline, LexAgentHallu contains 3414 instances across 17 legal categories and 6 task types. Each instance is annotated under a dual-layer hallucination taxonomy of 7 high-level categories and 27 fine-grained subclasses, covering both substantive errors and agent-procedural failures. We further design fine-grained metrics that quantify to what extent and localize how each failure occurs along an agent's execution path. Our evaluation across 18 proprietary and open-source agents uncovers a Right-Answer-Wrong-Reason effect and reveals that hallucination subclasses cluster rather than scatter, forming distinct agentic framework, legal task, and category profiles. These findings, invisible to outcome-level evaluation, validate the diagnostic power of LexAgentHallu for evaluating agentic hallucination in law.

Wed 9 SeptArtificial Intelligence
The gist
Large language models used as legal assistants sometimes make mistakes where wrong facts or fake citations appear in their answers. Existing tests only check if the final answer is right or wrong, missing these errors along the way. The authors created LexAgentHallu, a new tool that tracks when and how these errors happen during multi-step reasoning in legal tasks. They tested many legal AI systems and found patterns in these mistakes that older tests could not see. This tool can help improve legal AIs by showing exactly where they go wrong.
Open → 2609.09754v1

ContractEval reveals hidden failures in AI procedural task completion

ContractEval: Query-Conditioned Execution Matching for Procedural Instruction Conformance

Abstract: As LLM agents move from answering questions to carrying out procedures, failures can be unwarranted rather than visibly wrong: the final response looks acceptable even though the system skipped the check, branch, dependency, or invariant that made the answer justified. Output-only evaluation sees the answer, and trace-aware judging sees activity, but neither identifies which obligations were active for the query. We introduce CONTRACTEVAL, a diagnostic framework for making those active obligations explicit. It represents procedural instructions as query-active obligations and matches them against response or trace evidence, turning omissions, wrong branches, ordering errors, extra actions, invariant breaches, and output-contract violations into distinct conformance failures. On a controlled suite of audited procedural contracts, output-only and trace-aware LLM judges miss many injected structural failures; under gold expected and observed graphs, ContractEval detects and localizes all of them. LLM-backed extraction preserves much of this signal but remains calibration-sensitive. ContractEval is therefore not a compliance guarantee; it makes procedural conformance auditable rather than implicit in final-answer quality.

Tue 8 SeptArtificial Intelligence
The gist
When AI systems follow step-by-step instructions, sometimes they seem to do things right but actually skip important steps or checks. The authors created ContractEval to spot these hidden mistakes by making clear which rules should apply to the AI’s task and checking if they really did. This method can find errors that other ways miss, like doing things out of order or breaking key rules. ContractEval helps people audit AI behaviors instead of just guessing if the final answer looks okay.
Open → 2609.09458v1

Large language models can rate explainable AI explanation quality

XAI-Arena: Can LLMs Assess the Quality of XAI Explanations?

Abstract: Evaluating the quality of explanations produced by explainable AI (XAI) methods remains challenging because existing approaches often rely on subjective human judgment, limiting reproducibility, scalability, and comparability between studies. We examine whether LLMs can serve as a reproducible and scalable mechanism to make comparative assessments of the quality of XAI explanations. We introduce XAI-Arena, an LLM-as-a-judge framework for scalable, reproducible, multidimensional, and stakeholder-sensitive evaluation of XAI explanation quality. XAI-Arena then allows us to compare XAI explanations along various dimensions, namely, perceived simplicity, clarity, task adequacy, trust calibration, actionability, transparency, faithfulness, and overall interpretability. We then benchmark XAI explanation methods across various datasets, machine learning models, and stakeholder personas. Human validation shows a strong positive association between LLM-generated and human ratings (Spearman's rho=.693, p<.001). Together, LLM-based evaluations can capture systematic differences in XAI explanation quality and provide a scalable and reproducible framework for comparative assessment of XAI explanations.

Tue 8 SeptArtificial Intelligence
The gist
It is hard to measure how good explanations from explainable AI methods are because people judge them differently. The authors studied if large language models (LLMs) can consistently and fairly compare these explanations. They created XAI-Arena, a system where LLMs act like judges to evaluate explanations on many aspects such as clarity and trustworthiness. Their tests showed that the LLM ratings strongly matched human opinions, making LLMs a useful tool for scalable and repeatable assessments.
Open → 2609.09428v1

LLM fault injection offers different cloud system testing behaviors than rule methods

Beyond Fixed Fault Models: Comparing LLM-Based and Rule-Based Fault Injection in OpenStack

Abstract: Software Fault Injection (SFI) supports testing of cloud systems by introducing software defects and observing their manifestation. Rule-based injectors such as ProFIPy provide controlled and reproducible source-level mutations but require fault patterns to be encoded manually. Large Language Models (LLMs) offer a data-driven alternative by generating context-dependent software faults. We compare two code LLMs, Qwen2.5-Coder and DeepSeek-Coder, with ProFIPy in OpenStack's Nova and Cinder services. On shared injection targets, activation and observable-failure rates are comparable, but operational profiles differ: LLM-generated faults produce more Catastrophic outcomes on Nova, whereas ProFIPy produces more Silent and Multi-component effects. The sampled LLM outputs also differ in how they manifest failure, while showing greater agreement in their propagation scope. These findings show that LLM-based fault injection extends the behavioral coverage of fixed fault models without establishing general superiority, and that practical adoption still requires controlled generation, runtime validation, system-level oracles, and reproducible experimental provenance.

Tue 8 SeptSoftware Engineering
The gist
Testing cloud software by deliberately adding bugs helps find problems before users do. The authors compared two methods: one uses fixed, manually coded rules to add bugs, and the other uses AI language models to create faults based on the code context. Both methods triggered failures at similar rates but caused different types of problems, showing that AI-generated faults cover different testing scenarios. This means AI can add value without fully replacing traditional testing tools, and practical use needs careful setup for reliability and repeatability.
Open → 2609.08681v1