When the Answer Must Change the Code

In Code-Graph-RAG, an answer that leads to a code change is not complete when a model proposes new text. The important question is how that proposal becomes a repository state that can be inspected, rejected, undone, and reflected back into the graph. This chapter follows the change lifecycle—from an untouched working tree through staging, verification, commit, re-ingestion, and impact review—and separates syntax safety from evidence of behavioral correctness.

A safer edit begins as an overlay

A source rewrite is deceptively easy to describe: replace the old code with the new code. It is much harder to make that operation preserve the parts a human did not ask to change. Code-Graph-RAG’s span-preserving patcher works against the original bytes of a file rather than re-emitting the whole file from an abstract syntax tree. Comments, whitespace, and local formatting can therefore remain byte-for-byte intact around the edited spans.

This matters for trust as much as for aesthetics. A large regenerated diff makes it difficult to see whether an assistant changed one identifier or silently rearranged the file. The patcher applies a batch of non-overlapping edits from the end of the original file backward, so queued edits do not need to track shifting offsets. An identifier replacement also checks that the bytes at the requested position match the expected old name and, where a grammar is available, that the syntax tree contains an identifier node spanning that range. A stale graph location, a prefix of a longer name, or a matching string literal is refused rather than treated as a close enough target.

The patcher can re-parse the result with the available grammar. For languages with documented formatter checks, it can report whether Go or Rust formatting would change, but it does not silently reformat the file. That distinction is important: a file that still parses is structurally admissible, while a formatter warning is a style signal. Neither one says that the change preserves behavior.

Single-file precision is not enough for a rename, move, or signature change. Those operations can touch definitions, imports, calls, overrides, and other files. Code-Graph-RAG stages such work in an in-memory transaction overlay. The working tree remains untouched while the proposed contents are collected. The staged view answers reads from the overlay first and from the disk second, so a verifier can inspect the repository as it would look if the entire batch were present.

Verification can be as simple as checking that changed files parse or as substantial as running a tool against a materialized copy of the staged tree. If the verifier returns a failure, returns false, or raises an exception, the transaction is rejected. This separates “the proposal exists” from “the proposal passed the checks chosen for this operation.” It also prevents an intermediate file from becoming visible merely because a multi-file edit is being assembled.

The commit has its own failure path. Before writing, the transaction checks that each staged file still contains the bytes on which the proposal was based.