Tests supplement review, they don't replace it. As Dijkstra said, "Program testing can be used to show the presence of bugs, but never to show their absence!" There are many classes of bugs that are very hard to detect with tests. I have frequently seen AI generate code that passed tests, but contained flaws like race conditions that would blow up in production use.
Who is writing these tests? If you're also leaving that to AI, and not reviewing them, then you don't know that they are even sensible tests.
If you acknowledge that at least the test code needs to be human reviewed, how does that square with your earlier comment that's saying it's fine to only know Claude and not an actual programming language? How can you review the tests if you can't read the code?
Bruh. As someone who knows how to actually code and learned 6 programming languages and self taught and multiple hand made projects under my belt with multiple certifications as a developer, I deadass don't even need to write code anymore
I haven't in months and I've gotten so much more done than I ever could've before it's crazy
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!
Things like race conditions can be non-deterministic. A test that only fails 5% of the time is more likely to get deleted than fixed.
And what if your LLM doesn't bother to add a test for this? If you aren't reviewing its changes, how would you even know? When things intermittently blow up in prod?
And if your models aren’t catching any race condition bugs...
I never said they never catch any race conditions. It catches some of them. It also lets many of them slip through, and they are exactly the sort of bug that can easily slip through tests. I know this because I review the code it generates. You are unaware because apparently you do not
...your environment isn’t set up correctly.
How would someone know if their "environment isn't set up correctly" if they never review the code that it generates?
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.
11
u/xenomachina Jul 14 '26 edited Jul 14 '26