From SDLC to AI-DLC: Coding Agents Are Only the Beginning

From SDLC to AI-DLC: Coding Agents Are Only the Beginning

Part 1 of a five-part series on the AI-Driven Development Lifecycle

Most engineering organizations have started using AI somewhere in the development process. A 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.

The more significant change starts when AI is no longer limited to helping a developer write code. What 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?

At that point, we are no longer discussing a better coding assistant. We are discussing a different development lifecycle. I refer to this as the AI-Driven Development Lifecycle, or AI-DLC.

AI-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.

This 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.

The laptop is no longer the natural boundary of development work

One of the clearest signals of this shift is the move from locally operated coding assistants to remotely hosted, long-running coding agents. AWS recently published a blog 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.

OpenAI 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])

The practical implication is important. A 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. That creates additional engineering capacity, but it also creates a management problem. If 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.

This is why I believe the current discussion around AI coding productivity is too narrow.

Coding is rarely the only constraint

In most enterprise programmes I have worked with, coding effort is only one part of the delivery problem. Delays usually come from a combination of issues:

• Requirements are incomplete when development starts.
• Business rules are buried in conversations and legacy documents.
• Architecture decisions depend on a small number of senior people.
• Non-functional requirements appear late.
• Test environments are unstable or unavailable.
• Security reviews happen after implementation.
• Teams discover integration dependencies during QA.
• Release evidence is collected manually.
• Ownership between product, architecture, engineering and operations is unclear.

A coding agent does not automatically solve any of these problems. In fact, it can make them more visible. An 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. Speed amplifies both good engineering and poor engineering.

The 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. That is the purpose of AI-DLC.

What I mean by AI-DLC

AI-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.

The phrase "AI-driven" should not be interpreted as "fully autonomous." There 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. Enterprise 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.

A better model is a controlled collaboration between people, agents and deterministic engineering systems. In that model:

• People define the business intent and remain accountable for decisions.
• Agents perform analysis and execution within bounded responsibilities.
• Independent agents challenge the work produced by other agents.
• CI/CD tools provide repeatable technical verification.
• Human owners approve decisions at defined risk gates.
• Production outcomes are used to improve the system.

This is a more substantial change than adopting an AI assistant. It affects process design, engineering platforms, architecture governance, security, testing, knowledge management and team responsibilities.

The lifecycle starts before code

A common mistake is to start an AI engineering programme with the repository. By the time a coding agent receives a ticket, many of the important decisions have already been made-or left unmade. The 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.

In a mature AI-DLC, the lifecycle starts with business intent. A 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. That does not make the agent the product owner. The 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. The value of the agent is that it gives the product owner a stronger starting point and makes gaps visible earlier.

Before 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. The agent that created an artifact should not be the only agent reviewing whether that artifact is complete. The Critique Agent looks for missing business rules, conflicting acceptance criteria, undefined failure behaviour, absent non-functional requirements and outcomes that cannot be tested objectively. This review takes place before the team incurs implementation cost.

Architecture must remain an explicit stage

There is a growing temptation to allow coding agents to infer architecture directly from the codebase. That is risky. A 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.

An Architecture Agent needs broader context:

• Existing architecture decisions
• System and service boundaries
• Data ownership
• API standards
• Security controls
• Tenant-isolation rules
• Operational requirements
• Cost constraints
• Approved technology patterns
• Known technical debt
• Architecture guidelines

Using this context, the agent can prepare an impact assessment and a proposed design. The 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.

The design then goes through architecture critique. The Critique Agent does not produce another design simply for the sake of disagreement. It actively searches for weaknesses in the proposal. For example:

• Has the design introduced a second source of truth?
• Is sensitive information being copied unnecessarily?
• Are permissions broader than required?
• Is failure isolation clear?
• Is rollback possible?
• Is the solution more complicated than the problem?
• Does the proposed technology fit the organization's operating model?
• Are audit and monitoring requirements covered?

This design–critique loop is one of the most important controls in AI-DLC. It is far cheaper to challenge a weak architectural decision before several agents implement it in parallel.

Agents need bounded work, not broad instructions

Once the requirement and architecture are approved, a Planning Agent converts them into executable work packages. This is where many early agent implementations are weak. An 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.

A proper work package defines:

• The expected outcome
• The allowed scope
• The repositories and components involved
• The interfaces that may change
• The acceptance criteria
• The tests that must pass
• The tools the agent may use
• The evidence it must return
• The conditions under which it must stop and escalate

The task should be large enough to create value but small enough to review. That 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. Agents require the same discipline, often more explicitly.

Parallel execution changes the economics of engineering

Once work is decomposed properly, several developer agents can operate at the same time and the orchestrator agent will decide sequential and parallel work stream. One 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.

This is where the productivity opportunity becomes material. The benefit is not only that one task is completed faster. The benefit is that activities previously performed sequentially can overlap.

However, parallelism introduces coordination risks. Two 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. The orchestration layer therefore needs to understand dependencies and shared assets. Parallel execution without dependency management will create merge conflicts, inconsistent designs and additional review overhead.

This is one reason I do not believe that "more agents" is automatically better.

The Critique Agent is not optional

The 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.

The producing agent must not be the only reviewer of its work. A 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.

An independent Critique Agent receives the original requirement, approved architecture, implementation plan, actual code changes, test results and security findings. It then reviews the change for:

• Functional gaps
• Architecture deviations
• Error-handling weaknesses
• Security issues
• Scope expansion
• Compatibility risks
• Missing tests
• Unnecessary complexity
• Operational concerns

The same principle applies across the lifecycle. A 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. These may be separate specialised agents or different review policies applied through a common critique capability.

The core principle remains the same: No material AI-generated engineering artifact should progress only because the agent that created it believes it is correct. Recent work on long-running development agents also points toward generator–evaluator structures, where planning, production and independent evaluation are separate responsibilities.

AI review does not replace engineering controls

It is important not to overstate what a Critique Agent can do. A 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.

AI-DLC therefore combines three forms of control:

• The Implementation Agent produces the change.
• The Critique Agent reviews it using context and judgment.
• Deterministic tools verify conditions that can be tested consistently.

Those tools still include:

• Compilation
• Unit and integration testing
• Contract testing
• Static and dynamic security testing
• Dependency scanning
• Secret scanning
• Infrastructure policy checks
• Performance testing
• Migration validation

None of these controls becomes less important because agents are involved. The opposite is true. As the volume and speed of generated changes increase, automated verification becomes more important. Human review then sits above these l