social-app/CLAUDE.md at main · bluesky-social/social-app

The Bluesky Social application for Web, iOS, and Android - bluesky-social/social-app

GitHub
I mean when I check my feed much of the Bluesky eng team seems to be posting about how great Claude is all the time so I have been background wondering how common vibecoding is in that ecosystem
Let's see if anyone on Bluesky / the ATmosphere can say more https://bsky.app/profile/dustyweb.bsky.social/post/3mg6qipl6a22o
Christine Lemmer-Webber (@dustyweb.bsky.social)

Curious if vibecoding / AI agent assisted dev is currently common in ATmosphere dev? The feelings about AI generated code are def different on here than on fedi, so... I see a CLAUDE.md in bluesky-social/social-app https://github.com/bluesky-social/social-app/blob/main/CLAUDE.md

Bluesky Social

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

Why (@why.bsky.team)

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

Bluesky Social

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?

Also https://bsky.app/profile/pfrazee.com/post/3meogr22l3k2d

> A year ago, I thought LLMs were kind of neat but not that useful. I saw the code autocomplete and thought, meh.
>
>Last summer just flipped. I never ever thought I would see automated code generation like we see now.
>
> I know there’s baggage but you need to know the coders are being real about this

Paul Frazee (@pfrazee.com)

A year ago, I thought LLMs were kind of neat but not that useful. I saw the code autocomplete and thought, meh. Last summer just flipped. I never ever thought I would see automated code generation like we see now. I know there’s baggage but you need to know the coders are being real about this

Bluesky Social
Samuel (@samuel.fm)

I'm thinking something like this

Bluesky Social

Welp, there we go https://bsky.app/profile/why.bsky.team/post/3mgaqaaisfs2e

> Oh interesting, people who don’t know how to build software are getting mad at my post about building software. Cute.
>
> Let me be clear, over the next year, the job of software engineer will shift dramatically to no longer have typing syntax into an editor as its primary time sink.

Why (@why.bsky.team)

Oh interesting, people who don’t know how to build software are getting mad at my post about building software. Cute. Let me be clear, over the next year, the job of software engineer will shift dramatically to no longer have typing syntax into an editor as its primary time sink.

Bluesky Social
@cwebber yeah he's still his insufferable arrogant idiot self
@cwebber Typing is their primary timesink while developing? Not thinking?

@KatS @cwebber Well, I lost it when I heard folk talk about the benefits of generating test code.

This is what validates your spec (what you think the code should do) against your implementation (what your code actually does).

If you must generate code, generate everything *but* the tests.

@cwebber The idea that the primary timesink of a software engineer is typing is bizarre.
@itamarst @cwebber even for me it isn't and I am frankly terrible at not looking up stupid syntax questions all the time
@itamarst @cwebber I know, right? I find it really puzzling when I hear this idea that software engineers spend our time just typing.
For me, it varies depending on whether I'm adding new functionality, modifying existing, or bug-fixing, etc. but I'd say I spend most of my time reading and understanding existing code and the model it represents, and reconciling that with expectations about what it should be.
Actually typing code is usually a small of it for me, but I wouldn't throw it out as I want to be sure it reflects the real work that preceded it.
@cwebber I'm really not a huge fan of how ready people seem to be to just completely relinquish their ability to code. It does not take long for your brain to wallpaper over entire skillsets.
@cwebber also, I can see this type of situation very, very easily spiraling into a classic "death by convenience."
How long until the primary engineers no longer understand the how their program is built or what motivated ostensibly insignificant decisions that eventually add up
@cwebber yeah, least surprising Bluesky thing to do
@cwebber they're owned by crypto cultists, so it tracks.
@cwebber Over in ATProto-world, I'm not even seeing most people's profile pictures. They're just showing up as the default icon.

@cwebber before* any judgement on whethe it is a good thing or not, it was expected, tbh. it is very much on brand from their team.
they always had the "tech enthusiast" ethos

*just before.

@corujosilva @cwebber the team started as coiners, so they were very hot for AI

@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.

@cwebber @res260 I feel like there's always been a lot of software development that isn't craft but it's just shuffling bits around.

I don't really know how to feel about a lot of it these days. I've played around with some of the tools for work and there's certainly a lot of areas where they can write basically the same code that I would have done with less tedium, and by some metrics they do a better job (mostly things that are good practice but I couldn't be bothered).

Is that abandoning craft or careful allocation of executive function? I don't know.

I definitely think these things aren't going away. The bubble will pop, it'll maybe kill the big AI companies, people will stop shoving chat bots everywhere, but I don't see any way that LLMs don't remain a fact of life, and I don't know what the long term implications are of this
@erincandescent @cwebber I agree, I think a lot of people don't consider their code craft, but maybe the final product more so
@res260 @cwebber even a craftsman is sometimes just doing rote tasks
@erincandescent
@res260 @cwebber we have tools for that tho? templates and libraries and bootstrapping and automation tools. they don't have to be, as @olivia so said a couple month ago "made from shit and blood"
@fay @res260 @cwebber there's lots of code for which no reusable template could be created that is nonetheless rote
@fay @cwebber @res260 is this a failure of ours? Perhaps. But it's the sum product of millions of small failures, not something easily corrected
@erincandescent @res260 @cwebber with the hundreds of billions of dollars burned to make stochastic code generators that only sort of work (and at horrific ethical costs), i dare say that we could have developed adequate tooling instead, and we still can
@fay @res260 @cwebber it's a coordination problem, not an effort problem. If everyone agreed to use the one serialisation format with the one schema language, with the one runtime environment, ...
@erincandescent @res260 @cwebber i mean a lot of people are agreeing to use the one llm right now, it seems
@erincandescent @res260 @cwebber respectfully, that's not my experience :) If the task is specific enough to require human intervention, then it shouldn't be left to a stochastic code generator either

@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.

@benjamineskola @res260 @cwebber is this an argument of quality or of morals?

Because morals.. people can have different views on. But quality is very much about the end result
@[email protected] @benjamineskola @res260 @cwebber If the thing isn't "make once and forget" the process is very much part of quality, because it decides if the thing is maintainable.
@airtower @res260 @benjamineskola @cwebber two projects with identical code are, modulo institutional knowledge, equally maintainable; would you disagree?

@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.

@benjamineskola @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.

I know these are problems, but you’re moving the topic of conversation. There have always been bad developers with bad practices shovling crappy code over the fence. LLMs have made this easier and it sucks but it’s not new.

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.

Sure, but lazy/careless people use tool to produce bad results is not a unique problem. It’s very easy with a power drill to make messy holes, but we arent’ forcing everyone to use hand drills.

Saying using these tools results in necessarily bad output is just not backed up by available evidence.

I don’t pretend they’re perfect and I don’t pretend there aren’t problems. What I sense is that they’re not going away and are going to become and remain routine parts of toolboxes long into the future.

@erincandescent @res260 @cwebber @airtower > LLMs have made this easier and it sucks but it’s not new.

So why would we want to make it worse?

> Saying using these tools results in necessarily bad output is just not backed up by available evidence.

Every output I've seen from these things has been, at best, no better than a human would have done. And that's being generous.

> What I sense is that they’re not going away and are going to become and remain routine parts of toolboxes long into the future.

This is a self-fulfilling prophecy. Of course they won't go away if people insist on defending them.

@benjamineskola @[email protected] @res260 @cwebber Yeah, this. If I'm looking at a new tool/library to possibly use (and not do a hard fork on), a key question is: Are there people who understand and care maintaining this thing? Because if there aren't, eventually "hard fork" or "don't use it" will probably be my only choices.

And using LLMs to generate code points towards "no" (or at least "not much") for both understanding and caring. If someone skilled is actually putting in the effort to edit LLM output until it is no worse than what they would've written themselves (point for care at least), chances are it would've been faster (let alone other effects) to just do that.
@airtower @res260 @benjamineskola @cwebber I still see LLM related artifacts as a negative quality signal. There's lots of crap LLM aided code out there and there's lots of people slopping stuff together. The worst developers are disproportionality interested.

But I think there's a lot of stuff being written with LLM assistance these days where you'd not be able to tell
@[email protected] @res260 @benjamineskola @cwebber That might be, but as I wrote in that case I doubt there's any benefit (like faster progress) to the developer (even looking at code only, ignoring all the harmful side effects of LLMs).

@erincandescent @res260 @cwebber @airtower Given that every output of LLMs that I've seen that is identifiable as such has been mediocre at best, why would I assume without any evidence that there's a significant quantity of LLM-generated code that's actually good?

"There's no evidence of it but it's definitely there" is unpersuasive.

And I've also found that people's evaluations of LLM-generated code quality is wildly out of step with my own evaluations, so I would not automatically assume that because someone says it's good that it's actually good.

And then, even if the code was of acceptable quality, the negative effects on the process (increased difficult of reviewing ↔ decreased institutional knowledge, among other things) count against it too.

(And all of this is setting aside the ethical issues, which in practice I don't think we should do anyway. Like, even if LLMs produced good output they'd be ethically indefensible, and even if they were ethically acceptable the results are so poor that why would you bother with them?)

@erincandescent @res260 @cwebber I am no fan of tedium for tedium's sake... but why specifically slop machines, which are notoriously unreliable, to solve this problem, aside from all the money that got poured into this technology? Could the same money have been used to develop languages and frameworks with sensible defaults and configurations, thereby eliminating (or vastly reducing) the need for tedium?

@sitcom_nemesis @res260 @cwebber I think there’s a spectrum

There’s code we keep repeating in broadly the exact same structure, just with different details fileld in. That’s boilerplate.

There’s code that’s unique and creative and requires thought. That’s “the meat of the problem”.

But there’s lots of stuff in the middle where it’s not quite creative, doesn’t really require thought, but either because of domain requirements, accidents of history, or just because you’re gluing two libraries together that hadn’t ever seen each other, is too irregular to really code generate but is not actually interesting.

@cwebber
thanks for yet another reason to avoid bluesky
@cwebber technical debt will be off the scale in no time.

@cwebber Earnest and also deeply befuddled question:

Do you happen to know if this "Why" is the same "Why" who wrote "Why's? (Poignant) Guide to Ruby"?

(Seems very unlikely to be the same person—but I'm so out of the loop that this name confusion also feels like when people are excitedly talking about the Swedish metal band "Ghost" but I mistakenly think they're excitedly talking about the Japanese experimental psych-folk band "Ghost".)

@ryanrandall it's whyrusleeping

@ryanrandall https://github.com/whyrusleeping

pretty sure not the Ruby "Why" but I don't know for sure

whyrusleeping - Overview

Error: merkledag: not found. whyrusleeping has 284 repositories available. Follow their code on GitHub.

GitHub
@cwebber Thank you Christine!
@cwebber @ryanrandall My memory is that why_ said goodbye and disappeared one day and so we can’t know for sure but it’s unlikely (and if they are the same person, well, they don’t want to be connected)
@erincandescent @ryanrandall @cwebber its not the same Why. They both have photos of their real face on the internet I checked.
@liaizon @erincandescent @ryanrandall @cwebber this is the one from the mirror universe
@cwebber @ryanrandall Nah, definitely a different Why - you can find the Ruby Why's real name and the Bluesky Why's name also appears from time to time and it's not the same name
@ryanrandall I honestly thought I was the only person on earth going through that specific Ghost/Ghost confusion