Plan Mode for Writers: What AI Coding Can Teach Us
Here's a principle that guides this newsletter: developments in AI coding are a preview of what's coming for AI writing. Coders have been pushing these tools harder and longer than writers have. They've discovered failure modes, developed workarounds, and built workflows that actually work. Writers can learn from their experiments instead of repeating them.
This week, developer Matt Pocock released a video about plan mode—a feature in Claude Code that prevents the AI from writing any code until it has thoroughly explored the codebase and produced a detailed plan. Pocock describes himself as a former AI skeptic who now runs every piece of code through a plan-execute-test loop. His insight isn't just about coding. It's about how to get useful work from AI systems that forget everything between sessions.
"I want you to imagine for a second that you had a colleague who every time they made a commit forgot everything they'd ever learned about the repo. How would you make that colleague productive? Well, probably what you tell them is to explore the repo first before they went and made any changes."
— Matt Pocock
The Core Insight
Plan mode works by disabling the AI's ability to write files. The agent can read the codebase, search documentation, and ping URLs—but it can't change anything. This constraint forces the AI into exploration mode. It loads up context, identifies relevant patterns, and produces a plan document before making any modifications.
Pocock argues this helps both the AI and the developer. The AI gets the context it needs to avoid stupid mistakes. The developer gets clarity about what they actually want—because, as the Pragmatic Programmer puts it, "no one ever knows what they want." Planning becomes a form of rubber ducking: you iterate with the AI until both of you understand the requirements.
Three specific suggestions from the video:
1. Force concision. Pocock adds a line to his configuration file: "Make the plan extremely concise. Sacrifice grammar for the sake of concision." This takes 2,000-word plans down to 400 words. You can scan them quickly and spot problems without drowning in text.
2. Demand questions. His config also says: "At the end of each plan, give me a list of unresolved questions to answer if any." This nudges the AI toward what he calls "an exploratory, slightly worried, paranoid mode"—which surfaces assumptions you'd otherwise discover too late.
3. Make planning iterative. The AI suggests something, you push back, it adjusts. By the end of this loop, both parties have a clearer picture. Then execution becomes simple—you can let the AI work on autopilot because the hard thinking already happened.
Translating to Research
Research has the same problem coding does: the AI doesn't know your context. It doesn't know what you've already read, what angle you're pursuing, what sources you trust, or what arguments you've already considered and rejected. Without that context, it makes assumptions that waste your time.
A "plan mode" for research might look like this: before the AI searches for anything, it interviews you. What's the question you're actually trying to answer? What do you already know? What kinds of sources would be credible for your purposes? What would make a source not worth reading? The AI builds a research plan—specific searches to run, types of sources to prioritize, questions to answer—and you approve or adjust before it executes.
The analogy holds tightly here. Pocock's "force concision" principle applies: a research plan that lists twenty possible sources is less useful than one that prioritizes three and explains why. "Demand questions" works too: the AI should surface what it doesn't know about your needs before burning tokens on searches that miss the mark.
Where the analogy might strain: research is more open-ended than coding. A bug fix has clear success criteria. A research question might evolve as you learn more. Plan mode in research might need more frequent check-ins—not one big plan upfront, but a series of smaller plans as the inquiry develops.
Translating to Writing
Writing has the same amnesiac-colleague problem. Every time you start a new session, the AI doesn't remember your voice, your argument, your audience, or the choices you've already made. It will guess—and often guess wrong.
A "plan mode" for writing would prevent drafting until the AI has explored what you're trying to do. What's the argument? What's the structure? What's the voice? What must be included, and what's out of scope? The AI asks questions, you answer, and together you produce a writing plan before any prose gets generated.
Pocock's principles translate directly. "Force concision" means the writing plan should be shorter than the piece itself—a structural outline, not a rough draft in disguise. "Demand questions" means the AI should ask about audience, stakes, and constraints before assuming defaults. "Make planning iterative" means the plan evolves through dialogue until it feels solid enough to execute.
Where it might break down: writing is messier than coding. Sometimes you don't know what you think until you write it. A plan can become a cage that prevents discovery. The writing equivalent of plan mode might need an escape hatch—a way to abandon the plan when the draft reveals something better.
What This Newsletter Will Do
This coding-to-writing translation is going to be a recurring feature here. When developers figure out something useful—a workflow, a configuration trick, a mental model—I'll ask whether it applies to research and writing. Sometimes the analogy will be tight. Sometimes it will break in interesting ways. Either outcome is worth exploring.
The bet is that AI coding is about eighteen months ahead of AI writing in terms of workflow sophistication. Developers have been forced to figure this out because broken code is obvious and immediate. Broken writing is subtle and easy to ship. But the underlying challenge is the same: how do you collaborate with a system that's powerful but forgetful, capable but assumption-prone?
Plan mode is one answer. Interview first, plan second, execute last. It's not the only answer, and it's not always the right answer. But it's a pattern worth testing—in code, in research, and in writing.
What to Watch
Look for whether writing tools start building plan modes of their own. Notice whether researchers develop formal planning workflows or keep working ad hoc. And pay attention to how your own AI-assisted writing changes when you add an explicit planning step—whether it feels more controlled, more efficient, or more constrained.