AI can compress implementation time, but delivery speed depends on what happens before and after code. A practical guide for financial institutions to redesign planning, verification and release controls without losing accountability.
AI can make implementation dramatically faster. The harder question is what happens to the rest of delivery when the code is no longer the slowest step.
For years, software plans have been built around a simple assumption: writing the code is the constraint. Estimates, team sizes, handoffs and release calendars all reflect the time it takes skilled people to turn an approved specification into working software.
AI coding agents are changing that assumption. They can draft an implementation plan, write a first version, run tests and explain a diff in a single working session. That does not make a product decision, a risk decision or a production release automatic. It moves attention to the work around the code.
Anthropic’s The AI-Native SDLC Playbook describes a six-stage lifecycle in which each stage leaves a written artifact for the next one. The framework is a useful way to think about process design. The examples in this article are illustrative scenarios, not a survey of banks or a claim about how most institutions currently work.
The central idea is straightforward: when the build accelerates, the bottleneck can move to planning, verification, review and deployment. Teams need to redesign those stages if they want faster delivery with clear accountability.
Consider a typical payments integration. A business need is raised, requirements are discussed, a specification is circulated, development begins, QA receives a batch of code, defects return, and a release waits for a scheduled change window. The exact timings vary by organisation; the sequence is common enough to recognise.
Now compress implementation. The requirements still need a decision. The specification still needs a named owner. A reviewer still needs time to assess the change. A deployment still needs the right evidence and approvals. If those steps keep their old queues and calendars, faster code generation changes where work waits rather than how quickly value reaches a customer.
This is why an AI tool inside an unchanged sprint often produces less improvement than expected. Speed at one stage is not throughput. Throughput depends on the whole path from intent to a monitored release.
The playbook’s stage names are familiar. The useful change is making the handoff between stages explicit and reviewable.
Plan. The person closest to the problem records a committed statement of intent: the customer or operational problem, the desired outcome, the systems affected, and the constraints. It is a versioned file with an owner, rather than a decision that exists only in a meeting.
Design. The intent becomes a specification. It includes the data flows, interfaces, failure modes, security and compliance constraints, and acceptance criteria. A product or service owner accepts the specification before implementation starts.
Build. The engineer asks the agent for an implementation plan that names the files, sequence and trade-offs. The plan is corrected and committed before code is generated. This makes the reasoning available to the next reviewer and gives the agent stable project context.
Test. Tests, builds and policy checks run throughout implementation. The agent can use them to catch obvious mistakes, but its own report is evidence to inspect, not an approval. Independent tests and checks should exercise assumptions the agent may have shared with the author.
Deploy. A pull request can receive an automated first pass for security, compliance and specification rules. A human reviewer then assesses intent, risk and evidence. Protected branches, required reviewers and deployment gates enforce who may approve and release.
Maintain. Monitoring detects drift, errors and changes in acceptable operating bands. A useful signal opens a new statement of intent, so production feedback enters the same loop rather than disappearing into an operations queue.
The resulting chain is clear: intent → specification → implementation plan → code diff → independent verification → approval record → deployment and monitoring evidence.
Versioned documents can support an audit trail, but a commit history does not automatically make an approval reliable. It does not prove that the approver had the right authority, that the evidence was complete, or that the person who built a change was separate from the person who released it.
Instructions given to an AI are also different from controls enforced by permissions and deployment gates. A prompt saying “do not modify payment limits” is guidance. A protected file, a policy check that blocks the diff and a release gate requiring a named approver are controls. Good teams use both, and they know which is which.
The same distinction applies to AI review. An agent checking its own work can repeat the assumptions that produced the work. A green test run can still miss an untested failure mode, a privacy issue or a requirement that was misunderstood. Independent verification should include separate test cases, static and dependency analysis, security checks, contract tests where integrations are involved, and a human review with authority to reject the change. For higher-risk changes, the reviewer and release approver should be different people, with access enforced by the repository and deployment system.
This makes governance more specific, not less. The questions become: what artifact is being accepted, what evidence supports it, who is authorised to accept it, and which system prevents the next step until that decision exists?
Imagine a FinSense delivery team helping a bank add beneficiary confirmation to a real-time payments integration. The scenario is hypothetical, but the artifacts are the kind a small pilot could produce.
Plan. The product owner writes: “Before a high-value transfer is submitted, show the beneficiary name returned by the bank’s account-verification service. The customer must be able to cancel. The service must not expose account details to logs.” The plan names the affected API, the risk owner and the success measure.
Design. The specification records the request and response contract, authentication method, timeout and fallback behaviour, data-retention rule, accessibility requirement and acceptance criteria. It also states that a timeout must stop submission rather than silently bypass confirmation. The product owner accepts this document; the engineer who will implement it is not the approver.
Build. The engineer asks the coding agent to propose a sequence: client change, server adapter, feature flag, audit event and tests. The engineer edits the plan, commits it, and lets the agent work in a branch with no production credentials. The diff is traceable to the accepted specification.
Test. The pipeline runs unit and contract tests, checks that logs redact account data, runs dependency and static analysis, and exercises timeout, mismatch and retry cases. A separate test owner adds a case for a provider returning a valid response with an unexpected character set. The agent reports its results, but the independent test suite and the test owner provide the verification decision.
Approve and deploy. A reviewer compares the diff to the specification and records the residual risk. A protected branch requires that reviewer and a separate release approver. The change is enabled for an internal cohort behind a feature flag, then expanded after the error rate and confirmation-abandonment rate stay within the agreed band. The deployment record links the commit, approvals, test evidence and feature-flag change.
Maintain. The dashboard tracks verification timeouts, name mismatches, duplicate submissions, support contacts and log-redaction failures. An alert creates a new intent artifact if a threshold is exceeded. The team can now explain not only what changed, but why it changed and how it behaves in production.
FinSense could test this approach with one low-risk payments integration over four to six weeks. Spend the first week recording a baseline from recent comparable changes, then run two delivery cycles with the artifact chain and enforced gates.
Measure:
cycle time from accepted intent to production availability;
review waiting time from pull request opened to first substantive review;
rework rate, measured by changes sent back for a missed requirement or failed check;
escaped defects and production incidents attributable to the change;
percentage of changes with a linked intent, specification, plan, independent test evidence and approval record;
policy exceptions, and the time needed to resolve them.
The pilot should report medians and ranges, with a short explanation for outliers. It should also record developer and reviewer feedback. The goal is to learn which queues and controls need redesign, not to declare that an agent made a particular percentage of a team faster.
If you engage a partner to build or maintain financial systems, ask:
Where are your guardrails encoded? A checklist and training help, but which rules are enforced automatically by repository, CI and deployment permissions?
What artifact trail comes with the work? Can the partner hand over intent, specification and approved plan, as well as code and a status report?
Who approves what, and how is it recorded? Identify the owner for business intent, technical design, test evidence and production release. Ask how segregation is enforced.
How is AI-generated code verified before human approval? Look for independent tests, builds, security checks and a review that can reject the agent’s conclusion.
What happens when the AI is wrong? Mature teams keep a record of failure modes, corrections and policy changes, then feed those lessons into the next cycle.
These are familiar outsourcing and change-management questions applied to a lifecycle that now includes an AI collaborator.
AI has not solved software delivery. Judgement about what to build, what risk is acceptable and what belongs in production remains human work, and regulated teams should keep that accountability explicit.
What has changed is where effort is scarce. Teams need clarity about intent, fast access to independent evidence, and the willingness to redesign review and release stages around the new constraint. A coding agent can help produce the artifacts, but it cannot grant authority, create a control, or make its own conclusion independent.
FinSense Africa helps banks and financial institutions move from complexity to clarity across engineering, DevSecOps and digital transformation. If you are working through what AI-native delivery means for your institution’s governance and delivery model, we would welcome the conversation.
The six-stage framework described here is Anthropic’s, from The AI-Native SDLC Playbook. The interpretation, hypothetical FinSense example and pilot measures are ours. This article is educational and does not replace an institution’s legal, regulatory or security review.
Written by
Abdulshakur Abubakar
Take the first step towards simplified digitization and enhanced efficiency. Let's work together to create lasting value for your organization.
Alignment Meeting to scope out your requirements
Official confirmation of engagement for specific services
Project starts with pre-defined deliverables and SLAs