Coder Legion - Recent posts tagged loop-engineering

Prompting Is Dead. Long Live Graphs.

Sat, 19 Sep 2026 06:03:05 +0000

AI engineering renames itself every six weeks. Underneath the funeral, something real is happening and it's not what the eulogy says.

There’s a clip going around, an Anthropic lead in an interview, saying, roughly, that we don’t prompt models any more, we build the loops and now the graphs that do, and that in a few months prompts will be a thing of the past.

Predictably, the timeline heard: prompting is dead. Courses were announced by Sunday.

Now, before we go further: the sentiment is real and it’s coming from real people. Claude Code’s creator Boris Cherny said “I don’t prompt Claude anymore,” his job is to write the loops that do. That’s the origin of “loop engineering,” a name Addy Osmani popularized on June 7. Loop engineering then enjoyed exactly six weeks of fame before Peter Steinberger asked on X, “Are we still talking loops or did we shift to graphs yet?” and Hamel Husain filed the obituary within hours: Loop Engineering Is Dead. Enter Graph Engineering.

Six weeks. Some yogurts last longer.

So I’m not here to argue with the practice; the practice is right. I’m here to argue with the verb replaced, because it hides the one insight that actually matters, and because “prompting is dead” is going to make a lot of people build the wrong thing.

Nothing died. Everything got wrapped.
Line up the “dead” disciplines and look at what each one actually controls. Prompt engineering: the words you send. Context engineering: everything the model sees. Harness engineering: the code around the model, tools, files, state, errors. Loop engineering: the cycle that drives one agent toward a goal. Graph engineering: who runs when, and who checks whom, across many agents.

Not one of these replaced the one before it. Each wraps it. A graph is made of loops. Each loop needs a harness. Every harness call is a context problem. Every context contains prompts. Nobody stopped writing prompts; the prompt just got promoted from thing a human types to thing the system types, at the right node, with the right state. Saying prompts are dead because we build graphs is like saying sentences are dead because we invented paragraphs.

What “died” is the career: sitting there typing clever instructions by hand. Fine. That was always a job description with a countdown timer on it.

A loop is a one-node graph, and that’s the whole reveal
Here’s the mechanical fact that makes the loop-vs-graph war slightly ridiculous. A loop is: find the next piece of work, plan, act, check the result, continue or stop. Draw that on a whiteboard. It’s a single node with one edge pointing back at itself.

Congratulations. You’ve been doing graph engineering. Just with a very small graph.

The graph shows up the moment your task grows a second goal. A launch needs research, copy, code, legal review, approval. A code change needs analysis, implementation, security review, tests, release. You can build a loop for each. But someone has to connect them: which can run in parallel, which model does which step, who verifies whom, where the human veto sits. That connective tissue was always there, hidden in someone’s head or someone’s bash script. Graph engineering just means drawing it, and then treating it as a first-class thing you design, test, and version.

Graphs don’t replace loops. They connect and govern them.

That’s it. That’s the whole discipline. Everything else is nodes, edges, and state — which, as any grey-haired engineer will tell you while pointing at a workflow engine from 2013, is not exactly a fresh idea.

Okay, so what actually changed?
If the structure isn’t new, why does it feel new? Because the nodes changed. In a 2013 workflow engine, a node followed rules. Now a node interprets its task. And that one difference forces a decision every agent builder eventually hits the hard way: who decides what runs next?

Early agents let the model decide everything: which tool, what’s next, whether to stop, all mid-flight, all in one context window. It looks wonderfully general in a demo. In production it produces wonderfully general ways to fail: agents looping needlessly, skipping business logic, losing state, drowning their own context in tool output.

The pattern converging across the industry now is the opposite split. Google made it explicit with ADK 2.0: code controls predictable routing, models handle steps needing judgment. Anthropic’s version is Claude Code’s dynamic workflows, where Claude writes a small JavaScript orchestration script that coordinates parallel subagents, so the model spends far fewer tokens repeatedly deciding what to do next.

Read that as a rule and it’s clean: edges are code, nodes are model. Routing is boring and should be deterministic. Judgment is expensive and should be spent only where interpretation is actually needed. Every “graph engineering” tutorial that skips this rule is just spaghetti with better naming.

Two more things the graph makes visible that the loop hides. First, state: a loop keeps it in the context window, which is why long loops get amnesia; a graph forces state to be explicit and shared. Second, checking: a loop tends to check itself, which is like marking your own exam; a graph lets you add an independent verifier node, and, crucially, a loop that watches the metric your optimizing loop is chasing. An optimization loop without a checking loop becomes very good at producing the wrong result, and it produces it with tremendous confidence.

Loop vs graph, honestly, on every axis
Since the clip promised “differences from all aspects,” here’s the whole thing on one card.

Notice the failure-mode row. Loops fail by running forever or lying to themselves. Graphs fail differently: you draw a beautiful box-and-arrow diagram and discover you have carefully documented a traffic jam. Neither is free. The graph just moves your bugs from “invisible and in the model’s head” to “visible and in your architecture,” which is a trade I’ll take every time, but it is a trade.

Fine print, because the timeline skipped it
Three things Turing Post flagged that deserve amplifying. “Graph” now means four different things: a control graph (what runs next), a knowledge graph (GraphRAG, entities and relations), an execution trace (what happened in one run), and an improvement graph (loops auditing loops). People are stapling all four together in the same viral post. The stats are borrowed: the “18% more accurate, 85% cheaper” figure that toured the internet came from a GraphRAG paper on industrial engineering diagrams, a narrow result promoted to a general law. And Anthropic has not announced a discipline called graph engineering. It ships coded orchestration and five composable agent patterns from its “Building Effective Agents” guide, prompt chaining, routing, parallelization, orchestrator-workers, evaluator-optimizer, which, if you draw them, are a line, a branch, a fan-out, a hub, and a loop. Graph engineering is the label. Those are the mechanism.

Do you actually need one?
The most useful sentence in this whole discourse is also the least retweeted: most agents still don’t need a graph. One model, one tool loop, a good stopping condition covers an enormous amount of real work, and every graph framework you add brings state management, routing logic, and new places to break.

So the efficient way to use all this, architect hat on: start with a loop; you’ll be surprised how far it goes. Add a graph the moment you have real parallelism, a need for an independent verifier, or a human who must approve something consequential. When you do, put routing in code and judgment in the model, make state explicit, and give every loop a stop condition and a budget, because “when the test passes” is a stop condition and “when it feels done” is a séance. Hand-roll it first, in Claude Code or a plain script; lift it into a framework only when the shape stabilizes.

And when someone tells you graph engineering improved accuracy by 18%, ask three questions: which kind of graph, compared to what, and where did the number come from. That eliminates a surprising amount of graph engineering.

Someone has already proposed “metagraph engineering,” because the internet remains undefeated. The name will change again by autumn. The problem won’t: how to split work, control execution, check claims independently, preserve state, and keep humans in charge of the decisions that should stay theirs.

Prompts aren’t dead. They just stopped being the thing you type and became the thing your system types.

You didn’t lose a skill. You got promoted.

-Hardik

buymeacoffee.com/HardikGoel

I’ve spent about two decades building data and AI systems, and I’ve watched roughly nine “revolutionary” orchestration paradigms turn out to be nodes, edges, and state with a new logo. This one has real substance under the rename, which is rarer than it sounds. I write about AI’s mechanics, its hype cycles, and its remarkably short-lived funerals. Subscribe. Loop engineering would have wanted it that way.

Sources / further reading: Turing Post, “Is Graph Engineering Real?” (Ksenia Se, July 20, 2026), the best-sourced fact-check of the whole cycle, including the four meanings of “graph” and the borrowed 18%/85% figures. Addy Osmani, “Loop Engineering” (June 7, 2026). Peter Steinberger’s and Hamel Husain’s posts of July 18. Anthropic, “Building Effective Agents” (2024) and Claude Code’s dynamic workflows documentation. Google’s ADK 2.0 announcement on code-controlled routing. Louis Bouchard, “Graph Engineering vs Loop Engineering,” and MarkTechPost’s three-layer explainer (July 29). Note: I couldn’t access the specific interview clip that prompted this piece, so where I paraphrase the Anthropic lead, I’m relying on their published statements and the primary sources above rather than the clip’s framing; if the clip says something sharper, the primary sources still stand.

Loop Engineering: Why “Writing Loops” Is the New “Writing Code”

Fri, 04 Sep 2026 14:20:26 +0000

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.