I came to the exact same pattern, with one extra heuristic at the end: spin up a new claude instance after the implementation is complete and ask it to find discrepancies between the plan and the implementation.

The baffling part of the article is all the assertions about how this is unique, novel, not the typical way people are doing this etc.

There are whole products wrapped around this common workflow already (like Augment Intent).

Since the rise of AI systems I really wonder how people wrote code before. This is exactly how I planned out implementation and executed the plan. Might have been some paper notes, a ticket or a white board, buuuuut ... I don't know.

There is not a lot of explanation WHY is this better than doing the opposite: start coding and see how it goes and how this would apply to Codex models.

I do exactly the same, I even developed my own workflows wit Pi agent, which works really well. Here is the reason:

- Claude needs a lot more steering than other models, it's too eager to do stuff and does stupid things and write terrible code without feedback.

- Claude is very good at following the plan, you can even use a much cheaper model if you have a good plan. For example I list every single file which needs edits with a short explanation.

- At the end of the plan, I have a clear picture in my head how the feature will exactly look like and I can be pretty sure the end result will be good enough (given that the model is good at following the plan).

A lot of things don't need planning at all. Simple fixes, refactoring, simple scripts, packaging, etc. Just keep it simple.

Cool, the idea of leaving comments directly in the plan never even occurred to me, even though it really is the obvious thing to do.

Do you markup and then save your comments in any way, and have you tried keeping them so you can review the rules and requirements later?

Google Anti-Gravity has this process built in. This is essentially a cycle a developer would follow: plan/analyse - document/discuss - break down tasks/implement. We’ve been using requirements and design documents as best practice since leaving our teenage bedroom lab for the professional world. I suppose this could be seen as our coding agents coming of age.

My process is similar, but I recently added a new "critique the plan" feedback loop that is yielding good results. Steps:

1. Spec

2. Plan

3. Read the plan & tell it to fix its bad ideas.

4. (NB) Critique the plan (loop) & write a detailed report

5. Update the plan

6. Review and check the plan

7. Implement plan

Detailed here:

https://x.com/PetrusTheron/status/2016887552163119225

I had to stop reading about half way, it's written in that breathless linkedin/ai generated style.

> I am not seeing the performance degradation everyone talks about after 50% context window.

I pretty much agree with that. I use long sessions and stopped trying to optimize the context size, the compaction happens but the plan keeps the details and it works for me.