Building with a team of agents

The most interesting thing I've shipped lately isn't a feature, it's a way of working. Most of what went out the door in the last couple of months, a full Petal Pro release and a wave of new components, came out of running a small fleet of AI agents rather than sitting and typing it all myself. The texture of building has changed, and I've learned a fair bit about where it helps and where it very much doesn't.

Different models for different jobs

I've stopped using one model for everything. These days I run a fast one (Fable 5.2) for the main loop, the orchestration and the high-volume passes, and put a slower, deeper one (Opus) on the agents doing the actual hard thinking. It sounds fussy, but it's just tool selection. You wouldn't reach for the same model to rename twenty files and to untangle a billing edge case, any more than you'd use the same saw to frame a house and to trim a dovetail. Knowing which to reach for is a real skill now.

Agents that argue

The shape that works for me isn't one assistant in a loop. It's several agents in parallel, each on its own slice in its own branch, and then, this is the part that matters, two reviewers pointed at the result with opposite instructions. One is told to attack the code for correctness. The other is told to hunt for regressions against the design rules. Both are told to try to prove the work wrong, not to wave it through.

An agent that wants to agree with you is close to useless. One that's trying to catch you out is worth a lot. Those two reviewers find real problems the builder missed on roughly a third of the work: a contrast failure, a stray heading injected above every title, a double welcome email, the kind of thing that's invisible right up until a user hits it.

What it built: a settings overhaul

The clearest example is Petal Pro 4.5. The whole settings surface, around fifteen screens, got rebuilt. The navigation lifted out of the content card into a proper two-pane layout, real microcopy instead of the literal word "Settings" sitting on every page, designed empty states, a cancellation dialog that actually tells you what you're cancelling before you do. Underneath all of it is one idea: the boilerplate now uses the current component system for its own screens instead of hand-rolled markup. The agents did the mechanical lift across all fifteen screens. I made the design calls.

Before: the navigation lived inside the content card.

After, in both modes: two panes, a real subtitle, dark mode that was designed rather than inverted.

And a wave of components

On the library side, petal_components went from 4.14 to 4.18 in the same window. The middle of that was a single release that added something like twenty new components at once: a calendar and date picker, a file upload, a tree, a timeline, a resizable panel, a proper empty-state primitive. That's the kind of volume that's only possible when you can run the building in parallel and trust the reviewers to keep it honest.

One of the new ones: the date picker, open on a two-month range.

The one job I didn't hand over

Here's the part that keeps me honest about all this. The agents open and verify pull requests. They do not merge them, and they do not ship. I do. On a big day they'll open forty-odd PRs across the repos, and every one waits for me to read it, make the call, and press the button.

That isn't a safety rail I'll quietly remove once I trust them more. It's the actual job. AI made the building cheap, which just moved the bottleneck to deciding what's worth building and judging whether what came back is any good. The taste, the call on what ships, still mine. My day looks a lot more like editing and directing than typing now, and I've come to think that's exactly the right shape.

AI didn't take the interesting part of the work. It took the typing and handed me more of the deciding. I'll take that trade.