The Deslop Stack Fallacy: Why Style Rules Hurt Thinking Quality

Developer Twitter found a new silver bullet: the instant deslop system prompt.

Stop banning single words like “delve” or “testament” one at a time. Instead, paste an entire writing standard into your global CLAUDE.md or AGENTS.md. Stack Orwell’s 1946 rules, ASD-STE100 Simplified Technical English, ISO 24495-1, and GovUK style guidelines into one prompt block. Every commit message, README, and PR description ships in clean, human prose.

The promise is seductive. The reality is different. Forcing an LLM to follow strict writing constraints while it solves a complex problem creates severe cognitive interference. It destroys thinking quality.

Here’s what actually happens when you deslop at reasoning time.

What the Twitter Advice Actually Says

The advice circulating on X right now sounds like this:

“STOP telling Claude Code/Codex ‘no em dashes’. STOP telling Claude Code/Codex ‘stop saying delve’. STOP telling Claude Code/Codex ‘don’t sound like AI’. You never gave it a writing system.”

“Orwell wrote the fix 80 years ago. Six rules, 1946. Paste them into your global CLAUDE.md / AGENTS.md and every session picks them up: never use a long word where a short one will do, if it is possible to cut a word out cut it out, never use the passive where you can use the active.”

“Experimenting with a rare addition to my global CLAUDE.md: ‘Always talk in ASD-STE100 Simplified Technical English.’”

“I go for the three prong deslop stack: ASD-STE100 + Orwell + GovUK house style.”

The pattern is clear: take a historical writing standard, paste it into your system prompt, and let it run during generation. It sounds reasonable. To understand why it fails, you have to understand what these standards are and why humans created them.

What the Style Rules Actually Are

These frameworks were built for human editors working under specific constraints. They were never designed to run inside a reasoning loop.

ASD-STE100 (Simplified Technical English): In 1986, the European Association of Aerospace Industries created STE for aircraft maintenance manuals. Technicians across the world read these manuals in English as a second or third language. A misread procedure could crash a plane. STE solves this by restricting English to a controlled dictionary of about 1,000 approved words. Words can only function as one part of speech. “Close” is approved only as a verb, never as an adjective. Sentences cap at 20 words for instructions. Passive voice is forbidden.

Orwell’s Six Rules (1946): Orwell wrote Politics and the English Language to fight political propaganda and evasive jargon. His rules emphasize cutting spare words, using active verbs, and choosing short words over long ones. He was combatting dead metaphors that concealed uncomfortable truths.

GovUK, ISO 24495-1, W3C COGA: These standards were built for public services. They ensure citizens of all literacy levels can pay taxes, apply for benefits, or navigate healthcare forms without getting stuck in bureaucratic prose. ISO 24495-1 formalized plain language principles internationally. W3C COGA extended them for cognitive accessibility.

Why developers imported them: LLM outputs were filled with hyperbole, inflated symbolism, and passive academic framing. Developers saw STE, Orwell, and GovUK as a fix. If aerospace technicians used STE to prevent plane crashes, why not force LLMs to write in STE from the start?

The mistake is assuming that a rule system designed for human post-editing works as an inline constraint for an AI reasoning engine. Aerospace writers draft technical procedures, then edit them against STE. When you force an LLM to generate in STE during its reasoning pass, you force it to solve the problem and satisfy rigid lexical constraints at the same millisecond.

The Data: Anand’s Experimentation

I came across a blog from Anand. Anand tested this tradeoff empirically. He ran six complex reasoning tasks through ChatGPT (GPT 5.6 Sol) under two conditions: a standard prompt, and the same prompt with "Answer in ASD-STE100" appended.

The six tasks covered deep analytical work: designing non-saturating agent benchmarks, diagnosing support ticket surges, evaluating startup runway under doubled churn, testing AI decision quality, evaluating benchmark beliefs, and designing adversarial agent systems.

The Evaluation Protocol

To prevent bias toward longer or more sophisticated answers, Anand used a blind, position-swapped rubric. Every response pair was evaluated twice, swapping the order (A, B) and (B, A) to eliminate position bias. The rubric judged six criteria on content only: Correctness, Key Drivers, Mechanism, Caveats, Calibration, and Actionability. Plainly worded answers and technical answers that made the same point were scored as equal. The rubric explicitly instructed the evaluator to ignore reading level, vocabulary, sentence length, and word count.

The Results

The standard prompt won 11 out of 12 evaluations. The STE prompt won zero. One tied.

Task	Standard Sources	STE Sources	Standard Thinking Time	STE Thinking Time	Winner
1	66	44	1m 31s	41s	Standard
5	123	84	2m 04s	5m 04s	Standard
6	97	26	2m 20s	3m 44s	Standard

Tasks 2, 3, and 4 did not report source counts, but the rubric evaluations were just as decisive. The standard prompt won on Correctness, Key Drivers, Mechanism, Caveats, Calibration, and Actionability across all six task families.

Three Ways the STE Prompt Destroys Thinking

The data reveals three specific failure modes:

Source retrieval collapsed. On Task 1, source count dropped from 66 to 44. On Task 6, it fell from 97 to 26. The model spent less time searching for evidence because lexical compliance ate its attention budget.

Causal mechanisms disappeared. On Task 2, the standard answer identified Simpson’s paradox, case-mix distortion, duplicate ticket IDs, and premature case closures. The STE answer reduced these to high-level assertions. It stated that failures occurred without explaining why.

Nuance and edge cases were dropped. On Task 3, the STE prompt failed to distinguish between logo churn and revenue churn or quantify retained gross profit. Restricted vocabularies penalize hedged claims and conditional statements. The model dropped critical risk factors to stay within vocabulary rules.

Anand’s conclusion was stark: forcing a model to answer in ASD-STE100 reduces its thinking quality.

Why Constrained Generation Kills Reasoning

When an LLM generates text, every token prediction is a joint probability distribution over vocabulary, domain facts, and logical structure. When you force style constraints into the solver prompt, you turn a broad generation task into a constrained search problem.

%%{init: {"layout": "dagre"}}%%
flowchart TD
    A[Single-Pass Prompt with Deslop Rules] --> B[LLM Reasoning Pass]
    B --> C{Token Selection}
    C -->|Spends Tokens Checking Rules| D[Lexical Compliance: Short Words, Active Voice]
    C -->|Loses Probability Mass| E[Deeper Search: Causal Proofs, Long-tail Sources]
    D --> F[Shallow, Simplified Output]

    G[Two-Stage Pipeline] --> H[Stage 1: Solver Pass]
    H --> I[Unconstrained Reasoning: Deep Mechanisms, Full Nuance]
    I --> J[Stage 2: Editor Pass]
    J --> K[Lexical Transformation: Apply ASD-STE100 and Orwell Rules]
    K --> L[Clear, High-Quality Deliverable]

The key insight: An LLM has finite probability mass and attention capacity per token. If the model spends capacity checking whether a word violates ASD-STE100 or Orwell’s passive voice rule, it has less capacity to explore alternative hypotheses, retrieve long-tail facts, or construct multi-step causal proofs.

The model optimizes for the most immediate loss signal in the prompt. When style rules are present in the system instructions, lexical compliance competes directly with task accuracy.

The Fix: Reason First, Deslop Second

The solution is not to give up on clear language. Concise, direct prose remains essential for documentation, PR descriptions, and agent communication. The fix is separating reasoning from formatting into a two-stage pipeline. The Editor Pass is where your style rules belong.

Stage 1: The Solver Pass

Give your primary agent zero writing constraints. Let it write in dense technical prose, use precise jargon, include hedges, and cite sources.

# Stage 1: Solver Prompt Policy
task: "Analyze the codebase and propose an architecture refactor."
constraints:
  - Optimize purely for correctness, mechanism depth, and completeness.
  - Do not restrict vocabulary, sentence length, or technical terms.
  - Explore edge cases, trade-offs, and counterfactuals explicitly.
  - Include exact code references, data structures, and failure modes.

Stage 2: The Editor Pass

Pass the finalized output from Stage 1 into a fast post-processing pass. This secondary prompt applies Orwell’s rules, ASD-STE100, or your team style guide to the completed reasoning artifact.

# Stage 2: Editor Prompt Policy
task: "Rephrase the provided technical analysis for the team."
input: "{{ stage_1_output }}"
style_rules:
  - Apply ASD-STE100 and Orwell's 1946 plain English rules.
  - Never use a long word where a short word will do.
  - If it is possible to cut a word out, cut it out.
  - Prefer active voice over passive voice.
  - Remove AI stock phrases: "delve", "testament", "crucial role".
  - Do not alter technical facts, code snippets, or underlying logic.

Why this works: The editor model receives a fully reasoned solution as context. Its only task is lexical transformation, so constraint satisfaction no longer degrades problem solving.

The Bottom Line

Putting style rules, ASD-STE100, or Orwell’s checklist into your global solver prompt is a mistake. You buy stylistic cleanliness at the expense of analytical depth.

Allow your models to think in unconstrained, technical prose when solving problems. Once the solution is solid, run a dedicated editor pass to clean up the language.

Separate your thinking engine from your formatting engine.

Designing AI agent workflows or prompt architecture? I’d love to hear how you structure solver vs editor passes. Reach out on LinkedIn.