Felix Rieseberg: Persona-Prompts fuer Claude sind nutzloser Kostuem-Ballast

Posted on Oct 26 • Originally published at appliedaihub.org

Open your best system prompt. If it starts with "You are a world-class accountant," you are paying for a costume.

The persona line feels like engineering because it is easy to write, easy to explain to your boss, and easy to demo. It is also, according to one of the people building Claude's desktop products, a relic. The same goes for the fleet of narrow "data scientist agent" and "legal agent" wrappers many teams spent last year assembling. They were built for a model that no longer exists.

Felix Rieseberg leads engineering for Claude.ai, Cowork, and Claude Code Desktop at Anthropic, and he co-created Electron before that. In our timestamped breakdown of his interview on Silicon Valley Girl, his advice on role prompts is blunt. Models still tend to play-act when told to be an expert:

"A lot of the models still have the problem that if you tell them to act like a very good accountant that they engage in a little bit of role play."

What he does instead is ask the model what tools and techniques someone at the top of the field would use, then require it to use exactly those, and finally explain the result in plain language. In his words, he does not need the costume; he wants to be talked to "like I'm five," but with all the best tools in the field. His insight card on this is worth reading in full.

Notice what changed. The persona prompt asks the model to sound like a professional. The process prompt asks it to work like one. The first changes vocabulary. The second changes the computation.

Rieseberg's example: the recent jump in AI-generated 3D and motion work did not come from better adjectives. People told Claude to open Blender, the same program professional animators use. Hand the model the real instrument and the output improves, because the instrument carries decades of encoded craft that no paragraph of persona text can match.

This is not only an anecdote. A systematic study, Is "A Helpful Assistant" the Best Role for Large Language Models?, tested 162 social roles across several model families on factual and reasoning questions. Adding personas did not reliably improve accuracy over a no-persona baseline, and the effect of any single role was close to random. Picking the best role per question after the fact looked great, but predicting it in advance barely beat chance.

Personas still do something real: they shift tone, register, and format. If you need a gentle customer-support voice, a persona is the right tool. The mistake is believing it raises reasoning quality. Style and competence are different knobs, and most "expert" prompts turn only the first.

Author's Comment: A quick test for your own prompts. Delete the persona line, keep everything else, and run your ten hardest examples. If the quality is the same, you were paying tokens for a costume. If it drops, look at what dropped. It is usually tone, not correctness.

Rieseberg's second target is bigger. He thinks the industry is "over-rotating on this agents thing," meaning rigid casts of narrow persona agents, each fed a pre-sliced fragment of company data. His evidence is a clean historical example. Google DeepMind built a custom model and a custom harness for the International Mathematical Olympiad and got a silver-medal result with AlphaProof and AlphaGeometry 2. Then general-purpose models arrived, and an advanced Gemini with Deep Think reached gold-medal standard with no bespoke math machinery. (Rieseberg recalls four or five months; the official record is closer to a year, which only strengthens his point.)

This is the Bitter Lesson arriving at the application layer. Richard Sutton's argument was that hand-built domain knowledge keeps losing to general methods that scale. Your custom "contracts agent" is hand-built domain knowledge. It will win for a while, then a generalist with the right tools will pass it.

The same logic hits Skills, the packaged instructions teams attach to models. Rieseberg warns that they have a short half-life. Many encode workarounds for the previous model generation, and he reports that deleting a stale skill often improves output. That is debt in the literal sense: you borrowed speed from a weaker model's limitations, and the interest rate is set by every new release.

If personas and narrow agents are the wrong investment, what is the right one? Rieseberg's answer is what he calls Model Experience (MX), the counterpart to UX. Imagine you are the model. What would you need to do this job on your own?

His origin story is instructive. He used to tell Claude, "I found another crash, please fix it." Then he noticed that he was just a conveyor belt: pick up a crash, carry it over, drop it in front of the model, repeat. The fix was to give Claude direct access to the raw crash data and let it decide what was worth fixing. The setup cost was real, and he says it was worth it. Card 6 of the interview has the full account.

Compare the two investments side by side:

The second column is boring, and it is where the durable gains are. A model with a computer, the raw logs, and permission to install packages does not care how clever your persona paragraph was.

Practical Pitfall Avoidance Guide: Do not swap one fashion for another. "Give it tools" fails if the tools are poorly documented. Models are good at picking among well-described tools, so spend your effort on clear tool descriptions and sane permissions, not on longer prompts. If you want the surrounding architecture, our piece on context engineering versus prompt engineering covers the data-flow side, and The Claude Stack shows how heavy users layer these ideas.

A related warning lives in our post on contradictory prompts: the more rules and personas you stack, the more likely two of them collide. Short prompts with strong tools have fewer places to disagree with themselves.

The last piece of Rieseberg's argument is about ambition. He says most people use a "data center of geniuses" (an idea he links to Dario Amodei's framing, which we cover in our Dario Amodei interview breakdown ) like a 2024 email summarizer. His test for finding the ceiling is simple: take the task you are doing, ask what outcome you hope happens next, and hand that to the model. Repeat until it fails. The failure point is the frontier, and workflows built right at that edge are the ones that benefit when the next model ships.

This also explains why costume prompts and narrow agents feel safe. They keep the model small enough to rationalize. Giving a generalist real tools and a real goal is scarier, because you lose the comfortable fiction that you are supervising a junior hire.

Take one prompt tomorrow, delete the costume, and replace it with a list of tools and a goal one level higher than the task. If it fails, you learned where the ceiling is. If it works, you just deleted a liability.