DEV Community: Paul Horn

Designing an agent loop for coding

Paul Horn — Mon, 13 Jul 2026 22:29:44 +0000

A prompt tells a coding agent what to do once. Nearly everything that matters happens after the first result comes back wrong.

Suppose 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.

By the third round, you are the loop. You carry the evidence between attempts and you decide when the work is actually done.

The 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.

The loop outside the agent

The 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.

The one I care about here is a third loop, and it sits outside the model:

Request → define goal → attempt → verify → decide

If verification fails, the loop retries from the attempt while carrying the evidence forward.

A 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] 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.

Start with the condition for stopping

“Implement CSV export” describes an activity. It does not describe when the activity is complete.

Goal: A user can export the currently filtered report as a correctly encoded CSV file.
Check: Run the export tests, verify the build, and inspect the diff for changes outside the reporting feature.

The 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.

Collapse 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.

It 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.

Recent 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] 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]

The 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.

The structure of a coding loop

An 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.

Goal + check: what done means, and the evidence that proves it
Attempt: the agent changes an isolated worktree
Observe: collect the diff, test output, and runtime state
Verify: hold the evidence against the check
Pass: verified work, yours to review, merge, or discard
Stuck: back to a person because the loop is blocked, out of budget, or repeating itself

When 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.

The 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.

A retry needs new information

Feeding the agent the same prompt again is technically a loop. It is just not a loop that gets anywhere.

Every 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.

Isolating 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.

Memory 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.

Stopping is part of correctness

Every loop needs explicit terminal states. At minimum:

success: the check passed;
blocked: progress requires a person or missing external information;
exhausted: the attempt or cost limit was reached;
cancelled: the user stopped the work;
error: the loop itself could not continue safely.

A 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] 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.

The 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] In each case the loop kept reaching model calls, tools, retries, or handoffs without any stopping condition that covered the whole feedback path.

For 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.

A loop should remain inspectable

Handing 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.

While 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?

That 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]

The 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.

So 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.

The 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.

References

S. 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
H. 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
R. 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
S. 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
X. 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
0-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

Cate is an open-source spatial workspace for coding agents, terminals, editors, browsers, and Git worktrees. Explore Cate on GitHub.

10 nerdy GitHub repos I keep learning from

Paul Horn — Sat, 30 May 2026 12:41:22 +0000

I spend a lot of time browsing GitHub, not only to find tools, but to understand how good software is structured.

This is not a “best repos of all time” list. More like a personal list of repos I keep coming back to because they teach something: architecture, performance, dev tooling, systems design, UI, or just taste.

1. git/git

Git is one of those tools everyone uses and almost nobody fully understands.

The repo is worth studying because it is old, practical, and deeply battle-tested. There is a lot to learn from how a tool can stay relevant for decades without becoming trendy.

2. torvalds/linux

The Linux kernel is probably the most obvious nerd repo, but it still belongs here.

Not because I understand every part of it. I do not. But reading around the repo gives you a feeling for scale, maintainership, hardware boundaries, naming, review culture, and the amount of discipline needed to keep something this large moving.

3. sqlite/sqlite

SQLite is one of my favorite examples of software that is quietly everywhere.

Small surface area, huge impact. It is a good reminder that boring, reliable, embeddable software can be more impressive than most flashy infrastructure projects.

4. redis/redis

Redis is interesting because it feels simple from the outside, but the internals are full of careful tradeoffs.

It is a good repo to study if you care about data structures, networking, memory, persistence, and how a small set of primitives can become infrastructure for a lot of other systems.

5. curl/curl

curl is a good example of a tool that does one thing extremely well and then survives basically every platform, edge case, and protocol mess humans have created.

The repo is also interesting from a maintenance perspective. Supporting everything is not glamorous work, but it is real engineering.

6. neovim/neovim

Neovim is interesting because it is both old-school and modern.

It keeps the terminal/editor culture alive, but also has Lua, LSP, plugins, UIs, and a very active ecosystem around it. I like it as an example of how a project can modernize without losing its core identity.

7. 0-AI-UG/cate

Cate is one of my own projects, so this one is obviously biased.

It is an open source infinite canvas IDE for coding workflows that do not fit well into one editor window anymore: terminals, agents, previews, files, logs, and notes all sitting on one zoomable workspace.

The reason I include it here is not because it is done. It is still early. But it represents the kind of dev tool problem I care about most right now: not just better autocomplete or another chat box, but a better workspace for how coding is changing.

8. tree-sitter/tree-sitter

Tree-sitter is one of the more interesting dev tool building blocks.

Fast incremental parsing sounds niche until you realize how many editor and code intelligence features depend on understanding code structure without running a full compiler pipeline.

It is one of those projects that sits underneath the things developers use every day.

9. wasm3/wasm3

wasm3 is a WebAssembly interpreter, and it is just a fun repo to look at if you like low-level runtime stuff.

WebAssembly often gets talked about in big platform terms, but repos like this make it feel much more concrete: instructions, execution, portability, constraints.

10. tinygrad/tinygrad

tinygrad is interesting because it strips ML infrastructure down to something you can actually read and reason about.

It is not “tiny” because the problem is simple. It is tiny because it tries to avoid hiding everything behind huge abstractions. That makes it a good repo to learn from.

Closing thought

The repos I like most usually have one thing in common:

They are not just codebases. They are tools that changed how other people build.

Some are huge, some are small, some are old, some are still moving fast. But all of them are worth studying if you care about software beyond just shipping the next feature.

Also curious what repos other people keep coming back to. Especially the weird ones that are not on every standard “awesome GitHub repos” list.