Ryan Djurovich 😎

Fav tech January 2026: 📁 chezmoi to sync .dotfiles across machines via git. 🖥 ghostty terminal with tmux. #️⃣ zsh shell with oh-my-zsh. 📝 vscodium and zed code editors. 🧠 claude opus 4.5 for ai code assistance. 🤔 gpt 5.2 for other ai assistance. 🍞 bun for typescript deps and runtime. ⚡ vite and vitest for builds and testing. 💿 astro for apps with a UI. 🔷 solidjs for reactive UI. ⚛️ tailwindcss & daisyui for styling UI. 🛡️ zod for schema validation. ⌨️ felte for form validation using zod. 📦 tauri (v2) for native/mobile apps. 🤖 go (golang) for perf-sensitive backends and cli tools. 🔐 aws-vault for securely storing aws creds. ☸ k9s cli ui for working with kubernetes (k8s). 🚢 helm for managing k8s apps/manifests. 🔄 argocd for gitops continuous deployments on k8s. 🌐 traefik for reverse proxy into k8s services. 🤫 sealed-secrets for gitops encrypted secrets on k8s. kubesealplus for a better dx managing secrets. 📜 mkcert for generating trusted certs in dev. 🔏 cert-manager for certs in production. 🤖 podman for running (docker) containers & k8s locally. rancher desktop next best alternative. 💡 sqlite for small db's or for caching ephemeral data loaded from s3 in Go programs 🤝 postgresql on aws aurora for transactional/most db's. aurora serverless v2 is great but can't do reserved instances so not always. 📊 duckdb or clickhouse for storing huge data for olap queries. love being able to store the data in s3 with these. ⛁ duckdb or trino for querying bi data across data stores (trino can parallelise queries). 🔁 temporal for durable execution. 🦁 brave web browser. 📋 linear or markdown files in git for project management/issue tracking. 🍓 jam for one click bug reports devs can actually repro. 👀 runreveal to get alerts on important security logs. 📝 obsidian for md notes synced with icloud or gdrive or git. what's your fav tech right now?

@GergelyOrosz If anything I want the AI to help delete or archive the stuff I don’t need, like those projects from 10 years ago in my todo I’ll never do/touch

So many products are building the “AI that takes care of your life/remembers everything so you don’t have to” I actually like using zero advanced stuff: it forces me to keep my list of truly important stuff low; and forgetting about unimportant is honestly a feature not a bug

This post is for anyone who has wasted days, weeks, or months of their life struggling with state in your single-page JavaScript app. Maybe you type three paragraphs into an edit field — and a background refresh silently replaces the DOM, vaporizing your work. Or you bring up a modal dialog box, and something makes it disappear. Or your dropdown selection doesn't actually make it into the operation it was intended for. If this sounds like you, you probably need Datastar in your life, and reduce your use of JavaScript in your client. I had this realization while listening to a talk that David Yang (@dyang , founder of Fullstack Academy and Lightweight Labs) at Clojure/conj 2025. It made me realize that when you’re writing a JavaScript front-end, you’re almost always accidentally building a distributed system. Because of David, I ended up deleting ~1,700 lines of JavaScript in a week in an editor I've been writing, replacing it with a radically simpler approach: server-side Clojure + Datastar + SSE (Server-Sent Events). The server renders HTML, streams it to the browser, and the browser just displays it. Hundreds of lines of JS became ~20 lines of Clojure, over and over again. This is because I realize that the mess I had made for myself (enthusiastically encouraged by Claude Code, trained on a gazillion JS SPA apps) had became intolerable: The client has state. The server has state. They're stomping on each other, and you've lost track on which is actually the source of truth. You fix a bug in one place and it surfaces somewhere else, because you have two copies of reality and they're slowly diverging. And the longer you work on it, the more duct tape you add to keep two diverging copies of truth pointed at each other. In Yang's talk, he talks about how he thought his main business challenge was to build a sync engine between browser clients and his server to present their QuickBooks data in a Google Sheets like interface to their customers. He kept building more sophisticated solutions to reconcile state: cache invalidation, optimistic updates, conflict resolution, offline queues, replay logic. The code kept getting more complex, and the bugs never went away. In a moment of reflection and hammock-time, he saw three things in quick succession that led to a startling epiphany: - "One Billion Checkboxes," the viral app (written in Clojure by @anders_murphy!) serving one billion shared checkboxes to thousands of concurrent users, fully server-rendered on a $5/month VPS. Every session was an HTML stream, with toggles synced in real-time, with zero client-side state management. As Yang said, "I'm trying to render a thousand cells in the browser, and this guy posts about rendering a billion cells in the browser, and you're like: This is relevant to my interests." Haha, so true. - Watching his son play Fortnite streamed via NVIDIA GeForce NOW, streaming 60fps gameplay with no game engine running on his machine. Like the one billion checkboxes being streamed in each frame, Fortnite is streaming a ton of data to each gamer, and it works. His son's gaming computer was basically a monitor receiving pixels from the network. - Watching his wife who works at JP Morgan using a virtual desktop, which was streaming a bunch super, complicated enterprise apps as as pixel streams. Each of these had zero state sync bugs, because there was nothing to sync. Yang said: "You give someone state they'll have bug for a day but you teach them how to represent state in two places they have to be kept in sync and uh they'll get bugs for a lifetime." Har har. Ouch. In 2019, I described my Clojure and functional programming aha moment. I proudly talked about how much I learned from reading "React for People Who Know Just Enough jQuery to Get By," I presented the killer toy tweetbox example go from simple to nightmarish — a character counter here, a photo button there, and suddenly jQuery's callback spaghetti was unmanageable. In contrast, React's centralized state model felt like enlightenment. I wrote my Love Letter to Clojure, and how Clojure eliminated 90% of the errors I used to make. I thought I'd learned the lesson. I thought there were only two floors of Hell. Apparently there's a third — Claude Code will invariable take you there, and may make sure you never leave. This post is meant to show you the way out. - Floor 1 (2016): Don't mutate state. Pure functions, immutable data. Stop changing variables out from under yourself. (Clojure and functional programming, lodash, etc.) - Floor 2 (2019): Centralize state. One atom, one source of truth. Stop scattering state across components, callbacks, and global variables. (jQuery -> React → Redux, Flux, etc.) - Floor 3 (2025): Don’t duplicate state across client and server — eliminate the client copy entirely if you can . (Electron/JS → server-side Clojure + Server Side Events [SSE]/Datastar) For the last two weeks, I've been working on a text editor to help me write — it was my sixth attempt to write the ideal editor to help me write. I did a fresh rewrite as Electron JS app, and it worked wildly well, but it was growing unruly. I rewrote it as a web app, Clojure on the back-end, and JavaScript on the front-end. And started having all sorts of problems, as I described above, due to 50+ shared state across the front- and back-end. Here's some Claude Code summaries of days of bug bashing: - Ghost state everywhere. Modal says it's closed, but a localStorage restore opens it 500ms later. Dropdown shows Opus, spinner says Sonnet. A boolean set to true on button click is never set to false, so every subsequent update auto-scrolls the page forever. Client state and server state drift apart silently — no errors, just wrong behavior. - The DOM isn't yours. You set a button to "Loading..." in JavaScript, but the server replaces the DOM before your cleanup runs. You add a purple focus ring, and the next server push erases it. You double-click to edit, but the first click triggers a re-render that replaces the element before the second click arrives. Every piece of state you store in the DOM exists on borrowed time. - Invisible coordination bugs. Eleven bugs compounding, each masking the next — a scroll position saved by one system and restored by another, cancelling a third system's scroll animation, all within 50ms. You can't reproduce it. You can't even describe it to someone. You just stare at a dropdown that "does nothing." These were the categories of problems I was drowning in — the app was working, built quickly to during writing sessions, but getting impossible to change without breaking something else: Armed with Yang's lessons, I started mass-deleting JavaScript and HTMX calls, instead, streaming HTML fragments via SSE (Server-Sent Events) using Datastar. I started adopting the "game-engine" pattern, where the server assembled each frame from scratch, and streams it to the client as HTML. The browser started to become Yang said it should be: a monitor, like his son's Fortnite session. A couple of amazing surprises: I expected SSE round-trips to feel sluggish, which is usually why we keep things on the client. I was shocked that keyboard navigation could use client-side reactive signals (no network) — it was instant. Skeptically, I tried moving the character counter to be computed on the server, rendered to the client via SSE. To my shock, it was instantaneous. So I began a big rewrite around three architectural principles: - Think game engine. The server is a game loop: receive input, mutate state, render frame, push HTML. The browser is a dumb terminal — it displays what it receives and never decides what to show. - Minimize JS state to zero. I added a red "measles" overlay that highlights every JavaScript state variable on screen. Three variables became an embarrassment. The goal: if the server restarts or the page reloads, everything is restored from one Clojure atom — no localStorage, no JS globals, no let currentState =. (Well, I'm discovering that there's around 5 reason you need to have JS local state, but they're really at the periphery of your program.) - Fire and forget. Every user action is a POST that returns 204 No Content. No JSON response. No .then(data => {...}). The client fires the request and moves on. The server mutates state and pushes the new reality via SSE. The best proof of the value of the rewrite: I've had writing sessions where I was actively adding features in the app while using it. Adding keyboard accelerators to buttons when I became annoyed at clicking those buttons. No compile step. No browser refresh. No lost state. The modal stays open, the draft stays in the textarea. It felt genuinely sublime, even compared to the the world-standard of ClojureScript hot reload systems. Server-side SSE push with browser hot reload feels amazing. A couple of closing thoughts: 1. If any of these problems sound familiar, watch David Yang's talk. If you're a Clojure person (or Clojure-curious), the combination of Datastar + SSE + server-rendered Hiccup is freaking amazing. 2. If you're vibe coding applications, you're more at risk of falling into this third plane of Hell. It's been trained on so much JavaScript SPA that use the replicated state patterns; you'll have to work extra hard to make sure it uses the "game engine Datastar on backend" pattern. I've created a Claude Code skill for this. 3. I'm still figuring out some of the rough edges of Datastar, as well as things that don't work quite so easily when trying to replace JavaScript and DOM operations. The seven valid uses of JS include: - Keystroke dispatch. Capture keypress, read server state from data attributes, route it. Must happen in <16ms. - Cursor manipulation. insertTextAtCursor(), selection ranges, execCommand('insertText'). The browser owns the cursor — SSE can't touch it. - Browser gestures. Clipboard API, drag-and-drop, double-click. Requires user gesture or instant feedback that can't survive a round-trip. - Heartbeat/timers. SSE connection monitor, loading spinners, MutationObserver for post-morph cleanup. Detecting absence is inherently client-side. - Lifecycle interception. beforeunload beacon, deferring reload during editing. Only the browser can intercept the browser. I hope this helps someone who is suffering.

Nice to see Ghostty support added to VSCode/VSCodium

@dillon_mulroy SSR literally only matters for SEO, which has always felt dumb but was/is economically justified

funny how we’ve spent the past decade optimizing the hell out of ssr, ppr, isr, ssg, etc just for none of it to matter for agents and the future of product consumption

@siddontang S3. It’s called S3.

I think "agentic databases" will be a bigger category than "cloud databases." Cloud databases solved a human problem: "I don't want to manage servers." But they still assumed a human on the other side — someone who picks a region, chooses a tier, monitors dashboards. That model breaks the moment your customer is an AI agent. The math that keeps me up at night: Today → millions of cloud database instances, provisioned by humans. By 2028 → every AI agent that persists state will need a database. That's not millions — it's potentially trillions. Cloud databases compete on features: → More replicas → Bigger nodes → Fancier dashboards Agentic databases compete on invisibility: → Zero signup — provision via API in <1s → Zero cost at rest — pay only for queries → Zero ops — no DBA tickets → Zero trust assumed — isolation by default The best agentic database is one the agent never thinks about. The cloud database era served humans well. The agentic database era will serve trillions of autonomous processes. That's a bigger market. And it's already starting. #AgenticDB #AgenticAI #TiDB

@larsencc @browser_use I am. 2 years of dev so far. Built on Kubernetes. Deploys in a few minutes. Open Source. Launching April 28. I previously was responsible for CI & Dev Stacks at Cloudflare & Xero.

At @browser_use we run millions of parallel agents. We think about parallelism all day. That's the job. It got me thinking about something most teams aren't talking about yet. Picture a 50 person engineering org where everyone uses AI coding assistants. Each developer kicks off a few agents at once. Suddenly you have hundreds of concurrent code changes being generated, tested, and pushed. Now ask yourself: where does all that code get validated? For most companies, the answer is a single staging environment. Maybe two if they're lucky. That's a massive mismatch. Your development throughput just 10x'd, but your validation layer stayed exactly the same. Agents sit idle waiting their turn. Context windows expire. CI pipelines pile up. The productivity gains you paid for evaporate in a queue. This isn't an agent problem. It's an infrastructure problem. Staging was built for a world where one person ships one thing, gets feedback, iterates. That model breaks when the workload becomes parallel by default. I've seen this pattern before, even pre-AI. At Flexport, the product was so large you couldn't run it locally. Every engineer got their own cloud dev environment. Docker containers spun up on demand, with switches to toggle which services you needed. Not because it was fancy. Because one shared environment for hundreds of engineers simply didn't work. Now give each of those engineers 3 agents (or more ofc). Teams keep throwing money at better models and faster agents while ignoring the chokepoint sitting right behind them. You invested in 10x development speed and got 2x back because the rest is stuck waiting. The answer is ephemeral, isolated environments. One per agent. Spun up in seconds, torn down when done. Only the services that changed get deployed. No shared state, no queue, no conflicts. Every serious engineering org will need this. Most haven't even started thinking about it. So who's building this? Because most teams are holding together shared environments with duct tape and hoping it scales. If you're working on this or running into it, I want to hear from you.

Creating a simple tmux launcher script to auto-configure a tmux session with a layout for each of my main projects and their respective windows (for dev servers, agents, git, etc) has been the biggest productivity win. Started with it in September 2024 for dev procs.

@aakashgupta This shows a huge lack in the understanding of current SOTA LLMs and context limits: "It never misses context from a meeting three months ago". LLM context windows are limited. At some point, context must be summarised, which is a lossy exercise, meaning context can be missed.

Every CEO will be running an OpenClaw within 12 months. Zuck is just building his in-house. Here’s what to expect. Six days ago Jensen Huang stood in front of 30,000 people at GTC and said every company needs an OpenClaw strategy. OpenClaw hit 250,000 GitHub stars in 60 days, faster than Linux, React, or any open-source project in history. Peter Steinberger built the first version in an hour. Nvidia shipped NemoClaw, an enterprise security layer, on top of it. Anthropic shipped Cowork Dispatch before OpenAI shipped anything. The infrastructure for autonomous AI agents went from side project to enterprise standard in under two months. Zuckerberg building a personal CEO agent is what this looks like when a Fortune 5 company does it internally. A CEO at Meta’s scale sees maybe 1% of the information that determines whether a decision is right or wrong. The other 99% gets filtered through VPs, chiefs of staff, dashboards, and whatever made it into the pre-read. The agent replaces the filter. Think about what a CEO agent actually does. It ingests every product metric, every internal thread, every customer escalation, every competitive intelligence report across every team simultaneously. Then it surfaces the three things that actually matter this morning. Before every 1:1, it pulls that person’s team metrics, open headcount, recent launches, and the two things they said they’d deliver last quarter. When the CEO asks “what happens to our glasses timeline if we move 200 engineers to AI infra,” the agent gives a first-pass answer in minutes instead of a two-week strategy team exercise. And it never forgets. The person who remembered why the company killed that project in 2019 left two years ago. The agent didn’t. Meta employees are already running their own versions. Tools called “My Claw” and “Second Brain.” Engineering output up 30%, power users up 80% year over year. Zuckerberg is doing what his employees are doing. Applying it to the highest-leverage seat in the company. Now think about what that means for the people currently doing this work. Chief of staff. Executive assistant. BizOps. Strategy and planning. These roles exist to perform one loop: gather information from across the org, filter it, synthesize it, route it to a decision-maker, track the follow-through. Every step is a text-in, text-out task. Summarize this doc. Pull these metrics. Draft this brief. Follow up on action items. Cross-reference what engineering said with what finance approved. A typical Fortune 500 CEO has 8 to 12 people whose primary job is making them effective. Multiply that by every SVP with a chief of staff, every VP with a BizOps partner, every director with an EA. Thousands of roles per large company built around the information-routing function. The agent reads 400 pages of internal docs in seconds. It never misses context from a meeting three months ago. It doesn’t need to Slack four people for the latest numbers because it’s already connected to the source systems. The human in BizOps spends 70% of their week on information gathering and synthesis. The agent does that in minutes. That’s a 90% headcount reduction across chief of staff, EA, BizOps, and strategy roles over the next five years. The surviving 10% will be the ones doing work agents can’t: reading a room, managing a difficult exec relationship, knowing that the CFO’s “sure, let’s revisit” actually means no. Political judgment and human navigation. Everything else dissolves into software. The question every board should be asking: if your CEO isn’t running one of these by 2027, what are they making decisions on?

Ironically getting more folks to not use a React feature could be the best thing to happen to React this year

An uncomfortable truth about building agents/models: By default, your most lucrative, most-smitten customers will be those using intricate out-of-band techniques that are exorbitantly expensive and probably net negative (but that they love). It's a very weird incentive. You can't and don't want to indulge this. There's nothing wrong with experimentation, but if you saw what every agent company sees, you'd know this goes way beyond experimentation. Amp tries really hard to prevent this: limiting long context, showing prices, not recommending swarms or loops prematurely, strongly advising against big MCPs, killing features that have high usage but that aren't worth it anymore, and just generally staying away from any hype train we don't have a good gut feeling about. Pi and OpenCode are also particularly good and outspoken here. But if you have growth targets to hit, investors to pitch, and salespeople to keep happy, or if you didn't start this way from day 1, I can see it being tricky. At Amp, we're profitable, don't have salespeople, and have no sales/growth targets to hit, so we have it relatively easy. I often wonder what this tension is like inside other companies building agents. (And for the record: if you've shown me your Amp workflow and I haven't told you this directly, this post is not about you. :)

Guess ill move off of Vercel for (unpaid) personal projects at this point. I dont mind if people ask permission for this, and everyones free to make their own choices, but I am your funnel, not your product.

It auto-classifies gaps (missing_skill, missing_tool, repeated_failure, wrong_info) and posts to Slack with a pre-filled GitHub issue URL. This creates a feedback loop: real sessions -> detected gaps -> GitHub issues -> new skills -> better sessions.

@dillon_mulroy 🙏 and yes, which are the same docs that get published to the website. Also worth looking at the AGENTS.md structure if you’re curious. I found the feedback loop of piping dev procs to log files and having agents read that👌

@ryan0x44 respect, i'll take a read - the md files under /docs?

if you’ve generated a SPEC․md, PRD․md, or PLAN․md and fed it to an agent in the past week, this is mandatory reading so many nuggets of wisdom in here

@dillon_mulroy That’s a bad assumption about how things should work IMO. But I have plenty of examples I’ve published e.g. nstance.dev which started from a single spec that got split into the current docs, which is better for evolving the code.

@ryan0x44 put your money where your mouth is, show me what a good example of a spec send me a it so i can give to my model to reproduce a piece of software with

We benchmarked TanStack Start, React Router, and Next.js running the exact same eCommerce app at 1,000 req/s on AWS EKS. The results were eye-opening.

if you're curious, this is what peak looks like for me its when i was spending most hours building sentry. i had clean design, i had the ability to iterate fast, and i had clear progression the second image is the last year where i'm certainly able to generate a lot more code, but i can tell you that the code is far less maintainable (despite how much effort I put into it) i have not gotten less knowledgeable as an engineer, and while technology has certainly gotten needlessly complex, there's something here that is hard to articulate about the current state of LLMs...

Sage observation from @karrisaarinen (CEO of Linear) It now makes SO MUCH sense why I see a bunch of eng teams rebuilt a SaaS vendor in-house with AI, brag about and feel good They are doing side quests... and they don't even know it. And they are not helping their co win!!

@ritakozlov Awesome write-up. Does this mean no more PMMs??