Yeah I've been experimenting with a bunch of different domains: 2D CAD, PCB design, coding obviously and recently I had Claude finish a project on all three fronts: finish the firmware(in rust because why not), change up a few components and finalise the pcb design, source all the non pcb components and do all the documentation for the installer. To be fair, it had a solid base to build from, but still, almost everything was "good enough", now I'm at work looking at PCB design that take the electrical engineers 8 weeks when I know I could have had two prototypes shipped and tested already. The fact is 90% of people are not doing the really hard stuff and Claude can just brute force pretty much any low to mid tier white collar task given enough information.

> What I'm saying is the quiet part out loud: A majority of coders and a majority of really IS bad....

How would you know "the majority" from your anecdotes? Maybe you just spent your career working with incompetent people who didn't care.

And actually there's a point I forgot to address earlier, in my first comment:

>>>>> The thing is: people quickly discover that even mediocre LLM-code with a mediocre LLM-review, is still better quality than what they hand wrote and hand-reviewed.

People whose hand-written code is worse than "mediocre LLM-code with a mediocre LLM-review" are not going to discover the LLM-code is better, because they typically don't care. That's usually the whole problem with that kind of person.

> ...And now a lot of that code is actually better (big win).

> Basically: the code was so bad before, that un-reviewed LLM-code is now better than the average contribution. That means, that at least short term, the vibe coding can increase quality.

> The problem is that it also increases code volume (bad) and rapidly decreases understanding (even worse).

You're contradicting yourself here. Even accepting your statements uncritically, it doesn't sound like a "big win." It sounds like a marginal improvement that's ultimately self-defeating.

Code volume and understanding can be tackled with a proper system prompt. Even afterwards, apart from costing resources, a cross-model optimization can increase quality of the output. Unix philosophy in the system prompt could be useful if the code wants to be worked on later again.