Code Change Control

Engineering teams using coding agents need a cost gate before long-horizon runs, with a hard stop on repeated file viewing and editing. The evidence is no longer limited to vague complaints about expensive agents. On SWE-bench Verified in OpenHands, agentic coding used about 3500× more tokens than single-round code reasoning and about 1200× more than multi-turn code chat, with runs on the same task differing by up to 30×. The paper ties the worst failures to redundant search behavior, especially repeated file access and edits, and it shows that models are poor at forecasting their own token bill before they start.

A practical build is a repo-aware budget controller that watches action traces in real time and cuts the run into smaller scopes when the agent starts thrashing. The control point is simple: count file opens, revisits, edit reversions, and context growth, then require either a narrower subtask or human approval once those counters cross a threshold. Teams already paying for autonomous bug fixing or feature work would care first, because they absorb the cost of failed trajectories and usually do not get a reliable estimate upfront.

A cheap test is to replay past agent traces and measure how often an early stop after repeated file churn would have reduced token spend without hurting pass rate. If the controller mostly catches failures and late-stage wandering, it is worth shipping as a default guard in coding-agent products.

Repo-level generation workflows should split planning from implementation once a project passes roughly 1000 lines of code. RealBench shows current models still struggle on full repositories even when they receive natural-language requirements and UML package and class diagrams. The best average Pass@1 is 19.39%, performance is above 40% below 500 LOC and below 15% above 2000 LOC, and only 44.73% of methods are standalone on average. In the largest repositories, standalone methods drop to 26.23%, which points to dependency handling as the main source of failure.

The concrete workflow change is to stop asking a model for whole-repo output on medium and large codebases. Use the model first to map modules, interfaces, and dependency edges from the design artifacts, then generate files incrementally with tests after each step. RealBench’s own comparison supports this: whole-repo generation works better on smaller repositories, while incremental generation works better once repositories get larger.

A cheap check is to take an internal backlog item that already has architecture notes or diagrams and run it both ways: one-shot full-repo generation versus dependency-ordered file generation. Measure test pass rate, number of broken imports, and manual repair time. Teams building internal scaffolds, SDKs, or CRUD-heavy services can try this without changing their whole toolchain.

Requirements traceability can now justify a narrower maintenance tool that links a changed requirement to the file, class, or method most likely to break, while keeping context small enough to run in everyday development. R2Code reports an average F1 gain of 7.4% over strong baselines across five datasets and cuts token use by up to 41.7% with adaptive context control. The mechanism matters for product design: it decomposes requirements and code into aligned semantic parts, checks the explanation for each proposed link, and adjusts retrieval depth to the complexity of the requirement.

That supports a concrete build for teams with stale tickets, weak documentation, or regulated change review: a pull-request sidecar that takes a requirement ID, proposes the code links, shows the explanation for each link, and flags low-consistency matches for review. This is more useful than broad code chat when the job is impact analysis or audit preparation, because the user needs a compact evidence trail tied to named artifacts.

A cheap check is to sample resolved tickets from one service, hide the known touched files, and compare the tool’s top-k link suggestions against the actual implementation diff. If the links are accurate enough to cut search time for maintainers, the traceability layer earns its place before any broader agent workflow.