Prompt engineering is already sounding quaint. The people who build the coding agents have stopped prompting them. Here’s what “loop engineering” actually means, and the one loop nobody can automate.
There’s a quote from a few weeks ago that I keep turning over in my head.
Boris Cherny, the person who built Claude Code, said in an interview that he doesn’t really prompt Claude anymore. “I have loops running that prompt Claude,” he said. “My job is to write loops.”
Sit with that for a second, because it’s a small sentence with a large implication. The guy who built one of the most-used coding tools on the planet has quietly changed jobs, without changing jobs. He’s not writing prompts. He’s not even really writing code in the way we mean it. He’s building the little machine that tells the machine what to do, then watching it run.
Around the same time, an OpenAI engineer, Peter Steinberger, dropped his own version on X: stop prompting coding agents, start designing the loops that prompt them. Someone named it “loop engineering.” The internet, which needs a new discipline to panic about roughly every quarter, obliged. And then Andrew Ng wrote a genuinely useful letter about the three loops he actually uses to build products, which is the part worth slowing down for, because it’s the first version of this idea that isn’t just a vibe.
So let me do the thing I do: take the buzzphrase apart, keep the real bit, and tell you the part the hype is missing. Because there is a real bit. And there’s also a comforting lie buried in the excitement that I want to dig out.
First, what a “loop” even is here
Strip the mystique off and loop engineering is just an old idea wearing new sneakers. It’s control systems. It’s the thermostat. You set a target, the system acts, you measure the gap between where it is and where you wanted it, and you feed that gap back in. Do something, check it, adjust, repeat. Every engineer who’s ever built anything that self-corrects already knows this shape in their bones.
What changed is that, for the first time, the thing inside the loop, the part doing the acting, is a coding agent smart enough to run for an hour without you. That’s the unlock. Last year the agent wrote code and then sat there, tail wagging, waiting for you to tell it whether it worked. This year it writes the code, opens a browser, tests its own work, notices it broke something, fixes that, tests again, and only taps you on the shoulder when it’s genuinely stuck or genuinely done.
Ng’s example is perfectly mundane and exactly the point: over a weekend he had an agent build a typing app for his daughter, and it worked away for about an hour, checking itself in a browser repeatedly, before coming back to him. No hovering. No copy-pasting error messages. The loop closed itself.
The insight worth stealing isn’t “agents got better.” It’s that once your agent can check its own work, you stop being its babysitter and start being its director. And a director operates at a completely different altitude than a typist.
The three loops, and why the speeds matter
Here’s where Ng’s framing earns its keep, because he doesn’t talk about one loop. He talks about three, nested inside each other, each running at a wildly different tempo. Think of them like gears, or like orbits: a fast inner one, a slower middle one, and a slow outer one, all turning at once.
Screenshot 2026-09-04 at 7.48.01 PM.png
The inner loop is the agentic coding loop, and it runs in minutes. Write, build, test, repeat. This is the part that got automated over the last year, and it’s the part everyone’s tweeting about. It’s genuinely a game-changer, and it’s also, increasingly, not your job. The machine owns this gear now.
The middle loop is the developer feedback loop, running in tens of minutes to hours. This is you looking at what got built and deciding it’s wrong, not buggy-wrong, but wrong-wrong. The cat costumes should unlock differently. The login flow for a parent is clunky. The whole visual direction feels off. Last year, developers wasted this loop playing QA, hunting for bugs the agent should have caught. Now that the inner loop catches its own bugs, this middle loop gets freed up for the decisions that actually need a brain with taste.
The outer loop is the external feedback loop, and it grinds along in days to weeks. Real humans touch the thing. You ship to a few friends, run an A/B test, watch what actual users do versus what you smugly assumed they’d do. This is the slowest, most annoying, and most important gear, because it’s the only one connected to reality instead of your own opinion of reality.
Here’s the part I love, and the part the buzzphrase flattens: the loops feed each other. The outer loop reshapes your vision, which rewrites the spec, which redirects the inner loop. Reality flows inward, slowly. And speed flows outward, the fast loop producing the thing the slow loop gets to judge. It’s not three tricks. It’s one nested system with reality on the outside and raw execution on the inside.
The comforting lie in all this
Now the part I promised to dig out.
The hype version of loop engineering whispers something seductive: automate the loops and you’re done. Build the perfect harness, set it running, walk away, come back to a finished product. The dream is a closed loop, a machine that needs no human at all. Just add more agents.
That’s the lie. And Ng, to his credit, says so plainly, though he says it politely and I’ll say it bluntly.
The inner loop automates beautifully. The outer loops do not, and it’s not because the tech isn’t ready yet. It’s structural. The reason a human has to sit in the middle and outer loops is that the human knows things the agent doesn’t. You know who the user actually is. You know the office politics of the client. You know that your daughter loves cats and will abandon the app in four seconds if the costumes are lame. That knowledge isn’t in the training data and isn’t in the spec until you put it there.
Everyone calls this human contribution “taste.” I think that’s a flattering word for a boring truth: you simply have more context than the machine. And the moment you don’t, the loop can close without you.
I actually prefer Ng’s reframe here to the usual “AI can’t replace human creativity” cope, because it’s honest and it’s a little unsettling. It’s not that machines lack some magical human spark. It’s that, for now, you hold context the model can’t see. That’s a gap, not a soul. And gaps close. The parts of your judgment that are really just “I’ve seen this before” will get automated. The parts that are “I know this specific user in this specific world” will last longer. Knowing which of your instincts is which is suddenly a career skill.
The maker-checker trick that makes it all work
One under-hyped detail deserves a spotlight, because it’s the load-bearing wall of the whole thing.
The reason the inner loop can run unsupervised isn’t that the agent got smart enough to trust itself. It’s that the good setups don’t trust it to. The most consequential design choice in a real loop is splitting the agent that writes the code from the agent that checks it. A model grading its own homework is a soft touch, it’ll reason its way into believing its bug is a feature. So you put a second agent, with different instructions and no ego investment in the first one’s work, in the role of skeptic. Maker proposes. Checker disposes.
That’s it. That’s the trick that turns “an agent that writes code” into “an agent that writes code you can leave alone for an hour.” Not a bigger model. A second, adversarial one. If you’ve ever shipped better work because a ruthless colleague reviewed it than because you reviewed it yourself, you already understand why this works and why “just trust the AI” was never going to.
So what does this mean for you, actually
If you write software, the shift is already underway and it’s mostly good news, with one catch.
The good news: you get promoted whether you like it or not. When the inner loop runs itself, your time moves up to the middle and outer loops, which is to say you become part product manager, part director, part the-person-who-decides-what’s-even-worth-building. Ng’s quiet prediction is that engineers are growing into product roles the same way PMs and designers backed into doing more engineering. The org chart is blurring, and the people who thrive will be the ones comfortable zooming between “why does this feature exist” and “why is this test flaky” in the same afternoon.
The catch: writing loops is a genuinely different skill than writing code, and it’s closer to systems design than to typing. You’re no longer solving the problem. You’re designing the system that solves the problem, then designing the checks that catch it when it solves the wrong problem confidently. That’s a harder, more abstract job than most “AI will make coding easy” takes admit. Loop engineering doesn’t make software effortless. It moves the effort somewhere more interesting and, honestly, more demanding.
And the part that lingers, the reason I can’t stop thinking about Cherny’s line, is what it implies about the trajectory. He automated his own prompting by writing a loop. The natural next move is a loop that writes the loops. Then a loop that decides which loops to write. Each level up, the human does less of the doing and more of the deciding, until the only thing left that’s unmistakably ours is the context, the messy, specific, hard-won knowledge of who this is for and why it matters.
Hold onto that part. It’s the last gear reality still hands to you personally.
For now.
-Hardik
I’ve spent about two decades building data and AI systems, long enough to watch “the skill everyone must learn” get renamed every couple of years while the underlying job, thinking clearly about systems, stays exactly the same. I write about what’s actually changing under the hype, and what quietly isn’t. If this reframed how you see your own work, subscribe. I’ve got loops running.
Sources / further reading: Andrew Ng, “Three Key Loops for Building Great Software,” The Batch, issue 359 (DeepLearning.AI, June 2026). Boris Cherny (Claude Code, Anthropic) on “I don’t prompt Claude anymore… my job is to write loops,” via CNBC / Business Insider (June 2026). Peter Steinberger (OpenClaw) on designing loops that prompt agents, via X. Addy Osmani, “Loop Engineering,” on the five/six-part loop architecture (discovery, task decomposition, orchestration, verification, persistent memory). The New Stack and Slashdot coverage of the loop-engineering discussion (June 2026). On the maker/checker split: Anthropic’s writing on harnesses for long-running agents.
