A team asks an AI assistant to build an approval workflow. The request sounds straightforward: staff submit a request, a manager reviews it, and the system records the outcome. An implementation can take shape quickly. The difficult questions emerge when someone asks what happens if the manager is absent, whether a requester can approve their own submission, and who is allowed to change a decision after it has been recorded.
Those questions belong to the development process regardless of who writes the code. AI changes how quickly an interpretation can become an implementation, which makes it useful to examine how that interpretation is established and checked. A fast coding tool does not, on its own, provide a reliable route from a business request to a service people can depend on.
What AI-DLC Means
AI-DLC stands for AI-Driven Development Lifecycle. In AWS's description of the methodology, AI takes an active role in planning, asking questions, and producing development artefacts, while people validate proposals and make critical decisions. Its scope extends beyond code completion to the work surrounding implementation.
AWS organises the approach into three phases. Inception develops business intent into requirements and units of work. Construction develops the design, implementation, and tests. Operations carries the accumulated context into infrastructure and deployment with human oversight. Collaborative practices called Mob Elaboration and Mob Construction bring the team into the clarification and validation process. Plans and decisions are retained in the project repository so later work can use them.
The term describes an approach to developing software with AI. The resulting application need not contain an AI feature. An ordinary approval service, reporting tool, or internal business application can be developed this way.
Starting With the Decisions Hidden in the Request
For the approval workflow, an initial requirements discussion should establish who can submit, review, delegate, and amend a request. It should also identify the outcome the organisation wants. Reducing the time spent chasing approvals is a different objective from introducing stronger controls over spending, even if both lead to a similar screen.
AI can help turn the discussion into questions, examples, and proposed acceptance criteria. The people responsible for the process need to resolve the underlying choices. If nobody knows whether a delegated manager can approve a high-value request, generating a plausible rule simply hides an unresolved decision inside the software.
That uncertainty should remain visible until an owner settles it. A useful record distinguishes agreed behaviour from an assumption and identifies which work depends on the answer. This gives the team a way to proceed on settled parts of the problem without presenting the whole specification as complete.
Context Needs Maintenance
Keeping requirements and design notes in the repository makes them available, but availability alone does not establish accuracy. A document can describe an earlier permission model while the code implements a newer one. An assistant given both needs a reliable indication of which decision applies.
Changes should therefore include the context needed to understand them. If the team removes delegation from the first release, that decision needs to reach the relevant requirements, tests, and implementation plan. Otherwise a later task may reintroduce it because an old document still describes it as required. The useful artefact is the one that helps someone make or verify a decision; producing more documents is not an outcome in itself.
Review Has to Challenge the Interpretation
A generated test suite can agree perfectly with an incorrect implementation. If the assistant assumes that any manager can approve any request, it may produce tests that confirm exactly that behaviour. Passing those tests demonstrates consistency with the assumption, while leaving the real access requirement unexamined.
Review should begin with examples that come from the agreed business rules. For this workflow, useful cases include:
- A requester attempting to approve their own submission
- A manager trying to access a request outside their authority
- Two reviewers acting on the same request at nearly the same time
- A failed notification after an approval has already been saved
These cases test consequences that a successful demonstration may never reveal. Reviewers still need to examine the implementation, but they have a clearer basis for deciding whether it does the right thing. Security, accessibility, and operational requirements belong in that basis too.
The amount of work submitted for review matters. A large generated change can exceed the team's ability to examine it meaningfully. Smaller units with clear acceptance criteria let reviewers connect the requirement, the implementation, and the evidence before moving on.
Adapting the Process to the Change
AWS's adaptive workflow approach describes adjusting the depth of the workflow to the task. That is a useful principle for adoption: a small correction should not automatically require the same planning exercise as a service redesign.
Teams can apply it by looking at the consequences of the change. Updating explanatory text may need a brief content check. Changing approval authority needs closer examination of permissions, existing records, and failure cases. The workflow should make those differences visible rather than turn every request into the same sequence of documents and approvals.
Operations Still Needs an Owner
An approval service is not finished when its tests pass. Someone needs to know how failed requests are detected, how changes are deployed, and how the service is recovered when a release causes a problem. If the implementation changes stored data, a rollback plan must account for that data as well as the application code.
AI can assist with deployment definitions, runbooks, and investigation, but the team needs evidence that these artefacts work in its environment. A generated recovery procedure that has never been exercised remains an unverified proposal. Operational ownership should be established while the service is being designed, when the team can still change decisions that would make it difficult to support.
Access boundaries matter here too. Permission to prepare a deployment should not silently become permission to change production. The team should define which actions are authorised, where a further decision is required, and what record will show what actually happened.
Measuring Whether the Lifecycle Improved
A useful pilot starts with a bounded change and follows it through review and use. Record how long it took to reach an accepted result, how much correction was required, and whether the people maintaining it can explain the important decisions. Compare that with the team's existing delivery process, including the effort spent supervising the assistant.
AI-DLC is worth evaluating on those outcomes. Faster generation can create an opportunity to improve delivery, but it can also move the bottleneck into review or carry unresolved assumptions further through the process. The benefit comes when the team uses the available speed to clarify, test, and deliver a change it understands well enough to own.