In May 2026, an National Bureau of Economic Research (NBER) study of more than 100,000 developers delivered the cleanest number yet on AI and software: coding activity rose by up to 180% with AI agents — while actual software releases rose just 30%. Code is now being written by more people, faster, than ever before, including people who could not have written it two years ago. What has not accelerated is everything around the code: review, QA, synchronisation, accountability. AI has changed the price of writing software. It has not changed the price of shipping and owning it. On top of that, it certainly hasn't changed the level of scrutiny with which a regulator looks at your Sustainable Finance solutions.
If you do not read the whole article, just read this section!
The below table summarises the holistic needs for a successful software product delivered for financial institutions. Vibe coding makes the top two lines of this table feel free. For a business focused subject matter expert (SME) building directly, line 1 genuinely can be. But when you insource a build, you sign off on all ten and you take responsibility for all. Something a Head of Responsible Investing usually can’t.
A 2026 Team8 survey found 81% of North American banks have revised their build-versus-buy thinking because of AI, and in Mercer’s February 2026 survey of 131 asset managers, 91% plan to increase AI usage this year. There is also a genuine prototype experience driving this: Stanford’s research puts AI productivity gains at 35–40% on simple, greenfield tasks. On complex legacy code, the gain drops to 10% or less. Sustainable finance software today usually is part of this established legacy base.
We experienced this at WeeFin ourselves. We deliberately put AI building tools in the hands of the whole company, and coding activity rose exactly as the NBER data describes. Most of it from contributors who could not have written that code before. Product managers ship working mock-ups instead of specifications; front-end developers cross into back-end code and vice versa; sales and client teams build their own assistants and automations. Some developments would have consumed a quarter of the roadmap five years ago. And we would not want to reverse any of it today. We also experienced how it is easier to build from scratch and how hard it can be for the AI tools to build on top of an already complex system. Something that often gets overlooked at the beginning of a project.
But the wider limitations arrived on schedule: First tools break in ways their builders cannot diagnose. Prototypes lingered past their design intent, every tool that mattered landed on engineering’s desk for review, things broke silently when data models changed, and nobody had asked the security questions at build time. We identified these problems early and could solve them. Not solving them automatically results in a risk that is not mitigated. But as expected the solution is not cheap and the pressure lands back with experts in the development team.
In the long run even more significant problems show up. A key fundamental principle in software is system integrity published by Brooks (1975) in “The Mythical Man-Month”. It is clear that a few developers with a system that connects strongly together can create more value than a huge team. This is where vibe coded solutions break today. Each and every piece of software is strong for itself, but does not consider the rest to the degree a developer or architect would do today. Especially, in complex areas like Sustainable Finance this creates a massive limitation and a mid term risk that is barely manageable.
Maintenance accounts for 60–80% of a system’s lifecycle cost (IEEE analyses; Robert Glass’s ‘60/60 rule’), and roughly three-quarters of total cost of ownership accrues after launch. Banks spend up to 70 cents of every IT dollar maintaining legacy systems (McKinsey, 2024). When financial institutions build, they overrun: 45% over budget on average, delivering 56% less value than promised (McKinsey–Oxford, 5,400+ projects). And AI-written code is more expensive to own, not less: duplicated code is up 81% since 2023 while refactoring has fallen 70% (GitClear), and between 25% to 45% of AI-generated code introduces OWASP Top 10 vulnerabilities (Veracode and AppSecSanta). Gartner predicts 40% of AI-augmented coding projects will be cancelled by 2027.
Our own product organisation confirms this daily. On a complex product, the journey from idea to shipped feature is dominated by specifying, prioritising, testing and validating. Writing the code was always the final slice. AI has compressed that slice and left the rest largely untouched. We experiment with different models a lot. What we have seen is that an SME today can build a vibe coded tool from scratch, without writing specs. It is because the SME knows what is required. But when it comes to making that tool market ready, especially for data heavy requirements, a development team is required. And while the code writing part of this industrialisation process runs faster today, it still requires review, QA and all follow up processes to ensure a quality that is strong enough for the financial industry.
In Retool’s 2026 survey of 307 technology leaders, 44% had no clear default accountability for incidents caused by AI-built tools, and only 8% called their internal-tool governance strong. Finance has seen this film before. Over 90% of spreadsheets contain errors. Some people might still remember the VaR model that meant to catch JPMorgan’s $6.2 billion ‘London Whale’ loss. It ran on copy-pasted Excel with a formula that halved reported volatility (per the bank’s own 2013 task force report) and caused a misunderstanding of the underlying risk. The AI-era sequels are already showing: an AI agent deleting a production database despite a code freeze (Replit, 2025), 38 million records exposed through low-code default permissions, and breaches involving ‘shadow AI’ costing an average $670,000 more (IBM, 2025).
In finance, the regulator settles the ownership question for you. DORA’s technical standards apply development, testing and source-code review obligations to systems ‘developed or managed by users outside the ICT function’. The SME’s AI-built app is in scope by name and by regulation must follow governance principles. There is a volume effect here that deserves more attention than it gets: every internal tool adds an ICT asset to identify, classify and document, testing evidence to produce, and an annual review to run. When AI multiplies the number of internal tools, it multiplies the DORA surface with them. They are cheap to build, expensive to keep. For the UK the PRA’s SS1/23 covers all models ‘whether developed in-house or externally’, with a named senior manager personally accountable. Buying doesn’t transfer that accountability, but it transfers the burden of evidence, amortised across hundreds of clients. Building means the whole stack lands on you, per tool, forever.
An important addition to the raw underlying regulation is also the topic of trust. Regulators are in no position to review every single in house built solution. But they build trust with certain vendors over time. Especially, in a highly regulated field like Sustainable Finance, where regulations change very frequently this trust is a driving element of a build or buy decision. As regulations in this space are often politically driven and ambiguous, the human expertise allows us to weigh the necessary decision criteria.
At WeeFin we took the decision that every SME initiated tool has to fulfil the quality standard. Every tool has to be transferred into a team capable of understanding the underlying code that was written. Without this transfer of ownership, developed models and tools won’t hold an audit under the PRA or DORA rules.
All this still leaves us with the build or buy decision and a way to understand what might be best.
In areas that are less data heavy and where your new build is complementary, starting with a vibe coded solution works well. It helps to drive a strong understanding of what is actually needed and what is not. But it also creates a risk of creating features and solutions that in real life will never work. For complex, highly regulated and strongly data-driven areas such as Sustainable Finance you risk running into a self build project that could easily take several years. While the regulator might have doubts about the final outcome. Being specialised in Sustainable Finance gives us insights into what works from a technical perspective and how to prevent costly and time consuming mistakes.
So, having that in mind, AI does not change the general decision. It still holds true: Build where your proprietary data and workflows compound into an advantage nobody else can replicate. Buy where the vendor sees more transactions, edge cases and regulatory change than any single firm ever will. Build where you see more edge cases than anyone else. Buy only if you can internally build on the results of what you buy.
At WeeFin, our teams build freely at the prototype layer, engineering owns anything touching client data or a regulated process, and we buy what is not ours to be excellent at. Before a single prompt is written, ask six questions:
One honest correction to the fashionable framing, from our own experience: AI genuinely lowers the cost of writing code for every version not just the first. What it does not create is continuity. Products are made of consistency: one data model, one roadmap, one owner per decision. AI produces productivity while multiplying the initiatives competing for that consistency, and the costly, unmeasured line was never the code, but reactivating the organisation around every change. Review, QA, training, documentation, support, regulatory evidence: that absorption cost barely falls with AI, and it scales with the number of changes. Ship twice as many versions and you pay it twice as many times. The NBER gap — coding activity up 180%, releases up 30% — is that absorption queue made visible. A vendor charges you for exactly one thing: keeping a product coherent so your organisation only has to absorb it once.
A financial institution today has to ask itself the same build or buy question it did a few years ago. But the underlying assumptions changed. This does not automatically mean that every build today is easier. On the opposite it creates completely different requirements on governance and risk management and new challenges.
AI made every version cheaper to write. It made coherence — one product, one owner, one roadmap — the most expensive thing in software. That is what a licence actually buys.
.webp)
.webp)