When to use it
✅ Most everyday edits
Adding a feature, fixing a bug, restyling, refactoring. If you’re not sure which mode to use, start here.
✅ Multi-file changes
Edits that touch the schema and a page and a component. The agent traces dependencies for you.
✅ When you trust the prompt
Your prompt is clear and the change feels low-risk. Skip the Plan-mode review step.
❌ Schema migrations on production
Use Plan mode so you can review the migration before it runs.
How it works
A few things worth noting:- The agent reads your full project context before generating, not just snippets. It knows the schema, the auth model, your custom instructions, your design system.
- Type-check failures auto-retry up to three times. You only see the build that succeeded.
- Conflict-free for files you’ve manually edited. If you edited
components/Header.tsxby hand and the agent decides to change it, the agent will respect your edits as the new starting point.
Anatomy of a good agent-mode prompt
Three things make a prompt land cleanly:1
Be concrete about the user-facing behavior
“Add a settings page where users can change their display name and avatar” beats “Add a settings page”.
2
Mention scope
“Just for the logged-in user — admins shouldn’t see anyone else’s settings here.”
3
Reference existing things by name
“Add a column to the existing
Tasks table called notes (optional text)” beats “add a notes feature to tasks”.Switching agents per prompt
Agent mode runs against your default agent (set in workspace settings), but you can override per-prompt:Claude Code
The default. Strong reasoning across many files. Best general-purpose pick.
OpenAI Codex
Fast, surgical. Best on small, targeted changes (one file, one function).
Gemini CLI
Best for multi-file design work and schema modeling.
What you can ask for
- Add a feature
- Refactor
- Schema change
- Integration
- Performance fix
When the agent gets it wrong
The agent is good but not infallible. Common failure modes:It misinterpreted the prompt
It misinterpreted the prompt
Switch to Plan mode so you see the plan before code is written. Often the misread is visible in the plan and you can correct it in one reply.
It made the change but broke something else
It made the change but broke something else
Roll back via version history (one click). Then re-prompt with the additional constraint: “Same change, but don’t break the existing
<Header /> layout.”It picked an integration you didn't want
It picked an integration you didn't want
Be explicit. “Use Resend for email (not SendGrid)” or “Use the existing Convex storage for files (not S3).”
It generated working code but it doesn't match your style
It generated working code but it doesn't match your style
Add a custom instruction so this preference is global. Then re-prompt with “Refactor according to my custom instructions.” Easier than fighting it every time.
Tips
Related
Plan mode
Same flow, with a review step before code is written.
Code mode
Hand-edit when a prompt is overkill.
Iterating effectively
Patterns for making 50 small changes a day.
