There's a pattern I keep seeing. A developer opens their AI agent, types something like "build me a checkout flow with discount codes and tax logic", watches the code materialise in seconds, and thinks: "Done. That's what I asked for."
It isn't.
What they typed was a wish. What they needed was a specification. And those two things are separated by a chasm that no model — no matter how capable — can cross on its own.
The Illusion of Communication
When you hand a prompt to an AI agent, you feel like you've communicated. You used words, the agent responded with code, and the code runs. That feedback loop is so fast and so satisfying that it masks a fundamental problem: the agent didn't understand you. It predicted you.
There's a difference. Understanding requires context, constraints, and the ability to ask the right clarifying questions. Prediction is a statistical interpolation between everything the model has ever seen. When your prompt is ambiguous — and most prompts are — the model fills the gaps with assumptions. Confident, syntactically valid, unit-tested assumptions that have absolutely nothing to do with your actual business requirements.
Your checkout flow now handles tax the way most e-commerce checkouts do. Not the way yours should.
Garbage In, Garbage Out — But Faster
There's an old rule in software: garbage in, garbage out. Vague requirements produce bad software. This was true when requirements went to a junior developer. It's true now when they go to an AI agent.
The difference is speed. A junior developer might ask a clarifying question. They'll get stuck on something and come back to you. The friction is annoying, but it's also a signal — a symptom of missing information that surfaces before it becomes a bug.
An AI agent doesn't get stuck. It makes a decision and keeps going. It builds the entire feature on top of an assumption you never validated, and it does it in the time it takes you to refill your coffee. By the time you look at what was generated, you're already five decisions deep into the wrong direction.
AI doesn't make your bad requirements better. It executes them faster.
What a Spec Actually Is
A specification isn't a wall of formal documentation. It doesn't have to be. But it does have to answer questions that your prompt almost certainly left open:
| What the prompt says | What the spec needs to answer |
|---|---|
| "discount codes" | Which types? Percentage, fixed, free shipping? Stackable? Expiry dates? |
| "tax logic" | Which countries? Inclusive or exclusive pricing? VAT, GST, or both? |
| "user authentication" | Sessions or tokens? What happens when a session expires mid-checkout? |
| "send a confirmation email" | What triggers it? What if the email fails? Retry logic? |
Every one of those gaps is a decision. If you don't make that decision, the model will. And it will make it silently, without flagging it as a decision at all.
The Speed Trap
Here's where it gets insidious. Because the AI delivered something quickly, you feel like you're ahead. The velocity is real — lines of code are appearing, tests are passing, the feature looks complete. That feeling is the trap.
You haven't saved time. You've borrowed it. The debt sits in every assumption the model made that you haven't reviewed yet. You'll pay it back when the product manager asks why tax isn't calculated correctly for Belgian customers. Or when a discount code stacks with a sale price in a way that makes every item free. Or when a payment fails silently because an edge case nobody specified was handled incorrectly.
This is not a hypothetical. This is what happens when the prompt becomes the spec.
Use the Agent to Write the Spec
Here's the irony: AI agents are actually quite good at surfacing what you haven't thought of yet — if you ask them to.
Before you prompt for code, prompt for questions.
"I want to build a checkout flow with discount codes and tax logic. Before you write a single line of code, list every assumption you'd need to make and every decision I haven't specified."
The output will be uncomfortable. It will be a list of things you hadn't considered. That discomfort is the point. You're not losing time — you're front-loading the friction that would otherwise surface as production bugs.
Only once you've answered those questions do you prompt for code. At that point, you're not handing the agent a wish. You're handing it a spec.
Conclusion
The prompt is the beginning of a conversation, not the end of one. Treating it as a complete instruction set is how you end up with code that runs perfectly and does exactly the wrong thing.
Stay the author of your requirements. Make the decisions that are yours to make. And don't let the speed of delivery fool you into thinking clarity is optional.
The agent is fast. Make sure it's building the right thing.