The arrival of AI-powered software development was supposed to make one of technology’s oldest debates much simpler. If coding is now dramatically faster and cheaper, why shouldn’t banks simply build more software themselves?
The reality is proving far more complicated. Across financial services, engineering leaders are discovering that while AI has slashed the cost of writing software, it has simultaneously increased the importance, and cost, of proving that software can be trusted.
The bottleneck has shifted from code generation to code verification, making quality assurance one of the defining factors in the modern build-versus-buy decision.
Mudit Singh, co-founder and Head of Growth at TestMu AI, argued in recent blog post that developers using AI coding assistants are merging substantially more pull requests while time spent in code review has risen sharply.
Citing Google’s latest DORA research, he noted that AI “does not automatically improve software delivery performance. It amplifies what is already there.”
As Singh captured it: “The bottleneck in software has quietly moved. It used to be writing the code. Now it is trusting the code.”
For banks, this distinction matters more than almost any other industry. Unlike consumer technology companies, financial institutions cannot simply move fast and hope defects are caught later.
Every release potentially falls under operational resilience requirements, model governance, cyber resilience obligations and increasing regulatory scrutiny.
Under frameworks including DORA, the EU AI Act and similar supervisory initiatives emerging globally, software must not only work, it must be demonstrably tested, governed and auditable.
That changes the economics of build versus buy. For years, the argument for building software internally was compelling. Banks gained flexibility, retained intellectual property and avoided vendor lock-in.
AI coding assistants have strengthened that case by allowing internal teams to produce applications, APIs and automation at unprecedented speed.
Yet every line of AI-generated code carries an obligation to test it, validate it, secure it, document it and maintain it over many years.
The Financial Times newspaper recently highlighted how AI is exposing this hidden cost across the open-source software ecosystem.
Maintainers of critical projects such as cURL describe being overwhelmed by low-quality AI-generated contributions that require extensive human review. As the article concludes, writing software has become easier, while maintaining trusted software has become increasingly demanding.
“The bottleneck in software has quietly moved. It used to be writing the code. Now it is trusting the code.”
– Mudit Singh
That observation mirrors what many banking QA leaders are now experiencing internally. An AI coding assistant may generate a feature in minutes, but validating that feature across multiple channels, browsers, payment systems, regulatory scenarios and legacy integrations remains a human-led engineering challenge. In regulated financial environments, verification, not generation, is increasingly the expensive part.
This is where the traditional procurement calculation starts to break down. A licence for an AI coding assistant may appear inexpensive. Building an internal AI-powered testing platform on top of open-source frameworks can initially seem even cheaper than purchasing an enterprise testing platform.
But that comparison often ignores the largest cost: ownership. Singh argued that organisations frequently underestimate what happens after the first prototype.
A production-scale testing capability requires execution infrastructure, reporting, governance, dashboards, integrations, maintenance and continuous updates.
“The $19 AI coding agent subscription was never the full bill,” he wrote. “It was the down payment on a multiyear platform project.”
The result is that engineering teams end up maintaining two products: the banking application itself and the internal platform designed to test it. That maintenance burden is becoming one of the strongest arguments for buying rather than building.
Wider shift
Across the broader software industry, the consensus is increasingly shifting towards building only what genuinely differentiates an organisation while buying mature capabilities that have already been refined across thousands of implementations.
AI may have reduced the cost of creating software, but it has not fundamentally changed the long-term economics of maintenance, governance and operational ownership.
For banking QA teams, this distinction is becoming particularly important. A mature commercial testing platform increasingly delivers more than automated test execution.
It offers audit trails, governance, evidence collection, self-healing automation, cross-platform execution, root-cause analysis and integrations into enterprise delivery pipelines, all capabilities that regulators increasingly expect organisations to demonstrate.
Building these capabilities internally remains entirely possible. The question is whether they represent competitive advantage.
Banks rarely compete because they possess a proprietary regression-testing framework. They compete through customer experience, digital products, payments innovation and AI-enabled financial services. Every engineering team assigned to maintaining internal QA tooling is one that is not building customer-facing capabilities.
That does not mean buying is always the correct answer. Institutions with highly specialised trading platforms, unique regulatory environments or proprietary testing methodologies may still find strategic value in building significant elements of their own quality engineering capability.
Increasingly, however, many enterprises are moving towards a hybrid model: buying enterprise-grade testing foundations while extending them with custom automation, internal controls and institution-specific workflows, a strategy often described as “buy and extend” rather than simply “build or buy.”
For banking QA leaders, that hybrid approach may prove particularly attractive. Vendors provide the underlying testing infrastructure, while banks retain ownership of the controls, risk models and business logic that truly differentiate them.
Ultimately, AI has not eliminated the build-versus-buy debate. It has simply moved the discussion higher up the technology stack.
Generating software is becoming commoditised. Demonstrating that software is secure, resilient, compliant and fit for production is becoming the scarce capability.
For financial institutions operating under growing regulatory scrutiny, the question is no longer simply whether software can be built internally.
It is whether the organisation also wants to own the years of quality engineering, evidence generation and maintenance that follow. In the AI era, that may prove to be the most important architectural decision of all.
16 SEPTEMBER IN LONDON
REGISTER TODAY – SIMPLY CLICK HERE
Why not become a QA Financial subscriber?
It’s entirely FREE
* Receive our weekly newsletter every Wednesday * Get priority invitations to our Forum events *
REGULATION & COMPLIANCE
Looking for more news on regulations and compliance requirements driving developments in software quality engineering at financial firms? Visit our dedicated Regulation & Compliance page here.
READ MORE
- AI adoption strains JPMorgan testing
- Can banks ‘outsource’ AI accountability?
- HDFC Bank raises testing stakes
- Is observability banking QA’s next discipline?
- Barclays on AI testing, telemetry and kill switches
WATCH NOW
QA FINANCIAL PODCASTS
CLICK HERE TO LISTEN TO OUR EXCLUSIVE CONVERSATIONS
