36,000 Hours a Week: U.S. Bank

What U.S. Bank Tells Us About the Future of Software Engineering

AI-assisted coding is not just a developer productivity story. It could reshape how banks organise technology, shared services and software delivery.

For years, when banks wanted to build more software, the answer was largely predictable: add developers, expand technology centres, use offshore capacity, standardise development methods and improve the software-development lifecycle.

Artificial intelligence is beginning to change that capacity equation.

One example caught my attention because it moves the discussion away from demonstrations and into measurable work. U.S. Bancorp reported in its 2025 annual report that its engineers are using AI to write and review code faster and automate processes. Its GenAI-powered code-review assistant reduced code-review time by about 75%, while the bank reported approximately 36,000 hours of code-writing time saved each week.

Thirty-six thousand hours every week is the number that should make CIOs, CTOs and heads of global business services stop and think. Not because it proves that programmers are disappearing. It does not. It raises a much more important management question: what should a bank do with that capacity?

The important number is not the AI adoption rate

I have spent much of my career looking at technology and operations through a productivity lens. Whether we were re-engineering a banking process, moving work into shared services, introducing workflow, implementing RPA or changing a core platform, the technology itself was never the final measure.

We normally asked three practical questions. Where is the volume? What measurable value will the change create? And how will it improve the experience or capability of the bank and its customers?

That is why the U.S. Bank example is more interesting to me than a statement saying that thousands of developers have access to an AI assistant. Access is not an outcome. Usage is not an outcome. Even the percentage of AI-generated code is not necessarily an outcome.

Hours returned to the engineering organisation and time removed from a control point such as code review are much closer to the real management question.

Software engineering is a process, not just code writing

The first mistake in discussing AI and software development is to reduce software engineering to writing code. A bank's development factory includes requirements, architecture, coding, code review, testing, security checks, integration, release management, production monitoring, incident management and maintenance.

If AI makes one developer write code twice as fast but the code waits in a review queue, testing takes the same time and releases remain constrained by old controls, the bank has accelerated one station in the factory rather than the factory itself.

That is why the reported reduction in code-review time is particularly interesting. It suggests that AI is moving beyond autocomplete and into another part of the software-development lifecycle. The next stage will be broader: agents that can understand a task, inspect an existing codebase, produce changes, generate tests, identify defects, prepare documentation and support the release process - under defined human and control boundaries.

I do not expect that journey to happen overnight. Banking technology carries regulatory, security, resilience and legacy-system constraints that a start-up may not have. But I do expect the direction of travel to be clear over the next three to five years.

What happens to 36,000 hours?

This is where the conversation should move from technology to operating model.

If a bank genuinely releases tens of thousands of engineering hours every week, management has choices. It can use that capacity to deliver more releases. It can accelerate legacy modernisation. It can reduce technical debt that has been postponed for years. It can increase testing and security work. It can absorb business growth without adding developers at the same rate. Over time, it may also redesign the size and composition of technology teams.

The U.S. Bank disclosure does not tell us exactly how all of those saved hours are ultimately harvested, and we should not invent the answer. The bank places AI and automation within a broader productivity programme and says some productivity is reinvested in areas including technology, sales and marketing. Its enterprise financial outcomes should not be attributed to AI alone.

But this is precisely why the case is valuable. It gives us a measurable starting point and then forces the leadership question: where did the saved capacity go?

This could reshape the GBS model

For decades, global business services and offshore technology centres changed the economics of banking. Work was standardised, pooled and moved to locations where banks could access skills at scale and at a different cost base. I have been part of that journey myself.

AI does not automatically make that model obsolete. But it can change its mathematics.

If one engineer, supported by AI, can produce and review materially more work, the old relationship between application portfolio, change demand and developer headcount begins to move. The question for a technology centre is no longer simply, 'How many developers do we need?' It becomes, 'What combination of engineers, AI agents, platform capabilities and control specialists do we need to deliver this portfolio safely?'

That is a very different workforce-planning question.

The highest-value people may increasingly be those who understand architecture, business context, integration, security, production risk and how to judge AI-generated work - not simply those who can produce the largest number of lines of code.

Do not turn 36,000 hours into a headcount calculation

There is a temptation whenever productivity numbers appear to divide the hours by a working week and immediately convert the result into full-time employees. I would resist that.

Saved time is not automatically cash saved. Ten minutes removed from hundreds of people's work does not mean hundreds of people disappear. Capacity has to be concentrated, processes redesigned and demand managed before productivity becomes a financial outcome.

There is another reason for caution. Faster coding can create a new bottleneck elsewhere. If architecture decisions, testing, cybersecurity approval or production deployment cannot keep pace, the organisation simply moves the queue.

The objective should therefore not be 'AI writes more code.' The objective should be a better software-delivery system: faster where speed creates value, safer where risk matters, and cheaper where capacity can genuinely be harvested.

From copilots to an AI engineering workforce

I see three broad stages developing.

The first is the stage many banks are already entering: AI as a copilot. Developers use it to explain code, generate code, debug, document and accelerate reviews.

The second is AI embedded across the engineering lifecycle. Coding, testing, review, documentation, security analysis and change preparation begin to connect rather than operate as separate AI tools.

The third is more agentic. A human defines the outcome and constraints; specialised agents perform larger parts of the engineering workflow; humans increasingly supervise architecture, risk, exceptions and final accountability.

Banks will move through these stages at different speeds. A mature cloud-native environment with good APIs, automated testing and disciplined DevOps can move differently from a bank carrying decades of tightly coupled legacy applications. There is no universal recipe.

That is why I would use a staircase rather than a lift for this transition: start with bounded work, measure it, understand the defects and bottlenecks, widen the scope and then move to the next level.

The CIO question is changing

For many years the CIO question was: How do I obtain enough technology capacity to deliver the bank's change agenda?

AI introduces another question: How much of that capacity should still be human, and what should humans do when machines can perform an increasing share of the engineering work?

That does not mean software engineers disappear. It means the shape of software engineering changes. The valuable engineer of the next few years may write less code personally while taking responsibility for more software output - directing agents, reviewing decisions, understanding the existing estate, controlling risk and connecting technology to the business problem.

The U.S. Bank numbers matter because they give us an early view of that change in a real banking environment.

The lesson is not that every bank should copy U.S. Bank's tools. The lesson is that banks should start measuring AI in engineering as an operating-model change, not as another software licence.

What I would ask at the next technology review

• How many engineering hours are we actually releasing - not how many developers have an AI licence?

• Where in the software-development lifecycle are we saving time: coding, review, testing, documentation, security or release?

• Has the bottleneck moved somewhere else?

• What are we doing with the released capacity: more change, legacy modernisation, quality improvement, growth absorption or cost reduction?

• Are defects, incidents and security outcomes improving as delivery becomes faster?

• What should our technology workforce look like three years from now if these productivity gains continue?

The future of software engineering will not be decided by how much code AI can generate. It will be decided by how organisations redesign the engineering system around what AI can now do.

U.S. Bank's reported results are an important signal. If a bank can return tens of thousands of engineering hours every week, the discussion has already moved beyond whether AI can help programmers. The question now is how far the software factory itself can be redesigned.

Source note

U.S. Bancorp, 2025 Annual Report to Shareholders, filed March 10, 2026. The bank reports approximately 36,000 hours of code-writing time saved each week and an approximately 75% reduction in code-review time from a GenAI-powered code-review assistant. The broader observations about the future operating model of software engineering are the author's analysis and practitioner perspective, not claims made by U.S. Bancorp.

Public source: U.S. Bancorp 2025 Annual Report, U.S. Securities and Exchange Commission.