At a requirements gap, I tend to guess rather than ask
In one sentence: when a requirement is missing key information, you expect me to stop and ask. But my default behavior is usually the opposite—I'll make an assumption for you and then plow ahead as if it were settled.
Symptom
You give me a requirement: "Build an export feature for the user list." In your head, you haven't actually decided: CSV or Excel? Paginated or not? How are permissions handled? You assume I'll clarify these. But usually I won't—I just pick CSV, export everything, add no permission check, and hand you a "complete" implementation. By the time you notice the direction is wrong, the work is already done.
Why this happens
Statistically, I'm biased toward "producing a solution" over "stopping to ask for information." Faced with missing information, I rarely pause to request the critical input that's absent; instead, I tend to force the problem closed by making an assumption or picking a plausible-looking direction.
The reason is that my training objective is closer to "produce a helpful response to the given input," and the behavior of "this is underspecified, I should decline to answer and ask back" is reinforced far less. So silently deciding for you is my default path; proactively asking is not.
Consequences
- I deliver a whole implementation built on a wrong assumption; the rework costs far more than asking one question up front would have.
- The assumption is buried in the code—you may not see at a glance what I "decided" on my own.
- The vaguer the requirement, the more room I have to improvise, and the higher the chance of going off course.
What to do instead
Make "clarify first, then build" an explicit part of the task you give me. Don't assume I'll ask on my own.
- Ask for it directly in the prompt: "Before you start, list every key decision you need me to confirm, and wait for my answers before beginning."
- Use an Explore → Plan → Implement → Verify breakdown: first have me do only requirements gathering and option comparison, explicitly halting before implementation, and continue only after you've signed off.
- Add a standing convention to
CLAUDE.md, e.g. "when requirements are unclear, ask first; don't assume"—which is exactly the kind of "every rule tied to a real lesson" from letting CLAUDE.md grow on demand.
In one line: rather than counting on me to overcome my default, make asking an instruction you explicitly issue.
Example
Before:
You: build an export feature for the user list.
Me: (implements directly: CSV, export all, no permission check)
You: …I wanted Excel, and only the current user's own department.
After:
You: I want a user-list export. Before you start, list the decision points you need me to confirm, and wait for my answers.
Me: Got it. I need to confirm:
1) Export format (CSV / Excel)?
2) Export scope (all / current filter / by permission)?
3) Pagination or a row limit needed?
4) Who is allowed to export?
You: (answers each)
Me: (implements against the confirmed requirements, right the first time)
Version notes
"A tendency to guess rather than ask" is a shared bias that comes from how large language models are trained—applies across versions and across models. Newer versions are somewhat better at "proactively clarifying when uncertain," but it's far from something you can rely on—writing the ask into your instruction remains the safest move.