An agent builds exactly what you asked for

Every requirement rests on something nobody wrote down

A requirement is never the full story. It sits on top of things everyone assumes. Which rules the business really follows, what the system already does, what must not break.

On a new build, the missing part is the business itself. The rules, the regulation, the intent behind them. Nobody can look it up, because it lives in people’s heads.

On an existing system it is all of that, plus years of decisions built into code that nobody has read recently. The bigger the change, the more of both it touches.

Either way, the requirement is only as good as the part nobody wrote down.

Incomplete is the normal state

This is not a rare problem. Researchers surveyed 228 companies in 10 countries, then ran the survey again and again. The problem people named most often was the same every time.

Incomplete or hidden requirements. Not badly worded ones. Missing ones.

And they are the ones that reach your customer

Here is the part that should worry you. For each function point of software, requirements produce about 1.00 defects, and 0.23 of them reach production. Code produces 1.75 defects, but only 0.09 of them reach production.

Code creates far more defects. But more of the requirements defects reach the people who use your software.

Requirements produce fewer defects than code does. They just survive longer. Of every hundred defects that start in a requirement, about 23 are still there when a customer sees the software. Of every hundred that start in the code, about 5 remain, because compilers, tests and review are all built to catch those. Capers Jones measured this in 2011 at 1.00 and 1.75 defects per function point.

A requirements defect is roughly four and a half times more likely to reach the person using your software. Those numbers were measured in 2011. Fifteen years later, nobody has published anything to replace them.

Why they get through

Look at what checks your code. The compiler, the type system, the linter, the test suite, coverage, static analysis, code review, the pipeline. Layers of checks, added over thirty years.

Now look at what checks your requirements. Tools do exist and they are good. Jama Connect Advisor and QVscribe score requirements against INCOSE and EARS rules. They catch ambiguity, weak wording, duplicates and contradictions.

All of that checks the sentence.

None of it can tell you a requirement is incomplete, and it never will. Completeness is not a property of the text. It is a fact about the system the text is describing.

Thirty years of tooling points at the code. What points at requirements only checks how they are written. Whether a requirement is complete, and whether it still describes the system, is checked by nothing.

Agents ask about what they can see

The old safety net was informal, and nobody wrote it into the process. A developer who knew the system noticed the ambiguity while coding and asked a question.

Agents ask questions too, all the time. But they only ask about what is in front of them.

A 2026 benchmark ran 1,304 coding tasks with unclear requirements. Every model got worse, and the strongest models got worse the most. None of them spotted the ambiguity. They chose one reading and built it.

Nothing looked wrong from inside the prompt. The developer’s question came from knowing the system in their head. That is the part the agent does not have.

Fixing things late did get cheaper, but not this

There is a fair objection here. Deployment used to be expensive and slow. Now it is neither, so the old warnings about catching defects early matter less.

Partly true. Later research found the cost curve much flatter than the classic “hundred times more” figure.

But it flattened for one kind of defect. The crash, the bad branch, the thing a test catches. It never flattened for the other kind, where the system does exactly what was asked and the ask was wrong. Those still show up months later, through a customer or a regulator.

Twenty-five years on the same problem, and every row links to the study. It was priced, then measured, then confirmed by practitioners, and the method for fixing it afterwards is still unsolved. Only the last entry is new, and it is about AI making the problem worse.

Why nobody closed the gap

Not laziness. Doing it after the fact is truly hard.

A 2023 dissertation at Karlsruhe Institute of Technology took on exactly this problem. It tried to recover the links between requirements and the code that implements them. The result beat the previous best methods and still reached an F1 score of only 55.5 percent. Adding a large language model gave no improvement over simple word embeddings.

The author’s own conclusion was that on large projects every approach, including his, is far from what full automation would need.

That is the cost of starting late

Read that result carefully. It measures reconstruction. Digging links out of a system where nobody ever recorded them.

Checking a link you already have is a different problem, and a much smaller one.

The difficulty of reconnecting requirements to code is not an argument against doing it. It is the price of not having done it.

A new build never has to pay that price. An existing system pays it once, through assisted extraction that a person confirms. After that, you stop having to rebuild the same understanding on every change.

What this looks like with POLYREQ

Code quality was never solved by discipline. Developers did not become more careful. Failure became immediate and automatic. The compiler rejects it, the test goes red, the pipeline blocks the merge.

Requirements are the last input in the pipeline that never got that loop. POLYREQ builds it.

The missing check. A compiler checks the code against itself. A test suite checks the code against what the code was meant to do. Neither can tell you the system has drifted from what the business agreed. A specification graph does that check.

Your system becomes a graph, not a folder. Every requirement, rule, screen and interface is a statement. Every statement is linked to the code that implements it. The links are re-checked as the code changes, so nobody has to remember to keep them up to date.

Completeness is no longer guesswork. A statement with no code behind it is a gap somebody has to close. Code with no statement behind it is a rule nobody agreed to. Both are visible. Both can be counted. A writing-quality checker cannot tell you either of those things.

Drift shows up as an event, not a late surprise. When a change breaks the link between a rule and the code that implements it, you see it the same day. Not six months later in production, under the name of a scope change.

Agents stop guessing. A brief carries the statements the change touches, the rules it must not break, and the evidence it has to bring back. That is the context the benchmark showed models cannot work out on their own. It is what separates an agent that asks a good question from one that confidently builds the wrong thing.

And it keeps paying off. Impact analysis becomes a lookup instead of a week of digging. A new joiner reads the graph instead of interviewing whoever is still around. Traceability, which automotive and aerospace regulators already demand, shows up as a side effect rather than a separate project.

It does not write your requirements for you. Analysts still decide what the system should do. You just stop being in the dark about whether that decision still holds.

Key takeaways

Every requirement depends on context nobody wrote down, on new builds and on changes to old systems alike.
Incomplete requirements are the most reported problem in practice, across 228 companies and 10 countries.
A requirements defect reaches production about four and a half times more often than a coding defect.
Requirements tools check how a requirement is written. Nothing checks whether it is complete, because completeness is a fact about the system.
Agents ask about what they can see. They cannot ask about the rule nobody wrote down.

Make the missing part visible.

POLYREQ links every statement to the code that implements it and re-checks it on every change, so gaps show up as signals instead of surprises in production.

Load your system into POLYREQ →