News for hackers. Stuff that matters.

obiefernandez

Re:RubyLLM: A Ruby framework for all major AI providers on Wednesday June 24, 2026 @12:22PM (#48662172)
I have an open source gem called Raix that builds on top of RubyLLM's abstractions and is quite popular. https://github.com/OlympiaAI/raix
Re:Elevated errors on Claude.ai, API, Claude Code on Wednesday April 15, 2026 @12:19PM (#47781285)
I'm getting Cloudflare protection screens while trying to use claude.ai web app. I wonder if they were getting DDoS'd...

Show HN: Manceps – Ruby Client for the Model Context Protocol (MCP)

https://github.com/zarpay/manceps

I built this because existing Ruby options for MCP either don't handle persistent connections properly (MCP servers bind sessions to TCP connections) or couple you to a specific LLM framework.Manceps is a pure protocol client. Two transports (Streamable HTTP and stdio), built-in auth (bearer, API key, experimental OAuth 2.1 with PKCE), and full 2025-11-25 spec support including protocol...

( Read More... | no comments | on HN )
Re:Issue Tracking Is Dead on Tuesday March 24, 2026 @03:25PM (#47507781)
At ZAR once we had pervasive ingestion into an organization-wide knowledge graph in place and working well, the next step was to ditch Linear and replace it with a homegrown experiment tracking system that focuses all product engineers on empirical data and scientific method applied to how we prioritize work.

It's the only way to actually encourage high-agency, high-ownership behavior. Working from a backlog is actively counterproductive!

I’m gonna build this into Ruby on Rails.

I have lots of the code proven out already https://medium.com/zar-engineering/code-mode-mcp-ac17c2a1038...

Re:Does anyone use CrewAI or LangChain anymore? on Monday February 23, 2026 @10:13PM (#47132417)
No. They suck.
Re:How I use Claude Code: Separation of planning and execution on Saturday February 21, 2026 @09:43PM (#47107590)
My colleague swears by his DHH claude skill https://danieltenner.com/dhh-is-immortal-and-costs-200-m/
I just recreated most of Linear for my company in a few days. Making it hyper specific to what we want (metrics driven, lean startup style).

All state changes are made with MCP so it saved me from having to spend time on any forms and most interactions other than filtering searching sorting etc.

Means we will be ditching Linear soon.

I know I’m an outlier but this sort of thing will get more common.

Re:A Serverless WebRTC Signaling Protocol Using QR Codes on Monday January 19, 2026 @12:20PM (#46681707)
Love the creativity and that you took the time to explain every step of the discovery.
Re:Taiwan's £7.5T secret weapon is disintegrating on Friday January 02, 2026 @10:22AM (#46465618)
Anyone else look at this and think to themselves, "thank god"

Like it's probably a good thing for humanity if the USA does not feel the need to go to war with China over Taiwan.

Re:Recursive Language Models: the paradigm of 2026 on Thursday January 01, 2026 @08:11PM (#46460231)
The RLM framing basically turns long-context into an RL problem over what to remember and where to route it: main model context vs Python vs sub-LLMs. That’s a nice instantiation of The Bitter Lesson, but it also means performance is now tightly coupled to whatever reward signal you happen to define in those environments. Do you have any evidence yet that policies learned on DeepDive / Oolong-style tasks transfer to “messy” real workloads (multi-week code refactors, research over evolving corpora, etc.), or are we still in the “per-benchmark policy” regime?

The split between main model tokens and sub-LLM tokens is clever for cost and context rot, but it also hides the true economic story. For many users the cost that matters is total tokens across all calls, not just the controller’s context. Some of your plots celebrate higher “main model token efficiency” while total tokens rise substantially. Do you have scenarios where RLM is strictly more cost-efficient at equal or better quality, or is the current regime basically “pay more total tokens to get around context limits”?

math-python is the most damning data point: same capabilities, but the RLM harness makes models worse and slower. That feels like a warning that “more flexible scaffold” is not automatically a win; you’re introducing an extra layer of indirection that the model has not been optimized for. The claim that RL training over the RLM will fix this is plausible, but also unfalsifiable until you actually show a model that beats a strong plain-tool baseline on math with less wall-clock and tokens.

Oolong and verbatim-copy are more encouraging: the controller treating large inputs as opaque blobs and then using Python + sub-LLMs to scan/aggregate is exactly the kind of pattern humans write by hand in agents today. One thing I’d love to see is a comparison vs a well-engineered non-RL agent baseline that does essentially the same thing but with hand-written heuristics (chunk + batch + regex/SQL/etc.). Right now the RLM looks like a principled way to let the model learn those heuristics, but the post doesn’t really separate “benefit from architecture” vs “benefit from just having more structure/tools than a vanilla single call.”

On safety / robustness: giving the model a persistent Python REPL and arbitrary pip is powerful, but it also dramatically expands the attack surface if this ever runs on untrusted inputs. Are you treating RLM as strictly a research/eval harness, or do you envision this being exposed in production agent systems? If the latter, sandboxing guarantees and resource controls probably matter as much as reward curves.

Older »