In 1988 the roboticist Hans Moravec noticed something embarrassing about artificial intelligence: it is “comparatively easy to make computers exhibit adult level performance on intelligence tests or playing checkers, and difficult or impossible to give them the skills of a one-year-old when it comes to perception and mobility.”¹ Nearly four decades later that paradox still defines robotics, but the way the field attacks it has been completely rebuilt, twice. This post traces that rebuild: how hand-engineered control gave way to reinforcement learning, why reinforcement learning then lost the manipulation battle to a much older idea (copying people), and how the last four years fused everything into robot foundation models that look strikingly like their language-model cousins. The goal is a self-contained tour: enough math to see why each transition happened, real numbers from the papers that drove it, and a running experiment you can reproduce.

Table of Contents

There is a version of the AI pitch that every engineering leader has now heard. A controlled study hands developers an AI coding assistant, they finish the task 55.8% faster, a vendor slide rounds it to “twice as fast”, and the budget conversation ends with a quiet expectation: the same roadmap in half the time, starting next quarter. This is a short essay about why that expectation fails, and what the people who run teams should steer by instead.

Every morning, your coding agent shows up brilliant and amnesiac. It can refactor a module, chase a bug through five files, and quote the standard library from memory, and tomorrow it will remember none of it: not the bug, not the fix, not the thing you told it three times about how deploys work here. Andrej Karpathy put the complaint bluntly in October 2025: “They don’t have continual learning. You can’t just tell them something and they’ll remember it.” This post is a field guide to the two connected problems hiding in that sentence, remembering (keeping state across sessions) and learning (getting better with experience), and to the machinery being built for both: retrieval scores and memory pipelines, RL-trained librarians, a catastrophic-forgetting experiment you can run in numpy, the elastic weight consolidation derivation in full, and the new architectures that let weights learn at inference time.

In June 2026, two people with unusually good vantage points posted what amounts to the same sentence. Peter Steinberger: “You shouldn’t be prompting coding agents anymore. You should be designing loops that prompt your agents.” Boris Cherny, who created Claude Code: “My job is to write loops.” Both lines are quoted in Addy Osmani’s essay that gave the shift its name, loop engineering, and it would be easy to file them under aphorism if there were not a small, concrete feature sitting underneath: you hand the agent a definition of done, and it keeps working, turn after turn, until that definition actually holds. This is a short guide to that feature, what it does, why it works, and how to fold it into an ordinary day of work.

In late 2025, Andrej Karpathy described going from roughly 80% manual coding to 80% agent coding in a matter of weeks, calling it the biggest change to his workflow in two decades of programming. Coding agents like Claude Code and Codex can now explore a codebase, plan a change, write it, run it, and test it with minimal supervision. Yet the people getting reliably good output are not the ones with the cleverest prompts. They are the ones who noticed that the bottleneck has moved: writing code is now cheap, and deciding whether to trust it is the expensive part. This post distils what top practitioners converge on into seven working principles, aimed at anyone using these tools to build real things.