A bigger model will not close the gap in most production AI systems, because the gap is contextual, not a shortage of parameters. The thing your system keeps getting wrong is your data, your process and your edge cases, none of which were in the model's training set, because none of them were public. Scaling the model adds more of what it already had. It adds nothing of what it was always missing. That is a bet on where the bottleneck sits, and the evidence has moved toward it.
Ross Jones, Founder, The Hopium Lab. Last modified 22 July 2026.
A practitioner's position, held with the honesty that it is a position and not a proof.
What is the gap people actually hit?
The gap is that the model does not know the specific thing your system needs it to know, and that thing was never on the internet. A model at the frontier has read an astonishing amount of public text. It has not read your pricing rules, your last three years of support tickets, the reason your process has that weird exception, or the tacit knowledge in your senior people's heads. That is where a production system fails, not on general reasoning, on your particulars.
Watch where a deployed AI system goes wrong and it is almost never a reasoning failure in the abstract. It is the model confidently applying general knowledge to a case governed by a rule it was never shown. The fix that suggests itself, a smarter model, is the wrong fix, because the next model is smarter about the same public corpus and equally ignorant of your private one.
The gap in a production AI system is usually made of context the model never had, not intelligence it never got. A bigger model is more intelligence applied to the same missing context.
Is scaling even still delivering?
Not on the axis people are waiting on. Pure parameter scaling has been showing diminishing returns, and the binding constraint has shifted from compute to data. Analysis of scaling behaviour finds knowledge-task performance flattening beyond roughly 30 billion parameters, and projections put the exhaustion of high-quality public text somewhere around 2026 to 2028 at current training rates.
The labs are not hiding this. Ilya Sutskever told NeurIPS 2024 that "pre-training as we know it will end", because compute keeps growing while the high-quality data to spend it on does not. The frontier is visibly pivoting to other axes, test-time compute, mixture-of-experts, synthetic data, precisely because the straightforward "make it bigger" lever is losing its edge. Waiting for a bigger model to rescue your system is betting on the one axis the people building the models are quietly stepping off.
Isn't reasoning the counter-argument?
It is the strongest one, and I will not wave it away. Test-time compute, models that think longer before answering, is a real new axis, and it genuinely improves hard reasoning, maths and code. If your gap is that the model cannot reason well enough over information it already has, more reasoning may close it, and that is a case where waiting is rational.
But reasoning operates on available context, and it cannot reason its way to context it does not possess. A model thinking for thirty seconds about a customer whose account rules it has never seen produces a longer, more confident wrong answer, not a right one. Reasoning multiplies what is in the prompt. If your private context is not in the prompt, reasoning multiplies its absence.
| Where your gap lives | Does a bigger model help? | What actually closes it |
|---|---|---|
| General reasoning, maths, code | Yes, reasoning models genuinely help | A better model, or test-time compute |
| Your private data and rules | No, never trained on it | Retrieval, memory, structured context |
| Your process and edge cases | No, invisible to any public model | Encoding the process; a deterministic shell |
| Freshness and change | No, training has a cutoff | Retrieval over live data |
| Reliability of the same answer | No, scaling does not fix variance | System-level reproducibility |
Four of those five rows are not model problems. They are data-and-architecture problems wearing a model problem's clothes, and no size of model touches them.
So where did the bottleneck go?
The bottleneck moved off the model and into the architecture around it, the part that decides what context reaches the model, how reliably, and in what form. This is the whole argument in one sentence: the model got good enough that it stopped being the limiting factor for most tasks, and the limiting factor became whether your system can get the right private context in front of it at the right moment.
That is a data-architecture problem. It is retrieval that returns the correct chunk rather than a plausible one. It is memory that persists what matters and forgets what does not. It is the deterministic shell that hands the model exactly what it needs and checks what it returns. Those are unglamorous, they are yours to build, and they are where the gains now are, while the industry stares at a benchmark leaderboard measuring the axis that stopped mattering for your use case two model generations ago.
The model stopped being the bottleneck for most tasks a while ago. The bottleneck is now whether your architecture can put your context in front of it, and that is your problem to solve, not a lab's.
Where might this bet be wrong?
Three places, stated plainly, because a thesis with no failure conditions is a religion.
If a coming model is not merely bigger but categorically better at acquiring and using context on the fly, genuinely learning your particulars from a handful of examples in a way current models do not, then the architecture I am telling you to build becomes scaffolding you can throw away. That is possible. It has not happened, but the whole history of this field is discontinuous jumps, and betting against the next one has a poor track record.
If your actual gap really is raw capability, you are doing frontier maths, novel code, genuinely hard reasoning over data you already hold, then a better model is the right answer and I am wrong for your case. And if the cost of building the data architecture exceeds the cost of just waiting a year, waiting can be the correct commercial call even if the diagnosis stands.
So this is a bet, not a certainty. It is open. But it is a bet with the current evidence behind it, and its failure mode is cheap: build the data architecture, and if the magic model arrives you have lost some scaffolding. Wait for the model instead, and if it does not arrive on your axis, you have lost the year.
How do you tell which problem you have?
Diagnose the gap before you choose a fix, because the two fixes point in opposite directions.
MODEL PROBLEM OR DATA PROBLEM?
The Hopium Lab · v1.0 · 22 July 2026 · take it, fork it, argue with it
Take three recent failures of your system. For each:
1. WAS THE NEEDED INFORMATION IN THE PROMPT?
[ ] No -> data problem. Retrieval, memory, context. A bigger model
cannot read what you did not give it
[ ] Yes, and it still got it wrong -> possible model problem, continue
2. WAS IT A REASONING FAILURE OR A KNOWLEDGE FAILURE?
[ ] It reasoned wrong over correct, present information -> model/reasoning
[ ] It lacked a fact, rule or your specific context -> data problem
3. WOULD A HUMAN EXPERT WITH THE SAME PROMPT HAVE SUCCEEDED?
[ ] Yes -> the information was there; the model underused it -> model
[ ] No, they'd have needed more context too -> data problem, definitively
TALLY: if most failures are data problems, a bigger model is the wrong
purchase. Build retrieval, memory and structure. If most are genuine
reasoning failures over present data, a better model may be your answer.
THE TEST: could you fix the failure by changing what reaches the model,
without changing the model? If yes, it was never a model problem.
Run that on real failures, not hypotheticals. Most teams discover their "the model isn't smart enough" problem is a "we never gave it the context" problem, and the bigger model they were waiting for would have failed the same cases in a more articulate voice. The gap is closable now, with work you can start today, on the part of the system you actually own.
Ross Jones, Founder, The Hopium Lab. Last modified 22 July 2026.