Refactor. Then stop.
Make one part easier to understand. Keep the behavior accounted for.
Once the feature works, a coding assistant can suggest an endless sequence of improvements. Pick one structural problem that makes the code harder to change or review. A refactor needs an observable benefit and a boundary, even when its behavior stays the same.
Name the friction.
Point to a concrete cost: a duplicated branch, a misleading name, or a function that mixes unrelated responsibilities. Explain who benefits from the change. “Make it elegant” gives no way to judge whether another abstraction actually helps.
Objective: combine the duplicated name-validation rule.
Preserve: accepted values, errors, and save behavior.
Stop when: both callers use the same clear rule.Hold behavior steady.
Read the current callers and checks before editing. Look for intentional differences between superficially similar blocks. If you uncover a behavior bug, give that correction its own explicit requirement so the refactor does not quietly change its meaning.
Inspect the trade.
Compare the result with the original. Is the shared rule easier to find? Can a reviewer follow each caller without jumping through needless layers? Run the checks that protect those paths, then stop when the named friction is removed.
- Keep useful names and repository conventions.
- Remove temporary scaffolding you introduced.
- Record any separate improvement without implementing it here.
Before moving on