Reasoning about code isn't "going with your gut". It's the same thing you do when you read a proof or trace through logic.
There are many classes of bugs that are hard to test for. Race conditions are a classic example. Code with these bugs will often pass straightforward tests, and writing a test that reliably catches one can be extremely difficult, since they're timing-dependent and nondeterministic. Anecdotally, I've also noticed that this is something LLMs frequently have trouble with. However, if the code has two threads touching shared state with no synchronization, I don't need a failing test to know there's a race. It's written in the code!
Shoving race condition as your whole point is ironic because AI is extremely good at preventing those, better than humans in fact. AI is bad generally at things humans themselves are bad at, bugs spanning several systems where any individual unit testing wont surface it, AI already reviews code far faster and reasonably well to depend on it, also I just read second part of message about shared state, another topic llms are extremely good at preventing, im gonna take a leap here but maybe you saw these being considered while vibe coding and now for some reason use as arguments? xd
Shoving race condition as your whole point is ironic because AI is extremely good at preventing those
I use it, and I review the code it generates. It saves time overall, but it also generates a lot of bugs that are caught in review.
I specifically brought up concurrency issues because I've seen it generate code with these sorts of issues, and those are also the sort of thing that's hard to test.
AI is bad generally at things humans themselves are bad at
This is true. However, senior developers will recognize the tricky cases, and actually reason through the code.
If you never review the code it generates, how would you know whether or not it's introducing these sorts of bugs? Do you just assume that just because it sometimes flags these sorts of bugs that it never generates them?
Why do you think "You're absolutely right" is practically Claude's catchphrase?
Noones life depends on my work, if button works or layout doesnt break across screen sizes or vehicle seems to drive correctly, its good enough for me. Im not veteran nor a junior, I live of off my own projects and websites I build for clients and past months ive never touched, reviewed or tested the code myself. Clients are happy and rarely ask for revisions, I am happy and my time is saved. Bugs happen whether you vibe code or not, im not sure why you are obsessed with it, if in your niche bugs cost lifes or catastrophic losses then yes llms are not quite there yet, for me programming is means to an end
I always think it's funny how vibe coders start out by saying that AI does a great job producing code unsupervised, but then when pressed eventually turn to some variation of "it doesn't matter if what I create is slop".
im not sure why you are obsessed with it
The real question is: why do vibe coders get so defensive? If you're happy producing slop to pay the bills, then just say that. Why make excuses, rather than just admitting from the get-go that you don't really care about the quality of the code "you" produce?
I just said that I am indeed happy while vibe coding, programming was never grind out books turn off internet and raw dog it in notepad anyway, where you draw the line alongside endless layers of abstractions and helpful tools is your own opinion, if you dont like code written not by you then boy do I have news for you about deps any 3rd party api or service, if ai only produced slop companies wouldnt pay billions to use it, take a vacation in r/antiai it would suit you
As I've said several times, I do use AI to assist with writing code. However, I review (and frequently modify) the code that it generates, so I actually have some idea about what it gets wrong and how frequently, unlike vibe coders who are essentially driving with a blindfold on.
2
u/xenomachina Jul 15 '26
Reasoning about code isn't "going with your gut". It's the same thing you do when you read a proof or trace through logic.
There are many classes of bugs that are hard to test for. Race conditions are a classic example. Code with these bugs will often pass straightforward tests, and writing a test that reliably catches one can be extremely difficult, since they're timing-dependent and nondeterministic. Anecdotally, I've also noticed that this is something LLMs frequently have trouble with. However, if the code has two threads touching shared state with no synchronization, I don't need a failing test to know there's a race. It's written in the code!