[qrush]

We've used RubyLLM for ~6+ months and it's been mostly OK. The API/Dev UX is good but we have seen little success with engaging the maintainer on PRs, and have noticed a lot of vibe coded PRs being merged (including some rewrites of PRs we submitted) - I suspect an minimal API compatible gem with similar heuristics would do well.

[timr]

Similar experience. I tried using this library about a year ago, but the Rails integration was really rough at the time, and things like persisting the conversation to the database required essentially bespoke code. Also, tool use, schemas, etc. for Gemini required a lot of work, observability was limited, and IIRC, it did stuff like overwriting records in specific situations. I don't know if that is improved, but it was essentially a no-go for me at the time.

I tried submitting some PRs, but got a chilly reception. It was taking so long to make any forward progress on the parts I needed that I gave up, and wrote my own layer to do the parts of this that mattered to me. It didn't take long, and ultimately, I've customized it so much over time that I'm glad I didn't make this a dependency.

While the parts of this gem abstracting the various LLMs are nice and well designed, I think this kind of thing is a liability for anything but the most trivial applications. LLMs are moving too quickly to have the core connection infrastructure be gated on the release cycle of a third-party library. You can see this in the various comments down-thread where people are talking about the library lacking the Responses API -- it's great that the library is about to fix that problem, but if you just write your own adapter, you'd have been done months ago.

One of the biggest implications of LLMs in software, in my opinion, is that entire classes of third-party dependencies can be eliminated. It's interesting to look at which ones those are (and which ones continue to get interest) because it tells you a bit about where the post-LLM value of software will reside.

[earcar]

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.

[timr]

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.

[earcar]

Thanks for litigating every layer of a bug I fixed 27 minutes after your comment, more than a year ago.

> Also, the same PR was reverted a bit later, IIRC

No. Your #151 was merged. The regressions it introduced were patched the next day in #157/#159.

Cheers!

[timr]

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

[qup]

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?

[nougati]

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.

[spider-mario]

Why should the parent comment be immune from factual challenges? Reports of personal experience are not sacred.

[nougati]

Learn to pick your fights? People can check the history of the git issues if they want to see. The dev clearly had a bone to pick

[qup]

I think it's really neutral in tone and I appreciate the record being corrected.

2 days is a great turnaround time for PRs isn't it?

[nougati]

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

[earcar]

I checked whether you or anyone from Wistia, your company, opened PRs.

I found one: #813, opened June 16, 2026. Last week.

[shevy-java]

> engaging the maintainer on PRs

Well, do real people want to "interact" with bots, including AI? I noticed this problem recently on prawn. Someone wants to merge about 1000 lines of code, 95% of what was auto-written by some AI model. Then he complained that the solo-maintainer does not want to review those ~1000 lines of code. What can I say ... I understand the issues by real humans more than by "vibe" coders here.