[bmurphy1976]

I'm not using Cursor at the moment, but when I did (not too long ago) my experience was similar. Plan with Opus, implement with Composer, clean up with Opus.

Composer did a competent but not amazing job with a good plan. What I really liked though is it was fast! Opus could take 30 minutes to do something Composer would get done in 5-10 minutes. Of course the output wasn't perfect, but that's why I'd do a cleanup pass using Opus or Codex.

It's all a balance though, constantly changing and completely dependent on the problem you're solving. I just remain flexible and adapt my process to what's working best in the moment.

[ignoramous]

Interesting. If I may: What was this "clean up" pass? A code review? A code review with specialized prompt? A focused review to check for edge cases / logic errors / api misuse? Or, something else specific to the codebase?

Have you settled on what the clean up pass should look like? Or, do you keep experimenting with it?

In case one might not have been aware: Composer 2 was Kimi Base 2.5 post-trained (RL'd) by Cursor: https://news.ycombinator.com/item?id=48507474. Composer 2.5 might be something totally different.

[bmurphy1976]

I end every project with a long interrogation session. Why did you do this? Is there a better approach you didn't consider? Do the naming conventions follow the project idioms? Justify the decision you made here, providing evidence. I disagree with your approach, etc. etc.

Doesn't matter which model wrote the code, they all make mistakes. This is the same stuff I'd do with any junior engineer's PR and it leads to better quality outcomes (something I care about and am finding hard to let go).

Fable is particularly good at having this back and forth I'm discovering.