Recently I've seen coworkers frequently turn what should be a <10 line bugfix into a 500+ line refactor across multiple files. I suspect it's due to AI.

There's a time and place for refactoring, but just fixing an isolated bug isn't it. But I've seen that often AI can't help itself from making changes you didn't ask for.

I'll admit that I've done that type of bugfix in the past. Though, usually it's because the bug is caused by an underlying design flaw, and the 10-line fix would have only papered over a single instance of the bug, and wouldn't actually solve the underlying cause.

This is a major annoyance for me. In one PR I reviewed recently, it introduced concurrency where it was not needed and then cascaded to a bunch of synchronization logic everywhere as a result. What could have been 30 lines or so turned into a couple hundred line diff and the submitter did not think to question it. It was harder to review and introduced a potential for data races with zero benefit. These are all competent people I work with, who do good work normally too.

On the other hand, how do you know what they're prompting? For all you know, the AI proposed the hacky 10 line fix and tour coworker was all hey let's fix this problem better.

Before AI, "now" was seen as the wrong place for a refactor because of the time and effort involved, but if the hacky patch of a fix is roughly the same amount of wall clock time as a 500 line proper fix that makes the problem go away forever, what's the argument that the 10 line hack is actually better?