The headline says loop engineering is dead. The body of that same article already walks it back. What died is the version where the model grades its own homework and the retry counter never hits a wall.
The headline says loop engineering is dead. The body of that same article already walks it back. What died is the version where the model grades its own homework and the retry counter never hits a wall. That is not an obituary. That is a missing control plane. The data is real. The diagnosis is incomplete. I read Loop Engineering Is Dead: Here's the Data Behind the AI Backlash the way I read most 2026 obituaries: look for the failure, then look for the thing they still cannot kill. The failure is easy to name. Uber reportedly burned a year of AI budget in four months and then capped each engineer at about $1,500 per coding tool per month. Agents already cost roughly four times a normal chat, and up to fifteen times in a multi-agent stack, according to Oracle's writeup of the agent-loop pattern. If the only stop is the model saying "done," you do not have a loop. You have a tap. The article gets three things right, and I will not pretend otherwise. First, the AI saying it finished is not proof it finished. If the only check is the same model asking itself whether the work is good, that is a status update, not a test. Second, retries without a cap get expensive in silence. The bill arrives before the architecture review does. Third, a human still has to own the failure. Demos hide the steering. Production does not. Then the piece says the quiet part: the unglamorous version is not dead. Build a real check. Set a hard limit. Do not trust a claim you have not verified. I already wrote that what comes after microservices is an agent with a budget . This backlash is the receipt for skipping the budget. What I run instead of an obituary I did not want another essay about loops. I wanted a pipeline I could kill. In a lab I keep under learning-with-me, six roles run against a real local git repo and a real build. Team composition is YAML. Technology is YAML. Java does not mention Gradle. The Developer writes files. A deterministic gate runs an allowlisted test command. The agent cannot invent a shell string. The interesting part is not the role names. It is that every rework path has a goal a machine can reject, a cap in the team policy, and an escalate when the cap is hit. Hitting the cap does not spin. The run ends as ESCALATED . Loop Goal the machine can reject Default cap Exit L1 spec every acceptance criterion traces to a planned test 2 AiSpec.covers(featureBrief) L2 impl the project's test command is green 3 BuildResult.success L3 review no blocking findings on the git diff 3 ReviewVerdict.approved L4 QA score above a threshold against the criteria 3 QaVerdict.passed after evidence reconcile Outer a stakeholder ends the cycle 2 approved, or escalate L3 and L4 do not re-run the Developer because a prompt felt optimistic. They re-run only when the previous verdict asked for changes. The AI saying "done" is a status update. A green build is a check. That is loop engineering after the marketing fell off. It is also just software: typed verdicts, a path jail, argv from config, no push from the agent, artifacts you can replay. The model is a worker inside a gate. The gate is not a model. Graph versus loop is a fight we do not need A few weeks after the first "loop engineering" wave, the next brand showed up: graph engineering. Coordinate many agents. Explicit topology. Shared state. Supervisors. I already have that, and I did not need a new noun. The pipeline is a graph. Spec, implement, review, QA, stakeholder. Review and QA wrap the Developer in a conditional. Missing roles skip their node. Lean pair has no QA loop. Caps still apply to the loops that exist. A graph without loops cannot retry a failed test. A loop without a graph cannot say who owns the next check. The teams that got burned did not fail because they used a loop. They failed because one agent owned generate, judge, and stop. That is a conflict of interest we already know from code review. You do not let the author merge their own PR because they feel good about it. Maker and checker are different roles. In my lab the Developer writes. The build gate is not an LLM. The reviewer reads a diff. QA scores against the brief. The stakeholder is the last human-shaped stop, and when the outer cap is hit the system stops asking for another lap. When the headline is still useful I will not defend every loop. Do not put a retry wrapper around an architecture rewrite, an auth change, or a production deploy and call it engineering. Those exits are judgment. A machine cannot reject "this is the right boundary" the way it can reject a red test. Do not loop a one-off. A loop is amortized infrastructure. If the task happens once, you spent more designing the cycle than doing the work. Do not loop when you cannot name the check in one sentence. "Looks good" is not a check. "The allowlisted test command exited 0" is a check. "Every acceptance criterion has a planned test id" is a check. The Medium piece is useful as a warning label on those cases. It is a bad funeral for the rest. The skill that survived 2026 is not "design a loop that prompts your agents." That sentence got five million views and then a backlash, which is what happens when a slogan outruns a stop condition. The skill is older than the slogan. Name the goal. Wire a check the model does not get to grade. Cap the retries. Escalate to a human when the cap is hit. Keep the audit trail. If you cannot name the exit, you do not have a loop. You have a tap. Takeaways Treat "the model said done" as a log line. Treat the build, the spec cover check, and the review verdict as the stop. Put the cap in policy, not in a prompt. When the cap is hit, escalate. Do not hope. Split maker and checker. One role writes. Another role, or a deterministic gate, is allowed to say no. Use a graph for ownership and order. Use a loop only where a machine can reject the output. Keep the human on the outer cycle. Inner loops can be cheap. The last approval should not be. The question I would put to anyone who shared the obituary: which part of your agent loop can fail without asking the model if it failed? That is the part worth keeping. What is your answer? Sources AI Engineering Simplified — "Loop Engineering Is Dead: Here's the Data Behind the AI Backlash." medium.com/ai-engineering-simplified Bloomberg / Simon Willison — Uber burned its 2026 AI budget in about four months; later cap around $1,500 per engineer per coding tool per month. Cited across 2026 loop-engineering writeups. Oracle — Agent-loop pattern: roughly 4× tokens versus a standard chat, up to 15× in multi-agent systems. José Adrián Alemán Rojas — "What comes after microservices is an agent with a budget." my-tech-profile.dev learning-with-me / software-dev-team-cursor — Four nested loops, YAML team policy, allowlisted build gate, ESCALATED on cap. github.com/josalero/learning-with-me