> ## Content Index
> Fetch the complete content index at: https://vault.up-state.ai/llms.txt
> Use this file to discover other available public pages before exploring further.

# Who Looks After the Software When Vibe Coding Comes to the Bank.
- URL: https://vault.up-state.ai/who-looks-after-the-software-when-vibe-coding-comes-to-the-bank/
- Published: 2026-10-19T14:53:22.000Z
- Updated: 2026-10-19T14:53:22.000Z
- Description: The interesting consequence of AI writing software may be that banks and credit unions need more people who understand software, even as fewer people need to write it themselves.
- Author: Ben Nichols
- Tags: Commentary

*Commentary | Upstate AI | October 19, 2026*

The interesting consequence of AI writing software may be that banks and credit unions need more people who understand software, even as fewer people need to write it themselves.

Consider an operations manager who wants an application to compare two files and flag discrepancies. With an AI coding assistant, she can describe the workflow, try what it produces and ask for changes. That's the attraction of vibe coding: people who understand a business problem can participate directly in building its solution without first mastering a programming language.

Now suppose her team starts depending on it. Someone needs to understand what counts as a discrepancy, what happens when a file is missing, who can dismiss an exception and whether a change to an upstream system will quietly break the comparison. Those questions remain even if the assistant writes every line.

I think this is where a different kind of software professional becomes important: a software steward with the skills of a software engineer and an intimate understanding of the application, focused on its ongoing performance and maintenance rather than its initial creation.

## Cheaper software means more reasons to build

In *The Coal Question*, economist William Stanley Jevons argued that more efficient use of coal could increase total consumption by making coal-powered activity more economical. That's the mechanism behind what we now call the [Jevons paradox](https://www.econlib.org/library/YPDBooks/Jevons/jvnCQ.html?chapter%5Fnum=9&ref=vault.up-state.ai#book-reader).

Software offers a plausible parallel. When building an application requires a substantial budget and a long wait, many small problems don't justify the investment. Lower the cost of creating it, and the calculation changes. A reconciliation aid or an internal exception tracker might become worth building even though it would never have survived the old project queue.

That doesn't establish that AI will increase software employment. AI can help with testing and maintenance, too, allowing one professional to support more applications. The question is whether the portfolio grows faster than the effort required to look after each application falls.

My expectation is that more institutions will find themselves owning software they wouldn't previously have commissioned. They'll need to plan for that ownership, rather than assume that a cheaper build produces an equally cheap lifetime commitment.

![Illustration of a developer working at a computer while reviewing application details](https://storage.ghost.io/c/c5/ce/c5ce462a-7219-48d0-892f-946fcccc5d9e/content/images/2026/10/undraw_development_s4gv.svg)

## Brooks's other five-sixths

Frederick P. Brooks Jr., who managed IBM's OS/360 development, gave coding just one-sixth of his suggested project schedule in *The Mythical Man-Month*. He allocated one-third to planning and the remaining half to component and system testing. This was his [scheduling rule of thumb](https://web.eecs.umich.edu/~weimerw/2018-481/readings/mythical-man-month.pdf?ref=vault.up-state.ai), not a measurement of lifetime maintenance costs.

The fractions aren't a budget formula for an AI-assisted project. The useful point is that producing code was only part of delivering working software long before AI entered the picture.

AI can assist with the other parts. It can propose requirements, generate tests and explain failures. But someone still has to decide whether the requirements describe the bank's actual process and whether the tests prove anything useful. An assistant can faithfully implement the wrong rule and then write a test confirming that it did.

The National Institute of Standards and Technology (NIST) makes a related distinction in its [Secure Software Development Framework](https://csrc.nist.gov/pubs/sp/800/218/final?ref=vault.up-state.ai): security practices need to be integrated into the development lifecycle. Producing functioning software doesn't, on its own, establish that it's well-secured.

![Illustration of application documentation and requirements kept ready for review](https://storage.ghost.io/c/c5/ce/c5ce462a-7219-48d0-892f-946fcccc5d9e/content/images/2026/10/undraw_document-ready_o5d5.svg)

## The job moves outward from the code

I expect the professional's attention to shift toward the information surrounding the application: its purpose, requirements, dependencies, permissions, test evidence and operating history. Think of these as the application's metadata, the information that explains what it is, what it relies on and how we know it's behaving correctly.

For our hypothetical reconciliation application, the source code might be straightforward. The consequential knowledge is that one file arrives a day later on holidays, an empty file is different from a missing one, and only a designated reviewer can approve certain exceptions. A change that ignores those details can be technically tidy and operationally wrong.

The software steward keeps that knowledge connected to the running application. When the business process changes, they know which requirements and tests need to change with it. When a dependency becomes unsupported, they can assess what replacing it might affect. When nobody uses the application anymore, they can arrange its retirement instead of maintaining it indefinitely.

This brings together work associated with a product manager, a business analyst, a delivery lead and a technical operations specialist. The role carries the continuity between deciding what to build, organizing changes and keeping the result running. AI may handle more of the translation into code, while the professional maintains the understanding that makes those instructions worthwhile.

That still requires technical depth. A steward who can't challenge an explanation, investigate a failure or recognize when specialist help is needed is poorly equipped for the job. Maintaining metadata doesn't mean tending a spreadsheet while ignoring the software. It means checking that the institution's understanding still matches reality.

## Make room for both

For banks and credit unions, I wouldn't frame this as a choice between letting business teams build and reserving everything for technical specialists. The people closest to the work should help shape the tools. Professional stewardship gives their useful experiments a route into dependable operation.

The arrangement should reflect the application's importance. A small internal tool might share a qualified maintainer with several others. A sensitive application supporting a critical process needs deeper coverage and independent review; combining skills in one role doesn't make self-approval a good idea.

Before an institution starts relying on a homegrown application, leadership should be able to name the person who understands its business purpose and technical dependencies, has time to maintain it and can bring in help. If that person is an outside provider, the responsibility needs to be part of the engagement, not an assumption left over from the build.

Vibe coding has a place in banks. Its promise is that more people can turn their understanding of a problem into useful software. Realizing that promise means making professional care part of the ownership decision from the beginning.

---

**Upstate AI** helps banks and credit unions understand, evaluate and implement AI on established platforms. Its founder, **Ben Nichols**, works with institutions on AI strategy, implementation and governance, and teaches AI at Syracuse University. [ben@up-state-ai.com](mailto:ben@up-state-ai.com)