Repository-aware editing, recovery, and evaluation for coding agents

Teams automating repository-wide changes should bind each semantic edit operation to the requirements and design elements it is expected to satisfy. TraceDev shows how a traceability graph can expose missing links among requirements, designs, and files, while SCAS applies deterministic operations such as renaming a symbol or adding a parameter across affected locations. Combined, these mechanisms could prevent an operation that is structurally complete but implements the wrong requirement—or a requirement-aligned plan that leaves dispersed edits unfinished.

A practical implementation would require every operation to declare the traceability nodes it affects, update the graph after execution, and block completion when a required node has no implementation or test evidence. The cheapest useful check is a set of multi-file API changes with seeded omissions: compare text patches, unconstrained semantic operations, and requirement-linked operations on token use, missed call sites, and unmet acceptance criteria. TraceDev does not isolate the graph’s causal contribution, and SCAS reports only a preliminary synthetic rename probe, so this combination needs direct ablation before production use.

Maintainers using agents on C/C++ libraries could route failed attempts using invariant violations as well as compiler output, stderr, and ordinary test verdicts. CodeRescue demonstrates that reflection, replanning, and escalation have complementary cost-success profiles, but its router is described around conventional execution feedback. LISA produces documentation-grounded invariant checks for non-crashing functional defects, where a program can execute normally and still violate API semantics.

The router should receive the violated invariant, its provenance, and whether the failure was reproduced across valid API sequences. A likely workflow is to reflect on a localized, documentation-backed violation; replan when several independent invariants indicate a flawed approach; and escalate ambiguous candidates that still require developer confirmation. Evaluate this by replaying reintroduced library bugs and measuring confirmed fixes, false recovery cycles, escalation rate, and cost. This test matters because LISA’s candidates are not proofs of bugs, while CodeRescue’s formal guarantee controls expected cost rather than solve rate.

Engineering teams buying semantic repository retrieval should test whether it reduces incidental navigation work or compensates for genuinely harder program logic. JetBrains Context reports large maximum reductions in turns, latency, and execution cost, but the published excerpt does not separate task scale from repository presentation. Spaghetti Architect independently controls intrinsic problem size and incidental code messiness while preserving executable semantics, providing the missing experimental design.

Construct paired repositories from the same generated programs at several messiness levels, then run identical agent tasks with and without semantic indexing. Measure success, retrieved-file precision, turns, latency, and cost while holding intrinsic scale fixed; repeat by increasing intrinsic scale at fixed presentation. If retrieval gains appear mainly on messy variants, teams can target indexing at legacy codebases rather than treating it as a general capability upgrade. The result should remain scoped to synthetic repositories until repeated on production code, because Spaghetti Architect has not established that its messiness axis changes model accuracy and JetBrains’ figures are author-reported maxima.