Diagnosing Why Two Prompts Produce Different Quality Outcomes

1. Why specificity speeds up the gather-context phase:

The gather-context phase exists because Claude doesn't automatically know what's relevant to a request — it has to discover it, using Grep, Read, and similar tools, before it can act. Developer B's prompt effectively pre-supplies most of what that phase would otherwise have to discover from scratch: which endpoint, the specific symptom (8 seconds, correlated with record count), a location to start looking (src/reports/service.ts), and even a hypothesis about the root cause (N+1 querying). This means Claude's context-gathering can go almost straight to verifying or refuting a specific, well-formed hypothesis — read that one file, check whether the query pattern really is N+1 — rather than needing to first figure out "faster" means what, exactly, and which of possibly many endpoints is even in scope. Developer A's prompt gives the loop nothing to anchor on: "the API" could mean any endpoint, and "faster" has no defined target, so the gather-context phase has to spend real tool calls just establishing scope before it can even form a hypothesis.

2. Vague prompt: inability vs. changed process:

It changes how the loop proceeds, not whether it can proceed at all. Claude Code is not blocked by vagueness — it will treat the vague prompt as license to explore more broadly: searching for API route definitions, possibly running or checking for existing performance logs/monitoring, looking for endpoints with unusually complex queries, and forming its own hypothesis about what "the API" and "faster" most plausibly refer to in this codebase. This is a legitimate use of the agentic loop's autonomy — the loop is explicitly built to gather whatever context it needs, and it doesn't require the human to have already done the diagnosis. The cost isn't capability, it's time and risk of misdirection: Claude might spend several extra iterations investigating an endpoint that turns out not to be the one the developer actually cared about, or "fix" a real inefficiency that isn't the one causing user-visible pain.

3. Where the extra iterations went for Developer A:

Concretely, in the gather-context phase, repeated: likely several rounds of Grep/Glob to enumerate API routes and find candidates, Read calls across multiple candidate files to assess which looks most like a "slow" endpoint (checking for nested loops, missing indexes, obvious N+1 patterns, or large payloads), and possibly Bash calls to check for existing profiling output, logs, or to reproduce a slow request directly and measure it. All of this is the loop doing the diagnostic work that Developer B's prompt did up front in one message. None of that time was wasted in the sense of being useless — Claude still had to discover the same facts eventually — but it came at the cost of extra loop iterations (and extra time/tokens) that a more specific prompt would have avoided, and it carries a real risk that Claude's inferred scope ("I'll assume you mean the reports endpoint since it has the most complex query") doesn't match what the developer actually meant, requiring a correction turn to redirect.