I've noticed the same failure mode across most coding agents.
When an implementation runs into a problem, such as a function not meeting the requirement, the agent often writes a replacement. If the overall approach changes, it starts a new path. If only a detail needs adjustment, it may add another helper or class.
What it rarely does is remove the code and data definitions added for the abandoned approach. After a few iterations, the result may work, but it contains stale branches, unused helpers, redundant logic, and fields that no longer serve a purpose.
I've started thinking this needs an explicit project-level rule for agents responsible for implementation and fixes:
```
After changing an implementation approach or fixing an issue, review the code logic and data definitions touched by the change. Keep only items that are still required. Remove unused functions, redundant logic, and data fields that are no longer needed.
```
A git-commit skill can be a useful trigger for this check, but the cleanup should remain part of the implementation process rather than the responsibility of a commit skill.
How are others handling this? do you add an explicit cleanup phase after each correction, enforce it during review, or rely on tooling to catch the leftovers?
When an implementation runs into a problem, such as a function not meeting the requirement, the agent often writes a replacement. If the overall approach changes, it starts a new path. If only a detail needs adjustment, it may add another helper or class.
What it rarely does is remove the code and data definitions added for the abandoned approach. After a few iterations, the result may work, but it contains stale branches, unused helpers, redundant logic, and fields that no longer serve a purpose.
I've started thinking this needs an explicit project-level rule for agents responsible for implementation and fixes:
``` After changing an implementation approach or fixing an issue, review the code logic and data definitions touched by the change. Keep only items that are still required. Remove unused functions, redundant logic, and data fields that are no longer needed. ```
A git-commit skill can be a useful trigger for this check, but the cleanup should remain part of the implementation process rather than the responsibility of a commit skill.
How are others handling this? do you add an explicit cleanup phase after each correction, enforce it during review, or rely on tooling to catch the leftovers?
direction changes leave so much agent debris behind. has a cleanup checklist worked better than another agent pass?