Why two developers get different AI suggestions

Same repo, same file, two different agents

Open two terminals in the same repo. Same CLAUDE.md, same model, same version of Claude Code, same ticket on the board. Ask two developers to work the same kind of change and you do not get one agent behaving consistently. You get two agents behaving differently, on the same instructions, on the same day.

The clearest record we have of this is one line from our own research, verbatim: "why does Copilot suggest different things to me than Alex." One sentence, about Copilot rather than Claude Code, from one conversation. We are not going to stretch a single line into a trend. What we can do is show you the mechanism sitting underneath it, because that mechanism is measured, and it says something sharper about two people than it ever said about one.

The file is a constant. The session is not.

CLAUDE.md sits on disk, byte-for-byte identical for whoever opens the repo. Read it at message one and an agent follows it closely. Published measurements of instruction compliance put it near 95 percent early in a session, falling to somewhere between 20 and 60 percent by message six to ten. That is a wide range, and the width is the point: where you land in it depends on how much has piled into the context window since the file was last read, and that number is different for every person in every session.

Developer A opens a fresh session and asks one clean question. Developer B has been in the same session since standup, six files into a refactor, context compacted once already. Both of them are working from the identical CLAUDE.md. Neither of them is working with the identical amount of decay. The file did not change between their two terminals. The distance between "the instruction was read" and "the agent is deciding right now" did.

That is the whole mechanism, and it is duller than it sounds. Nobody is prompting better or worse than anybody else. The agent is not being inconsistent about one shared input, because the input each of them is actually working against was never the same. A short session and a long one are two different amounts of context sitting between the rule and the decision, and the rule loses weight the further back it sits.

Nobody can see the other person's turn count

Here is what makes it hard to catch. Neither developer has any way to see how far into a session the other one is. There is no shared readout saying "Alex is on message eleven, and the instruction has not been re-read since message one." Each of them just sees their own agent doing what it does right now, with nothing to compare it against.

So the gap gets explained by whatever is visible, which is never the real cause. It reads as the model being unpredictable, or as one person being better at prompting, or as bad luck on a given day. The actual variable, turns elapsed since the last re-assertion, does not show up in any window either of them is looking at. The two people best positioned to notice the pattern are the two people structurally unable to compare notes on it, because the thing they would need to compare is invisible to both of them.

What a shared file cannot fix

The instinct is to fix the file. Write more detail into CLAUDE.md. Add a team wiki page. Put the rule in the pull request template too, in case it gets missed twice. All of that is still one document, read once, by everyone who opens it. If the words in the file were the problem, more words would help.

The actual problem is a clock that starts over every time the file gets read and counts down while the session keeps going, and a longer file does not touch that clock. It just gives the session more to compete against for the same finite attention. Code review catches the result after the fact, which is worth doing and is a different thing from reproducibility. By the time a reviewer flags an agent that drifted from a convention, the fix was to notice it, not to prevent it, and the same gap reopens on the next long session.

What has to be true instead

The variable is per session, so the fix has to run per session, on every turn, no matter how long any one person has already been at it. A hook that re-asserts the instruction on every prompt does not check whether this is message two or message twenty. It puts the rule back in front of the model right before the decision, every time, which means a short session and a long one stop running against different amounts of decay. They start running against the same floor.

Worth being honest about what that is and is not. A hook is a context nudge, not a hard gate. It cannot force a model to comply, and anyone telling you otherwise is overselling it. What it does, in our own usage, is keep a routing decision in front of the model on roughly one prompt in four, with precision around 88 to 92 percent. Those are internal numbers from our own sessions, not a lab result, and we are not dressing them up as more than that.

The other honest part is that none of this is a team feature. It is the same mechanism one person runs, run twice. Two developers each installing the same Flow, the same FLOW.md, the same hook, get the same floor under their instructions independently of each other. Nobody has to coordinate, and nothing has to be shared except the file both of them were already supposed to be reading. Consistency across a team, in this shape, is consistency per person, multiplied by however many people actually run it.

The question worth asking first

Next time your output disagrees with a teammate's on the same repo, skip the theory about who prompts better. Ask how long each of you has been in your session, and when either of you last actually re-read the file rather than just having it open. Most of the time, that is the whole explanation, and no amount of comparing prompting habits will find it if you are looking in the wrong place.