Example: https://bsky.app/profile/why.bsky.team/post/3meomclcfss2w

> Until December of last year I was using LLMs as fancy autocomplete for coding. It was nice for scaffolding out boilerplate, or giving me a gut check on some things, or banging out some boring routine stuff.
>
> In the past two months Claude has written about 99% of my code. Things are changing. Fast

I have this suspicion that the ATproto stack, at least the stuff from Bluesky, is heading towards "majority-vibecoded" but that's mostly just from seeing a lot of posts from the Bluesky eng team rather than me having spent much time in the codebase

Why is def hugely responsible for much of Bluesky/ATProto's design and if *he's* mostly letting Claude write 99% of his code, the rest of the eng team is likely to be heading in that direction too?

@cwebber I'm hanging out there a lot and yes there is a lot of vibecoding. However, they don't seem to vibecode more than the average paid software dev.

In 2024, I'd say about 20% of my friends vibecoded. Today the number looks more like 90%. This is not specific to atproto, my understanding is that most people vibecode nowadays.

@res260 Sadly a likely observation :\

So many people just giving up on their craft.

@res260 @erincandescent @cwebber if you care about the final product, surely you should care about how it’s made?

I see so many apologists for LLM usage recently trying to distinguish between the outcome and the process, as if the quality of the outcome isn’t defined by the process.

@erincandescent @res260 @cwebber @airtower

'modulo institutional knowledge' is doing a lot of heavy lifting there since that's half the problem with LLM usage

and the other half of the problem is the assumption that an LLM will produce identical code

so I don't think there's a useful discussion to be had if those are your assumptions

@benjamineskola @res260 @cwebber @airtower Look, I don’t think we’re talking about (original definition) vibe coding here, where nobody is looking at the output. We’re talking about cases where there’s a human in the loop.

If the tool is generating garbage code and the human is accepting it, that’s a human problem more than a tool problem.

I start from this assumption because we assume the human is competent and has taste. I assume they are not just letting the tool run wild on the codebase and make a mess.

There are issues and questions around institutional knowledge (if the human isn’t exploring the codebase in the same way, how much are they learning? how much do you pickup through review vs implementation?) but even then I’d argue that one of the primary criterions with regards to maintainability is how hard it is for a newcomer to pick something up and work on it.

@erincandescent @res260 @cwebber @airtower Except there is a huge problem with people actually just not looking at the code being generated. The wave of slop PRs inundating many open-source projects recently, for example.

People keep saying 'of course there is a human in the loop' but it seems increasingly clear to me that nobody is actually bothering to be the human in the loop themselves.

(Edit: but also, even when people are well-intentioned, I think the LLM-based process just makes it much harder to ensure quality than actually writing the code oneself.)

And yes, this is a human problem, it's all a human problem. But that's like saying 'guns don't kill people, people do'. True, but, the tool clearly exacerbates the problem.

As for your final paragraph I don't remotely see why you think LLMs solve this problem either.