AI is rewriting 40 years of legacy code and nobody is counting the new bugs

The PHP2Shell timeline is the most useful data point in the current argument about AI and old code. I think it cuts against most of the people citing it. A researcher at Calif, working with AI tools in an audit that OpenAI sponsored, took a crash report filed against PHP in 2024 and turned it into arbitrary code execution in under two weeks. Wiz then confirmed and extended the findings. After that, four engineers at the PHP Foundation spent two months building a patch. Finding the attack took one person a fortnight. Closing it took roughly eight engineer-months.

Matt Suiche of Tolmo described the moment to IEEE Spectrum as a reckoning: “Now it is time for the technical debt to be paid off.” I like the energy but I think the metaphor gives the wrong idea. Debt implies a balance you can clear by doing enough work, and AI is very good at producing work. The PHP bug sat untouched for two years because maintainers looked at it and judged it a crash, which is usually unpleasant but harmless. That was a misreading of what the code meant. Suman Jana of Columbia says the exploit needed a lot of specific reasoning that is painful to do, and that AI handles that reasoning well. So AI sped up the attacker’s understanding. The understanding the defenders lacked in 2024 is still something a human has to supply.

I went into the research expecting the case for AI clearing legacy code to rest on defect data. I was surprised to find the strongest evidence measures speed. Google’s January 2025 preprint on internal code migrations reports that 80 percent of the code changes were written entirely by AI, with time savings of up to 89 percent in some cases. Every change had to pass unit tests, and an expert had to start each run. As engineering, this is impressive. But the outcome being measured is whether the migrated code passed its tests and how quickly it got there.

Unit tests on legacy code record what the code currently does, and the PHP2Shell flaw was something the code currently did. A migration that passes every existing test will faithfully reproduce an undersized memory allocation, because no test ever said that allocation was wrong. If the new code is written by a model, there is also the matter of what it adds. Veracode’s 2025 GenAI Code Security Report tested more than 100 LLMs on 80 coding tasks. It found that the code worked but introduced security flaws in 45 percent of cases. When the models had a choice between a secure and an insecure approach, they chose the insecure one 45 percent of the time, and Java code failed on security more than 70 percent of the time. Veracode’s October 2025 update gave the same 45 percent figure.

Put those together and an AI migration carries old bugs across and adds new ones at a rate Veracode has measured, while the number of bugs it removes is unknown. Nobody I can find publishes the net figure. Old code that has been exercised in production for decades has, at least, had its common failures found and fixed. A freshly rewritten module loses that history and has to rebuild it with real users.

The serious answer to all this is formal verification. Jana is optimistic about tools such as the one Anthropic released on 22 October. In that setup an LLM writes the patch, another LLM writes a proof that the patch is correct, and a formal checker that does not hallucinate checks the proof. Of everything in the article, this is the idea I find most encouraging, because a checked proof is a real measurement. But a proof only certifies the property someone chose to state. PHP2Shell happened because nobody had stated that this particular crash mattered. Verification can make patching cheaper once a person has decided what correct behaviour is. It cannot make that decision, and Google’s numbers show an expert still pressing the button on every run.

Matthew Green of Johns Hopkins expects something bad enough to upset ordinary people around early 2027, and he expects the funding to follow. If that funding goes to AI rewrites judged on hours saved, I think we will pay for the same flaws twice. If you are running or buying an AI migration this quarter, tag every machine-rewritten file now. Then track security bugs per thousand lines in those files over the next twelve months, alongside the code nobody touched. Any vendor whose case study gives you developer hours and not that ratio is selling you speed, and I would not assume it also buys you safety.

Prompted by PHP2Shell and AI Put Half the Internet on Edge, IEEE Spectrum.