Same codebase, two developers, completely different AI output

I had a conversation this week that I think a lot of teams are about to have, whether they realise it or not.

A colleague had noticed something odd. Two developers, working on the same project, on the same codebase, with the same AI assistant, were producing strikingly different code. One leaned simple: boring, KISS-friendly, the kind of code you can read once and move on. The other reached for more elaborate patterns and less conventional naming. Same repo, same baseline conventions, two very different results.

His assumption, reasonably, was that the codebase itself should be the dominant influence. If the patterns are already established, surely the AI just follows them?

The codebase is only part of the context.

Where the difference actually comes from

Modern AI coding tools do not start each session from a blank slate plus your repo. They assemble context from several layers. Using Claude Code as the example, instructions can come from:

• An organisation-wide layer, deployed centrally (the managed policy file)
• A user layer, personal to each developer, that applies to every project they open
• A project layer, committed to the repo and shared with the team
• A local layer, personal but scoped to one project and kept out of version control

On top of all that sits a separate system: auto memory. This is the part most people miss. As a developer works, the tool quietly saves notes to itself about how that person tends to work: preferred commands, debugging insights, naming habits, stylistic leanings. Nobody writes these down. They accumulate on their own, and they load back in at the start of future sessions.

That is the likely source of the divergence. The two developers were not just bringing different skill sets to the keyboard. They were bringing different accumulated context. One person's personal preferences, written or learned, were steering output in a direction the shared project conventions were not strong enough to override.

The detail worth getting right

There is a tempting version of this story where one developer's habits leak out of every side project and contaminate everything else they touch. It is a good story, but it is not quite how it works, and the real mechanism matters more.

Auto memory is keyed to the repository. It is shared across worktrees of the same repo, but it does not automatically bleed from one project into another. The route that genuinely does cross every project is the user layer: the personal preferences that apply everywhere that developer works. So the contamination is not everything they have ever built. It is their personal defaults, applied to a shared project that had nothing strong enough to say otherwise.

That distinction is the whole point. The fix is not to scold anyone for their side projects. The fix is to make the shared project assert itself.

The fix: make the project speak louder

If you want consistency across a multi-developer codebase, the project has to carry its own context, committed and shared, rather than relying on each person's personal setup to behave.

In practice that means:

• A committed project instructions file that states the conventions explicitly. Specific beats vague: "use 2-space indentation" lands where "format code nicely" does not. More specific scopes override broader personal ones, so a clear project file beats an individual's defaults.
• Path-scoped rules or skills for the parts of the codebase with their own conventions, so the right guidance loads at the right moment.
• And the part people forget: these files are context, not enforcement. The AI reads them and tries to follow, but there is no hard guarantee. For things that must hold every time, a hook that runs as an actual check is the enforcement layer. Instructions shape behaviour; hooks enforce it.

The bigger takeaway

Both developers in this story had been using AI on their own for a long time and assumed this was their first time really collaborating with it. In a sense it was. Working solo, your accumulated context is invisible and harmless, because it only ever serves you. The moment two people share a codebase, all that private context meets in one place, and the differences surface as inconsistent output.

The tooling did exactly what it was designed to do. It personalised. The job now is to decide, deliberately, which context should be personal and which should belong to the team, and then to write the team's half down.

If your AI is producing inconsistent results across your developers, it is probably not being unpredictable. It is being faithful to context you have not made shared yet.

If you are working through how to set up shared AI conventions on a team codebase, I am happy to compare notes. No pitch, just a conversation if it is useful.