Skip to content

Week 3 Reflection: Plan Before You Build

Goal: Turn Week 3 into a personal rule for when to explore, when to execute, and when to stay read-only.

Time: 20–30 minutes.

This reflection is not a quiz. It is a checkpoint for your judgment. By now, you have used plan mode to investigate before editing and practiced at least one task that should stay in plan mode.

What to Submit

Write a short reflection in your own words. Aim for 300–500 words total.

Use these headings:

  1. What I Learned About Plan Mode
  2. What I Learned About Build Mode
  3. One Time I Should Stay in Plan Mode
  4. My Rule for Switching to Build

You can write this in a local notes file, a course journal, or the place your instructor asks you to submit work.

Prompt 1: What Did Plan Mode Change?

Answer these questions:

  • What did the plan agent find that you might have missed if you went straight to build?
  • Did plan mode make you slower or faster overall? Explain why.
  • What kind of follow-up question helped the most?

Use a concrete example from Lab 3.1 or Lab 3.2. Avoid vague answers like "it helped me understand the code." Say what you understood.

Good example:

Plan mode showed me that the crash was not only in lib/db.js. The real problem was that one route could call the database function without a valid user. If I had started in build mode, I probably would have added a guard in one file and missed the route-level issue.

Prompt 2: What Makes Build Mode Risky?

Build mode is not bad. It is powerful. The risk is using it before you know what you want changed.

Answer these questions:

  • What is one edit you would deny if the agent proposed it?
  • What should you check before approving a file edit?
  • What should you ask the agent to do before committing?

Beginner-safe warning: Do not approve edits just because the agent sounds confident. Approve because the edit matches the plan, touches the expected file, and you understand the reason.

Prompt 3: When Should Work Stay in Plan Mode?

Choose one task type from this week:

  • Security audit
  • Code review
  • Unfamiliar codebase exploration
  • Mentoring or teaching someone else
  • Performance investigation

Explain why the task should stay in plan mode.

Use this sentence starter if it helps:

This should stay in plan mode because the output I need is a report or explanation, not automatic edits.

Then add the specific reason. For example, security work may require rotating secrets, code review may require a human conversation, and architecture exploration may require learning before changing.

Prompt 4: Your Switching Rule

Write your own rule for when you are allowed to switch from plan to build.

Your rule should include at least three checks:

  • You know the root cause or purpose of the change.
  • You have a short plan with file names.
  • You can explain why each step is needed.
  • You know how you will verify the work.
  • You are ready to deny edits that do not match the plan.

Example:

I switch to build only after the agent has named the root cause, listed the files it will edit, and told me how it will test the fix. If the plan uses vague words like "improve" or "clean up," I stay in plan mode.

Success Criteria

You are done when your reflection:

  • Names at least one specific file, bug, or scenario from the labs.
  • Explains the difference between plan and build in your own words.
  • Gives one example of a task that should stay in plan mode.
  • Includes a personal rule for switching to build mode.
  • Mentions one approval habit you will use before accepting edits.

Troubleshooting

Q: I do not remember what happened in the lab. A: Reopen your terminal history or OpenCode conversation if available. If you cannot recover it, rerun a small part of Lab 3.1 and take notes this time.

Q: My answer sounds too obvious. A: Add specifics. Name the file, command, prompt, or approval you saw. Specific beats polished.

Q: I still feel unsure when to switch to build. A: Use this default rule: stay in plan mode until you have a 3–5 step plan and know how to verify the result.

Q: The agent never made a mistake for me. What should I write? A: Write about what could have gone wrong. The point is judgment, not catching the agent failing.

Takeaway

The habit is simple: think in plan mode, ship in build mode.

If you leave Week 3 with only one new instinct, make it this: when the task is unclear, expensive, risky, or educational, do not start by editing. Start by understanding.