The Feature Everyone Agreed On — Until It Was Built

Everyone in the room agreed. That was the problem.

The request sounded simple: "Let customers export their data." Heads nodded. Someone said it couldn't take more than a day now that the AI writes most of the code. The meeting moved on. By the next afternoon there was a working export button in staging — real code, real tests, a real download.

And at the demo two weeks later, it fell apart. Not because the code was broken. Because "export their data" had meant six different things to the six people who agreed to it, and nobody wrote down which one they were building.

Key Takeaways

• Agreement in a meeting is not a specification. People nod at a sentence while picturing completely different features.
• An AI builder resolves every ambiguity you leave open — quickly, plausibly, and without telling you it made a choice.
• The gaps that break a feature are almost always decided in the requirements conversation, by omission.
• Specify the problem, not the solution: who needs this, what they do with the output, what "correct" means, and what must never happen.
• Acceptance criteria written before the build is the cheapest bug fix you will ever make.
• Speed of construction raises the cost of a vague brief. The faster the build, the earlier the thinking has to happen.

The Meeting Where Everyone Nodded

"Export their data" is a sentence, not a design. In the room, the account manager pictured a one-click CSV a customer could open in Excel. Finance pictured a fixed schema that would reconcile against their ledger. The support lead pictured a scheduled report emailed every Monday. Legal, half-listening, assumed personal fields would be stripped. Engineering heard "add a button." Everyone agreed, because everyone was agreeing to their own version.

This is how requirements usually fail — not in disagreement, which is visible and gets resolved, but in false consensus, which feels like progress. The meeting ends, everyone believes the hard part is done, and the ambiguity travels downstream untouched.

---

AI Builds Exactly What You Asked For

Hand that sentence to a capable model and you get working code fast. That is the part that feels like magic, and it is also the part that hides the damage. The model does not ask which version you meant. It picks one.

Every gap you left open in the meeting still has to be filled before the code compiles — the format, the size limits, the columns, the delivery mechanism, the permissions. The AI fills all of them, instantly, with the most statistically plausible choice. Plausible is not the same as correct for your business, and nothing in the output flags which decisions were yours and which were the model's. You review a clean diff, tests pass, and the guesses ship inside something that looks finished.

---

The Demo Where It Fell Apart

Here is what "done" turned out to mean:

• Wrong format. It produced a generic CSV. Finance needed a specific column order and headers to reconcile, and could not use it.
• Wrong scale. It built the file in memory. It worked in the demo and timed out on any account with more than a few months of history.
• Wrong data. It exported every column in the table, including one legal had already ruled could never leave the system.
• Wrong delivery. Support had promised customers a scheduled Monday email. What shipped was a button a user had to remember to click.

None of these were coding mistakes. Every one of them was a decision made in the requirements conversation — by leaving it out. The AI didn't get anything wrong that it was actually told.

---

Specify the Problem, Not the Solution

The fix is not more code review. It is upstream, in the part everyone wanted to skip. Before a single prompt, write down:

• Who needs this and what they do with the output. "Finance, to reconcile against the ledger monthly" is a different feature than "a customer, to keep a personal copy." Name the user and the job.
• What "correct" means. The exact format, the required fields, the acceptable size and speed. If you can't state it, you can't verify it.
• What must never happen. The columns that can't leave the system. The accounts that can't be exported. The non-goals, stated as plainly as the goals.
• How you'll know it works. Concrete acceptance criteria — real inputs, expected outputs, the large-account case, the empty case — written before the build, not discovered at the demo.

Then hand the model a problem with its edges drawn, instead of a wish. The AI is still fast. It is just now fast at the right thing.

---

What Good Looks Like

A workable pattern, before AI touches the feature:

• A one-paragraph problem statement the whole room actually reads, out loud, and agrees on word by word — not concept by concept.
• Named users and their job-to-be-done, so "export" resolves to a specific outcome instead of a category.
• Explicit non-goals. The things this feature deliberately will not do, written down so nobody assumes them into scope.
• Acceptance criteria first. The test cases exist before the implementation, including the edge and failure cases you expect to be hard.
• A spec review by the people who'll use it. Finance reads the finance parts. Legal reads the data parts. Disagreement surfaces here, on a page, where it costs nothing to fix.

Only then do you prompt. The model builds in an afternoon, same as before — but now the afternoon produces the feature everyone actually agreed on.

Rewrite the lesson: a fast builder doesn't reduce the need to understand the problem. It moves the deadline for understanding it earlier.

---

FAQ

Isn’t writing a detailed spec the slow process AI was supposed to replace?

AI replaced the slow part of construction, not the thinking that tells construction what to build. A problem statement, named users, non-goals, and acceptance criteria are a few hours of work, and they are the few hours that decide whether the afternoon of building produces the right thing. When the build was slow, a vague brief cost you weeks and you noticed. Now it costs you a rebuild and a missed demo, and you notice later. The thinking got more valuable, not less.

The AI’s choices were reasonable. Isn’t that good enough?

Reasonable in general is not the same as correct for your context. A generic CSV is a reasonable default and useless to a finance team that needs a specific schema. Exporting every column is reasonable and a compliance incident if one of those columns was legally off-limits. The model optimizes for the plausible average; your business runs on the specifics. Someone has to supply the specifics, and it can't be the model.

Where do these requirements failures actually come from?

Almost always from false consensus in the requirements conversation. People agree to a short phrase — "export their data," "notify the user," "sync the account" — while each picturing a different implementation. Nobody disagrees, so nothing gets resolved, and the ambiguity is passed to whoever builds it. A fast builder then makes all the unresolved calls at once, silently. The failure was created in the meeting; the build just made it visible.

What’s the single highest-value habit to adopt?

Write acceptance criteria before you prompt. Concrete inputs, expected outputs, the large case, the empty case, the thing that must never happen. It forces the ambiguity out of the requirements while it's still cheap to fix, it gives the model a target instead of a vibe, and it gives you an objective way to check what came back. If you do only one thing upstream, do this.

How does this scale to a small team moving quickly?

It's cheaper for a small team, not more expensive. A missed demo, a rebuild, or a compliance scramble costs a small team far more than the hour it takes to write down who needs the feature and what "correct" means. The spec doesn't have to be a document with a template — a shared paragraph and a list of test cases is enough. The point is that the decisions get made deliberately by people, once, instead of accidentally by a model, silently.

Last updated: August 2026