Two days ago, a Hacker News post titled "Plan mode is dead" caught fire.
It was written by Ayman Nadeem, the founder and CEO of Nuanced, a small AI programming company that is YC-focused.
Earlier this year, Nadeem was convinced that the plan would be the most important link in AI programming. So she created a desktop programming application around this decision, hoping to help developers regain control of the software building process after a significant increase in the speed of code generation.
After a few months, she changed her mind.
What this article really touches on is a loose product assumption in AI programming tools: before writing code, people have to put the needs, architecture, and execution steps together into a complete plan and then hand it over to the Agent.
The following is the original version of the blog (first person title). Planning is translated as Planning and Plan is translated as Planning.
Earlier this year, I believe planning will be the most important link in building software with AI.
I have no doubts about this judgment, and even built and released a whole suite of desktop programming applications around it. The starting point of Nuanced is that AI has significantly increased the speed and quantity of code generation, and the interface that supports this new pace of work is not yet in place.
Nuanced has failed in planning, but this experience has also shown me that the planning model as a whole has not been as useful in the past.
In the past, the planning model primarily carried out two tasks: providing a sufficiently precise instruction to the Agent; helping humans understand what they were building. As model capabilities improved, the first work is rapidly becoming obsolete. The second work is more important than ever, and the planning model is not suitable for this task, especially after the growing number of parallel agents.
Why did I do Nuanced?
The way it delves into abstract boundaries may be a problem for me later on. Misunderstandings about expected behavior and design goals can spread deeply along multiple files, hidden beneath the chat interface, and easily missed.
Under this superficial layer, it's not as efficient to make a design work from the start as it is to explore the difficulty of understanding it.
This experience has left me mentally disconnected from work, and even with some coding applications like Conductor, Codex making it easier to run multiple Agents simultaneously, and this feeling has become apparent as well.
I find it difficult to concentrate as much as I have in the past, and it's also difficult to understand what's going on in depth. Judging whether the output is correct becomes even more difficult.
At the time, there was no clear, explainable trajectory to show the link between "user prompts → agent decisions → code → product behaviour".
This doesn't mean that I want to go back in time and re-read the code or files. In fact, I think it's easier and more efficient to think in natural language. I want to be able to stand on top of the code and continue to understand how the system works.
Lack of collaboration in existing planning patterns
Gradually, I realized that while planning patterns already existed, there was still no abstract way for good planning.
I used the Claude Code CLI, the Conductor, and then the Codex. During that time, I was constantly shaping and deleting plans, but there was no clear place to continue iterating.
Prior to the introduction of the Codex batch function, I was usually only able to push this through chat and modify some of the contents of the plan to be copied into new messages. This kind of copy and paste process was awkward and made it very difficult to work around an idea while mastering the current plan.
I want to give the program a fixed attribution and put it into the overall workflow, so that it gradually floods temporary text in the historical record as the dialogue progresses and becomes a document that can be continuously updated.
I want to turn programming into a first-rate capability to guide development because I need:
I've been thinking about what to do next.
Make sure your description is accurate enough;
Understanding what has been accomplished;
When problems arise, understand when and why they occur.
Creating an ideal workflow
I thought about my ideal way of working and decided to code it into a product.
Nuanced allows users to create multiple threads, each of which is a conversation conversation. The user can discuss what they want to build, the system will point out the differences between them, and the issues that need to be decided by the user. The two sides work together to form a sustainability plan before the implementation begins.
After that, Nuanced will execute as planned, ensuring that the generated code meets user requirements.
I want to build a process that starts with intentions and extends to the complete process of implementation, review and verification.
In my opinion, Nuanced is more like the brains of the human mind, or my ADHD brains. It helps me keep track of what's going on in the project.
Where did I go wrong?
My judgments about existing tool gaps and software development lifecycle changes are largely correct.
There are several reasons: I confuse planning and planning; models become strong enough; no one wants to read the text created by AI; we divide planning and construction in a way that disrupts continuity of work.
Planning (planning) ≠ planning (planning)
First of all, we found that we were confusing planning and planning. The two are not the same thing.
I used to think that it would be valuable to leave room for good thinking before it was implemented. I also thought that it would be valuable to keep these thoughts in a large structured document as the project progresses.
However, early users' interest in this type of specification documentation was unexpectedly low.
The model is strong enough.
As models improve their ability to understand large code libraries through context and memory, they become better at exploring code repositories and making rational judgments on their own.
The need for people to clearly tell models to "produce a well-thought out result" has been reduced.
I hadn't thought that the ability of a model to think and design better interfaces for humans would create a competitive relationship. Every time a model reliably makes a decision on its own, there is less of a decision that needs to be made separately and handed over to humans.
It's painful to read AI-generated text.
The specification document contains more information, but does not provide the same level of clarity.
One of the reasons is that our specification documents are too long. They record important decisions and contain a lot of useful background information.
The rhythm and over-structured writing that AI produces makes it very difficult to read.
After discovering this problem, we didn't immediately abandon the specification documentation, but did a Spec Tour, hoping to focus on the user browsing documentation.
As a result, it just adds another layer of complexity. More text appears on the screen, and more content demands my attention.
If a shorter specification summary has to be reproduced to make the original specification document available, what is the meaning of a complete document?
We're breaking up a process that should be continuous.
Our workflow is too linear and too much emphasis on order.
Create a specification document → Review specification document → Modify specification document → Approve → Implement → Review code
This is not how real thinking works. Separating these links from each other is also human and hard.
Usually, you will first understand part of the problem and then try to do something. The first generation will bring new insights, allow you to change your original idea and try another solution.
Planning and construction are often intertwined and unfold naturally. Planning patterns are difficult to accommodate in this way, especially in Nuanced designs.
Our interface requires users to "finish thinking" prematurely so that they can start building. Once implemented, revert back to the previous chat-based reasoning process, like going backwards in the workflow.
Looking at the way the Codex currently works, you will find that the boundaries between planning and execution are disappearing, and the two are gradually coming together.
In the early days, Agent encoding was better suited to processes such as:
Planning → Approval → Implementation
The cost of going in the wrong direction is much higher.
As agents become better at understanding the system, they become more and more capable of acting autonomously, testing their own work, and adjusting the program after checking the results. This makes another cycle possible:
Understanding → Acting → Checking → Clarifying → Adjusting → Reacting
This cycle still contains a lot of planning, but planning does not necessarily have to be presented as a document called a "plan".
My biggest mistake was to make the plan a document of results, but not to design a process that would enhance human understanding.
It's a strange separation between planning and building.
Nuanced offers both programming and building modes, which users can choose to start with.
The program model always generates a specification document. The build model does not force the user to write the specification document first, which is suitable for small tasks that do not deserve to specify the specification document.
The user should first ask himself a simple question: Is the task worth planning? If it is, remember to enable the program mode with a button or keyboard shortcut.
This distinction should be judged by AI for users based on the context that already exists.
When I realized this, I had a feeling of a "midwit infarct": a simple chat interface that was planned on demand rather than going into the programming process by default, the experience might have been pretty good.
We still haven't solved the problem of understanding.
Thinking about what to build, why it's important, and evaluating decisions is still important. People need to build a coherent understanding of what's going on in the system, but I don't think a piece of AI-generated text is suitable for this task.
The problem becomes even more difficult when the number of agents increases from five to hundreds.
Then change can't mean reading each dialog and then requiring a separate explanation for each code change. Agents need to find a few of the places that are most worthy of attention and provide enough context to really make a difference.
While hundreds of increasingly capable Agents modify a system at the same time, we still don't solve the problem of how to help people maintain a sense of direction.
But in my view, there is always a deeper question: how humans understand systems, how to navigate complex levels of information, how to use powerful tools.
Interfaces change with the technology behind them, so that the need for complexity to be understandable does not disappear.
Hot reviews from netizens
There are people who support and oppose Nadeem's views.
A self-proclaimed Claude Code developer basically agrees with the judgement that "Plan Mode used to be useful but is now declining in value". He explains that Claude Code's Plan Mode has essentially been just a prompter mechanism to remind the model "pre-planning, not writing code right away" and does not really change the tools that the model can be called upon. As the model's capabilities improve, he himself has increasingly used Plan Mode: a better understanding of the model's mission intent, while in more complex tasks, planning also increasingly presents interactive, iterative features that are difficult to complete once in a while.
However, he does not believe that the need to "understand code change" has disappeared. For complex modifications to the core system, he sometimes has Claude produce additional explanatory documents, architectural diagrams or even interactive demos to help himself and other developers understand the modifications and their alternatives, and attach these materials to PR to keep Claude in context for subsequent collaboration and future work on projects.
In mid-2025, Claude Code made a clear distinction between "planning" and "executing" patterns; this was quickly followed by Cursor, GitHub Copilot. In early 2026, OpenAI Codex and Google Gemini CLI also complemented Plan Mode. By March 2026, Plan Mode had evolved from an interactive design by Claude Code into a product format that would provide almost all of the mainstream coding agents.
Another developer believes that the value of Plan Mode remains clear, especially in large code libraries and complex tasks. It at least allows developers to understand the strategies the Agent is ready to take first, and to have the opportunity to examine the design and architecture. If this step is lacking, developers can easily lose their understanding of the code, and Code Review may also degenerate into a simple "tipping through, eventually making the code library increasingly rigid and difficult to maintain".
What do you think?
Hacker News was originally posted at: