Running a small, agent-heavy engineering org at a startup (the part I can say in public), writing about what agents change about the job, and comparing notes with teams working the same way. If you lead one of them, I may have made you a page of your own.
The book, an AI-generated physical artifact 2026
Problem. Could a fully AI-authored object feel like a gift instead of a gimmick?
Approach. A multi-agent pipeline for narrative, typesetting, and print-ready output. I hand-bound the result and gave it to my girlfriend.
Impact. An edition of one, which was the point. The pipeline generalizes to any personalized long-form print. [SLOT: one line on how it landed, only if you want that public]
An always-on personal agent 2025–26
Problem. I wanted code getting written while my laptop was closed, and to find out where an unattended agent actually breaks.
Approach. An OpenClaw instance on a repurposed mini PC, wired into Telegram and my ticket queue. In crank mode it wakes hourly, picks up whatever is assigned to it, and drives each ticket to an open pull request waiting for my review.
Impact. The discovery that now shapes how I run teams: agent capacity was rarely the limit, the quality of my task-writing was. The bottleneck moves to specification. (Told honestly, the box also needs regular gardening. Ask me about the failure modes.)
The Subnet Show, 53 episodes 2021–22
Problem. Avalanche's subnet ecosystem was growing faster than anyone was explaining it. The record of what was being built lived in whitepapers and hype threads.
Approach. I interviewed the people building it, episode after episode, and made them explain their work in plain language. Fifty-three episodes, all still on YouTube.
Impact. 55,000 listens, and an education in asking questions in public. The same muscle now goes into explaining agents and engineering.
How I run teams living
Review attention is the scarce resource. An agent-powered engineer can produce more output than anyone has time to review, and unreviewed volume quietly pollutes a system. Once agents multiply everyone's throughput, the constraint stops being engineering time and becomes review attention. Most of my management system is an answer to this.
I stopped reviewing most code. I review designs instead. Anything that will take more than a day gets a short design discussion first, which catches mistakes while they are cheap and gives the team reps on what matters in this system. Code review depth is then a sliding scale set by trust, per person, never as team policy.
Moving people along the trust spectrum is the job. Some engineers need every PR read. Some need their approaches checked and their gaps backfilled. Some get autonomy by default and a check-in when a problem is genuinely tricky. Leveling each person honestly on that spectrum, then moving them along it, is the actual management work.
Watch the specification bottleneck. When agents are fast, the org's throughput is set by whoever writes the tasks. Task quality now matters more than typing speed, so I spend real time on scoping and tickets, and I expect the team to.