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.