Why it matters: A prompt that produces clean, working code can still be a worse outcome than one that produces obvious garbage, because nobody files a bug against code that matches exactly what they asked for.
The Details:
Vague prompts fail loudly. Ask for an auth system with no other detail and the model must guess at session versus token strategy, library choices, and threat model. Those guesses are often reasonable alone and wrong for your stack, but at least the mismatch is visible fast, so you catch it and redo the work.
Over-specified prompts fail silently. Lock down every function signature, file path, and naming convention and the model stops being a collaborator and becomes a transcription service. It will build precisely what you listed and stay quiet about the rate limiting you forgot, the credentials leaking into logs, or the migration about to lock a table, because none of that was on your list.
The fix is naming constraints, not details. State the two or three decisions you would actually defend in a review: authentication method, which existing file the new code must match, what counts as security-sensitive. Everything else stays open to the model's judgment, the same way a good code review skips formatting nitpicks and argues only the calls that carry real consequences.
Negative space beats a wish list. If you cannot articulate what a new system should do, you almost certainly know what would make you reject it in review: plaintext credentials, an unnecessary dependency, a blocking migration. Naming two or three things you would refuse changes output more than a page of positive requirements, and pointing at one existing file to "match this feel" teaches more conventions than any rule list could.
Bottom Line: Good architecture prompts constrain what must be true and leave open how it gets done; that middle ground, not more detail, is where the collaboration actually works.
Enjoy this article?
Listen to the Claude Code Conversations radio show or join the community.
