The team wants to ship a feature. Before writing code, they need to understand the API, the model's capabilities, the integration patterns, and the security implications.
That preparation is sensible. Some questions need answers before implementation can begin.
Then the research document arrives.
It identifies twelve areas for investigation. Each area contains sub-questions. Each sub-question has dependencies. The team starts working through the list, and every answer produces another question. Three weeks later, nobody has written a line of code.
This is the Wall of Prerequisite Research: the point where research stops supporting action and becomes a substitute for it.
Each brick looks reasonable
The Wall is not built from obviously foolish questions. That is what makes it difficult to spot.
A concern about security may deserve investigation. An unfamiliar API may require careful reading. An integration pattern may affect the design. A question about the model's capabilities may determine whether the feature is practical.
The problem is not that any one question is illegitimate. The problem is the accumulation.
AI makes this accumulation easier because it can produce a large research document very quickly. A fifty-page document can appear in minutes. Reading it still takes hours. Turning its findings into decisions and working code still takes weeks.
The cost of generating research has fallen much faster than the cost of understanding or acting on it. That difference creates room for the Wall to grow.
A document can expand almost without friction. The work it describes cannot.
Research that generates more research
The Wall reinforces itself.
The first document lists risks that need investigation. The investigation produces findings that need evaluation. The evaluation reveals gaps. Those gaps become new research tasks. The new research introduces more risks and qualifications, which send the team back to the beginning.
At every stage, the team can explain why the next step is justified. The risk is real. The question is relevant. The proposed investigation is careful. Nothing looks like a clear mistake.
The aggregate result is paralysis.
This kind of delay rarely feels like doing nothing. The team is busy. People are reading documentation, comparing options, discussing edge cases, and adding notes to the research file. Every new document looks like evidence of progress.
That appearance can be convincing. Carefulness is good. Thoroughness is good. Responsible engineering is good. But those qualities only help if they lead to a decision.
The useful question is not whether the team has learned more. It is whether the team is closer to deciding whether to build the feature.
When diligence becomes avoidance
Research becomes a problem when it no longer has a stopping condition.
Without a stopping condition, there is always one more uncertainty to resolve. The team can postpone implementation while claiming that the remaining work is necessary. Since the research is inexpensive to generate, postponement can continue for a long time.
The team may also start treating uncertainty as a reason not to choose. Instead of identifying what is known, what is unknown, and what can be tested through a small implementation, it tries to remove every unknown in advance.
That standard is impossible to meet. Building something is often how you answer questions that cannot be settled from documents alone. An integration may look straightforward until a prototype exposes a constraint. A security concern may become clearer when the team defines the actual data flow. A capability question may be easier to answer with a small test than with another round of analysis.
Research has a job. It should reduce uncertainty enough to make a decision, not promise that uncertainty can be eliminated.
Set the budget before you start
The counter is to set a research budget before opening the first document.
Choose how much time the team will spend investigating. Define the specific question that must be answered. Decide what result will trigger a build and what result will stop the project. If the team cannot state the decision, it will have trouble recognizing when the research is complete.
A good research task should lead somewhere concrete: build the feature, reject the approach, run a limited experiment, or revisit a particular assumption. The trigger does not need to resolve every concern. It needs to tell the team what to do next.
Time-boxing also changes the shape of the work. Instead of collecting every possible detail, the team looks for the information that can change the decision. Instead of treating a research document as a deliverable, it treats the document as an input to action.
Some research will still uncover a reason not to build. That is a useful outcome. So is discovering that a small prototype is needed before making a larger commitment.
The failure is not deciding against the feature. The failure is never deciding.
The Wall of Prerequisite Research does not prevent bad decisions. It prevents decisions. Set the budget, name the trigger, and start the work before preparation becomes the only work anyone knows how to do.