3 ms·
> One of the craziest damned things I hear devs say about LLM-based coding help is that they can’t “trust” the code that it writes, because it “might have bugs
by yellowapple 4y ago
> One of the craziest damned things I hear devs say about LLM-based coding help is that they can’t “trust” the code that it writes, because it “might have bugs in it”.
I can't speak for other devs, but when I'm talking about my inability to "trust" an LLM-based coding partner, it boils down to the lack of transparency around where that code actually came from. There have been numerous documented instances of Copilot and similar tools plagiarizing code verbatim from other projects, sometimes in ways that violate the license terms of the code in question; the last thing I need is to get nailed over an accidental GPL (or, worse, some EULA) violation.
- noirbot 4y agoI think it's also less about the bugs and more about the fact that the "thought" behind it is less predictable. If I have a random developer implement some basic function, I can have some confidence that it will cover all of the "normal" and obvious use cases for our shared intended use of this code. Because of how an LLM approaches it, I have to be more careful about what assumptions it may have made, and which edge cases it decided to have guards around, since there's often a lot of "invisible" context and state baked into even simple tasks. How a human would name a variable or a function reveals something about how they conceived of its use and purpose. How an LLM names things doesn't necessarily tell you anything about the code that surrounds it. This can make it harder to reason about the code at a time or skill distance.