Bank of America now has about 4,000 people working on security weaknesses that AI models found in the code it runs: 3,000 of its own staff and 1,000 outside contractors who joined in the second quarter and are still there. The weaknesses are in the bank's own programs and in programs it buys from vendors.
Finding a flaw is now much faster than fixing it
An AI model like Mythos reads code the way a security researcher does, but it can do it across thousands of programs, and it can build a working attack. In one case it built a way to forge the certificates that prove a website is genuine, so an attacker could run a fake bank site that looks real to the customer.
A fix is a different kind of job. Someone has to understand why old code was written the way it was, change it without breaking the other programs that rely on it, test the change, and install it everywhere. Anthropic itself says the limit is people to sort and repair the flaws, not the finding. In open-source software, about 2,300 flaws had been reported to the people who maintain the code by late August, and 421 had been fixed. Many of those maintainers are unpaid volunteers with another job.
A bank can pay contractors to close that gap. Most software makers cannot.
What it looks like for a small business
Take a chain of dental clinics that books patients through software from a vendor with three developers. Scanners keep finding weaknesses in that software, and the vendor has to choose which ones to fix first. The clinics will see updates arrive in bursts, and some weaknesses will stay open for months, while attackers use the same kind of AI to look for them.
The clinic manager cannot fix the code, but can do two things: turn on automatic updates, and ask the vendor how long it takes to fix a serious flaw once it hears about one. A vendor that has a clear answer is in a much better position than one that does not.
The bill will fall, but the work will not end
Bank of America's chief executive expects the spending to shrink once the backlog is cleared. I think that is half right. The year 2000 repair had a deadline: once the code was fixed, the job was over. This work has no deadline, because each new model can read the same old code and find more. So patching becomes a permanent job, like keeping books, rather than a project that finishes.
What falls is the cost of each fix. The old repair tools worked because the year-2000 problem had a pattern that a program could recognise and correct. Security flaws are less uniform, but the same kind of models write and review code every day, so drafting a candidate fix is within reach, and a person can check a draft faster than write one from scratch. If that holds, the 1,000 contractors are the expensive early phase, and the work will move from people typing fixes to people deciding which fixes to trust.
For people who know old systems well, the next few years look like the late 1990s again, when that knowledge was suddenly worth a lot. For everyone who buys software, the useful question for a supplier is how fast it fixes a serious flaw once it hears about one.