Verification-aware cleanup of coding-agent work

Maintainers reviewing agent-authored pull requests could run trajectory-guided minimization only under a broader acceptance check: a removal must keep the test suite green, preserve or improve diff coverage, and retain links between stated requirements and executable evidence. TRIM currently accepts a smaller patch when execution tests still pass, but field data show that existing tests exercise only 61.5% of changed Java lines and 27.0% of changed Python lines. A passing suite can therefore authorize deletion without showing that the remaining change is adequately tested. VNVSpec supplies a practical representation for the missing condition by linking requirements, tests, and verdicts in CI.

The cheapest check is an offline replay on completed agent pull requests: compare ordinary TRIM with the expanded acceptance rule and inspect disagreements, especially removals involving tests, error handling, or requirement-linked files. This would establish whether stronger evidence checks materially change the minimized patch before adding another merge gate.

Teams running coding agents from detailed repository instructions should mark requirement statements, acceptance criteria, and checker failures as non-prunable context. SWE-Pruner Pro shows that line-level removal of tool output can cut token use substantially, but its relevance signal is learned from the model’s hidden states. The white-box audit study shows why a second constraint is needed: a few omitted requirements invalidated otherwise nearly complete artifacts, while an explicit 24-item checklist passed 10 of 10 runs compared with 5 of 10 for a generic self-check. A pruner should therefore optimize token reduction only after preserving lines tied to an external checklist or machine-readable requirement identifier.

Evaluate the change by adding protected-line masks to a pruning replay and reporting both token savings and requirement-level completion, rather than benchmark success alone. The audit task’s fixed checks offer a small initial test, although its context-length result was limited to one model-task pair and should not be treated as universal.

Coding-agent maintainers could use the repair trajectory twice: first to identify speculative edits and abandoned hypotheses, then to generate focused tests before those edits are removed from the final patch. TRIM finds that exploratory changes often survive after the correct repair is reached. Separately, pull-request analysis finds that error-handling additions are especially poorly exercised, with try/catch miss rates of 86.0% in Java and 81.0% in Python. Tool failures, temporary exception handling, and reverted conditions in the trajectory may expose precisely the boundary cases that the final patch’s tests omit.

A post-run step could extract touched branches, exception types, and failed commands from edits later classified as removable; generate tests against the minimized patch; and retain only tests that increase diff or mutation coverage. Replaying this on recorded trajectories would show whether discarded hypotheses yield more useful tests than tests generated from the final diff alone.