AI Coding Agents in Finance: How to Accelerate Delivery Without Losing Control of Your Codebase

AI Coding Agents in Banking Teams: Speed, Risk, and Code Review

AI coding agents can genuinely compress delivery time for finance and treasury teams. They also introduce risks that require tighter controls, not looser ones. This post sets out where the gains are real, where the dangers concentrate, and how to run a team that gets both right.

What AI Coding Agents Actually Do

Agents that operate on goals are not the same thing as autocomplete, and that distinction matters before you evaluate whether to use them.

Tools like GitHub Copilot operate mostly inline: they suggest the next line or block as you type. That is useful, but it is still reactive. Goal driven systems, including more recent configurations of Cursor, Claude, and frameworks built on top of large language models, can take a high level instruction and execute a sequence of steps to complete it. They can read your existing files, write new ones, run tests, interpret the output, and revise the code without you touching the keyboard between steps.

To make that concrete: you can tell an agent to build a pandas pipeline that reads your HQLA position file, classifies assets for the LCR numerator, and models outflow run off rates by liability category. The agent will produce something that compiles and broadly runs. What you cannot assume is that it has applied your firm's liquidity policy correctly, or that the outflow categories match what the UK CRR or your internal policy actually specifies. More on that shortly.

The honest summary: agents are good at structure, repetition, and pattern matching. They are not good at knowing what your firm's liquidity policy says, what the PRA expects in your ILAAP narrative, or whether a calculation is right in a domain they cannot directly observe.

Where Delivery Genuinely Accelerates

The productivity gains are real. They are just concentrated in specific places.

Boilerplate and scaffolding. Setting up a project structure, writing class skeletons, generating configuration loaders, connecting to a database, writing logging wrappers: an agent can do all of this in minutes. A developer who would have spent half a day on setup can be writing actual business logic by mid morning.

Test scaffolding. Writing unit tests for a function you have already built is useful but tedious. Agents are good at generating test cases from a docstring or a function signature. They will miss edge cases specific to your domain, but they give you a structure to build from rather than a blank file.

Data pipeline construction. Reading a CSV, cleaning columns, applying transformations, reshaping for output: this is where agents really compress time. A pipeline that previously took two days of careful construction, including boilerplate, error handling, and documentation, can reach a working first draft within two hours. The developer's time shifts from writing to reviewing and extending.

Documentation. Agents can write docstrings, README files, and inline comments at scale. For teams that struggle to keep documentation current, this is genuinely useful.

The Risks You Cannot Outsource to the Model

This is the section that matters most if you work in a regulated environment.

Hallucinated Logic

Code the agent generates can compile, pass basic tests, and still be functionally wrong. It might apply a run off rate from the wrong liability category, invert a condition, or use a formula that looks plausible but does not match what the UK CRR or your internal policy actually specifies. The code works. The number is wrong.

Domain Blindness

A general coding agent has no reliable knowledge of your firm's FTP methodology, your specific encumbrance calculation, or the version of the PRA110 return your team currently submits. It will fill in those gaps with something plausible. Plausible is dangerous in regulatory reporting.

Insecure Patterns

Code produced by large language models is a known risk area for hardcoded credentials, weak input validation, and dependency choices that carry known vulnerabilities. Your security review process needs to treat code the agent produces with the same scrutiny as any external contribution.

Dependency Sprawl

Agents default to importing libraries that solve the problem quickly. Without a team standard on approved packages, an AI assisted codebase can accumulate unnecessary dependencies in a matter of weeks, each one a potential vulnerability and a maintenance burden.

The core risk is this: agents optimise for producing something that works in the moment. They are not optimising for correctness in your specific regulatory context, or for what happens when someone has to maintain that code a year or more down the line.

Code Review in an AI Assisted Team

When agents generate more of your code, code review becomes more important, not less. The nature of the review also needs to shift.

Traditional review catches things the developer missed. Review in an AI assisted team needs to additionally catch things the developer never wrote themselves and may not fully understand. That is a higher bar.

What to Change in Your Review Process

• Require reviewers to run the logic, not just read it. Code from an agent can look clearly structured while being substantively wrong. Reading it is not enough.
• Check domain correctness explicitly. For any finance or risk calculation, the reviewer should be able to trace the formula back to a source: your internal policy, a regulatory document, or an agreed business rule. If they cannot, that is a flag.
• Treat passing tests as a necessary condition, not a sufficient one. An agent can write tests that confirm its own assumptions. Tests written by the same model that wrote the code are not an independent check.
• Flag magic numbers and unexplained constants immediately. Code the agent produces is prone to embedding literal values with no explanation of their origin. In a financial context, this is a serious problem. See our post on writing clear constants and fixed values in Python for the right approach.

Review gates are not negotiable. No code the agent produces goes to production without a human sign off from someone who understands both the code and the business context it operates in.

Avoiding the Technical Debt Trap

Agents produce code that works now. They do not produce code that is easy to change, extend, or hand to a new team member in a year.

Without enforced standards, an AI assisted codebase accumulates debt fast. You will see:

• Inconsistent naming conventions across files written in different sessions
• Logic duplicated because the agent did not know it already existed elsewhere
• Comments that describe what the code does rather than why it does it
• Configuration values buried inside functions

None of this is the agent's fault. It is doing what it is asked. The responsibility is on the team to set standards before the agent writes anything.

Clear comments are part of this. Comments that explain the why, the business rule, the regulatory reference, are what make a finance codebase maintainable. An agent will write comments if you ask it to, but it will write superficial ones unless you are specific about what you want. Our post on writing clear and readable code with comments covers this properly.

Define your standards in a team document. Name conventions, file structure, how constants are handled, which libraries are approved, what a comment should contain. Give that document to the agent as context at the start of every session.

Building for Business Flexibility From the Start

Treasury and risk environments change. Rates change, regulatory thresholds get updated, business units restructure. Code that cannot absorb those changes without a rewrite is a liability.

Two things matter here.

Separate configuration from logic. Run off rates, threshold values, product classifications, and any other parameter that might change belong in a configuration file or a constants module, not hardcoded into functions. When the regulator updates a category, you change one file and rerun. When the logic is buried, you go hunting through the codebase hoping you found every instance.

Use modular design. Each function or module should do one thing. A pipeline that reads, cleans, transforms, applies business rules, and outputs should be broken into discrete steps that can be tested and changed independently. Agents, if not directed otherwise, will sometimes collapse all of this into a single long function. Push back on that from the start.

A clearly structured codebase also makes the agent more useful over time. When the agent can read clearly separated, well named modules, it generates better suggestions for extending them. A tangled codebase confuses the agent the same way it confuses a new developer.

A Practical Framework for Finance and Banking Teams

Here is a lightweight operating model you can adapt.

Before You Use an Agent

• Define the task precisely. Vague instructions produce vague code.
• Provide context: your team's naming conventions, approved libraries, relevant business rules.
• Identify who will review the output and confirm they have the domain knowledge to do so.

While the Agent Is Working

• Keep tasks small and specific. One function, one module, one pipeline stage at a time.
• Review incrementally. Do not let the agent write five hundred lines and then try to review it all at once.
• Ask the agent to explain its logic before you accept it, particularly for any calculation.

Before Any Output Merges

• Domain review: is the business logic correct? Can you trace every formula and constant to a source?
• Security review: are there hardcoded values, unusual dependencies, or weak validation patterns?
• Standards review: does the code meet your team's naming, structure, and comment standards?
• Test review: are the tests actually testing the right conditions, or just confirming the agent's own assumptions?

Ongoing

• Log which parts of your codebase were primarily produced by the agent. This is useful when something breaks.
• Review those modules more frequently in the first few months.
• Update your team standards document as you learn what the agent does well and where it needs the most direction.

The Bottom Line

The speed benefit is real and worth capturing. The teams that get the most from AI coding agents are not the ones who let the agent run freely. They are the ones who apply the tightest standards around it, so that speed and quality move together rather than in opposite directions.