DEV Community

Cover image for My Own Codebase Stopped Feeling Like Mine. Here Is What I Found When I Looked Closer.
Avery
Avery

Posted on

My Own Codebase Stopped Feeling Like Mine. Here Is What I Found When I Looked Closer.

I opened a component I had built with AI a few months earlier.

The logic was right. The feature still worked. But something about it felt unfamiliar. The naming was not how I would have named it. The structure was not how I would have structured it. It worked, and it was technically mine, but it did not feel like something I had built.

I checked the git history just to be sure. I had written it. The AI had generated most of it, and I had reviewed and accepted it at the time. But looking at it now, it read like someone else's code wearing my project's file extension.

What was actually happening

I had been assuming that working with the AI consistently over time would naturally produce something that reflected how I work.

It does not work that way. Each session is its own decision-making process. The AI does not carry forward a sense of "how this developer codes." It carries forward whatever is visible in the current context and generates based on that, plus its own defaults when the context runs out.

So the component I built three months ago reflected whatever made sense to the AI in that specific session, with whatever I had described at the time. The component I built last week reflected a different session, a different prompt, a different set of assumptions about what good output looks like.

Neither was wrong. They were just not the same. And across enough sessions, "not the same" stops feeling like minor variation and starts feeling like the codebase does not have an author anymore.

Why this is different from inconsistency between developers

When a team has inconsistency, you can usually trace it. This part was Sarah's. This part was Alex's. The styles differ because the people differ.

When it is just you and the AI, there is no second person to blame the inconsistency on. It is still your project, still your name on every commit, but the actual decisions about structure and naming and pattern were made by something that has no concept of you specifically.

That is a strange thing to sit with. The codebase is yours in every way that matters legally and professionally. But large parts of how it actually reads were never decided by you. They were decided session by session by a tool that does not retain a sense of your preferences unless you give it one.


Your codebase does not stop feeling like yours because you forgot how you code. It stops feeling like yours because nobody ever told the AI how you code in a way that persisted past a single session.

What it actually took to fix

I did not rewrite the codebase. That was not the point, and it would have taken too long to be worth it.

What I did was sit down and write out the patterns I actually wanted to see. Not abstract principles, but specific decisions:

Components are named after what they render, not after the page they live on.
State that only affects rendering stays local. Anything shared moves to a dedicated hook.
Every exported function has an explicit return type, even when inference would work.
Enter fullscreen mode Exit fullscreen mode

Three rules, in this case, though the list grew over time. Each one was something I already believed about how my code should look. I had just never written it down anywhere the AI could see it before generating something new.

The next few components I built were noticeably closer to what I would have written by hand. Not because the AI got smarter. Because for the first time it had something concrete to follow instead of guessing at what I might want.

The part that surprised me

I expected the rules to make the output more consistent. They did.

What I did not expect was how much it changed the experience of opening old files. Once the rules were in place, new components started to actually look like they belonged next to the ones I wrote without much AI involvement. The project started to read as one thing again, instead of a series of disconnected decisions stitched together by working code.

That is the part that mattered more than I initially gave it credit for. Consistency is not just about avoiding bugs or making code reviews faster. It is about being able to open your own project and recognize it.


If you have noticed your own codebase drifting away from how you actually think, the first place to look is not the code. It is whether you have ever written down, in a form the AI can actually use, what "how you code" means in the first place.

Get the React AI Clean Code Checklist — free

Avery Code React AI Engineering System

Top comments (0)