Plan mode is dead

Earlier this year, I believed planning was going to become the most important part of building software with AI.

My belief in this idea was so strong that I built and launched an entire desktop coding app around it. Nuanced was motivated by the observation that AI had radically increased the speed and volume of code generation, but interfaces required to support this new pace of working hadn’t caught up yet.

Nuanced’s approach to planning failed, but it also revealed to me how plan modes more broadly aren’t as useful anymore. Historically, plan modes served two purposes: (1) they specified instructions that were sufficiently precise enough for an agent, and (2) they helped humans understand what they were building.

I think #1 is rapidly becoming obsolete as models get better. I think #2 matters more than ever, but plan modes are the wrong abstraction for it, especially as the number of parallel agents we run increases.

Why I built Nuanced

The product I was motivated to build ultimately answered a question I think is still relevant, and will always be relevant, which is: how do humans maintain a coherent mental model of a software system while machines are changing it faster than humans can inspect the changes?

Models could write thousands of lines of code in minutes, meaning you’d inherit a massive maintenance burden before even thinking through what you were building or why. This made it difficult to reason about behavior and debug incorrect assumptions that had prematurely been hardened into code.

While the ease of generating code this way triggered a greater dopamine reward, it obfuscated the uncomfortable work of understanding why building something mattered, whether it mattered at all, and rigorously evaluating product, design, and infrastructure decisions. I would often have a product before consciously making any product decisions. If I under-specified the architecture, the agent would take the liberty of filling those gaps, even if the way it carved abstraction boundaries created problems for me later on. These misunderstandings about intended behavior and design would propagate through several files far beneath the surface of chat, and could be easily missed. Fishing around for problems inscrutable under this surface felt less efficient than having designed something correctly to begin with.

There was something about this experience that made me feel mentally disconnected and zombie-like, especially as coding apps like Conductor and Codex enabled the ability to run more agents in parallel. I felt I couldn’t really focus and access the same depth or understanding about what I was working on as I was able to in beforetimes. This also made it more difficult for me to verify whether generated results were correct.

There was no clear, interpretable trace showing the connection between user prompt → agent decision → code → product behavior. This didn’t mean I wanted to return to the olden days of looking at lines of code or at files. I actually felt that reasoning about ideas in natural language was easier and more efficient. I wanted to confidently sail above the code without having to sacrifice my understanding of how the system worked.

Existing plan modes didn’t feel collaborative enough

I felt that while plan modes existed, the right abstraction for planning well didn’t exist. As I rotated through the Claude Code CLI, to Conductor, and finally Codex when it launched, I found myself meticulously shaping and whittling plans without having a clear home to iterate on them. I would do this by using chat and then copying pieces of a plan into new messages to revise them (before Codex’s annotation features). This cut-and-paste workflow felt clunky and made it arduous to work through an idea while keeping track of the current plan.

I wanted to give my plans a home, ground them in my overall workflow, and take them from being ephemeral blobs of text that disappeared into the backscroll as conversations progressed, into a living, breathing, persistent document. I wanted to turn plan mode into a first-class primitive guiding development for a few reasons:

• I needed to think about what to do.
• I needed to make sure I described it precisely enough.
• I needed to understand what had been done.
• I needed to understand when things went wrong and why.

Building the dream

I thought about my dream workflow, and decided to bring it to life by encoding it into a product. Nuanced let you spin up threads, where each thread was a chat conversation. You would talk through what you wanted to build, and the system would surface ambiguities and decisions that required your input, and together you would arrive at a persistent plan before implementation began. Then, Nuanced would implement your plan, making sure that the generated code adhered to your requirements. I wanted an end-to-end pipeline that started with intent, carried through all the way to implementation, review, and verification. I looked at it more as a prosthesis for the human mind (or my ADHD mind) more than simply just another coding app, in that it was designed to instruct as much as it was to help me keep tabs on what was going on.

Why I was wrong

It’s not so much that my ideas regarding gaps in existing tools or how the SDLC was changing were incorrect, but that our implementation didn’t deliver the solution we expected it to. This is because:

• I conflated planning with a plan
• models got really good
• no one wants to read AI-generated text
• we separated planning from building in a way that was disruptive

Planning != Plan

The first thing we learned was that we had conflated planning with a plan. Those are actually not the same thing. My assumption was that having the space to think thoroughly about something before it was implemented was valuable. I also thought preserving that thinking in a large structured artifact would be valuable as the project evolved. But early users had surprisingly little appetite for that spec.

Models got really good

As models got better at understanding large codebases through context and memory, they excelled at exploring a repository and making reasonable assumptions. The need to explicitly instruct them to produce a well-thought out result had shrunk.

I hadn’t originally thought of model capability as being in competition with designing a better interface for human thinking, but in many ways, it was. This is because each decision the model could reliably make by itself was one fewer decision that needed to be surfaced.

AI-generated text is painful to read

The spec contained more information without creating more clarity. This is because our specs were long. They captured important decisions and contained a lot of context that seemed useful but the problem was: they were AI-generated. There’s something about the pacing and overly structured nature of AI-generated text that makes it very difficult to read. My eyes kept glazing over.

Instead of reacting to this discovery by killing the spec, we built a Spec Tour to solve this. We thought that rather than asking someone to absorb the whole document, Spec Tour could walk them through the important parts. But that only bolted on an additional layer of complexity, more text on my screen demanding attention. If we needed to generate a shorter representation of the spec to make the spec usable, what was the point of the full document in the first place?

We split up a process that needed to feel continuous

Our workflow was too linear and sequential. Our process looked something like this:

chat → disambiguate by answering questions → generate spec → review spec → revise spec → approve → implement → review code

Real thinking doesn’t happen this way, and the separation between these parts felt artificial and forced. Usually you’ll understand a part of the problem, try something, the initial generation teaches you something new, which might make you change your mind about it and try something else. Each step exposes a new question. Planning and building are interleaved and emerge more organically than plan modes allow, especially how we built it in Nuanced. Our interface forced users to prematurely “finish thinking” so that they could start building. Once implementation began, returning to the earlier chat-based reasoning felt like moving backward in the workflow. There was no going back up the waterfall.

When you look at how Codex currently works, the boundary between planning and execution is disappearing as they collapse into one. Earlier on, coding agents benefited from the workflow where humans would do the following:

plan → approve → execute

Back then, the cost of going in the wrong direction was significantly higher. But as agents got better at understanding systems, they also got better at acting autonomously and testing their own work. They’re also good at revising their approach after inspecting the result. This enables a different loop:

understand → act → inspect → clarify → adjust → act again

There is still an enormous amount of planning happening inside that loop, but it doesn’t necessarily need to appear as a document called “the plan”. I think the biggest mistake I made was turning the plan into an artifact instead of designing a process for improved human understanding.

Plan mode and build modes were a strange separation

Nuanced had a plan mode and build mode, and users could start with either. Plan mode always produced a spec, while build mode wouldn’t force users into a spec and could be used for smaller tasks that didn’t justify a spec. But the separation between these modes was awkward and required the user to have to ask themselves the meta-question of whether a task deserved planning, and then remember to activate plan mode through a button or keyboard shortcut if it did. This felt like the kind of distinction AI should make for you based on context it already has, and remembering which mode you needed to be in felt like it introduced more cognitive load.

This realization made me feel like the midwit meme, in that the simplicity of a chat interface where planning was done as-needed rather than by default, was actually pretty great.

We still haven’t solved the understanding problem

Thinking through what to build, why it matters, and evaluating decisions remains important. People need to build a coherent mental model of what’s going on, but I don’t think a large body of AI-generated text is the right interface for that. Working through decisions in chat feels more intuitive, but keeping that understanding up to date as the system changes is still an open problem.

That problem gets harder as you go from five agents to hundreds. Keeping up can’t mean reading every conversation and trying to prompt an explanation for each code change. Agents need to identify the fewest places where human attention can have the greatest impact and surface enough context to make that attention useful.

We still haven’t solved how to help people stay oriented as hundreds of increasingly capable agents are changing the system all at once.