Digitaliko's issue-to-PR loop: the dispatcher starts no new task while agent PRs wait for a person
Filip Papranec describes a bash-driven loop where code picks the work and decides when it's done, a red machine check can never be overruled to pass, a repeated reviewer finding stops the loop, and new work pauses whenever agent PRs are waiting on human review.
Source: Agent harness engineering in practice: from issue to PR
Filip Papranec (Digitaliko) writes up the loop his small Slovak shop runs every day on its own repositories. AI writes most of the code and a senior reviews every change. The design rule sits at the top of the dispatcher script: "code decides WHAT to take and WHEN it is done, models only do the work." A bash dispatcher picks issues by priority, and each run is one issue, one worktree, one branch, one Claude Code session, one PR.
The stages are READY, BUILD, VERIFY, CI and HANDOFF. A read-only model call first checks the issue's premise against the code, with file and line, and asks what would prove it done. The build session writes a test that fails on the unchanged code before implementing. Verification is a plain bash gate with exit codes, then a fresh reviewer whose only job is to refute the work. A red machine check can't be talked into green: the script downgrades a model's "pass" to "fix" whenever the check failed. If the reviewer reports the same finding twice in a row, the task goes to a person with that finding attached, because another round wouldn't fix it. There are only two exits: ready for review with evidence, or blocked with a question on the issue.
A person shows up three times: assigning the issue (that's the approval), answering a blocked question, and reviewing and merging. Only a person merges, enforced by hooks the agent can't edit. The review-relevant rule is the throttle: "Review is the bottleneck, not the agent. So the dispatcher starts no new task while agent PRs wait for people."
The breakage list is the useful part. A change to the review limit silently fed the loop empty input, so no task started and nothing alerted until an audit caught it. Sessions that died in their first minute from missing access landed on a person as "blocked" instead of retrying. And CI that never finished counted as green until they changed it: "Not finished is not passed." Digitaliko sells this kind of loop as a service, and the post is its own account.
Why it matters for code review
Most overnight setups cap how many agents run. Papranec caps on the human side, so the loop only keeps momentum as fast as review clears it, and an unreviewed queue never piles up. It's the same idea as Csorba's per-reviewer WIP cap, written as one line in a dispatcher. And its silent stall is a reminder that a throttled loop can fail by quietly doing nothing, which no green check will tell you.