Most AI coding failures are not bad code. They are good code for the wrong problem. The model understood the words and misunderstood the intent, then confidently produced 200 lines implementing the misunderstanding.
By the time you see that diff, the cost is already paid. You read it, you realize it solved the wrong thing, you explain again, it regenerates. The expensive part was not the typing. It was the wrong assumption that nobody checked until after the work.
/plan moves the checkpoint earlier
Type /plan and Vesper Code proposes the approach and the files it intends to
touch before it changes anything. You read a short plan, not a large diff. If
the assumption is wrong, you catch it in the one place where catching it is
free: before any code exists.
This is not a new idea. It is how good engineers work with each other. You do not hand someone a finished branch and hope. You say "here's how I'm thinking about this" and let them stop you cheap.
When to use it
- Skip it for a one-line fix. Planning a typo correction is overhead.
- Use it for anything that spans files, touches a data model, or where "the way you'd do it" and "the way the codebase does it" might differ.
- Always use it when you are not sure the agent understood the request. The plan is where you find out, before the cost.
The underlying bet
Every part of Vesper Code's design pushes the same direction: move the moment
of "wait, that's not right" as early as possible. /plan moves it before the
edit. The independent Reviewer
moves a second check after the edit but before you. Layers of cheap
interception around an expensive mistake.
Fast wrong code is not fast. It just sends the bill to your review time and your production incidents. A plan you read in ten seconds is the cheapest review you will ever do.