Your single-tool approach is a solid starting point. As it grows, you might hit context window limits and find the prompt getting unwieldy. Things like why is this prompt choking on 1.5MB of JSON coming from this other API/Tool?

When you look at systems like Codex CLI, they run at least four separate LLM subsystems: (1) the main agent prompt, (2) a summarizer model that watches the reasoning trace and produces user-facing updates like "Searching for test files...", (3) compaction and (4) a reviewer agent. Each one only sees the context it needs. Like a function with their inputs and outputs. Total tokens stay similar, but signal density per prompt goes up.

DSPy.rb[0] enables this pattern in Ruby: define typed Signatures for each concern, compose them as Modules/Prompting Techniques (simple predictor, CoT, ReAct, CodeAct, your own, ...), and let each maintain its own memory scope. Three articles that show this:

- "Ephemeral Memory Chat"[1] — the Two-Struct pattern (rich storage vs. lean prompt context) plus cost-based routing between cheap and expensive models.

- "Evaluator Loops"[2] — decompose generation from evaluation: a cheap model drafts, a smarter model critiques, each with its own focused signature.

- "Workflow Router"[3] — route requests to the right model based on complexity, only escalate to expensive LLMs when needed.

And since you're already using RubyLLM, the dspy-ruby_llm adapter lets you keep your provider setup while gaining the decomposition benefits.

Thanks for coming to my TED talk. Let me know if you need someone to bounce ideas off.

[0] https://github.com/vicentereig/dspy.rb

[1] https://oss.vicente.services/dspy.rb/blog/articles/ephemeral...

[2] https://oss.vicente.services/dspy.rb/blog/articles/evaluator...

[3] https://oss.vicente.services/dspy.rb/blog/articles/workflow-...

(edit: minor formatting)

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. "Building Your First ReAct Agent" shows how to build tool-using agents with type-safe tool definitions [0].

2. "Building Chat Agents with Ephemeral Memory" demonstrates context engineering patterns (what the LLM sees vs. what you store), cost-based routing between models, and memory management [1].

The article's approach (RubyLLM + single tool) works great for simple cases. DSPy.rb shines when you need to decompose into multiple specialized modules with different concerns. Some examples: separate signatures for classification vs. response generation, each optimized independently with separate context windows and memory to maintain.

Would love to learn how dspy.rb is working for you!

Note that RubyLLM and DSPy.rb aren't mutually exclusive (`gem 'dspy-ruby_llm'`) adapter gives us access to a TON of providers.

[0] https://oss.vicente.services/dspy.rb/blog/articles/react-age... [1] https://oss.vicente.services/dspy.rb/blog/articles/ephemeral...

I’ve been using this pattern for API clients[0] and CLIs[1]: define the shape once with Sorbet, get automatic JSON Schema generation when you need it.

[0] https://github.com/vicentereig/exa-ruby [1] https://github.com/vicentereig/lf-cli

For generating (with LLMs) API clients and CLIs it’s especially useful—define the shape once, get validation at ingress/egress for free.

Maybe momentum is happening in new projects rather than retrofits? [0] https://oss.vicente.services/dspy.rb

DSPy is a programming paradigm. I like to look at it like the MVC for the Web. You define Signatures[0]: typed contracts governing the relationship between your models and your app. Signatures model prompts as functions too, without leaving Ruby. Then compose them into modules (Predict, ChainOfThought, ReAct, your own). The framework can automatically optimize prompts based on your metrics.

DSPy.rb brings the DSPy paradigm's tooling (optimizers, evaluation loops) to Ruby. Comes with OpenTelemetry OOTB. It also borrows BAML's schema format for 85% token savings vs JSON Schema in complex signatures. [1]

Everyone is talking about prompt, context, and harness engineering -and I agree they are good ways to frame how to build workflows and agents- this is just programming really.

[0] https://oss.vicente.services/dspy.rb/core-concepts/signature...

[1] https://oss.vicente.services/dspy.rb/articles/baml-schema-fo...

I'm working on DSPy.rb [1] and this could pair nicely for multi-step reasoning chains.

Curious - any plans for async gem support?

[1] https://oss.vicente.services/dspy.rb/

So I started https://github.com/vicentereig/dspy.rb: a composable, type-safe version built for Rubyists who want to design and optimize prompts, and reuse LLM pipelines without leaving their language of choice. Working with DSPy::Signatures reminds me a bit of designing a db schema with an ORM.

It’s still early, but it already lets you define structured modules, instrument them in Langfuse, wire them up like functional components, and experiment with signature optimization. All in plain Ruby.

Comments URL: https://news.ycombinator.com/item?id=38018140

Points: 2

# Comments: 0

They are useful in organizations where the people who author and publish the content aren't the same people who known how to code a website.

It'd be helpful if you could provide a couple of examples of that _boilerplate content_ looks like.

I led the team migrating to Contentful (CF) a hefty documentation website [1] from a homegrown CMS based on MDX. 600+ mdx articles, multiple GBs of media. This was about a year ago, so my knowledge might be outdated.

What worked for us was focusing our workflow as if CF were a database. I personally borrowed a bunch of concepts of how Rails' Active Record allows you, or your CI pipeline, to manage your database schema. Things like:

- have CF doing some gymnastics to keep track of migrations ran.

- supporting ephemeral CF environments so each developer could work without stepping on each others toes.

- promoting environments on PR merges

Being able to track changes in CF's schema through migrations, allowed us to build other useful stuff like:

- structuring articles in a way that the navigation under each section is not a pain to rebuild.

This might be what you mean when you talk about _boilerplate content_. Didn't find anything at the time, but it's possible that someone else has built a framework of sorts.

It took us a few weeks to prepare ours before working on actually migrating content. However, it supported our work along the way during the incremental and continuous migration we planned.

And then we were in a good spot to actually start migrating content. Transpiling the MDX to the JSON CF can ingest, uploading media assets, rewiring the UI (nextjs) to fetch contents from CF instead of the local MDX source.

Anyway, let me know if you want to bounce some ideas off. Contact details in my profile.

[1] https://tray.io/documentation/

I felt the need to protect myself from these sources of FOMO.

When it is necessary to set up a group chat, I like them short-lived. You organize an event with friends. The event is over. I delete the chat for all. Sometimes I lack the ability to do so. So I just leave, usually leaving a see-you-soon note. You know, ruthlessly prioritizing where I am spending my attention, while not acting like a d*ck.

I keep less than a handful of evergreen group chats with family and close friends. All of them with notifications on mute. No read, played, delivered ticks as well. If I need confirmation I'll just call them on the phone!

I leave notifications on for a few folks like my dad. He can get my attention anytime, anywhere. A good old phone call will definitely catch my attention too.

In return, I get to spend real good quality time, when they are not around, with my partner, family, close friends, and acquaintances. And hopefully they do too. :)

I am building the Growth Engineering team in the Commercial Business Segment organization at New Relic, Inc. I am looking for several Software Engineers to drive acquisition, monetization, on boarding, and retention.

We are a disciplined and focused engineering team, measuring every single experiment and incremental changes to validate, or invalidate, our hypotheses to drive growth.

On the technical side of things, we work on Ruby, Elixir, and modern JavaScript (Angular and ReactJS).

If being in the middle of fast paced growth team in a successful SaaS company rings a bell, I would love to talk to you.

I am happy to answer questions here or by email! vicente@newrelic.com

- Sr Growth Software Eng (5+ years): http://jobs.jobvite.com/newrelic/job/osn55fwJ

- Growth Software Eng (3+ years): http://jobs.jobvite.com/newrelic/job/otId6fwe

The Growth Engineering Team is looking for a great Senior Software Engineer to join us in building customer experiences to drive acquisition, onboarding, monetization, organic/viral growth, and retention across the New Relic product suite. Please include a short cover letter, telling us why you’re interested in this position and why you think we should work together.

As a good fit for this role, you…

* Have a least 5 years of industry experience working in a team environment building production web applications with modern OO languages such as Ruby or functional languages like Elixir. You have built Single Page Apps in AngularJS, and backend services in Rails and Elixir.

* Possess a Growth Engineering mindset focused on continuously improving the customer experience to help drive engagement and sales. You are curious at heart and ship iterative changes and experiments with instrumentation to improve key metrics. You minimize risk introduced by these changes with an ironclad test suite.

* Actively participate in code and UI design reviews, weekly sprint planning meetings and team retrospectives to ensure we are all building at our best while driving key business goals.

* Have strong opinions, weakly held and rooted in personal experience. Can easily disregard prior held biases and opinions in the face of new information and use cases.

* Be part of a disciplined team that follows best Agile practices. Can build strong alliances with Product and Engineering Managers, using your knowledge to influence task prioritization.

* Relish the chance to mentor others and are passionate about improving software and your teammates’ skills.

Apply here in our Careers website! https://newrelic.com/about/careers?p=job%2Fosn55fwJ

Cheers, Vicente.

http://www.toastmasters.org