Refactoring

Refactoring is restructuring existing code without changing what it does: tidying a messy function, removing duplication, splitting a sprawling file into clear pieces. The behaviour stays identical; the code just becomes easier to understand and safer to change next time.

It is how you pay down technical debt before it strangles you. As a codebase grows, especially one built fast with AI, near-duplicate logic and tangled files accumulate, and every new feature gets harder to add. Periodic refactoring keeps the foundation clean so you can keep moving quickly.

A few concrete shapes it takes. Say you're running your back end on Supabase and three edge functions each carry their own copy of the same auth check: refactoring means pulling that into one shared helper they all call, so the logic lives in a single place. Say you're orchestrating work in Make and the same five-step lookup is pasted into eight scenarios: you extract it into one reusable scenario the others trigger, and a fix now lands once instead of eight times. And when a refactor closes out, the tidy-up itself becomes a ticket in Linear so the cleanup is tracked, not a silent rewrite nobody can review.

The one rule that matters is to have a way to prove behaviour did not change, tests or a real check, because a refactor that silently breaks something is worse than the mess you started with. Clean as you go, and verify nothing moved.