Discussion
Every time I see a vibe coder say something along the lines of "if you haven't used these tools over the past five minutes, you don't know what they're capable of, because everything's different now!" I get a little bit perplexed.
You do know that we can see the output without using it ourselves, right? Some of us are still reviewing pull requests and reading through code repositories, y’know?
@baldur Last time I said this I got a no-true-scotsman immediately in my replies, which was both funny and a little sad.
@baldur I don't have to hug the cactus to know it would hurt.
@baldur whaaaaat?! You are doing code reviews?! Just use another AI to do the review!*
* I hope it is clear that this is sarcasm.
@baldur I know nearly nothing about coding. But these people sound like the guy entering a 3-star restaurant's kitchen. The boss calls him for cutting meat. The guy: why should I use that special knife! If you haven't used that new US weapon that can slice up everything ...
@baldur “Capable of” vs what they are actually producing.
@baldur Did you see the Reply Guy lecturing Eugen Rochko (!) for having opinions about vibe coding, despite not having used chatbots himself? Basically everyone made the same point: you don't have to have "experienced" using the tech to assess the quality of its outputs.
Indeed, the elevation of subjectivity in this context looks very much like a form of "AI" psychosis. Of course Eugen is more than qualified to tell if the code is "spaghetti" (as he put it). 🤷🏻♂️
@baldur They are also so occupied with trying to sell courses and learning material to the others, who they think are simply misinformed about how great this new technology is.
And it's always business school graduates.
Believe me, I've tried this stuff and I spent more time refining prompts into the night than I ever would have spent checking that ticket off myself.
And mind you — it feels amazing and you get instant feedback but the results are overcooked for a lack of a better word.
@baldur The slop boosters always leave out a crucial part of the phrase because we absolutely know what sloptools are capable of (slop), what they mean by "you don't know what they're capable of" is "you don't know [how smart they make me feel as I accomplish nothing while offloading the real work to other people who have to review my slop]!"
@baldur I mean, they're not wrong. You ask LLMs to do the same task and you get wildly different results just 5 mins apart 😂
every time i see someone say "i've reviewed some ai-generated PRs, so i know what these tools are capable of," i get a little perplexed.
you do know that seeing bad code doesn't mean you've seen the best these tools can produce, right? some of us are actually building software with them, y'know?
I see it every time my coworker sends me an email.
Occasionally there is a gem of useful information buried somewhere among the reams of slop, but it takes so much effort to read it all that I'd probably have been better off not reading it in the first place.
@baldur@toot.cafe also, the majority of my reasons against it have nothing to do with how well they work (or not)
even in an alternate universe where slop tools were very effective, i would still be against them
@lumi Oh, agree completely. Same.
@baldur Aye. There have been meaningful changes, but the way I put it to people is: the November 2025/Opus 4.5 shift was from “the stuff they spit out doesn’t usually work” to “the stuff they spit out usually works… but it still isn’t *good*”.
It’s quite plausible to me that that change has *worsened* the quality of code coming across the line, because “works” is enough for some folks to say “ship it”. When it just didn’t work, you *had* to actually touch it, which may have helped… somewhat.
@baldur I would say (and in the past *did* say) that this was just a new version of the classic automation paradox, but the *classic* automation paradox involves higher performance than the baseline under normal circumstances. There are axes on which that is sometimes true here—adversarial review, e.g., surprisingly often does better than manual code review given existing code review practices (That’s its own topic of broken engineering practices, of course!) — but it’s not remotely all of them.
@baldur So it’s often ending up being a *worse* version of the automation paradox: the direct outcomes being anywhere from somewhat to significantly worse and the second-order effect still being deskilling. We tolerate the cost of the automation paradox in aircraft autopilot and similar systems because it significantly improves average outcomes. It doesn’t seem to be doing that here.
@chriskrycho It's interesting that the human factors paper that originated the automation paradox (https://en.wikipedia.org/wiki/Ironies_of_Automation) as well as much of the research that followed didn't focus on the idea of higher performance than baseline. The paradox kicks in as soon as the output is good enough to switch the human participant out of "participation" mode and into "monitoring" which is also more exhausting as it requires heightened vigilance.
@baldur Tried it on some embedded code this weekend. While it did work the thing puked out about 10x the lines a good human coder would have. Nothing elegant and no consideration for the specific application. I would say it took as long to just review the code than if I had created it from repo examples myself.
Install Fedizen
Get the full app experience
@baldur Soon it will become "if you're looking at the code, you're doing it wrong".