The toolbelt
Four tools do almost everything. I talk or type, agents write, every change is a commit, every push gets a preview.
Right model
for the job
Not every task needs the same brain. I match the model to the complexity — big planning sessions for hard problems, a fast composer for tiny tweaks.
- Complex
I plan with Opus or Fable first, then Composer 2.5 implements — or I tell Fable to orchestrate Composer 2.5 subagents.
Example prompt “Plan a behind-the-scenes page about my AI workflow. Don't implement yet — just the structure and copy outline.”
- Medium
I use Grok 4.5 in Cursor for focused feature work that still needs judgment, not a full planning session.
Example prompt “Tighten the hero spacing on mobile and make the footer link label match the new page name.”
- Simple
A clean Composer 2.5 instance — text tweaks, image swaps, one-liners. Fast and disposable.
Example prompt “Rename the CTA from “Let’s talk” to “Get in touch” and bump the logo 4px up.”
The feedback loop
Browser open, Cursor in the background. I walk the page, hit speech-to-text (or type), dump everything I notice, paste it in — and while the agent ships, I'm already collecting the next round. Running those in parallel is how this stays roughly five times faster than waiting for each fix.
Me
- 1. Looking at the page
- 2. Dictating one or two points of feedback
- 3. Over to Cursor — paste, hit enter
- 4. Back to the page, collecting more feedback
“Move the CTA up a bit, rename Duo to Built Together, and the animation delay on the fireflies feels too snappy — add 150ms.”
Agent
- 1. Reads the notes
- 2. Implements the changes
- 3. Commits and pushes
- 4. Ready for the next paste
By the time a fix lands, the next batch of notes is already waiting.
Match the mode
to the work
Same tools, different shapes. I pick the mode based on how big and how tangled the work is — here's how they compare side by side.
- Multitask mode
- Orchestration
- Composer 2.5 direct
- Fable planning
- Multitask mode
Best for · Lots of tiny, independent tasks
I send several small prompts at once. An orchestrator fans them out to parallel subagents and merges the results.
Example prompt “Fix the mobile nav gap. Swap the OG image. Shorten the about paragraph.”
Pros
- Very fast for backlog clearing
- True parallel execution
- Great when tasks don't touch the same files
Cons
- A sub-agent might stash another agent's changes — gets really messy
- Harder to follow as one narrative
- Harder to cancel or reorder — no queue to shuffle by importance or delete items
- Orchestration
Best for · Bigger features with many steps
One strong model stays in charge. It plans the work, then spawns Composer 2.5 subagents to implement each piece.
Example prompt “You are the orchestrator. For everything that needs to be done, spawn sub-agents of model Composer 2.5.”
Pros
- One brain keeps the plan coherent
- Workers stay cheap and fast
- Scales without me micromanaging each step
Cons
- Depends on a good orchestrator model
- Can over-spawn for simple work
- Harder for me to interrupt mid-flight
- Composer 2.5 direct
Best for · Simple text, layout, and asset tweaks
A clean Composer 2.5 chat. No ceremony — I paste the note, let it ship, move on.
Example prompt “Move the contact button 12px left, rename the section to Work, and slow the firefly delay by 200ms.”
Pros
- Lowest friction
- Fastest feedback cycle
- Ideal for polish passes
Cons
- Weak on big architectural decisions
- Easy to lose context across many chats
- I do the sequencing myself
- Fable planning
Best for · Ambiguous or high-stakes changes
I start in Plan mode with Fable (or Opus). We agree on the approach, then I hand implementation to Composer 2.5 — or tell Fable to orchestrate it.
Example prompt “We're in plan mode. Design how the cloud preview workflow should work on this site. Pros, cons, and a concrete file list — no code yet.”
Pros
- Fewer wrong turns
- Clear acceptance criteria up front
- Great handoff into implementation
Cons
- Slower to start
- Overkill for tiny edits
- Plan can drift if I skip the review
Local vs cloud
Same agents, same prompts — different where the loop runs. Local is the fast desk loop. Cloud is the anywhere loop, with a preview URL and a cost.
- Local
Best for · Polish passes and rapid visual iteration
Desktop loop. Browser and Cursor side by side — see a change the moment it lands.
- 01 Looking at localhost
- 02 Dictate or type a couple of notes
- 03 Paste into Cursor, hit enter
- 04 Hot reload — check, collect more feedback
- 05 Commit when a batch feels done
Example prompt “Move the CTA up a bit. Firefly delay feels snappy — add 150ms.”
Pros
- Instant feedback — no deploy wait
- Easy to interrupt mid-flow
- Doesn't burn Netlify minutes
Cons
- Tied to the desk
- Preview is only on this machine
- Cloud
Best for · Working from the phone or away from the desk
One long-lived pull request on a work branch. Agents push; Netlify keeps a preview URL fresh.
- 01 Looking at the Netlify preview
- 02 Dictate or type feedback — phone or laptop
- 03 Agent edits, commits, pushes — version bumps
- 04 Netlify sees the push and redeploys
- 05 Back to the preview — new version, more notes, repeat
Example prompt “The hero CTA sits too low on mobile. Nudge it up 12px and make the supporting line one step quieter.”
Pros
- Works from anywhere
- Real preview URL to share
- Same PR accumulates the session
Cons
- Wait for each redeploy
- ~200 prompts ≈ 200 builds
- Netlify minutes evaporate fast