Anthropic Claude Won't Save You From Bad Requirements: Why AI Delivers Convincing But Weak Results

Large prompts, roles, and incantations like "think carefully" don't guarantee a good answer from AI. Using Claude as an example, the author breaks down why the model often accelerates the production of plausible text but fails to deliver useful results if the task itself is not clearly defined.

Why This Doesn't Work

The main complaint is simple: AI rarely pushes back on poor task specifications. While a designer, analyst, or developer would typically come back with clarifying questions, a model more often fills in the missing context itself and delivers a confident answer. This makes it seem to the user like work is progressing quickly, when in fact what's accelerating isn't the production of a quality result, but the production of text that looks convincing. This explains the fatigue after long iterations: you spend an hour rewriting what you should have gotten right on the first or second attempt.

"A prompt is not a prayer."

The author links this to a reversal in the cost of actions. It used to be expensive to execute, while thinking and discussing were relatively cheap. Now AI creates five variants of analysis, emails, or strategies in seconds, but team discussion of the task becomes the most expensive part of the process. This creates an illusion that you can skip the stage of proper specification and jump straight to generation. But a long prompt doesn't replace a clear goal, and magic formulas don't cure the absence of structure.

Four Questions Before the Chat

Instead of searching for the perfect wording, the author proposes returning to basic business analysis discipline and assembling a task map before starting work. Its logic is built around the As-Is, To-Be, Gap approach: what we have now, what the outcome should be, and what separates one from the other. This framework is useful not only for complex research but also for everyday tasks like competitive analysis, article structure preparation, or analyzing user interviews. The point is to describe not a general hope for a good answer, but a specific route to it.

• Input: what data, links, documents, hypotheses, and observations you already have at the start.
• Steps: what actions the model should perform in order, without vague "analyze."
• Output of each step: what exactly should result after each step—table, list, matrix, draft.
• Final result: what the completed work looks like and by what criterion you'll accept it without the feeling of "seems okay."

In practice, this changes the very format of interaction with the model. Instead of one enormous prompt, it's better to build a pipeline of several steps with intermediate review: first fact-gathering, then comparison, then identifying gaps, and only then conclusions. In a competitive analysis example, this approach turns an abstract request into a sequence of small tasks, where it's easier to catch an error before the final text.

How It's Assembled in Claude

For himself, the author packaged this approach into a separate Claude skill. First, he checks what is actually required: a one-time answer or a prompt for reuse. Then comes the As-Is, To-Be, Gap map, after which the system assesses the request's completeness by several mandatory elements—goal, audience, format, constraints, and context.

If data is missing, the model doesn't immediately generate beautiful text but asks clarifying questions. A key step here is the Confirmation Gate: before work begins, AI shows how it understood the task and waits for explicit confirmation. Then the final prompt is assembled into a structured template following the Context, Role, Instructions, Style, Parameters scheme.

The author particularly emphasizes the importance of negative constraints, few-shot examples, and targeted iteration on specific errors rather than the feeling "it got better." If the result turned out too general, what needs fixing isn't the prompt's mood but the rule itself: add metrics, forbid clichés, demand a clear answer format. This mode makes prompting less like creative guessing and more like engineering process tuning.

What It Means

The main conclusion is harsh but useful: AI amplifies not only good solutions but also poor specification. For teams, this signals stopping the measurement of efficiency by the number of generated variants and starting to demand task maps, intermediate review, and readiness criteria. The cheaper generation becomes, the more expensive clear thinking becomes—and it's clear thinking that now provides the greatest advantage.