Coding agents should work inside incremental control loops rather than producing giant pull requests that teams cannot review.
2
A useful loop senses a measurable code problem, selects a small change, applies it with an agent, and checks the result through deterministic feedback.
3
Tracking loop state in version control and allowing only one open pull request per loop keeps the work reviewable and prevents duplicated changes.
Summary
Kyle Mistele argues that coding agents need better-engineered loops, not simply better prompts. A blind loop can generate a 40,000-line pull request that nobody wants to read, even if it includes automated review and verification. He borrows the structure of a control loop: measure the current state, compare it with a desired state, choose an incremental change, apply it, and measure again. His example migrates RPC procedures to Effect. AST grep finds unmigrated procedures, a controller chooses the smallest or most useful next procedure, and an actuator agent applies the change using handwritten golden patterns. Each run creates one pull request through CI. A feedback file in version control lets humans steer the agent without repeatedly editing its setup. Flow control stops the loop when its previous pull request is still open. The result is a coding process that produces small changes people can inspect, while still allowing parallelism and higher throughput when the team is ready.
Large agent-generated pull requests create a review problem
Mistele opens with the example of a coding agent producing a 40,000-line pull request that nobody wants to read. Adding verifiers or several code-review agents does not solve the basic problem if the system still generates more code than the team can inspect. He distinguishes this from Ralph loops, which can work well for certain problems, especially when someone is working alone and the system is not critical. Teams with customers, regulatory obligations, and service-level agreements need a process that limits risk before code reaches production.
Control theory gives coding loops a measurable structure
A control loop moves a dynamic system toward a desired state. A sensor measures the current state, the set point defines the desired state, and their difference is the measured error. A controller turns that error into an incremental control signal, and an actuator applies the change. The system is measured again after disturbances occur. Mistele compares this with a thermostat and points to Kubernetes autoscaling and infrastructure as code as familiar examples. Incremental changes reduce the chance of oversteering or destabilizing the system.
Agentic control loops need sensors, controllers, and actuators
For a coding loop, the set point describes a desired property of the codebase. The sensor can be deterministic, such as ESLint rules, AST grep, or another structural check, or it can use an agent and natural-language rules. Components can overlap. React Doctor, for example, can identify React problems and recommend which ones to fix, making it both a sensor and a controller. A controller matters because an overly large or incorrect change can quickly make a loop unsafe.
A migration becomes manageable when the loop selects one procedure
HumanLayer uses a loop to migrate an RPC API to Effect. AST grep finds procedures that still match the old pattern, then filters and sorts the results deterministically. Before the incremental migration starts, the team records the full list on the main branch so new pull requests cannot add more unmigrated procedures. A simple controller can select the first violation, or AST grep can select the smallest procedure to reduce risk. The controller can also use telemetry, such as error counts or gaps in APM coverage, to choose a migration that improves the code for a specific reason.
Handwritten golden patterns give the actuator a local standard
The actuator is an agent plus a skill. Mistele recommends developing the skill over time and writing golden patterns by hand before letting the agent operate. These examples show the idiomatic forms the team wants, instead of leaving the agent to follow documentation or patterns found on the internet. The skill and the controller's chosen procedure are passed to the agent. Once the agent finishes, the workflow deterministically commits, pushes, and opens a pull request using the agent's final response as the description.
CI can run one complete loop iteration on a schedule
Mistele recommends running the workflow in GitHub Actions, GitLab, CircleCI, or a similar system because the CI environment already has access to the repository, secrets, scheduling, and dispatch. One workflow run performs sensing, control, and actuation, then creates a pull request. A daily schedule can produce one small change each morning. When HumanLayer first tried this, maintaining the skill required too much manual work, so the team added a feedback Markdown file tracked in version control. A slash command on the pull request loads its diff, comments, reviews, and feedback into the next agent run.
Flow control prevents unfinished loop work from stacking up
If a team is traveling or busy for several days, scheduled loops can create duplicate and conflicting pull requests. Mistele's fix is to label pull requests created by each loop and check for an open pull request with that label before starting another iteration. If one exists, the workflow stops. This gives each loop at most one open pull request, so the system does not create more work before a human has reviewed its previous output. Once the process is trusted, throughput can increase by selecting several procedures, giving each its own context window, or running several workflows for different reviewers.
"Control loops change a system incrementally instead of just trying to get straight to the end state immediately all at once and risk blowing everything up."06:11
Who should watch
You are considering coding-agent loops for a shared codebase and need pull requests that engineers can review without trusting a giant diff.
Your migration or cleanup task has a measurable target, such as removing an old pattern, enforcing an API specification, or improving instrumentation.
Scheduled automation keeps producing duplicate pull requests while the team is busy, and you need a way to pause one loop and steer it through version-controlled feedback.
