Both produce a large diff and the sentence “I cleaned up the export module”. One of them made a promise about behaviour. The other quietly cancelled it.
Both changed about four hundred lines. Both say the module was cleaned up. One of them also changed the tests.
Split a 300-line function into six named ones. Renamed three variables. Deleted a dead branch. The test file was not opened.
Rebuilt the export module from scratch on a cleaner design. Eleven tests were updated to match the new shape.
One is a change with a promise attached. One is a change with the promise removed, which is why it costs what it costs.
Refactoring keeps a promise: nothing outside this file may notice. That promise is what makes it safe, and it is also what makes it checkable — the old tests are the promise written down, so if they still pass untouched, the promise held.
Rewriting cancels the promise, and everything the old code quietly knew goes with it. Years of small decisions live in working code and almost none of them are written anywhere else — the odd currency, the partner who needs tab-separated files, the retry that exists because an API once flaked at month-end.
Tap a change, then tap whether anything outside the file may notice. Then see what each one is actually committing to.
Pick a situation. In every one, a tidy-up was asked for and a replacement was delivered.
It was used four times a year, by one partner, and it was in the old code because somebody once needed it.
Five questions. Nothing is scored.
Five terms, not two. Tap one.
If your code works but is messy or hard to read, refactoring is usually enough. If the code is broken, unfixable, or must do something new, rewriting may be needed. Always start by asking what needs to change—structure or behaviour.
AI tools can suggest refactoring steps, like renaming variables or splitting functions. For rewriting, AI can generate new code, but you must check that the new code matches what you need and does not break anything important.
Both involve changing code and can look similar in a code review. The confusion happens because both can be described as 'cleaning up' or 'fixing' code, but only rewriting changes what the code does.
Renaming variables in a payroll script so they are easier to understand, or splitting a long function into smaller ones, are both refactoring. The script still calculates pay the same way, but is easier to update next month.
Break the rewrite into small, testable parts. Write tests for old and new code. Involve colleagues who know the old system. Communicate clearly about what is changing and why.
Yes, but it is risky. Mixing the two makes it hard to spot where new bugs come from. It is better to refactor first, then rewrite if needed, so you can track what changed.
| Term | What it means | Why it matters |
|---|---|---|
| Regression | A feature that stops working after a change | Rewriting can introduce regressions, so users lose trust if things break. |
If the old tests still pass untouched, you refactored. If you had to change the tests, you rewrote — whatever the commit message says.
Copyright © Pawan Nayar · LLOS.ai · 2026 — Refactoring vs Rewriting: keeping the promise about behaviour, versus cancelling it.Original pedagogy, voice, and design — all rights reserved.