Refactoring

Refactoring is changing the insides without changing the show.

Same buttons. Same API. Same numbers on the judge's screen. You rename, you extract, you delete the third copy. Users see nothing. If they see something, it was a feature or a bug fix — not a refactor.

Saturday code is almost never tidy. You bolt a path on, then another. A "tiny" change starts touching eleven files and you get scared. That fear is the bill. Tidying is how you stop paying it on every commit.

Proof is a test, not a vibe

Tests are how you know the show did not change. A typecheck is a test the compiler already wrote. Refactor without a net and you are gambling the demo on a rename.

Do it when the next change is scary because of the mess. Do it small and often — one function, one module — not a "cleanup week" that never ships. Don't do it when the demo is in an hour. That is how you invent new mess and call it craft.

Agents make piles

Vibe coding optimizes for "it runs." Multiply that over a Saturday and you have a repo held together with tape. Stop and say: "This works. Clean it up without changing behavior. Same routes, tidier files." That sentence is a refactor. A tidy tree is also easier for the next agent to navigate.

At a hackathon, refactor the module you will touch next, not the whole monorepo. Leave technical debt you wrote down. Pay the debt that is blocking the next feature.

What this unlocks

Tidying is the third job, next to features and fixes. Skip it forever and every future change costs more than it should. Same show. Better backstage. That is the whole move.