I just fixed a bug where someone had sent an LLM-generated fix. At first glance, the LLM fix was mostly right, except for a redundant atomic fence (LLMs seem to love __atomic_thread_fence in this codebase, no idea why).
But then I went to fix the bug. The problem was that a lock was initialised too late and so could end up being initialised twice. Ooops, locks are not meant to introduce concurrency problems!
And the LLM fix moved it earlier, so that's fine.
Except... there's another way that the object containing the lock might be reached via a global pointer and that didn't have any guards. I don't think it's possible to trigger the bug that way, but some of the future changes that I'd considered might introduce that as a path.
And there's no real reason for anyone to want the object without the initialised lock, so moving the initialisation to just before the point where any other thread might reach the object is a simple fix.
But that isn't what the LLM proposed. Instead, it fixed the immediate issue without any reference to the long-term impact and maintainability of the codebase.
My fix was a fairly simple change: one new line of code, four new lines of comment, and six deleted lines of code (so worth doing for code readability even if the bug hadn't been real). And even a change that small, if you accepted the LLM recommendation (three new lines of code, no new comments, and six deleted lines), would have made the code less maintainable and more subtly broken.
And that's why I refer to these things as Technical Debt as a Service.