ADLC: Claude Code's New Lifecycle for AI Coding

AAI LABS
컴퓨터/소프트웨어경영/리더십AI/미래기술

Transcript

00:00:00You have probably heard this again and again that software development has changed,
00:00:03but just adopting the new tools only covered the surface,
00:00:06because the systems being built today do not behave the way old software did.
00:00:10Therefore, the frameworks companies were building on also had to shift,
00:00:14because if you keep building on the old process, you will run into problems it has no way of solving.
00:00:18So in order to cater to this changing landscape,
00:00:21a new framework has emerged in the developer community that was built with agents in mind.
00:00:25And by the end of this video, we'll walk you through this new lifecycle framework
00:00:29and why you need to adopt it.
00:00:31For many years, software development has been carried out using the SDLC.
00:00:35The software development lifecycle is a structured process used through decades,
00:00:39containing multiple steps like design, development, testing, deployment, maintenance, and ongoing support.
00:00:45The whole idea behind it is that software should be developed with business goals and user requirements in mind,
00:00:51with the output of each phase becoming the input of the next.
00:00:54But this only worked until AI entered the technology space.
00:00:57Ever since AI started gaining traction, the first thing it started replacing was coding.
00:01:02Before AI, development was the system of writing code numerous times,
00:01:06often a repetitive process of merging snippets and logic from other places to build a system that solved the problem.
00:01:12So as models started getting better, and tools like Claude Code and Cursor started dominating the industry,
00:01:18the SDLC on its own has failed.
00:01:20It cannot sustain itself, and it needs to change in order to provide proper value.
00:01:24That is why the Agenic Development Lifecycle, or ADLC, was developed.
00:01:28It bridges the gap between SDLC and the current tech space.
00:01:32The ADLC was needed because in systems where SDLC was used,
00:01:36you already knew the behavior of the system at the time of planning, and there were ways to verify it.
00:01:41To put it simply, SDLC treats the software as a static piece, while ADLC treats it as a living system.
00:01:47Now since AI agents are unpredictable, and because they are actually the ones evolving by reasoning and adapting tasks
00:01:53to the environment they are in, it becomes hard to grade them on the same metrics traditional software uses.
00:01:59The whole reason ADLC was developed in the first place is the non-determinism of an AI agent in production.
00:02:05With AI agents, there is constant learning and continuous development,
00:02:09and you cannot determine what the agent's output will look like.
00:02:12When you are working with AI, the decisions you make depend on the prompt, the context, the models,
00:02:16and all the external tools you have connected.
00:02:18Models on their own are still unpredictable, so we cannot determine what a prompt will return with 100% accuracy.
00:02:25With that, you essentially have different success metrics from what SDLC uses.
00:02:29There are 7 phases of ADLC, and each phase maps to the exact SDLC phase in one way or another.
00:02:36Whether you are working on an agentic system or not, the first step always remains planning.
00:02:41What changes is how you do it.
00:02:43For agents, you cannot plan the way you would for non-agentic systems,
00:02:46because unlike traditional systems, the flow of logic does not apply the same way.
00:02:51So the first phase of ADLC, the preparation and hypothesis,
00:02:54aims at building a grounded understanding of the problem before committing to any system design or model.
00:02:59When it comes to agents, you need to understand how users will interact with the system
00:03:04and coordinate with all the stakeholders to find where the workflow breaks down
00:03:07and what the repeated manual effort looks like because this is what the agent will actually be solving.
00:03:12Then you review the existing workflows and policies to see how things are currently handled,
00:03:16and once that is clear, you form testable hypotheses on where the agents will assist or automate the workflow.
00:03:22If we skip this phase entirely, we would end up automating the wrong work,
00:03:26and instead of fixing the issue, it can make things worse.
00:03:28The difference compared to SDLC here is behavior.
00:03:31In SDLC, behavior could be predicted because the same input would always give the same output.
00:03:37But ADLC is probabilistic because of the model's involvement,
00:03:40and the same inputs can never lead to the exact same output.
00:03:43With this knowledge, the first step you need to do is turn on planning mode
00:03:47and have whichever agent you are using plan out the behavior of the agent you are developing, not the implementation.
00:03:52Prompt it not to think about code and instead map out the whole workflow,
00:03:56how the agents interact with users, what could go wrong, what overhead there may be,
00:04:00and all other assumptions about the system.
00:04:03That way, your agent building process starts with the core assumptions,
00:04:06which become a better guide than jumping straight into architecture planning.
00:04:10Once initial planning is done, there is another layer right after,
00:04:13where you identify the scope and the problem properly.
00:04:16This actually maps into the analysis phase or feasibility study of SDLC,
00:04:20where you used to analyze business requirements and whether the implementation was feasible.
00:04:25So this phase of ADLC maps into identifying the important processes and AI's role in solving them,
00:04:31marking out the constraints and technical boundaries,
00:04:33and defining clear business and technical KPIs upfront, like time, cost, latency, and feasibility.
00:04:39You also define the trade-offs at this point, knowing which factors are acceptable and which are not.
00:04:44But the most important part of this phase is mapping the human-agent responsibility model properly,
00:04:49because this creates an accountability structure.
00:04:52A human still needs to review them, because we cannot trust an agent with all decisions.
00:04:56By the end of this phase, you have proper documentation where workflow steps are explicitly defined with key KPIs,
00:05:02and the human-agent responsibility model is laid out clearly.
00:05:05This matters because in case of any failure, you cannot blame the model entirely.
00:05:09Accountability ultimately needs to remain with humans.
00:05:12Now this human responsibility planning was not needed previously, because there was no AI involved.
00:05:17It defines the agent's autonomy boundaries, and if you skip this step,
00:05:21you are risking your own compliance and accountability in production.
00:05:24To do this with agents, you again use the planning mode, prompting it to plan out workflows, latency, system issues,
00:05:30all the features that need to be in the architecture, and what failure could look like.
00:05:34Once these are stated clearly, the agent understands the right scope to iterate toward while building.
00:05:39With scope and high-level features defined, it is time to move to the design phase.
00:05:43In this stage, we are defining the system architecture for the agent itself.
00:05:47Here you decide what pattern the agent will follow, like react or plan an act or a multi-agent setup or whichever approach you want.
00:05:54Then you plan the data flow from one point to another, and this becomes much more crucial with the involvement of multiple agents.
00:06:00The agent should be getting the correct data, otherwise it will create issues instead of helping.
00:06:05You also plan out cost structures like the token economics, context editing features, compaction,
00:06:10and understand what the cost of deploying this agent to production will look like,
00:06:14and what will happen when it starts handling multiple users.
00:06:17Now this is also where you actually pick which models you want to use, which orchestration framework you are going with,
00:06:23the database, and all the other technologies involved, and it is here that you define what success will look like
00:06:28before any code is written, so you can build the agent with TDD.
00:06:32Before your system goes live, you have already considered the trade-offs in latency, accuracy, hallucinations, and similar issues.
00:06:38This phase also needs your agent's planning mode.
00:06:41You give it prompts to lay out a comprehensive design covering the agent architecture, data flow, cost model,
00:06:46and overall technical structure so that you move to the next step with a concrete plan.
00:06:51After the initial plans are done, the next step is simulation and proof of value.
00:06:55Here you use real-world data to test the assumptions you made in the earlier stages.
00:06:59You create prototypes so you can figure out whether it is worth moving further with building this agent.
00:07:04Basically, this is where you decide if you should develop the agent at all, because at this stage the cost of failure is much lower.
00:07:10So the core activities here include preparing the dataset or ground truth for behavioral testing,
00:07:15building prototypes so you can test the high-risk assumptions you documented previously,
00:07:19and validating data quality, hallucination rate, accuracy, response quality, and benchmarks.
00:07:25You also revisit the initial hypothesis to determine whether it will provide a return on investment.
00:07:30The deliverables are properly measured performance and cost baselines,
00:07:33along with the ground truth document mentioned earlier, which acts as a testing asset for regression testing and model fine-tuning.
00:07:40This phase acts as a validation gate.
00:07:42If your results move from here to the next stage, you can continue working on the agent.
00:07:46If not, the build is a failure, and discovering that early is much better,
00:07:50because if this thing made it into production, the damage would be far worse.
00:07:54To do this, you prompt your AI agent to create the first prototype so you can test it against all the planning you just did.
00:08:00But before we move forwards, let's have a word by our sponsor, Softer.
00:08:04Vibe coding tools are great for generating a UI, but the moment you need real auth,
00:08:08user roles, permissions, or a database that actually scales, everything falls apart and you're back to writing code.
00:08:14Softer is an AI app builder that handles all of that in one prompt.
00:08:18You describe what you need in plain English, and the AI co-builder generates the full stack, the database, the pages, the navigation, the login, and the role-based permissions all at once.
00:08:28These aren't prototype pages, they actually work.
00:08:30You can preview the app, check what each user role sees, and when you hit publish, your app is live with hosting, user groups, enterprise-grade security, and access control locked in.
00:08:40And you don't need a developer to maintain it.
00:08:42Everything is visual so you can update workflows, manage users, and add features yourself.
00:08:47The real cost of software isn't building it, it's maintaining it, and that's what Softer solves.
00:08:52Get your free AI credits by clicking the link in the description and get started.
00:08:57This marks the end of the planning phase, and it brings us to the part a lot of people jump straight into, which is implementation.
00:09:03The previous steps are really important because if you have done them properly, you will not run into the problems most people hit here from skipping those phases.
00:09:11So this is when you actually develop your agent, build the core logic, and orchestrate your development workflow.
00:09:16And here you see one of the clearest splits between SDLC and ADLC.
00:09:20In SDLC, the logic lives in code, configuration, and third-party dependencies.
00:09:25In ADLC, that logic spreads across code, prompts, models, tools, and external services.
00:09:30So you are not just managing software anymore, you are managing all of these layers together, and any one of them can change how the system behaves.
00:09:38If you have multi-agent systems to develop, one way to orchestrate your workflows is the new agent's view in Claude code.
00:09:44Using the agent's view, you can delegate tasks much better than with regular Claude usage.
00:09:49Because instead of managing different Claude code sessions, you manage a single orchestration layer and give the agent manager prompts to coordinate all the agents through it.
00:09:57Now at this point, you integrate tools like MCPs and APIs.
00:10:01For example, if you are building a personal assistant, you know it will need something like a Google Calendar MCP, Gmail MCP, and maybe a Notion MCP.
00:10:09And the most important thing here is context management.
00:10:11Because once you build an agent for production, it becomes one of the most critical aspects.
00:10:16Even the largest context windows available right now, like the 1 million token windows in Gemini and Opus, still require careful handling.
00:10:24You have to make sure the agent holds the correct memory and avoids context rot.
00:10:28Because if it ends up with too much irrelevant information, its attention spreads all over the place and the outputs get worse.
00:10:34You also need to test from the developer's side during this stage to ensure behavioral consistency after every change by manually validating the agent setup against the requirements.
00:10:44Development and validation are not separate in agentic systems.
00:10:48You cannot move forward without constant testing since even a small change can create a huge effect on the entire workflow.
00:10:54So you need developer level validation while building your agent side by side instead of relying only on a separate testing step later on.
00:11:01After you are done building your system, testing becomes the next phase.
00:11:05As mentioned earlier, testing needs to be ongoing during the building process, but once your system is built, you test it under production-like conditions rather than as individual components.
00:11:14This is the stage where you perform integrated testing.
00:11:16You also carry out user acceptance testing, where you collect feedback from actual users of the system and incorporate it back into the system.
00:11:24You test across multiple factors like bias, compliance, performance and other risk-related dimensions to ensure the release is safe before it goes live.
00:11:32And this is also where the success metrics shift completely.
00:11:35In SDLC, you measured functional correctness with tests that simply passed or failed.
00:11:40In ADLC, you measure accuracy distribution, hallucination rate and cost per outcome because none of those collapse cleanly into a single pass or fail.
00:11:48The testing paradigm itself moves with it.
00:11:50In SDLC, predefined tests validated known code paths.
00:11:54In ADLC, that becomes continuous evaluation of reasoning, safety and tool use because the agent does not run the same path twice in the same way.
00:12:02There are multiple evaluation frameworks like RAGAS and DPVAL, but the main thing that verifies correctness is how your data performs against the metrics you defined earlier.
00:12:12And there are several ways to test an agentic system, including functional, non-functional, structural and load testing.
00:12:18Each of these must be carried out thoroughly, often using agentic systems themselves so edge cases are identified properly and fixed before they reach production.
00:12:27Also, if you are enjoying our content, consider pressing the hype button because it helps us create more content like this and reach out to more people.
00:12:34Once your system is ready, it is time to deploy it and make it available for the real world.
00:12:39You do not deploy it directly and call it done because with agentic systems there is a lot more involved.
00:12:44For a normal system, deployment usually means pushing it to production and monitoring system health.
00:12:49For agentic systems, it is entirely different and here is where the meaning of deployment itself changes.
00:12:54In SDLC, deployment was the end of development and the start of a stable operating phase, the point where the software entered its steady years.
00:13:02In ADLC, deployment is the start of active monitoring and control, shaped by model updates, context drift and environment changes that keep moving even after you shift.
00:13:11So even though development may be complete, this stage is even more critical because you now have to actively monitor behavioral and system metrics.
00:13:19You also need alerting rules that constantly watch for quality, safety and performance issues so they can be caught early before they turn into large scale production errors.
00:13:28Deployment is essentially a controlled activation with continuous observation while real users interact with the system.
00:13:34Instead of only focusing on system health, you focus on behavioral performance so issues get caught early before they reach all users.
00:13:41In practice, you first release the system to a limited group of users and let them use it under real conditions.
00:13:46Then you observe how the agentic system responds over time before gradually rolling it out to everyone.
00:13:52After implementation has gone through all the processes, it becomes an ongoing cycle of maintenance, continuous learning and growth.
00:13:58This is an important stage because it keeps the agent accurate and aligned with real world needs.
00:14:03With traditional systems, feedback loops are relatively simple.
00:14:06A user reports a bug and a developer iterates on it and fixes it.
00:14:10With agentic systems, it is quite different because they are based on a continuous improvement process that does not stop at any point.
00:14:16The cycle keeps refining the model and all negative signals are fed back in so it can improve its behavior over time.
00:14:22This is typically done through UI signals like thumbs up and thumbs down to capture how the user feels after a response.
00:14:29Many production systems already use similar mechanisms like selecting between multiple outputs or ranking responses as seen in tools like ChatGPT or the feedback systems in Claude.
00:14:39These signals are then fed back into the agentic system so it can learn and iterate toward better performance.
00:14:44There is also periodic updating of data sources and embeddings to ensure the system stays current and does not suffer from outdated information.
00:14:52Alignment must be constantly monitored so safety and guardrails remain effective against all types of prompts, including risks like prompt injection.
00:15:00The key variables here are ongoing cost management, quality tracking, product improvement backlogs and model upgrades, all of which need to be continuously maintained to keep the system stable, safe and operational over time.
00:15:11That brings us to the end of this video.
00:15:13If you'd like to support the channel and help us keep making videos like this, you can do so by using the super thanks button below.
00:15:20As always, thank you for watching and I'll see you in the next one.

Key Takeaway

The Agentic Development Lifecycle (ADLC) provides a 7-phase framework designed to manage the probabilistic behavior, continuous learning, and human-accountability structures required by AI agents in production.

Highlights

  • The Agentic Development Lifecycle (ADLC) replaces the traditional Software Development Lifecycle (SDLC) to handle the non-determinism of AI agents in production.

  • ADLC shifts success metrics from binary pass/fail functional correctness to accuracy distribution, hallucination rate, and cost per outcome.

  • Logic in ADLC expands beyond code, configuration, and dependencies to spread across code, prompts, models, tools, and external services.

  • Context management remains critical even with 1 million token windows in Gemini and Opus to prevent context rot and degraded attention.

  • Deployment in ADLC marks the beginning of active monitoring for model updates, context drift, and environmental changes rather than the end of development.

Timeline

The Shift from SDLC to ADLC

  • Traditional software development lifecycles fail when applied to unpredictable, evolving AI agent systems.
  • SDLC treats software as a static piece with predictable inputs and outputs, while ADLC treats it as a living, probabilistic system.
  • Decisions in agentic workflows depend heavily on the prompt, context, models, and connected external tools.

Software development frameworks require a shift because systems built today do not behave like old software. Before AI, development relied on repetitive coding and merging snippets to achieve predictable behavior verified during planning. Because AI agents reason and adapt to environments dynamically, traditional metrics cannot accurately grade their output.

Phase 1: Preparation and Hypothesis

  • The first phase of ADLC builds a grounded understanding of the problem before committing to system design or specific models.
  • AI planning modes must map out workflow behavior, user interactions, and potential overhead instead of implementation code.
  • Skipping the preparation phase leads to automating the wrong manual workflows and worsens existing system issues.

Planning remains the first step for both traditional and agentic systems, but the methodology changes. Teams must coordinate with stakeholders to review existing policies and pinpoint exactly where workflows break down or require repeated manual effort. Because AI involvement makes outcomes probabilistic, developers must force the model to outline behavioral assumptions before architecture planning begins.

Phase 2: Scope Identification and Feasibility

  • Phase two maps out business and technical KPIs upfront alongside clear constraints and technical boundaries.
  • The human-agent responsibility model creates an accountability structure ensuring humans review critical agent decisions.
  • Explicitly defining trade-offs prevents entire blame from shifting to the model during an operational failure.

This phase maps directly to the analysis phase or feasibility study of traditional SDLC. Key performance indicators established here include time, cost, latency, and overall feasibility. Defining the boundaries of autonomy ensures regulatory compliance and forces the AI planning mode to account for latency and systemic failure risks during the early iteration cycle.

Phase 3: Architecture and System Design

  • System design defines the specific pattern the agent follows, such as react, plan-and-act, or multi-agent configurations.
  • Cost structures must incorporate token economics, context editing features, compaction, and multi-user scaling predictions.
  • Success definitions established during design allow developers to build the agent using Test-Driven Development (TDD).

Designing agentic architecture requires planning data flows meticulously from one point to another, which becomes highly critical in multi-agent environments to prevent corrupted inputs. This phase marks the selection of specific models, orchestration frameworks, and databases. Potential trade-offs regarding latency, accuracy, and hallucinations are completely analyzed before any functional code is written.

Phase 4: Simulation and Proof of Value

  • Simulation utilizes real-world data to test high-risk assumptions and determine if development should proceed.
  • The primary output of this phase is a ground truth document used for regression testing and model fine-tuning.
  • Validating performance early drastically lowers the overall financial and operational cost of failure.

This phase acts as a strict validation gate where prototypes face behavioral testing against collected datasets. Key metrics analyzed include data quality, hallucination rates, accuracy, response quality, and established benchmarks. If a prototype fails to demonstrate a return on investment at this stage, the project is terminated before entering costly production environments.

Phase 5: Implementation and Context Management

  • Agentic logic spreads dynamically across code, prompts, models, tools, and external services.
  • The agent view in Claude Code provides a single orchestration layer to manage and delegate tasks to multiple agents.
  • Context windows require careful handling to prevent context rot and widespread attention degradation.

Implementation clearly splits from SDLC because logic no longer lives solely in code and configurations. Developers integrate tools like Model Context Protocol (MCP) and APIs for services like Google Calendar, Gmail, and Notion. Development and validation happen side by side, demanding constant manual testing because a minor prompt adjustment can completely alter the final output workflow.

Phase 6: Integrated Testing and Evaluation Frameworks

  • Testing occurs under full production conditions rather than evaluating isolated, individual software components.
  • Continuous evaluation tracks reasoning, safety, and tool usage because agents rarely execute the exact same path twice.
  • Frameworks like RAGAS and DEEPVAL verify system correctness against historical behavioral metrics.

Testing paradigms shift away from traditional predefined tests that validate known code paths. User acceptance testing gathers direct feedback from real users to identify edge cases, while secondary testing addresses bias, compliance, and risk dimensions. Teams execute functional, non-functional, structural, and load tests, frequently utilizing secondary agentic systems to run the evaluations.

Phase 7: Deployment, Monitoring, and Continuous Learning

  • Deployment initiates active monitoring and control against model updates, context drift, and environmental shifts.
  • Alerting rules must actively track behavioral performance, safety, and quality metrics to catch large-scale errors early.
  • Negative signals and user interface feedback loops continuously refine the agent model post-launch.

In ADLC, deployment is not the end of development but a controlled activation characterized by limited canary rollouts to specific user groups. Ongoing maintenance relies on explicit user interface signals like thumbs up, thumbs down, or response ranking to capture sentiment. Systems require periodic updates to data sources, embeddings, and prompt-injection guardrails to manage long-term costs and maintain alignment.

Community Posts

No posts yet. Be the first to write about this video!

Write about this video