Loop Engineering: The Concept Quietly Redefining How Products Get Built
If you've spent any time in AI circles over the past month, you've probably run into the phrase "Loop Engineering." It started as an offhand remark from Boris Cherny, who leads Claude Code at Anthropic, and it's since turned into something that looks less like a trend and more like the next real shift in how software gets built.
Here's the quote that kicked it off:
"I don't prompt Claude anymore. I have loops running that prompt Claude. My job is to write loops."
Read that twice. This isn't about AI getting smarter. It's about what we're actually asking the AI to do.
The ladder we climbed
To understand Loop Engineering, it helps to see where it sits in the evolution of working with these systems.
Prompt Engineering, roughly 2022 to 2024, was about finding the magic words. Craft the perfect phrasing, use the right tone, throw in a few examples, hope for a good answer. It was almost literary. People shared prompt templates like recipes, and the whole frontier was making one prompt better.
Context Engineering came next, once it became clear that what the model sees matters as much as what you ask it. Teams got obsessive about what went into the context window: documentation, examples, constraints, structured data. You weren't just asking better questions anymore. You were building a better environment for the model to think in.
Harness Engineering pushed further still, creating a single controlled run where the model operates inside guardrails. Think of it as a sandbox with rules. The model can write code, but only in this directory. It can call APIs, but only these three. It gets feedback from tests, but only two tries before it gives up. A harness made one attempt more reliable.
Loop Engineering is the leap after that. It asks: why do we assume one attempt is enough?
Instead of hoping a single, even perfectly crafted, prompt produces the right answer, you design a system that keeps trying. Iterating, checking its own work, deciding when to stop, with as little human hand-holding as possible.
What a loop actually is
Ground this in something concrete. Every implementation, across every team doing this seriously, seems to converge on the same four parts.
The Trigger starts the cycle. It might be a GitHub webhook when a new PR lands, a scheduled cron job that runs a migration overnight, a failing test in CI/CD, or a Slack message that mentions a bot. The trigger's whole job is to say: now.
The Generator is the agent doing the actual work, usually an LLM (Claude, in most of Anthropic's own writing about this) given a goal and some context, producing output. Write a migration script. Fix this test. Refactor that function. It runs cheap and fast, and that's the whole point.
The Verifier is where most teams get it wrong. It's not the model checking its own homework. It's a set of criteria you define ahead of time to judge whether the generator's output is actually good: do the tests pass, does the output match the TypeScript types, does the screenshot diff match the Figma reference, does it follow the style guide, is it within token limits. The verifier decides whether to ship, retry, iterate, or hand it to a human.
Here's the part that caught people off guard: because the generator is cheap and can run over and over, the verifier ends up being the actual bottleneck. You can spin up a hundred agent runs for less than one senior engineer's salary. You can't spin up a hundred verifiers. They still have to be automated checks or human judgment, and neither of those scales the way compute does.
The Stop Condition decides when the loop is done. In theory, when the verifier says "good enough." But that has to be defined in advance. Tests pass? Tests pass and some metric clears a threshold? The human reviewer hasn't pushed back in two hours? Without a real stop condition, you get agents that spin forever, or that quit too early.
Ng's three nested loops
The most useful way to think about this as a product person comes from Andrew Ng's framing in his June 30 essay. He describes three loops running at different speeds.
The Agentic Coding Loop, seconds to minutes, is the innermost cycle: an agent gets a spec, writes code, tests it, and iterates until the verifier signs off. This is the new "build" phase, and it's fast.
The Developer Feedback Loop, minutes to hours, sits one ring out. A human engineer looks at what the agent produced, maybe adjusts the spec based on what they just learned, and sends it back in. This is where judgment lives. The machine can verify correctness, but someone still has to verify intent.
The External Feedback Loop, hours to weeks, is the slowest ring. Real users interact with the code. A/B tests run. Metrics come in. Bugs show up in the wild. This feeds back down into the original spec, which feeds the developer loop, which feeds the agent loop.
The key thing Ng points at: faster loops don't replace slower ones. They stack on top of them. A fast agentic loop is only as good as the spec feeding it, and that spec is only as good as the external signal informing it.
That's a PM's job, basically drawn as a diagram.
How this changes the product lifecycle
Specs stop being documentation and start being load-bearing. Right now, a PRD gets read by humans who fill in the gaps with judgment. A vague line gets caught in standup, someone asks a clarifying question, the spec evolves in conversation. In a loop-driven world, the spec is also the verifier's rulebook. It's the machine-checkable line between what you meant and what got built.
A vague requirement in the old workflow costs you a Slack thread and maybe a day of rework. A vague requirement in a loop's spec costs you a night of wasted compute, a stack of confidently wrong pull requests, and a morning spent figuring out what the agent decided to do at 3 a.m. when it guessed wrong.
That doesn't mean specs get longer. It means they get more precise. "Improve the checkout flow" now has to look more like:
- Checkout completes in under 3 seconds on a 4G connection
- Tax calculation matches the accounting system within $0.01
- The A/B test needs to show at least a 2% conversion lift before it ships
- The agent doesn't touch the payment processing layer
Ambiguity used to be a communication problem. Now it's a verification problem.
QA moves upstream instead of downstream. Traditionally, code gets written first and QA tests it after. Loops invert that. Acceptance criteria and quality standards have to exist before the loop even runs, because the verifier needs to know what "good" looks like before it can judge anything. QA people don't disappear. Their job shifts from catching bugs after the fact to defining "no bugs" precisely enough that a verifier can actually check for it.
Build phases compress, and review shifts shape. Cherny's own story makes the point: one sentence typed, forty agents spin up, three PRs are waiting by the time he's back with coffee. That's not a flourish, it's becoming normal. A feature that used to take an engineer two days can now be generated, tested, and queued for review in minutes.
What doesn't compress is deciding whether it's right. Code review doesn't go away, it changes shape. Instead of reading one PR line by line, you're auditing batches of AI-generated code, figuring out why the loop made the choices it made, and checking whether its idea of "done" actually matches the product vision. In some ways this is harder. You're not just reviewing code anymore, you're reviewing the spec that generated the code. The question shifts from "did the agent do what we asked" to "did we ask for the right thing."
Release cycles get faster but noisier. Faster build cycles only help if the external feedback loop is actually working. Without real user signal coming back down, you're just iterating faster toward a locally optimal wrong answer. The slow outer loop, real users, real usage, real problems, is what keeps the fast inner loops honest.
How each role changes
Engineers move from writing code to writing and maintaining loops. The job starts to look like: define the spec precisely enough for an agent to run with it, write the verifier that judges the output, figure out why the loop failed when it does. Review time doesn't vanish, it turns into batch review of AI-generated PRs, plus the occasional debugging session into why a loop looped 87 times without converging.
Product managers stop being the person who explains the spec and become the person whose spec a machine can actually execute against. Value shifts toward the decisions a verifier can't make: tradeoffs, taste, judgment calls, strategic context. The spec itself becomes a machine-executable artifact, not just something people read.
Designers need their mockups to be legible to verifiers too. A screenshot diff against a Figma reference becomes a real verification mechanism, not a nice-to-have. Design specs stop being "here's what it should look like" and start being "here's how we'll know if you built it right."
QA engineers probably get the biggest upgrade. Their test suites and acceptance criteria stop being a gate that work passes through on the way out and become the actual mechanism that governs the agent while it's still working.
Engineering managers pick up a new budgeting headache: agent-hours and token spend, not just headcount and calendar time. Uber's cautionary tale is worth knowing here. They capped individual engineers at $1,500 a month in AI tool spend after blowing through their entire annual budget in four months.
Product leadership needs new judgment about what's safe to automate and what needs a human gate. Adding a database column? Probably fine, with the right verifier. Charging a customer? No. That's an irreversible action, and it needs a person signing off.
The risks nobody's saying loudly enough
A few honest caveats. This is proven mostly in code, migrations, test suites, PR review, refactoring. There's no mature playbook yet for marketing copy, design iteration, or other creative work, and it's not obvious the framework even transfers.
Cost blowouts are real. A poorly constrained loop burns compute fast, and teams are already reporting engineers accidentally torching a month's budget in days without iteration caps in place.
The skeptic's case is fair, too. A lot of what people call a "loop" is a cron job, an LLM call, and a try/catch block. The hard part was never the loop mechanism, it's designing a verifier that actually knows what "done" means, and the guardrails around it.
And emergent behavior is hard to predict. A loop chasing a specified goal will find edge cases you didn't think of. Sometimes that's a clever solution. Sometimes it's an agent taking a technically valid but strategically wrong path, and you don't find out until later.
What this means if you're a PM
Your spec is now closer to your product's constitution than its documentation. Ambiguity isn't just a communication problem, it's a verification problem, and the muscle of writing clear, unambiguous specs is probably the highest-leverage skill in this environment right now.
QA thinking has to move upstream. Define what "good" means before you build, not after.
Feedback loops matter more than raw velocity. A fast inner loop is only useful if the slow outer loop is feeding it real signal. Speed without feedback is just iterating toward the wrong answer, faster.
Judgment is the actual competitive advantage. Machines can verify correctness. Humans decide intent, tradeoffs, strategy. The PM's job isn't just "make the spec clear" anymore, it's "make the spec clear and make sure it captures what the user actually needs."
Looking ahead
We're early. Cherny's line about writing loops instead of prompts is going to ripple through how software gets built for a while yet. The product lifecycle isn't going away, it's just growing new layers.
Teams that get good at writing tight specs, defining real verifiers, and building fast feedback loops will ship faster and with more confidence. Teams that don't will spend their time fighting runaway agents, burning compute, and shipping the wrong thing very quickly.
The future of product development isn't better prompts. It's better systems of judgment.
That's a PM skill.