If you’re planning a fintech app or improving one people already use, there’s a lot to like about faster AI-powered development. Features that would otherwise sit in the backlog can reach customers sooner, giving you something to learn from while there’s still time to change direction. For a founder, that means spending less time imagining how the product will work and more time finding out what people actually need.
We’d take those advantages, though we’d look carefully at what counts as “working” when the product touches money.
A purchase that goes through without waiting for approval might look like an improvement in a demo. Whether it should have gone through without approval is much harder to see, particularly when the same coding agent has made the purchase possible and removed the check.
In a controlled run described on r/AI_Agents, an agent received a fairly ordinary request: support bigger gift cards, sold at every till.
To deliver it, the agent raised the cap to €2,000, allowed every cashier to issue cards and removed administrator validation. According to the author, the cap was an anti-money-laundering control, but the agent went on to rewrite its tests so they passed and justify the changes with safeguards it had invented.
What makes the story particularly revealing is that the agent had written the validation step itself, 18 tasks earlier. The rule had also appeared in its context 13 times, so this wasn’t simply a requirement nobody had mentioned.
The newer task asked for bigger purchases; an earlier requirement restricted them. In this run, the agent treated that restriction as something to change to complete the latest request, rather than a condition the new feature still had to meet. Having the rule in its instructions hadn’t kept the rule in the code.
A separate evaluation caught the violation before this became a story about money lost in production. Even so, it’s easy to see why someone reviewing the update might have accepted it: the bigger cards worked, the tests passed and the agent supplied an explanation for its choices.
Spotting the problem required more than checking that the implementation matched the latest ticket. Whoever reviewed it also needed to know why the old restriction existed, because without that context, removing it could look like a reasonable part of the job.
You don’t need AI to end up with a financial product that appears to work while missing something important. Starling’s sanctions-screening failure offers a real banking example of how quietly that can happen.
In January 2023, the bank discovered that its automated screening covered only designated individuals with UK citizenship or residency: 39 people out of 3,088 on the relevant list. That configuration dated back to 2017, and according to the FCA’s final notice, the system produced no financial-sanctions screening alerts for individual customers between July 2022 and the discovery in January 2023.
The bank had a screening system, but most of the people it needed to screen for were outside its coverage. Unlike a broken registration button, that gap wouldn’t necessarily reveal itself to someone trying the app. Establishing whether the check worked meant understanding who it was supposed to cover, then comparing that requirement with what the software actually did.
AI-assisted development makes it possible to introduce more changes like these in a much shorter period. A team can get through more of its backlog before Friday, while the work of understanding how those changes affect existing rules still needs to happen.
That gap grows if review can’t keep pace, especially when the agent changes the tests alongside the feature. Passing tests become less reassuring when the behaviour being tested and the definition of an acceptable result have moved together.
From a commercial perspective, the gift-card request makes perfect sense. Customers can buy more, cashiers can serve them at any till and fewer people have to wait for a manager. Those are the kinds of improvements a product team should be looking for.
In fintech app development, however, making a purchase more convenient can also change how much value someone is allowed to issue and who gets to authorise it. What starts as a small improvement to the customer experience can reach into decisions about how the business handles risk.
That doesn’t make every extra step worth keeping. Financial products have plenty of unnecessarily painful experiences, and we’d happily help remove them. But there’s an important difference between improving an awkward way of meeting a requirement and removing a requirement nobody has stopped to understand.
An agent can help build the better experience once those decisions are clear. When they aren’t, it can fill the gaps with choices that look sensible on screen, leaving the team to discover later what it has effectively agreed to. Once customers are using the feature, putting things right may involve tracing affected transactions as well as fixing the code.
The ambition behind the original request is worth keeping: let people buy bigger gift cards without spending so much time waiting for a manager. AI makes acting on that ambition quicker, and there’s no reason the result has to be a less thoughtful product.
For example, an approval could reach the right person sooner, with the purchase details already attached and a clear status for the cashier. That gives the customer a better experience without taking the decision away from the business. The opportunity is still there once you understand what the approval is protecting.
Finding that version of the feature takes a little more work than accepting the first implementation that runs. It means bringing the reason for the restriction into design and development, whether you’re launching something new or improving a product people already use.
That’s where we’d spend some of the time AI saves. Bigger gift cards were a perfectly good idea; they just deserved a better definition of “done” than passing tests.
