# Why Claude Does the Wrong Thing: 3 Prompts > Claude writes the wrong thing because it rushes into code without understanding your intent. I explain why and give you 3 ready-to-use prompts to make it ask questions first. Source: https://ailoot.ai/blog/en/why-claude-does-the-wrong-thing/ Canonical: https://ailoot.ai/blog/en/why-claude-does-the-wrong-thing/ Language: en Publisher: Ailoot (https://ailoot.ai/) Translation: guide-201 Revision: sha256-97537285ff3536482a55c9f9c190820cc35776e6a60536138eaa2e9e661a43b6
Key takeaway Claude writes the wrong thing because it rushes into code and fills in what it thinks you wanted. Often, it gets that wrong. The problem is almost never the model—even the strongest one will miss the mark on a vague task. I fix this in one move: I make Claude interview me first, draw out my intent, and only then write. Below are three ready-to-use prompts you can copy and paste.
For more about using the service, see the [Ailoot documentation](https://ailoot.ai/docs/). ## Why does Claude do the wrong thing?
Key takeaway Claude gets a short request, instantly fills in the missing pieces, and rushes into writing code based on its own version of the task. Its version and yours differ. That is how you end up with a diff touching 14 files when you expected a one-line change. The cause is the gap between what you said and what you had in mind. The model has almost nothing to do with it.
You write, “Add filters to the products page.” In your head, that means a couple of checkboxes and an updated list. Claude hears the same thing and decides to build a full-fledged filtering engine: its own state store, separate input delay logic, URL synchronization, and a dozen helper functions. Hundreds of lines where a few URL parameters would have been enough. In a case like this, the conclusion is clear: the agent did not make a mistake; it simply solved a much bigger problem than necessary. The fault lay in not describing the desired outcome briefly and precisely enough. The key word is “intent.” You have it in your head; Claude does not. It sees the text of your request and everything in its context up to that request. Then it fills the gaps with guesses. The shorter the request, the more guesses it makes—and the farther the result gets from what you wanted. Anthropic says this plainly in the Claude Code documentation:

If you let Claude jump straight into code, it might solve the wrong problem.

— Claude Code Docs, https://code.claude.com/docs/en/best-practices
I ran into this on my own project. I asked for a fix to one authorization screen and got a diff that affected half of a neighboring module. Claude was not to blame: I gave it one line, and it filled in the rest itself. Since then, I start any task bigger than a typo with questions—the ones Claude asks me. ## Is it really the model—and why do even the strongest ones miss?
Key takeaway The model matters less than people tend to think. On a vague task, even the strongest one will miss the mark: it gets the same incomplete instructions and fills in the gaps with its own guesses. Developers who keep their agent under control get the same results whether they use a top-tier model or a midrange one. It all comes down to how clearly you describe what you want. Model power is secondary here.
Every week brings a model that is “smarter” than the last, and every time it feels like this is the moment AI will finally understand us from a few words. It will not. A stronger model writes code faster and handles complex logic better, but it still cannot read your mind. If the task is poorly framed, you will get something beautifully written that is still wrong. The takeaway for you is simple. Chasing the newest model so it can guess better is a dead end. It is cheaper and more reliable to learn how to give it tasks so it does not have to guess. That is what comes next. ## What is grilling, and how does it fix misalignment with AI?
Key takeaway Grilling is when you make AI interview you before it starts working: it asks detailed questions about the task until you reach a shared understanding. The point is to close the communication gap before the first line of code.
It sounds counterintuitive. We turn to AI to get things done faster, and now we are being told to slow it down and make it ask questions first. But five minutes of questions before coding can save an hour of fixes afterward. The problem is not just that you explained things poorly to Claude. Often, you have not thought the task through yourself—which cases to account for, where the boundaries are, what matters most. Grilling draws this out of you with questions. By the end of the conversation, you have not only a task the AI understands, but also your own task, finally spelled out in detail. That is how context engineering works: the main work happens before the prompt, not during it. You are not searching for magic prompt wording; you are laying out what you need for Claude in advance, until it understands without extra explanation. ## How do you make Claude ask you questions first?
Key takeaway Give Claude a short description of the task and explicitly ask it to interview you before starting work: have it ask about details, edge cases, and constraints, then put everything into a specification file at the end. This is Anthropic's official recommendation—the Claude Code documentation has a ready-made prompt template for this. Copy it, change the description, and paste it at the start of a session.
Anthropic does not just allow this approach; it recommends it. Its documentation has a section called “Let Claude interview you,” with a ready-made prompt. Here is a practical version:
Prompt Grilling prompt—make Claude interview you ``` I want to build [brief description of the task]. Interview me in detail before writing any code. Ask questions about implementation, the interface, edge cases, risks, and trade-offs. Do not ask obvious questions—dig into the tricky parts I may not have thought through. Ask one question at a time and wait for my answer. For each question, immediately suggest your recommended answer. Continue until we have covered everything. Then compile a complete specification in a file called SPEC.md. ```
Three details make this prompt useful instead of decorative. First, “one question at a time.” If AI dumps ten questions on you at once, you get overwhelmed and answer superficially. Second, “suggest your answer”: you do not have to come up with everything from scratch; you can agree or correct it. Third, “compile a specification in a file”: the intent drawn out of you becomes a document that will not get lost. Anthropic describes the payoff in terms of effort:

The time spent getting the specification right is more valuable than the time spent watching the implementation.

— Claude Code documentation, https://code.claude.com/docs/en/best-practices
After the interview, open a fresh session and give it the completed specification. Clean context plus clearly stated intent—and Claude hits the mark on the first try. ## The “prove to me this is the best plan” technique
Key takeaway Do not just make AI ask questions—make it defend its decision too. I add a requirement to the task: prove that the proposed plan is the best one, not just the first one that comes to mind, and that it is thought through several steps ahead. This gets Claude out of “I’ll do something similar” mode and into critic mode, where it checks its own work before you spend time on implementation.
Grilling draws out your intent. But AI has a second habit: grabbing the first solution that looks plausible. Anthropic calls this the “trust but verify” gap: Claude produces a plausible implementation that does not hold up in edge cases. The fix is to ask for evidence before code.

If you cannot check the result, do not submit it.

— Anthropic, Claude Code Docs, https://code.claude.com/docs/en/best-practices
I almost always add a “prove it” section to my prompt. Here is the exact wording:
Prompt Prompt—make AI defend its plan ``` Before writing code, analyze the task like a critic. Find 2-3 ways to solve it. For each one, prove to me that it really solves my task instead of adding complexity for its own sake. Do not write code just for the sake of writing code. Then choose one and prove that it is the best solution, thought through several steps ahead. What will break as the project grows? What are we missing right now? Only then propose an implementation. ```
Without this section, Claude gives you the first workable option. With it, Claude rules out dead ends itself, explains its choice, and lets you see its reasoning before a single file is touched. You read a short text that takes two minutes instead of spending an hour figuring out why the finished code does not work as expected. ## Pre-mortem: make AI find 10 reasons for failure before you start
Key takeaway A pre-mortem is a technique where you ask AI to imagine that the project has already failed and name the reasons. Claude switches from optimistic “I’ll get this done” mode to looking for weaknesses that would otherwise surface after a week of work. You get a list of risks before you have invested time in the project, and can address them in advance.
This is my favorite technique, and it is psychological. When you ask AI to “do a good job,” it is primed for success and skips over the holes. Ask it to imagine failure, and it starts seeing what it ignored before. The prompt is short:
Prompt Pre-mortem prompt—find the gaps before you start ``` Imagine it is a year from now. The project we are planning has failed. Write down 10 reasons why it happened. What did we fail to account for at the start, what did we underestimate, where did we cut corners, and which assumptions turned out to be false? Then, for each reason, tell me what we can fix right now to address it. ```
I run this prompt before approving the plan. Half the reasons turn out to be nonsense, but the other half are real pitfalls I would have run into a week later. Addressing them at the planning stage takes ten minutes. Running into them in a finished project costs several days of investigation. The combination is simple: grilling draws out intent, “prove it” defends the decision, and the pre-mortem finds the gaps. Three short pieces of text you paste in before writing code. They turn Claude from a rushing executor into a collaborator who thinks first. ## Why does an overloaded context make Claude act dumb?
Key takeaway Claude has a limited context window—the amount of information it can hold in mind at once. When the window is more than half full, it starts losing important details, mixing up earlier agreements, and filling in gaps instead of remembering. A long session about everything under the sun is a common reason AI does something completely different by the end of the day from what you agreed on that morning.
Even a perfectly framed task falls apart if you work on it in a cluttered context. Here is how it works: every new request you make brings the entire chat history into Claude's working context. The longer the session, the faster the window fills up. Keep it no more than half full; beyond that, AI starts acting dumb and losing important things you discussed at the beginning. Here is the rule that saves me the most frustration: one task, one chat. Finished a function? Close the chat and open a fresh one for the next task. Yes, sometimes it is more convenient to do everything in one window, but you will pay for it with lost context and off-topic answers. Anthropic calls this failure mode a “junk-drawer session.” The fix is simple: use `/clear` between unrelated tasks to clear the window and avoid carrying clutter from the previous task into the new one. If you run long sessions and do not understand where the money and AI's attention are going, I cover that separately in the guide on [where Claude Code tokens go](https://ailoot.ai/blog/en/where-claude-code-tokens-go/). And I put together the basics of persistent context, which Claude reads at every startup, in the guide to [setting up CLAUDE.md](https://ailoot.ai/blog/en/claude-md-template/). ## Grilling or Plan Mode—which is the difference, and how do they fit together?
Key takeaway Grilling and Plan Mode solve different halves of the same problem. Grilling draws out your intent with questions before there is a plan. Plan Mode takes a task that is already understood and shows you a change plan, without touching anything until you approve it. They work best together: first grilling clarifies what we are building, then Plan Mode shows exactly how.
People often confuse these two techniques or assume only one is needed. In practice, they belong at different points in the process. | Feature | Grilling | Plan Mode | |----|----|----| | When it happens | Before the plan—it clarifies intent | Afterward—it creates a change plan | | Who asks whom | AI interviews you | You read and approve the plan | | What you get | A task specification | A file-by-file change plan | | Main benefit | Prevents “that’s not what I wanted” | Prevents “don’t touch anything else” | Anthropic describes a canonical four-phase workflow: first Explore (Claude studies and asks questions), then Plan (builds a plan without making changes), then Implement (writes code according to the plan), and finally Commit (records the result). Grilling happens in the first phase; Plan Mode in the second. For a full breakdown of the second phase, see the guide to [Plan Mode in Claude Code](https://ailoot.ai/blog/en/claude-code-plan-mode/). An important caveat from Anthropic itself: do not burden small tasks with this.

If you can describe a change in one sentence, skip the plan.

— Official Claude Code documentation, https://code.claude.com/docs/en/best-practices
For a typo, a rename, or a one-line change, just write it directly, without interviews or plans. Grilling pays off on tasks with ambiguity and a cost of error. For trivial tasks, it only slows you down. ## 5 task-framing mistakes that make AI do the wrong thing
Key takeaway Almost every AI miss comes down to five task-framing mistakes: a vague one-liner, no constraints, “write code” with no “understand first” phase, no definition of “done,” and one endless session for everything. Each makes Claude fill in the task with guesses. Below is what each looks like and how to replace it.
I have summarized common pitfalls in a table. On the left is what people usually do and get wrong; on the right is what to do instead. | Mistake | What it sounds like | What to do instead | |----|----|----| | Vague one-liner | “Make the dashboard better” | Describe the task and start a grilling session—let AI draw out the details with questions | | No constraints | “Add authorization” | Say what must not break, which libraries not to bring in, and what is out of scope | | “Write code” right away | Prompt—and start coding | First “understand and ask,” then write code | | No definition of “done” | You expect AI to guess the result | Give an example, a reference screenshot, or a test showing what “working” means | | One session for everything | Spend all day in one chat | One task, one fresh chat, so the context does not get cluttered | Review the last prompt where AI gave you the wrong answer. Almost certainly, one of these five mistakes was at work. Most often it is the first: you gave it a short phrase and expected Claude to fill in the rest correctly. It filled in the rest—just not the way you had in mind. ## What next: build a system so AI understands you from a few words
Key takeaway Individual prompts fix individual tasks. To make AI understand you without lengthy explanations every time, you need a system: grilling draws out intent for each task, a Second Brain stores project knowledge, and context engineering connects everything Claude reads before the prompt. Then the reason it does the wrong thing disappears: it always has enough context to avoid guessing.
The three prompts in this guide—grilling, “prove it,” and the pre-mortem—handle the specific task at hand. That is already a lot: you stop getting a 14-file diff when all you wanted was a one-line change. But grilling has a ceiling. Drawing out your intent from scratch every time takes a long time. The real shift comes when some context is always there: in a folder of knowledge about your project, in a CLAUDE.md file that Claude reads at every startup, and in your methodology encoded in skills. Then AI comes to the task already knowing your business, your goals, and your style—and understands you from a few words because you laid out half the context in advance. Anthropic's recent analysis shows just how much work this is: developers use AI in about 60% of their work, but can fully trust it with only 0-20% of tasks. The rest takes your understanding, supervision, and ability to explain what to build. That is the skill worth developing, not chasing the smartest model.
### Sources - [Claude Code Docs - Best Practices (Let Claude interview you, plan mode)](https://code.claude.com/docs/en/best-practices) - [Anthropic - 2026 Agentic Coding Trends Report](https://resources.anthropic.com/2026-agentic-coding-trends-report)
Get to know [Ailoot](https://ailoot.ai/). ## Questions about Why Claude Does the Wrong Thing: 3 Prompts ### When should I use the interview prompt instead of going straight to code? Use it when the outcome, edge cases, or constraints are unclear and mistakes would be costly. Ask one question at a time and save the agreed result in SPEC.md; a typo or clearly described one-line change can be requested directly. ### What should I check before accepting the proposed plan? Ask for two or three approaches and compare how each meets the specification and constraints. Then run the pre-mortem prompt, review its failure reasons, and address the relevant risks before implementation. ## Ailoot · The company and its project portfolio Ailoot combines established operating experience, a large client base, stable service and ongoing KPI control. The company and its project portfolio: millions of customers; monthly sales in the billions. Ailoot brings that operating experience to API access for AI features in customer products, agents, applications and automations.