Comment by nonethewiser
21 hours ago
I am shocked how many bugs AI finds in the gray bearded wizards code at work. Just tons of stuff I didnt catch and I assumed wasnt there.
21 hours ago
I am shocked how many bugs AI finds in the gray bearded wizards code at work. Just tons of stuff I didnt catch and I assumed wasnt there.
I’ve had this experience as well where it is finding all kinds of subtle bugs. The trouble is when it lulls you into checking its work a little less carefully and you let some of its bugs slip through as well. Definitely had a few of those happen to me at work.
The problem is also that enticement thing it does. Over representing the importance of some bugs or introducing more complexity to squash something that doesn’t matter.
If you aren’t 100% on it the entire time it’ll make 4 bugs for each solution and then write tests that hand hold the nonsense through. The juice isn’t always worth the squeeze and it messes with your ability to parse it all.
...and at some point you wish you hadn't looked at the code at all, then you could have the blissful ignorance and optimism of a vibe coder.
Being a gray beard myself. I am hardly surprised, we used to find many of these through users in production.
Yes, working on a customer's 20 years old software architecture in logistics it's fascinating in a horrifying way how many of those "it only affects 1-100 supply chains" bugs are in production.
It's less gray bearded wizards than the fact that they used cheaper crazy cackling goblins to write the software.
The challenge is to determine if a finding is an important bug or just a dead business process now never called in production. That is knowledge the AI does not have, and it requires careful, exhausting work of going through the problem.
i mean, you way is certainly one way..
but ai is perfectly capable of adding/enable matching monitoring so you can check what processes are used... or ai can
The amount of crazy stupid bugs in the 8-year-old codebase I work on is shocking. Every time I work on a new subsystem I end up fixing 20 incidental bugs; lots of N+1 query problems, completely wrong type annotations, all kinds of things.
I was under the impression that the point of strict types was that the code wouldnt compile/run with wrong type information.
This _is_ how strict types work. Problems creep in when people introduce lax types into the strict type system.
dict[str, Any] is a type, and sometimes it is the right type to specify, but most of the time it's used by someone who wants to shut up the type checker rather than think about the right type.
2 replies →
> type annotations
Stopped reading right there
Are the bugs there though, or the LLM says there are?
LLMs are no trained to say "no". They are likely to find a ton of bugs in a simple "Hello, world" than generate "no, there are no bugs".
On top of that: if there are possible bugs in an isolated piece in code they find, are those bugs actually there?
They're there, but in my experience, lots of them are for edge cases that almost certainly wouldn't have been hit in prod. I think this is a major reason why LLM-generated code can be much longer for the same problem than human code. Humans won't think of every edge case, and occasionally that bites them in the butt, but they also won't cover all the edge cases that happen rarely enough that they will not matter.
I'm unsure what the right solution is. I currently tend to let LLMs resolve these bugs because it does fix genuine issues that would have affected real users. But this also means that LLM-generated code is often twice as long as what I would have written, and much of it is for defensive behaviors that will never matter in prod.
I noticed the same thing at work, the code is very defensive, and often the case could not happen in prod, so my solution at the moment is to make it prove that an issue can happen and try to measure how frequently it would happen with real data. That's often enough to realize that a particular defensive measure is not needed and the code complexity decrease as a result. And it's something we can automate.
I think it's an important point because the more complex the code become the harder it will be to maintain it, so hopefully this process will improve.
The priblem is, actual bugs that may exist end up being covered in an avalanch of code to cover possible and often purely hypothetical edge cases.
Was the actual bug fixed? Hard to tell among the 150000 new unit tests and a million lines of new code.
---
Anecodtally: ran an "adevrsarial review" on a Stripe integration for a side project. Dozens and dozens of issues, thousands of new lines of code added as a result of the "review".
Looking at issues and code closely: none of the bugs or issues were bugs or issues. None of the flows were relevant to the project at hand, and would've never hit the possible bug paths. And on top of that a lot of functionality was duplicated or triplicated in the "fix". Had to revert a lot of commits.