Loop engineering solves the coding-agent babysitting problem by giving DevOps teams a way to run larger tasks with evidence, constraints, and a clear definition of done. Andrey Devyatkin, Vladimir Samoylov, and Fernando Gonçalves unpack outer loops around agents, context-window limits, unattended runs, greenfield versus brownfield work, alert batching with SNS and SQS, model mixing, token costs, and why bad code still gets worse when you automate it faster.

Spotify Apple Podcasts RSS

Summary

Coding agents can do a lot now, and yet most engineers are still parked in front of the screen, tapping enter, enter, it’s okay, continue like a parent walking a toddler across a room. This episode of Agentic AI in DevOps closes a gap the hosts left open in their foundational run: loop engineering — the discipline of wrapping an agent in an outer loop that runs a large task to completion without a human at the keyboard. Andrey Devyatkin, Vladimir Samoylov, and Fernando Gonçalves work through what a loop actually needs (a clear definition of done, a way to collect evidence, and constraints on how far it can wander), why the context window — not the model — is the constraint that forces the loop, and where the whole idea earns its keep in DevOps: batching noisy alerts instead of firing an agent at every one. Along the way there is a metric worth stealing (Vladimir clocks how long an agent runs before it has to ask him anything — last count, two to three hours), a two-stage greenfield trick, a confession about running Codex inside Cursor to spend the bigger subscription, and a blunt reminder that a loop pointed at a bad codebase just produces more bad code faster — “please delete this repository, it’s screwing up our training data.”

Key Topics

What loop engineering actually is

The hosts frame loop engineering as the missing term from their earlier foundational episodes, which covered tools, context, and the harness but never named this one. Vladimir Samoylov gives the working definition: an agent in a loop has to be able to act — change something — then observe what it changed, decide what to do next or whether to change approach, and check whether the result now matches the goal. If it does not match, it loops again: more changes, verify, repeat, until it does. The non-negotiable piece is evidence. Without logs, errors, test output, or some other signal fed back into the loop, the agent has no way to know whether the goal is met — it is guessing in the dark.

Fernando Gonçalves adds the other half: constraints. A loop needs boundaries on how far it is allowed to go, and a definition of done. His analogy is a Jira ticket — you write the definition of done, hand it to the agent, and the agent carries the work from this point to that point. Andrey Devyatkin ties the two together as nested loops: the agentic loop the hosts discussed in earlier episodes is the inner loop — the model’s own act-observe-decide cycle inside a single session. Loop engineering is the outer loop you build yourself around the harness, checking that the larger task is actually finished and restarting the agent as needed. The inner loop closes a task; the outer loop closes a project.

This is what the “babysitting” complaint is really about. Engineers keep telling the hosts that the agents do impressive work but still need someone in front of the computer approving each step. The pull toward loop engineering, Fernando notes, is partly just fatigue: people are annoyed at having to sit there, and they want to hand over a goal and walk away.

The context window is the real constraint

The first hard problem the loop solves is the context window. A genuinely big task will not fit in one, so you cannot just hand it over and let a single session grind. This is the origin of the Ralph loop — a deliberately simple pattern where you tell the model to do the next thing from a plan document, let it either finish or get stopped by a hook watching the context window, then restart the session and repeat. You are, in effect, restarting the harness continuously so you never hit the wall. (The pattern is named, half-jokingly, after Ralph Wiggum; it has inspired several Ralph-loop projects and shows up alongside newer harness features like /goal.)

The alternative to restarting is summarization, and the hosts split on it. Vladimir, a self-described Codex user, likes how OpenAI’s Codex handles the squeeze: as the window fills, it runs a smarter-than-naive summarization that keeps the initial request and the last roughly 20% of the context verbatim — on the theory that the most recent work matters most — and compresses the messy middle. He compares it to how people work: you keep the original goal and the finished result, and throw away the trial and error in between. Andrey takes the opposite tack and avoids summarization where he can, because it is lossy and because the summary itself consumes part of the next session’s window — treat a summarization event as the start of a new session, and it can eat a considerable chunk of the room you have left to work in.

Between “restart clean” and “summarize,” the episode points at the middle ground now shipping in the harnesses. Both Codex and Claude Code expose a /goal command that iterates toward a stated goal, though within a single session. Better still, Andrey argues, is delegating to sub-agents to preserve the main context — the approach he attributes to AWS’s Kiro, which slices a large stack into small pieces, runs a sub-agent per piece, and keeps the supervising session thin by seeding context down and validating results back up. And the low-tech version still works: offload state to an external system. Vladimir has used a task tracker like Linear as scratch memory; Andrey notes a plain Markdown file does the same job.

How long can an agent run unattended

Vladimir offers a metric other teams could adopt: how long the agent runs without asking him anything. His last high-water mark was two to three hours of uninterrupted work. The catch is that hitting numbers like that pushes the human up the org chart — you have to think far enough ahead to hand over a task big enough to fill the time, which means acting less like an engineer and more like a manager writing a brief.

There is a comic failure mode here too. Andrey ran the loop against a small hobby project and simply finished it — ended up with a tiny app running locally on his MacBook, all the harness, goals, and hooks still primed, and nothing left to point them at. As Vladimir puts it, the project is done, and it is an interesting world to live in when the constraint is no longer the agent’s stamina but your supply of work.

Fernando presses on the part everyone worries about: what is the quality of what comes out of a multi-hour unattended run? He still sees rough output even on short ones. The honest answer from the table is that expectations have to be calibrated to the task — which leads straight into where loops actually shine.

Greenfield vs. brownfield: where loops shine

The pattern the hosts keep landing on: loops thrive when the agent has something concrete to measure against. Vladimir keeps his tasks scoped and finds greenfield work goes remarkably well, and he has turned that into a two-stage trick. Rather than ask the agent to modify his real app, he has it build the new feature in an empty space — same framework, same language, same tools — let it run three or four hours until the feature is done, and then ask it to merge the feature back into the main application. The merge step works even when the isolated code was written in some “bizarre way,” because porting a working thing is a bounded problem.

Why greenfield? Because the failure mode is the tweak, not the build. Ask an agent to “create me a web page that looks beautiful” and the first result often does look good; start adjusting it and things fall apart. Andrey’s version is a rewrite rather than a blank page: his pet project started in Python, and when he wanted to move part of the processing off the local machine onto a web server, he told the agent to redo that piece in Go — “look at this, make it Go.” That works precisely because the agent has a reference. It can run the existing code, see the output, run what it builds, see that output, and compare the two. The old behavior is the definition of done.

That is the reusable lesson for loop design, and Fernando names both halves: figuring out the end criteria is the hard part, and separately you have to figure out what you are looping over. In a program you loop over an array or a map — you need a concrete set. A loop without a measurable end and a defined set of items to grind through is just an expensive way to wander.

Loop engineering for DevOps: batch your alerts

This is where the episode connects loops back to its own title. Andrey walks through an experiment he is running on alert fatigue — the Slack or Telegram channel that fills with alerts of wildly varying quality until nobody reads it. The tempting move is the one being sold as a category: run an AI agent on every single alert. His take is blunt — that gets expensive very quickly and is not necessarily productive. An alert might be flapping and resolve itself in five seconds while you have already burned tokens on it; worse, you can end up running five or ten investigations into the same underlying event and miss the bigger picture.

The better shape is a loop over a batch, and it falls out of how alerts already travel. In a stack like Amazon Managed Service for Prometheus, Alertmanager sends alerts to Amazon Simple Notification Service (SNS), and from SNS you fan out to wherever humans read them. The trick: add an Amazon Simple Queue Service (SQS) queue as a second subscriber to that same SNS topic, so every alert is also accumulated in a programmatically readable store alongside normal delivery. (Vladimir notes the same idea works with a Kafka topic or Redis if that is what a team already runs.) Now a small skill can pull everything from the last hour, three hours, or day, and ask the agent to categorize the batch into actionable versus noise and act on it. Andrey ran exactly this and cleaned up a couple of noisy alerts on the spot.

Batching is not only cheaper, it is often better. As Vladimir puts it, the alerts are all symptoms and only one is the real root cause — process them one at a time and you can’t see that. A single event commonly manifests as several unconnected-looking alerts across the system: a spike on the load balancer, then the database, then something downstream. Seen by eye they look separate; an agent looking at the whole batch — and, with something like B.O.R.I.S’s MCP connected, able to pull live data and resolve dependencies — can spot that they are one event propagating through the stack. Processing ten or twenty together is also faster in wall-clock terms, since you are not waiting on per-item scaling. The same shape applies to security tooling, Fernando points out: thousands of findings, mostly false positives, with one low-severity item that actually matters buried in the pile. It is the job nobody wants — a full alert channel that still needs tending while everyone is busy — which makes it a natural fit for a loop.

Building the loop: tools, tokens, and model mixing

How do people actually build these outer loops? The common starting point is the tool everyone already knows: bash gluing harnesses together, piping one agent’s output into another’s input. It works. Andrey then surfaces a more productized option he found by following a thread from the previous episode — guest Viktor Vedmich had mentioned the long-running Russian-speaking tech podcast Radio-T, Andrey went to see what those folks were up to now, and landed on ralphex (ralphex.com), an extended Ralph loop built by one of the show’s hosts. Ralphex takes the Ralph idea further: you put a plan in a known place in the repo, and it drives Claude Code and Codex against it as a graph of execution — pairing them so one acts as executor and the other as reviewer. Andrey rates it the most complete of the several Ralph-loop projects he has seen.

Which raises the prerequisite nobody escapes: a loop burns tokens continuously, so you need something to burn. In practice that means a beefy subscription, a thick wallet for API rates, or the biggest GPU box you can fit under your desk to run locally. As Andrey puts it, you can build the loop, but it will get you exactly as far as your wallet or subscription allows — a point that echoes the token-cost reality check from episode #13.

The model-mixing rabbit hole gets a self-aware laugh. Vladimir admits he caught himself running the Codex CLI inside Cursor — using Cursor’s smaller subscription to drive the CLI where he has the bigger one — prompting Andrey to note how quickly this all turns into a Rube Goldberg machine of stacked subscriptions (“you’re just starting a crazy thing with all of this”). He is genuinely unsure how much you gain from crossing models versus running separate sessions on the same one. Where it clearly helps is subjective or exploratory work — Vladimir’s example is asking Claude, Grok, and Codex each to riff on a house-renovation layout, since they are trained on different data and produce different ideas. And the models are trained to behave differently: Andrey describes OpenAI’s models as pedantic to a fault — a Codex “grill me” planning session will interrogate you about every tiny detail until you want to scream just decide it for me — while Claude tends to pick a reasonable option and ask fewer questions. That pedantry has a use, though: it makes Codex the better reviewer.

Loops don’t fix bad code

The sharpest disagreement is about whether code quality still matters when a human may never read the code again. Fernando floats the provocative position: as long as it works and doesn’t hurt performance, maybe how beautiful the code is matters less and less. Andrey disagrees, and it is the most important caveat in the episode. Bad patterns spread — the agent uses existing code as its example, so ugly patterns infest the codebase and multiply. He is not arguing for reviewing every line, but grilling sessions to stay aligned and clear coding guidelines still matter, because without them the codebase becomes unmaintainable in surprising ways very quickly. Point a loop at an already-bad codebase, Vladimir summarizes, and it only makes things worse.

The table riffs on where this leads. Fernando recalls someone filing an issue on a public repo that amounted to please delete this repository, it’s screwing up our training data — about 20% of the code is that bad. Vladimir’s counterpoint is that a market is already forming for people who will rewrite your codebase for a fee when you are stuck — the “vibe-code cleaners.” Andrey’s read: there is a lot of consulting work coming down the pipe; give it a year or two. The half-serious framing that “building your own AI loop is the engineering challenge of 2026” lands here too — the loop is only as good as the criteria, the constraints, and the code it is allowed to touch.

Resources

Join B.O.R.I.S Slack Playground