Annie Tsai

Over the weekend, I spent International Women’s Day in a room with 150 first-time builders.

The energy was extraordinary — 150 people, most of them building something for the very first time, using Lovable to bring an idea to life without needing to write a single line of code. I was there as a volunteer, walking the floor, helping people get unstuck.

And the same thing kept happening, over and over, in more than half of the conversations.

Someone would show me what they were working on, where they were in the process. “I’m building this.” And more often than not, they had started building with an idea for a product in mind without necessarily a clear problem statement that had enabled them to dig into enough detail to break through the idea-to-implementation chasm. Sometimes, they’d gotten so deep into building one feature that they’d lost the thread of what the thing was even supposed to do. This was expected — we were there to just get started. And part of my role was to help people new to the process get unstuck.

Every single time, I asked them the same question: “Did you go into plan mode first?”

And every single time, I got a version of the same response: uncertainty. I mean these builders were incredibly smart and had already done a lot of work around lived experience with a problem they were out to solve with technology. But, plan mode had never come up. They simply hadn’t been made aware that this was an option or an important step in the building process.

I left that day genuinely wondering: if 150 motivated, engaged builders in one room had never heard of plan mode, how many millions of people are opening these tools every day and going straight to “doing” simply because no one told them there was another way to start?

The Button in the Toolbar You’ve Been Ignoring

Here’s the thing: it’s not just a metaphor. Plan mode is a real capability in most of the major AI assistant tools right now, and I would guess that most of you have never clicked on the buttons or dropped the “right” prompts in the chat box.

In Lovable, there’s a “Plan” button sitting next to the message input – it visually reads as “chat” but the action is to stop “doing” and start “thinking and talking.” Click it before you send your first message, and instead of immediately generating an app from your prompt, Lovable shifts into a conversational mode. It asks you clarifying questions about your vision, your constraints, your tradeoffs. It helps you explore different approaches and make key decisions before a single line of code is written. When you’re ready, it creates a formal plan document that you can review, edit, and approve — and only then does it switch to Agent mode to build. The plan is saved to your project file for reference. Every message in Plan mode costs one credit, but the credits you save by not having to rebuild something you didn’t mean to build in the first place are not small. You can also instruct Lovable to go into planning mode with a prompt, which is what I usually do.

In Cursor, you hit Shift + Tab in the agent input to trigger plan mode. Cursor researches your codebase, reviews relevant files and documentation, asks clarifying questions about your requirements, and generates a markdown plan with specific file paths and code references that you can edit directly, adding or removing to-dos before you approve anything. Cursor has four distinct modes — Agent, Ask, Plan, and Debug — and so many users I talk to have never left Agent mode.

In GitHub Copilot, plan mode is available across VS Code, JetBrains, Eclipse, and Xcode via the agents dropdown. It analyzes your codebase, generates a detailed execution plan, validates that your requirements are covered, and asks clarifying questions before writing a single line of code. In the CLI, it’s Shift + Tab to toggle in and out. Like Lovable, no code changes happen until you’ve reviewed and approved the plan.

In Windsurf, the planning capability is built into Cascade, their agentic system. It handles multi-step task orchestration and is designed to think through a problem across your full codebase before it starts executing — though it’s less of a discrete toggle and more of a mode you invoke by how you prompt it.

If you’re using Claude Code, you have to prompt to plan, and you can use any of the prompts noted later in this newsletter but I often will ask CC to research existing local project files and add new requirements or considerations as the starting point for planning and problem identification. You can do this in Cursor and I imagine Github Copilot as well.

In Claude and ChatGPT, there’s no button, toggle, or dropdown. You have to prompt your way into planning mode — which is both the feature and the problem, because most people don’t know to do it, and the blank text box is always asking you to just go.

There is a real pattern in AI-assisted tools, and that is that are most focused on building and taking action so they have made planning a first-class feature without prioritizing it as a key component of the building process. The conversational tools have left it as an exercise for the user. And across all of them the vast majority of people are skipping the step entirely regardless of if there is or isn’t a button to plan.

The Product Management Principle That Changes Everything

I’ve spent a few years now building AI systems and working through the discipline of product management, and the single most important lesson I keep relearning is this: the most expensive mistake you can make is solving the wrong problem efficiently.

In product, we call this being solution-focused versus problem-obsessed. Solution-focused is when you come in with a feature in mind and start building toward it. Problem-obsessed is when you slow down long enough to ask — what is the actual problem I’m solving, for whom, and how will I know when I’ve solved it? — before you write a single line of requirements.

The teams that skip this step build things that are technically impressive and functionally off. The teams that do this step well ship faster, with less rework, and end up with products that people actually use.

AI tools only accelerate this dynamic. If you’re problem-obsessed before you prompt, the outputs are dramatically better. If you’re solution-focused, you generate your way into the wrong thing at unprecedented speed.

The way I work at the beginning of every AI-assisted project: before I build anything meaningful with AI, whether it’s a new feature, a complex workflow, an agentic system, a piece of content with real stakes, I write a rough PRD (product requirements document) first. My version of a PRD is more a thinking document than a deeply structured document meant to hand off to create sprints. Most important for me to think through are: what problem am I actually solving, who is it for, what does success look like, where in the stage of solution sophistication is this within the broader scope of the problem, and what are the constraints I have to consider and work through?

I work through that document with my AI as a thought partner, not a builder. By the time I’m done, I have a brief that’s a living document and I can use this to ingest into my AI-assisted builder to execute against.

Every single output downstream is better for it.

How to Surface Planning Mode When There’s No Button

For the tools that don’t give you a toggle (or for when you want to go deeper than what the toggle surfaces) here are the prompts that actually shift the mode:

“Before we build anything, I want to make sure I’m focusing on the right problem. Ask me questions until you can summarize my actual goal, who it’s for, and what success looks like.”

“Here’s what I’m thinking of building: [description]. What assumptions am I making that are most likely to be wrong? What would a skeptic say about this approach?”

“Help me write a one-page brief for this before we start. What do you need to know from me to make it useful?”

“I want to pressure-test this idea before I commit to it. Play devil’s advocate.”

“What am I probably not thinking about? What are the most common failure modes for something like this?”

“Summarize what you understand about my goal, my audience, and my constraints — then tell me what’s still ambiguous before we proceed.”

Notice the pattern here. Every one of these prompts asks your LLM to surface what it needs from you and help you think before you ask it to produce anything. That’s the whole move, and it works whether you’re in Claude, ChatGPT, Lovable, Cursor, or anywhere else.

What a Planning Conversation Actually Produces

If you’re building a product or feature, spend fifteen minutes in planning mode before you open your build tool. Use something like: “I want to build [thing]. Before we write any code or specs, help me work through the problem. Who specifically has this problem? What have they already tried? What does a good solution actually need to do, and what does it explicitly not need to do?”

What comes back is the foundation of your PRD, a brief that you then hand to your build tool as the instruction set. The first build output will be dramatically closer to right, revision loops will be shorter, and you’ll spend less time backtracking from decisions you didn’t realize you were making.

If you’re making a strategic decision, try: “I’m trying to decide [decision]. Before you give me recommendations, help me map the assumptions I’m making and identify the ones most likely to be wrong. What information would most change my thinking here?”

This is a pre-mortem, or one of the highest-leverage tools in decision-making. Using your AI tools like this broadens the scope of information available to you in ten minutes, on any decision and at any scale. The questions it surfaces are often the ones your team would only think to ask three months in, after something had already gone sideways.

If you’re focusing on content generation, start with: “I need to write [piece]. Before you draft anything, help me get clear on the one thing I want the reader to feel or do, the single most important idea I need to communicate, and the three most common ways this kind of piece falls flat. Then, let’s discuss the story arc and how the key points flow throughout.”

The planning conversation becomes the brief, the brief becomes the prompt, and the output much more closely meets your expectations.

The Planning Conversation Is a Deliverable

Here’s the move most people leave on the table: the output of a good planning session is itself something worth keeping and potentially turning into a repeatable skill within your AI tools.

At the end of a strong planning conversation, you have real material — a brief, a spec, a set of clarified constraints, a decision framework — that you can save, reuse, and build from. Don’t let it disappear into the chat history.

Three things worth doing at the end of any planning session:

Ask your AI to summarize what you’ve established into a one-paragraph brief or recurring workflows into a prompt template for similar work or if you’re using Claude, create a skill against so you can prompt the entire process end-to-end with a couple of keystrokes.

For strategic decisions, ask it to write a lightweight decision doc that includes sections for problem, assumptions validated, alternatives considered, recommendation, and key risks. You can then add this template into your context so your team can easily reuse and reference instead of relitigating the same ground six months later.

Your Takeaway This Week

The blank box will always be there. The temptation to just start outputting stuff will always be strong, especially with the UI is biased towards action and when life keeps moving faster.

Don’t skip planning mode with any project, no matter how big or small. I promise you it’ll be worth your time.

Plan first, build second. Everything downstream gets better.

---

If you found this issue useful, share it with someone who’s building something right now. I wrote this newsletter for us — the people building the future at work.

– Annie