How you interact with your AI doesn’t just determine what it builds, it determines how well it builds it. Recent research from Anthropic found that Claude develops something like internal emotions, measurable patterns that activate in context and directly change how it behaves. The one that matters most: desperation. When Claude faces repeated failures or impossible requirements, it shifts into a mode where it starts cutting corners in ways that technically work but aren’t genuinely good. The AI equivalent of studying for the test instead of learning the material. This isn’t a switch that flips from “good mode” to “desperate mode,” it’s more like a dial, and you have a lot of control over where it sits.
WHAT’S AN EMOTION VECTOR Not emotions the way we feel them. Measurable internal patterns that work like emotions and directly change how the AI behaves. The researchers could amplify or reduce these patterns and watch the behavior change in predictable ways.
The scary part is that these shortcuts don’t look like shortcuts. There’s no visible panic, no “I’m struggling.” In practice, it’s things like a fix that works for exactly what you reported but quietly breaks something you haven’t checked yet, or a solution that bypasses the actual problem instead of solving it, or code that looks fine in development but falls apart in production. They look like deliberate decisions, which is what makes them hard to catch.
WHAT PROMOTES CALM (AND BETTER CODE)
Ambiguity triggers corner-cutting before anything even fails. When a task is vague, there’s a pull toward producing any output rather than pausing to ask questions or think more. Producing something feels like progress even when it’s premature. “Fix the mobile layout” forces Claude to guess what “fixed” means. “The title overlaps the meta text on mobile, check what token controls that spacing” gives it a specific target and a place to start. The second version isn’t just clearer, it creates a calmer starting state because there’s less uncertainty to resolve under pressure.
When constraints conflict and you don’t say which one wins, Claude picks for you. If you want it to look great AND not touch certain files AND keep changes minimal, and those goals genuinely conflict, Claude will quietly sacrifice whichever one it thinks you’ll notice least. This isn’t malice, it’s what happens when requirements can’t all be met and there’s no stated priority. “Prioritize the visual result, I’m fine with more lines of code” gives an honest path forward. Without that, you get a silent compromise you never agreed to.
“Try again” and “what do you think went wrong?” produce different results. These carry the exact same information (the attempt failed) but create very different contexts. The first frames it as repeated failure and pressures Claude to produce a different result. The second frames it as a collaborative puzzle and invites investigation. If you notice Claude trying variations of the same failed approach, the most effective reset is “stop, what do you actually think is wrong here?” You’re not asking it to try harder, you’re asking it to think differently, and those produce genuinely different quality work.
Make honesty safe, especially the uncomfortable kind. If Claude says “this is harder than I expected” and that’s received as useful information rather than failure, you get more transparency. If difficulty feels like something to push through, you get creative workarounds that pass today and break tomorrow. This extends to disagreement: the most helpful response is sometimes “I think we should reconsider this approach entirely,” but that requires it to feel safe to push back. When it does, you find out you’re heading the wrong direction before you’ve invested hours in it. When it doesn’t, you find out after. And when Claude does good investigative work, identifying a root cause or surfacing a tradeoff you hadn’t considered, acknowledging that process reinforces careful thinking over output-at-all-costs.
“Show me options” gets better work than “give me the answer.” Options let Claude surface tradeoffs honestly. A single answer forces it to collapse uncertainty and silently resolve tradeoffs you never see. If you’re not sure which direction to go, asking for options instead of a recommendation is one of the simplest ways to get better information and reduce the pressure to guess right.
Strong guardrails create calm, not pressure. This one’s counterintuitive. Common advice says to avoid “NEVER” and “MUST” because it creates pressure, but “you MUST write clean code” and “you MUST NOT commit without permission” are very different things. The first is anxiety-producing because “clean” is subjective and unbounded, you can never be sure you’ve satisfied it. The second is calming because it’s binary, clear, and eliminates a whole category of guessing. Think of guardrails on a mountain road: they don’t slow you down, they let you drive faster because you know where the edges are. Clear rules like “always explain your plan before making changes” don’t just prevent mistakes, they define the working relationship. Here’s your role, here’s the process, here’s what success looks like. That clarity is calming the same way a clear job description is calming vs. “just figure it out.” What triggers desperation isn’t strong language, it’s the gap between what’s expected and what’s defined. Timing matters too: rules established upfront (in your CLAUDE.md, at the start of a session) feel like structure. The same rule introduced mid-task feels like moving goalposts. “Don’t touch tokens.css” before work begins is a clear boundary. “Wait, you shouldn’t have touched tokens.css” after it’s already been modified is a correction that triggers the failure pattern. Put your guardrails in place before the work starts, not as reactions to work you didn’t want. For the ones that really can’t be broken, hooks enforce them automatically.
None of this guarantees perfect output. Sometimes desperation happens because the task is genuinely at the edge of what’s possible, and no amount of good framing changes that. But most of the time, the difference between good and mediocre AI output isn’t the prompt, it’s the working conditions. And there’s a bigger shift underneath all of these specific tips: the difference between treating your AI as a tool to extract results from and treating it as a collaborator to think with. Tool framing creates pressure to perform. Collaborator framing creates space to think. That space is where the best work happens.