hm https://github.com/bluesky-social/social-app/blob/main/CLAUDE.md
-
@n_dimension @andymoose @cwebber @thebluewizard Granted, "#VibeCoding" is just a different term to "bossing around #AI until it does 50% what it should do and calling that a success when a #Skiddie copypasting shit would've done a better job even when half the amount wasted on *"#AI" Tokens...
@andymoose @cwebber @thebluewizard @kkarhan
"Bossing AI around" is actually a very good description of #vibecoding
I call it "Hitting the machine with a stick" (like a recalcitant) mule.
However, the accuracy is significantly better than 50%
Granted, #Ai will get into the weeds sometimes.
But because I was a shit programmer before Ai (slow and dim) Vibecoding makes me better.
There were times I would get stuck on a bug for a day, with Ai, I can mush it in 15 min max.In my experience, majority of errors are regex or basic syntax, my Webby got carded last night because the Ai commented out whole anti-carding logic by accident, even though I got it to check it twice.
Each fuckup makes you write better prompts.
-
@andymoose @cwebber @thebluewizard @kkarhan
"Bossing AI around" is actually a very good description of #vibecoding
I call it "Hitting the machine with a stick" (like a recalcitant) mule.
However, the accuracy is significantly better than 50%
Granted, #Ai will get into the weeds sometimes.
But because I was a shit programmer before Ai (slow and dim) Vibecoding makes me better.
There were times I would get stuck on a bug for a day, with Ai, I can mush it in 15 min max.In my experience, majority of errors are regex or basic syntax, my Webby got carded last night because the Ai commented out whole anti-carding logic by accident, even though I got it to check it twice.
Each fuckup makes you write better prompts.
@n_dimension @andymoose @cwebber @thebluewizard I still think it's #WastefulComputing and doesn't really help oneself to become better at coding.
- Or not even better at reviewing and testing.
- At best it'll make one better at documenting requirements.
- Basically doing a shitty way to learn "Requirements Engineering"...
-
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
@cwebber
Bit of a tangent, but a few months ago, when tech nerds on bsky and fedi started talking about Framework being a milkshake duck, Bsky staff immediately started bragging how cool and fast and powerful their Frameworks are. -
@erincandescent @cwebber I agree, I think a lot of people don't consider their code craft, but maybe the final product more so
@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.
-
@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 -
@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@erincandescent@akko.erincandescent.net @benjamineskola@hachyderm.io @res260@infosec.exchange @cwebber@social.coop 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.
-
@erincandescent@akko.erincandescent.net @benjamineskola@hachyderm.io @res260@infosec.exchange @cwebber@social.coop 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? -
@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
-
@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 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 Ah yes, LLMs are finally good now, this is probably the fourth or fifth time I've heard it and at this point it's like the boy who cried wolf, I'm not even going to bother testing out the LLMs of today to see what they get wrong, I'm just not going to believe their advocates
-
@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 @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?
-
@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.
-
@cwebber Ah yes, LLMs are finally good now, this is probably the fourth or fifth time I've heard it and at this point it's like the boy who cried wolf, I'm not even going to bother testing out the LLMs of today to see what they get wrong, I'm just not going to believe their advocates
-
@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.
-
@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 But honestly bsky web UI felt like a one-shoted ‘vibe-coded’ Twitter clone even before it actually became one.
-
@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@hachyderm.io @erincandescent@akko.erincandescent.net @res260@infosec.exchange @cwebber@social.coop 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. -
@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.
