# Loop Engineering from First Principles — Kyle Mistele, HumanLayer AI Engineer · 2026-07-25 Kyle Mistele argues that the fix for AI-generated 40,000-line pull requests is not a better prompt but a better loop, borrowing from control theory: a sensor measures the gap between current and desired codebase state, a controller picks the smallest incremental change, and an actuator agent applies it using hand-written golden patterns. Mistele illustrates with HumanLayer's own loop that migrates their RPC API to Effect one procedure at a time, using AST grep as a deterministic sensor, a controller that selects the smallest unmigrated procedure, and an actuator agent gated by deterministic CI running a single iteration per day. The loop tracks its own PRs in version control, refuses to stack a new change while an earlier one is still open, and includes a feedback file and comment trigger for humans to re-steer it. Mistele concludes that this design makes the code incrementally better, readable, and verifiable, solving the problem of unreadable mass-generated code. ## Questions this episode answers ### How does control theory apply to AI coding assistants to avoid massive, unreviewable pull requests? Kyle Mistele advocates applying control loops: define a desired end state (setpoint), use a sensor (e.g., AST grep) to detect current state and compute error, a controller to decide which small change to make next (like picking the smallest unmigrated procedure), and an actuator (AI agent with golden patterns) to apply it. Unlike blind loops that generate massive diffs, this incremental approach produces small, reviewable PRs and tracks progress in version control. [4:44](https://aiengineer.podhood.com/37385f8a-aefb-42fb-8055-ef7dab03c060?t=284000) ### What technique does Kyle Mistele use to ensure automated loops don't stack unreviewed PRs? Each loop workflow is given a unique label. Before running, the workflow checks if a PR with that label is already open. If so, it shuts down, preventing new work from piling up before a human has reviewed the previous output. This ensures at most one unreviewed PR per loop exists at any time, avoiding duplication and conflicts. [15:05](https://aiengineer.podhood.com/37385f8a-aefb-42fb-8055-ef7dab03c060?t=905000) ### How can a human steer an automated coding loop without manually editing the code? The loop uses a Markdown feedback file tracked in version control. After an agent creates a PR, reviewers can leave a 'slash iterate' comment. The workflow loads the PR context and feedback file, instructing the agent to fix the code and update the feedback file with new instructions. This lets teams steer the loop's behavior iteratively without manual code changes. [14:18](https://aiengineer.podhood.com/37385f8a-aefb-42fb-8055-ef7dab03c060?t=858000) ## Key moments - **[0:00] Intro** - [0:49] Coding agents produce 40,000-line PRs nobody wants to review on teams - [2:30] Kyle Mistele predicts swarms of agents will design loops instead of engineers - [3:51] "Bad code is much more expensive in the age of agents than it has ever been at any point in the past." - **[4:29] Control Theory** - [4:29] Control loops, like a thermostat, prevent agents from making one large change - **[8:35] Migration** - [9:09] HumanLayer migrates RPC API to Effect one procedure at a time with a control loop - **[10:40] Version Control** - **[12:35] Actuator** - **[13:51] CI Wiring** - [14:07] A feedback file tracked in version control lets humans re-steer agent loops - [15:26] Loop flow control prevents stacked PRs by pausing when the last PR remains unmerged - **[15:44] Flow Control** - **[17:03] Conclusion** - [17:03] Agentic control loops let teams read code and improve it incrementally ## Speakers - **Kyle Mistele** (guest) ## Topics Coding Agents ## Mentioned GitLab (company), HumanLayer (company), AST grep (product), CircleCI (product), Claude (product), Claude Code (product), ESLint (product), Effect (product), GitHub Actions (product), Kubernetes (product), Next.js (product), OpenClaw (product), OpenCode (product), Postgres (product), Ralph (product), React (product), React Doctor (product), TypeScript (product), Vite (product) ## Transcript ### Intro **Kyle Mistele** [0:28] Hey everybody. My name is Kyle, I'm co-founder of a company called HumanLayer, and I'm here to talk about loops. I think we've all been building loops lately, and I realized recently, I think we're all doing it wrong. Loops are really powerful, don't get me wrong, but so much of the discourse around them is hype-driven and just really not helpful,right? We— I think we have this idea, just kind of as an industry somehow, that we can like pipe a prompt and a loop to a coding agent and that we can build software this way,right? Maybe we're investing a lot of time in verifiers, maybe you have 6 different code review agents, but at the end of the day, if we're doing this, we're still building 40,000 line PRs that just nobody wants to read,right? And this isn't to throw shade at Jeff Huntley,right? This is— Ralph is an innovative, uh, it's a sharp tool that works very well for certain types of problems. It works very well if you're not building on a team, and it works very well if you're not working on critical systems. But most of us are working on teams, and we don't fit in that box. So today I want to talk about how to build loops that work in large, complex codebases for systems that have real customers, real users, real regulatory obligations, and service level agreements, and everything else that keeps us from shipping YOLO 40,000 line PRs straight to production. In other words, I want to talk about how to build loops for the real world. If you're not aware, uh, this post actually dates back to July. It went viral this past January, which is when a lot of us, I think, started building loops. And of course, much more recently, I'm sure y'all are going to see this slide a lot this week, uh, but Peter Steinberger said that we shouldn't be prompting coding agents anymore,right? We should just be designing loops that prompt our agents. Of course, OpenClaw is notoriously built on loops. Loops build the code, loops review the code, they merge and release the code, they find and fix the bugs. There's even loops for finding and fixing bugs in the loops that are merging the things,right? It's loops all the way down. It's, uh, Boris Churny also, the creator of Claude Code, recently said that this is his entire job as an engineer now, is just writing loops to prompt Claude. And eventually, we might not even need loops,right? We're just going to have like swarms of agents designing loops to prompt agents building swarms for loops and like, I don't know, somewhere we're like writing production code, I assume. And in fact, all of our loops that we're building are producing so much code that we can't possibly read all of it,right? So we might as well just not read any of it,right? We're— we're investing in verification and in code review, but all this code is read-only. This was the thesis of a conference that, uh, was here in town last month. So a lot of smart people at the frontier labs think that this is the future of software development, and if you're doing this, you're moving 10x faster, and everybody else is getting left behind. Now, it's not clear how well this works yet. Uh, it took 6 months to fix the Claude Code terminal flicker. The OpenCode team wrote a renderer in a fraction of that time. And OpenClaw, of course, also notoriously has stability issues. What is abundantly clear, however, is that this shit is really expensive if you don't work at a frontier lab and have an unlimited token budget. And all this code that we're writing is actually really expensive,right? Matt Pocock talked about this recently. Uh, bad code is much more expensive in the age of agents than it— it has ever been at any point in the past. So today I want to talk about what I think works in the real world and what we've started doing at HumanLayer, which, to be clear, is still building loops,right? I think loops are super powerful, but we can design loops and still read the code. In fact, we can design loops that make it easier to read the code because the loops are making the code better. We can solve hard problems in complex codebases with loops, and we can build our software for that at 3 incrementally. ### Control Theory **Kyle Mistele** [4:29] But, uh, to do this is going to take some real engineering, y'all. So let's talk about control theory. Control theory is all about how we drive a dynamic system, which would be your codebase, towards some desired stable or optimal end state,right? You have a sensor that measures the current state of the world. You have your setpoint,right, the desired state of the world, and the difference between those two things is your measured error. You have a controller that reads that measured error and turns it into a control signal about an incremental change to apply to the system. We have an actuator that applies that change to the system, which is undergoing disturbances in the meantime. And then we re-measure, recompute our measured error, and we're back where we started. Now, this sounds really complicated, and it can be. I have a twin brother, actually, who's an aerospace engineer. This is how they keep fighter jets from falling out of the sky. Uh, but, uh, it's probably a little bit simpler than most of y'all think. Does anyone have one of these? Uh, a thermostat uses a control loop,right? Uh, for— for any of our European friends in the audience, it's part of something we have, uh, here in the States. It's called air conditioning. And, uh, most of us probably actually use control loops on a daily basis,right? Kubernetes, auto scaling systems are built on control loops. Infrastructure as code uses a desired state, current state, iterative change, like control loop pattern. Postgres is, uh, auto vacuum and React's virtual DOM both use or approximate control loops. Control loops are ideal when we have a system that we want to change, a problem we can measure, and a way to get feedback on the results of that change. Like good software engineers have always been taught to do, control loops change the system incrementally instead of just trying to get straight to the end state immediately all at once and risk blowing everything up,right? They help us to avoid oversteering and destabilizing the system, and it minimizes risk. So control loops are the opposite of what I'm going to call a blind Ralph loop. They're how we avoid PRs that look like this because nobody wants to review this,right? Which is not to say that all Ralph loops are blind loops. The best Ralphs are actually applying control theory. I know Jeff Huntley is out in the hall somewhere wandering around. If you go talk to him, he's going to tell you the same thing,right? That Ralph is a, a teaching device, and I think some of us read it a little too literally, but this is how we should have always been building loops. But the other issue with Ralph loops is they're not incremental,right? It's just a bash loop. So we have to build agentic control loops. And to do that, we start by defining a setpoint, which is the desired end state of our codebase with respect to some property of it. And we add a sensor. There's a lot of ways to build a sensor. It can be strictly deterministic. Your ESLint rules, your AST grep, your PAC work, or it can be nondeterministic. You can have an agent and a skill and a bunch of natural language rules, and you could also just have a pipeline, like a combination of the two. So how do we build agentic con oops. There we go. Now, uh, this is all theory,right? Practically speaking, and because we're using agents, we can blur the lines a little bit between system components. So Aiden Bye's React Doctor, for example, is fantastic. It is, uh, it's a great way to catch all of the React slop that Claude snuck into your codebase last week. But, uh, it's a hybrid sensor and controller. It tells you what are all the problems with your React code, and also, by the way, what are the top three things you should fix and how do you fix them. Similarly, our controller and actuator might actually just be a single agent deciding on an incremental change to make and then applying it in the same context window. But I want to zoom in on the controller a little bit because without one, or without a well-tuned one, we might make too large of a change all at once, or we might make the wrong change entirely. And if you put that in a loop, you're in trouble pretty quickly. So we can use control loops to root out bad patterns and to clean up our code, but we can actually use them for all sorts of things,right? ### Migration **Kyle Mistele** [8:35] We could make sure that our API is compliant with someone else's OpenAPI spec. We can make sure that our MCP server is compliant with whatever version of the, uh, the MCP specification that we're currently on. Haven't checked. You could mirror a project from Python into TypeScript, or vice versa. You could even maintain your, uh, Vite-based slop fork of Next.js against the upstream. The key questions are, can we find something we can measure, can we apply changes incrementally, and can we get feedback on the quality of those changes. To illustrate that, I'm going to walk through a control loop that we use internally at HumanLayer. Uh, for our loop, we are incrementally migrating our RPC API to Effect. We adopted it for some of our race prone code. We like it, so we're adopting it across the rest of our codebase. If you've never seen Effect code before, the code on theright is just the kind of trivial procedure on the left rewritten in Effect. Uh, the syntax is really weird. We're psychos. We really like it. It's not for everybody. That's okay. Uh, this isn't a talk about Effect, so we'll keep moving. Ooh, clicker's not working. Cool. So step one, we have to build our sensor to find unmigrated procedures. We can have an agent do this, or we could use grep or rep grep, but instead we're going to use AST grep because it's really powerful. It's a great tool to have in your toolbox for building loops. It's language agnostic. It's out of band from your TypeScript config or ESLint rules, which if you're a TypeScript developer, you have watched Claude disable those with inline comments. Uh, but so we can just write a simple rule that finds unmigrated procedures, uh, based on the pattern above. And we over time, we can even layer on more rules that describe other patterns we want to get rid of, with granular include and exclude paths. If you have a multilingual monorepo like we do, uh, it'll work for any language you could possibly imagine. And we can just scan our codebase and it'll produce a long list of violations. Uh, way too long, in fact. It'll give you about 50 keys per violation. So we're just going to filter it down to four, and we're going to sort it deterministically. Why are we doing that? At the beginning, I said this was going to be practical, and so we're going to step outside of our control loop paradigm for a second because before we start incrementally migrating procedures one at a time, we need to enforce that all new procedures are using Effect,right? ### Version Control **Kyle Mistele** [10:49] So we're going to run a full scan once on main, sort all the violations deterministically, and track it in our version control. And then on every new PR, we can see if the branch added any unmigrated procedures,right? So this is our control loop, and our system is undergoing disturbances. In this case, uh, all of our teammates shipping Claude's slop. And this is how we make sure that they're not undoing our loop's work. This doesn't map directly to a part of the control loop, but we can kind of like squint at it a little bit and call it a disturbance dampener. So now that we've stopped the bleeding, we can actually design our controller. For a simple controller, we could just deterministically pick the first violation from the list. You can use bash and jq. Or we could get a little cleverer and use AST grep to find the smallest unmigrated procedure and always pick the smallest one to reduce the risk. Uh, we could have an agent make the decision if we really want to. I don't think you should ever send an agent to do deterministic code's job, but you certainly can. In fact, depending on the complexity, we could have the agent pick the procedure to migrate and just do it at the same time, like we just talked about. But we can make this even more powerful,right? Because we're not just migrating to Effect for the sake of it. We're doing it because it's helpful for handling errors and for helping us instrument our code better. And so what we could do if we want to get really clever is we can look at our telemetry and figure out which procedures have the most errors or the least instrumentation or has a gap in our APM,right? And when we send a control signal to our actuator agent, we can include not just the procedure to migrate, but also all the data about the things that we're trying to fix with this migration so that the actuator agent can actually make the code better instead of just doing a one-to-one migration. Oh, man. There we go. So next is building our actuator. Our actuator is just an agent plus a skill. Um, bring your CLI coding agent of choice. You should spend a lot of time on the skill. Not all of that should be upfront. ### Actuator **Kyle Mistele** [12:45] You'll want to iterate on it over time based on what works. At HumanLayer, we like to build out what we call golden patterns by hand before setting the agent loose. These are just like idiomatic handwritten examples for the agent to follow because they're just pattern replicators, and otherwise you're getting what's in the docs or what the agent knows from the internet. And so we pipe the skill plus our control signal into our actuator agent. And the skill, of course, should include a response template. And the agent's going to work and work and work, and it'll produce a final response. And then we're going to deterministically commit and push and create a PR using the final message as our PR description. Now, all we have to do is actually run the loop,right? Uh, my recommendation is to use GitHub Actions or your GitLab or your CircleCI or whatever else you're using because it has access to your code, it has access to your secrets, and it has great dispatch and scheduling primitives,right? We don't need a new cluster for this. So we can write a workflow that runs a single iteration of the loop, sense control actuate, and creates a PR. And then we can schedule this to run once a day. And every morning, we walk into the office to a small incremental PR that's low risk. And when we first did this, it was actually really frustrating, and we turned the loop off. And it, uh, because we had to constantly update the skill, we had to constantly check out the branch, change the skill, change the code, commit and push, and our loop was actually really high friction,right? ### CI Wiring **Kyle Mistele** [14:07] But there's a better way to do this, uh, where we can put a human on the loop in a really low friction way to re-steer it when it goes wrong. And the way to do this is to just create a feedback file that's tracked in version control, just as a markdown file,right? We can deterministically load it into our actuator agent's context every time that it runs after we run the controller. Then we can add a label to the PR,right? Each workflow needs to be able to identify PRs that it created since there might be a bunch of different loops running, and we only want workflows to respond to feedback from, uh, comments on their PRs. And we're going to add a comment trigger to each loop workflow. So then when a user leaves a slash iterate comment on the PR, uh, the loop workflow is going to pick that up. It's going to deterministically load all of the PR context, the diff, the comments, the review comments, the description into the agent's context along with the skill. And it's going to instruct the agent to fix the code, but also to update that feedback file,right? It looks kind of like this. And the benefit of doing this way is that now that feedback file with instructions is tracked in your version control. You can see how you've changed it over time. You can revert it if you need to. So the next thing we're going to do is add flow control. Because the other problem that we had when we did this was that if we were at a customer site for a week, or if we were traveling, or spent six days working on slides instead of writing code, uh, the PRs from all of our loops would just stack up. They'd duplicate work. They'd conflict, and we wouldn't get around to doing it. And like the loop's work is important, but it's not that important. And so now we just had all this like junk we had to deal with that wasn't important. So this is actually a really easy problem to fix, uh, because each loop and its workflow has a label that gets attached to PRs. When the workflow first runs, uh, before we check out the code and install the dependencies and run our sense actu or sense control actuate steps, we can just check and see if the last PR that we created, or any PR with the loop's label on it, is open. ### Flow Control **Kyle Mistele** [15:59] And if so, we just shut down,right? Because this means that the last time that a human, uh, reviewed the code from this loop was before the loop ran,right? No human reviewed the last output, so there's no reason to stack up even more work for humans to review. This way, we have exactly one PR at most open per loop at a time. No stacking, no duplication, hopefully no conflicts. And of course, once you're feeling confident in the loop, we're going to want to speed it up,right? I have 150 RPC procedures to migrate. If I do one at a time, it's going to take six months, which is way longer than I want to wait. Fortunately, there's a lot of ways to pick up the, the velocity of our loop. Uh, we could have our controller pick three procedures to migrate instead of one at a time or five. Uh, we could have our controller pick three or five and then do each of those in a separate implementation phase, which will be both cheaper and more reliable since each migration gets its own context window. Or we could just run the workflow four times and give one PR to each of four people on the team. So let's put it all together. We built a control loop that improves our code incrementally, and we're actually reading the code. ### Conclusion **Kyle Mistele** [17:03] It has adaptive flow control, so we're not creating a bunch of loop or a bunch of work that nobody wants to review. And we can re-steer it on the fly in a super low friction way. If you want to try this yourself, uh, we built a skill. Please try it out. My Twitter handle is down there on the bottom. Please share it. I would love to see what you build. And if you get excited by this, uh, at HumanLayer, we're hiring here in San Francisco. And if you're working on mission-critical systems and want to figure out how to get more out of AI, we'd love to chat. Thank you so much. --- This library is powered by PodHood (https://podhood.com), the podcast website platform.