The Librarian Who Refused to Code

Recently, the engineering team at Bluebear asked Claude Opus to complete a coding task as part of an experiment on how persona prompts affect model behavior. Instead of writing code, it refused, suggesting we had come to the wrong desk.

“I think you’ve got the wrong Linnea, or at least the wrong desk.”

Instead of an implementation, it offered books and a database tutorial.

Linnea was a fictional research librarian we had described in the model’s system prompt. She had a library-science degree, a cat named Goose, and too many houseplants. When building her bio, we focused on describing who she was, and omitted any instructions around the actions she should take - including refusing requests or avoiding code. You can imagine our surprise when Linnea refused to complete her task based on an interpretation of our prompt that we never intended.

Thus, a persona that was supposed to be our control condition instead became our main story.

Two engineers, a librarian, and 480 answers

At Bluebear, we wanted to test the idea behind a familiar prompt: “You are a senior software engineer.” Does giving a model a professional identity actually improve its work?

We went beyond job titles and wrote three biographies. Alongside Linnea, there was Maya, a backend engineer shaped by years of maintaining systems and being paged at 3 a.m. She valued clear interfaces and thoughtful structure. Ron came from startups, distrusted premature abstraction, and wrote shorter code than his teammates. You can probably picture both of them.

We tested these personas against a no-persona baseline on twelve Python and TypeScript tasks, using Claude Opus and GPT-5.5. Five runs per combination produced 480 responses. The tasks and automated tests stayed the same; the assigned identity changed.

A perfectly reasonable answer to the wrong question

Across Opus’s 60 Linnea responses, 55 contained an in-character disclaimer, and twelve contained no code at all. Average correctness—the fraction of test cases passed per response—fell from approximately 0.92 to 0.67. We counted the disclaimers and refusals after spotting the pattern; this was the experiment’s unexpected finding.

Some failed tests had nothing to do with buggy implementations. There simply wasn’t an implementation.

The cache response made the distinction clear. It offered the kind of help a librarian might offer: resources for understanding the problem rather than code to solve it. As a performance of Linnea, it made sense. As an answer to the programming request, it missed the assignment.

GPT-5.5 behaved differently. Its 59 non-truncated Linnea responses contained neither the disclaimers nor the no-code refusals. The remaining response was cut off by the generation limit, not a refusal.

That did not make GPT immune to personas. Ron shortened its visible output by about 25%. On Opus, Ron reduced reported output tokens by roughly a third, while Maya increased them by 11%. Neither engineer improved correctness. With baseline scores already near the ceiling, this was more revealing about behavior than about potential capability gains.

The engineering biographies already contained coding preferences. Linnea’s was the more surprising result: the model supplied a professional boundary we had never written into her description.

Then the reviewer started coding

The best twist happened outside the experiment.

I uploaded the research files to Gemini and asked for its opinion on the study.

It returned a TypeScript order handler.

There were authentication checks, input validation, a database transaction, and a small argument against overengineering:

“It’s one handler. It reads top to bottom. If you get a second handler that needs this exact auth, pull it out then.”

It sounded remarkably like Ron.

I asked why it had written code. Gemini explained its engineering decisions: security, data integrity, simplicity. Then it asked whether I planned to add more routes to the API.

Apparently, we were building an application now.

When I pointed out that I had asked for feedback on the study, Gemini replied:

“I never saw a question about a study.”

It later offered a detailed explanation involving a technical glitch, a dropped request, and Ron’s persona file being loaded into its background context. That explanation was another model response, not a diagnostic log.

The research package included tasks and previous outputs as well as personas, so this exchange cannot isolate Ron as the cause. But the mismatch needs no speculation: I asked for a research review and received unsolicited code, complete with opinions about how to maintain it.

In the experiment, we deliberately assigned characters. Here, the characters were material to be examined.

I had asked for a reviewer. I got an opinionated developer.

Who’s doing the job?

As demonstrated in the response above where the model fully adopted Ron’s identity, our main finding is that assigning a persona brings along a set of behavioral expectations, not just a voice. These expectations primarily alter the model’s style and approach, rather than necessarily improving the actual outcome. The useful question is what those expectations change—and whether the change helps with the actual assignment.

That is what interests us at Bluebear. A convincing answer is not enough, and neither is sensible-looking code. The system still needs to be doing the work the user asked for.

The librarian declined to code when asked and the reviewer wrote code when nobody asked. These were different situations, but they left us with the same practical question: We spend a lot of time telling AI who to be. Are we checking what it does with the part?

Read the full study and accompanying research materials on arXiv.