Four Ways to Plan Agent Work, and When to Switch
Bit Byte Bit
SubscribeSign in
Four Ways to Plan Agent Work, and When to Switch<br>Strategies for picking the right planning approach based on the change in front of you
Zarar Siddiqi<br>Jun 22, 2026
Share
This post is for developers who want to learn about the different planning approaches to take during agentic software development. This is my experience, and all of this could be wrong, but it does work for me.<br>The type of planning I reach for depends on the type of change being introduced, and I’ll walk through these from the lightest to the heaviest. But picking the right approach up front is only part of it, as often I start in one mode and realize partway through that I’ve under-planned. The last section covers how I notice that and change direction mid-flight.<br>Planning Approaches
Before walking through each approach, here’s the whole idea in one chart. The way I see it, the effort of planning boils down to two things: 1) do I actually know what I want, and 2) how much breaks if I get it wrong? Everything below is just those two questions playing out.
Simple changes
If a change is dead simple and you feel the chances of the agent messing it up is low to none, you can enter a direct prompt. The three most recent changes I made using this approach are:<br>Double the thickness of the border of the selected item on the product page
Change default radius of ad targeting from 15 km to 25 km
Use component to display statistics instead of raw HTML on dashboard
These are all changes that have easy verification and are 1-15 lines of changes, if that. I find there is no need to get into any sort of complex planning mode here because you could even hand-roll these changes out easily.<br>Agent plan mode
Most agents now ship with some sort of a plan mode which allows you to scope and bound the change before implementation. The plan mode can be invoked using /plan in Claude Code and other agents have similar, if not the exact, command. I reserve agent plan mode for changes where I know what I want to implement but where I want a “preview” of what the agent is about to do.<br>This doesn’t need to be a heavy weight blow-by-blow plan, but something that gives me confidence that it’s about to do the right things, and an opportunity for me to provide guardrails before it does it.<br>These are the three most recent changes I’ve requested an agent-driven plan for:<br>The url is not a required field, but if it is provided, use the url path validator that we implemented recently which allows a / or a http(s) url to be used here.
Add a clickable link next to subscriber count on campaign audience page that opens a modal showing a random sample of targeted subscribers with name and email filters.
Remove the image_aspect thumbnail mode setting for event images as we now derive what aspect ratio to use based on whether the event has single or multiple images
Spec Driven Development Execution
There are changes where I know what I want but I:<br>Expect a bigger blast radius across the codebase (e.g., more than 3-5 files)
Want to spend more time on technical design and architecture
Want a more comprehensive historical record on why the change was introduced
In these cases, I will use a tool like OpenSpec or Superpowers to create a more comprehensive plan which will consider customer needs, technical designs and post-implementation documentation.<br>I’m a big fan of OpenSpec entirely because of how lightweight and non-prescriptive it is. I will start with an /ospx:propose command which will create the high-level proposal, a Gherkin-based spec which can be used as invariants by agents for future changes, a technical design and a task list for review. I will spend perhaps 10-30 minutes reviewing the plan and tweaking it before going into execution.<br>These are the three most recent changes I’ve done using /opsx:propose:<br>Centralize object-level authorization in a shared on_mount hook and replace the per-LiveView/IDOR-open object checks with one shared hook
Create deep links from the order email customer receives to the refund page for that order’s items, while brand settings and not showing user refund links when not applicable to the item they purchased
Derive a brand’s default URL slug from brand name with a mnemonic suffix when URL slug collisions occur (use an existing Elixir library to create suffixes - not random numbers like currently)
The above cases do a significant refactor (1), touch a crucial part of the customer experience which is the email they get (2) and change the internals of how we calculate public-facing URLs (3). These all affect the technical design of the feature to a degree where I want to review the impact in detail to ensure SRP, DRY etc are followed to my liking.<br>Spec Driven Development Brainstorming
In all the above cases so far, I have known what I want the outcome and design to be at some level. In many other cases, I find myself in a position where:<br>I don’t...