The sharpest AI split this week is not over benchmarks or benchmarks-to-be. It is over the definition of progress itself.

At Google I/O, Demis Hassabis said humanity is standing “in the foothills of the singularity,” a phrase that does more than hype near-term capability gains. It suggests an inflection already under way, where incremental improvements in model scale, tool use, and agentic workflows could compound into something qualitatively larger. In the same news cycle, Yann LeCun pushed in the opposite direction: current LLMs aren’t intelligent, he argued, because real intelligence shows up when a system solves problems it was not trained on, in situations it has not previously seen.

That disagreement matters because it changes what companies should optimize for right now. If Hassabis is directionally right, then the main task is to keep feeding Transformer-based models into larger systems, better products, and tighter feedback loops. If LeCun is right, then the real frontier is not another wrapper around the current stack but a shift toward learning by doing, child-like learning, and architectures that adapt continuously instead of merely extrapolating from pretraining.

The core dispute is about competence, not just capability

Hassabis’s framing implies that the field may be closer to discontinuity than most deployment teams assume. Even if the singularity remains a metaphor rather than a forecast, the important signal is his confidence that capability is compounding quickly enough to justify strategic urgency.

LeCun’s critique cuts elsewhere. He is not saying today’s systems are useless; he is saying their apparent fluency should not be mistaken for intelligence. In his view, accumulation of text, code, and tool traces does not equal robust problem solving. A model that performs well within the distribution of its training can still fail the moment it must invent a solution, adapt to a new environment, or learn from interaction alone.

For product teams, that distinction is more than philosophical. It determines whether “progress” means higher benchmark scores on familiar tasks or stronger adaptation in novel ones. It also determines how much faith to place in one-shot model releases versus systems designed to learn in production.

What a learning-by-doing stack would actually require

If LeCun’s view wins out, then the current Transformer-centered stack becomes only a component, not the architecture.

A system built for learning by doing would need more than a larger context window and a better system prompt. It would need mechanisms for online or semi-online adaptation, memory that is both durable and governable, and curricula that expose the model to progressively harder tasks with real feedback. It would also need evaluation regimes that measure how quickly the system improves when the problem shifts, not just how well it answers static tests.

That has several technical implications:

Training data stops being a one-time asset and becomes a recurring input loop. Product telemetry, user corrections, environment signals, and task outcomes all become candidates for controlled learning.
Architecture choices start to favor modularity. A pure next-token engine is not obviously enough for child-like learning, where perception, planning, memory, and action may need tighter coupling.
Safety must become dynamic. A model that can adapt after deployment introduces new failure modes: capability drift, reward hacking, and emergent behaviors that were absent at launch.
Benchmarks need to stress novelty. If current LLMs aren’t intelligent in LeCun’s sense, then tests should probe transfer, abstraction, and data efficiency under unfamiliar conditions.

This is why “learning by doing” is such a disruptive phrase. It implies that the model is not merely a finished product at release. It is a system whose competence should deepen through structured interaction.

Product teams should plan for continuous adaptation, not static launch quality

The operational consequence is straightforward: stop treating model deployment as the end of training.

Most AI products today still follow a release cadence inherited from software and foundation-model cycles: train, evaluate, ship, monitor, patch. That works when the underlying model is frozen and improvement happens only in the next version. It works less well if the strategic direction of AI is toward continual learning.

Teams should therefore design for controlled adaptation from day one. That means:

Defining learning objectives, not just quality targets. A useful system should get better at specific tasks over time, and the organization should be able to measure that improvement.
Building constrained feedback channels. User interactions, agent outcomes, and human review should feed learning loops with guardrails, not uncontrolled self-modification.
Separating experimentation from production. If a deployed system is learning, the company needs clear boundaries between what it can change autonomously and what requires approval.
Tracking regression as carefully as gain. In a learning-centric regime, capability gains can come with unintended drift, so safety and alignment checks must scale with adaptation.

This is especially important if Hassabis’s near-term trajectory is right. A rapid capability environment rewards teams that can iterate quickly, but only if they can observe what changed and whether the change is trustworthy.

Market positioning will favor systems that can adapt, not just generate

The strategic fork is obvious once you translate it into competitive dynamics.

If AI continues to improve mostly through scaling and better orchestration around Transformer-based models, then incumbents with compute, distribution, and integration advantages keep compounding. But if the field moves toward systems that learn by doing, then the advantage shifts toward teams that can build flexible architectures, rich telemetry loops, and governance designed for changing models.

That creates a risk for organizations that have overcommitted to static LLM pipelines. They may find themselves with elegant products built on a foundation that looks increasingly incomplete if the market starts demanding genuine adaptation rather than fluent response generation.

The upside is equally clear. Firms that can combine learnable systems with safety controls and rapid iteration cycles will be well positioned if capability jumps become more abrupt. In that world, product defensibility comes less from prompt engineering and more from the ability to operationalize learning without losing control.

What to watch next

Engineers and managers should keep a close eye on signals that the field is moving from static inference toward adaptive intelligence:

Benchmarks for novel-problem solving. Not just more natural-language tests, but tasks that require discovering solutions in unfamiliar settings.
Data-efficiency measures. How much new experience a system needs before it improves on a new task.
Continual-learning performance. Whether updates accumulate skill without catastrophic forgetting.
Agentic reliability metrics. Success rates for systems that plan, act, and recover across multi-step workflows.
Safety metrics under adaptation. Whether alignment holds when the model changes after deployment.

These indicators matter because they map directly to LeCun’s critique and Hassabis’s optimism. If current LLMs aren’t intelligent, then the relevant question is whether new paradigms can close that gap. If we really are in the foothills of the singularity, then the companies that notice the slope first will set the pace.

What this means for your team

For technical teams, the practical response is not to pick a side in the abstract. It is to prepare for both trajectories at once.

Keep shipping on today’s models, but do not assume the current Transformer-based stack is the endpoint. Invest in data pipelines that can support feedback-driven learning. Build evaluation that measures adaptation, not just accuracy. And treat governance as a design constraint, not an afterthought, because systems that learn after deployment will require tighter controls than systems that merely respond.

For product leaders, the message is similar: plan roadmaps around iterative learning-centered cycles, not a single model launch. Revisit partner strategy, compute assumptions, and safety posture now, while the market is still debating whether intelligence is emerging from scale or still waiting for a new architecture.

The deeper lesson in the Hassabis-LeCun split is that AI progress may soon be judged less by how well models sound and more by how well they learn.

AI News

Hassabis and LeCun are not just disagreeing on timing — they are disagreeing on what counts as intelligence

Get the brief in your inbox.