“Loop engineering” is having a big moment right now.
Boris Cherny mentioned that he doesn’t prompt Claude anymore, he writes loops. Peter Steinberger posted a monthly reminder to stop prompting agents, and design loops that prompt them instead. On the other side, people are pointing out that a loop around an LLM call is still just a while loop, and that we had cron jobs and webhooks long before we had agents.
I think that this critique misses an important shift that’s happening: the work inside the loop has changed. Agents can now investigate, modify code, run tests, and review results with pretty high quality. The middle of the software development lifecycle (SDLC), where humans used to spend so much time working on repetitive tasks, can now be designed with agents and humans working side-by-side, as part of an autonomous system.
Most of the conversation today is still around individual loops: one developer using agents to move a task forward. But I believe the more important pattern is emerging at the team level.
The best engineering teams are starting to run agentic SDLC loops in production: always-on systems that take work from trigger to verified outcome across the software development lifecycle, with humans involved where judgment actually matters.
So, what is loop engineering?
At the team level, loop engineering is the practice of designing a system where a team of agents work toward an outcome, bringing humans in where judgment matters most. The hard engineering work lies in choosing the right system design, the right models for each task, and knowing when to involve humans so the loop delivers a higher-quality outcome.
A team-level loop connects triggers, agents, human checkpoints, and shipped outcomes into one repeatable system.
What makes loop engineering different from automation?
1. Agents carry the bulk of the doing
Pre-AI software automation could route, notify, and glue systems together, but it couldn’t investigate a stack trace, write a fix, and then rerun the test suite. The middle of the workflow, the part that used to require a person, can now be fully agentic. That’s a completely different category of work being absorbed, and it requires you to rethink what can become a loop.
2. Humans are in the loop by design, not as a failure mode
In previous DevOps-style automation, a human showing up usually meant something was broken. In agentic loops, a human checkpoint is where the highest-leverage judgment happens. It separates a high-quality outcome, from a loop that keeps spinning and burning tokens.
The hard part is identifying the right point to bring the human in. If it’s early, you’ve rebuilt a notification bot. If it’s late, you increase the risk of creating a whole lot of slop. The goal is not always to remove the human entirely, but to use the right level of autonomy for the risk involved.
3. Each run can make the loop better
A cron job runs the same way every night. An agentic loop can leverage memory and traces from previous runs to improve over time.
Each run produces a trace: what worked, what failed, and where the human stepped in and corrected course. That trace can then be fed back to improve the quality of the overall system: prompts, tests, acceptance criteria, tools, or escalation rules.
The key shift: from individual to team-level agentic SDLC loops
The most forward-thinking teams are moving beyond individual loops and building loops for the team: standing workflows where repetitive work across the software development lifecycle is handled by agents on an ongoing basis, and humans participate at the moments that actually need them.
We’ve started calling these agentic SDLC loops, and the shape is remarkably consistent.
The outer shape of an agentic SDLC loop
Trigger: A PR opens, an alert goes off, or a ticket lands.
Execution: Agents execute the middle: investigate, reproduce, draft a fix, and run the tests.
Verification: Agents and automated systems run the checks available to them, while humans step in where judgment, approval, or additional context is required. Some loops may require human involvement every time, while others can determine dynamically whether a human is needed based on risk.
Note: there’s also a mini loop between verification and execution. The agent continues to execute and verify until it meets its acceptance criteria or reaches a point where it needs to escalate.
Outcome: The loop completes once the outcome has been verified and the acceptance criteria have been met.
Improve: The team uses the trace from the run to improve the loop: what broke, what needed a human, and what could run more cleanly next time.
These stages describe the outer shape of an agentic SDLC loop, not necessarily a single agent moving through five steps. In production, the execution and verification stages often contain multiple specialist agents, each with its own objective, tools, and acceptance criteria.
An agentic SDLC loop moves from trigger to execution, verification, outcome, and improvement.
Ultimately, the loop doesn’t just create output, but drives toward a concrete outcome – a merged fix, a triaged incident, a closed vulnerability.
This is the most important part about loops: a loop that generates output nobody ships is not a successful loop. The loops that stick and have the highest ROI are the ones accountable for actually finishing something.
The loops teams are running today
Here are the agentic SDLC loops we see running in production most often.
Code review loop
PR opens (trigger) → agents analyze risk, perform a deep review, find and fix issues (execute) → human reviews for intent, not line-by-line diffs (verify) → approved, higher-quality merge (outcome)
This loop demonstrates a multi-agent SDLC loop. What matters is not the number of agents, but the separation of objectives. One system assesses risk, another performs the work, another tries to find fault with it, and a human supplies judgment only when the risk or ambiguity warrants it.
The code review loop we run at Augment.
When designed well, the code review loop above has shown that it can produce much higher quality PRs at a lower cost compared to a traditional code review bot, which just comments on the PR and waits for a human to repeatedly close the gaps.
Ticket-to-PR loop
Ticket lands (trigger) → agent investigates and drafts the code, performs E2E testing (execute) → human reviews the change (verify) → merge-ready PR (outcome)
Vulnerability remediation loop
CVE drops (trigger) → agent identifies affected services and drafts patches (execute) → human approves (verify) → patched services (outcome)
Incident response loop
Alert fires (trigger) → agent pulls logs, identifies the likely change, drafts a timeline (execute) → on-call engineer joins with full context and decides on escalation (verify) → triaged or mitigated incident (outcome)
The interesting thing here is that none of these are novel engineering loops. They’re the unglamorous, repetitive middle of the SDLC, which is exactly where most engineering time goes.
Connecting loops to build a software factory
Each agentic SDLC loop can deliver a step change in productivity on its own, but the real compounding begins when the loops start connecting. The ticket-to-PR loop triggers the code review loop. The triage loop’s findings become the ticket loop’s triggers. An incident postmortem spawns remediation work.
Connect enough of these loops and you’re no longer managing agents one at a time. You’re running a system that produces outcomes, measures itself, and improves: a software factory.
Connected agentic SDLC loops compound into a software factory.
I know the term “factory” can make some engineers flinch, so allow me to clarify. A factory isn’t about volume, and definitely not about slop. It’s about instrumented, repeatable, quality-gated production: throughput measured in outcomes, issues caught by the process, and skilled people spending their time on the highest-leverage judgment calls.
That’s when designing the loop itself becomes the thing your team optimizes. Where do the human checkpoints sit, and do we still need them? How can we improve our verification systems? Are the tokens we’re burning actually producing value? You want to measure your loops on outcomes per dollar, not output per dollar. That’s a very different question from “how productive is each engineer with their agent?”.
The pattern will outlive the term
While the specific term “loop engineering” may not survive (plenty of terms don’t), the pattern is defining the future of software engineering: agents doing the repetitive middle, humans at the judgment moments, and loops that can get better every time they run.
The teams building loops aren’t chasing a trend or a buzzword; they’re creating a system. And the ones that figure out how to make those loops compound won’t just ship faster, they’ll be running a different kind of engineering organization.
If you’re ready to start building agentic SDLC loops, try out Cosmos. If you’re interested in learning more about best practices on how to build these agentic SDLC loops for your team, talk to our team.
Further reading on loops
Written by
Vinay Perneti
VP of Engineering
As VP of Engineering, Vinay supports product, research, and engineering teams building AI agents that truly understand large, complex codebases. Before joining Augment, Vinay led product and platform organizations at Meta and Pure Storage. He’s drawn to problems that live at the intersection of technology and people, like how teams evolve, how AI reshapes the craft of software engineering, and what it takes to build things that evoke delight.