How should AI-DLC be applied to production maintenance?

AI coding tools can increase code output immediately. They can also call plausible methods that do not exist, invent values that differ from the real status codes, and conclude that a change is complete. A build may pass in one repository while the tool misses effects on a connected frontend or batch job.

AI-DLC (AI-Driven Development Life Cycle) does not leave these problems to a model's attention alone. It turns the development lifecycle into a workflow in which AI creates plans, questions, and artifacts while people approve the critical decisions. The methodology AWS introduced in 2025 used three phases: Inception, Construction, and Operations.¹ The current v2 implementation adds Initialization and Ideation, expanding the lifecycle to five phases and 33 stages. Its 14-agent roster includes 11 domain experts, two review-only agents, and an adaptive-workflows composer.²³

AI-DLC is not a collection of prompts for generating better code. It selects the stages a task needs, records questions and artifacts at each stage, and makes human approval and verification prerequisites for moving forward.

AI-DLC is not a tool for producing more code

A typical AI coding tool shortens the path between a request and an output. AI-DLC inserts decisions and evidence into that path. It asks, stage by stage, whether the requirements are sufficient, whether the existing code was actually inspected, whether design and implementation remain connected, and whether testing and release preparation are complete.

The current v2 does not impose the same procedure on every task. A full feature uses all 33 stages, while the bugfix scope uses seven, refactor uses eight, and security-patch uses ten. Scope selects the stages, depth controls how detailed each artifact becomes, and test strategy is adjusted separately.⁴

Read the prerequisites before the AWS maintenance results

The LG CNS case published on the AWS Korea Technology Blog describes how AI-DLC was adapted for large-scale production maintenance.⁵ The most important details are not the 32 customizations, but the conditions that already existed before adoption.

• The target applications had been modernized, so AI could analyze their code structure.
• They used mainstream technology stacks whose patterns were easier for the model to understand.
• The environment had already passed security-governance review through prior use of Amazon Q Developer.

Without those conditions, a more elaborate workflow could still fail at the starting line. If teams cannot reproduce the build, lack regression tests, and keep business rules only in individual memory, AI merely processes the wrong context faster.

The problems in the case are also specific to production maintenance. The default workflow repeatedly asked about greenfield development and infrastructure design. The AI invented methods such as getUserName() and unverified code values. In an environment split across frontend, backend, and batch repositories, it changed the current repository without finding the impact on the others.⁵

LG CNS applied AI-DLC to 16 development change requests across five systems for one month. The post reports that all task types remained below standard effort and that repetitive work benefited more.⁵ It does not publish an exact savings rate, quality metric, control group, or independent reproduction. Those results show possibility, not an ROI estimate that another organization can reuse. An investment decision needs its own baseline and pilot evidence.

The DMM case shows where the bottleneck moves

DMM.com ran a two-day AI-DLC workshop from September 1, 2025, with four participating teams. Product managers, designers, and engineers decided requirements and implementation direction together. All four teams reportedly completed code generation and behavior verification.⁶

The more useful finding is DMM's diagnosis of the bottleneck. The company listed code review, knowledge transfer, testing and debugging, coordination, and communication as burdens in its existing process. It attributed the shorter workshop cycle not only to AI code generation, but also to real-time collaboration and reduced waiting between stages. AI-DLC does not remove approval work. It makes the response time of decision makers a governing constraint.

Treat the published figures as directional evidence. The effort table reports reductions from 4.5 person-months to 1–2 person-months, 10–14 person-days to 3–8 person-days, and two weeks to two days, with listed reductions ranging from 20% to 85%.

DMM's unresolved issues belong directly in a pilot design. Split work into small scopes, reserve decision-maker time, define how remote teams make shared decisions, and appoint a facilitator who helps the team learn the process. If only model-call speed improves, approval waiting time becomes the new bottleneck.

Adopt the principle, not a copied implementation

The AWS case keeps organization-specific changes in a separate layer instead of editing the upstream methodology. That principle still holds. Framework upgrades must not erase organization rules, and teams must be able to distinguish AWS source from internal policy.

The implementation must be reread for the version in use. The case layers company-wide, domain, and system overrides on Kiro Steering, Hooks, and Skills. Current AI-DLC v2 uses one harness-neutral core across Kiro, Claude Code, Codex CLI, Cursor, GitHub Copilot, and other harnesses. Its rules accumulate in a strict-additive org → team → project → phase → stage order. A lower layer does not silently replace an upper layer through an overrides block at runtime; conflicts are detected when rules are recorded.²⁷

Even the official repository presents different versions under one URL. The default main README announces 2.0 GA at the top, but the body still includes a three-phase Inception, Construction, and Operations workflow and an older installation model that copies legacy distribution files.⁸ The v2 branch describes five phases, 33 stages, a harness-neutral core, and dist/<harness>/ distributions.² Bookmarking only the repository root can lead a team to read the 2.0 concept while following installation instructions from the older structure.

It is safer to carry over these principles than to clone the sample directory and merge logic.

1. Do not modify methodology knowledge and agent files shipped by the framework.
2. Put company standards and project business knowledge in the team-knowledge layer.
3. Express mandatory behavior as rules and make mechanically testable outcomes sensors or tests.
4. Select the scope and approval level for each task.
5. Record the v2 branch, release or commit, and harness configuration, then run regression checks before an upgrade.

The v2 documentation also separates framework methodology knowledge from user-managed team knowledge. Team knowledge contains company coding standards, architecture principles, security policy, and test criteria that inform an agent's decisions.⁹ If behavior must be constrained, use rules and verification mechanisms instead of repeating the same knowledge.

Write five contracts before adoption

The following five contracts are not a list copied from official AI-DLC components. They reorganize the decisions a production-maintenance organization should make before a pilot.

1. Task-scope contract

Separate changes AI-DLC may handle from changes it may not. Start with work whose result is easy to verify, such as simple defect fixes, repetitive API changes, and test coverage. Preserve separate approval and manual execution for data migrations, broad permission changes, and irreversible production operations.

Attach a default scope, mandatory stages, and non-skippable checks to each work type. Do not select seven stages automatically because a ticket is called a bugfix. If it affects multiple repositories or a shared schema, restore the impact-analysis stage.

2. Context and evidence contract

Rank the evidence AI may trust. Put executable source, schemas, build configuration, and approved API specifications first. Treat stale wikis and old tickets as supporting material. If an identifier or code value cannot be confirmed in code, do not guess it. Leave an explicit review state such as [VERIFY_REQUIRED] or [CODE_VALUE_TBD].

Multi-repository environments need paths for finding API, shared database, event-topic, common DTO, and batch dependencies. A repository list alone is not enough. Write rules that say which change signal triggers analysis in which additional repository.

3. Approval and authority contract

Human approval is not a button that means an artifact was read. Separate requirement, implementation, and deployment decisions, and name their accountable owners. Also separate permission to read, edit files, call external systems, commit, and deploy.

AI-DLC v2 places an approval gate at the end of every stage except Initialization and records approval or revision requests in state and audit logs.¹⁰ Connect those gates to actual authority boundaries, such as dual approval for high-risk work, operating-hour limits, and prohibitions on production credentials.

More gates do not automatically create more control. As the DMM case shows, real-time decision-maker participation can accelerate flow. When approvers are occupied elsewhere, AI-generated artifacts accumulate in a queue.⁶ The contract should name not only the owner, but also response time, delegate, and shared review hours.

4. Verification contract

A verification contract must be more specific than “run tests.” Define pre- and post-change builds and tests, affected repositories, API and event contracts, data integrity, performance, and security thresholds for each work type. A check that could not be run remains unverified; it does not pass.

The first goal is not to increase the pass rate of AI-generated code. It is to stop a wrong change from reaching approval or deployment. Verification that halts the workflow and exposes a cause matters more than an agent that explains a plausible-looking result.

5. Evidence and learning contract

Connect the ticket, branch, questions and answers, design artifacts, code changes, test results, approver, and deployment result with one work identifier. AI-DLC v2 separates current position in intent-specific state files from the full event history in an append-only audit log.¹¹

Repeated corrections can become rules, but they should not be promoted automatically. Expanding one project's exception into an organization-wide rule can constrain other systems incorrectly. The v2 learning loop also records verified corrections at project scope by default and expands them to team scope only when a user chooses to do so.⁷

A 30-day pilot should test control before productivity

If the first pilot targets only “reduce development time by X percent,” teams will select only fast tasks. Production maintenance should first establish whether the same request can be repeated, a wrong assumption can be stopped in the middle, and a person can reconstruct why a decision was made.

Week 1 limits code generation to reveal how organizational documents and code mislead AI before implementation begins. Do not immediately turn every discovered problem into a company-wide rule. Decide whether it belongs in project knowledge or in a verification item.

As with the six gates for moving an AI PoC into production, the pilot review should end with go, conditional go, or stop. A conditional go names the permitted work types and repositories, approver, and expiry date. “Keep trying it” is not a verification plan.

The scorecard must cover flow, quality, control, and economics

Measuring AI-DLC by code output hides the burden carried by a production organization. Track human approval and rework time, the cost of recovering from a wrong impact analysis, and time spent assembling audit evidence under the same unit of work.

Do not import targets from another company's case. Compare with the same organization's existing baseline and segment by work type. When a pilot sample is small, record the conditions under which the approach helped instead of declaring a productivity gain. Track AI execution time together with approval waiting, decision participants, meeting time, and production defects.

Stop expansion in any of these situations.

• The build and regression tests cannot be rerun under the same conditions.
• The source of code, documents, and rules used by AI cannot be explained.
• An unconfirmed code value or nonexistent identifier enters code before verification.
• No owner is accountable for impact on other repositories and data contracts.
• Work that bypassed approval or audit records leads to a production change.

The first four conditions may not be solvable by changing agent configuration. They signal that the codebase and operating model themselves are not ready.

When modernization should come before AI-DLC

AI-DLC does not automatically understand undocumented legacy systems. It works best when code and builds are reproducible, change units and owners are visible, and teams can prove test and deployment results. That is why the AWS maintenance case lists application modernization and AI readability as prerequisites.⁵

Modernization does not have to mean a full rewrite. As described in our application modernization assessment and roadmap, begin by restoring dependency visibility, reproducible builds and tests, observability, and responsibility boundaries so the team can explain what the next change will affect.

Installing AI-DLC and then reshaping work around it reverses the order. First inspect the production organization's real change flow and cost of failure. Then write the five contracts, select only the required stages, and test controllability for 30 days. Individual prompts become an organizational development asset only when the resulting rules, knowledge, and verification items can be reused in the next system.

To design codebase readiness and a 30-day pilot before adopting AI-DLC, review AX Consulting. If reproducible builds and tests, dependency visibility, and operational ownership must come first, review Application Modernization.

References