ADLC: Claude Code's New Lifecycle for AI Coding

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