21–30 of 59 posts
What does the end user do with the AI chat? It sounds like they can just use it to do searches of client information… which the existing site would already do.
But not without using a thousand gallons of water and propping up Nvidia shares.
Earlier quoted context omitted.
But not without using a thousand gallons of water and propping up Nvidia shares.
I get that the water stereotype is funny, but it gets tiring after a while (because it's not actually true).
It may be the current "Zeitgeist", but I find the addiction to AI annoying. I am not denying that there are use cases to be had that can be net-positive, but there are also numerous bad examples of AI use. And these, IMO, are more prevalent than the positive ones overall.
Was there any concern about giving the LLM access to this return data? Reading your article I wondered if there could be an approach that limits the LLM to running the function calls without ever seeing the output itself fully, e.g., only seeing the start of a JSON string with a status like “success” or “not found”. But I guess it would be complicated to have a continuous conversation that way.
> No model should ever know Jon Snow’s phone number from a SaaS service, but this approach allows this sort of retrieval. This reads to me like they think that the response from the tool doesn’t go back to the LLM. I’ve not worked with tools but my understanding is that they’re a way to allow the LLM to request additional data from the client. Once the client executes the requested function, that response data then g…
If all this does is give you the data from a contact API, why not just let the users directly interact with the API? The LLM is just extra bloat in this case. Surely a fuzzy search by name or some other field is a much better UI for this.
By interact directly with the API, are you having the user to make curl calls to your backend? We build front ends for the API to make our applications easier to use. This is just another type of front end.
I liked how well designed the monolith application seems to be from the brief description in the article.
Coincidentally I installed Ruby, first time in years, last week and spent a half hour experimenting the same nicely designed RubyLLM gem used in the article. While slop code can be written in any language, it seems like in general many Ruby devs have excellent style. Clojure is another language where I have noticed a preponderance for great style.
As long as I am rambling, one more thing, a plug for monolith applications: I used to get a lot of pleasure from working as a single dev on monoliths in Java and Ruby, eschewing micro-services, really great to share data and code in one huge usually multithreaded process.
It's interesting the use of RubyLLM here. I'm trying to contrast that with my own use of DSPy.rb, which so far I've been quite happy with for small experiments. Does anyone have a comparison of the two, or any other libraries?
Maintainer of DSPy.rb here. The key difference is the level of abstraction: RubyLLM gives you a clean API for LLM calls and tool definitions. You're still writing prompts and managing conversations directly. DSPy.rb treats prompts as functions with typed signatures. You define inputs/outputs and the framework handles prompt construction, JSON parsing, and structured extraction. Two articles that might help: 1. "Build…
Earlier quoted context omitted.
Maintainer of DSPy.rb here. The key difference is the level of abstraction: RubyLLM gives you a clean API for LLM calls and tool definitions. You're still writing prompts and managing conversations directly. DSPy.rb treats prompts as functions with typed signatures. You define inputs/outputs and the framework handles prompt construction, JSON parsing, and structured extraction. Two articles that might help: 1. "Build…
A lot of good info, thanks. I have just lightly experimented with Python DSPy and I will probably give your DSPy.rb gem a try, or at least read your code.
Earlier quoted context omitted.
I built a similar system for php and I can tell you what is the smart thing here: accessing data using tools. Of course tool calling and MCP are not new. But the smart thing is that by defining the tools in the context of an authenticated request, one can easily enforce the security policy of the monolith. In my case (we will maybe write a blog post one day), it's even neater as the agent is coded in Python so the ph…
I had to do something similar. Ruby is awful and very immature compared to python, so I "outsourced" the machine learning / LLM interaction to python. The rails service talks to it through grpc / protobuf and it works wonderfully.
Not all cool code is in new greenfield projects.
I really enjoyed reading the code listings in the article. Many years ago I was a Ruby fanatic, even wrote a book on Ruby, but for work requirements I was pulled to Java and Python (and occasionally Clojure and Common Lisp). I liked how well designed the monolith application seems to be from the brief description in the article. Coincidentally I installed Ruby, first time in years, last week and spent a half hour exp…