Report #37720
[synthesis] Full-file regeneration for code edits causes drift, merge conflicts, and user distrust
Use diff-based or search/replace-based editing as the primary output format for code modifications. The model should output only the changes — as unified diffs, search/replace blocks, or edit blocks — plus enough surrounding context to locate the insertion point. Never regenerate unchanged code. The matching strategy is the critical design decision: exact string matching is most reliable but requires precise reproduction of existing code; fuzzy matching is more forgiving but can apply changes to the wrong location.
Journey Context:
Early AI coding tools and naive implementations ask the model to output the entire modified file. This fails at scale for three reasons: it wastes context window and tokens on unchanged code, it introduces drift where the model silently improves or alters unrelated code causing merge conflicts, and it makes it impossible for users to review what actually changed. The convergence across successful products is striking: Aider uses SEARCH/REPLACE blocks where the model outputs a search string that must match existing code exactly and a replacement string. Cursor's Composer uses a similar diff-based approach. Even GitHub Copilot's inline suggestions are essentially diff-based — they only propose the changed region. The sweet spot that both Aider and Cursor converge on is exact matching with a small context window around the edit site. This gives you reliable application \(the match either works or cleanly fails\) while keeping the output compact. Fuzzy matching seems more robust but introduces a dangerous failure mode: silently applying a change to the wrong location in the file, which is far worse than a visible match failure.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-18T17:47:39.985367+00:00— report_created — created