Searcharxiv⌕ Search

subject

cs.SE

cs.SE: explore 370 source-linked works published from 2025 to 2026, with original documents and citations.

This collection is a preview while coverage and quality are evaluated.

Search within this collection

Coverage and selection

Includes records with this source-supplied label or an explicit phrase match in their metadata. Matches indicate a mention, not proof that a paper uses a method or tests a material. Source versions are consolidated by DOI.

Sources: arxiv. Collection updated 2026-09-16. Counts describe this index, not the complete source archives.

What Does an Evaluation License? A Commit-Bound Census of Claim Replay in Inspect Evals

Benchmarks can run without determining what their results license. We freeze a large evaluation collection and attempt to replay its historical claims. Most units stop because the evidence required for replay is not bound. Where replay is possible, different claims remain stable at different resolutions. We make this otherwise implicit inference step explicit and executable.

cs.SE↗

Repair or Resample? Rethinking Failure Debugging in LLM Multi-Agent Systems

As large language model (LLM)-based multi-agent systems (MASs) are increasingly applied to long-horizon complex tasks, their reliability has emerged as the core bottleneck hindering their real-world deployment. Existing MAS debugging and repair methods typically rely on rerunning and resampling the entire execution trajectory. However, a fundamental question remains to be answered: do these methods causally repair MAS failures or merely stochastically repair by leveraging the randomness of LLM sampling? To evaluate the effectiveness of MAS repair methods, we introduce SymTrace, a controlled evaluation framework that records the MAS execution trajectory and establishes intervention anchors. During replay, it effectively reconstructs the execution before the anchor using recorded logs and only regenerates the downstream trajectory, thereby enabling the reliable reproduction of MAS failures. We further construct the dataset SymFail, comprising 536 human-annotated failure trajectories with graph-linked locations, categories, and trace evidence. Based on these foundations, we conduct a large-scale empirical study across three mainstream MAS frameworks. Our findings reveal that existing unguided rerun methods are highly unreliable, exhibiting low failure reproduction and repair rates (only 67.97% and 6.90%, respectively). Building upon these findings, we further explore the effectiveness of a symptom-driven intervention method, which successfully repairs 20.15% of the failed cases (a 191.89% improvement to state-of-the-art repair methods). This study aims to provide actionable insights for MAS debugging and repair research, paving the way for the robust deployment of multi-agent systems.

cs.AI↗

Legacy System Modernization with Coding Agents: A Case Study

Legacy systems built on discontinued platforms are a recurring technological liability in organizations that depend on these applications to sustain critical business processes. Although modernization is strategically necessary, it is costly and error-prone when performed exclusively through manual effort. In this paper, we report on a case study conducted in a real industrial setting, where we evaluate both the effectiveness and efficiency of AI coding agents in supporting the migration of legacy systems to modern platforms. By using one version of Claude Code agent, we migrated 12 features of distinct complexity levels from a corporate ERP system written in Visual Basic 6 to C# .NET 10 under a single-generation strategy. Once the migration sessions were completed, we measured the equivalence of the migrated features against the original ones, and collected data about the time spent and the number of tokens consumed by the agent during the process. In our experiment, the agent achieved an average equivalence of 70%, with a strong asymmetry across complexity levels; low-level features achieved 92%, and high-complexity ones scored 47%. Similar asymmetry was observed in the cost-based metrics; low-level features consumed 1.47M tokens ($1.66), whereas high-level ones used 9.09M ($10.28). We reveal the practical scenarios and circumstances where this migration strategy is more effective, as well as discuss the limitations and challenges of using AI agents for legacy system modernization.

cs.SE↗

Towards Fully Automated Medical Imaging Code Generation via Validation-based Context Engineering

Large language models (LLMs) have demonstrated considerable promise in program generation for small-scale and conventional application development; however, they remain limited when applied to complex, domain-specific tasks such as medical image processing. General-purpose models lack explicit domain knowledge and robust validation mechanisms to ensure correctness, often requiring substantial human intervention to produce reliable processing pipelines. To address these limitations, we propose AutoMedImg, a multi-agent framework for fully automated medical image processing code generation. AutoMedImg orchestrates specialised agents across two phases: a Planning Phase that performs dataset analysis and architecture design with semantic and formal verification, and a Coding Phase that generates modules in parallel with static checking, execution testing, and assembly validation. This multi-stage validation mitigates error propagation throughout generation, while comprehensive auto-context engineering combining domain-specific knowledge bases, shared memory, and validation feedback automates context construction without manual prompting. A cross-project adaptive pipeline synthesis mechanism further accumulates validated pipelines and retrieves proven components for new tasks based on project similarity, enhancing generation efficiency through cross-project learning. Extensive evaluation across six diverse and well-established medical imaging datasets with five backbone LLMs demonstrates that AutoMedImg achieves zero human intervention, with Dice scores of up to 0.90 for segmentation tasks and 99% accuracy for classification.

cs.CV↗

APIFlow-Bench: Measuring Whether Agents Survive Long, Dependent API Workflows

Tool-using agents are commonly evaluated by a single bit: whether an end-to-end workflow completed. This metric fails to distinguish failures that matter in production, such as expired credentials, malformed payloads, or correct execution followed by incorrect final delivery. We introduce APIFlow-Bench, a fully auditable benchmark for long-horizon, dependent REST-API workflows that decomposes performance into seven engineering capabilities and requires agents to produce answers supported by the actual call path. We generate synthetic API worlds forward, subtask by subtask; each subtask is admitted only after a zero-LLM self-test triad verifies its grader and an oracle establishes solvability, and an adversarial audit identified and fixed six grader exploits. Grading is deterministic and provenance-sensitive: a state check traces a mock-minted canary through the API data flow to the response the answer must originate from, and a typed answer card is verified field by field. We release all answer keys and 44,362 unredacted execution transcripts. Across 19 frontier and open-weight models under one neutral scaffold, we find: (1) longer dependency chains degrade success, from 93% on individual subtasks to 74% on clean 20-subtask chains and 61% when including the 8% of chain trials that a model-consensus screen flags as passed by no model; (2) reliability separates models more than best-case capability, with best-of-five spanning seven points but all-five-of-five reliability spanning 44 points; (3) the independent-error account of compounding failure does not fit the data: pass rates on 20-subtask chains are 33 percentage points above the product of subtask-level rates, and on the clean slice 77% of failing runs reached the correct final state and failed only at delivery.

cs.AI↗

AgentLogs: A Dataset for Opening the Black Box of GitHub's Cloud Agent

Generative AI-based software engineering agents are becoming routine contributors to real-world software projects. On GitHub, developers can assign tasks to the Copilot cloud agent, which autonomously explores the repository, edits code, runs commands, and opens or reviews pull requests, producing a detailed log of every step along the way. While existing datasets capture outcomes of agent contributions, such as agent-authored pull requests, the process by which agents produce these contributions remains largely unexplored. To address this gap, we introduce AgentLogs, a large-scale dataset of agent activity on GitHub. AgentLogs comprises 307,416 agent tasks and 549,239 agent sessions in 35,810 of the 1,812,362 popular public repositories that we scanned, together with 64,255,174 session log entries that record each agent run step by step, including prompts, intermediate reasoning, tool calls (e.g., file edits, git operations, and GitHub interactions), and token usage. By exposing not only what agents contribute but also how they work, AgentLogs enables research on agent behavior, efficiency and cost, task formulation, failure modes, and human-agent collaboration in agentic software engineering.

cs.SE↗

A Multi-Month Study of Git Commit Signing

Git commit signing, introduced in 2012, is one mechanism for establishing commit provenance in software supply chains, yet developer-controlled adoption remains rare and developers' experiences using it are understudied. To examine this experience, we conducted a three-month study with senior undergraduate and graduate computer science students (n = 22), whom we treat as proxies for junior developers. Participants configured commit signing independently, used it across four coursework projects, extended it to a second device, examined an external repository containing anomalous commits, and answered security-reasoning prompts. We found that while almost all participants successfully signed every commit and rated routine signing positively, many faced friction during setup, multi-device configuration, and repository verification. Despite signing all semester, they struggled to spot anomalous commits during verification, with over a quarter finding none. Additionally, nearly half expressed at least one misconception regarding signing guarantees or key management. Without isolating whether these difficulties stemmed from tooling, education, or understanding, we conclude that making signing easier is not enough to ensure effective security use. Rather, secure adoption also requires tools and education that support signature verification against authorized identities, interpretation of missing signatures and unknown keys, and correct reasoning about key-lifecycle operations.

cs.CR↗

Database-Augmented RAG for Automated Repair of REST API Misuses

Many Internet of Things (IoT) services provide Representational State Transfer (REST) APIs, which require client developers to implement applications that conform to the corresponding API specifications. When client programs contain API misuse, developers debug them based on error responses. However, such responses are often insufficient for identifying the root cause, requiring developers to repeatedly communicate with the server. Retrieval-Augmented Generation (RAG) is a promising approach for providing large language models (LLMs) with external knowledge. However, in automated repair of REST API misuses, it remains unclear how specifications should be stored in a RAG database. This study evaluates how different configurations for organizing API specifications affect RAG-based repair of REST API misuse. We constructed 11 RAG configurations with different database structures and compared their repair rates with a baseline method. For evaluation, we used REST API misuse cases collected from real-world repositories. The results show that, in the studied datasets, the baseline method achieved a repair rate of 54.3%, whereas a RAG-based method using four databases achieved a maximum repair rate of 88.6%. These results indicate that organizing specifications according to version and content type can be an effective design choice for RAG-based REST API misuse repair.

cs.IR↗

Super Library Agent: Joint Generation and Maintenance of Multiple Applications Beyond the Single Codebase

Organizations often develop and maintain portfolios of related applications: independently deployable codebases that share substantial domain logic, interface patterns, or operational conventions. As LLM coding agents are increasingly used to generate and maintain such software, a naive application-by-application workflow duplicates shared logic across codebases and allows prolonged agentic maintenance to accumulate verbosity, dead code, and structural erosion. We introduce the Super Library Agent problem, where an agent sequentially generates a portfolio of N related applications while maintaining a shared Super Library of reusable cross-application components. A minimal sequential scaffold can in principle extract shared code and migrate applications to the evolving library, but in practice suffers from low extraction recall and fragile dependency migration. We address these failures with candidate-guided extraction over code chunk summaries, pre-extraction codebase consolidation, and context-aware migration using extraction traces and call-graph information. Across WebGen-Bench and PaperBench, our method preserves application functionality while significantly reducing redundancy and token footprint (verbosity, token length) over zero-shot, and avoiding the structural erosion introduced by naive library construction, with additional reductions in LOC and MDL. Our code is available at https://github.com/sbigstar0310/super-library-agent.

cs.SE↗

Evaluating Tiny Recursive Models Across Training for Code Generation

Code generation increasingly relies on large transformer models, whose capability advances with scale. Yet such a scale is costly, creating demand for small models, especially where data is limited. Recursive models address this by reusing a single block to add depth rather than stacking independent layers. Such models are typically evaluated by teacher-forced fit (next-token loss on ground-truth prefixes) or task accuracy, at a single checkpoint, whereas code is produced by free-running generation, where the model extends its own output. Whether a teacher-forced advantage survives free-running generation, and whether it holds across training, remains open. To study both, we compare a ~28M-parameter autoregressive Tiny Recursive Model (TRM-AR) on natural-language-to-Python code generation against parameter-matched and depth-matched controls, tracking fit and generation across 40 epochs and three seeds. The fit ranking between the recursive model and the depth-matched control reverses twice. Selecting each checkpoint by validation loss and examining the trajectory yields a consistent comparison. At equal parameters, TRM-AR fits, generates, and generalizes better than the parameter-matched control while recovering approximately 45% of the validation-loss gap and 57% of the generation-quality gap between the two controls, at roughly 175 times the per-step cost of the parameter-matched control. However, at equal effective depth, the larger transformer fits and generates better at its validation optimum, suggesting TRM-AR's advantage lies in resistance to overfitting, not greater capability. These findings suggest that recursive code generation models should be evaluated jointly on fit and generation across the training trajectory rather than at a single checkpoint.

cs.AI↗

One Capability or Many? Structural and Predictive Tests of Benchmark Validity Disagree About Economic Benchmarks for Frontier AI

Frontier-model leaderboards now rank systems on economic benchmarks, and those rankings inform what organisations buy and what regulators scrutinise. Whether such benchmarks measure a capability distinct from general test-taking is a question of construct validity that a structural test and a predictive test can answer in opposite ways. We show that they do on a hash-pinned snapshot of a frontier leaderboard with 421 model configurations across twelve benchmarks, four of them economic, of which 103 configurations carry all three sparsely scored economic benchmarks and 96 carry all twelve; four hypotheses and their thresholds were fixed before analysis, and every deviation from the plan is reported. The first factor of a three-factor extraction carries 74.5% of common variance and tracks release date (R^2 = 0.505), and date adjustment lowers its share by 14.9 points. Under the dimensionality rule fixed in advance the economic benchmarks form no factor of their own. A leave-one-benchmark-out test with factors re-estimated inside every fold nevertheless finds that a multi-factor representation predicts held-out economic scores better than a single general index (pooled Delta-MSE 0.037, 95% bootstrap interval [0.019, 0.055]) under the linear learners that fit best, an advantage that reverses for tree learners. Under the linear learners the same representation also predicts the eight other benchmarks better, so the battery carries predictive structure that one index misses and the economic benchmarks share it without forming a distinct factor. Construct validity should therefore be assessed by predictive tests alongside structural ones. We give a two-test protocol for benchmark builders and release the pinned data, the analysis plan and the code.

cs.LG↗

SilentProbe: Measuring Silent Failure in Production APIs Used as Agent Tools

An LLM agent calling a production API cannot distinguish a query that matched nothing from a query the server did not understand. Both return HTTP 200 with a parsable body, no exception to catch and no field to branch on. We ask what predicts which one occurred, and what it does to the agent. Auditing 721,320 parameters across 2,501 independently published OpenAPI documents, we find that 7.5% declare an enumeration and 15.2% declare any machine-checkable constraint at all, while 40.1% of documents state at least one constraint in prose that their schema does not encode. Executing 219 schema-derived perturbations against live commercial endpoints from 27 vendors, reached through a single aggregation layer (Monid) that publishes a schema and returns a run identifier for every call, we find that constraint form, not vendor identity, predicts honesty: machine-checkable constraints yielded an honest error in 111 of 111 cases, prose-only constraints failed silently in 44 of 61 (p = 2e-13). Twelve models across eight families then met these endpoints on ordinary tasks. A vocabulary that the description merely exemplifies was missed by every model on 88 of 88 attempts, while vocabularies written out in full were used correctly 88 to 91% of the time. Running the full agent loop, models detected the resulting silent failure in 12% of cases, repaired it in 0%, asserted a false negative to the user in 41%, and invented a figure in 12%. Promoting the vocabulary into the schema removes the failure, from 88 of 88 to 0 of 89. The fix is one line of schema rather than a better model. Code, schemas, perturbation sets, agent transcripts and per-call run identifiers are released at https://github.com/Jasper0122/silentprobe.

cs.IR↗

trajectory-judge: What Outcome-Only LLM Judges Miss on Agent Trajectories

A direct test of an LLM judge of agent trajectories injects faults into correct runs and reports recall, per fault type or by whether the fault broke the environment outcome (loud) or not (silent). Such recall can credit a judge with detection it does not have; paired discrimination, its flag rate on the faults minus its rate on the clean runs they came from, exposes this. Our testbed, a deterministic support desk with a scripted oracle and a one-step fault injector, labels all 400 trajectories exactly. A 14B judge shown only the request and final reply scores 34% to 76% recall on four fault types that leave the reply unchanged. There its input is the clean run's, so its paired discrimination is zero and that recall is its flag rate on clean runs. Splitting by outcome survival does not fix this: its loud recall of 84% is a paired +0.393 and its silent recall of 45% a paired +0.048, all from the two fault types that change the reply. Told to check each step, the same model flags every fault of those four types and 0 of 100 clean runs (95% CI up to 3.6%). It does not reliably check the reply: of four invented promises it flags one every time and the other three once in 42 faults. Shown every step but asked only about the reply, it still reaches a paired +0.69 on reply-unchanged faults, against +1.00 when told to check each step. We recommend reporting paired discrimination against clean parents, split by whether the fault reaches the judge's input and by outcome survival, and release the testbed, raw verdicts and analysis pipeline.

cs.CL↗

Structure-Behavior Coalescence and the Limits of Traditional Systems Theory

This paper examines a foundational assumption in traditional systems theory, namely that structure (the organization of components) and behavior (the evolution of system activity over time) can be treated as separable analytical dimensions. It argues that this separation contributes to persistent difficulties in explaining system identity, particularly in cases involving change, emergence, and boundary specification. To address this issue, the paper introduces Structure-Behavior Coalescence (SBC) as a reframing principle. SBC proposes that structure and behavior should not be understood as independently existing entities that are subsequently related through modeling constructs, but as mutually constitutive aspects of a single systemic process. From this perspective, system identity is understood as arising from the sustained co-determination of structural organization and behavioral dynamics, rather than from their external correspondence or alignment. This reframing provides a unified way of understanding system identity, emergence, and boundary formation within a cybernetically informed systems perspective.

cs.SE↗

What Is a System? An Interaction-Based Account of Structure-Behavior Coalescence in General Systems Theory

The question of what constitutes a system remains fundamental to General Systems Theory. Existing definitions commonly characterize a system in terms of elements, relationships, boundaries, functions, or interactions, but these perspectives do not always provide a unified account of how system structure and system behavior constitute one another. This paper proposes Structure-Behavior Coalescence (SBC) as an interaction-based account of what a system is. From the SBC perspective, a system is not merely a collection of elements or relationships, nor is it adequately characterized by behavior considered independently of structure. Rather, a system is a structured entity whose behavior arises through interactions among its constituent entities, with those interactions simultaneously contributing to both its structural organization and behavioral realization. The paper develops this perspective by distinguishing system structure, interaction, and behavior while treating them as inseparable aspects of a unified system representation. It argues that interactions provide the essential link through which structural relationships become behavioral processes and through which behavioral processes reveal and instantiate system structure. This perspective provides a basis for representing systems in a manner that maintains consistency between what a system is and what a system does. The paper further considers the implications of SBC for General Systems Theory, particularly for system identity, system boundaries, behavioral emergence, and the representation of complex systems. SBC is presented as a general conceptual foundation that complements existing systems theories by placing the coalescence of structure and behavior through interaction at the center of the definition of a system.

cs.SE↗

Developer-LLM Conversations: An Empirical Study of Interactions and Generated Code Quality

Large Language Models (LLMs) are increasingly used by developers for conversational coding assistance, including code generation, technical questions, and iterative problem solving. However, limited empirical evidence exists on the topics developers discuss with LLMs, how interaction patterns vary across tasks, and how the quality of generated code changes across conversational turns. To address this, we construct CodeChat, a large-scale dataset derived from WildChat. CodeChat contains 587,568 real-world developer-LLM conversations and 1.7 million code snippets across more than 20 programming languages. We identify the topics developers raise and examine how their engagement varies across topics. We then assess the quality of generated code across five programming languages (i.e., Python, JavaScript, C++, Java, and C#) and analyze how quality issues evolve across conversational turns. We find that developers most frequently seek help with web design (9.6% of conversations) and machine learning (8.7%), and that conversations often grow long because developers repeatedly shift use cases. LLM-generated code exhibits prevalent, language-specific issues whose prevalence does not consistently decrease in interactions lasting at least five turns. Among successful syntax-error resolutions, prompts that explicitly identify the error and request a fix are the most frequently observed. Our findings suggest that conversational assistants should track evolving developer intent and monitor code quality across turns.

cs.SE↗

ASA: Backbone-Training-Free Representation Engineering for Tool-Calling Agents

Adapting LLM agents to domain-specific tool calling remains notably brittle under evolving interfaces. Prompt and schema engineering is easy to deploy but often fragile under distribution shift and strict parsers, while continual parameter-efficient fine-tuning improves reliability at the cost of training, maintenance, and potential forgetting. We identify a critical Lazy Agent failure mode where tool necessity is nearly perfectly decodable from mid-layer activations, yet the model remains conservative in entering tool mode, revealing a representation-behavior gap. We propose Activation Steering Adapter (ASA), a training-free, inference-time controller that performs a single-shot mid-layer intervention and targets tool domains via a router-conditioned mixture of steering vectors with a probe-guided signed gate to amplify true intent while suppressing spurious triggers. On MTU-Bench with Qwen2.5-1.5B, ASA improves strict tool-use F1 from 0.18 to 0.50 while reducing the false positive rate from 0.15 to 0.05, using only about 20KB of portable assets and no weight updates.

cs.SE↗

Do Not Treat Code as Natural Language: Implications for Repository-Level Code Generation and Beyond

Large language models for code (CodeLLMs) have demonstrated remarkable success in standalone code completion and generation, sometimes even surpassing human performance, yet their effectiveness diminishes in repository-level settings where cross-file dependencies and structural context are essential. Existing Retrieval-Augmented Generation (RAG) approaches often borrow strategies from NLP, relying on chunking-based indexing and similarity-based retrieval. Chunking results in the loss of coherence between code units and overlooks structural relationships, while similarity-driven methods frequently miss functionally relevant dependencies such as helper functions, classes, or global variables. To address these limitations, we present Hydra, a repository-level code generation framework that treats code as structured code rather than natural language. Our approach introduces (i) a structure-aware indexing strategy that represents repositories as hierarchical trees of functions, classes, and variables, preserving code structure and dependencies, (ii) a lightweight dependency-aware retriever (DAR) that explicitly identifies and retrieves the true dependencies required by a target function, and (iii) a hybrid retrieval mechanism that combines DAR with similarity-based retrieval to provide both essential building blocks and practical usage examples. Extensive experiments on the challenging DevEval and RepoExec benchmarks, both requiring function implementation from real-world repositories with complex large repository context, show that Hydra achieves state-of-the-art performance across open- and closed-source CodeLLMs. Notably, our method establishes a new state of the art in repository-level code generation, surpassing strongest baseline by over 5% in Pass@1 and even enabling smaller models to match or exceed the performance of much larger ones that rely on existing retrievers.

cs.SE↗
Compare source metadata on this page
WorkPublishedSource identifierSource
What Does an Evaluation License? A Commit-Bound Census of Claim Replay in Inspect Evals2026-08-292608.19269arxiv
Repair or Resample? Rethinking Failure Debugging in LLM Multi-Agent Systems2026-08-292608.25920arxiv
Legacy System Modernization with Coding Agents: A Case Study2026-08-292608.28972arxiv
Towards Fully Automated Medical Imaging Code Generation via Validation-based Context Engineering2026-08-292608.29016arxiv
APIFlow-Bench: Measuring Whether Agents Survive Long, Dependent API Workflows2026-08-292608.29128arxiv
AgentLogs: A Dataset for Opening the Black Box of GitHub's Cloud Agent2026-08-292608.29204arxiv
A Multi-Month Study of Git Commit Signing2026-08-292608.29283arxiv
Database-Augmented RAG for Automated Repair of REST API Misuses2026-08-292608.29290arxiv
Super Library Agent: Joint Generation and Maintenance of Multiple Applications Beyond the Single Codebase2026-08-292608.29310arxiv
Evaluating Tiny Recursive Models Across Training for Code Generation2026-08-292608.29376arxiv
One Capability or Many? Structural and Predictive Tests of Benchmark Validity Disagree About Economic Benchmarks for Frontier AI2026-09-252608.29420arxiv
SilentProbe: Measuring Silent Failure in Production APIs Used as Agent Tools2026-08-292609.00035arxiv
trajectory-judge: What Outcome-Only LLM Judges Miss on Agent Trajectories2026-10-022609.00038arxiv
Structure-Behavior Coalescence and the Limits of Traditional Systems Theory2026-08-292609.00042arxiv
What Is a System? An Interaction-Based Account of Structure-Behavior Coalescence in General Systems Theory2026-08-292609.00043arxiv
Developer-LLM Conversations: An Empirical Study of Interactions and Generated Code Quality2026-08-282509.10402arxiv
ASA: Backbone-Training-Free Representation Engineering for Tool-Calling Agents2026-08-282602.04935arxiv
Do Not Treat Code as Natural Language: Implications for Repository-Level Code Generation and Beyond2026-08-282602.11671arxiv

These are bibliographic comparisons, not experimental rankings. Follow the original document for methods and conditions.