As you interact more with LLM and agentic tools you start developing an intuition of sorts to make better use of the workflow and developing ideas to make them better.

One such simplest and neat ideas is Architect-to-Builder. It’s a pattern wherein you use a more capable model to write a proper plan of exactly what you want, it creates a plan, a proper summary of what is needed and also a phased plan of several subtasks with all edge cases thought through, definition of done etc.

Once that is done, then we can dispatch those subtasks to an implementor like Sonnet-5-high or grok-4.6 (at the time of writing this). Sonnet is a proper workhorse, it implements so well, most of the solutions are pretty good and don’t require any fixes / further changes. Grok does need it from time to time. So handholding, proper supervision is necessary.

Architect and Builder roles

Architect: researches, makes the trade-offs, and writes the plan. It does not implement. Builder: reads the plan, does exactly one approved phase, records what actually happened, and stops. It does not redesign.

My favourite architect is either Opus-5 or GPT-sol-xtrahigh, lately Opus is just being extremely verbose claudish hard to follow, I constantly ask it to make it crisp and simple English and I made it a mandatory cursor rule across the project to not be verbosemaxxing and avoid tokenshitting.

Each plan file consists of 2 components one for humans, another for AI agents.

Architecture and Strategy

How it fits the current system, control/data flow, decisions made, alternatives rejected, trade-offs, security constraints, migration concerns. Assumptions and open blockers in plain language. If a teammate (or future me) opens the file, this section should not feel “wtf is going on”.

Implementation Blueprint

This one is for the implementing model. Density over readability. This is sometimes hard to read as it is in LLMish language, I think people won’t be reading this layer much and plan layer will contain overall system architecture and this would be mostly like detailed chunks of tests written for LLM to efficiently implement without exploring thousands of files and burning tokens, I have noticed many times in Sonnet, it takes like few minutes to even start single line of code, if you inspect the thoughts / tool usage of that model, you will see it read tons of files.

Work gets cut into numbered phases each plan is assigned a suitable model to build.

A phase is too big when more than one of these is true:

• It touches more than roughly eight files, or more than one schema migration
• It can’t be verified with one focused command or test run
• It wouldn’t make sense as a single reviewable commit
• It spans unrelated subsystems

If the whole request can’t be done accurately in one sitting, I don’t start it. I push for a finer phase list and wait. Half a context window is about the budget I want for real work once you count reads and tool output, burn past that and quality falls off a cliff even when the model still sounds confident.

Phase status lives in the headings:

### Phase 2 - wire the webhook handler [x] Complete

Planned, in progress, complete, or blocked. That status line is the source of truth. Todo lists mirror it; they don’t contradict it.

After each phase, the Builder marks it done (or blocked), writes what changed and what drifted from the blueprint, then revises the later phases based on what the code actually looked like. A plan that only gets written once is fiction. The useful version is the one that absorbs reality after every mergeable chunk.

Time-to-first-code

The metric I care about for the blueprint is simple: how fast can the Builder write the first real line of code after opening the plan? If it’s productive before chewing through ~15% of the context window, the plan did its job. If the first half of the session is the model rediscovering the repo, the Architect failed — usually by being vague, skipping paths, or leaving “figure out the existing pattern” as an exercise.

I keep this as a local Cursor skill so I don’t have to restate the protocol every time. Architect chat writes or updates the plan. Builder chat gets a one-liner: implement Phase N of this file, that phase only, then stop and report. An engineer with right system design knowledge and taste can go a long way in crafting a best plan, with proper sub tasks to give enough to Sonnet in each phase so it doesn’t spill over into next context, this setup is best for tasks M+, as with anything in life as humans use AI better and better, new ideas and intuition comes to mind constantly to improve the workflow.

P.S. I'm on X as @arvzhq if you want more of this. RSS is in the footer.