Two Loops: One Builds Your Code, One Improves Your AI Agent Chapter 12 of The Agentic Development Lifecycle

An AI coding agent makes a mistake. You fix the code, rerun the tests, and move on.
Then it makes the same mistake next week.
You fix it again.
A few days later, another agent repeats it.
At some point, you have to ask a different question:
What if the problem isn't the code the agent generates, but the system that tells it how to generate it?
That question gets to the heart of the Agentic Development Lifecycle (ADLC).
The idea is simple: building software with AI agents requires two feedback loops—not just one.
🔄 One Loop Builds. One Loop Steers.
The first loop produces software changes. The second improves the system responsible for producing them.
Think of them as two connected engineering processes:
• Inner loop: Turns a task into a verified software change.
• Outer loop: Uses evidence from completed work to improve the agent's instructions, context, tools, and controls.
The inner loop helps you ship code.
The outer loop helps you avoid repeating the same mistakes.

This distinction matters because an agentic workflow is not a static pipeline. Instructions become outdated. Context retrieval misses important details. Tests fail to catch defects. Controls accumulate until they contradict one another.
Your harness is an engineered system, too. It needs maintenance and improvement just like your application.

1. The Inner Loop: From Intent to Integration The ADLC inner loop has six phases:
2. Intent — Define what needs to change and what success means.
3. Ground — Gather the relevant code, context, and evidence.
4. Decompose — Break the task into manageable steps.
5. Generate — Produce a candidate implementation.
6. Verify — Check the result against acceptance criteria.
7. Integrate — Incorporate the accepted change into the wider system. The order matters. Intent, grounding, and decomposition narrow the space of possible solutions. Generation introduces variety: the agent may produce several plausible approaches, not all of them correct. Verification and integration then reduce that variety to an acceptable change.

Here's the important debugging lesson:
When an agent produces bad code, don't immediately blame the model.
Ask yourself:
• Was the task clear enough to evaluate?
• Did the agent have the right context?
• Was the task broken down sensibly?
• Were the acceptance criteria strong enough?
A failure during generation may have started much earlier.
Fix the earliest weak point in the process, not just the latest visible symptom.

1. The Outer Loop: Stop Fixing the Same Problem Imagine an agent repeatedly misunderstands a particular module. You could add a reminder to individual prompts. You could ask reviewers to pay closer attention. You could manually correct every generated patch. But those responses treat every occurrence as a separate incident. The outer loop asks: What should we change in the harness so this failure becomes less likely next time? Maybe the agent needs better repository context. Maybe retrieval is returning irrelevant files. Perhaps a verification step is missing. The team investigates the pattern, improves the relevant part of the harness, and observes whether the change helps. That's the outer loop at work. But there's a catch: the inner loop can operate much faster than a human team can inspect every result. If you only collect evidence during occasional retrospectives, you may discover a recurring problem long after it has become expensive. The solution is automated sensing. Capture execution traces. Record verification results. Track recurring failure patterns. Surface important changes in agent behaviour. Humans can still make the consequential decisions. But collecting the evidence shouldn't depend entirely on someone remembering to do it.
2. No Evidence, No Learning The two loops connect through artefacts—the records produced as work moves through the lifecycle. Start with five: • Task specifications and acceptance criteria • Context and retrieved information provided to the agent • Execution traces and tool usage • Verification results • Human corrections, approvals, and interventions Why bother? Because one failed test might be an isolated mistake. The same failure across dozens of tasks could indicate a deeper problem with the harness. Without records, those failures may look unrelated. With records, you can investigate the pattern and improve the system. This is more than debugging. It's how the development process learns. A lifecycle without artefacts has no outer loop. It may have tests, reviews, and retrospectives. But without evidence feeding back into changes to the harness, the system isn't systematically improving how it produces software.
3. Seven Rules for a Better ADLC The ADLC model also gives teams seven practical prohibitions:
4. Don't generate before intent is checkable. If success can't be evaluated, the agent has no reliable target.
5. Don't merge based solely on a test the generator authored. Verification needs independent strength.
6. Don't fix recurring defects only at the instance. Investigate the harness.
7. Don't add controls without a date, named failure mode, and retirement criterion. Avoid accumulating permanent safeguards without clear purpose.
8. Don't increase autonomy without evidence. Consider whether the harness can manage the risk and the potential blast radius.
9. Don't automatically trust artefacts an agent reads. Treat them as potentially untrusted instructions.
10. Don't mandate generation throughput. More generated code doesn't necessarily mean more useful, verified software. These rules challenge a common mistake: measuring agent productivity by how much code it produces. A workflow can generate code faster while producing more defects, weaker verification, and additional review work. The goal isn't maximum output. The goal is reliable engineering outcomes.
11. Autonomy Needs Two Ladders There's one more distinction worth remembering: specification strength and agent authority are not the same thing. Specification strength describes how clearly the task, context, and acceptance criteria are defined. Agent authority describes how much freedom the agent has to act. An agent might have a precise specification but very limited authority. Or it might have broad permissions while working from vague instructions. Neither dimension automatically fixes the other. Giving an agent more authority doesn't make an unclear task safer. Writing a detailed specification doesn't automatically make every autonomous action appropriate.

Autonomy isn't simply a switch you turn on.
It's a capability you expand when the surrounding system can support it.
🛠️ Try This With Your Team
You don't need to rebuild your entire workflow to get started.
Choose one AI-assisted development process and begin recording:
• What the agent was asked to do
• What context it received
• What actions it took
• Which checks ran and what they found
• Where a human had to intervene
Then look for recurring patterns.
Choose one problem, change one part of the harness, and measure whether the outcome improves.
That's your first practical outer loop:
Capture evidence → Find a pattern → Improve the harness → Measure the result.
The Takeaway
The inner loop builds software.
The outer loop improves the system that builds it.
Without the first, nothing gets shipped. Without the second, the same weaknesses can keep returning—even as your agents become faster and more capable.
The objective isn't to remove human judgement. It's to build a workflow that gives people reliable evidence and a systematic way to improve the system.
📖 Read the full chapter: Chapter 12 — The ADLC Model
Next up: Chapter 13 — The Autonomy Ladder, exploring how to increase an agent's authority without getting ahead of the system's ability to control it.
💬 Question for you: Does your team have an outer loop, or are you fixing each AI-generated problem as it appears?
If you're building reliable AI-assisted engineering workflows, follow along as we explore the ADLC one chapter at a time.