7 ms·

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

by qrush 3mo ago

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.

shevy-java 3mo ago
> 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.
timr 3mo ago
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 3mo ago
  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 3mo ago
    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.
    - 3mo ago
earcar 3mo ago
I checked whether you or anyone from Wistia, your company, opened PRs. I found one: #813, opened June 16, 2026. Last week.

by qrush 3mo ago

shevy-java 3mo ago

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

timr 3mo ago

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 3mo ago
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 3mo ago
  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.
  - 3mo ago

earcar 3mo ago

I checked whether you or anyone from Wistia, your company, opened PRs. I found one: #813, opened June 16, 2026. Last week.