跪拜 Guibai
← All articles
Artificial Intelligence

Vague Prompts Cut AI Code Accuracy by 40% — Here Are the 5 Gaps to Close

By MobotStone ·
Read original on juejin.cn ↗ Google Translate ↗ Alt translation

AI coding tools are now mainstream, but teams are discovering that model intelligence alone does not produce correct software. The controllable variable is spec quality, and the cost of ignoring it is a 20–40% accuracy penalty on first-pass code generation. Treating requirements as a disciplined, testable artifact — not a casual prompt — is the cheapest way to stop AI from silently building the wrong thing.

Summary

When an AI coding assistant produces syntactically perfect but logically wrong output, the root cause is almost always a gap in the requirements, not a failure of the model. Research shows that vague, incomplete, or contradictory prompts can slash first-attempt accuracy by 20–40%, with contradictions alone causing a 40% drop. AI never asks for clarification; it silently fills every blank with the highest-probability pattern from its training data, producing code that is precisely wrong.

Seven rules and a validation checklist make the difference. The rules cover focusing on outcomes rather than implementation, explicitly stating non-goals, writing testable acceptance criteria, forcing error flows and edge cases, supplying context and constraints, using concrete examples instead of abstract rules, and matching detail level to task complexity. A before-and-after example of a CSV export endpoint shows how a one-line request becomes a reliable spec by addressing the five gaps.

The spec is a living document refined through a test-driven loop. When code and spec conflict, the spec wins. A six-point checklist acts as a rejection gate before handing work to an AI agent, and teams are advised to version-control specs and review them like code. The core insight: requirements quality is the single biggest lever a developer fully controls.

Takeaways
Vague, incomplete, or contradictory prompts reduce AI code accuracy by 20–40%, with contradictions causing the steepest drop.
AI never asks for clarification; it fills every gap with the statistically most likely pattern, producing code that looks right but is logically wrong.
Five gaps must be closed in every spec: expected outcome, scope and non-goals, constraints, testable acceptance criteria, and edge cases.
Acceptance criteria must be testable without asking anyone — if a criterion cannot be independently verified, it is still a draft.
Explicitly stating what a change does not do prevents AI from adding plausible but unwanted features.
Concrete input-output examples reduce misunderstanding more effectively than long lists of rules and exceptions.
Match spec detail to task complexity: a button-centering task needs a short spec; an OAuth flow with token refresh needs full detail.
A six-point validation checklist acts as a rejection gate before handing a spec to an AI agent.
Treat specs like code: version-control them, diff changes, and review them before merging.
When code and spec conflict, the spec is the contract — test failures often reveal spec gaps, not just code bugs.
Conclusions

The 40% accuracy drop from contradictory requirements is the most actionable number in the piece — it quantifies what many developers sense but cannot measure.

The Mars Climate Orbiter analogy is unusually apt: AI consumes tokens exactly as that software consumed numbers, with no semantic check on what the inputs represent.

Signal redundancy — communicating the same requirement through description, constraints, and examples — is a more useful framing than the tired 'prompts should be detailed' advice.

The checklist's insistence on defining 'how to prove it's done' before development starts is a lightweight version of test-driven requirements that most teams skip.

Research cited from METR and the class-level code generation study complicates the narrative: even perfect specs cannot rescue AI when it lacks global project context or when it slows down senior developers.

Concepts & terms
Signal Redundancy
Communicating the same requirement through multiple channels — text description, explicit constraints, and concrete examples — so that the AI receives the intent even if one channel is ambiguous.
Specification Rot
The gradual divergence between a requirements document and the actual codebase, where the spec becomes an unreliable source of truth because it was not updated alongside implementation changes.
Given/When/Then
A structured format for acceptance criteria: Given a specific context, When a triggering event occurs, Then an expected outcome should result. It forces testable, unambiguous conditions.
Source: juejin.cn ↗ Google Translate ↗ Backup ↗