Everything you do is ultimately pointless, yet embracing this pointlessness gives you the freedom to create your own meaning.
San José, CA
Joined October 2016
- Tweets351
- Following220
- Followers22
- Likes56
Lately I've read about a few systems being rewritten in Rust, Bun and Campfire among them. In both cases, the rewrite was checked with tests that only look at the system from the outside: Bun's TypeScript test suite, and a harness that compares Campfire's pages with the Rails app.
I've noticed a smaller version of this in my own work. AI writes most of my code now, so a module may be rewritten next month, and the tests tied to its internals get replaced along with it. The user stories usually stay the same, so more of my review time has gone there, which mostly means E2E tests. We used to write few of those, because preparing one round could take half a day or more.
For the past few months I've been handing that work to agents, set up so I can still check each step myself. I wrote down how it works so far.
yaodong.dev/rethinking-e2e-t…
AI can propose a solution, write the code, and turn a complex workflow into a series of yes-or-no answers. Checking its work still takes judgment, and I've been thinking about where that judgment comes from.
Recently an AI agent wrote a small pull request for me, and it took me a whole day to find the one corner case it had missed. What let me find it was years of doing the work myself, writing code, getting it wrong, and fixing it. Confirming finished answers builds none of that. When my only role is to say yes or no, I'm never wrong in a way I can feel, and nothing sticks.
So keeping that understanding has become deliberate practice for me. I work a problem before asking, write ideas in my own words, and read code I don't strictly have to read. Little of it is required to finish the task, but it's the part that made finding that corner case possible.
yaodong.dev/understanding-fr…
What Does It Mean to Store Something Per Request?
whir.org/what-does-it-mean-t…
Recently I built a PKM client from Craft Agents' source. While the AI was helping me fix some UI issues, it hit me that I'd been building the client in the wrong direction.
Treating AI as a runtime is different from treating it as a tool. My PKM client treated it as a tool: AI was one feature in the workflow, a thing I'd build, polish, and maintain. So I scrapped it, nearly done as it was, and handed the AI two frameworks instead: CODE and PARA, both used for building a second brain.
1️⃣ CODE is the workflow, how information moves from saved to useful, in four stages: Capture it, Organize it where it belongs, Distill it to the part worth reaching for later, Express it as your own work.
2️⃣ PARA is the filing: four buckets sorted by how close something is to your active work. Projects are what you're producing now, with a deadline. Areas are ongoing responsibilities with no end date. Resources are things that might matter someday. Archives are what's gone cold but you keep anyway.
Now the AI drives the process. To decide what to automate, I had it write user stories from how I actually work, corner cases included, and turned those into skills. For example, /capture is the one I use most: hand it a YouTube link or article URL and it pulls the content into a clean Markdown file. /organize is next: once I've decided where a note belongs, the AI files it. I'm building /review now: a personal knowledge base only pays off when you come back to what you saved and turn it into something.
So when people ask why an engineer would hand the code to AI instead of writing it: writing it myself is sometimes faster, I won't pretend otherwise. But software development is already moving onto an AI runtime, and I don't see it going back. If I keep AI as a tool, I'm the one maintaining it, and I'd rather put that time somewhere else. How to keep growing as an engineer in this new setup is a real question, but not a reason to stay where we are.
If they truly cared about this society, what Google should do is open-source Gemini.
If you’re giving a commencement speech in 2026, maybe don’t mention AI techcrunch.com/2026/05/17/if…
I built a small tmux plugin for monitoring AI coding agents. One keybinding opens a dashboard showing every Claude Code and Codex instance across all sessions, another jumps straight to the next agent that needs attention. One line in tmux.conf to set it up.
I've been exploring a way of working where I run a dozen agents across multiple branches at once, trying to push them to their limit and see how much they can handle in parallel. Running two Claude Code instances at once feels natural: one for a feature, one for tests.
But at this scale, I kept cycling through tmux panes trying to find out which agent just finished, which one was waiting for input, and which one had been stuck on a permission prompt for the last ten minutes. The agents weren't the slow part. I was, trying to keep up with all of them.
Now I just glance at the dashboard, see which agents are done, jump to the ones that need me, and move on. The mental overhead of managing them is mostly gone. I can focus on directing the work instead of tracking it.
Every time the tooling moves, I push it past what I think it can handle. A new model, a better coding agent, a different workflow, and a different category of problem. Let it fail. Learn where the boundary is. Recalibrate. Push again.
Six months ago AI couldn't handle a legacy refactoring without breaking things across the codebase. Now it catches things my IDE misses. AI has worked its way into every stage of how I build software, and the pace is still accelerating.
The tool I calibrated against last time is never the tool I'm using today. Wrote up what a year of this cycle taught me: how I build context before writing code, why I ask AI to throw away my constraints, and what happens when you use two models against each other.
yaodong.dev/push-it-until-it…
I've been running a multi-agent setup on Discord, and it's changed how I manage my day-to-day more than I expected.
The core idea: instead of one AI assistant stretched across everything, split the work into dedicated agents, each with its own domain, its own context, and its own environment. One orchestrates. One codes. One thinks with me about ideas. They don't share context, and that's the point.
The surprising part was where I ended up running them: Discord. Channels map naturally to domains. Threads give you context isolation for free. The channel topic acts as a persistent prompt, so the instruction lives in the space, not in my head. I didn't have to build any of this structure. It was already there.
Docker containers keep the agents genuinely separated. Different environments, independent upgrades, separate failure domains. One can crash without taking the others down. That isolation is what makes the whole thing reliable enough to actually depend on.
What changed for me isn't speed. It's that parallel work became possible at all. While one agent is building, I can be developing an idea with another. The dead time between responses used to feel like waiting. Now it's where everything else moves forward.
The other shift I didn't expect: my mental load dropped. I used to track where every conversation left off, what context to bring back in, what was still in progress. Now the state lives in the system. I can come back to a channel a day later and pick up exactly where things were.
I wrote up the full architecture, the trade-offs, and what I learned along the way:
yaodong.dev/the-multi-agent-…
Exploring OpenClaw's memory system (markdown files, semantic search, daily notes) got me interested in how AI agents manage context more broadly. Its design was surprisingly thoughtful, which made me wonder what else was out there.
That's how I found ByteDance's open-source project OpenViking. Not a fancy algorithm, but a cognitive shift:
Treat memory like a filesystem, not a document.
Think of the agent's memory as a book. Instead of reading it cover to cover every time, the agent can:
• Scan the table of contents (L0, one-line abstract)
• Locate the chapter (L1, key-points overview)
• Pull up details only when needed (L2, full content)
Elegant, but it only solves half the problem. Knowing where to look doesn't help if the shelves keep growing.
OpenViking handles this with lifecycle management. At the end of each session, the system analyzes what happened, extracts useful insights, and writes them back to memory. Important things get reinforced. Irrelevant things fade. The agent gets smarter with use instead of just accumulating data.
This is how human memory works. Important things stick. Trivial things fade. But you can still recall them when you need to.
So the question becomes: how do we apply the same idea to our agents? For anyone running OpenClaw, Claude Code, or similar setups, the takeaway is practical:
• Periodically compress and distill, don't let memory grow unbounded
• Keep hot data small and sharp, pull cold data on demand
• Give your agent a working buffer: room to consolidate before things get trimmed
• Assign TTLs, some things are permanent, others should age out
We're teaching machines the same trick our brains figured out long ago: not everything deserves to be remembered, but what matters should be easy to find.
Using Opus 4.6 in work and found it is very smart but still have faults due to miscommunications. This is not something can be resolved by a smarter model.
A patient named Elliot had surgery to remove a brain tumor. Afterward, his IQ tested normal. Memory, normal. Reasoning, normal. But he couldn't function. He'd spend thirty minutes choosing where to eat lunch, weighing every option endlessly.
Neuroscientist Antonio Damasio figured out what happened: the surgery damaged the region connecting emotions to decisions. Without that "bias" to filter options, everything seemed equally important. When everything is equally important, nothing is.
I've been thinking about this while working with AI. Context windows are expanding fast: from 4K tokens to 128K, heading toward millions. But longer context doesn't always help. Models pay less attention to information in the middle. More can dilute what matters.
Humans have filtering mechanisms we barely notice. We forget gradually, letting details blur while impressions remain. We tag experiences with emotion. We reconstruct memories rather than retrieve them verbatim. AI has none of this. Its filtering criteria come from outside: position, rules, instructions.
If context capacity stops being the bottleneck, what takes its place? Elliot didn't need a bigger brain. He needed something to tell him "this option feels wrong."
Maybe the constraint was never the problem. Maybe it was pointing toward a deeper one.
yaodong.dev/context-is-a-cho…
When adding an AI feature in Ruby on Rails, the first technical challenge is streaming the LLM response.
I started with Turbo Streams. It's the obvious choice for a small project. But for long-running AI calls, the default "fire-and-forget" model fell apart quickly. Connections dropped. Chunks arrived out of order. Users stared at incomplete answers.
So I stepped back and defined what a good streaming architecture actually needs:
1️⃣ Resumability: If a connection flickers, can the client pick up where it left off?
2️⃣ Ordering: Are race conditions shuffling paragraphs randomly?
3️⃣ Non-blocking: Are 60-second LLM calls tying up web server threads, or living in background jobs where they belong?
4️⃣ Reliability: Does every chunk arrive?
After trying a few approaches, I landed on Redis Streams + Server-Sent Events (SSE).
Why this combination works:
LLM calls stay in background jobs, so the web server remains responsive. Redis persists chunks sequentially, which solves ordering. And SSE's “Last-Event-ID” header gives you resumability for free: reconnecting clients automatically retrieve missed chunks.
It's not trivial to set up, and it's probably overkill for a simple chatbot. But for anything production-grade, the debugging experience alone is worth it. Everything is local and inspectable. No third-party dependencies until you genuinely need to scale.
Rails 8.1 doesn't pick up tests due to a minitest 6 issue. Pin minitest to 5 fixes it.
github.com/rails/rails/issue…
