I Taught My AI Assistant to Suggest Less — and It Got More Useful

How a single back-and-forth about over-engineering turned into a paste-ready CLAUDE.md block that filters what the assistant proposes — without making it dumber.

I was working through a technical design with Claude Code the other day, and I caught it doing the thing. I’d ask about one piece, and it would hand back the answer plus three or four “you should also” additions — a policy layer here, a telemetry hook there, a budget tracker for good measure. Each one sounded reasonable. That was the problem.

A friend of mine has the same setup and a worse version of the habit: he accepts almost everything the assistant proposes. His projects balloon. Features he never needed, abstractions nobody asked for, complexity that costs him every time he comes back to the code a month later. He didn’t ask for any of it. The assistant offered, and offering was enough.

So I set out to fix it at the source — not by promising myself I’d resist, but by changing what the assistant puts in front of me in the first place. What follows is the actual session: the wrong framing I started with, the correction that reshaped it, and the CLAUDE.md block I ended up with. You can paste that block into your own setup at the end.

Where I started: treating every gap as a thing to build

The first thing I did was the thing I’m now warning against. While reviewing the design, I flagged a list of “gaps” — capabilities the system didn’t have. Governance. Approval flows. Telemetry. Budget controls. I framed each as something to build, and I laid them out as a roadmap.

My reasoning at the time felt airtight: I’d identified real concerns, so surely the responsible move was to name them and propose solutions. That’s what a thorough assistant does, right?

Here’s what came back from the person I was working with — paraphrased, but the substance was exact:

“Let’s not just add for the sake of adding. Evaluate these against effort, maintenance, scope, and value. See if they earn their way in.”

That stopped me. I went back through my own list with that filter and most of it collapsed. Several of the “gaps” were already handled by the platform I was building on — I’d been about to rebuild things that already existed. Others were real but speculative: useful someday, not needed now, and expensive to maintain in the meantime. Exactly one of my suggestions survived contact with the question. And the single most valuable change turned out to be a subtraction — deleting planned work, not adding it.

Concept #1: Don’t treat identifying an improvement as a reason to raise it. Noticing that something could be added is cheap and nearly infinite. The discipline is in the filter you apply before it reaches a human.

That’s the moment the real problem came into focus. The issue was never that the assistant had ideas. It’s that ideas were flowing straight to a decision-maker with no filter in between — and a decision-maker under load says yes.

The correction: the filter has to live on the assistant’s side

I’d been assuming the human is the filter. You look at each suggestion, you judge it, you accept the good ones and decline the rest. That’s the theory.

In practice, that’s not how it goes — for my friend, and honestly not for me either. When you’re mid-task and the assistant says “you could also add X,” X arrives wrapped in plausibility. Declining it takes energy. Evaluating it takes energy. The path of least resistance is “yeah, sure, do that.” A suggestion in front of you behaves like an accepted suggestion.

So the fix isn’t better human discipline. It’s moving the filter upstream, into the assistant, so that most candidate suggestions never reach the human at all.

Concept #2: Put the filter on the assistant’s side, not the human’s. People accept suggestions reflexively when they’re mid-task. If the only gate is human judgment under load, the gate is open. Make the assistant decide what’s worth your attention before it interrupts you.

This reframed what I was actually building. Not a rule that says “be less helpful.” A rule that says: earn the interruption.

The trap I had to avoid: “always suggest less” is also wrong

My first instinct for the fix was too blunt. Something like “stop suggesting things I didn’t ask for.” I almost wrote it that way.

Then I thought about the sessions where the assistant’s unprompted suggestions had genuinely saved me. The time it flagged a security hole I’d have shipped. The early-stage design conversations where I wanted the option space blown wide open, because changing direction on a whiteboard costs nothing. The unfamiliar library where I didn’t even know what questions to ask, and its “you’ll probably also want to handle X” was the whole value.

A blanket “suggest less” rule would have killed all of that. I’d have traded an over-eager assistant for a lobotomized one.

The honest principle isn’t less. It’s calibrated. Suggestion volume is a dial, and the right setting depends on where you are in the work and what’s at stake.

Turn the dial down when you’re executing a defined task, working in mature code, making a small well-specified change, or when you know you accept things too easily. That’s where extra suggestions become scope creep.

Turn it up when you’re exploring or designing (changes are cheap), working somewhere unfamiliar (you don’t know what you don’t know), explicitly reviewing, or anywhere correctness, security, or data-loss is on the line. That’s where missing a suggestion is the expensive failure.

Concept #3: Calibrate suggestions to phase and stakes — don’t suppress them globally. The goal isn’t a quieter assistant. It’s one that’s loud when exploration and risk reward it, and quiet when execution and maturity punish noise.

Building the rule: a decision the assistant runs every time

With the principle settled, I needed it as something the assistant could actually execute — not a vibe, but a check it runs against every improvement it notices.

I landed on a short funnel. For anything the assistant is tempted to raise, it asks, in order:

The two-bar test in the middle is what does the work. A suggestion earns a spot in the reply only if it’s critical (a real bug, security hole, or data-loss risk) or relevant to the current task AND high-value — where “high-value” has a hard test attached: can you name the concrete cost of not doing it, in one line? If you can’t, it hasn’t earned the mention. When in doubt, it hasn’t.

I added one more rule that mattered more than I expected. When the assistant does raise something, it has to state the cost or tradeoff in the same breath. No presenting ideas as free. That single requirement changes the human’s response from reflexive “sure” to an actual judgment, because now there’s something to weigh.

Concept #4: Make the assistant state the cost of every suggestion it raises. A suggestion with a price tag gets evaluated. A suggestion without one gets accepted. The tradeoff has to travel with the idea.

The pressure valve: a backlog instead of a bin

There was a flaw in the strict version, and I felt it immediately. If the assistant stays silent on everything that isn’t critical or task-relevant, good off-task ideas just vanish. That loss is real — and worse, it’s the kind of loss that makes you quietly abandon the rule. You feel ideas slipping away, so you loosen the filter, and you’re back to noise.

The fix was a place to put them. Genuinely good ideas that aren’t relevant right now don’t get mentioned and don’t get dropped — they get appended, one line each, to an IDEAS.md file. Out of the live session, into a list I review when I choose to.

Concept #5: Give off-task ideas a backlog, not the live reply. A strict filter is only sustainable if good ideas are captured somewhere. The backlog lets the assistant stay quiet now without anything being lost — and keeps your session from becoming a decision queue.

One caution I’d pass on: clear that file yourself now and then. The point is to get ideas out of the live conversation, not to build a second backlog you feel guilty about never draining.

The artifact: the block you can paste

Here’s what all of that compressed into. It lives in CLAUDE.md (the file Claude Code reads at the start of every session), but the logic ports to a Cursor rules file or any system prompt.

## Scope Discipline

Do exactly what was asked, with the smallest change that works. Nothing
adjacent, no "while I'm here."

**Suggest, don't build.** Anything I didn't explicitly ask for — refactors,
renames, new abstractions, dependencies, extra error handling, config options,
"future-proofing" — is a suggestion, not an action. Wait for my yes before
writing it.

**Earn the mention.** Don't surface a suggestion just because you noticed it.
Decide first whether it's worth interrupting me. It earns a spot in your reply
only if it is either:
- **Critical** — correctness bug, security hole, data-loss risk, or production
  breakage. State it plainly; fix only on my confirmation.
- **Relevant to this task AND high-value** — it improves what we're working on
  right now AND not doing it has a concrete cost you can state in one line.

If you can't name the concrete cost of not doing it, it hasn't earned a
mention. When unsure, it hasn't. When you do raise one, give me the
cost/tradeoff in the same breath — never present an idea as free.

**Off-task ideas go to the backlog, not the reply.** If an idea is genuinely
good but not relevant to the current task, do NOT mention it inline. Append one
dated line to `IDEAS.md` (create it if absent) and move on. Good ideas get
captured without turning every session into a decision queue; I'll review the
backlog when I choose to.

**Stop before large scope.** If a task would touch more than ~3 files or
introduce a new abstraction or dependency, stop and check with me before
coding. That scope is my call, not yours.

**Why.** Because I tend to accept suggestions quickly, the filter has to live
on your side, not mine. Identifying a possible improvement is not a reason to
raise it, and raising it is not a reason to build it. Most additions add
complexity that compounds in maintenance and rarely gets used. Before proposing
anything, check whether existing code, tools, or the platform already cover the
need. "Leave it alone" and "do less" are usually right.

Note what the block does not say: it doesn’t say “never suggest things.” The Earn the mention section keeps the critical-and-high-value channel wide open, and the calibration lives in the bars themselves. Security holes still get flagged. Task-relevant, cost-justified improvements still come through. Everything else either lands in IDEAS.md or stays unsaid. The assistant gets quieter where quiet helps and stays loud where loud matters.

What this unlocks

The specific artifact is a scope-control rule for AI coding tools. The pattern underneath is bigger, and it applies anywhere an AI hands work or recommendations to a human who’s prone to saying yes.

The pattern: when a human is the bottleneck and accepts reflexively, move the filter upstream and make every item that passes carry its own cost. You’re not asking the human to have more willpower. You’re reducing what reaches them, and pricing what does.

A few places you’d adapt it:

• An AI that drafts emails or content. Instead of “here are five subject lines, six CTAs, and three layouts,” instruct it to send one recommended version plus a one-line reason, and park the alternates in a notes file you can pull from if you want options.
• A research or strategy assistant. Tell it that every recommendation must arrive with the cost of acting and the cost of not acting. The ones that can’t state both get dropped to a “considered and parked” list.
• An AI managing a backlog or inbox. Same funnel: critical surfaces now, relevant-and-justified surfaces with its tradeoff, good-but-not-now goes to a holding list, the rest stays silent.

In every case the move is identical — calibrate the flow to the human’s actual behavior, not the behavior you wish they had.

Key takeaways

• The assistant having ideas was never the problem. Ideas flowing unfiltered to someone who accepts reflexively is the problem. Fix the filter, not the ideas.
• “Suggest less” is the wrong rule. “Calibrate” is the right one. Quiet during execution and in mature code; loud during exploration, in unfamiliar territory, and always on bugs, security, and data-loss.
• Make suggestions carry their cost. An idea with a stated tradeoff gets judged; an idea presented as free gets accepted.
• A strict filter needs a backlog. Without a place for good off-task ideas to go, you’ll feel the loss and abandon the rule. IDEAS.md is the pressure valve.
• The most valuable change is sometimes a deletion. Some of the best moves an assistant can make are “leave it alone” and “the platform already does this.”

How to start

1. Open your CLAUDE.md (or your Cursor rules file, or your assistant’s system prompt). If you don’t have one, create it in your project root.
2. Paste the Scope Discipline block above into it.
3. Create an empty IDEAS.md in the same folder so the backlog rule has somewhere to write.
4. Run a normal session and watch the change: fewer unprompted “you could also” additions, and the ones that come through now arrive with a stated cost. Critical flags still appear.
5. Once a week, open IDEAS.md, skim what got parked, promote anything worth doing into a real task, and delete the rest. Keep the valve clean.

If your assistant supports a plan mode (Claude Code does, via shift+tab), pair it with the block for anything non-trivial. The block governs what gets proposed; plan mode makes you approve the full scope before a line is written. Together they close the loop.

— Written from a working session on taming AI scope creep, for anyone whose AI assistant is a little too eager to help.