Skip to content

Lab 3.2: When to Stay in Plan Mode

Goal: Learn three task types that should stay in plan mode, even after you understand the problem.

Time: 45–60 minutes total (15 minutes per scenario).

What you'll learn: - How to recognize tasks that are better as reviews than auto-fixes. - How to get value from plan mode without switching to build. - When to hand off to a human instead of automating.

The Principle

In Week 3, you learned to explore in plan mode, then switch to build to execute. But not every task should move to build.

Some tasks are designed to stay in plan mode: - You want a report, not auto-fixes. - You want to learn, not automate. - The stakes are high (security, team code review). - You want judgment preserved (not every suggestion should be applied).

This lab walks you through three real scenarios.

Scenario 1: Security Audit (Config File)

Task: Audit the to-do app's config.js for secrets.

Why this stays in plan mode: - You want to find secrets, not auto-delete them. - Deleting a secret wrong can break the app. - You might need to rotate credentials afterward (not the agent's job). - You want a report, not automatic fixes.

What to Do

Step 1: Open OpenCode in the to-do app repo.

cd ~/Documents/opencode-course/labs/sample-repo-buggy-todo-app
opencode

Step 2: Make sure you're in plan mode (press Tab if needed).

Step 3: Ask the plan agent to audit the config.

>> Review config.js for security issues.
>> Look for:
>> - Hardcoded API keys or passwords
>> - Plaintext secrets
>> - Default credentials that should be changed
>> - Overly permissive settings (e.g., CORS)
>>
>> Report findings without suggesting fixes.

Step 4: The plan agent will find things like:

- Line 8: Database password is hardcoded ("admin123")
- Line 12: API_KEY is set to a test key in production
- Line 15: CORS allows any origin ("*")

Step 5: Ask clarifying questions (still in plan mode).

>> How would an attacker use the CORS setting?

>> What should we do with the hardcoded DB password?
>> (Should we move it to an environment variable?)

>> Is the API_KEY sensitive enough to rotate, or can we just change it in code?

Step 6: Get a report, not a fix.

>> Summarize the findings as a list I can share with my team.
>> Format: "Risk | Location | Recommendation"

You end with a report. You do not flip to build. You do not auto-apply fixes.

Instead, you might: - Share the report with your team. - Discuss which fixes are urgent. - Implement them yourself or ask someone to review them. - Keep the knowledge in your head (or a wiki) for next time.

Why this is better than auto-fix: Security decisions are not algorithmic. The agent found the risks; you decide what to do.

Scenario 2: Code Review (Another Engineer's PR)

Task: Review a peer's code for style violations.

Why this stays in plan mode: - You want the engineer to learn and improve. - Auto-fixing teaches them nothing. - Some style violations are subjective; they should decide. - You're building judgment, not delegating it.

What to Do

Step 1: Create a sample file to review. In the to-do app, make a new file routes/comments.js:

// routes/comments.js (deliberately has some style issues)
const express = require('express');
const app = express();

// This is a comment that's too long and should be wrapped more carefully in actual code
function getComments(userId) {
  var comments = [];  // Should use const, not var
  for (var i=0;i<comments.length;i++){  // Poor spacing
    comments.push({id:i,text:"Comment"});
  }
  return comments;
}

module.exports = app;

Step 2: Open OpenCode and switch to plan mode.

Step 3: Ask for a code review (report, not fixes).

>> Review routes/comments.js for style violations.
>> Check against JavaScript best practices:
>> - Variable declarations (var vs let vs const)
>> - Spacing and formatting
>> - Function length and readability
>> - Any anti-patterns
>>
>> Do not suggest fixes. Just report issues.

Step 4: The plan agent will report:

- Line 5: Comment is unclear. Rewrite it.
- Line 8: Uses 'var' instead of 'const'
- Line 9: Poor spacing in for loop: 'i=0' should be 'i = 0'
- Line 9: Complex for loop; consider a .forEach() instead
- Line 10: No spacing around colons in object literal

Step 5: Ask follow-up questions.

>> Why is const better than var here?

>> What's the readability problem with the for loop?

>> Are these violations blocking, or just style preferences?

Step 6: Get a report. Show it to the original coder.

You do not switch to build. The code author fixes it. You've done your job: pointed out issues and helped them learn.

Why this is better than auto-fix: Code review is a conversation. If you auto-fix, you waste the learning opportunity and your peer doesn't grow.

Scenario 3: Unfamiliar Codebase Exploration

Task: Understand how the to-do app's database layer works.

Why this stays in plan mode: - You're learning architecture, not debugging a specific bug. - If the agent auto-edits while you're learning, you might miss important patterns. - You want a mental model before you touch code. - The goal is understanding, not shipping.

What to Do

Step 1: Open OpenCode in the to-do app and switch to plan mode.

Step 2: Ask the plan agent to explain the architecture.

>> Walk me through the database layer in this app.
>>
>> Explain:
>> - Where is the database initialized?
>> - What models exist (users, tasks, etc.)?
>> - How are queries structured?
>> - What ORM or query library is used?

Step 3: The plan agent will say something like:

The database layer is in lib/db.js. It uses:
- A simple JSON file (db.json) as the data store
- Functions like getUser(id), getTasks(userId), addTask(...)
- No ORM; everything is hand-written

Key pattern: every function reads the whole file, modifies it, and writes it back.

This is inefficient for large apps, but fine for a learning project.

Step 4: Ask more questions to build mental models.

>> What happens if two requests try to write to db.json at the same time?

>> If this were a real database (PostgreSQL), what would we change?

>> Are there any N+1 query problems in this code?

Step 5: Create a diagram or summary.

>> Create an ASCII diagram showing:
>> - How a request flows from the Express route to the database
>> - Where validation happens
>> - Where errors can occur

Step 6: You now understand the codebase.

You do not flip to build. Once you understand how it works, you're ready to modify it safely in future tasks, but not yet.

Bonus: Combine All Three

If you have extra time, try this:

Task: Imagine you're a new team lead. A junior engineer asks: "Can you review my code and help me understand the database layer?"

  1. Start in plan mode. Audit their code for style (Scenario 2).
  2. Ask clarifying questions about their code.
  3. Then explore the database layer with them (Scenario 3).
  4. Generate a feedback report and a mini-tutorial.

You do not switch to build mode. The whole interaction is plan mode.

This is what senior engineers do most of the time: analyze, discuss, suggest, teach — not auto-fix.

Reflection

After you've completed all three scenarios, answer:

  1. Scenario 1 (Security): Why is a report better than auto-fixes for secrets?
  2. Scenario 2 (Review): What does an engineer lose if an agent auto-fixes their code instead of pointing out issues?
  3. Scenario 3 (Learning): How does understanding architecture before touching code prevent bugs?
  4. The Big Picture: What fraction of your real work should stay in plan mode? (Not just for learning tasks, but ongoing.)

Write 4–5 sentences. Think deeply about when plan mode is not a stepping stone to build mode, but a destination.

Key Insight

Plan mode is not just a tool for exploring bugs. It's a way of working.

  • Code review? Plan mode.
  • Security audit? Plan mode.
  • Learning a codebase? Plan mode.
  • Mentoring? Plan mode.

Build mode is for shipping. Plan mode is for thinking.

The best engineers spend 60% of their time thinking (plan mode) and 40% shipping (build mode). Beginners often get it backward.

Next Week

Week 4: Custom Slash Commands. You'll write commands that you and your team use repeatedly, so you don't have to type the same prompts over and over.