Prompting modern Claude (4.7) correctly
Last Tuesday I asked Claude to "review the auth module." Eight months ago that prompt would have given me a thoughtful walk-through — flagged the obvious issues, made a few suggestions I half-expected. This time I got six generic bullets. Two were useful. The rest read like checklist filler someone left in the room.
The model wasn't worse. My prompt was.
I want to argue something specific in this post: the jump from Claude 4.6 to 4.7 is not the kind of upgrade where you keep doing what you were doing and quietly enjoy better answers. The contract changed. 4.6 tried to figure out what you meant. 4.7 does what you said. If your habits formed in the "Claude will fill in the gaps" era, they will quietly rot your output until one day you can't trace where the drift started.
The compiler turned on strict mode
Here's the metaphor that finally made it click for me. You know that feeling of writing TypeScript with any scattered everywhere, then flipping on strict and watching the editor erupt? That is roughly what happened between 4.6 and 4.7. The model stopped inferring your intent and started honouring your declarations.
"Summarise this PR" used to give you something proportional to a normal-shaped reply. Now it gives you something proportional to your input. Paste 4,000 lines of diff and "summarise" returns a multi-page brief. The model is no longer rounding to a sensible shape. It is executing what you typed.
That sounds annoying until you remember it's the property you'd want in any tool you depend on. Inference is convenient until it's wrong — then you waste ten minutes regenerating, re-prompting, second-guessing. With 4.7 the unit of feedback is the prompt itself. When the answer is wrong, you can usually point at the missing constraint.
Ruben Hassid's piece on the new prompting rules is a decent walk-through of Anthropic's official consumer guide. Worth a read. But the consumer framing buries the bit that actually matters if you write code for a living: 4.7 reads your prompt like a spec, not a vibe.
Code review, before and after
Concrete example. I'm cleaning up a billing service and I want Claude to flag issues before I touch anything. The prompt I'd have used on 4.6 — the one that worked fine on 4.6 — looked like this:
review src/services/billing/ for problemsOn 4.7 that prompt has one firm constraint and two free variables. "Problems" is undefined. "Review" is undefined. The output is a generic checklist because I asked for a generic checklist.
Here is the same intent written as a spec:
Read the files under src/services/billing/. Produce a
markdown table with columns: file, line, severity
(high/medium/low), issue, suggested fix. Restrict to
issues that would block a production deploy. No more than
12 rows. Do not modify any code.That second prompt is uglier. It is also a few times more useful, because every choice I don't make gets made for me, and 4.7 makes those choices literally rather than thoughtfully. Name every output. Name the format. Name the cap. Name the boundary on what counts as in-scope.
The same trap shows up with negatives. "Don't include marketing fluff" reliably produces marketing fluff on 4.7 — the model anchors to the literal sentence instead of rounding to the obvious intent. "Use only technical language; no adjectives stronger than 'significant'" gives me what I wanted. The rule I now follow: stop telling the model what to avoid, tell it what to produce.
The adaptive thinking trap
There's a quieter change that bites engineers harder than the style shift: 4.7 doesn't reason by default. Anthropic calls this "adaptive thinking" — the model decides whether to engage the slow path based on the task. Sometimes it does, sometimes it doesn't, and from the outside you can't always tell which run you got.
For routine work this is fine. For anything where being wrong is expensive, it's a footgun. You get a confident, fast, shallow response and assume the model thought it through. It didn't.
The fix is unglamorous: append something like think carefully before answering, use maximum reasoning to prompts where you want the deliberate path. I've started treating this as a build flag. Routine prompts run unannotated. Architecture decisions, hard debugging, anything that would normally get a senior engineer's "let me sit with this for a minute" — those carry the explicit flag.
The cost is a few extra seconds. The value is not getting confidently misled by a model that decided this one wasn't worth thinking about.
Prompt libraries are about to fork
Here is a prediction you can disagree with. Within twelve months, prompt libraries — your team's saved prompts, your snippet store, your ~/.claude/skills/ directory — will fork by model version. The 4.6-shaped prompts that survived earlier upgrades because the model smoothed over rough edges will not survive 4.7 cleanly. Either you rewrite them as specs, or you accept that the same prompt produces qualitatively different output depending on which model is on the other end of the API.
The teams that quietly win the next year of AI-assisted development are the ones treating prompts like infrastructure. Versioned. Reviewed. Tested against real outputs. Tagged with the model they were tuned for. The teams losing are the ones with a Confluence page called "Useful Claude prompts" last edited in February.
You could argue the next model rounds out the literalness and our old vibes come back. I'd bet against it. Strictness has been a one-way ratchet across every developer tool I can think of — PHP to Python, JavaScript to TypeScript, weakly-typed JSON blobs to schema-validated everything. The models are following the same arc.
The small move I'd start with
If you only do one thing this week, do this: take the three prompts you reach for most often — your review prompt, your summarise prompt, whatever sits in your muscle memory — and rewrite them as specs.
For each one, write down the output format, the length cap, and the boundary on what counts as in-scope. If you can't describe "good" in twenty words, the prompt isn't ready. Then switch every negative instruction to a positive one. "Don't be verbose" becomes "answer in under 80 words." "Don't hallucinate APIs" becomes "only reference APIs that appear in the code I pasted."
Save the rewrites. Tag them with the model version. Treat them like code, because they are.
The deeper move is psychological. Stop writing prompts like wishes and start writing them like contracts. The model is a strict typer now. Type your code accordingly.
Sources I drew from: