Planning used to be the part of the workflow I protected most. I treated a written plan as the handoff between judgment and execution, because it made assumptions visible before code made them expensive.
Six months after writing I and AI, where I called planning first non-negotiable, I no longer routinely use the /plan skill or plan mode. I ask a capable model to design the change, review the result, and move into implementation when the direction is clear.
That is faster. I am still deciding whether it is better.
The old loop
My earlier workflow was deliberately explicit: define the scope, write the plan, implement the smallest correct change, verify it, review the result, and ship it. The plan was a shared artifact. It forced the important questions into the open before code made the answer feel settled.
That friction was useful. It exposed unclear requirements, competing approaches, and work that did not earn its place. It also created a natural pause between understanding a problem and changing the system.
It had a cost too. Plans often became another thing to maintain. The model would write a detailed plan, learn something during implementation, and then spend time reconciling the plan instead of simply following the new evidence. The plan was correct when written and stale before the work was finished.
Route by capability
The change started with model routing. Powerful models handle difficult design and high-risk review. Balanced models drive the work and handle normal implementation and debugging. Fast models handle bounded edits and mechanical work. These tiers describe capability, cost, and latency. They are separate from the reasoning effort I choose for a particular call.
I typically use standard reasoning to drive the work. It maintains direction while keeping capability, speed, and cost in balance. I reserve higher reasoning for powerful models when a design needs deeper judgment or a review needs more scrutiny.
I usually tell the driver to consult a powerful model when difficult design or review requires it. I do not decide when to use a less powerful model for execution. The skills make that routing decision for bounded work.
The most powerful model is not automatically the right driver. A driver also needs to maintain direction, notice when the task has changed, and decide when the evidence is sufficient.
The important point is not the exact model assignment. It is that I stopped asking one model to be equally good at direction, design, and mechanical execution.
A recent AI SDK migration made the split concrete. I used standard reasoning to keep the work moving, asked a powerful model to decide whether the change was mechanical, and let a fast model perform the bounded edits. The typecheck, audit, and full test suite then decided whether the migration was actually complete.
Design became implicit
I trust designs from powerful models more than standalone plans. They are produced close to implementation, with the relevant code in view and the next decision still concrete. That makes them more useful when the design has to survive contact with the code.
Instead of asking for a plan, saving it, and then starting a new phase, I ask for the design and let implementation begin when it has answered the actual question in front of us.
This is not an argument that models have made planning obsolete. It is an observation about where the value moved. The design is now part of the working conversation instead of a document that must survive unchanged until the first edit.
Preserve durable context
The conversation is only one layer of context. I use /agents-md to create and maintain the rules agents must follow across tools, and /spec when a project needs a separate source of truth for requirements. When I use /spec, I ask the model to use the skill to update the spec before implementing the change.
The distinction matters when it applies: repository rules explain how the project is operated, while a spec says what must be true. I also use /docs to keep architecture, workflow, and decision records useful to both agents and humans.
Evolve the skills
The skills themselves are part of the workflow, not a static prompt library. My public skills repository contains the applicable skills, which I have revised with workflow pathing, model routing, clearer handoffs, and stronger evidence thresholds. They now help choose what should happen next and which capability is appropriate for it across the tasks where they apply.
Delegate routine review
Code review used to be the slowest part of my workflow. I use /review at work and on personal projects, but work also requires a manual review of every change. On personal projects, I used to do that extra pass too. I now use /review with /correctness-review as one of its dimensions and usually skip the manual pass there.
That has sped up the workflow on personal projects. I still review higher-risk changes myself and remain responsible for the result, but manual review of every diff is no longer the default quality gate there.
What might be lost
Explicit planning does something that a good design response does not always do: it makes omissions visible. A plan can show that a requirement has no owner, that a migration has no rollback, or that the proposed scope is larger than the original problem.
When I remove that step, I may also remove the moment where those problems would have become difficult enough to address. A model can produce a design that is coherent, specific, and wrong. It can make an assumption look settled because the prose is confident.
The risk is not that the model cannot design. It is that the speed of a good design makes it easier to stop questioning the design. I am watching for that now. The workflow is faster, but the burden of noticing missing questions has moved back to me.
Verify more
If planning becomes lighter, verification has to become heavier in the right places. Tests, type checks, linting, integration behavior, and a careful diff review are not the final ceremony after the real work. They are how I find out whether the design survived contact with the codebase.
The checks also need to test behavior, not just the implementation’s preferred shape. A clean typecheck cannot tell me whether a lifecycle response was lost. A passing unit test cannot tell me whether two clients can claim the same last slot. The useful check is the one that would fail for the actual mistake I am trying not to make.
The system also needs to let the model test its changes without waiting for a human to check every step. Acolyte’s /dogfood is a good example: it tells the model to use the product, capture the trace, and report only structural and behavioral findings supported by evidence. The model can run those checks, observe the result, and iterate before handing me the work. This does not replace human judgment. Qualitative feel and high-risk or user-facing behavior still require a manual read when the cost of missing something is high.
This is part of why I built Acolyte. The agent needs to make tools, context, and verification easy to use without trying to replace the model’s judgment. The host can enforce deterministic checks. It should not pretend that a fixed sequence of phases is wiser than the model in every task.
The new rule
I will still write an explicit plan when the requirements are unclear, the change is difficult to reverse, several systems have to move together, or the cost of a wrong assumption is high. In those cases, the planning artifact earns its keep by making uncertainty visible before execution begins.
For smaller and better-understood changes, I am comfortable letting design happen in the loop. A powerful model proposes the direction, a balanced or fast model carries out the bounded work, and verification decides whether the result is acceptable before the change ships.
The distinction I care about is not plan versus no plan. It is thinking versus ceremony. I want less ceremony, not less thought.