Writing

A weekend prototype: an analytics agent that writes the SQL, runs it, and draws a dashboard in a design system I built, on the fly. What generative UI is, and where the boundary has to go.

Building AI agents keeps surfacing problems I already worked through making games. Two of them, and the fix that worked for both.

I spent maybe a month building a five-agent harness. Then Claude Code shipped dynamic workflows that do the orchestration for free, so I raced my harness against one. On correctness they tied. The only edge my harness kept was its rubric, and a rubric is a prompt.

A year of building AI agents, four rules of thumb I keep coming back to, and the one that ties the other three together.

Most agent-design advice tells me to give my agents personas. The research says don't. Or at least, not the way most agent tooling assumes.

Every agent I build hits the same fork in the road. New capability needed. Should it run in the agent's context or in its own?

The first thing most PMs want to do with agents is build a team of them. The research mostly says don't. Here's when that's right, and when it isn't.

Anthropic published the Planner/Generator/Evaluator pattern for long-running app development. My harness inherits the pattern and adds a Plan-Critic, an adjudicating Lead, and the engagement layer that keeps me looped in.

Four pieces of scaffolding I've built around Claude Code to turn one-off sessions into consistent work. A docs tree, a dotfiles repo, a skills layer, and a preview loop.

Some days I feel like Claude's context monkey. The way I do my PM work has shifted, and I haven't fully sat with what it means.

I'm not an engineer, so I don't know what I don't know until I shoot myself with a footgun. Last week: two Claude sessions, one inbox, and a race I didn't see coming.

I solo-built an AI Slack agent for my team this year and didn't write a single line of code. A year ago that sentence would've been an oxymoron.