Modes, Context & Prompting

Different AI tools use different names, but the workflow ideas are usually the same.

This page explains the most common modes you’ll see in tools like Cursor, Copilot, Claude Code, and similar assistants:

• Ask mode — explore, explain, and think out loud.
• Plan mode — design the change before touching code.
• Agent mode — execute the plan and make multi-step edits.
• Inline edit / autocomplete — make small changes directly in the file you already have open.

It also covers the small habits that make these modes much more useful: context, rules, tests, and review.

1. Ask mode

Ask mode is for questions, exploration, and understanding.

Use it when you want the assistant to:

• summarize a file or folder
• explain a concept in plain language
• compare two implementation options
• help you find where something lives in the codebase
• suggest likely causes for a bug

Typical prompt style:

Where is the todo completion flow implemented?
Please summarize the files involved and explain the current behavior.
Do not change any code yet.

Good uses for Ask mode

• You are new to the codebase.
• You need orientation before making a change.
• You want to inspect trade-offs before deciding.
• You want a quick second opinion.

What to avoid

• Asking it to “just fix everything” without a clear target.
• Skipping verification and trusting the summary blindly.
• Mixing exploration with implementation in one vague request.

2. Plan mode

Plan mode is for designing the work before code changes begin.

Use it when the task is bigger than a one-line edit, especially if it touches multiple files or needs careful sequencing.

What Plan mode should produce

• a short problem summary
• the files or subsystems likely to change
• a step-by-step implementation plan
• test cases or validation steps
• any open questions or risks

Typical prompt style:

We need to add a "mark todo completed" feature.

Please:
1. Propose a small implementation plan.
2. List the tests we should add.
3. Stop after the plan and do not edit files yet.

Good uses for Plan mode

• Multi-file features
• Refactors
• Bug fixes that need a regression test first
• Architecture decisions
• Anything where order matters

What to avoid

• Letting the assistant start coding before you agree with the plan.
• Keeping the plan open forever instead of deciding.
• Changing the goal mid-plan without restarting.

3. Agent mode

Agent mode is for doing the work.

In agent mode, the tool can usually:

• edit files
• create new files
• run tests or commands
• inspect failures
• iterate until the task is done

Use it when you already know what you want and you want help executing it safely.

Good uses for Agent mode

• Implementing a planned feature
• Fixing a failing test
• Updating several files consistently
• Refactoring a small area of the codebase
• Cleaning up a change after review

Best practice for Agent mode

1. Give it a clear goal.
2. Keep the scope narrow.
3. Ask for tests or validation.
4. Review the diff before merging.

What to avoid

• Handing over a huge, fuzzy task with no boundaries.
• Letting the agent wander into unrelated cleanup.
• Assuming “agent did it” means “it is correct.”

4. Inline edit and autocomplete

This is the smallest mode: make a local change where the code already is.

Use it for:

• renaming a variable
• completing a function body
• fixing a small branch or condition
• writing boilerplate
• making a tiny, obvious edit

Inline editing is fastest when the change is local and well understood.

Good uses

• One function
• One file
• One clearly bounded fix

What to avoid

• Large feature work
• Cross-file changes without a plan
• “Rewrite this whole area” requests in a tiny inline context

5. The other stuff that matters

Modes are useful, but the supporting habits matter just as much.

5.1 Context

The assistant works better when you give it the right context:

• reference the relevant folders or files
• include error messages and stack traces
• mention the desired behavior
• say what should not change

Examples of good context:

Context: @src @tests

Task: add a new endpoint to mark a todo completed.
Constraints:
- keep the current API shape
- preserve existing tests
- add new regression tests first

5.2 Instructions and rules

Project-level instructions help the assistant stay consistent:

• AGENTS.md
• .cursorrules
• copilot-instructions.md
• docs like workflows.md and twelve_golden_rules.md

If your repo has special conventions, put them in a file instead of retyping them every time.

5.3 Tests first

For non-trivial changes, tests are your best specification.

• write the failing test first when possible
• ask the assistant to stop after the test step
• use the failing test to guide the implementation

5.4 Verify the output

AI can be confident and wrong at the same time.

So always check:

• does the code compile?
• do tests pass?
• does the diff match the plan?
• did it invent anything that does not exist in the repo?

5.5 Model choice

Not every task needs the strongest model.

• use faster / cheaper models for simple edits
• use stronger reasoning models for design, debugging, or refactoring
• choose the mode first, then the model

6. A simple recommended workflow

For most coding tasks, this sequence works well:

1. Ask — understand the code and the problem.
2. Plan — decide the approach and tests.
3. Agent — implement the change.
4. Review — inspect the diff and run validation.

If the task is tiny, you can skip straight to inline edit.

If the task is unclear, spend more time in Ask mode first.