I find it interesting that what the author arrives at is the OODA loop.

The final form became: understand → act → inspect → clarify → adjust → act again

But he says that "understand" isn't really fitting (or something like that), so we are at: act → inspect → clarify → adjust → act again

That can be understood as "observe, orient, adjust, act" - but with other words.

That is the method to use when you are IN the sh*t rather than removed from it and making some theoretical plan.

I thoroughly enjoyed the read <3

Yes, a conversation can be the plan. It helps if you ask it what the commits will be and then tell it to use subagents to implement them.

Also, since sometimes an AI can be a busy beaver, I added instructions to not edit any checked-in files if the prompt contains a question.

A bit late to this party but what the heck.

I too have started using plan mode less, mainly for two reasons: 1. I plan my prompt more carefully and think about architecture up front 2. I found with more recent powerful models, the clarifying questions were generally not useful because it was pointing out issues it obviously knew the answer to and would have resolved in implementation anyway. So essentially they became time-wasting and anxiety inducing for no good reason

The mental shift I made was to not accept poor understanding of a code base on my part when writing the prompt - if I don’t understand it, I can’t predict what assumptions the model will make even on a basic level.

I used to tell myself that plan mode mitigated that, but I usually ended up mentally glossing over the generated plans anyway.

That just resulted in pure anxiety-driven engineering, where I’d often spend extra cycles verifying what was built and worrying about the design.

So invest the time understanding the system, at an appropriate level. That level will change over time as models get better.

I also noticed this personally. Consider when an agent says

"Should I start with the spec, or go straight to building it?

Unless you're working on a super crucial piece of engineering, you can probably get away with going straight to building it. Even if something doesn't go the way you intended, I find that it's usually faster to correct the agent later, once the initial implementation is in place. It's more of an iterative approach to building and I feel that it is less cognitively demanding.

I have rules.md read on every start of the session, in which some of the rules are:

Never start coding befire I say codenow, and add datetime. Before patch explain in plain English what it does. Each file has datetime added to the top of the file, and updated if exist. Each file has a backup copy, created with name.datetime and checked after patch vs backup file, and again with new .backup file for logic vs new backup

I haven't used plan mode for a long time. I do still plan, I usually ask claude to make a plan with me first an explain how it will work, then I iterate with it until I am satisfied and then just let it go. So far it has not started implementing on it's own before I told it to.

I only really used it because the harness was way too trigger happy to start making changes. Even if I just asked a question some times I would come back and it refactored the whole codebase. Now it doesn't seem to do that any more.

I still would appreciate a "read-only" mode. It's not uncommon that I start a harness ONLY to explore and understand the code and I don't really want one typo to have it off building something, or even to save a plan document.

Plan mode is not dead, it just moved to OpenSpec and other similar tools.

If you’re not using those either… I pray for your codebase.

I think Plan mode is very useful when building something that needs step by step validation, but also needs a broad strategy before starting.

For instance, in games where I work, we often need to manually test work out by playing or by using tools in ways that aren't feasible for the AI to do. In that case, getting the human in the loop between steps is an organized process when it's following a staged plan.