```html

The AI world is getting 'loopy'

At Meta's @Scale conference last Friday, someone in the audience asked Boris Cherny — the creator of Claude Code — whether AI loops were the next hype cycle or something real. His answer was immediate: real, and as significant as the shift from hand-written code to agentic AI. That exchange put a name to something developers across the world have been quietly experimenting with, and it reframes how we should think about what AI systems are actually capable of doing. The AI world is getting 'loopy', and for developers building in Asia, that shift carries specific implications worth unpacking.

What Happened

Boris Cherny, Head of Claude Code at Anthropic, appeared at Meta's @Scale conference and made a case that "loops" represent the next major architectural shift in how AI systems work. The progression he described is worth quoting directly: "Two years ago, we wrote source code by hand. We started to transition so agents write the code. And now we're transitioning to the point where agents are prompting agents that then write the code." He argued that the leap from agentic AI to looping AI is as significant as the leap from manual coding to agents in the first place.

What does a loop actually look like in practice? Cherny described his own setup in the talk: one agent continuously scans for ways to improve code architecture, another hunts for duplicated abstractions that can be unified. Both submit pull requests like any human contributor would. Because the codebase is always changing, neither agent ever stops running. There's no finish line — just continuous, background improvement.

This isn't entirely novel territory. Recursive loops have been a staple of computer science since the beginning — functions that call themselves until a condition is met. What's different here is that the stopping condition isn't deterministic. A sub-agent decides when the loop has done enough, not a hard-coded rule. That non-determinism is what makes this feel genuinely new.

One popular implementation already circulating in developer communities is the Ralph Loop — named, brilliantly, after Ralph Wiggum — which works by summarizing everything the model has accomplished so far and asking whether the goal has been met. It's a simple but effective way to stop AI models from drifting when they run for extended periods, essentially bouncing the model between action and self-evaluation until the task is complete.

There's also a connection to the broader push for more test-time compute — the idea that models can produce better outputs by spending more time reasoning rather than simply scaling parameters. Loops fit neatly into that framework: instead of one big inference pass, you get continuous, iterative refinement over time.

Why It Matters for Asia

Asia's developer ecosystem has always moved fast on adoption, but the structural conditions here make the looping paradigm particularly relevant. Engineering talent in Southeast Asia, India, and East Asia is growing rapidly, but senior engineering hours remain expensive and scarce relative to the scale of software that needs to be built. A background agent that continuously refactors your codebase, catches duplicated abstractions, and submits PRs without being asked — that's not a productivity multiplier, it's a structural change in what a small team can maintain.

Consider a five-person startup in Jakarta or Ho Chi Minh City shipping a fintech product. They're dealing with a codebase that grows faster than their team can review it. Technical debt accumulates not because anyone is careless, but because there simply aren't enough hours. A persistent refactoring agent running in the background — the kind Cherny described — addresses exactly that constraint. It doesn't replace the engineers; it handles the category of work that engineers always defer.

There's also a language dimension that matters specifically for Asia. Much of the tooling and documentation in the AI agent ecosystem is English-first. Loops, by their nature, are more abstract — they operate at the code level, where language barriers matter less. An agent that improves your TypeScript or Python architecture doesn't need to understand Bahasa Indonesia or Mandarin to do its job. That makes looping agents more immediately accessible to Asian development teams than many other AI capabilities that depend on nuanced natural language understanding.

The Asia tech scene has also been quicker than most to experiment with multi-agent architectures, particularly in enterprise automation. Companies building on platforms like MonstarX are already thinking in terms of agents that coordinate with each other, not just single-model inference. The loop concept slots naturally into that mental model — it's less of a conceptual jump for teams already working with agentic workflows.

The risk, of course, is that loops running without sufficient oversight can compound errors as easily as they compound improvements. An agent that's wrong about what constitutes a good abstraction will keep being wrong, at scale, forever. That governance challenge is real, and it's one Asian teams will need to think about deliberately as they adopt these patterns.

What This Means for Developers

If you're building with AI today, loops change your mental model of what the system is doing. You're no longer sending a prompt and waiting for a response. You're configuring a persistent process — one that has goals, makes decisions, and produces outputs on an ongoing basis. That's closer to hiring a contractor than running a query.

Practically, here's what that means for how you build:

• Scope your agents tightly. Cherny's agents each have a narrow, well-defined mandate — one looks for architecture improvements, another for duplicated abstractions. They don't do everything. The tighter the scope, the less likely a loop is to drift into territory where it causes damage.
• Build evaluation into the loop. The Ralph Loop works because it forces the model to check its own progress. Any loop you run should have an evaluation step baked in — whether that's a sub-agent, a test suite, or a human review gate for PRs above a certain complexity threshold.
• Treat loop outputs like contributor PRs. Cherny's agents submit pull requests. That's the right abstraction. Don't auto-merge. Review loop outputs the same way you'd review a junior developer's work — with attention to whether the change is correct, not just whether it compiles.
• Start with read-only loops. Before you let an agent write and submit, run it in observation mode. Let it flag what it would change without actually changing anything. That gives you a sense of whether its judgment is trustworthy before you hand over write access.
• Monitor for drift over time. A loop that runs for days or weeks can accumulate small errors that compound. Set up logging that lets you audit what a loop has done, not just what it's currently doing.

The tooling for this is still maturing. Most developers today are stitching together loops manually — using orchestration frameworks, custom evaluation scripts, and a lot of prompt engineering. But the primitives are becoming clearer, and platforms that support persistent agent execution with proper state management will become significantly more valuable as this pattern spreads.

For teams using connectors to wire AI agents into their existing infrastructure — databases, CI/CD pipelines, issue trackers — the loop pattern is a natural extension of what they're already doing. The difference is that instead of triggering an agent on demand, you're letting it run continuously against a live system. The integration surface is the same; the execution model is different.

There's also a cost dimension developers need to think about. Loops consume tokens continuously. An agent running 24/7 against a large codebase can generate significant inference costs. Before you deploy a loop in production, model the token usage. Set hard limits. The economics of looping agents are not the same as the economics of on-demand inference.

Key Takeaways

The shift Cherny described at @Scale is real, and it's already happening. Loops — persistent, background, self-directing agent swarms — represent a meaningful architectural evolution beyond the agentic AI most developers are working with today. The jump from "agent completes a task" to "agent continuously improves a system" is not incremental. It changes what AI can own in a software organization.

For Asian developers and founders, the timing is good. The infrastructure for agentic AI is maturing, the cost curves are falling, and the patterns — like the Ralph Loop — are simple enough to implement today without waiting for purpose-built tooling. The governance challenges are real but solvable with the right design discipline: narrow scope, evaluation steps, PR-based output review, and careful cost monitoring.

The deeper implication is this: as loops become standard practice, the competitive advantage won't come from having AI write your code. It'll come from having AI that never stops improving it. That's a fundamentally different kind of leverage — and the teams who figure out how to manage it responsibly will build software that compounds in quality over time, not just in features.

The question isn't whether to run loops. It's whether you've designed your systems to handle what happens when the loop keeps running after you've stopped watching.

```