{"slug": "designing-an-agent-loop-for-coding", "title": "Designing an agent loop for coding", "summary": "A developer explores the design of agent loops for coding, arguing that the critical challenge is specifying precise verification steps to prevent agents from circling indefinitely or declaring false success. The post distinguishes between internal agent cycles and an outer loop of request, goal, attempt, verify, and decide, citing recent research on loop specifications and structured review. The developer advocates for a ladder of verification—from self-reports to real product tests—to ensure agents reliably complete tasks.", "body_md": "A prompt tells a coding agent what to do once. Nearly everything that matters happens after the first result comes back wrong.\n\nSuppose you ask a coding agent to add CSV export to a reporting page. It reads the repository, edits a few files, runs a test, and reports success. The test fails, so you paste the error back in. The next version breaks the page, so you tell it to open the browser and look. The version after that works, but it also rewrote half the reporting module on the way.\n\nBy the third round, you are the loop. You carry the evidence between attempts and you decide when the work is actually done.\n\nThe question that interests me is how much of that can be written down precisely enough for the system to run it alone, and where it cannot be, so that the work comes back to a person instead of circling forever.\n\nThe word *loop* is doing a lot of work in that last paragraph, so it helps to pull the senses apart. There is the ordinary loop inside a program. There is the internal cycle most agents already run on their own: look at the environment, pick an action, call a tool, look at the result, keep going.\n\nThe one I care about here is a third loop, and it sits outside the model:\n\n**Request → define goal → attempt → verify → decide**\n\nIf verification fails, the loop retries from the attempt while carrying the evidence forward.\n\nA recent preprint calls this a *loop specification*: a trigger, a goal, some execution, a verification step, a rule for when to stop, and memory carried between rounds.[[1]](https://arxiv.org/abs/2607.00038) The name is new but none of the parts are. Continuous integration has done a version of this for years. It runs when something happens, checks the result, records what it saw, and ends in a named state. The one thing an agent adds is a model that can rewrite its own plan between runs.\n\n“Implement CSV export” describes an activity. It does not describe when the activity is complete.\n\nThe split is the whole point. The goal is what should become true. The check is the evidence the loop will actually use to decide whether it did.\n\nCollapse the two and the agent ends up as its own author, tester, and judge. It will happily declare victory because the code looks reasonable, because a command exited zero, or because it has simply run out of ideas. None of those mean the feature works.\n\nIt helps to treat verification as a ladder rather than a single gate. A self-report from the agent is the cheap bottom rung, and on its own it is worth almost nothing. A clean static check and a passing build tell you more. Targeted tests tell you more again, because they exercise the behavior you actually asked for. Running the real product surfaces the integration failures that no unit test was ever going to catch, and a separate review picks up the things the implementation agent has quietly trained itself to skip.\n\nRecent coding-agent research is pushing the same way. SWE-Cycle pulls apart environment setup, implementation, and test generation, then measures a sharp drop in performance once agents have to run the whole cycle themselves.[[2]](https://arxiv.org/abs/2605.13139) SWE-Review bolts a separate reviewer onto a generate-review-revise loop and finds that structured review feedback makes later revisions better than one-shot generation does.[[3]](https://arxiv.org/abs/2607.06065)\n\nThe verifier does not have to be another model. When a deterministic test can settle it, use the test. A model earns its place only when the check needs judgment: did the diff stay inside the feature, does the UI actually match what was asked, is this workaround a tradeoff you would accept.\n\nAn attempt changes the environment, observation writes down what happened, and verification holds that evidence up against the goal. A failed check goes one of two ways: it either hands useful evidence to the next attempt, or it exits into a named terminal state.\n\nWhen the result is not ready, the loop returns to a new attempt with the failure evidence. The agent only occupies the Attempt step. The loop around it decides what counts as done, which evidence to trust, and when to stop.\n\nThe agent is one box in this diagram. How the whole thing behaves depends just as much on the verifier, on the state you carry between attempts, on the retry policy, and on the rules that decide when the loop is allowed to end.\n\nFeeding the agent the same prompt again is technically a loop. It is just not a loop that gets anywhere.\n\nEvery failed attempt should hand something concrete to the next one: a failing assertion, a screenshot, a compiler error, a reviewer comment, or even a plain sentence about why the goal was missed. The next round should start from that, not from a fresh copy of the original request.\n\nIsolating attempts helps more than I expected it to. A fresh branch or worktree gives each attempt a clean starting point, keeps them comparable, and stops an abandoned approach from leaking into the one that follows. Run several attempts at once and each one needs its own workspace anyway. Then the loop can keep whichever result actually verified instead of trying to stitch half-compatible diffs together.\n\nMemory is worth being picky about. The loop needs the goal, the previous verdicts, the decisions that mattered, and the current state of the repository. It almost never needs the full transcript of every tool call. Keeping everything just makes the next round longer, not smarter.\n\nEvery loop needs explicit terminal states. At minimum:\n\nA cap on attempts is still worth having, but treat it as a safety bound and not as a definition of done. Work on iterative language-model systems suggests fixed iteration counts burn effort long after the output has stopped getting better. In one small non-coding experiment, a semantic stopping rule cut operational tokens by 38 percent at roughly the same measured quality.[[4]](https://arxiv.org/abs/2606.27009) That number does not carry straight over to software, but the lesson behind it does: watch whether the loop is making progress, not just how many times it has gone around.\n\nThe opposite failure is the loop that never hits a real bound at all. A July 2026 static-analysis study looked at 6,549 agent repositories and confirmed 68 likely infinite-agent-loop defects across 47 projects.[[5]](https://arxiv.org/abs/2607.01641) In each case the loop kept reaching model calls, tools, retries, or handoffs without any stopping condition that covered the whole feedback path.\n\nFor coding, a workable no-progress rule might trip when two attempts fail the same check for the same reason, when the diff stops changing in any meaningful way, or when the next step would need authority the agent was never given.\n\nHanding more of the work to the machine does not shrink how much its internal state matters. It turns that state into about the only thing you can still supervise.\n\nWhile a loop runs, a developer should be able to answer plain questions about it. What is the goal right now? Which attempt is live? What changed? Which check is running? Why did the last attempt fail, and what happens if this one passes?\n\nThat is the idea behind the new Cate Agent. For a code task, a read-only orchestrator sets the goal and the verification check. It can spin up one or more attempts in fresh Git worktrees. Per-attempt drivers launch coding-agent CLIs in real canvas terminals, and when an attempt finishes a separate verifier checks it. From there the orchestrator either takes a passing result or starts another round from the failure evidence. The finished work sits in a review state until you merge it, open it as a pull request, or throw it away.[[6]](https://github.com/0-AI-UG/cate/pull/423)\n\nThe reason the loop stays legible is that each part has a place you can point at. Attempts live in their own worktrees and terminals. Verification gets its own terminal. The result you kept stays visibly separate from the attempts you rejected. The canvas lays the process out as a workspace instead of flattening it into a single scrolling chat.\n\nSo designing a loop turns out to be mostly structural work. You give a repeated process a shape: something concrete to satisfy, evidence to check it against, a little state to carry forward, limits that genuinely halt it, and an ending a person can still read. Getting the agent to run longer is almost beside the point.\n\nThe model does the individual steps. Whether those steps add up to software you can actually ship is a property of the loop you built around it, and that part is still your job.\n\nS. Macedo, “Stop Hand-Holding Your Coding Agent: Engineering the Loops that Replace Step-by-Step Prompting” (2026). Used for the distinction between internal agent cycles and external loop specifications, and for the trigger, goal, verification, stopping, and memory structure. This is a recent preprint based partly on a hand-coded corpus of 50 public loops. [arxiv.org/abs/2607.00038](https://arxiv.org/abs/2607.00038)\n\nH. Guan et al., “SWE-Cycle: Benchmarking Code Agents across the Complete Issue Resolution Cycle” (2026). Used for the separation of environment reconstruction, implementation, verification-test generation, and complete-cycle execution. [arxiv.org/abs/2605.13139](https://arxiv.org/abs/2605.13139)\n\nR. Wang et al., “SWE-Review: Closing the Loop on Issue Resolution with Agentic Code Review” (2026). Used for the generate-review-revise architecture and reported value of structured reviewer feedback. This is a very recent preprint. [arxiv.org/abs/2607.06065](https://arxiv.org/abs/2607.06065)\n\nS. Shrivastava, “Semantic Early-Stopping for Iterative LLM Agent Loops” (2026). Used for the fixed-iteration critique and 38% operational-token result. The experiment covers 60 multi-hop QA questions, not coding tasks, so it is presented only as a stopping-policy example. [arxiv.org/abs/2606.27009](https://arxiv.org/abs/2606.27009)\n\nX. Hou et al., “When Agents Do Not Stop: Uncovering Infinite Agentic Loops in LLM Agents” (2026). Used for the definition and repository scan of infinite agentic loops. [arxiv.org/abs/2607.01641](https://arxiv.org/abs/2607.01641)\n\n0-AI-UG, “Cate Agent: job-card agent that drives coding CLIs in canvas worktrees” and the Cate Agent tool implementation (2026). Used for Cate’s goal, iteration, worktree, driver, verifier, and result-selection workflow. [github.com/0-AI-UG/cate/pull/423](https://github.com/0-AI-UG/cate/pull/423)\n\nCate is an open-source spatial workspace for coding agents, terminals, editors, browsers, and Git worktrees. [Explore Cate on GitHub](https://github.com/0-AI-UG/cate).", "url": "https://wpnews.pro/news/designing-an-agent-loop-for-coding", "canonical_source": "https://dev.to/paulhorn/designing-an-agent-loop-for-coding-1fmg", "published_at": "2026-07-13 22:29:44+00:00", "updated_at": "2026-07-13 23:17:42.104124+00:00", "lang": "en", "topics": ["ai-agents", "developer-tools", "ai-research", "large-language-models"], "entities": [], "alternates": {"html": "https://wpnews.pro/news/designing-an-agent-loop-for-coding", "markdown": "https://wpnews.pro/news/designing-an-agent-loop-for-coding.md", "text": "https://wpnews.pro/news/designing-an-agent-loop-for-coding.txt", "jsonld": "https://wpnews.pro/news/designing-an-agent-loop-for-coding.jsonld"}}