You know the feeling.
Three days of careful work. Moving logic to the right place. Splitting components that had grown too large. Establishing naming that actually made sense. Cleaning up the state management that had accumulated across too many sessions.
The codebase finally looked the way it should have looked from the start.
Then a new feature request came in. You opened a session. The AI generated the first component.
And it looked exactly like the codebase before the refactor.
Why refactoring without rules does not hold
A refactor changes what exists. It does not change how new things get built.
When you refactor a React project you are correcting the accumulated decisions of every session that came before. You are imposing a standard on a codebase that never had one.
But the AI that builds the next feature does not know about the refactor. It does not know that you spent three days establishing a pattern. It does not know that components should now be split differently, that state should now live somewhere specific, that imports should now follow a particular convention.
It generates based on what it can see and what constraints exist. If the constraints are the same as before the refactor, the output will be the same as before the refactor.
The refactor cleaned the past. The rules were never written down to protect the future.
The cycle most developers do not realize they are in
Refactor. Build with AI. Watch the standard erode. Refactor again.
It feels like progress because each refactor genuinely improves things. But the improvement does not compound. It resets. Because the underlying cause — the AI making its own decisions without rules — never changed.
The three days you spent refactoring were not wasted. But they were not invested either. They were spent. And the next session spent them again on the other side.
What makes a refactor permanent
The refactor becomes permanent when the standard it establishes gets written down as rules the AI follows going forward.
Not documentation. Not comments in the code. Rules that exist before the session starts and define what every new piece of output must look like.
When you finish a refactor, the question is not just "does the codebase look better?" It is "have I given the AI the rules it needs to not undo this?"
Here is what that looks like in practice:
Rules written after the last refactor:
1. Components above 200 lines get split before the session continues. No exceptions.
2. Every new feature gets a dedicated hook before the UI component is built.
3. Imports always go through the feature index file. No direct cross-feature imports.
These were the patterns the refactor established. Writing them down took twenty minutes. They have held up across every session since.
The refactor you will not have to do again
Most developers refactor reactively. The codebase drifts, the pain becomes too great, the refactor happens.
With rules in place the drift stops. Not because the AI became better at guessing. Because the AI stopped guessing and started following.
The next feature looks like the refactored codebase because the rules define that it must. Not approximately. Exactly.
That is the refactor you do not have to do again. Not because the codebase never changes. Because the standard that the refactor established now travels with every session that comes after it.
The prompt does not matter. The rules do.
Three days of refactoring deserve more than one session to undo them.
Write the standard down. Give it to the AI before the next session starts. And stop refactoring the same codebase over and over because the rules that would protect it were never written down.
Want to find which parts of your React project are one AI session away from needing another refactor?
I built a free 24 point checklist that helps you find exactly that. The structural gaps the AI will fill with its own decisions the moment you give it something new to build.
Top comments (0)