Search for ADLC today, and you might find two people confidently explaining two completely different things.
One is talking about building AI agents as products.
The other is talking about building software with AI agents.
Both use the same four letters. Both argue that traditional software development needs to change. Both have a point.
But here's the problem: follow the wrong advice, and you could spend months building the right controls for the wrong problem.
Let's untangle this.
Two teams. One acronym. Two different problems.
Imagine two engineering teams.
Team A is building an AI customer-service agent.
Customers will talk to it every day. Sometimes it will give a great answer. Sometimes it will misunderstand a question. Its behaviour might change when the model changes, the data changes, or a tool it depends on stops working.
The team needs to know whether the agent behaves correctly in production. They need evaluations, monitoring, safety checks, and ways to catch quality degradation over time.
Their problem is the behaviour of the thing they're shipping.
Now imagine Team B.
Team B is building a payment system using AI coding agents.
The payment system itself is supposed to behave predictably. What has changed is how the code gets written.
An AI agent can generate a large change in minutes. It can also introduce a subtle bug, choose an inappropriate dependency, or produce code that looks convincing but is wrong.
The team needs reliable tests, static analysis, architecture checks, and a review process that can keep up with the speed of code generation.
Their problem is the reliability of the process that produces the software.
See the difference?
One team is building an agent.
The other is using an agent to build software.
And that's where ADLC gets confusing.
Meaning A: The agent is the product
The first interpretation is the Agent Development Lifecycle.
Here, the AI agent is the product you're building and deploying.
Think of customer-support bots, research assistants, scheduling agents, and other AI systems that interact directly with users.
The challenge doesn't end when the software is released. In fact, that's when a new set of challenges begins.
Users ask unexpected questions. Models behave differently after updates. Retrieved information changes. Tools fail. Attempts to manipulate the agent appear in ways your original tests never anticipated.
You cannot test every possible interaction before launch.
So you need a continuous feedback loop:
• Evaluate the agent against expected behaviour.
• Monitor quality and performance in production.
• Track costs and latency.
• Test for prompt injection and other security risks.
• Investigate failures and improve the system.
The important detail is that the uncertainty lives in the product itself.
Every new user interaction creates another opportunity for unexpected behaviour.
That means monitoring cannot simply stop after deployment. You need ongoing controls for as long as the agent operates.
This is a legitimate engineering discipline. It solves a real problem.
But it isn't the main subject of this series.
Meaning B: The agent is the labour
The second interpretation is the Agentic Development Lifecycle.
This is the one we're exploring throughout this series.
Here, AI agents are not necessarily the products being built. They're the workers helping to build them.
You're developing an API, maintaining a legacy application, migrating a database, or adding a feature to an existing codebase.
Instead of writing every line yourself, you delegate tasks to coding agents.
They inspect files, generate code, run tests, modify implementations, and sometimes complete work with surprisingly little human intervention.
Productivity goes up.
But so does the amount of code that needs to be verified.
A coding agent can generate a change faster than a developer can understand it. Multiply that across a team, and you have a new engineering bottleneck.
Generating code is getting cheaper. Establishing that the code is correct is becoming the harder part.
Your challenge isn't primarily to monitor an AI agent serving millions of user interactions.
It's to ensure that the code produced by AI agents is safe, correct, maintainable, and suitable for the system it enters.
That calls for a different set of controls.
You need automated tests, type checks, linters, static analysis, architecture rules, well-designed development environments, and review processes that scale.
Most importantly, you need a way to prevent incorrect changes from reaching the main codebase.
Which brings us to the question that separates these two meanings.
The question that makes everything clearer
Forget the acronym for a moment.
Ask yourself:
Where does the randomness come to rest?
In other words, where does the uncertainty introduced by the AI ultimately end up?
Figure 1.1 — Same acronym, two places for the randomness.
In one case, the uncertainty reaches your users. In the other, it must be contained before the code is merged.
Alt text: A comparison of two AI development lifecycles. In the first, a stochastic agent serves users and requires continuous runtime monitoring. In the second, an AI coding agent produces software whose changes must pass verification gates before merging.
If you're building an AI agent as a product, the uncertainty continues into production. Users interact with a system whose outputs may vary.
You need runtime monitoring, ongoing evaluation, and mechanisms for detecting changes in behaviour.
But if you're using an AI agent to build a conventional software product, you have an opportunity to contain that uncertainty.
The generated code can be checked before it enters the main codebase.
A test either passes or fails. A type checker either reports an error or doesn't. A policy can block a merge when a required check fails.
These controls aren't perfect, and they can't prove that every program is correct. But they give you something powerful: a boundary where you can reject changes that fail known requirements.
That's the merge gate.
The goal is not to make the AI perfectly predictable.
The goal is to make sure its unpredictability doesn't automatically become your users' problem.
Why using the wrong playbook is expensive
Here's where the distinction becomes more than a naming debate.
Imagine a platform team adopts an AI coding agent. They invest heavily in monitoring the agent's outputs, measuring token usage, and building dashboards around generation quality.
Those metrics might be useful.
But nobody asks the most important questions:
• How much code is each engineer expected to review?
• Can the review process keep pace with the number of changes?
• Which defects are being caught automatically?
• Are static-analysis warnings increasing?
• How much work is being generated compared with how much can be verified?
The organisation ends up with an impressive view of its AI agent and a poor understanding of its own engineering bottleneck.
It has instrumented the generator instead of improving the system that checks the generator's work.
Now reverse the mistake.
Suppose a team builds a disciplined development process around an AI customer-service agent. Every code change passes automated tests, static analysis, and strict merge checks.
Excellent.
But after deployment, a user discovers a way to manipulate the agent into producing an unsafe response.
The construction process may have been well controlled. The runtime behaviour wasn't.
Both teams invested in engineering controls. Both may have done excellent work.
They simply addressed the wrong problem.
The lesson isn't that one lifecycle is better than the other. It's that they solve different problems.
And choosing the right one starts with understanding what you're actually building.
Here's the interesting twist: one fits inside the other
At first, the two meanings look like competing approaches.
But there's a more useful way to understand their relationship.
Building an AI agent is still software development.
And if you're using coding agents to build that AI agent, you're doing both things at once.
You're using an agentic development process to build a product that itself needs an agent development lifecycle.
The first discipline doesn't replace the second. It adds another layer of responsibility.
Figure 1.2 — Building agents is also building software with agents.
The outer layer governs how the software is constructed. If that software is itself an AI agent, it also needs controls for its behaviour in production.
Alt text: A nested diagram showing the Agentic Development Lifecycle surrounding software under construction, with an AI agent as one possible product. The agent product adds runtime evaluation, monitoring, and security requirements without removing the need for construction-time controls.
This relationship matters because it changes how we learn from the two disciplines.
The agent-product world has developed useful practices for defining what successful behaviour looks like before implementation begins.
For example, evaluation datasets and clearly specified acceptance criteria help teams decide what an AI agent should do before they assess whether it does it.
Those ideas can also improve AI-assisted software development.
Instead of allowing an AI coding agent to write both the implementation and the tests that supposedly prove its correctness, teams can define expected behaviour independently and verify the generated changes against it.
That doesn't solve every testing problem. Writing good acceptance criteria for a complex existing codebase can be difficult.
But it gives us a valuable principle:
Define what success means before asking the AI to implement it.
We don't need to copy an entire discipline to benefit from its best ideas. We need to understand the boundary, then borrow deliberately.
The bigger idea behind this series
This distinction introduces a broader principle that will run through the chapters ahead.
AI-assisted software development is not simply traditional software development with a faster typing tool.
The way work gets produced has changed.
Tasks can be delegated to agents. Changes arrive at machine speed. Developers must supervise work they didn't personally produce line by line.
That means the engineering process must evolve around a different question.
Not just:
Can the agent produce the code?
But:
Can we reliably determine whether the code should be allowed into our system?
This is why the book describes agentic development as delegated execution under human supervision.
The agent performs the task. The human defines the boundaries, grants the appropriate authority, and ensures the result is checked.
The aim isn't to eliminate human judgment.
It's to reserve that judgment for the decisions that genuinely need it, while automating the checks that machines can perform consistently.
That is the foundation for everything that follows.
The most important question isn't how much code your AI can generate. It's how reliably your engineering process can verify what it generates.
Try this: find your randomness boundary
You don't need to redesign your development process today.
Start with one simple exercise.
Choose a project you're currently working on and answer these three questions:
- What is the AI doing? Is it operating as part of the product your users interact with, or is it helping your team build that product?
- Where can its mistakes escape? Can unexpected behaviour reach users directly, or can generated code be checked before it is merged?
- What catches those mistakes? List the automated checks, human reviews, and runtime monitors that are already in place. If your project involves both an AI-powered product and AI-assisted development, identify both boundaries separately. You may discover that your team has strong runtime monitoring but weak construction-time verification. Or you may have excellent automated checks but insufficient monitoring of an AI product after release. Either way, you now have a clearer starting point. You can improve the controls that match your actual problem instead of adopting every new practice labelled ADLC.
Read the full chapter
This post is a practical introduction to the distinction. The original chapter develops the argument in more detail, including the terminology, engineering consequences, and supporting references.
Read Chapter 1: Two Meanings of ADLC, and Why the Confusion Costs You
Next week: The Scaffolding Insight — why the real productivity gains from coding agents depend on more than the code they generate.
One question before you go:
When you hear “ADLC,” which problem do you think people are actually trying to solve — building AI agents, or building software with AI agents?
Share your experience in the comments.
If you'd like to follow the series, subscribe to receive the next chapter in your inbox.
Top comments (0)