Papers for

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

Neuron coverage criteria help diversity but not error detection in AI models

Unraveling the Efficacy of Neuron Coverage Criteria on Testing Large Language Models

Abstract: Neuron coverage criteria aim to assess test suite quality and guide test input generation, but their effectiveness for Transformer-based language models remains unclear. We evaluate six criteria, including four established and two recent criteria, across encoder-only, decoder-only, and encoder-decoder models. Our evaluation examines error-revealing capability, distribution diversity, sample fairness (category diversity), and guidance for test input generation. The results reveal uneven effectiveness. Erroneous samples provide only 0.32% additional coverage over noise samples, indicating limited sensitivity to adversarial errors. By contrast, coverage criteria effectively assess distribution diversity and sample fairness in 26 and 30 of 33 configurations, respectively. Incorporating neuron-wise coverage guidance into test input generation increases adversarial sample production by only 4.56%. These findings suggest that existing coverage criteria can serve as an antidote for assessing diversity but remain largely a placebo for revealing adversarial errors, particularly when used individually. Their practical value therefore depends on whether these limited benefits justify the computational overhead of testing large Transformer-based models. Our study highlights the need for more robust and efficient coverage criteria tailored to these models, with stronger error-revealing capability and greater value for test generation.

Thu 29 OctSoftware Engineering
The gist
Testing large AI language models to find mistakes is hard. The authors looked at methods called neuron coverage criteria, which measure how fully tests examine the model's workings. They found these criteria help check if test examples are varied and fair, but they don’t do well at spotting errors or problems the AI might make. Using these criteria to create tricky test inputs only slightly increases finding mistakes. This means current methods mostly help show test variety rather than catch AI faults.
Open → 2610.40234v1

Additional AI contexts do not boost software warning detection accuracy

Beyond QASecClaw: Agent Scaling, Verifier Feedback, and Evidence Reliability in Software Assurance

Abstract: Can additional specialist language-model contexts improve software assurance when deterministic tool evidence is already available? We study this question through five experiments spanning authored Java warning controls, OWASP Benchmark assessment, Defects4J test generation, SV-COMP assertion verdicts, and deliberately misleading evidence packages. The evaluated systems use Qwen2.5-Coder-7B-Instruct, with a 1.5B sensitivity analysis, and complete 13,638 model requests. On eight related development warnings, increasing the context count from 1 to 50 increases token use 49-fold without improving unsafe clearance. On 160 OWASP cases, model configurations trade clearance against unresolved outcomes; the ten-context arm assesses only 96 cases. On 32 SV-COMP tasks, raw verifier feedback raises mean correct model verdicts from 12.7 to 22.0, but also raises incorrect verdicts from one to seven; a JBMC-plus-JVM validation baseline returns 26 correct verdicts and six unresolved outcomes. On two sets of 120 evidence packages, models reject 70-100% of applicable counterexamples, while construction-specific scope checks classify every package correctly. No target defect is discovered in three Defects4J bugs, one unsupported by the test adapter. These descriptive results support deterministic evidence admission for the tested settings, while exposing limits of verdict aggregation, feedback interpretation, and the available evaluation coverage.

Tue 27 OctSoftware EngineeringArtificial Intelligence
The gist
This paper looks at whether adding more language-model-based analysis helps find software bugs better when traditional tools already give clear evidence. The authors tested different setups on software with known warnings, benchmarks, and verification tasks. They found that simply increasing the language model's context size used much more processing but didn’t improve bug clearance. Also, feedback from software verifiers helped somewhat but sometimes increased errors. The results suggest sticking to traditional, deterministic evidence methods works best in these tested cases, while AI methods need refinement.
Open → 2610.36947v1

Concentration of software complexity signals god classes and methods well

Complexity concentration as a god-class and god-method detector: a pre-registered test of a scale-free outlier rule against tool definitions and human labels

Abstract: God-class and god-method detectors mark concentrated complexity with a raw-scale threshold, a constant fitted on a corpus and re-fitted when the population moves. This paper pre-registers a test of a rule with no raw-scale constant: a unit is a god unit when its complexity is a robust outlier for its own codebase, a modified z-score of 3.5 or more. On 445 repositories in ten languages, 171 of them Java, and the 492 Java repositories of MLCQ, the rule is scored against PMD's GodClass, MLCQ's reviewers and two further definitions, with signal and cutoff chosen on half the repositories and read on the rest. LLM-written code may gather its complexity differently, the case for a detector that needs no re-fitting; the first question is whether one can match the scale of existing human-written code. The verdict is inconclusive on both populations, by different arms. The rule ranks PMD's god classes from the per-file maximum of cognitive complexity at per-repository AUCs of 0.916 and 0.908. On the main run it is, at its default, non-inferior within the margin to a cutoff tuned on the same population on recovery, and flags about twice as many non-god classes; on MLCQ it flags about as many and falls short of the margin on pooled recovery. Pooled, the raw value ranks god classes better than the per-repository score, and a cutoff carried between the populations lost almost nothing: both are human-written code on one scale, so the test is of matching that scale, not of surviving a shift. The rule's extra flags are small classes, just over half holding a method at PMD's own method-level threshold; its misses are large classes whose complexity is spread over many methods. Two readers of the source did not agree on what the extra flags are. Concentration finds where the complexity is; whether that place is a god unit is a question about coupling, which a registered follow-on study takes up.

Fri 23 OctSoftware Engineering
The gist
Detecting overly complex parts of software is important because they are hard to maintain. This paper tests a new way to find these so-called god classes and methods that doesn’t rely on fixed thresholds but looks for unusual complexity within each codebase. The authors found mixed results: their method matches some existing tools well but also flags different kinds of complex code units. Their approach shows promise especially because it can adapt without needing to be re-tuned for different projects, though more work is needed to confirm its usefulness.
Open → 2610.32466v1

Entity boundary and control roles show consistent proportions in Java files

The EBC Proportionality Law: A Recurring Architectural-Role Pattern Across Java Software

Abstract: Architectural roles describe how responsibilities are distributed within software systems. Entity--Boundary--Control (EBC) separates domain information, external interaction, and workflow coordination, but its proportions across diverse software remain unclear. This study examines file-level classifier-derived EBC proportionality in 1,556,985 Java files from 732 project instances and 78 functional categories. A classifier trained on labels generated by a large language model assigned one representative role per file. The labels were aggregated at project and functional-category levels and analysed using descriptive statistics and density-based clustering. The results show that Entity was less common than Boundary and Control. The dominant cluster covered 48 categories, 472 project instances, and 47.75% of classified files; its mean composition was 13.25% Entity, 42.65% Boundary, and 44.10% Control. The remaining 30 categories form one alternative and 11 smaller specialised patterns. Some selected variations were consistent with category responsibilities, while others received mixed support. Agreement with independent expert labels was limited (31.37% accuracy; macro-F1 0.31; Entity recall 13%). All reported proportions and clusters are therefore patterns in classifier-assigned roles, not verified architectural ground truth. Within this measurement boundary, the study provides a large-scale empirical reference of EBC distributions at the file level, and it documents the limitations of the automated approach.

Mon 19 OctSoftware Engineering
The gist
Software is often divided into parts with different jobs, like holding data, interacting with users, and coordinating actions. The authors looked at over 1.5 million Java files to see how these roles, called Entity, Boundary, and Control, appear together. They found that files with Boundary and Control roles are more common than those with Entity roles, with a typical mix across many projects. However, the method to assign these roles automatically doesn't always agree with human experts, so the results show general patterns, not exact truths.
Open → 2610.26392v1

Classification improves stepwise reasoning checks in language models

Stepwise Reasoning Verification: Don't Generate, Classify!

Abstract: Verifying the reasoning of large language models is increasingly important as they are applied to complex mathematical and scientific problems. Existing work focuses on large decoder models and reports mixed results for generative and discriminative verifiers, leaving unclear which paradigm is more effective and whether large models are necessary. In this work, we cast stepwise verification as a natural language inference task: the problem and partial solution prefix form the premise, while the next reasoning step serves as the hypothesis to be classified as entailed or non-entailed. This formulation enables error localisation at individual reasoning steps and direct comparison of encoder classification, decoder classification, and decoder verdict generation across model scales and annotation budgets. Across five reasoning datasets, a 0.15B encoder classifier outperforms most generative verifiers with up to 4B parameters. On identical decoder backbones, classification outperforms generation from 0.5B to 4B parameters and matches it on the strongest 7B backbone---reaching comparable performance with roughly one tenth as many annotated problems. Our findings establish classification as a parameter- and data-efficient approach to stepwise verification and show that strong verification does not require large generative decoders.

Sun 18 OctArtificial Intelligence
The gist
Checking the reasoning of large language models is important when they solve math and science problems. The authors find that instead of generating next steps, it works better to classify whether each new reasoning step logically follows from the previous steps. They test this idea on several datasets and show that smaller models using classification can outperform much larger models that generate answers. This means verifying reasoning can be done more accurately and efficiently without huge models.
Open → 2610.25441v1

Calibration challenges limit reliability of deep code models

Beyond Confidence: Rethinking Uncertainty Calibration in Deep Code Models

Abstract: Deep learning models have shown significant promise in code-related tasks. While confidence calibration techniques have been proposed to improve model reliability, their effectiveness in real-world tasks with strict accuracy requirements remains uncertain. In this paper, we investigate two key questions: first, whether existing measurement metrics, including confidence scores and uncertainty metrics, are effective for guiding selective prediction; and second, whether existing calibration techniques can improve these metrics to better identify cases where model predictions are likely to succeed or fail. We conduct a systematic study on defect prediction and vulnerability detection using seven code models, evaluating thirteen uncertainty signals and three widely used post-hoc calibration methods. Our analysis reveals three major findings: (1) even strong uncertainty signals can remain poorly calibrated and provide limited separation at the high-confidence end, constraining selective prediction in practice; (2) standard post-hoc calibrators often improve calibration scores but do not consistently translate into better selective prediction behavior; and (3) commonly used calibration metrics can disagree with selective prediction performance, underscoring the need to evaluate both jointly. Moreover, our findings motivate a decision-oriented view of reliability in deep code models, where calibrated scores must be evaluated together with selective-prediction quality and retained-region risk before they can support accept--defer deployment.

Thu 15 OctSoftware Engineering
The gist
Deep learning models are used to analyze computer code, but knowing when these models are likely right or wrong is tricky. The authors studied if current ways to measure uncertainty and adjust confidence actually help decide when to trust model predictions or not. They found that these methods don’t always give clear guidance, especially for the most confident predictions, making it hard to skip uncertain cases reliably. This means we need to think differently about how to assess and use model confidence to improve decision-making in code analysis tasks.
Open → 2610.21248v1

Tool finds energy use changes in software updates quickly

Systematic Detection of Energy Regressions in Software Version Histories

Abstract: Context: Green software engineering is emerging as a crucial response to the rising energy impact of information technology, especially in continuous development. However, challenges remain in devising automated methods to efficiently identify energy regressions across commits. In particular, little effort has been put into automatically detecting regressions at the commit level by identifying statistically significant changes in energy consumption. Objectives: This paper presents EnergyTrackr, an approach for detecting energy regressions across multiple commits. Methods: We empirically evaluated EnergyTrackr on 1,932 commits from five Java projects, assessing its ability to identify significant energy changes. We also compared a straightforward linear algorithm that analyzes the entire commit history with a more efficient dichotomous search algorithm. Results: The evaluation demonstrates the effectiveness of EnergyTrackr in identifying significant energy changes across commits. Our findings highlight the efficiency of the dichotomous algorithm in uncovering overall software energy trends, achieving results comparable to the linear approach while reducing resource consumption and processing time. Conclusion: We expect EnergyTrackr to help developers accurately monitor energy regressions and improvements in their projects and optimize their source code to reduce software energy consumption.

Wed 14 OctSoftware Engineering
The gist
Software updates can sometimes make programs use more energy without the developers realizing it. The authors created a tool called EnergyTrackr that checks many versions of software to spot when energy use goes up or down significantly. They tested this tool on thousands of software updates and found that a fast checking method works nearly as well as a slower one but saves time and computing power. This can help developers fix software to make it more energy efficient over time.
Open → 2610.19895v1

Neural networks improve file to module mapping in software projects

When Does the Dependency Graph Help Code-to-Architecture Mapping?

Abstract: Architectural technical debt arises when a system's implementation drifts from its inten ded modular decomposition, while the mapping between source files and architectural modu les is missing, incomplete, or costly to maintain manually. We formulate code-to-archite cture mapping as semi-supervised node classification over a directed multi-relational de pendency graph, with files as nodes, typed dependencies as edges, and lexical features d erived from code identifiers and directory layout. Starting from a small labeled sample, an iterative self-training procedure expands the mapping to the remaining files. We com pare a graph convolutional network (GCN), a graph attention network (GAT), and a graph-f ree multi-layer perceptron (MLP), using identical features and training procedures for t he learned models, against a Naive Bayes reference. Across 100 runs on ten open-source J ava and C/C++ systems, all three neural models outperform the reference on both F1 metri cs. GAT achieves the highest averages of system-level median macro and micro F1, at 83.5 and 92.2, respectively, whereas MLP remains competitive or superior on several systems. On Chrome, the largest system with 18,343 files, GAT and GCN exceed MLP by 22 and 19 ma cro-F1 points, respectively, and have substantially fewer persistently misclassified fil es. Connectivity and homophily are associated with where neural message passing helps, w hile multi-relational aggregation outperforms a single merged edge type on every system for both GCN and GAT. A follow-up study finds that several model rankings depend on the training seed, qualifying smaller advantages without removing the large graph benefit ob served on Chrome.

Wed 14 OctSoftware EngineeringMachine Learning
The gist
Software projects often get messy over time, with files not clearly belonging to parts of the system as originally planned, making it hard to manage the system's architecture. The authors studied how machine learning, especially graph-based neural networks, can help assign files back to their architectural modules by looking at how files depend on each other and other clues. They tested several kinds of models across many real software projects and found that including the file dependency structure helps most for big, well-connected projects. Different models worked better in different cases, but overall, using the graph of file dependencies improved the accuracy of mapping files to their intended architectural parts.
Open → 2610.19769v1

Verification issues cause failures in multi-agent proof searches

Viva La Vida: Verification and Accumulation Failures in Multi-Agent Proof Search

Abstract: When an agentic prover works on an open problem, there is no proof assistant to fall back on: its verifier and lemma library are ultimately language models judging model outputs. We instrumented such a system end to end and analyzed $51{,}754$ traced observations across three full runs ($186$ hours, \$$5{,}694$). We find three connected failure modes. First, the three-model verifier requires unanimity and treats parse or API failure as non-approval; in $10$ of $12$ verification events, one member returned no parseable output or an API error, making acceptance arithmetically impossible without surfacing an error. Second, when the ensemble did function, one verifier approved $3$ attempts that GPT rejected, each claiming to resolve the open problem; a single-verifier design would therefore have announced a solution three times. Third, because nothing could be approved, every review was a refutation, yet the lemma extractor mines reviews as well as proofs: $24$ of $93$ lemmas ($26\%$) were extracted from rejected arguments with their refutational context removed. Taken together, these findings show that without external verification, supervision is itself a critical trust boundary: systems must distinguish abstention from rejection, preserve useful disagreement, and preserve the provenance and polarity of information before it becomes future context.

Sun 4 OctComputation and LanguageArtificial IntelligenceMultiagent Systems
The gist
The paper studies an automated system where multiple AI models work together to prove difficult problems. It finds that the system often fails because the verifiers disagree or fail to parse results correctly, preventing any solution from being accepted. Sometimes one verifier approves a wrong proof that others reject, showing that relying on a single verifier would cause false successes. Also, even rejected attempts yield useful information that the system extracts and reuses, but this requires careful handling to keep track of the disagreement and context. The authors highlight that such systems need better ways to handle verification errors and preserve useful disagreements to improve trust and future performance.
Open → 2610.04829v1

Redundant checks in satellite data pipelines can share hidden errors

Independent Verification Paths Are Not Independent: A Case Study of Common-Mode Failure in a Satellite Catalogue Pipeline

Abstract: A common safeguard for a data pipeline is redundant computation: derive each published number by two routes built on different technology and refuse to exit when they disagree. We report one such gate failing, in a cross-catalogue integrity study of two open registers of Earth-orbiting objects. A gate comparing a set-based Python path with SPARQL queries over the emitted RDF graph printed ALL CROSS-CHECKS AGREE on seven counts. Three were wrong, one overstated more than fourfold (932 against 220). Both paths imported the same constants, which encoded a misreading of the source's status vocabulary, so the error was common-mode and the gate could not see it. We give the mechanism, an object-level ledger reconciling every figure, and three checks that go back to the source's documentation, measured on the defective code and on its correction. We then checked that correction against each object's phase history, held in a source file the pipeline never read. The correction was also wrong: 42 of its 261 disagreements are artefacts, and none of our three checks flagged them. Finally, in a controlled replication with three pinned models and tools disabled, 72 of 75 paths generated on request as independent checks computed the defective count, 29 of 30 even when the prompt carried the source's own definitions of the codes. The evidence is one pipeline and one defect family. Within it, redundancy verified implementation, and the errors that reached publication were errors of meaning.

Tue 29 SeptSoftware EngineeringArtificial IntelligenceDatabases
The gist
This paper reveals that double-checking satellite data using two different computer methods does not always catch mistakes. The authors studied two ways of verifying satellite catalog numbers and found that both made the same wrong assumption, so all checks agreed even when the data were wrong. They traced the problem to shared misinterpretations and showed that even fixing the code did not fully solve it. This shows that some errors are about the meaning of data, which redundancy alone can miss.
Open → 2609.37603v1

Model token weighting method improves math and code tasks

Rethinking Token Reweighting for SFT: Suppress, Reverse, and Extrapolate Learned Features

Abstract: Supervised fine-tuning (SFT) learns most aggressively from tokens that the model deems least likely. This helps acquire new behaviors, but also amplifies noisy or conflicting supervision and can overwrite useful pretrained knowledge. Through a unified policy-loss view, we revisit existing token-reweighting methods and show that they assign nonnegative coefficients to demonstrated tokens. Consequently, they can suppress or amplify supervised updates, but cannot reverse harmful features once learned. Moreover, larger training weights do not amount to feature extrapolation, since they change the optimization trajectory rather than scale a fixed SFT direction. We argue that reversal and extrapolation require a stable reference frame defined by a fixed SFT delta. Motivated by this, we propose SCALE (Selective Control of Adaptation via Local Entropy), an entropy-guided adaptation-strength-control method that freezes the pretrained model and the SFT delta and learns bounded token- and module-specific gates by minimizing predictive entropy alone. These gates suppress, reverse, or extrapolate frozen SFT features according to their alignment with entropy reduction. Across Qwen2.5-Math-1.5B, Qwen2.5-Math-7B, and Qwen3-4B-Base, SCALE achieves mathematical-reasoning averages of 37.84, 43.60, and 36.57, exceeding the strongest corresponding baselines while remaining competitive on general-retention benchmarks. It also attains the best average code-generation performance across HumanEval, HumanEval+, and MBPP for all three models. These results suggest that effective SFT correction can benefit from controlling how already learned residuals are used, rather than only modifying how they are learned.

Sun 27 SeptComputation and Language
The gist
Fine-tuning language models involves teaching them to pay attention to certain words more than others, but this can sometimes reinforce mistakes or erase useful knowledge. The authors studied how existing ways of weighting tokens during training can only increase or decrease importance but cannot undo harmful behavior already learned. They introduced SCALE, a method that controls these learned features more precisely by selectively activating or suppressing parts of the model based on uncertainty signals. This approach helps models perform better at math reasoning and code generation while keeping general knowledge intact.
Open → 2609.33463v1

Language models identify code style not author identity in zero-shot tests

Style, Not Self: Surface Cues Explain Zero-Shot Code Attribution by Large Language Models

Abstract: If a language model can recognize code it wrote, it may favor that code as a judge, and instances of one model monitoring each other could collude. We test this zero-shot on current commercial models. Five LLMs generate solutions to MBPP, HumanEval, and DS-1000, seven more to MBPP, and models act as evaluators in four tasks: picking their own solution from a pair, judging whether a single solution is their own, identifying which of two solutions a named model wrote, and judging quality blind. In the single-solution task, balanced accuracy is 49-58% for all 15 model-benchmark combinations, while raw accuracy (38-67%) mostly reflects how readily a model claims authorship. In the pairwise task, accuracy across 14 evaluator-opponent combinations correlates at r=0.93 with how often the evaluator's solution is longer. Attribution to a named model succeeds on some pairs and is consistently inverted on others. A rule-based normalization that strips docstrings, comments, type hints, and local names preserves Pass@1 and leaves ten of twelve re-tested results at chance; the other two follow a length difference it leaves, although a trained classifier still separates most normalized pairs. Claude Haiku's self-preference also disappears. We recommend reporting balanced accuracy, heuristic baselines, and label consistency.

Thu 24 SeptArtificial IntelligenceComputation and LanguageSoftware Engineering
The gist
Sometimes computer programs try to guess if a piece of code was written by themselves or another program. This study found that large language models don’t really recognize their own code but instead rely on surface details like length and style. When these obvious clues are removed, the models perform no better than guessing. The authors suggest using balanced accuracy and simple baseline tests to report these results more clearly.
Open → 2609.30048v1

SKstars combines zero-shot and adapted models to spot image hallucinations

SKstars at SHROOM: Visions Agreement-Guided Ensembling of Zero-Shot and LoRA-Adapted Vision--Language Models

Abstract: This paper describes the SKstars submission to SHROOM-Visions 2026, a shared task on fine-grained hallucination detection in large vision-language model outputs. The task requires systems to identify hallucinated character spans, assign hallucination categories, and provide confidence estimates for their predictions. Our approach combines zero-shot predictions from Qwen2.5-VL-72B-Instruct with those of a LoRA-adapted Qwen2.5-VL-7B-Instruct model. The outputs of the two models are integrated through a lightweight ensemble procedure, followed by span refinement and confidence adjustment. We evaluate the main system components on a small internal development subset and report the performance of the submitted system on the official English test set. SKstars achieved a Cor+Lbl score of 0.2902, ranking 15th among 29 teams, and obtained Cor and IoU scores of 0.3642 and 0.3151, respectively, ranking 18th on both metrics. The results show that combining a large zero-shot model with a smaller adapted model provides a practical framework for multilingual and fine-grained hallucination localization, while also highlighting the difficulty of transferring development-set improvements to hidden test data. Code and predictions: https://github.com/aliathar1401/SK-Stars-shroom-visions-2026

Mon 21 SeptArtificial IntelligenceComputer Vision and Pattern Recognition
The gist
Sometimes, AI models that describe images make mistakes called hallucinations, where they say things that aren't actually in the picture. The SKstars team built a system that uses two different AI image-text models working together to catch these mistakes more accurately. They combined a very large model that works without specific training and a smaller model fine-tuned for the task, and then carefully merged their outputs. Their system ranked in the middle among many teams, showing this method works but also that it's hard to improve much on hidden test data.
Open → 2609.24198v1

Machine learning finds swapped arguments in Python code without full context

Detecting Argument-Swap Bugs Using Context-Enhanced Code Representations

Abstract: Names of source code elements convey rich semantic information and have been widely used in software engineering tasks such as bug detection, code completion, type prediction, and code classification. Prior studies exploit lexical similarity between method arguments and formal parameter names to detect bugs caused by incorrectly ordered arguments, typically relying on establishing mappings between method calls and their corresponding definitions. However, such mappings are often difficult to obtain in dynamically typed languages like Python. In this paper, we present BugProbe, a learning-based approach for detecting incorrectly ordered arguments in Python method calls that does not require call-to-definition mappings. Our approach leverages multiple sources of contextual information, including local context and argument usage context, and combines name-based similarity with machine learning to construct expressive representations of method arguments. We collect a new dataset of 132,739 Python source files from the top-1,000 starred GitHub repositories, yielding 3,371,244 synthetic training examples, and contribute a curated benchmark of 55 real-world argument-swap bugs manually verified from commit histories. We evaluate our approach on this dataset and show that it achieves high accuracy and consistently outperforms a state-of-the-art baseline across standard evaluation metrics. These results demonstrate that effective detection of argument-ordering bugs is possible without relying on explicit call-to-definition resolution, making the approach well suited for dynamically typed language settings.

Tue 15 SeptSoftware Engineering
The gist
Sometimes programmers accidentally swap the order of inputs when calling functions, which can cause bugs. The authors created a method called BugProbe that uses machine learning to spot these swapped arguments in Python code, even when it's hard to find out which function is being called. They trained BugProbe with lots of example code and tested it with real bugs found in popular projects, showing it works better than earlier methods. This approach helps find bugs in dynamically typed languages like Python, where traditional methods struggle.
Open → 2609.17844v1

Adversarial learning improves c to rust translation quality

Translator vs. Challenger: Adversarial Agentic Learning for C-to-Rust Translation

Abstract: C-to-Rust translation remains challenging due to the substantial semantic gap between the two languages. Recent experience-enhanced LLM translators improve translation quality by learning reusable insights from prior failures and repairs. Yet learned insights do not automatically constitute reusable translation knowledge: derived from sparse, program-specific traces, they often contain missing conditions, narrow applicability boundaries, or overlooked corner cases. This limits their robustness and generalizability in new translation scenarios. We present TRAIL, an adversarial agentic learning framework for robust C-to-Rust translation. TRAIL employs two collaborating agents: a Translator that derives candidate insights from translation failures and accepted repairs, and a Challenger that actively searches for weaknesses, gaps, and boundary cases through adversarial challenges. To improve the robustness of individual insights and the completeness of insight collections, TRAIL performs adversarial learning at two levels. Individual-insight adversarial learning repeatedly stress-tests each insight to refine its applicability conditions and constraints, while compositional insight adversarial learning strengthens groups of related insights by exposing conflicts, gaps, and uncovered corner cases. By challenging insights and their compositions with executable counterexamples, TRAIL transforms trace-specific experience into robust, reusable, and generalizable translation knowledge. We evaluate TRAIL on two project-level benchmarks, CRUST-Bench and SmartC2Rust-Bench. Compared with the strongest LLM-based baseline, TRAIL achieves average relative improvements of 23.1% in syntax accuracy and 15.9% in semantic accuracy. Furthermore, the adversarially refined insights transfer effectively across benchmarks, demonstrating strong generalizability across diverse C-to-Rust translation tasks.

Mon 14 SeptSoftware Engineering
The gist
Translating code from the C programming language to Rust is difficult because they work very differently. The authors created a method called TRAIL, which uses two smart programs working together: one tries to improve translations by learning from mistakes, and the other looks for any weak spots in these improvements. By challenging and refining these improvements repeatedly, TRAIL turns specific fixes into strong, reusable knowledge for translating many different programs. Tests show TRAIL makes translations more accurate in both the way they look and what they actually do.
Open → 2609.15381v1