LLM refactors code into infinite loop

Here’s a lovely example of an LLM going awry in a deployed software product, causing a service to slow to a crawl.

A section of code was “refactored” by an LLM – meaning it was restructured without intending to change its behaviour. The refactoring involved moving a block of code between files, but in the process the LLM made a subtle edit that did dramatically alter the code’s behaviour.

Originally, the code included a loop that checked for errors on each iteration. If an error occurred, the loop exited. In the refactored version, the loop instead continued after encountering an error, which meant that errors became infinite loops. This tiny change – in code, the word “break” becoming “continue” – was missed during human review, buried among other edits. But if a human developer had done the refactor, they probably would have copy-pasted the entire block and so preserved the original logic.

Here’s the software company’s blog post explaining what happened.

Software crisis

History has valuable lessons on AI. Many of us are aware of the replication crisis in social science. Were you aware of the software crisis, first famously discussed at the NATO Conference on Software Engineering in Garmisch, October 1968? We have got used to software being buggy, updates being required on a near-daily basis, often to fix security vulnerabilities – and, given the vast number of high profile cyber attacks, often too late. People are now suggesting using large language models, trained on code people have dumped on the web, to write software. Software testing and static program analysis are going to be more important than ever, whether you’re evaluating internet-connected apps or statistical analysis code.

The original reports are available online. It’s worth having a browse around to see the issues. In 1968, hardware and software had a tiny fraction of the computational and political power it has now.