// HACKER NEWS — CYBERSECURITY
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.
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.
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.