[torben-friis]

There is certainly a certain... entitlement? (It's not the perfect word, but I fail to find a proper term) from some of the vibe crowd. Like an attachment to the output and refusal to accept that most of the work was not theirs.

It is seen in the way they approach contributions but also in regular language. I created X, insistence that their 'curation' was very influencial to the output, difficulty to mention LLM contribution, attitude of 'I care about building while others lose time in details', refusal to engage with potential flaws, and so on.

It is surprisingly different to what I'm used to from senior devs, which behave like they always suspect their own work is flawed and half assed. Like impostor syndrome was reversed.

[progbits]

I've experienced the following sequence more than once at work, and I remain baffled by it each time:

- Receive a huge vibecoded PR for complicated new feature.

- Complain that this needs some design doc to figure out the right approach first.

- Author says no need for design doc, easier to have vibed implementation and discuss the concrete code instead of abstract document.

- I disagree (obviously), but review the PR with feedback along the lines: this entire approach is flawed, throw this out and start over.

- Author gets defensive, says "but this is already working and ready, let's just merge".

- I tell them there is no chance in hell this is getting merged. They go sulk to their manager that I'm not interested in helping them launch.

[gedy]

> helping them launch.

I think that's probably the key - sounds like you are at a place that rewards "launches" and not long term maintenance and so you are ruining their KPOs or promo packet or whatever.

[coryrc]

That's every place :(

[philovivero]

SRE.

"You ship it, you take the pager. Once it's stable, then SRE org will take the feature. If it gets unstable again, SRE will hand it back."

If someone vibe codes something, and it works, then no reason not to merge it. So just set it up so if it doesn't work, they're on the line to fix it.

Along with their oh-so-supportive manager.

But also, if you have the clout, doing what you're doing nips the problem in the bud earlier, and so is more efficient. Good that you have the clout.

[einpoklum]

> They go sulk to their manager that I'm not interested in helping them launch.

But what happens if:

* You're not the only possible reviewer, and they get some patsies / kool-aid drinkers to approve the PR?

* Their manager is also the code repository owner?

:-(

[skydhash]

> It is surprisingly different to what I'm used to from senior devs, which behave like they always suspect their own work is flawed and half assed

I never trust my own code. And one of the motivations of trying to be fluent with my editor, is to be able to quickly look at it when a bug is reported. I also don’t trust another person with their description of their code. Any surprise, and I’m looking at the source if it’s a available.

[einpoklum]

> 'I care about building while others lose time in details'

Them's fightin' words.

A person who says that to me - I ban them from... well, actually, I don't believe in banning people from platforms. Let's say I put them in my basket of deplorables.

[artyom]

I agree it's not "entitlement" specifically but there's something there. I guess by now everyone has experienced that type of person that "tries to help" by copy/pasting a bunch of AI slop and expecting you to work through the cognitive load of validating it.

The original post sums it pretty well, such big output inherently meant big effort, which was a proxy for good faith. Now that's gone.

[Sharlin]

It was a proof of work system. When work becomes cheap, it stops being proof.