A large language model can produce twenty plausible answers before a conventional workflow has formulated one. This looks like accelerated problem solving, and sometimes it is. But quantity of candidates is not the same as quality of resolution.
LLMs are expansion instruments. They widen a search space by generating alternatives, recombining patterns and moving rapidly between possible descriptions. Many real solutions, however, are found through the opposite operation: eliminating paths that violate evidence, constraints or formal rules.
The difference between those operations explains both the usefulness and the danger of generative AI.
The Expansion Advantage
Early problem solving often suffers from premature convergence. A team settles on the first coherent diagnosis. A writer follows the most familiar structure. An engineer searches only within the architecture already in use.
An LLM can interrupt this tendency. It can generate:
- competing hypotheses;
- alternative causal stories;
- edge cases and failure scenarios;
- analogies from another domain;
- multiple implementation approaches;
- questions that the original framing omitted.
This is genuine value. A system that proposes candidates cheaply can reveal parts of a problem space that would otherwise remain unexplored.
Yet expansion has a predictable failure mode: the model can produce more plausible paths than a person has time to inspect. Fluency makes weak candidates expensive because each one arrives already wrapped in an explanation.
Why Solutions Often Come from Elimination
Consider an incident investigation. An LLM may suggest that a service failed because of authentication, a schema change, resource exhaustion, a network dependency or an expired certificate. None of these suggestions is knowledge yet.
The investigation advances when evidence removes candidates:
- a valid certificate eliminates expiry;
- stable memory use eliminates resource exhaustion;
- a version diff exposes the schema change;
- a reproduction confirms the causal path.
What remains is not correct because the model preferred it. It is credible because alternatives failed against observable constraints and the surviving explanation produced testable expectations.
The same architecture appears in formal problem solving. AlphaProof generates candidate proof steps inside Lean, where they can be formally checked. Google DeepMind describes a cycle of proving or disproving generated problems rather than relying on natural-language plausibility.
FunSearch uses an LLM to produce programs, while an evaluator measures their performance. The language model contributes diversity; the evaluator supplies selection pressure. The reported discoveries were possible because candidate solutions lived in a domain where quality could be tested.
Separate the Generator from the Evaluator
Asking the same model to generate an answer and then declare it correct does not create a strong validation boundary. The second response may reproduce the assumptions of the first or invent a persuasive justification after the fact.
A stronger system separates roles:
| Operation | Function | Typical instrument |
|---|---|---|
| Expand | Produce candidate claims or solutions | LLM, search, brainstorming |
| Constrain | Apply scope, policy and known facts | Rules, ontology, requirements |
| Test | Attempt to reject candidates | Experiments, validators, queries |
| Select | Retain candidates that survive | Human or governed workflow |
| Record | Preserve why a candidate survived | Provenance and decision log |
The evaluator does not always need to be deterministic. Peer review and expert judgment are not deterministic in the software sense. They can still be disciplined when criteria, evidence and responsibility are explicit.
Expansion Without Boundaries Becomes Accumulation
In a knowledge system, generated candidates create a second risk: proposals may silently become memory. A speculative statement is summarized, stored, retrieved later and treated as established context. Repetition gradually converts an unsupported suggestion into apparent organizational knowledge.
This is why production knowledge needs admission controls. A generated claim should carry a status such as candidate, challenged, validated or rejected. It should retain its source context and never lose the distinction between retrieved evidence and model-generated interpretation.
A useful knowledge strategy therefore defines:
- what the system is allowed to claim;
- which evidence qualifies for each class of claim;
- which tests can reject it;
- who may promote it into operational knowledge;
- how corrections propagate without erasing history.
The model remains free to expand inside an exploratory space. The governed knowledge layer remains selective.
Design for Productive Rejection
Most AI interfaces optimize for completion: provide an input, receive an answer. A knowledge-centric interface should also optimize for rejection.
It could ask:
- Which observation would contradict this explanation?
- Which assumptions are shared by all proposed solutions?
- Which candidate is cheapest to test first?
- What evidence is missing?
- Is there a known constraint that rules out this path?
- Has a similar claim already failed elsewhere?
These questions change the model from an oracle into a critique instrument. Its purpose is not merely to speak, but to help construct a search process in which errors become visible and removable.
The Two Engines of Discovery
Discovery needs both variation and selection. Without expansion, a system repeats familiar ideas. Without elimination, it accumulates attractive noise.
LLMs dramatically reduce the cost of variation. That shifts the bottleneck toward evaluation: evidence, formal checks, experiments, domain constraints and accountable judgment.
The future of reliable AI may therefore depend less on making the generator sound certain and more on building better machinery around it—machinery that can reject most of what it produces.