Many banks have bought AI coding tools. Far fewer have changed how software is planned, reviewed and approved. That gap is where the next set of delivery problems will come from, and it is the subject of this six-part series on the AI-driven development lifecycle, or AIDLC.

A caution first, because the topic attracts a common confusion. Code written with AI is still ordinary code. Once it is written, reviewed and merged, it behaves exactly as hand-written code would: it is deterministic, and the tests, release and runtime work as they always did. The artifact is not what breaks. What strains is the lifecycle around it, which was designed for human authors working at human speed.

What the AIDLC is

The best-known formulation comes from AWS, which describes a methodology in which AI leads execution and people hold the decision rights: AI produces requirements, proposes designs, writes code and generates tests, and people supply business context, answer its questions and approve the work before it moves on[1]. In that formulation the lifecycle has three phases (inception, construction and operations), the team validates AI proposals in short working sessions rather than writing documents first, and the sprint gives way to shorter cycles called bolts.

You need not adopt that vocabulary. The useful idea is the shift in roles: AI drafts, humans decide. A bank's version has to add what a regulated firm needs on top, which is evidence of who approved what.

Five assumptions the SDLC makes, and AI strains

Writing code is the slow, expensive step. Planning, estimation and staffing models all assume it. When AI drafts code in minutes, the constraint moves to the two ends: knowing precisely what to build, and proving that what was built is right. A team that cannot state intent clearly now produces wrong software faster.

The sprint is the right planning cycle. Two-week sprints reflect how long humans take to build a slice of functionality. If a slice takes hours, planning ceremonies, backlog grooming and handoffs become the dominant cost. This is the rationale behind shorter cycles such as bolts.

Review gates are sized for human output. Code review, security scanning, change approval and testing capacity were set for the volume a team could write by hand. The 2025 DORA research on AI-assisted development found that AI adoption correlates with higher delivery throughput, and also with higher instability: more change failures and more rework[2]. It describes AI as an amplifier of whatever the organisation already does well or badly. Gates sized for the old volume become either a queue or a rubber stamp.

The author understands the code. Bank controls lean on an accountable developer who wrote the change and can explain it. When AI wrote it, a reviewer can approve code nobody present fully reasoned through. Accountability has to move from authorship to verification: a named person who owns the change and the evidence behind it.

The person who writes the tests understands the requirement. Developers have always written their own unit tests (the checks on individual pieces of code), and that was tolerable because their understanding of the requirement stood behind both the code and the tests. Independence came later, from QA, user acceptance testing and review. If the same AI writes the implementation and the tests, both can encode the same misreading of the requirement, and the tests pass. Segregation of duties, a long-standing bank principle, has to be applied earlier: acceptance tests that express the requirement must come from a source other than the code generator, such as the business owner, a tester or an independent tool.

When AI does the drafting, the scarce skills are specifying intent precisely and verifying the result, and the lifecycle must be rebuilt around them.

What an AIDLC looks like in a bank

I would keep the three phases and add the controls a bank needs.

  1. Inception: turn intent into verifiable requirements. The business owner states the outcome, constraints and what must never happen. AI helps break it into user stories and units of work, and the team corrects and approves them. Requirements are written to be testable, because they are now the primary input, not a document that gets stale.
  2. Construction: AI drafts, humans decide. AI proposes design, code and tests within the bank's standards, supplied as context: architecture patterns, security rules, approved libraries. Every change has a named human owner. Acceptance tests that express the requirement come from a source independent of the code generator.
  3. Operations: AI assists, evidence carries forward. In the AWS formulation AI also drafts deployment scripts, infrastructure code and monitoring. In a bank, AI-drafted operational changes go through the same gates as application code, and production actions such as releases, rollbacks and access changes stay with people. Each change carries its provenance: the requirement it satisfies, which tool and model produced it, who reviewed it and which tests it passed.

Three rules run across all phases. Decision rights are explicit: AI may propose, but only a named person approves intent, design and release. Risk tiering decides how much human attention a change gets, so a copy change and a payment-routing change are not treated alike. And the bank measures outcomes, such as lead time, change failure rate and rework, not volumes such as lines of code or changes generated. Part 2 of this series takes up measurement.

One change, end to end

Take a request from a bank's business payments team: raise the daily limit on same-day payments from £250,000 to £1 million for corporate clients that have passed enhanced due diligence, with a second approver required above £500,000.

Inception. The product owner writes the outcome and constraints in plain language. AI breaks the request into pieces of work: the limit check, the second-approver step, audit logging and client notices. It also asks the questions the request left open. Does the limit apply per account or per client? What happens to payments already queued under the old limit? The team answers them, and the product owner approves the work items and a short set of acceptance examples, the business's own statement of what correct looks like: a £600,000 payment from an eligible client with one approver is held for a second; the same payment from an ineligible client is rejected.

Construction. AI drafts the code and its unit tests within the bank's patterns. The acceptance examples, written by the product owner and a tester rather than by the AI, run against it. A named engineer reviews and owns the change. Because it touches payment limits, it sits in the highest risk tier, so a second reviewer from payments operations signs off and a security scan runs.

Operations. AI drafts the deployment configuration and an alert for unusual volumes of held payments. An engineer approves both, and a person, not the AI, releases the change. The change record links the requirement, the tools used, the reviewers and the test results, which is the evidence an auditor will ask for.

In the old lifecycle, most of the elapsed time went into writing and testing code. Here it goes into the questions at inception and the review in construction, which is where a bank wants its people's attention.

The tools are a risk in their own right

AI coding tools also bring risks that a bank's existing controls already know how to handle, provided someone applies them. The tool sees source code and sometimes data, so the bank must decide which repositories and environments each tool may access and what leaves the bank. The tool vendor is a third party and belongs in third-party risk management, with contract terms on data retention and model training. Generated code can contain security flaws or reference packages that do not exist, which attackers can register under the invented name, so dependency checks and security scanning matter more, not less. And the licensing and IP position of generated code needs a stated policy.

What most programmes get wrong

The common pattern is to roll out licences, run a productivity pilot and leave the lifecycle untouched. Developers write more code, review queues grow, change failure rises, and the programme concludes that AI "does not scale". The tool was not the problem; the process absorbed an output rate it was not built for.

The second pattern is the reverse: loosening review to "keep up". That is how a bank turns a throughput gain into an incident. The fix is to redesign the gates, with automated verification doing the volume work and human attention reserved for the decisions that carry risk.

A different problem: AI inside the workflow

None of this covers AI that runs inside a business process, such as a model that reads documents or drafts customer replies at run time. That component is probabilistic and needs evaluation rather than pass/fail testing, and US supervisors have left it to banks: the revised model risk guidance of 17 April 2026 states that "Generative AI and agentic AI models are novel and rapidly evolving. As such, they are not within the scope of this guidance"[3]. Keep it in a separate governance track from AI-assisted development.

What to do on Monday

  • Map your lifecycle to its human-speed assumptions. For each of planning cadence, review capacity, test coverage and change approval, record the volume it was sized for and what AI-assisted teams now produce.
  • Make every AI-assisted change traceable. Capture the requirement, the tool and model used, the human owner and the tests passed, in the change record.
  • Set an independence rule for tests. For risk-tiered changes, require acceptance tests (the business-level checks that a change does what was asked) that were not generated by the same AI that wrote the code.
  • Put the tools under existing controls: repository and data access, third-party risk review of the vendor, dependency and security scanning, and an IP policy for generated code.
  • Invest in requirements quality before buying more generation capacity: templates, testable acceptance criteria and a library of the bank's standards that AI tools can use as context.
  • Track outcome metrics from the start, including change failure rate and rework, so any throughput gain is visible alongside its cost.

The bank's challenge is not that AI-written code behaves differently once shipped. It is that a lifecycle built for human pace will either choke on AI output or wave it through. The next part of this series turns to the question that decides whether the redesign gets funded: how to measure AI delivery, from pilot adoption to P&L impact, and which popular metrics to drop.