Prompt deeper, not bigger

A lot of prompts end with a line like this:

Think like a software engineer.

It isn't wrong. You'll often get a solid answer. But it asks the model to act like an expert without telling it what an expert would actually bring: the standards they'd hold the work to, the sources they'd trust, the tools they'd reach for, and how they'd know they were done. The model fills those gaps with its best guess. Sometimes that guess is what you wanted.

There's a better way to ask.

The deeper prompt

Felix Rieseberg, an engineering manager at Anthropic who has led engineering for Claude.ai, Cowork and Claude Code Desktop, shared this in his post How to be more ambitious: A tutorial for humans with models (October 13, 2026):

I want a deeper version of this task, not a bigger one. Before rewriting it:
(1) say what a top professional in this field would do here that I'm not asking for;
(2) name the rawest material they would start from instead of what has already been digested for me;
(3) name the specific methods and tools they would use;
(4) say what, other than you or me, would show the result is right.
Then rewrite my prompt to ask for exactly that.

You don't run it instead of your task. You run it on your task: paste your draft prompt, let the model rewrite it, then send the rewritten version.

Why each part works

1. What a top professional would do that you didn't ask for. This is where industry standards come from. You asked for a dark mode toggle; a professional also thinks about the system preference, the flash of the wrong theme on load, and contrast in both themes. You can't ask for what you don't know exists, so the first step makes the model tell you.

2. The rawest material. Summaries lose detail. "The docs say X" is weaker than the spec itself, the source code, the actual error log, or the real dataset. Asking for raw material pushes the work toward primary sources instead of the model's memory of a blog post about them.

3. Specific methods and tools. "Make it fast" is a wish. "Profile it with the browser's Performance panel and check the Core Web Vitals" is a plan. Naming the methods turns a vague goal into steps you can check.

4. What, other than you or me, would show it's right. This is the most important line. It rules out "the model said it looks good" and asks for an outside judge: a test, a linter, a benchmark, a real browser, a validator. Rieseberg's post puts it bluntly: don't ask the model to judge itself; insist on outside validation, ideally a tool the model can run for immediate feedback.

Side by side

Here's a small task, and the kind of prompt the deeper version tends to produce. The second one is an illustration written for this post, not a captured model output, but it's representative.

Add a dark mode toggle to my site. Think like a software engineer.

Add a dark mode toggle to the site.

Standards a professional would meet:
- Default to the visitor's OS setting (prefers-color-scheme); the toggle overrides it and is remembered.
- No flash of the wrong theme on load: set the theme in a tiny inline script in <head>, before first paint.
- Text and UI contrast meet WCAG 2.2 AA in both themes.

Start from: our existing CSS custom properties in src/styles/tokens.css and the current color list, not new hard-coded colors.

Methods: CSS custom properties per theme, the color-scheme property for native controls, a data-theme attribute on <html>.

Prove it with:
- an automated contrast check (axe) in both themes
- screenshots of the home page in light and dark
- a hard reload with dark preferred, confirming no light flash

The first prompt leaves every one of those decisions to chance. The second one makes them explicit, and it ends with checks you can actually run.

"But models don't need prompting anymore"

It's a fair objection. Models need far less hand-holding than they did a year ago. You rarely have to explain output formats, beg for complete code, or repeat instructions three times. A lot of old prompting advice is obsolete.

What hasn't changed is the gap between what you said and what you meant. A stronger model fills that gap with better guesses, trained on more data, but they're still guesses. And the more capable and literal a model is, the more faithfully it executes the vague version.

The vendors say the same thing:

• Anthropic's prompting best practices: "If you want Claude to do more than the task strictly requires, explicitly request it rather than relying on the model to infer this from vague prompts."
• The Claude Code best practices: "Claude can infer intent, but it can't read your mind," and "The more precise your instructions, the fewer corrections you'll need."
• OpenAI's GPT-5 prompting guide notes that the model "follows prompt instructions with surgical precision," which means "poorly-constructed prompts containing contradictory or vague instructions can be more damaging" than with older models.

Better models raise the ceiling. A deeper prompt is how you actually reach it.

When not to bother

Not every task deserves this. Renaming a variable, fixing a typo or asking a quick question doesn't need a professional's standards. And sometimes vague is the point: the Claude Code docs note that "sometimes a vague prompt is exactly right because you want to see how Claude interprets the problem."

Use it for work you'll ship, trust, or build on.

One honest caveat

I haven't seen a controlled study showing this prompt improves results; the evidence so far is people trying it and comparing. So do the same. Pick a real task, run it once with your usual prompt and once with the deeper one, and judge the results with the outside check from step four. That's the whole idea anyway.