In my recent 1:1 conversations with engineers across our team, I have noticed a pattern of frustration. Developers are spending their days hovering over AI prompts, watching terminal outputs scroll by line by line, and stepping in to correct minor syntax mistakes. There is a clear feeling that instead of making us more productive, AI tools have turned us into helicopter managers. As we discussed in my previous reflections on navigating AI change, this shift from writing code to delegating it requires building a different kind of trust.
My boss, Christopher Cunningham, recently shared an analogy that captures this trap: the Roomba. When you buy a Roomba, the goal is not to follow it around the house, correcting its path every time it bumps into a chair leg. You could vacuum your house much faster yourself. The whole value of a Roomba is that it runs on its own in the background. If you spend your afternoon trailing it around the living room, buying it was pointless.
Of course, exceptions exist. For example, my second floor has glass panels, and the Roomba spent its first day repeatedly bumping into them because its sensors could not see the transparent barrier. I had to pause the run and set up a digital no-go zone. Once that boundary was established, I could let it run unmonitored (unless it somehow figures out how to hack its way past the digital barrier).
We are making the exact same mistake with AI agents today. We have delegated the work, but we are still trying to control every line of code. Trusting the system means setting clear boundaries (the equivalent of digital no-go zones) rather than hovering over the AI while it works.
Trusting the system means setting clear boundaries (the equivalent of digital no-go zones) rather than hovering over the AI while it works.
Defining the Boundary
To get past this, we need to understand two concepts: agentic loops and micro-interactions.
- An Agentic Loop is when you give an AI a goal, and it keeps working (planning, writing, testing, and fixing code) until it gets the job done without you stepping in. Industry pioneers have shown that these agentic design patterns can significantly improve model performance compared to simple zero-shot prompting.
- A Micro-Interaction is when a developer jumps in to correct or guide the AI at every tiny step, rather than letting it finish on its own.
Improving our craft means moving away from constant manual steering and letting these loops run on their own.
How We Got Here
Our relationship with AI tools has evolved through a few clear stages, changing rapidly over the last twelve months:
- The Prompt Era: We wrote long instructions to get the AI to output correct code. This was hard because we were still guessing how the AI would interpret our words. Most of the industry is still here today.
- The Skills Era: We built reusable patterns and slash commands. This helped teams establish reliable, repeatable steps for the AI to follow.
- The Workflows Era: We began combining multiple agents, skills, and commands to handle larger tasks.
- The Loop Era: We now give the AI a broad goal and let it run, test, and fix its own work until it succeeds.
Writing the actual code is no longer the hard part. Our focus must shift from writing the code ourselves to building the loops that verify the AI's output.
Fix the System, Not the Code
The friction today comes from how we interact with these tools. We often treat agents like smart autocomplete tools, stopping them the second they make a mistake.
If the final output of a loop is wrong, do not micromanage the intermediate steps. Instead, look at the failure afterward and ask: Why did the loop fail?
Check if the prompt, the tools we gave it, or our testing rules were incomplete. For example, if the agent writes code that violates formatting rules, do not rewrite the file yourself. Instead, update the linter rules or the instructions so the agent fixes the code on its next try. When you fix the system instead of the individual mistake, you make sure the error never happens again.
When you fix the system instead of the individual mistake, you make sure the error never happens again.
This shifts the engineer's role from manual coding to system design. The core of modern engineering is building the guardrails that make these loops reliable.
Moving to autonomous loops helps us use AI speed safely. Research shows that introducing AI without proper controls can actually make software 7.2% less stable, because developers generate massive amounts of code that are hard to review (source: DORA Gen AI Report). To keep things reliable, we need to focus heavily on automated testing. However, productivity is not just about counting the number of pull requests. Treating code volume as a scoreboard only drains team morale. We need to focus on real results, not vanity metrics.
Learning to Delegate to Machines
If you are early in your career, learning how to delegate is one of the most critical skills you can build. True delegation means giving someone a clear goal, setting the context upfront, making sure they have what they need to succeed, and letting them work. When they finish, they present completed work for your review.
Delegating to an AI is no different. The rules of delegation are identical. The only change is that you are delegating to an AI agent rather than another engineer.
If you don't provide a coworker the right context, you will get poor results. The same thing happens with an AI. In fact, learning how to prompt an AI is great practice for communicating with other engineers. Success in both cases requires clear scope, explicit criteria, and trust.
For developers starting out, a simple rule of thumb applies: if the agent fails the same test twice, do not step in to write the code manually. Instead, look at the test rules or the prompt instructions to see where the boundaries need to be clarified.
How to Audit and Fix the Loop
Reviewing an agentic loop requires more than just checking the final output. When an agent runs through multiple steps, a small mistake early on can turn into a major failure later. To make the loop reliable, we need to inspect the entire path the AI took.
We call this Tracing. Think of it as a flight data recorder for your code. When a run fails, we look at three distinct layers:
- The Thinking Step: Did the AI break down the task correctly and choose the right tools?
- The Action Step: Did the AI use its tools correctly, with the right options and settings?
- The Result Step: Is the final output correct, safe, and formatted exactly the way you asked?
To make these loops reliable, we must establish structured testing, secure environments, and deep observability.
Testing AI agents requires automated Evaluations (Evals). These are automated test suites that run your agent against a reference dataset of scenarios to make sure outcomes are accurate and safe. Both OpenAI and Anthropic have shown that these evaluations form the foundation of agent quality. Since AI behavior is unpredictable, these tests must check actual outcomes (like verifying a layout rule or an API status code) rather than asserting on exact text matches.
Running these test loops also requires secure execution. Running untrusted, AI-generated code directly on your local machine is a safety hazard. Instead, these loops must execute inside isolated, temporary sandboxes like E2B or Docker containers. This keeps the host system secure and prevents the agent from modifying local files.
When a test fails, you need deep visibility to understand what went wrong. Teams can use tracing tools like LangSmith or Langfuse to record every step, tool call, and reasoning state. For instance, Honeycomb structured their logs using span-based tracing to make agent execution steps easier to debug. Much of this data is also captured directly in developer CLI logs. When using tools like Claude Code, session logs record every step in structured JSON. If a run diverges, you can compare the logs against a successful execution to isolate the exact step that went off track.
When a bug does slip into production, avoid patching the code manually. Instead, convert the bug into a new evaluation scenario, update the prompt or validation rules, and allow the agent to solve the task autonomously. This makes sure the error never happens again.
Risks and Trade-offs
Moving to fully autonomous loops comes with new challenges:
- Token Costs: Cap loop execution (e.g., maximum five iterations), monitor token usage per task, and use techniques like OpenAI's prompt caching to reduce redundant context costs;
- Quality Drift: Run automated CI checks and visual gates before notifying reviewers to avoid PR fatigue;
- Context Overload: Define clear workspace boundaries and file-level exclusions;
Managing this shared infrastructure (the tools, skills, and test datasets) changes the role of platform engineering teams.
Leaders also need to look at the costs and benefits. Spending a few dollars on API tokens to let an autonomous loop fix a complex bug is a huge win compared to paying for several hours of developer time. At the same time, we must prevent developers from falling into the trap of blindly approving code changes without understanding how they work. Reviewing AI-generated code requires us to focus more on system design, not less.
When you are used to controlling every character, letting an agent run in the background feels like letting go of the steering wheel.
The Path Forward
Stepping back from the console is uncomfortable. When you are used to controlling every character, letting an agent run in the background feels like letting go of the steering wheel.
But the long game of software engineering has always been about focusing on the big picture rather than spelling out every line of code. As platforms like Google Antigravity continue to mature, engineering success will be measured by how well developers define goals and how effectively they audit loops. Trust the process, build the verification systems, and let the Roomba clean. Stay curious, and be fearless.