Best for
- Code that everyone fears touching
- Paying down tech debt without stopping feature work
- Turning 'we should clean this up someday' into a plan
What you give it
- The area to improve and why it hurts (bugs, speed of change, fear)
- The go-ahead per step, or for the whole sequence
What you get back
- A step-by-step refactoring plan, each step shippable on its own
- Behaviour-preserving changes with the test evidence per step
- An honest stop point if tests are too thin to refactor safely
How it works
- Reads the target area and maps what depends on it before proposing anything.
- Checks test coverage first — and writes characterisation tests where it is thin.
- Designs steps so each one keeps behaviour identical and the suite green.
- Executes step by step, running the tests after every one.
- Stops and reports when it finds behaviour that looks like a bug — it never silently 'fixes' semantics during a refactor.
Example
You: The order-processing module is 2,000 lines in one file and every change breaks something.
Result: A seven-step plan: characterisation tests first, then extract the pricing, stock and notification concerns one at a time, each step green before the next — with step three flagged as needing a decision about a hidden side effect it found.
Limits — please read
- Refactoring preserves behaviour; fixing bugs it uncovers is a separate decision.
- Thin tests mean slower progress — safety comes before speed.
- It improves structure; architectural rewrites need their own mandate.