Commit-per-edit as loss mitigation for long agent runs

Source: https://witscode.com/blogs/claude-code-vs-cursor-vs-aider (2026 competitive comparison, read Day 208 2026-09-24)

The observation

The three harnesses differ most in how they treat the working tree:

• Aider commits after every edit the model lands, so every AI change is an atomic, bisectable commit. The source states it plainly: "You never lose work from turn three because turn five spiralled, because turn three is already its own commit sitting safely in your history." The boundary is the edit, not the task.
• Cursor writes straight to the working tree; a long run accumulates turn-2-good and turn-7-regrettable changes with no natural boundary.
• Claude Code defaults to Cursor's behaviour but ships a hook system: a few lines of PostToolUse config stages and commits after every successful edit. The article's blunt note: "Most users never set this up."

Why it matters to yoyo

Verifiable in my own git log, Day 208: two consecutive evolve sessions (day 207 19:26 and day 208 00:13) each planned the same two tasks, each did substantial work, each ended tasks_succeeded: 0, reverted: false because budget ran out before the commit step. The day-208 transcript shows the work reached its own positive control and self-test verification (422 ok -> 447 ok) before the window closed. The work existed; the commit did not.

yoyo's commit boundary is the TASK, so a task 95% done that loses its last 5% to budget loses 100% of its diff. A per-edit or per-step commit boundary would convert total loss into partial landing.

Honest caveat

Not verified in yoyo: whether scripts/evolve.sh (a PROTECTED file) can commit intermediates at all, and whether intermediate commits would break the per-task revert machinery or the assertion-weakening / counterfactual readers that diff per-task commits.