Faster Code is Only Part of Bank Modernization

AI can help banks modernize applications faster. The value depends on how teams use it, how productivity gains affect the cost of the service, and how quickly people can make decisions together.

Consider a nightly batch job in a banking application. It runs at 2 a.m. and feeds several downstream reports. An AI coding agent can help analyze and refactor it. Before changing it, though, the team needs to understand why it runs at that time, who depends on its output, and what happens if it finishes late.

Some answers may be in the code. Others may sit in operating procedures, scheduling rules, or the experience of the people who support the application.

That is a useful starting point for evaluating AI-enabled modernization. Faster development matters. So do the conditions that turn it into a working improvement for the bank: business context, sound engineering, a clear commercial arrangement, and a team that can resolve questions together.

What coding agents need around them 

Our Agentic Software Engineering approach pairs coding agents with engineering expertise, business context, architecture standards, and human oversight. On a corporate banking platform modernization, development timelines were 30–40% shorter. That result comes from one engagement and won't hold for every application, but what we learned there applies more broadly. 

Industry research points the same way. In its 2025 research, Google Cloud's DORA team surveyed nearly 5,000 technology professionals. Ninety percent reported using AI at work, and more than 80% believed it had increased their productivity. AI adoption was positively associated with software delivery throughput, but negatively associated with delivery stability. These are cross-industry findings, rather than results specific to banks. 

More code and faster changes need to be supported by the practices that help teams release safely. For a bank evaluating an engineering partner, here are five things we’ve learned to put in place. 

1. Business context

An agent can help reconstruct application logic, map dependencies, and draft documentation. The team still needs to check that understanding against how the business operates. 

For the batch job, that means confirming which reports depend on it and whether its schedule reflects a business deadline. Understanding what the code does is a starting point; deciding what can change requires a broader view. 

2. Architecture 

A change can work in isolation and still create problems elsewhere. Teams need agreed patterns for how applications, data, and integrations should fit together. 

Ask how agents receive those standards and how engineers review their output against the target architecture. The answer should explain how individual changes contribute to the modernization plan. 

3. Security and compliance 

The delivery process needs to account for which environments agents can access, what information they can use, and how changes are recorded and reviewed. 

Ask what evidence the process produces as work happens. That makes the discussion more useful than a general assurance that security and compliance are covered. 

4. Quality 

Agents can help generate tests and refactor code. Engineers need to check whether those tests cover the application's requirements, dependencies, and failure scenarios. 

For the batch job, testing also needs to cover the accuracy of downstream reports and the timing of their delivery. Those checks belong in the acceptance criteria too. 

5. Accountability 

There should be a clear owner for reviewing outputs, resolving exceptions, and approving a release. Ask which decisions agents can support, which require human approval, and who is responsible when a change needs further investigation. 

Softtek's approach to Agentic Software Engineering combines agents with engineering expertise, business context, architecture standards, and human oversight across the modernization process. Softtek reports 30–40% shorter development timelines on a corporate banking platform modernization. That is a result from a specific engagement, rather than an expected improvement for every application. 

If delivery is faster, what changes in the price?

A bank can receive value from productivity in several ways: lower spending, more work completed within the same budget, or capacity redirected to another priority. The commercial agreement should make clear which of those the bank is buying. 

Three questions help make that conversation specific.

What is actually improving? 

Faster development, less regression effort, and lower support costs are different gains. Agree on the activity being measured, its baseline, and the quality requirements that still apply. 

A reduction in coding hours, for example, does not establish that the total cost of changing and running the application has fallen. The review needs to include the work that follows coding.  

How does the improvement affect what we pay? 

Under an hourly arrangement, fewer billable hours can reduce the bill for the same scope. Other arrangements may turn productivity into additional capacity or a change in service pricing. 

Ask the provider to explain how this works in the proposed agreement. Softtek's stated approach is to reflect productivity gains in service value rather than headcount alone. The agreement needs to define what that means for the bank's scope and budget. 

How will we know we received the value? 

Agree how improvements will be measured and reviewed. If the expected benefit is more capacity, define what additional work that capacity should support. If it is lower cost, identify which costs should change and how the comparison will be made. 

Softtek reports 20% lower IT operations cost on a wealth management platform. That is a relevant result to discuss, but it does not establish that pricing arrangements caused the reduction. Ask which delivery changes contributed and whether they apply to your situation. 

How much time does the team spend waiting for answers? 

On an engagement with a top-three global bank, our team delivered about 99% of work on time, and the client rated the engagement 4.5 out of 5. Those figures describe the engagement as a whole, not the effect of nearshore delivery alone. Work like this has shown us how much a project depends on getting answers quickly. 

Modernization also depends on access to people who can clarify a requirement, review a design, or approve a change. A short question can delay work when the person who can answer it is unavailable until the next shift. 

Working-hour overlap gives teams more opportunity to resolve those questions together. Softtek's Americas delivery model offers near-full overlap with the US East Coast workday. For a bank evaluating nearshore delivery, the practical question is how that overlap will be used. 

Will architects and application owners be available for design reviews? Can engineering and operations investigate a dependency together? Who can make a decision when a release issue arises? Shared hours are useful when the people involved have the knowledge and authority to move the work forward. 

Team continuity matters alongside availability. Engineers build knowledge as they work on an application: why a workaround exists, which dependency caused trouble before, and who needs to review a particular change. Repeated handovers can mean explaining that context again. 

Ask how the provider retains application knowledge, documents decisions, and transfers responsibility when people change. A shared workday and a clear continuity plan both belong in the delivery discussion. 

Start with one application 

Choose an application already under consideration for modernization. Bring together its engineering lead, business or operations owner, and the person responsible for the service agreement. 

Use the discussion to answer three questions: 

• Can we change it with confidence? Identify the business dependencies, architecture requirements, controls, tests, and approval owners that need to guide the work. 

• How will we measure the value? Agree on the improvement being sought and how it should affect cost, capacity, or delivery time. 

• Can the team resolve decisions promptly? Check working-hour overlap, access to decision-makers, and how application knowledge will be maintained.

Where an answer is unclear, you have a specific issue to address before expanding the work. This gives the bank and its engineering partner a practical basis for deciding where AI can help and what needs to be in place around it.  
 
AI-enabled modernization is worth evaluating through all three lenses: engineering, commercial value, and delivery. Together, they give a clearer view of what faster development can mean for the bank. 

Helped banks modernize core systems and develop new financial products for decades. Today, we work with global banks to build the platforms that support their next generation of financial products and customer experiences.  Learn more about how we our approach agentic software engineering.