{"slug": "from-sdlc-to-ai-dlc-coding-agents-are-only-the-beginning", "title": "From SDLC to AI-DLC: Coding Agents Are Only the Beginning", "summary": "A developer introduces the concept of the AI-Driven Development Lifecycle (AI-DLC), arguing that the real opportunity lies not in using AI for coding assistance but in redesigning the entire delivery lifecycle around agent capabilities. The article notes that coding agents are becoming managed workers, as seen with AWS and OpenAI, but warns that without addressing bottlenecks in requirements, architecture, and validation, faster code generation can amplify poor engineering.", "body_md": "*Part 1 of a five-part series on the AI-Driven Development Lifecycle*\n\nMost engineering organizations have started using AI somewhere in the development process.\n\nA developer uses it to understand an unfamiliar class. Another uses it to generate unit tests. Someone else asks it to fix a static-analysis finding or prepare a first draft of a pull request.\n\nThe more significant change starts when AI is no longer limited to helping a developer write code.\n\nWhat happens when agents can analyse requirements, inspect an existing architecture, prepare an implementation plan, work on several engineering tasks in parallel, run tests, review code, identify security gaps and assemble release evidence?\n\nAt that point, we are no longer discussing a better coding assistant.\n\nWe are discussing a different development lifecycle.\n\nI refer to this as the **AI-Driven Development Lifecycle, or AI-DLC**.\n\nAI-DLC is not a replacement for SDLC. It is the next operating model for it: one in which humans remain accountable for business and engineering outcomes, while AI agents take on a meaningful share of the analysis, execution, review and validation work.\n\nThis is the first article in a five-part series in which I will explore what that model looks like in practice, where it creates value, where it introduces risk and how engineering leaders can adopt it without losing control.\n\nOne of the clearest signals of this shift is the move from locally operated coding assistants to remotely hosted, long-running coding agents.\n\nAWS recently published a [blog](https://aws.amazon.com/blogs/machine-learning/its-safe-to-close-your-laptop-now-hosting-coding-agents-on-amazon-bedrock-agentcore/) in which several coding agents were run in parallel, each with an isolated environment, persistent workspace, controlled tool access and central observability. The article was written around an AWS service, but the broader point is not AWS-specific: coding agents are becoming managed workers rather than temporary sessions running inside a developer’s laptop.\n\nOpenAI has taken a similar direction with Codex, positioning it as a cloud-based software engineering agent that can work on multiple assignments in parallel. Its later desktop experience is explicitly designed as a command centre for long-running agent work rather than a conventional editor extension. ([OpenAI][2])\n\nThe practical implication is important.\n\nA developer can assign one agent to investigate a defect, another to update tests, another to analyse a dependency upgrade and another to review documentation. These activities can continue without occupying the developer’s primary workstation.\n\nThat creates additional engineering capacity, but it also creates a management problem.\n\nIf four agents can generate changes faster than the team can review requirements, validate architecture, test integrations or approve releases, then the organization has not improved delivery. It has simply moved the bottleneck.\n\nThis is why I believe the current discussion around AI coding productivity is too narrow.\n\nIn most enterprise programmes I have worked with, coding effort is only one part of the delivery problem.\n\nDelays usually come from a combination of issues:\n\nA coding agent does not automatically solve any of these problems.\n\nIn fact, it can make them more visible.\n\nAn agent working from a weak requirement will produce a weak implementation more quickly. An agent operating without current architecture context may introduce another source of truth, bypass an established integration pattern or add a dependency that the organization cannot support.\n\nSpeed amplifies both good engineering and poor engineering.\n\nThe real opportunity is therefore not to insert AI into coding. It is to redesign the complete delivery lifecycle around the capabilities and limitations of agents.\n\nThat is the purpose of AI-DLC.\n\nAI-DLC is an engineering operating model in which specialised AI agents participate across the lifecycle under explicit human accountability, controlled access, independent review and deterministic quality gates.\n\nThe phrase “AI-driven” should not be interpreted as “fully autonomous.”\n\nThere will be organizations that attempt to build a single agent that receives a feature request and independently modifies production. That may work for tightly bounded and low-risk scenarios. It is not a credible general operating model for enterprise software delivery.\n\nEnterprise delivery involves product judgment, architecture trade-offs, regulatory obligations, operational risk and decisions that cannot be delegated to a model merely because it can generate working code.\n\nA better model is a controlled collaboration between people, agents and deterministic engineering systems.\n\nIn that model:\n\nThis is a more substantial change than adopting an AI assistant.\n\nIt affects process design, engineering platforms, architecture governance, security, testing, knowledge management and team responsibilities.\n\nA common mistake is to start an AI engineering programme with the repository.\n\nBy the time a coding agent receives a ticket, many of the important decisions have already been made—or left unmade.\n\nThe requirement may not define failure behaviour. Data ownership may be unclear. Security requirements may be missing. Acceptance criteria may describe the happy path but ignore permissions, retries or partial failures.\n\nIn a mature AI-DLC, the lifecycle starts with business intent.\n\nA Requirement Agent can help a product owner convert a request into a structured engineering requirement. It can identify ambiguity, suggest missing scenarios, highlight assumptions and propose acceptance criteria.\n\nThat does not make the agent the product owner.\n\nThe agent does not know which customer commitment takes priority, which commercial constraint matters most or which compromise the business is willing to accept. Those remain human decisions.\n\nThe value of the agent is that it gives the product owner a stronger starting point and makes gaps visible earlier.\n\nBefore the requirement moves forward, a separate Critique Agent reviews it. This separation is essential to ensure another view and this is quite similar to our architecture review by a senior resource.\n\nThe agent that created an artifact should not be the only agent reviewing whether that artifact is complete.\n\nThe Critique Agent looks for missing business rules, conflicting acceptance criteria, undefined failure behaviour, absent non-functional requirements and outcomes that cannot be tested objectively.\n\nThis review takes place before the team incurs implementation cost.\n\nThere is a growing temptation to allow coding agents to infer architecture directly from the codebase.\n\nThat is risky.\n\nA repository tells an agent how the system has been implemented. It does not always explain why it was implemented that way, which constraints are still valid or which historical decisions the organization is trying to reverse.\n\nAn Architecture Agent needs broader context:\n\nUsing this context, the agent can prepare an impact assessment and a proposed design.\n\nThe human architect remains accountable for the decision, but the agent can remove a considerable amount of analysis effort. It can trace dependencies, locate related decisions and compare the proposal with established standards.\n\nThe design then goes through architecture critique.\n\nThe Critique Agent does not produce another design simply for the sake of disagreement. It actively searches for weaknesses in the proposal.\n\nFor example:\n\nThis design–critique loop is one of the most important controls in AI-DLC.\n\nIt is far cheaper to challenge a weak architectural decision before several agents implement it in parallel.\n\nOnce the requirement and architecture are approved, a Planning Agent converts them into executable work packages.\n\nThis is where many early agent implementations are weak.\n\nAn instruction such as “implement this feature” leaves too much room for interpretation. A long-running agent may touch unrelated files, redesign existing behaviour or make assumptions that were never approved.\n\nA proper work package defines:\n\nThe task should be large enough to create value but small enough to review.\n\nThat is very similar to managing human engineering work. We do not give a new engineer unrestricted access and say, “Improve the platform.” We define the outcome, the boundaries and the review expectations.\n\nAgents require the same discipline, often more explicitly.\n\nOnce work is decomposed properly, several developer agents can operate at the same time and the orchestrator agent will decide sequential and parallel work stream.\n\nOne agent may update a backend service while another updates the client. A third can prepare tests. A fourth can assess a migration. A fifth can update technical documentation.\n\nThis is where the productivity opportunity becomes material.\n\nThe benefit is not only that one task is completed faster. The benefit is that activities previously performed sequentially can overlap.\n\nHowever, parallelism introduces coordination risks.\n\nTwo agents may modify the same API contract. One may make an assumption that invalidates another agent’s work. A database change may be completed before the compatibility strategy is agreed.\n\nThe orchestration layer therefore needs to understand dependencies and shared assets.\n\nParallel execution without dependency management will create merge conflicts, inconsistent designs and additional review overhead.\n\nThis is one reason I do not believe that “more agents” is automatically better.\n\nThe Critique Agent will be a central topic in the third article of this series, but it needs to be introduced here because it is one of the defining differences between casual AI use and an engineered AI-DLC.\n\nThe producing agent must not be the only reviewer of its work.\n\nA coding agent can certainly run a self-review. That is useful. But it will often carry the same assumptions and blind spots into the review that it used during implementation.\n\nAn independent Critique Agent receives the original requirement, approved architecture, implementation plan, actual code changes, test results and security findings.\n\nIt then reviews the change for:\n\nThe same principle applies across the lifecycle.\n\nA Requirement Critic reviews requirements. An Architecture Critic reviews designs. A Code Critic reviews implementation. A Test Critic evaluates test quality. A Release Critic reviews the final evidence package.\n\nThese may be separate specialised agents or different review policies applied through a common critique capability.\n\nThe core principle remains the same:\n\nNo material AI-generated engineering artifact should progress only because the agent that created it believes it is correct.\n\nRecent work on long-running development agents also points toward generator–evaluator structures, where planning, production and independent evaluation are separate responsibilities.\n\nIt is important not to overstate what a Critique Agent can do.\n\nA model may identify a logical weakness that a static-analysis tool cannot see. It may also miss a known vulnerability that a scanner would detect immediately.\n\nAI-DLC therefore combines three forms of control.\n\nThe Implementation Agent produces the change.\n\nThe Critique Agent reviews it using context and judgment.\n\nDeterministic tools verify conditions that can be tested consistently.\n\nThose tools still include:\n\nNone of these controls becomes less important because agents are involved.\n\nThe opposite is true.\n\nAs the volume and speed of generated changes increase, automated verification becomes more important.\n\nHuman review then sits above these layers, focusing on trade-offs, business impact, exceptions and risk acceptance.\n\nMuch of the discussion around agent performance focuses on model selection.\n\nModels matter, but context is usually the larger organizational issue.\n\nAn engineering agent needs more than source code.\n\nIt needs access to the current requirement, architecture decisions, coding standards, API conventions, data definitions, security policies, test patterns and operational expectations.\n\nMost organizations do not maintain this information consistently.\n\nImportant decisions live in meeting notes. Architecture diagrams are outdated. Business rules are known by a few senior people. Repository documentation does not reflect the current implementation.\n\nAI-DLC exposes this weakness very quickly.\n\nA strong model with incomplete context will still make poor decisions.\n\nAnthropic describes context engineering as the ongoing discipline of deciding what information, tools, history and state should be available to an agent during execution. That is a better description of the problem than “prompt engineering.” ([Anthropic][5])\n\nFor engineering leaders, this means documentation and architecture governance are no longer administrative activities.\n\nThey become part of the runtime environment for agents.\n\nArchitecture Decision Records, API contracts, repository instructions and approved patterns must be accurate enough for both people and machines to use.\n\nOrganizations with disciplined engineering knowledge will adopt AI-DLC faster than organizations that depend on tribal knowledge.\n\nA coding agent is not simply generating text.\n\nIt may execute commands, access repositories, read files, call APIs and modify infrastructure definitions.\n\nThat gives it a meaningful blast radius.\n\nRunning such an agent directly in a developer’s normal environment with permanent credentials is not an enterprise operating model.\n\nAgents need isolated execution environments, scoped access and traceability.\n\nAt minimum, the platform needs:\n\nThe AWS example that prompted this article emphasises this surrounding control plane: isolated sessions, identity-aware tool access, credentials held outside the agent environment and central observability. These are not unique product features; they are useful architectural requirements for any managed coding-agent platform.\n\nThe objective is not to claim that an agent environment is risk-free.\n\nThe objective is to know who initiated the work, what the agent was allowed to access, what it changed and how its access can be revoked.\n\nI do not believe AI-DLC removes the need for strong engineers.\n\nIt changes where their time creates the most value.\n\nDevelopers will spend less time producing routine code line by line. They will spend more time understanding intent, defining boundaries, reviewing design, supervising execution and resolving difficult failures.\n\nArchitects will spend less time producing the first draft of every diagram. They will spend more time defining principles, reviewing trade-offs and governing exceptions.\n\nQuality engineers will spend less time manually repeating predictable test steps. They will spend more time improving test strategy, designing evaluation datasets and identifying where generated tests are giving false confidence.\n\nSecurity teams will define enforceable policies, tool permissions and evidence requirements rather than reviewing every change at the end of the process.\n\nEngineering managers will need to manage capacity differently. Their delivery system will include people, agents, deterministic automation and external platforms.\n\nThis will require new skills.\n\nThe best engineer will not necessarily be the person who writes the most code. It may be the person who can define a problem clearly, divide it intelligently, provide the right context and judge whether the resulting system is genuinely production-ready.\n\nOrganizations should not begin by attempting to automate their entire SDLC.\n\nThat would be a weak approach.\n\nThe better starting point is one repeatable, bounded engineering workflow with reliable tests and manageable risk.\n\nExamples include:\n\nThen introduce a controlled producer–critic–verifier workflow.\n\nThe key metric is not lines of code generated. It is the number of useful changes that reach production safely, with less effort and no deterioration in quality.\n\nThat is the difference between a demonstration and an operating model.\n\nThe leadership decision is whether that usage remains fragmented and dependent on individual behaviour, or becomes a controlled engineering capability.\n\nFragmented adoption will produce some productivity improvement, but it will also create inconsistent practices, duplicated cost and limited traceability.\n\nA well-designed AI-DLC can create something more valuable:\n\nBut this will not happen by purchasing a coding assistant and declaring success.\n\nIt requires changes to process, architecture, engineering platforms, security, testing, knowledge management and leadership accountability.\n\nCoding agents are the visible part of the change.\n\nThe larger shift is the redesign of the software delivery system around teams of humans and agents.\n\nIn Part 2, I will describe the practical multi-agent operating model behind AI-DLC.\n\nI will cover the roles of requirement, architecture, planning, implementation, testing, security, release and critique agents; how work moves between them; where parallel execution makes sense; and where human ownership must remain explicit.\n\nThe focus will remain practical.", "url": "https://wpnews.pro/news/from-sdlc-to-ai-dlc-coding-agents-are-only-the-beginning", "canonical_source": "https://dev.to/aws-builders/from-sdlc-to-ai-dlc-coding-agents-are-only-the-beginning-3n6f", "published_at": "2026-07-13 07:15:38+00:00", "updated_at": "2026-07-13 07:16:30.521419+00:00", "lang": "en", "topics": ["artificial-intelligence", "ai-agents", "developer-tools", "ai-infrastructure", "ai-products"], "entities": ["AWS", "OpenAI", "Codex", "Amazon Bedrock"], "alternates": {"html": "https://wpnews.pro/news/from-sdlc-to-ai-dlc-coding-agents-are-only-the-beginning", "markdown": "https://wpnews.pro/news/from-sdlc-to-ai-dlc-coding-agents-are-only-the-beginning.md", "text": "https://wpnews.pro/news/from-sdlc-to-ai-dlc-coding-agents-are-only-the-beginning.txt", "jsonld": "https://wpnews.pro/news/from-sdlc-to-ai-dlc-coding-agents-are-only-the-beginning.jsonld"}}