Coding-Agent Loops: Triggers, Goals and the Cost of Repetition

Matthew Berman discusses coding-agent loops in a June 2026 video, citing comments by Anthropic’s Boris Cherny and OpenAI’s Peter Steinberger. Both describe designing systems that direct agents rather than manually issuing each prompt. Berman calls this an important direction for software engineering, a forecast rather than an established universal practice.

The video is sponsored by here.now. Berman defines a loop as work initiated by a trigger and directed toward a goal. Instead of a human repeatedly issuing the next instruction, the designer specifies an intended end state and lets the agent work toward it.

He says the goal should be verifiable: passing tests are one possible check, while a model can judge a less concrete outcome. Automated tests only cover what they test, and an AI judge can be wrong, so either kind of check depends on how well it represents the actual goal.

Berman compares this feedback to reinforcement learning, in which a reward signals progress toward an objective. The analogy is about feedback and evaluation: repeatedly prompting an agent and checking results does not by itself train model weights or constitute reinforcement learning.

In Cursor Automations, Berman shows an example triggered when a pull request opens in his Astro Hub project. Its instruction asks the agent to review the PR, fix potential issues, commit to the same PR and ensure tests and CI pass. This describes the requested workflow, not evidence that the configuration has successfully completed every such task.

A concrete test result can make success easier to check, but Berman says a broad request such as “build this feature” is harder to specify. Much product development involves exploring what is needed and revising it, so writing a complete end state in advance can be difficult.

He groups triggers into events such as a PR opening, a recurring schedule such as every 30 minutes, and a person initiating work. A schedule or event can start an agent run; whether it retries, checks an outcome or stops depends on the actual workflow and its implementation.

Berman says loops can be made more elaborate with skills and additional logic. He distinguishes the minimal idea of a trigger and goal from the harder engineering needed to make a system choose useful next actions and judge completion reliably.

He shows Claude Code’s /loop command and suggests an example that periodically compares a project against spec.md and continues building. A scheduled prompt can request that work, but running it repeatedly is not a guarantee that each execution starts a separate agent, that the specification is achieved or that the schedule cancels itself on success.

Berman also describes omitting a fixed interval and asking the system to continue toward the goal. The behavior of a particular /loop implementation depends on its version and session; current Claude Code documentation describes session-scoped scheduling and distinguishes it from turn-by-turn goal continuation.

Berman says a simple loop is easy to write, but a continuously operating software factory is far harder. When the end state cannot be checked deterministically, the agent may repeatedly spend tokens without actually resolving the underlying problem.

He identifies cost as another practical constraint: more autonomous work generally means more model calls and potentially higher bills. He predicts that costs will fall as the technology becomes more efficient, but that is a forecast rather than a guarantee for any particular workload.

Berman suggests that only a very small fraction of engineers can experiment at the most expensive end of this approach and cites purportedly generous internal token budgets and a reported high usage figure. The video provides no representative adoption study or independently verified accounting of company-wide allowances, so those figures are his claims.

He predicts that engineering will increasingly involve designing software factories that direct agents, instead of continually writing prompts or code. That is his vision of a possible future; it does not establish the pace or extent of adoption.

Berman distinguishes a loop from an automation by emphasizing a decision about whether the goal has been reached. This is his useful framing for the examples, rather than a universal technical definition: automations can also include conditions and feedback, and a repeating schedule can run without a meaningful success check.

Finally, he asks whether humans will always set goals. He imagines AI choosing features and products and designing its own development system, connecting the idea to recursive self-improvement. Anthropic’s essay discusses AI accelerating research while explicitly saying fully autonomous recursive self-improvement had not yet been achieved and is not inevitable.