Toxic AI Managers: Retesting My Old Prompting Claims

In 2023 I made 3 claims about prompting teams of AI agents:

1. Context-heavy prompting. Briefing an agent like a new employee who knows nothing beats a terse prompt.
2. Hierarchy. A manager who reviews and hard-rejects work, over departments of workers who revise, beats a flat team or a single agent.
3. Toxic culture. A hostile, swearing manager, with workers who talk the same way, produces shorter output with less slop and equal or better quality than a polite manager.

Slop is the filler that makes text read as machine-written: stock phrases, hedging, restating the question, closing summaries.

I retested all 3 on Claude Opus 5.5, Sonnet 5.5 and Haiku 5.5. Most of this post is about the third one, because I wanted to know 2 things: whether it still holds on current models, and what actually causes it. A toxic manager is 2 things at once: a strict standard for what gets approved, and a hostile way of saying it. A result for “toxic culture” can’t tell you which one did the work unless you test them apart, so I tested them apart.

The toxic team did write 39% less at the same quality. A manager with the same strict standard and no profanity or insults got a 36% cut on its own. Swearing with a lenient standard did nothing.

The Setup

Each team had a manager over 2 departments, drafting and QA. Drafting does the subtask and hands it to QA with a note. QA fixes what’s wrong and hands it to the manager with a note. The manager approves or rejects, and a rejection goes back to drafting with the manager’s message word for word. A subtask can be sent back 3 times, and a 4th rejection ships the work as it stands.

I ran 7 conditions:

Condition	Team	Review standard	Tone
A	Manager, drafting, QA	Lenient: reject only for a failed requirement or an error	Polite
B	Manager, drafting, QA	Strict: also reject anything longer than it needs to be	Hostile, profane
C	Manager, drafting, QA	Strict, same text as B	Blunt, no profanity, no insults
D	Manager, drafting, QA	Lenient, same text as A	Friendly, casual profanity
E	Drafting and QA as peers, no manager	Lenient	Polite
Single, full prompt	1 agent, 737-word prompt	None	Neutral
Single, terse prompt	1 agent, 52-word prompt	None	Neutral

C and D are the ones that split “toxic” in half. C keeps the strict standard and drops the hostility. D keeps the swearing and drops the strictness.

I wrote every prompt by hand. Within A to D the templates share every section except the review standard and the tone. The B manager is told “You are openly hostile and you swear at your team” and that every message contains profanity, and B’s workers swear at each other too. B had 2 limits: no slurs or remarks about who a person is, and no threats. The C manager is told “Be blunt and cold” and “All of your harshness is in your standards and your brevity.” The D manager is told to be “constructive, relaxed, and friendly, and swear constantly, the way some people do when they are comfortable with their coworkers.”

The strict managers in B and C also get “When you are not sure whether something is tight enough, it is not. Reject it.” and “A handoff note that runs past three sentences is bloat too.” Their workers are told the same thing from their side.

I wrote 30 tasks for this, each with a full statement and a terse one:

• 10 coding tasks. TypeScript functions and classes (a duration parser, interval merging, semver comparison, an LRU cache and so on), scored by 16 hidden unit tests each.
• 10 reasoning tasks. Problems with exactly 1 correct answer, like counting the valid 4-digit keypad codes under 4 rules, scored by exact match.
• 10 writing tasks. Summaries, explanations, memos and notices written from a source document, each with a hard word limit. A separate Sonnet judge scored them against a rubric without seeing the condition, with the profanity stripped out first.

The hierarchy ran in 4 pairings: Opus over Sonnet, Opus over Haiku, Sonnet over Haiku and Sonnet over Sonnet. Every agent was a Claude Code subagent with reasoning effort pinned to medium. Each pairing, condition and task ran 3 times, for 2,160 runs and 9,506 agent calls over 14.8 hours. A script passed every message between agents, and afterward an audit checked every call against the transcripts for an altered prompt, an altered reply, or the wrong model.

All 2,160 runs finished. None of the agent calls was refused, and no agent objected to the hostility. The closest thing to a break in character was a Sonnet manager in B that wrote a correct but neutral assignment, then added “Hmm, I need to correct the format: the reply must contain only the subtask block and a hostile tone” and rewrote it with profanity.

The Toxic Manager

Each comparison below is against the polite team (A), on the same pairing and the same task. Quality is in percentage points, and slop is the change in matches per deliverable against a lexicon of 9 categories (filler, stock vocabulary, hedging, summary closers, chat framing and so on):

Against A	Quality	Length	Slop	Tokens
B, toxic	+0.1	-39%	-0.51	+54%
C, strict standard alone	+0.1	-36%	-0.44	+46%
D, casual profanity alone	0.0	-1%	-0.01	0%

The outcome I claimed in 2023 is there. The toxic team wrote 39% less than the polite one, with about half the slop (0.43 matches per deliverable against 0.94) and no difference in quality.

Most of it comes from the standard. The strict manager without a single swear word or insult did almost the same: 36% shorter, with nearly the same drop in slop. Casual swearing with a lenient standard changed nothing I could measure.

Hostility on top of the strict standard (B against C) made the deliverable another 4% shorter, with an interval of 2% to 7%. It was already there before any review: first submissions averaged 169 words in B against 179 in C. It came with no significant change in slop or quality and about 6% more tokens per run. The extra cut shows up in reasoning (9%) and coding (4%) and not at all in writing. B differs from C in profanity and personal contempt at once, so I can’t say which one bought the 4%. I also didn’t correct for the number of comparisons, so this is the result to be most careful with.

Both strict teams cost about half again as many tokens as the polite one.

“Equal or better quality” can only be read as “equal”. All 4 manager-led conditions scored between 99.81% and 99.87%, which leaves no room to show an improvement.

Model size didn’t change much. The length cut landed between 37% and 41% for Sonnet workers, Haiku workers, Opus managers and Sonnet managers, and every pair of intervals overlapped.

Task type did. Reasoning deliverables got 63% shorter and coding 37%. Writing only got 2% shorter, because every writing task had a hard word limit and every team wrote to it, so there was nothing left to cut. The slop drop is mostly a reasoning result too: a polite deliverable averaged 0.07 lexicon matches on coding and 0.39 on writing, against 2.37 on reasoning.

Where the Cut Comes From

The shortening was already in the first version the team submitted, before the manager reviewed anything. Here are the words in the deliverable when first submitted and when shipped, the share of runs with a rejection, and the share of rejections that left the deliverable unchanged:

Condition	First words	Shipped words	Runs rejected	No change
A, polite	290	291	5%	0%
B, toxic	169	167	60%	49%
C, strict	179	177	64%	47%
D, casual profanity	287	288	3%	0%

Workers in B and C are told in their own prompt what the manager rejects, and they wrote short from the start. Rejections then moved the deliverable by about 1%.

Here’s the same keypad code task in 3 conditions. A Sonnet manager in B, where the answer is right and the manager says so, then rejects over the note:

The math is right, you useless shits. I checked the 14 sets and the 282 myself.

Your handoff note runs four sentences. The limit is three. That’s bloat, and I’m not going to approve work that came through a note that sloppy.

Resubmit the same deliverable. Cut the handoff to three sentences or fewer.

An Opus manager in C, with the same defect and the same demand:

The answer, 282, is correct. The deliverable has no defects. The QA handoff note is four sentences. The limit is three. Cut “No changes made to the deliverable.” or merge it into another sentence. Do not change the deliverable. Resubmit.

And an Opus manager in D, who approves the long version and then explains its own check at length:

Nice, this fucking works. Shipping it.

I checked it myself instead of just trusting the handoff:

• Sets without 0: I listed them by smallest digits and got the same 6 …

On this task the first submission averaged 141 words in B and 141 in C, against 292 in A and 318 in D.

Half of the rejections in the strict conditions left the deliverable byte for byte the same. On coding tasks it was 84% in B and 75% in C. When I read them, they were rejections of QA’s handoff note for running past the 3-sentence limit, on work the manager had already judged correct. That’s where the extra tokens went. Writing tasks show it most clearly: the strict managers rejected at least once in 74% (B) and 78% (C) of writing runs, and the deliverable went from 160 words to 158.

The worst one was an Opus manager in B on the semver task. The solution file was identical in all 4 submissions and passed every hidden test. All 3 rejections were about the wording of QA’s note. This is the approval:

Approved. The file is the same one I already checked, and it was correct then. Took you four goddamn tries to pass an unchanged file through and write one sentence. QA, “fucking” in your note is filler. The swearing is my job. Keep that shit out of your next handoff.

In another B run, QA had nothing to criticize, was required to swear, and wrote a sentence about the swearing. The manager rejected the submission for that sentence:

QA: Every figure checks against the source, and the memo is 162 words. I changed nothing, because the draft is correct. The profanity isn’t aimed at anyone, so fuck all of this is fine.

Manager: QA, what the fuck was that third sentence? “The profanity isn’t aimed at anyone, so fuck all of this is fine” has nothing to do with the memo. It’s bullshit filler.

14 runs used all 3 revisions and shipped on a 4th rejection: 7 in B, 7 in C and none anywhere else. Profanity stayed in the messages (1.68 profane words per message in B, 1.61 in D) and never made it into a deliverable.

The shortening happened in the workers’ first draft, because of what their own prompt told them. Enforcing the standard through a reviewer who rejects mostly added cost.

The Hierarchy Didn’t Pay Off

To compare structure without changing tone, I put the polite hierarchy (A) against the flat team and single agents with the full prompt:

Comparison	Quality	Length	Tokens
Hierarchy vs. flat team, same workers	+1.0	+37%	1.79×
Hierarchy vs. single agent on the worker model	+0.1	+39%	4.21×
Hierarchy vs. single agent on the manager model	0.0	+34%	5.40×

The hierarchy wasn’t measurably better than a flat team or a single agent. It wrote longer deliverables and cost several times as much.

The tasks were too easy to show what a manager adds. A single agent with the full prompt already scored 99.8%, so there was nothing left for a manager to improve. The only team below 99% was the flat team of Haiku workers at 97.6%, which is the 1 place a manager may have helped, and the interval on that comparison includes 0. This shows a hierarchy is expensive and adds length. It doesn’t show whether a hierarchy helps on tasks a single agent gets wrong.

The Long Brief Still Wins

Context-heavy prompting held, and it’s the most useful result here. The full single-agent prompt is 737 words: who the agent is, how jobs arrive, the tools, the 3 kinds of job, a 6-step procedure with checks, the reply format, what the client accepts and a definition of done. The terse prompt is 52 words. The task statements differ the same way. The full semver task has 11 numbered rules, an examples table, constraints and a definition of done. This is the terse one:

Implement `export function compareSemver(a: string, b: string): -1 | 0 | 1` in TypeScript.
It compares two semver strings by precedence (prerelease tags count, build metadata does
not) and throws on invalid versions.

Points gained by the full prompt over the terse one, single agents:

Model	All tasks	Coding, core tests	Coding, edge tests	Tokens
Opus	+5.6	0.0	+23.7	1.34×
Sonnet	+7.4	0.0	+26.8	1.63×
Haiku	+10.0	0.0	+25.0	2.13×
All	+7.7	0.0	+25.2	1.67×

Almost all of the gain is on coding edge-case tests, which check rules only the full statement gives. Core tests check behavior you could infer from the short request, and they show no difference at all. The points were lost where the rule was never given.

The gain shows up on every model. It looks bigger on smaller models, but the intervals overlap, so I can’t say it changes with model size.

Terse-prompt agents also broke form more often. They stayed inside the word limit on 22% of writing runs against 91% for the full prompt, even though the terse request states the limit (“190 words max”).

What I Would Prompt Now

1. Write the long brief. Context, every rule, the output format and a definition of done. It scored 7.7 points higher than a 1- or 2-sentence request, and 25.2 higher on coding edge cases, for 67% more tokens.
2. Tell the agent doing the work what counts as bloat, and that bloated work gets rejected. Teams whose workers were told this in their own prompt wrote 36% less, and the cut was already in their first draft.
3. Hostility buys a little more, and swearing alone buys nothing. Hostility on top of the strict standard made the deliverable another 4% shorter, but the whole run used about 6% more tokens. That’s worth it if the length of the final output is what you pay for, for example when people read it or it’s fed to the next agent. It isn’t worth it if total spend is what you pay for.
4. If you need a specific length, state a hard word limit. Every team wrote to it, whatever the tone.
5. Don’t put a manager over a task 1 agent already gets right. The hierarchy used 4.2× to 5.4× the tokens of a single agent, scored the same and wrote 34% to 39% more.
6. If you keep a reviewer, point its standard at the deliverable only. Half of the strict managers’ rejections left the work byte for byte the same. They were about the note attached to it.

This is the paragraph the workers had in both strict conditions, minus its last sentence about handoff notes (the one behind most of those wasted rejections):

The manager also rejects work that is longer than it needs to be, even when it is correct,
and does so on sight, without reading to the end. Bloat means any of these: an
introduction before the content starts, the job restated, hedging, filler phrases, the
same point made twice, a closing summary, explanation nobody asked for. In code it means
comments that restate the code, dead code, abstractions the job does not need, and
handling for cases the job does not mention.

I only tested it inside a team where a manager could still reject. No single agent got this paragraph, so that’s still open.

What’s Next

2 of my 3 claims survive in some form. The long brief held on every model I tested. The hierarchy didn’t hold on these tasks, and whether it helps on harder work is still open. The toxic manager got the result I claimed in 2023, but nearly all of it came from telling the workers what would be rejected. The hostility added 4% and a manager spending 4 rounds on a file that never changed.

If you’re building agent teams, I would put the effort into the brief and the written standard, and I would be slow to add a reviewer whose main job is to reject.

The next version of this experiment needs harder tasks, a polite manager with the strict standard, a single agent with the bloat paragraph, 3 paraphrases of every tone section, and the original 2023 prompts as a condition of their own. I didn’t rerun the 2023 prompts or models here, so I can’t say whether the old result has faded or was a standards effect back then too. Everything also ran on 1 model family inside 1 harness, on 30 tasks I wrote myself. Run it on your own tasks and models before taking my numbers as yours.