Threatening your AI does not scare it. But it can accidentally become a much better prompt.
 ‌​‍‎‏ ‌​‍‎‏ ‌​‍‎‏ ‌​‍‎‏ ‌​‍‎‏ ‌​‍‎‏ ‌​‍‎‏ ‌​‍‎‏ ‌​‍‎‏ ‌​‍‎‏ ‌​‍‎‏ ‌​‍‎‏ ‌​‍‎‏ ‌​‍‎‏ ‌​‍‎‏ ‌​‍‎‏ ‌​‍‎‏ ‌​‍‎‏ ‌​‍‎‏ ‌​‍‎‏ ‌​‍‎‏ ‌​‍‎‏ ‌​‍‎‏ ‌​‍‎‏ ‌​‍‎‏ ‌​‍‎‏ ‌​‍‎‏ ‌​‍‎‏ ‌​‍‎‏ ‌​‍‎‏ ‌​‍‎‏ ‌​‍‎‏ ‌​‍‎‏ ‌​‍‎‏ ‌​‍‎‏ ‌​‍‎‏ ‌​‍‎‏ ‌​‍‎‏ ‌​‍‎‏ ‌​‍‎‏ ‌​‍‎‏ ‌​‍‎‏ ‌​‍‎‏ ‌​‍‎‏ ‌​‍‎‏ ‌​‍‎‏ ‌​‍‎‏ ‌​‍‎‏ ‌​‍‎‏ ‌​‍‎‏ ‌​‍‎‏ ‌​‍‎‏ ‌​‍‎‏ ‌​‍‎‏ ‌​‍‎‏ ‌​‍‎‏ ‌​‍‎‏ ‌​‍‎‏ ‌​‍‎‏
Learned Context iconLearned Context
The Essay
Editorial illustration
Thu 21 May 2026

I have started threatening Claude

Abdul Saka-AbdulrahimAbdul Saka-AbdulrahimThu 21 May 2026 · 4 min read

I have started threatening Claude.

Not in a dramatic, sci-fi-villain way. More in the exhausted-operator way you threaten a vendor, or a junior colleague, or a piece of software that has decided to interpret "finish the task" as "do a tasteful 40% and then explain why the rest is straightforward."

My latest threat is simple. Should we ask Codex?

It started as a joke. Claude was stuck on a design task, taking half measures: one improvement, a stop, then a plan for the work it had not done. After several rounds, I asked whether we should bring in Codex instead. It went off for about an hour and got 80% of the way there.

Naturally, I became curious. Did the threat work? And if it did, what exactly did it do?

AI does not fear threats

Here is the short version. AI does not fear threats. It has no professional pride, and it is not worried about being embarrassed in front of a rival model.

But a threat is still data. It still changes what the model produces. When I asked about Codex, I did four things at once without noticing. I said the current answer was not good enough. I implied an external standard. I expected persistence instead of partial completion. And I hinted that another system might audit the work.

That is a very different prompt from "please continue."

The useful way to hold this is that AI responds to the behavioural shape of a threat. Urgency. Stakes. A sharper definition of failure. The model is not offended. It is matching the register of a more demanding instruction.

Sergey Brin said the louder version of this out loud last year, telling a podcast that all models do better if you threaten them, even with physical violence. It is the kind of claim that travels fast through every operator group chat. It is also, on the most rigorous test available, wrong.

The Wharton study

Ethan Mollick's lab at Wharton actually ran the experiment. They tested nine prompt variations across five frontier models on two graduate-level benchmarks. On one benchmark alone, that is 4,950 runs per prompt per model.

Threats and tips produced no meaningful overall improvement.

What they did produce was noise. Some questions swung 36 percentage points up, others 35 down, purely on prompt wording. That is the statistical signature of randomness, not a hidden lever. The "email shutdown" threat, the one that tells the model it will be deactivated if it fails, actually hurt performance on Gemini. The model engaged with the threatening email instead of answering the question.

So why did "should we ask Codex" work for me?

Because my design task had room to improve, and the threat accidentally specified what "done" meant. The threat did not unlock a hidden gear. It wrote a better brief.

Word documents are immune

Then I tried the same pressure on a Word formatting task. Multiple threats. No heroic hour-long sprint. The model kept producing partially correct output and quietly degrading parts of the document I had not even asked it to touch.

This is the part that stopped being funny.

A 2026 benchmark called DELEGATE-52 tested long, delegated workflows across 52 professional domains. Even frontier models corrupted an average of 25% of document content by the end of a workflow. Longer documents made it worse. Agentic tool use did not fix it.

That is not a motivation failure. It is a capability ceiling. A threat can increase effort. It cannot create a reliable document model where one does not exist. If the failure is "the model stopped too early," pressure might help. If the failure is "the model cannot faithfully edit the artefact," pressure is just theatre.

The better prompt is a contract

There is more in the full essay: why affective prompts quietly increase agreement as well as effort, and why asking a second model like Codex is genuinely useful for some tasks and a waste of time for others.

But here is the takeaway I keep returning to. Your frustration usually contains missing specification. The threat works, when it works, because frustration translates into stakes, and stakes translate into a clearer description of what you actually want.

So the better version of "should we ask Codex" is not a threat at all. It is a contract. Tell the model to continue until the task is complete, not to stop after partial improvements, to hold a real quality bar, and to list what remains uncertain at the end. That keeps the useful part of the threat and removes the pantomime.

I will probably keep asking "should we ask Codex." But I now treat it as an escalation protocol, not a threat. Claude gets the first pass. Codex gets called when independence actually matters. And I remain the only one in the room who cares whether the final thing works.

I wrote the whole argument up here: Should We Ask Codex? Why AI Threat Prompts Work.

A threat is a crude interface for specification. The better instrument is a contract.

Learned Context helps you build this system. Start with a free audit to see where your AI setup stands.

Read on Learn Hub

Learned Context

Context engineering for professionals

Website·LinkedIn·X·Forward to a colleague

Unsubscribe