I love to use the Plan mode, but when I do it with Composer 2 model, each time I ask for changes (change the implementation, add details, correct some asumptions …), the model update the plan but refer to the “old one”.
For example, if I ask it to do A and B with each one many details, and then tell it something about B (to fix something, add details …), it “changes” how A is described and often write something like “(unchanged)” or “we still follow the old plan” but stripes some details along the way.
Another thing : the plan often contains sentences that sound like questions it should ask the human instead of only writing them in the plan description. In my opinion, the plan itself should be affirmative, not “poisoned” with interrogations / multiple implementation paths, and to do that, it can (should) ask me questions.
I assume it’s a system prompt problem, not the model itself. I often use Opus model too to plan changes, and this model seems far better at writing plans because it does less these things : it asks questions more often, is declarative in plan, keep details when iterating on it. It really feels like Composer 2 is this close to produce equal quality, and it does when adding all this “harness” manually.
Hope this feedback can help improve the product, don’t know if I’m alone to have this feeling when using plan mode.
Thanks for the feedback @Christophe_Hautenne! Sending it over to the team working on Composer!
Honestly, I don’t hear too much about Composer being used for Plan Mode. Often what we hear users do is the opposite: plan with a more expensive/advanced model, then execute with Composer.
Outside of these two issues you’ve described, how do you like the plans created with Composer?
I’m convinced models today are already powerful enough to do incredible things, and the project on which they work (architecture, code quality, documentation), and of course the Prompt (with a capital P, to take into account user prompt, system prompt, cursor rules, skills … every bit given to the model) have a far more important impact than the model performance itself.
Yes, there are moment where you want the bigger model do the heavy part of researching the best approach, but I do professionnal work most of the times in big projects, not vibe coding starting from nothing. The plan mode is almost used as “prepare your work on this codebase” rather than “imagine a whole architecture”, so the “bigger” model is not always the good solution when we take into account the pricing associated and speed.
With infinite resources, today, I would be a liar if I say I wouldn’t use Opus 4.7 max everytime, but I don’t have them and Composer 2 is good enough when you know how to describe your intention.
That’s why I made these suggestions: improve a nice feature with an already capable model and some tweaking that could also be profitable for any future, bigger, better model.
My process is something like :
Do planning with the best performance model, and implement with the second best, more sustainable (from an economic point) model
Implement rules, guidelines, linter, checker, tests, anything deterministic that control the result
When I’m confident and don’t need to add control anymore, use a less expensive model for planning and implementation. This will increase the need of control process on smaller details, but every cycle, rules are stronger, result more deterministic, and code is generated faster than ever