AI Coding Agents in Finance: What to Hand Over, What to Keep

Alex: 9 out of 10 professional developers now use AI coding agents at work every week. Two-thirds use them every day. That's from a survey of more than 15,000 developers this summer. And this year, researchers gave the best AI coding agents a job that looks like real work. Build something, then keep adding to it round after round.

Alex: The best agent passed fewer than 15% of the checks. In most runs, its code got messier the longer it worked. Both of these are true at the same time, so if you run technology at a bank, a fund, an insurer, or a fintech, here is a real question. Which work do you hand to AI and which work stays with people? I'm Alex and this is Curiosity Code.

Alex: If you've watched for a while, you'll notice something missing today. A guest. The interviews are still coming. Booking someone smart just takes weeks of calendars and time zones and some questions won't wait that long. So in between you get me on my own with nobody to interrupt.

Alex: I'll try not to enjoy it too much. Before I answer, you should know where I stand because I'm not neutral. My company, Productera, builds software for financial firms. We sell AI-driven teams. Small teams where a senior engineer directs the AI and the AI writes most of the code.

Alex: We also still supply conventional developers to larger firms. So I make money whichever way you decide and I've seen both work and both fail. There are two loud views on this. At the end of September engineering lead posted a video about moving his small team onto AI for 18 months. He called himself a failed engineering leader and he stopped using AI completely.

Alex: It got 50 times his channel's usual views. On the other side, executives compare notes on what share of their code AI now writes, and the numbers only go up. One thing before I go on. When I say conventional developers, I still mean developers who use AI. Nearly all of them do.

Alex: The difference is who writes the critical code and who owns it. In an AI-driven team, a senior engineer directs and the AI writes. In the conventional team, people write the parts that matter and AI helps. Here is where I land. Writing the code got cheap.

Alex: Being accountable for it did not. Give an AI-driven team the work that used to need headcount: the scaffolding, the first-draft tests, the prototype, the new build a senior engineer can read end-to-end. Keep conventional developers on anything that has to stay sound for years, be read against a regulation, or be signed off by someone who did not write it. Nobody can yet honestly review that work when agent wrote it. Start with what I'd hand over.

Alex: Fred Brooks wrote The Mythical Man-Month in 1975. In it he describes a proposal from 1971, organise a software team like a surgical team. One person does the cutting, everyone else exists to make the person more effective. Everyone agreed it was the right shape. Almost nobody built it because you had to hire the whole support staff around the surgeon.

Alex: Right structure, impossible economics. That support work is what AI now does well. Boilerplate, scaffolding, first-draft tests, the documentation nobody gets round to, the prototype that proves an approach before you commit to it. So the first thing I would hand an AI-driven team is that support work on almost any project. The second is a new build where a senior engineer can read every line.

Alex: Here the agents start strong and they are improving. In that same benchmark simply asking for a cleaner code made the first version up to a third less bloated. It didn't slow the decline that came after. The third is reading old code as opposed to rewriting it. Morgan Stanley built a tool that reads its old COBOL programs and writes plain English specifications from them.

Alex: According to the Wall Street Journal, it has processed more than nine million lines and saves around 280,000 hours. People still write the new code. And the fourth is small, bounded changes. A ticket comes in, an agent writes the fix, and the change is small enough to review properly. Now, what I would keep with conventional developers for now.

Alex: First, systems that have to stay sound for years. A core ledger, a payments engine, anything an agent would keep extending change after change. That benchmark is called SlopCodeBench from the University of Wisconsin. The best agent passed 14.8% of the checks. Its code ended up more than twice as long-winded as code people wrote.

Alex: People's code got worse over time too but less often and by less. Second, code that has to be read against the regulation or that guards the doors. Payment rules, reporting logic, logins, permissions, keys. The model writes what the prompt asks for and the prompt rarely carries the whole rule. Veracode tested more than a hundred models.

Alex: 45% of the code samples contained a well-known class of security flaw and bigger more advanced models did no better. Third, any change that needs someone else to sign it off. Here is the trap. AI-driven teams produce far more code and somebody has to review it. One analytics firm studied about 10,000 developers.

Alex: Teams using AI heavily merged nearly twice as many pull requests and reviews took 91% longer. Read thousands of lines that look right for long enough and you stop reading closely. So the recap. Hand over the support work, new builds a senior engineer can read, reading old code, and small changes. Keep conventional developers on long-lived core systems, regulated and security code, and anything that needs an independent sign-off.

Alex: For a financial firm, that second list covers a lot of what it runs. No regulator has told banks to stop using AI to write code. In Europe, though, one rule already draws this line for you. It's called DORA, the Digital Operational Resilience Act, and it has applied since January last year. Its rule on changing systems says whoever approves a change has to be independent of whoever asks for it and builds it.

Alex: Think about what that means for an agent. If an agent writes the change, tests it and merges it, nobody independently approved it anything. If a person clicks approve on 5,000 lines they did not read, that's the same failure with a signature in it. In the US, the bank guidance on model risk was replaced in April, and the new version leaves generative and agentic AI out of scope. So there, the ordinary controls on changing systems do the work, whoever wrote the code.

Alex: So here is the test I would use. Can someone senior who didn't write it honestly review all of it? And will they still own it in three years? If both answers are yes and the work is bounded, use an AI-driven team. If either answer is no, keep conventional developers on it or keep the AI to a small scope.

Alex: So here is what I do this week. Take your backlog and sort it with three questions. Will this code still be running in three years? Does it touch a regulation, money movement or security? And is there someone senior who didn't write it with time to read all of it?

Alex: If this work is short-lived, low stakes and reviewable, give it to an AI-driven team. If it's long-lived, regulated, or nobody can review it properly, keep conventional developers on it The three questions are in the show notes. Here's what I can't settle. The line I've drawn depends on senior engineers who can review what the agents write. Most of them learn by doing the junior work the agents now do.

Alex: So where does the next one come from? Tell me how you would answer that. If you're watching, leave it in the comments. If you're listening send me a message on LinkedIn and follow the show wherever you're listening or watching