We Named Our Company After This: Loop Engineering Is Eating Software Development
The man who built Claude Code says he doesn't prompt it anymore — he writes loops that prompt it. That single line named the paradigm shift the whole agentic era has been building toward: from one-shot prompting to persistent, feedback-driven loops. Here's why the prompt was always a placeholder, why the loop is becoming the unit of software work, and why a company called Inference Loops bet its name on exactly this.
In a mid-2026 interview, the engineer who created Claude Code at Anthropic, Boris Cherny, described how his own job had changed. The wording is worth quoting in full, because it is doing more work than it looks:
“Now it’s actually leveled up, I think, again, to the next wave of abstraction where I don’t prompt Claude anymore. I have loops that are running. They’re the ones that are prompting Claude and figuring out what to do. My job is to write loops.”
The clip spread fast. Within days it had a name — loop engineering — popularized by Peter Steinberger’s blunt one-liner that the work has moved from prompting agents to designing the loops that prompt them, which itself collected millions of views. When the person who built one of the most-used coding agents on earth tells you he has stopped prompting it, that is not a productivity tip. That is the job description of an entire industry changing under its own feet.
We have a particular stake in this. Our company is called Inference Loops. We picked that name before the term “loop engineering” existed, on a bet about where the value in agentic software was heading. This is the post where we get to say: the bet landed.
The death of the prompt era
For about two years, the dominant skill in AI was prompting — the craft of phrasing a single request well enough to get a good single answer. Prompt engineering got guides, job postings, and a faint priesthood. And it was real work, for a while. But notice what it assumed: a human in the loop, reading each output and deciding what to type next. The prompt was the interface, and you were the control system. Every iteration ran through your keyboard and your attention.
Cherny’s sentence marks the end of that arrangement. The next wave of abstraction isn’t a better prompt — it’s removing the human from the per-turn decision and replacing them with a program. The loop reads the output, checks it against a goal, decides what to do next, and prompts the model again, all without a person in the conversation. The prompt didn’t disappear; it got generated by the loop instead of typed by you.
That reframing is the whole shift in one move. The prompt was never the unit of work. It was a placeholder for the loop we hadn’t built yet. As long as models were weak and tool use was fragile, a human had to stand in for the missing control logic — re-reading, re-steering, catching mistakes. As models got good enough to be trusted inside a feedback cycle with a verifiable goal, that human-shaped placeholder became the bottleneck. Loop engineering is what you do once you take the placeholder out.
What a loop actually is — and why writing one is the hard part
A loop, mechanically, is almost embarrassingly simple: a trigger kicks it off, the agent acts, something checks whether the goal is met, and the cycle repeats or stops. We’ve taken that structure apart in detail before, in the agent loop pattern — the plan, act, observe, verify cycle that turns a single model call into a system that gets work done.
The trap is thinking the difficulty is in the while statement. It isn’t. The while statement is trivial. The hard parts are the two things the human used to supply by instinct:
- A verifiable goal. The loop has to know, mechanically, whether it has succeeded — a test passing, CI going green, a spec matching the output. This is the same requirement that makes reinforcement learning work, and the same one that breaks it when it’s missing: a loop with no checkable reward either declares false victory or grinds forever. Most of the engineering in a good loop is in defining “done” precisely enough that a machine can check it.
- A stopping condition. Knowing when to quit — when the work is genuinely finished, when the agent is stuck and should escalate, when it’s burning tokens going in circles — is judgment encoded as code. Get it wrong in one direction and the loop stops half-done; get it wrong in the other and it never stops at all.
Those two are where the craft lives, and they are exactly the parts that don’t come from a better model. They come from understanding the problem well enough to say what correct means and when to stop. That’s why we keep insisting the durable value sits in the structure around the model, not the model itself — the argument we made about the harness being the product. The model is increasingly a commodity you rent. The loop is the thing you build, and it’s yours.
Why we named the company Inference Loops
When we chose the name, the reasoning was contrarian. The whole market was transfixed by models — which lab had the biggest, which benchmark moved, which API was cheapest per token. Our wager was that the model would commoditize and the loop around it would be where work actually got done and where differentiation actually lived. Inference without a loop is a party trick: a clever answer to one question. Inference inside a loop is a system that ships features overnight, reviews every pull request, keeps a migration moving while you sleep.
Cherny’s quote is that wager stated by the person with the most authority to state it. “My job is to write loops” is, almost word for word, the thesis the name encodes. We didn’t predict he’d say it — but we built around the same observation: the loop is the unit of value in agentic software. Everything above the loop (orchestrating many of them) and below it (the harness, the model) matters because of what it does for the loop. Name a company after the layer where the value concentrates, and you’re forced to keep your attention there even when the market is shouting about something shinier.
What changes when the loop is the unit of work
This isn’t just vocabulary. Treating the loop as the primitive changes what you build and how you measure it.
You design feedback, not phrasing. The question stops being “how do I word this request?” and becomes “what signal tells this loop it’s on track, and what tools let it act on that signal?” That’s a systems-design question, and a far more durable skill than wording.
You invest in verification, not just generation. In the prompt era, output quality was capped by the model and your patience. In the loop era, it’s capped by your verification. A loop can only be as good as its ability to check itself — which means the highest-leverage engineering moves from making the agent generate to making the loop judge. The quality of the verification phase is the ceiling on the quality of the whole system.
You think in fleets, not sessions. Once a single loop runs reliably, the natural next move is many of them — in parallel, on schedules, in pipelines. One loop fixing flaky tests nightly, another comparing specs to implementations, a third triaging issues. The human role rises again, from writing one loop to orchestrating many. But it all rests on the loop being a trustworthy unit first.
The through-line: the developer’s job is migrating from producing code to producing the systems that produce code. That’s not a smaller job. It’s a higher-leverage one, and it rewards a different muscle — judgment about goals, verification, and stopping conditions rather than speed at typing.
Why this favors Southeast Asia
Here is the part that matters most to us, and it’s the most encouraging implication of the whole shift. Loop engineering is a skill, not a capital expenditure.
The expensive, capital-intensive layer of this stack — pretraining frontier models — is exactly the layer that’s commoditizing into a rented API. The layer where the value is moving — the loop — runs on judgment: the ability to define a verifiable goal, design a feedback cycle, and know when the work is done. That judgment doesn’t require a GPU cluster or a thousand-person org. It requires understanding a problem deeply enough to encode “correct” into code. A loop engineer in Phnom Penh or Jakarta, renting the same model and running the same harness as one in San Francisco, competes on the layer where talent decides the outcome — not the layer where capital does.
We’ve made the practitioner’s version of this case in full — the three-layer model and why it’s the single best skill bet a regional developer can make — in what loop engineering means for Southeast Asian developers. The short version is that this is the most level playing field software has offered the region in a generation. The squeeze on junior implementation work is real, and loop engineering is the answer to it rather than a victim of it: it multiplies one developer’s output enormously, it’s portable, and it’s learnable without a frontier budget.
So when the creator of Claude Code says his job is now to write loops, we don’t hear a curiosity from a Silicon Valley interview. We hear the name of our company being read back to us as an industry-wide job title — and we hear an opening for every engineer in this region who’d rather compete on judgment than on compute.
The prompt era is ending. The loop era is here, and it has a name. We’ve been building for it the whole time.
If your team is learning to engineer loops — or wants engineers who already can — let’s talk.