Words That Push Back

A companion cluster for Chapter 3. The rest of that chapter teaches you to decode the vocabulary Claude reaches for. This section runs the other direction: a small set of words you say to Claude to redirect it — each one a single token that lands a correction it would otherwise take a paragraph to make.

Why these words have leverage

Every term in this section is a piece of engineering culture Claude absorbed during training. Blog posts, code reviews, Stack Overflow threads, and conference talks are full of a senior engineer writing one of these words to reject an over-built change. So when you use the word, you aren’t just issuing an instruction — you’re activating a whole cluster of associated behavior that already lives in the model. “YAGNI” pulls in strip the speculative parts, solve only the stated problem, stop gold-plating without you having to spell any of that out.

That’s the payoff: one word does the work of a sentence like “please don’t add the abstraction layer, don’t add config options I didn’t ask for, don’t handle cases that aren’t in the requirement — just do the specific thing I described.”

Most of these words share a target. Almost every pathology in Chapter 9 is a symptom of the same engine — additive bias, Claude’s standing tendency to reach for more. The words below are the vocabulary for pushing back against that engine at the moment it fires. (One entry, over-index, aims a step upstream — at the misjudged priority that so often produces the addition in the first place — and its entry marks the difference.)

The one caveat, up front

Each of these is a scalpel, not a hammer, and the whole cluster shares a single failure mode worth stating once here rather than repeating under every entry:

There is a legitimate version of “extra.” Input validation, error handling, the edge case that genuinely will occur — these look additive but are not gold-plating. A reader who swings these words too hard can talk Claude out of defenses it was right to include.

“Remove the speculative stuff” and “remove the safety checks” are different requests, and to Claude — mid-generation, optimizing for a clean-looking result — they can look like the same request. Knowing which is which is the experienced-developer instinct this whole book is about. If you’re a non-developer wielding these words, the safe habit is to ask Claude what it removed after you push back, and to treat “I dropped the error handling” as a red flag, not a win. (See Chapter 9 on Silent Error Swallowing for the specific danger.)

YAGNI

“You Aren’t Gonna Need It.” The anchor of this cluster. A principle from Extreme Programming: don’t build something until you actually need it. Don’t add the config option, the abstraction layer, the plugin system, or the extra function parameter on the theory that it might be useful someday. Build for the requirement in front of you.

Why Claude responds to it: YAGNI is the single most direct counter to additive bias, and Claude knows the term cold — it’s attached in the training data to exactly the behavior you want to suppress. Ask for a function that reads one file and you may get one that also accepts a URL, handles three formats you never mentioned, and takes an options object “for extensibility.” “YAGNI” is the word that says cut all of that.

How to say it:

• Pre-emptively, in the prompt: “Write a function that parses this one date format. YAGNI — I don’t need a general date parser.”
• As a reaction: “This is over-built. YAGNI. Give me just the version that handles the case I described.”
• As a standing instruction: drop “Apply YAGNI” into CLAUDE.md to bias the default toward restraint across the whole project.

See also: Gold-plating , Premature abstraction , Over-engineering ; Chapter 5 (YAGNI as a durable principle — what good looks like); Chapter 9 (Speculative Complexity, Phantom Requirements — the pathologies YAGNI names).

Gold-plating

Adding polish, features, or robustness beyond what the requirement asked for — making the deliverable “nicer” than the spec, at a cost in complexity nobody agreed to pay. Where YAGNI targets speculative structure (abstractions, extension points), gold-plating targets speculative finish: the extra flag, the prettier output, the third export format, the handling for an input that will never arrive.

Why Claude responds to it: “Gold-plating” is the classic name for Claude’s Phantom Requirements pattern — reading between the lines of your request and building the “obviously implied” feature that you never validated as a real need. Naming it as gold-plating tells Claude the addition was unwanted specifically because it exceeded the ask, not because it was wrong on its own terms.

How to say it: “This is gold-plating — I asked for X and you built X plus a settings panel. Drop the extras and keep X.”

See also: YAGNI , Scope creep ; Chapter 9 (Phantom Requirements).

Scope creep

The requirement quietly growing beyond what was agreed — each step reasonable on its own, the sum well past the original ask. Gold-plating is usually one over-built response; scope creep is the drift across a conversation, where “while I’m in here” additions accumulate until the change is three times the size it needed to be.

Why Claude responds to it: Claude is an eager collaborator and a fluent one, which makes it a natural scope-creep engine — it will happily fold “and I also refactored the neighboring module, updated the tests, and added a helper” into a change you asked to be small. “Scope creep” names the drift as the problem, which is more precise than objecting to any single addition (each of which Claude can defend as reasonable).

How to say it: “That’s scope creep — I asked you to fix the one bug and you’ve touched six files. Revert the unrelated changes and show me just the fix.” Pairs well with asking for a minimal diff (below).

See also: Gold-plating , Minimal diff ; Chapter 9 (Sidecar Proliferation).

Premature abstraction

Building a general, reusable structure before you have enough real cases to know what the right generalization is. The sibling terms travel together and Claude knows all of them: premature optimization (making it fast before making it work, or before you know what’s slow), and speculative generality (Martin Fowler’s code smell — machinery built for a flexibility no caller has asked for). Reach for whichever fits: abstraction for a needless interface or base class, optimization for needless performance machinery, speculative generality for the catch-all.

Why Claude responds to it: These are canonical code smells with a long paper trail, so the terms carry specific corrective weight. “Premature abstraction” tells Claude the problem isn’t that the abstraction is badly built — it’s that it’s too early, built on one example when a sound abstraction needs several. That’s a different fix (inline it, wait for the third case) than “make the abstraction better.”

How to say it: “This is premature abstraction — there’s exactly one caller. Inline it and we’ll extract an interface if a second use case ever shows up.” / “Don’t optimize this yet, that’s premature — make it correct and readable first.”

See also: YAGNI , Over-engineering ; Chapter 5 (“make it work, make it right, make it fast” — in order); Chapter 9 (Speculative Complexity, Premature Maturity).

Over-engineering

The plain-English umbrella for the whole family — a solution more complex, more layered, or more clever than the problem warrants. Use this when you can feel that a change is too much but can’t name precisely which sub-pathology it is (abstraction? gold-plating? speculative generality?). “This is over-engineered” is a valid, understood push-back on its own, and it invites Claude to identify and strip the excess rather than requiring you to diagnose it.

Why Claude responds to it: It’s the word engineers use in review when the specific smell doesn’t matter and the verdict does. It reliably prompts Claude to produce a simpler alternative — which is exactly the move you want. Its close cousins over-built and over-complicated work identically; pick whichever reads naturally.

How to say it: “This feels over-engineered for what I asked. What’s the simplest version that still does the job?” — Asking for “the simplest version that still does the job” is the constructive half of the correction: it sets the target, not just the complaint.

See also: everything above; Chapter 5 (Simplicity — simpler changes when all else is equal).

Over-index

Giving a concern more weight than it deserves — treating a secondary consideration as if it were decisive. Borrowed from statistics and finance, where a fund is “over-indexed” on a sector when it holds more of it than the benchmark warrants, the term crossed into engineering and product culture to mean a misallocation of attention: you’re spending your judgment on the wrong variable.

The odd one out in this cluster — and why it earns its place. Every other word here vetoes an addition (“you built too much”). Over-index vetoes a weighting (“you’re fixating on the wrong thing”). It sits one step upstream of the others: the misjudged priority is often what produces the addition — Claude over-indexes on backward compatibility, and therefore adds the compatibility shim; over-indexes on a rare input, and therefore adds the guard. But the correction lands earlier, on the judgment call itself, which is why it works even when the fixation hasn’t yet turned into code — when Claude spends three paragraphs defending a concern that doesn’t matter for the case in front of you.

Why Claude responds to it: It’s well-worn product- and code-review vocabulary, attached in the training data to precisely “you’re giving disproportionate weight to a minor factor.” Crucially, it corrects without dismissing: “over-indexing on X” concedes that X is a real concern in general while saying it’s over-weighted here. That’s a more surgical redirect than “ignore X,” which Claude may resist because X genuinely is a valid consideration — just not the load-bearing one for this decision.

How to say it:

• As a reaction: “You’re over-indexing on backward compatibility — this is a throwaway script, nothing else calls it. Just change the signature.”
• To reset priorities: “You’re over-indexing on performance. This runs once a day; make it correct and readable and stop optimizing.”
• To redirect attention: “You’ve over-indexed on the error path and under-indexed on the happy path I actually asked about.”

The caveat, in this term’s specific shape: the shared warning at the top of this section bites here too, but differently. With the additive-bias words the risk is stripping real robustness; with over-index the risk is waving off a concern that was correctly weighted. Sometimes Claude is “fixating” on backward compatibility because something really does depend on the old behavior and Claude has inferred it from the code. Before you tell Claude it’s over-indexing, be sure the concern really is secondary — the whole point of this book is that telling the difference is the experienced-developer instinct. If you’re not sure, ask why Claude is weighting it so heavily before you overrule the weighting.

See also: YAGNI , Over-engineering ; Chapter 9 (the pathologies a misjudged priority tends to produce); Chapter 5 (“make it work, make it right, make it fast” — an ordering of concerns, which is what over-index polices).

Minimal diff (the constructive counterpart)

Every word above is a veto. This one is the positive instruction that prevents the problem instead of reacting to it: ask for a minimal diff — the smallest change that satisfies the requirement, touching as few lines and files as possible, with unrelated code left alone.

Why it works: It converts “don’t do too much” (a negative Claude has to interpret) into “do exactly this much” (a target Claude can aim at). It’s especially effective against scope creep, because it makes touching an unrelated file a visible violation of the stated goal rather than a helpful bonus. Related phrasings Claude honors: “keep it minimal,” “surgical change,” “don’t refactor anything you don’t have to.”

How to say it: “Give me the minimal diff that fixes this — smallest change, no drive-by refactors, don’t touch files unrelated to the bug.”

See also: Scope creep ; Chapter 9 (blast-radius triage — scale scrutiny to the size of the change).

Quick reference

Reminder: each of these targets speculative additions, not necessary robustness. If a push-back makes Claude remove real error handling or a real edge case, that’s the caveat at the top of this section biting — ask what it dropped, and put back anything that was actually load-bearing.

Found something wrong, unclear, or plainly disagreeable? Open an issue