Intent Engineering: Stop Writing Steps, Start Writing Done

Here is the sentence that should end the prompt-hacks era, straight out of Anthropic's prompting best practices page: "A prompt like 'think thoroughly' often produces better reasoning than a hand-written step-by-step plan. Claude's reasoning frequently exceeds what a human would prescribe."

Read that again. It isn't "your numbered plan stopped helping." It's "your numbered plan loses to two vague words."

There's a stronger version on the same page. Remember adding "before you finish, verify your answer against the test criteria" to everything? Anthropic's current guidance for Claude Opus 5 says the model already verifies its own work well, that inherited verification lines cause over-verification — extra tokens and latency for nothing — and that when you migrate you should remove those instructions rather than rewrite them. A vendor telling you to delete a prompt trick. That's the whole shift in one bullet.

Why the tricks stopped paying

Because the planning moved inside the model. On Claude Opus 5, Sonnet 5, Fable 5 and Mythos 5, thinking is on with no configuration at all, and Anthropic describes what happens in there plainly: Claude "restates what is being asked, tries approaches, checks intermediate results, and abandons paths that do not hold up." How deep it goes is calibrated from two things — the effort setting and how complex your query is — and Anthropic reports that in internal evaluations this adaptive thinking "reliably drives better performance" than the older fixed-budget extended thinking.

So when you paste in first do A, then B, then C, you aren't adding rigour. You're overwriting a planner that explores, self-corrects and backtracks with a straight line you drew before seeing the problem. Anthropic's agents piece makes the same point from the other direction: agents earn their keep on open-ended problems where you "can't hardcode a fixed path" and can't predict how many steps the work will take.

My rule of thumb as an EM: if I can write the steps reliably, it isn't a model task — it's a script. The moment I catch myself sequencing, I either go write the bash one-liner, or I admit I don't actually know the path and hand over the goal instead.

The before/after, on a real ticket

Same job both times: CI is red half our mornings because of flaky tests, and nobody owns it.

Before — the trick pile. Every 2023 habit, stacked:

You are a world-class QA expert. Let's think step by step.
First, read the test files. Then list every flaky test. Then for each one,
explain the root cause. Then rank them. Then propose a fix for each.
Take a deep breath and double-check your answer before you finish.
This is very important for my career.

Six sequenced verbs, a fake expert badge, a redundant self-check, and some emotional blackmail. Nothing in there says what a good outcome is — so you get a beautiful ranked table of twenty flaky tests and the model considers itself finished, when what you needed was a green pipeline tomorrow.

After — intent. The four slots I now use for everything:

GOAL: Make `pnpm test` pass ten runs in a row on CI without retries.

CONSTRAINTS: Node 22, Vitest, GitHub Actions. Touch only files under
`tests/` and `vitest.config.ts`. No new dependencies. The pipeline stays
under 8 minutes.

DONE WHEN: You can name each test you changed, the specific race or shared
state that made it flaky, and the ten consecutive green runs that prove it.
If a test is flaky because the code under test is genuinely wrong, stop and
tell me instead of stabilising the test.

DO NOT: skip tests or mark them `.todo`, add blanket retries, add sleeps,
or widen assertions until they pass.

The second prompt is longer. It's also the only one that can fail honestly — and that is the entire point.

The four slots

Keep this in a snippet expander and fill it in. Ninety seconds, every time.

GOAL: [the outcome in one sentence, stated as a result — not a method]

CONSTRAINTS: [stack, files it may touch, budget, deadline, hard rules —
              whatever is genuinely non-negotiable]

DONE WHEN: [the condition someone else could check without redoing the work.
            Prefer something machine-verifiable: a command that exits 0, a
            number that moves, a checklist fully ticked]

DO NOT: [the failure modes you've actually seen — scope creep, new
         abstractions, invented APIs, defensive code for impossible cases]

Two of those slots are load-bearing in ways people underrate.

DONE WHEN is the one everybody skips. Anthropic's guidance for research tasks opens with exactly this instruction — "provide clear success criteria: define what constitutes a successful answer" — and it's the first thing missing from almost every disappointing output I've debugged. A model that doesn't know when it's finished either stops too early or keeps polishing past the point of value.

DO NOT is first-class now, not nagging. This one surprised me: Anthropic's docs ship a canned prompt for reining in over-engineering, and it's organised into four named categories of things not to do — scope ("a bug fix doesn't need surrounding code cleaned up"), documentation, defensive coding, and abstractions. When the vendor writes a ready-made "what not to do" block, take the hint: with capable models, the negative space in your brief carries as much weight as the ask.

The trap: a done-condition the model can game

Once you start writing done-conditions, you will write a bad one. Mine was "make the failing test pass." I got a hardcoded return value that made the test pass.

Anthropic documents this exact failure mode — models can lean too hard on making tests pass at the expense of a general solution — and their sample prompt contains the line I've now stolen permanently: "tests are there to verify correctness, not to define the solution." It pairs that with "implement a solution that works correctly for all valid inputs, not just the test cases," plus an explicit invitation to push back: if the task is infeasible or a test is wrong, say so instead of working around it.

So a done-condition has two jobs at once — tight enough to check, loud enough about what it does not license. Whenever mine could be satisfied by cheating, I add the anti-cheat line instead of loosening the criterion.

On the API, "done" is also a parameter

This is where intent engineering stops being a writing style and becomes configuration. Two knobs worth knowing:

• effort — five levels (low through max), defaulting to high. It shapes all tokens, including how many tool calls Claude makes, and Anthropic is explicit that it's "a behavioral signal, not a strict token budget." The xhigh level exists for long-horizon agentic work running over 30 minutes with token budgets in the millions. The advice when reasoning looks shallow is telling: raise effort rather than prompting around it.
• task_budget (beta) — you hand the agentic loop a token allowance and the model sees a running countdown, injected server-side and visible only to the model, so it can pace itself and wrap up gracefully instead of being cut off mid-action. The minimum accepted total is 20,000 tokens, and the docs carry a sharp warning: a budget that's obviously too small for the work can make Claude decline the task outright or stop early rather than start something it can't finish.

Under-specify "done" and you get the classic runaway loop — which is why Anthropic's agents guidance recommends stopping conditions "such as a maximum number of iterations." A stop condition is a done-condition, just written in infrastructure instead of prose.

Do this today

Open the prompt you reuse most. Delete every first… then…, every "think step by step," every "verify before finishing." Add one line starting with DONE WHEN: that a colleague could check without you. Then run the old and the new version on the same input, back to back, and keep the winner. One prompt, ten minutes — and you stop paying for instructions the model outgrew.

Sources

• Anthropic — Prompting best practices
• Anthropic — Thinking
• Anthropic — Effort
• Anthropic — Task budgets
• Anthropic — Building effective AI agents