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.

Table of Contents

Table of Contents

Table of Contents