The claim in the title is not that language models are finished or overrated. I use them daily and half the things on my work page have one somewhere inside. The claim is narrower and, I think, harder to argue with: the interesting difficulty in this field has moved. It used to be can the model produce the right answer. It is now can a system act on that answer, in time, on hardware you control, and survive being wrong. Every one of those clauses is a robotics problem, and they were robotics problems long before they were AI problems.
A model trained on the internet is trained on a finished artefact. It is a very large photograph of what people had already written down by a certain date, and the supply of that is not growing at the rate the training runs are consuming it. More importantly, it is a record of what humans found worth saying — which systematically excludes everything too obvious, too physical, or too continuous to be worth writing down. Nobody wrote a blog post about how a wheel behaves on wet tile.
A system with a body does not have that problem. It generates its own data, continuously, and every sample is labelled by the world rather than by an annotator. That is not a small advantage. It is the difference between a corpus that runs out and one that does not.
I spent months this year training a segmentation model on aerial imagery of Accra, and the most useful thing I learned had nothing to do with architecture. Every improvement I made to the model stopped registering, and the reason was that I had been grading it against labels that were themselves wrong — building footprints offset by a metre or two, adjacent structures merged into one. The benchmark was the bottleneck. When I rebuilt the metric to only score pixels that two independent sources agreed on, the model I already had jumped from an apparent 0.58 to a real 0.77, without retraining anything.
That failure mode is endemic to a field that evaluates itself on datasets. You can spend a year improving a number that does not measure what you think it measures. A robot cannot do this. If the perception is wrong, the car hits the obstacle, and the run ends in front of judges. There is no version of that where you got a better score for the wrong reason. Embodiment is not just a source of data — it is a source of honest data, and the field is short on those.
In a chat window, slow is annoying. In a moving system, slow is wrong. A perfect answer about what is in front of a robot, delivered four seconds late, is not a slightly worse answer — it is an answer about a world that no longer exists.
This changes the architecture, not just the performance budget. When I built a real-time perception system this year, the governing rule ended up being drop stale, never lag: every hand-off between stages holds exactly one frame, the newest, and a slow consumer sees fewer fresh frames rather than a growing backlog. That is the opposite of how almost all AI infrastructure is built. Queues, batching and retries all trade latency for completeness, which is correct for a job and wrong for a stream. And it forces the expensive model into its proper place: not on every frame, but gated — fired when the cheap, always-on layer says something changed.
I think that shape — a fast deterministic loop with an expensive model gated behind it — is where most useful AI systems end up, and robotics got there first because it had no choice.
Building here has made this obvious to me in a way I do not think it would have elsewhere. The network is not reliable, the hardware is whatever you can actually buy, and the assumption that you can call a data centre in the loop is simply not available.
So the robot I built runs entirely offline — wake word, speech, vision and the language model all on a Raspberry Pi, no cloud call anywhere. The competition car does all of its perception on-board because the rules and the physics both forbid offloading it. The student app I am building schedules its reminders locally, because the moment someone most needs a deadline warning is not reliably a moment they have data.
None of those were ideological choices. They were the only designs that worked. But they are also, exactly, the architecture that embodied AI requires — local inference, bounded latency, graceful degradation when a component dies. Building under constraint is not a disadvantage to be apologised for. It is early practice for the problem the rest of the field is walking towards.
Not humanoids in every home. The version I would defend is duller and more likely: the frontier of this field stops being measured in benchmark scores on static datasets and starts being measured in whether a system holds up in contact with a world that does not care about it. Perception that runs where the sensor is. Models that are one component of a system rather than the system. Failure that is visible immediately instead of six months later when someone audits the eval.
The other reason I believe it is simpler. The best debugging tool I have ever used is a machine that visibly does the wrong thing in front of me. You cannot argue with it, you cannot reframe the metric, and it does not care how good the architecture diagram looked. Every field gets better when it gets a grader like that. AI is about to get one.