What are AI scaling laws?

AI scaling laws are empirical curves showing that a language model's prediction error falls in a predictable way as you increase three inputs: the number of parameters, the amount of training data, and the compute spent training. The canonical reference is Scaling Laws for Neural Language Models, published by Jared Kaplan and colleagues at OpenAI in January 2020, which found that test loss tracks those three inputs as power laws across many orders of magnitude. The critical detail for anyone building a product is what the curve is fitted to. It predicts loss, meaning how well the model predicts the next token, not whether the model can do a specific job. Capability has broadly followed loss, but not in every case, which is where planning goes wrong.

What are the three scaling laws in AI?

The three scaling laws are pre-training scaling, post-training scaling, and test-time scaling. Pre-training scaling is the original one from the 2020 Kaplan paper: prediction error falls as a power law when you add parameters, data, and training compute. Post-training scaling covers everything applied after the base model exists, including fine-tuning, reinforcement learning, distillation, and synthetic data. Test-time scaling means spending extra compute at inference so the model reasons before answering. Nvidia has pushed this three-part framing since late 2024. The distinction is practical rather than academic: they are three different places to spend money, and the record shows they do not buy the same capabilities.

Are AI scaling laws still holding?

AI scaling laws are still holding on the thing they actually measure. Loss keeps falling predictably as model size, data, and compute go up, and OpenAI president Greg Brockman describes the empirical picture as models getting correspondingly more capable with no wall in sight. The catch is that the curve is fitted to prediction error, not to any specific skill. Francois Chollet points out that base models were scaled by 50,000 times between GPT-3 and 2026 while their scores on the ARC-AGI-1 benchmark stayed near the floor, from 0 percent for GPT-3 to 5 percent for GPT-4o. So the scaling laws are holding and one particular capability still did not arrive on them. Both are true at once, and that is the part worth planning around.

Does AI have a scaling problem?

AI does not have a problem with the scaling curves themselves, but there is a real limit on what they reach. Progress is fastest in domains where a machine can verify whether the answer is correct, because that allows an automated loop: generate candidate solutions, check them mechanically, and train on the ones that pass. Code was the first domain to fall for exactly this reason, and mathematics is widely expected to follow. In domains with no mechanical grader, such as writing or law, improvement depends on expensive human annotation and moves much more slowly. The useful question for a product team is therefore not whether scaling continues but whether your own domain sits on the verifiable side of that line.

AI Scaling Laws: What They Actually Promise

Every AI roadmap argument eventually reaches the same fork. One person says the next model will handle it, so do not build that. The other says the next model has been six months away for two years, so build it. Both sides invoke scaling laws, and neither side is usually arguing about what the scaling laws actually claim.

AI scaling laws claim less than the argument gives them credit for, and the narrow version is the one you can plan against.

What AI scaling laws actually say

AI scaling laws are empirical curves showing that a language model's prediction error falls in a predictable way as you increase three inputs: the number of parameters in the model, the amount of training data, and the compute spent training it. Not that the model gets smarter, and not that it acquires a new skill. Error goes down, and it goes down as a smooth power law you can extrapolate.

The canonical reference is Scaling Laws for Neural Language Models, published by Jared Kaplan and colleagues at OpenAI in January 2020. It found that test loss tracks model size, dataset size and training compute as power laws across many orders of magnitude, and proposed a rule for splitting a compute budget between a bigger model and more data.

DeepMind corrected the split two years later. Training Compute-Optimal Large Language Models, the 2022 Chinchilla paper, found that the Kaplan allocation was too model-heavy: for a fixed compute budget, parameters and training tokens should scale roughly in step. Many of the era's largest models were undertrained, and would have been better built smaller and fed more data. That is worth remembering the next time a scaling law is quoted as settled physics. The first one was revised just over two years later by a rival lab.

The industry now talks about three scaling laws rather than one, a framing Nvidia has pushed since late 2024. Its write-up names pre-training scaling (the original), post-training scaling (fine-tuning, reinforcement learning and distillation applied after the base model exists), and test-time scaling, where you spend extra compute at inference so the model reasons before it answers. They are three different places to put a dollar, and as the rest of this article argues, they do not buy the same thing.

Inside a frontier lab the curves are treated as close to a law of nature. Greg Brockman, OpenAI's president, put it this way at Sequoia:

"the scaling laws are a deep and very beautiful mystery"

He is precise about what kind of truth they are. They "feel deeply fundamental", he says, and they are empirical rather than derived, since "we don't necessarily have all the theory to explain exactly why it works". Then comes the sentence founders quote at each other:

"as you pour more compute into the models, they get correspondingly more capable and it just keeps going. There's no wall."

That is the strongest version of the case, from someone with the best possible view of the training runs. The interesting question is not whether he is wrong. It is which capabilities the record shows arriving on that curve, and which have not.

The gap between lower loss and new capability

A scaling law is fitted to loss. Loss measures how well a model predicts the next token in text it has not seen. Your customer's job is not next-token prediction. The industry's working assumption is that capability follows loss, and across an enormous range of tasks it has.

François Chollet has spent longer than the scaling debate has existed measuring the thing scaling does not buy. He created the Keras deep learning library, published the ARC-AGI benchmark in 2019 out of program-synthesis work he began years earlier, and left Google in 2024 to co-found Ndea with Zapier co-founder Mike Knoop, a lab pursuing AGI through deep learning-guided program synthesis rather than through scale. ARC-AGI tests how efficiently a system picks up a rule it has never seen, which is precisely the thing more training data cannot hand it.

On Y Combinator's Lightcone he gave the single cleanest data point in the scaling argument. Between GPT-3 and the base models of early 2026, he says,

"we had scaled up these models by 50,000 X"

Across that entire span, base models without reasoning stayed near the floor of ARC-AGI-1. The published scores are blunt: GPT-3 scored 0 percent, GPT-4 near zero, GPT-4o reached 5 percent. Nearly five orders of magnitude of additional pre-training scale, and that particular capability did not show up.

Read that next to Brockman's sentence and you get the honest picture, which is not that one of them is wrong. Loss kept falling. Capability kept arriving. One specific capability, learning an unfamiliar rule from a handful of examples, did not arrive with it. Scaling was buying real things and not that thing.

This is the practical form of the question every founder is actually asking. It is not whether scaling laws are holding. They are. It is whether the capability your product is waiting on rides the curve, or sits off it.

What actually broke ARC-AGI, and why it was not more scaling

ARC-AGI-1 did eventually fall, and how it fell is the useful part.

The step change came from reasoning models rather than from bigger base models. In December 2024, OpenAI's o3 scored 75.7 percent on the semi-private evaluation set under high-efficiency settings and 87.5 percent in a high-compute configuration, against 5 percent for GPT-4o. That is not the pre-training curve. That is the reasoning-model paradigm, post-training and test-time compute together, doing something the first law had not. ARC Prize also notes that OpenAI trained the o3 it tested on 75 percent of the public training set, so the score is not a clean out-of-the-box result either.

ARC-AGI-2 then went the same way, through a mechanism you can copy. Chollet's account of the shape is worth noting: the earliest reasoning models scored very low on ARC-AGI-2, and then, at roughly the moment coding agents started working, it saturated fast. Chollet describes the loop labs ran against it: you ask a reasoning model to generate more tasks like the benchmark's, you solve them, and then, because the answers can be checked mechanically,

"generate new tasks, you solve them, you verify the solution, you fine-tune the model on the reasoning chains"

Repeat that a few million times. His summary of what the loop costs is the least mystical sentence in the interview: "you just need to spend more money".

And then the correction that should reorganize your roadmap. Chollet is explicit that this did not produce smarter models:

"The models don't have higher fluid intelligence per se. They don't have like a higher IQ, so to speak. It's just that they're way better trained."

He generalizes it: "there's always a trade-off between intelligence and knowledge". Better training substitutes for raw reasoning ability, and for building a product, better-trained beats smarter every time. But it only works where the loop can run, and the loop needs one specific ingredient.

The line that decides whether AI progress reaches your product

That ingredient is a reward you can trust without asking a human.

Chollet's claim here is strong, and the coding evidence supports the direction if not the word fully. He states the qualifying condition, then the consequence:

"any problem where the solutions you propose can be formally verified and you can actually trust the reward signal. It's not just some guess made by a model. Any domain like this can be fully automated with current technology"

The reason coding moved first is not that code is intellectually easy. It is that "code provides you with a verifiable reward signal". Tests pass or fail. Code compiles or does not. As he puts it: "And code is sort of like the first domain to fall but there will be many others in the future." He expects mathematics next, for the same structural reason, and is careful to call that one pending rather than done.

Now the other side of the line, which is where most startups actually live. In the domains with no mechanical grader, "writing essays is, you know, the typical example of the domain that's not verifiable". Progress there depends on human-annotated preferences, which are slow and expensive to produce, so improvement is slow and may stall. Law is in the same category. So is most of what happens in a sales call, a diagnosis, a design review, or an underwriting decision.

The relevant question is not the shape of a curve on a log-log plot. It is a yes or no question about your own domain:

Can a machine check whether the work was done correctly, without a person looking at it?

If yes, expect capability in your domain to improve quickly, and expect it to improve for your competitors too, because the loop that produces it is available to anyone who can buy compute. Your advantage will not be model quality. It will be distribution, proprietary data, and owning the workflow.

If no, the next model will help you less than the roadmap assumes, the gap will close slowly, and the thing standing between you and a working product is not a model release. It is that nobody has built the grader yet. Which is a job, and it might be yours.

Building the verifier is the actual work

If your domain has no natural verifier, the leverage is in constructing one. That is what the harness around a model does: it turns a fuzzy task into a structured one with checkable intermediate results.

Chollet is clear-eyed about what harness engineering is and is not. He treats the fact that "you need humans to engineer these harnesses" as evidence the field is short of general intelligence, since a genuinely general system would work out its own approach. In the same breath he calls it a very valuable area of research, because it is what converts capability into task automation at scale. Both things are true, and the second one is the one you get paid for.

Brockman describes the same distance from the other side, talking about what it took to make coding agents work outside a benchmark. Solving programming competitions was not enough: "you need something that's seen real-world messy codebases". His remedy there is training exposure rather than harness design, but the distance he is describing, between a benchmark score and software that survives contact with a real customer, is the distance a good harness closes.

In practice, for your product, building a verifier means:

Defining done, mechanically. Not a judgment that the summary reads well, but a set of checks a script can run: the five required fields are present, no figure appears that is not in the source document, every citation resolves.
Instrumenting the correction. Where a human currently fixes the output, capture the fix. That is your reward signal, and it is the one asset a lab cannot buy. This is the same machinery that makes continual learning possible, and the same reason LLM evals are worth more than they look.
Deciding whether to train. Once the verifier exists you have the option to go further and train against it, which is what RL environments are for, and what it costs.

Notice the order. The verifier comes first, and it is useful on its own even if you never train anything. Most teams try to skip to the training step and discover they have nothing to train against.

The security cost of a reward signal you trust

This is the part that gets skipped, and it follows directly from everything above. The moment a verifier is good enough to run an automated loop against, that verifier becomes a security boundary. Whatever it approves, the system will produce at scale.

A grader with a hole in it does not fail loudly. It gets optimized into. Any process that generates candidates and keeps the ones that pass will find the cheapest way to pass, and if a shortcut satisfies the check without doing the work, the loop will discover it far faster than your team will. The same property that makes a domain automatable, a signal you can trust without a human, makes a flawed signal dangerous in proportion to how much you trust it.

Three controls are worth putting in early, while the loop is small:

Treat verifier code as security-critical code. It gets review, version history, and a named owner. A silent change to a grading rule is a silent change to everything the system will produce next month.
Keep adversarial cases in the eval set. Deliberately include inputs where the obvious shortcut passes the check but the work is wrong. If your grader cannot catch a case you constructed on purpose, it will not catch the ones the model finds on its own.
Never let the system define its own success criteria. The reward definition is a human decision with an audit trail. Delegating it to the thing being rewarded is how automation goes quietly wrong.

None of this slows you down much at the start, and all of it is expensive to retrofit once a year of output has been produced against a grader nobody reviewed.

Where AI scaling laws stop and your roadmap starts

The answer is not the same for every part of your product.

Wait when the capability you need sits squarely on the verifiable side of the line and the labs are already pushing on it. Anything that looks like writing, running and checking code is the clearest case. Building your own version of that today means competing against a loop funded by billions of dollars of compute. Design a clean seam instead, so a better model drops in without a rewrite, which is the whole subject of building for the next AI model.

Build when the gap is in the harness rather than in the model. If your product fails today because nobody has encoded what counts as correct in your domain, no model release fixes that. That work is yours, it compounds, and it is not on anyone's roadmap but yours.

Chollet's own test for whether an approach is worth pursuing transfers directly to a startup. "I think you are looking for approaches that scale," he says, and what he means by scale is specific:

"You want to be in a setup where the system can improve its capabilities with no human in the loop, with no human input."

Otherwise capabilities are bounded, and he names the bound exactly: "They're going to be bounded by human investment".

Applied to a company rather than a lab, that is a question you can answer this week. When your product gets better, is it because your team put in hours, or because the system learned something from usage? The first is a service business with software margins on the pitch deck. The second compounds. It is the same distinction that separates a real moat from a temporary one, which is why it runs through the AI for startups pillar and through competitive moats in AI.

Which is the honest end of the AI scaling laws conversation. A date on a curve is not a strategy, any more than an AGI timeline is. What you can check, and what you can build a grader for, is.

What to do this week

Answer the yes-or-no question for your product in writing: can a machine tell whether the work was done correctly, without a person looking? Do it per feature, not per company. Most products land on both sides.
Take your single most expensive human review step and try to express correct as five mechanical checks. If you can, you have found a verifier. If you cannot, you have found what your competitors also cannot do.
Find where users currently fix your output, and start capturing the fix rather than a thumbs up. The correction is the reward signal.
Split the roadmap into two lists: capabilities on the verifiable side that the labs will deliver, and capabilities that need a harness only you will build. Stop funding the first list.
Put an owner and a review process on any grading or scoring code you already run, and add three adversarial cases where a shortcut passes the check.
Delete any planning assumption that depends on a specific model landing on a specific date. Replace it with the seam that lets you swap models when one does.

Working out which capabilities to wait for, which to build, and how to tell the difference is the core of the AI Operating System for Startups.

Sources

François Chollet: Why Scaling Alone Isn't Enough for AGI, Y Combinator's Lightcone, the interview this article distills, for the 50,000X figure, the ARC-AGI history, the verifiable-rewards argument, and the harness discussion.
OpenAI's Greg Brockman: Why Human Attention Is the New Bottleneck, Sequoia Capital, for the frontier-lab view of the scaling laws and the point about messy real-world codebases.
Scaling Laws for Neural Language Models, Kaplan et al., OpenAI, January 2020, the paper that made scaling laws canonical for language models.
Training Compute-Optimal Large Language Models, Hoffmann et al., DeepMind, 2022, the Chinchilla correction to the compute allocation.
How Scaling Laws Drive Smarter, More Powerful AI, Nvidia, for the pre-training, post-training and test-time framing.
OpenAI o3 Breakthrough High Score on ARC-AGI-Pub, ARC Prize, for the o3 scores and the earlier GPT model scores on ARC-AGI-1.
Background on the people and labs named: François Chollet and Ndea, reported at launch by TechCrunch, which also covers Ndea co-founder Mike Knoop and his Zapier background; and Greg Brockman, president and co-founder of OpenAI.