
NATS maintainer @Synadia
San Francisco, CA
Joined February 2009
- Tweets3.5K
- Following2.2K
- Followers1.1K
- Likes3.9K
MLIR style compilers are one of my favorite ways to use LLMs these days, really cool to see this release
Ruby 4.0.9 with the complete fixes to prevent GitLab CVE via Regexp ruby-lang.org/en/news/2026/1…
I'm actually more optimistic about OSS and things in general by the end of this week than when it started.
Ruby release with the fix that avoids the GitLab CVE regex issue
Ruby 4.0.8 Released ruby-lang.org/en/news/2026/1…
This is a routine update that includes bugfixes. We recommend upgrading your Ruby version at your earliest convenience.
This is also not a joke, LiteLLM was compromised again… aikido.dev/blog/litellm-comp…
Typescript rewritten into Rust keeping the Typescript Go compiler as the oracle blog.cloudflare.com/typescri…
I think now that the aha moment behind "oh so using LLMs still means having to code" is realizing that you still need to build and maintain an imperative shell.
Looking forward to Data Streaming Summit in SF tomorrow! #DSS2026
Completely onboard with the Regenerative Software idea, it lines up with how I've been approaching software dev in the past few months.
Another sign of DSPy being future proof is how quickly Jev support was added and how well it fits its paradigm
Here's a repo demoing these compound AI patterns with DSPy + Jev! github.com/cmpnd-ai/dspy-sys…
Think many are ending up converging into a similar workflow (e.g. increased TLA+ adoption, specs or building custom compilers)... Everyone having a private closed 'factory' used to generate public repos is maybe what is next for OSS?
I want to share how I have developed celld - because it's a bit different and it's working well for me. You might have noticed that the github.com/denoland/celld repo is pretty bare - this is because it's an export of a much larger private repo: denoland/celld.dev
This larger repo contains: an llm-wiki with an enormous amount of design docs, a large test suite, a spec written in TLA+, the code for the website, scripts for spinning up fleets of celld instances on various clouds and running tests against them, and a speculative centralized managed control plane that I might someday release as a commercial product.
My llm-wiki is modified to fit my workflow - diff here gist.github.com/ry/c56dfa7b1…
I find llm-wiki extremely useful for gathering context. Reviewing wiki/design/ is a primary development activity.
celld is open source, but the development happens in private. The test suite and design docs are private. Why do this? First of all, I don't need the public following my every commit - it's oversharing. Secondly, in the age of coding agents, I don't really need external contributors. I'll always appreciate a patch, but most properly reported issues are one-shottable solutions. Third, it's just a bit of IP that might be valuable someday.
I do a lot of experiments with celld on Vultr with a VPC. I'll spin up between 2 and 10 VMs at a time, run some experiment, and usually try to tell some story via a chart of some sort (one below).
My own coding agent setup is ssh/tmux to mac mini, with various codex and claude sessions running. I don't use an enormous number - something like 2-4 at a time. (Why a mac mini? idk someone just gave me it)
My musts for a coding agent: 1) readline bindings should just work and apply through whole UI, 2) Ctrl-Z / fg are reliable.













