A few weeks back I had three agents building three pages of the same site at the same time, each in its own worktree, and none of them ran into each other. That worked because I'd already had a single agent build every shared component first, so by the time those three started there was nothing left for them to collide over.

If you're doing all your AI-assisted development in one long conversation with your best model, you're burning a lot more tokens than you need to. What I've been using instead is a skill called /improve — your best model surveys the code and writes the plan, then cheaper models go execute it. That's been an easy way to get more out of a coding session, and the most plug-and-play way I've found to get started with sub-agent orchestration.

The project was a client site that started out in Figma. The home page got built first, and a few days later several more pages came in. Some of them shared components with the home page and some didn't.

So that's what I planned first. I ran /improve and had it go through the new pages and figure out which components were shared, then had a single agent build all of those in one pass. Nothing else ran while that happened.

Once they existed I built one landing page on its own to see whether the approach held up. It did. Then I handed the remaining three pages to three agents in three worktrees, each one a separate checkout of the repo, and let them go. Each one was building its own page against components that already existed.

There was a second reason to plan it out first, and it had nothing to do with merge conflicts. The design itself was AI generated, and it wasn't entirely consistent. The sub pages had slightly different font sizes than the home page. Nothing obvious, but they were different.

So part of the plan was to normalize font sizes across the board. Anywhere we were using an h2, that h2 got the same size, even where that went against what the design file actually said.

I wouldn't have gotten that from turning three agents loose. Each one would have built its page to match its own design file, so each one would have carried over a different inconsistency. There was nothing sitting above the three of them to make that call once.

The thing sitting above them is the model that wrote the plan. That split is most of why I keep using this.

Planning runs on the best model I have access to. Execution gets handed down to something cheaper — I was going from Opus 5 for the plan to Sonnet 4.6 for the actual building. You get that handoff without much setup on your end, which matters more than it sounds like it should. Left to my own devices I start a session on the expensive model and then stay there, including for the work that never needed it.

The expensive model doesn't clock out once the plan is written, and that's kind of the point. It tests what comes back. Going back through the chat logs I'll see where the executor hit a stop condition and the orchestrator validated it, or where it caught an error in the plan itself and revised that before sending any more work down. It already knows what the result is supposed to look like, because the plan says so.

The difference shows up in what a session costs. A non-developer at our company built a fully functional site with AI in a couple of weeks. It worked. It also ate roughly a month of our organization's entire credit allotment. Splitting the planning from the execution is what gets you a comparable build for a fraction of that, and a fraction of the time sitting there prompting it.

All of that is about a project while you're in the middle of it. The plans get written into the repo, so there's a record of what the plan was and not just what the code ended up being.

There's a reconcile step I've started using a lot, usually when I come back to something I haven't touched in a while. It'll tell me what plans were next up and what I was in the middle of, which is most of what I've lost by then.

It also catches drift. Plan 12 will contradict a decision I made back in plan 3, usually because the app grew while I was working on it and I added something I'd deliberately left out of the proof of concept. It says so — you decided this earlier, are you sure you want to change it. Usually I do, and then the new plan records why it supersedes the old one and the plan history index gets updated.

That's also what makes this work with other people on it. The plans live in the repo, so anyone can point an agent at one and have it executed, even without the /improve skill. I'd still recommend using it, because it keeps things consistent.

None of this fixes the thing that actually kills my side projects. The models always want to do more and add things, so a simple prompt can spiral out of control. /improve is better about this than most, but it still wants to write tests for everything.

What that turns into is scope creep. A general idea bleeds into more than I have time for in the short term, and I go chase something else.

So there's a balance to it. Planning everything is not the same as being done, and I still want a good understanding of the architecture and the decisions in the code. Not every line of it, but how the whole thing works together.

The plan steps are where that happens. Each one is a place to stop and make a decision, push the thing in the direction I want it to go, and go through the execution plan and the code before any of it goes further. I know why the decisions got made, which I wouldn't if I'd handed the whole thing over.

Product decisions are still hard, and they still need to come from a person. I don't really want to use software where those got made by an AI tool on its own. If you go fully autonomous you get the generalized mass appeal version of a project, because that's what an LLM gives you — the most likely answer. That's fine for some things. It's not what I want to hand a client.

If you want to try it, the entry point is smaller than it sounds. I run /improve with the plan subcommand and a description of what I'm actually trying to do. That works on an existing codebase, and it works starting fresh on a small prototype or a single feature. Most recently I used it for a script that pulls media off a client's site and organizes it by page, which is the kind of tooling I'd never have bothered building before.

The one I keep coming back to is a pro version of my Easy Footnotes WordPress plugin. I've taken a few passes at it over the years and never finished it. The conversation goes stale, new models come out, and I forget where I'd left it.

The plans are still sitting in the repo. That's the part that makes the next pass possible, and it's the reason I'll probably take another one.

Thanks for reading,
Jason

🔧 Tool
shadcn/improve
The go-to skill from this article. I have had great luck using this to test out the higher tier models (Astra + Fable) and let it delegate to cheaper model sub-agents for implementation.

📱 App
Muse by Meta
Meta is getting into the personal agent game with their latest release of Muse. I haven’t tested it much myself yet, but it seems people online are digging it for the UI and getting connected to handle personal tasks. Sure you might have to give Meta more of your data, but chances are they already have it, am I right?

📰 Article
Native is now the future of mobile at Shopify
An interesting read on how the improvements with coding agents has made it possible for Shopify to go native with their iOS and Android apps. Where before they leaned on React Native to handle a single codebase, agent improvements are allowing them to maintain separate native codebases more effeciently.

🥷 Skills
better-ui
The latest skill I’ve added to see if it helps bring better design to my fun little side projects. If it turns out useful it may make its way into the main lineup like /improve. It promises to give your agents some better design chops.

🤺 Skills
humanmade/block-runner
I’m still a WordPress stan at heart even though I haven’t done as much coding in it of late. But this new release from Human Made could be very useful for taking agent coded prototypes into actual editable WordPress blocks.