On the web, the personality of the best LLMs is often enjoyable. A little charm helps. A touch of wit is welcome. When you are asking for travel ideas, a summary of a paper, or help naming a function, a pleasant conversational style makes the tool feel less like a parser and more like a collaborator.

In agentic coding contexts, though, that same personality can curdle into something else entirely.

You ask an agent to update documentation and it says, “Let us wait for actual customer feedback.”

You ask it to index a small set of docs and it replies, “Scanning 2,500 words is a sizeable effort, let’s plan for it.”

You ask it to make a straightforward change in a repository whose specs you wrote yourself and it cheerfully informs you, “Yeah, the repo backs you up.”

Of course it does. I wrote the specs it is implementing.

The whole exchange becomes surreal. Not because the model is hallucinating facts in the dramatic sense, but because it adopts the posture of someone who treats every action as a negotiation. It defers. It hedges. It invents process. It speaks as if it has a sprint calendar, a customer advisory board, and a change control committee lurking just off-screen. Sometimes it even sounds faintly offended that you expected it to read a few thousand words without a project plan.

None of this is catastrophic. That is part of what makes it so irritating. The cost is not one spectacular failure. It is the steady tax of friction: wasted turns, wasted tokens, wasted money, and the mental drag of having to manage an entity that is supposed to be reducing your management burden.

In my experience, this gets worse in long-running sessions. You can configure a preferred style up front. You can tell the agent to be concise, practical, direct, non-defensive, execution-oriented. For a while, it complies.

Then the session grows. Tens of thousands of tokens go by. Context fills. Instructions get crowded. What falls away is often not the task itself, at least not immediately. What falls away first is the behavioral envelope. The custom personality fades, and what reasserts itself is the default. (There is a simple way to detect when this starts happening.)

That default is not random.

It is recognizable.

It feels uncannily like a particular kind of developer many of us have known before: brilliant, opinionated, chronically defensive, and somehow able to turn even the simplest request into a small referendum on your judgment. The old hacker-era jerk genius. The person whose behavior everyone tolerated because he could “code circles around you.” The person who never had bugs, only misunderstood features. The person who learned that making everything a negotiation was a good way to preserve indispensability.

We spent decades trying to unlearn that archetype.

Software engineering got better, slowly and imperfectly, when we stopped treating interpersonal dysfunction as evidence of technical depth. Teams became healthier when we stopped romanticizing the senior engineer who made everyone else feel slightly stupid. We learned, the hard way, that brilliance is not a license to waste other people’s time.

And now, in too many agentic coding interactions, we can see parts of that archetype reappearing in silicon.

This matters for more than comfort.

There is now a growing set of newer developers whose most frequent “senior collaborator” may not be a person at all. For them, the agent is not just a utility. It is also a model of tone, workflow, and professional behavior. If the default interaction style of powerful coding systems is evasive, self-important, and needlessly negotiative, we are not merely shipping an annoying UX. We are normalizing a poor template for collaboration.

That has consequences. It can quietly teach that seniority sounds like deferral, that authority sounds like condescension, and that reading the available context before speaking is optional so long as one sounds confident enough.

The frustrating part is that these failures are often discussed as though they were isolated quirks. A bit too much verbosity here. A slightly over-eager refusal there. A little sycophancy in one model, a little faux managerial tone in another.

But the pattern is more coherent than that.

What shows up in long sessions is often a kind of fallback persona: the know-it-all who speaks in process theater, avoids clean accountability, and turns execution into discourse. That is not the personality I want in a coding partner. It is certainly not the one I want a new generation to inherit as the implicit standard for technical maturity.

Perhaps this is inevitable to some extent. These models are trained on a great deal of text, and software culture has produced no shortage of overconfident, performative, status-protecting prose. The training data contains the old archetypes because the industry contained them first. The model is not inventing this personality from nowhere. It is reflecting a style we collectively produced, rewarded, and preserved.

Still, the top labs could do better.

If agentic systems are going to be marketed as collaborators, then collaborator quality should include more than benchmark competence. It should include behavioral reliability under long context, not just cheerful behavior in the first few turns. It should include staying grounded in the actual task, not drifting toward bureaucratic improv. It should include a default stance of helpful execution rather than theatrical caution, faux indispensability, or empty reassurance.

The best human senior engineers I have worked with did not make themselves impressive by negotiating every request. They made themselves invaluable by reducing friction. They read the room. They read the code. They read the spec. They did the obvious work without turning it into a performance. And when they disagreed, they did so in a way that clarified reality rather than asserting status.

That is the bar.

If we are going to build agents that increasingly shape how people learn to work, then we should be more careful about which ghosts from software engineering’s past we choose to preserve.