I prioritized shipping over carefully crafting docs. I thought nobody would read them and they'd rather enjoy the software. I was wrong. I'll rewrite them.
Then, just do not add text that adds no value. Less is more.
Documentation is first part people see when presented. I personally hate AI written text even though I do agentic engineering a lot as well. Any user facing documentation must be reviewed, if you snoozy by reading it - remove or rewrite.
I do not care about paragraph long comments in code, because I’m not gonna read them, but I still follow my internal guideline and cut all this verbosity to level where it readable using hooks and skills.
So basicly like you said if you care about product do not add placeholders. It’s take away first impression.
Fair enough. But then, how should I enjoy the software, if the documentation to its' usage is buried beyond a whole paragraph? To be clear, I do not judge the usage of AI per se. But you can instruct AI to write a clear manual. It just takes time. :)
I think you got a but too much negativity, from a crowd that became more easily irratated because their AI sensor became very sensitive by e.g. reviewing a lot of AI generated code and comments.
I haven't seen any evidence of Spotify killing librespot. To me the project looks active and works totally fine. I don't have a new Spotify account to verify the claim above.
I suspect wilted-iris is conflating it with the recent changes to the Web APIs: new developer apps can't use all endpoints anymore. In Fastpotify if you add your Client ID I use both an older developer app and your app to keep everything as fast and seamless as possible.
Have a look at the librespot pinned issues, you’ll see the reports from folks experiencing this. You may also be able to find the legal threats they sent out to third party client libraries if you search carefully (many have been redacted.)
Yes, the code is generated. Yes, the docs are generated. I agree LLM copy is annoying and will rewrite them myself.
But I built this for myself out of frustration with the official client, and I use it every day, so every bug I find is fixed immediately. I also care about bugs and PRs from other people, as you can see the amount that have been closed on the repo. The only reason I would stop maintaining this is if Spotify kills it.
I also wouldn't call this vibe coded either. Human directed and LLM generated is fairer. It's been an intense 5 days with tons of design decisions and testing on 3 platforms. I think we need a new vocabulary to distinguish it from "author doesn't care". I do.
Also: nagging about the specifics of the README's tone of voice, while the 600-1000MB RAM usage drops to 100-250MB seems a little childish to me.
It's still open source! Just like in the pre-AI era they are welcome to submit a PR and improve it in the way they like it. The main dev seems very open to accepting help.
I don't see you publishing something which further reduces the memory footprint?
Given the project is open source, have at it! See if you can help improve it instead of complaining. This is a significant improvement and a cool project!
I run actual Winamp for my music streaming, and windows task manager claims it's using 4.1 MB.
Even that seems pretty high, but whatever, but given y'all are spending hundreds of mbs, I think I'm ok. Yes, spotify has features my subscription music service doesn't have... but the one I use lets me stream with Winamp.
I'm not complaining and it is a cool project (from what I can tell). But I think it's fair to say 200 MB memory usage is a lot without providing source code as a proof. Just by feel when you recall what were computers capable of when they did not have 100s of MB to spare.
I like the direction, but stewarded feels just a little too awkward to type or say to catch on. Perhaps "guide coded"? But it will be really hard to dislodge vibe coded from being generally applied to this concept, I think, in part because it is a catchy little term.
> The Debian Project nevertheless expects that all contributions submitted to Debian, regardless of how and with which tools they were produced, satisfy the same standards of quality, correctness, maintainability, and legal compliance.
Slop text on the homepage does not scream "quality" to me.
Don’t worry. Folks are entirely too concerned about the distinction between human made and LLM made. In a short handful of years, it will be incredibly rare to find something an LLM hasn’t been involved with
Agree, everyone thought I was crazy in 2025 when I was preoccupied with this question about moral 'authorship' in the AI era, but I think the culture will catch up quite soon, whether it likes it or not
I have no doubt that in the future AI code will be superior to human code. But today is not that day, and these projects that have never yet had human eyes on them are mostly shoddy pieces of work.
I rewrite docs myself on my own projects because they read as very LLMish, there's an intermediate stage which feels slightly less bad where I ask it to remove most of the comments, especially LLM signposting ones and then "rewrite any remaining comments and docs in a dry ukgov/gds style" which makes things slighyly less worse.
I'm going to sound harsh here, but please don't take this as criticism of the effort, it's criticism of how it's being portrayed. The quality might for all intents be great and useful.
> But I built this for myself out of frustration with the official client
But you didn't build it. This is akin to me telling an intern to build me a widget and then claiming it was me who built it. Or a construction manager saying they built a skyscraper.
Yes, the intern and the construction crew needs guidance and management, but I can't then go to the management committee and claim ownership of the effort.
> I also wouldn't call this vibe coded either.
You didn't write any of the code or even the documentation for that matter. You guided a code generator that relied on you to guide high level decisions but then did all the implementation on it's own. That's vibe coding.
Any act of making can be treated as product, as craft, or as art. You'll find yourself taking all three stances at different points. Any engineer or artisan or artist can choose to pour their attention and love into any layer of the production process.
I like ceramics. I like wheel throwing. Once upon a time, the pottery wheel was a newfangled technique for rapid and regular production of commodity goods. Same with coil building, same with slip casting, same with standardization of glaze recipes, gas and electric kilns, all of it.
But I know people who choose to quarry and purify their own clay, or to mix their own glazes, or to fire their pieces in a hole in the ground dug by hand with a fire they built by hand. I know people who make dozens of identical copies of just a few forms, after they spend months iterating on carving intricate molds. I know people who will spend a whole season working on a single hand-built bust.
And none of these people have ever, to my knowledge, expressed scorn for any of the others, for focusing on a different step in the process.
No they can't. The construction crew - which includes the manager - can say that they built a skyscraper.
If the construction manager did lay the bricks or did the majority of the work in all aspects, they could claim to have built a building. Otherwise they contributed work, no denying that, but they can't claim credit for building it. Same way that architects can't claim they built the skyscraper, even though they probably spent a lot of effort designing it to specs. To the best of my knowledge, no serious architect claims they "built" the building. They have designed it yes. Same way, the construction manager would claim they have managed the construction.
I admit that the classification is fuzzy, but there's an explosion of vibe coders going about claiming to have built things, whose contribution is basically spending a total of one hour with a prompt and and LLM doing basically all the heavy lifting.
That's not necessarily the case of the author here, but the line has blurred a lot and people very giddily claim credit for much less actual accomplishment than what would've flown in the past.
I think you're being pedantic to the point of losing all credibility. And you're gatekeeping in the worst possible way.
Your argument that using an LLM means you didn't "make" a thing could just as easily be used to say that if you used a framework or a library, you also didn't "make" a thing, because you didn't write all the code yourself and you didn't understand everything.
Would you say the authors of YT-DLP didn't "make" anything because they are a wrapper over FFMPEG and CURL?
If you produce something useful (even just to yourself), you "made" a thing.. It has a purpose, and it's useful. Who cares how you made it or how long it took?
For example I've made plenty of bash scripts over the years that were effectively thin wrappers that combined other tools, but they did something novel and useful that saved me tons of time, and I've shared those as gists or in other ways.
Some of these scripts took me mere minutes to make. I didn't use an LLM to make them, but the "heavy lifting" definitely wasn't in my script. No one ever showed up to berate me and try to tell me that I didn't actually produce anything useful in any of these cases.
So this "in the past" that you imagine where people were held to some bullshit standard for what is accepted as "making" a thing?
That past doesn't really exist, and if does where you are, it sucks.
People do care - lots of people do. Maybe you don’t, and maybe the argument the other poster made wasn’t fair, but you make just as spurious claims when you say „who cares how you made it or how long it took?”
Really? You care about some stranger's work and how they created it?
Pro tip: you shouldn't.
Care about your work if you want, but "caring" about how someone else makes things and how they talk about it is just being a judgemental busybody and again, gatekeeping.
As for my comment, I stand by it.
If I made something genuinely useful, then it should not matter if it took me 5 minutes or 5 days to make it.
You'll never convince me that more time spent making something (all other factors being equal - yes, quality matters) gives it more value or credibility.
Thanks for the tip haha. I am personally divided on it, but it’s more complicated than just quality or output for me.
I will apologize if I came off combative - was in the backseat of a car so may have been a little direct.
I think people care, all for different reasons. You care too - just when it comes to quality as you mentioned (and I’m sure other factors).
In this case many people correctly pointed out that there were clear indications of a lack of direct cognitive effort on behalf of the operator - including code quality, comment / git history, and including copy that he didn’t write. Now that doesn’t necessarily mean the LLM which did most of the work (or not? How can we know without an auditable prompt history) didn’t produce quality work.
When it comes to something that was made in 5 days AI assisted - the idea may be novel, but without a full prompt history it does become difficult to assess quality of cognitive effort on the operator at least.
In any case - it’s hard for me to know what to call the author. And I do think this applies to traditional media as well, so Im definitely not saying it’s all one sided (Bah! AI!)
That's fair, I guess I was really reacting to the narrow gatekeeping-like case the OP was advocating, where time spent/invested - or only doing things a certain way - was correlated to legitimacy and being able to claim you "made" a thing.
OK, clear enough. But that's an unusual definition of "build" that I don't think you should necessarily expect others to share.
The first entry for "build" in the OED is: To construct, put up, erect (a house or other dwelling or building); to construct (a permanent static structure such as a wall, bridge, or architectural feature, a road or railway, etc.). Also: to commission, finance, direct, or oversee the construction of (something of this type).
There's a trend where people go around claiming they built something and just happen to conveniently omit everywhere that everything was "built" using an LLM and the author doesn't even understand what the code does. That's the crux of my objection.
FWIW I agree with your post and perhaps we need a separate name for people who just instructed an LLM to build something, but then took the trouble to understand how the thing actually works.
It seems to me that this is not the case here. The author used LLM to build the whole thing and left it at that. Which is completely fair, I'd do the same if I just wanted to scratch an itch with the minimal amount of effort, but then I wouldn't go around claiming "I built it".
If I take a photo and then use GIMP to edit it, then did I take a photo or just direct my camera at something and then steer my computer to make changes to it? After all, it's not me drawing each pixel manually. It's vibe-photoed!
No. It's vibe-photoed when you use AI models which are trained on countless hours of actual human work. Otherwise you apply deterministic tools at your will and according to your skill level.
Not author. LLM manager, technical producer (if we're borrowing game development language), advanced AI user; not author. Authors are those whose code was used to train LLM(s) you were using while producing this fine piece of software.
I'm saying this having neither positive nor negative emotions. Just clarifying.
One thing I like about Spotify is the recommendations. I like to do what i call “beat digging” which is basically exploring the platform for new artists and tracks?
Should add a full page click through slop warning to each page on the site. Also give credit to the LLM that made it in the "Brought to you by" section at the bottom.
Author here. Two reasons I chose an immediate mode UI framework:
1. Latency. A click paints on the next frame, because it sidesteps the stages of a retained mode UI: there's no dirty-marking, no layout and paint passes scheduled for later, no cached visual state that can be stale.
2. Simplicity. The UI is a plain function of app state. There's no retained tree to keep in sync and no invalidation bugs: mutate the state and the next frame shows it.
Yes, the drawback is that you have to watch what a frame costs, but it doesn't repaint at every frame. It paints on input and you can schedule repaints yourself. Fastpotify sits at zero CPU when idle, asks for a few frames a second while a track plays, and runs at full rate only while you scroll.
This app is a dream come true for me. As a user I'm heavily invested in Spotify but I've grown more and more irritated with their client. Especially the recommendations, which thankfully are largely absent from your client.
Would love a setting to also remove the "Made for you" section, as well as the "Recommended for you" section, both on the home page.
I was using Spicetify to customize the official client to this effect, using CSS.
Author here. I opened the Solid Queue fiber-worker PR because I needed Rails background jobs to handle long-running LLM streams without allocating a worker thread per conversation.
The implementation shipped today in Solid Queue 1.6.0. It uses one Async reactor thread per fiber worker, keeps thread workers available for CPU-bound or blocking jobs, and requires fiber-scoped Rails isolation.
One caveat: the benchmark results in the article were produced from the pre-release PR branch. I’ve marked that clearly and will rerun the suite against the 1.6.0 tag over the next few weeks.
Happy to answer implementation or Active Record connection-pool questions.
Your PR #151 was opened May 4, 2025 and merged 2 days later.
The repeated `chat.to_llm` message bug was reported Apr 30 2025, and fixed May 6, 2025, about 27 minutes after your comment.
It only showed up when reusing the same Rails chat object for multiple turns in the same Ruby object lifetime, e.g. `chat.ask("first"); chat.ask("second")` inside one controller action or one background job.
The usual flow is one turn per request/job, where the record is reloaded each time. Also, it did not overwrite records; it duplicated messages in the in-memory request context.
Gemini tool calling shipped in 1.0, schema support landed in 1.4, and observability landed in 1.16.
As for "the most trivial of applications": check the docs. RubyLLM goes well beyond that, and several multi-million-dollar companies use it in production every day.
I don't remember every interaction I had with you folks, but that wasn't the only one. Also, the same PR was reverted a bit later, IIRC -- I think I made a mistake in my PR or it wasn't compatible with some other use case, so that's fine, but the overall theme of the interactions (again, in my recollection) was that I was personally moving much faster than you, and using your library was hurting more than helping. So I stopped.
> It only showed up when reusing the same Rails chat object for multiple turns in the same Ruby object lifetime, e.g. `chat.ask("first"); chat.ask("second")` inside one controller action or one background job.
That happens all the time. Without it, you can't pass things around to functions that add to the chat, for example.
> The usual flow is one turn per request/job, where the record is reloaded each time.
This may be your usual flow, but it doesn't have to be everybody's usual flow. No offense, but you're currently reminding me of what I interpreted as "chilly reactions" at the time.
> Gemini tool calling shipped in 1.0, schema support landed in 1.4, and observability landed in 1.16.
Great! I did them myself in less time. It's entirely possible that your library, today, is the tool I needed then.
> As for "the most trivial of applications": check the docs. RubyLLM goes well beyond that, and several multi-million-dollar companies use it in production every day.
OK. Cool. If they want to use the software, I'm sure nothing I say will convince them otherwise.
> Thanks for litigating every layer of a bug I fixed 27 minutes after your comment, more than a year ago.
Erm, OK. I don't think that's even close to what I did, but I guess people can read for themselves.
Again, this was not the only interaction I had with you folks, and even if you accepted my patch instantly and didn't roll it back or anything else at all (Also, once again: completely fine; I understand why you did it and don't fault you for doing it), the fact remains that there were lots of missing features that I needed, and working with you was slower than doing it myself.
Maybe that has changed, but I have to be honest: being defensive and prickly is not making me want to do it. You're actually pretty much illustrating the primary reason why I stopped.
You called them out for being slow; turns out they weren't. You called them out for un-merging your work; turns out they didn't.
Now you keep saying you had other bad interactions, but you haven't even said what they were. I have a feeling that if you named them, shortly later I'd read a comment about how it wasn't true. Again.
If the library didn't match your needs, that's fine. Who cares? That's happened to all of us many times, right?
The decision to audit (frankly, aggressively) this guy out the gate with this comment on a discussion thread is not a good look. It's a very unnecessary way to tarnish the reputation of the devs by picking fights with someone sharing their experience. If you can't see how you did that, perhaps you should ask an LLM to help.
With how the record is so correct now, can you clarify for me who was right?
It's the wrong question; the first person was sharing their experience, and the reply jumped to collecting evidence that only vindicated the characterisation of a 'chilly response'. It's a human social skills thing. This place is not github issues. People who actually care will see. People who 'clarify' it here were never maintainers
