Three ways to drive Copilot Chat

Copilot Chat in VS Code hides a small dropdown near the bottom of the window that most developers barely notice. It switches between three distinct modes—ask, edit, and agent—each with its own level of autonomy and control. Choosing the right one depends less on experience level and more on the kind of task you're tackling.

Ask mode: Questions without side effects

Ask mode is the most straightforward. You select code, type a question, and get an answer. It explains what a snippet does, suggests test strategies, offers alternative implementations, or clarifies an edge case without ever modifying your files.

Ask mode works on general programming questions, too. How to use a library, structure a SQL query, or compare search algorithms for a given dataset—all fair game. The responses draw on your current editor context, but there is no project commitment or architectural decision implied. It's frictionless: a fast gut check before you commit to a direction.

Edit mode: Collaboration with a review step

Edit mode performs code changes across one or more selected files based on a natural-language instruction—something like "add error handling" or "refactor this using async/await." The critical detail is that Copilot applies inline edits as review-ready diffs and does not commit anything without your approval. You stay in control of exactly what changes.

Edit mode suits brownfield work and targeted improvements. It won't rename unrelated symbols or redesign your architecture; it addresses only the code you specified, with the final say still yours. Custom instructions can further shape results by defining team style, verbosity, comment language, or naming preferences—so when you say "clean this up," Copilot knows what clean means to your project.

Agent mode: Autonomous execution with guardrails

Agent mode accepts a high-level prompt and then plans steps, selects files, runs terminal commands, and iterates on edits until the task is done. It reasons across the whole project, holds substantial session context, and handles features, bug fixes, file creation, or scaffolding from a single request.

The difference from edit mode is significant. Instead of limiting itself to lines you explicitly select, agent mode identifies related code and applies changes across the project for consistency. Edits happen automatically rather than waiting for approval. Potentially risky commands are still surfaced for review before execution, but the overall workflow follows a continuous-edit model: the developer defines the goal and Copilot drives execution.

For many developers, that shift feels like pairing with a brilliant but fast-moving partner. The key to keeping that partnership productive is custom instructions. Because the context window, while large, is finite, pre-defined rules on API conventions, naming patterns, and stylistic preferences prevent drift across a long session—say, when Copilot builds a frontend that should match a backend structure it designed earlier.

An example from one project shows how such rules can be captured:

This is a Next.js-based travel application with TypeScript that helps users search for trips, manage bookings, view travel guides, and track points. The application uses React components, server components, and client components as part of the Next.js App Router architecture. Please follow these guidelines when contributing:

## Code Standards

### Required Before Each Commit
- Run `npm run lint` to ensure code follows project standards
- Make sure all components follow Next.js App Router patterns
- Client components should be marked with 'use client' when they use browser APIs or React hooks
- When adding new functionality, make sure you update the README
- Make sure that the repository structure documentation is correct and accurate in the Copilot Instructions file
- Ensure all tests pass by running `npm run test` in the terminal

### TypeScript and React Patterns
- Use TypeScript interfaces/types for all props and data structures
- Follow React best practices (hooks, functional components)
- Use proper state management techniques
- Components should be modular and follow single-responsibility principle

### Styling
- You must prioritize using Tailwind CSS classes as much as possible. If needed, you may define custom Tailwind Classes / Styles. Creating custom CSS should be the last approach.

## Development Flow
- Install dependencies: `npm install`
- Development server: `npm run dev`
- Build: `npm run build`
- Test: `npm run test`
- Lint: `npm run lint`

## Repository Structure
- `app/`: Next.js App Router pages and layouts organized by route
- `components/`: Reusable React components
  - `components/ui/`: UI components (buttons, inputs, etc.)
  - `components/__tests__/`: Component tests
- `lib/`: Core logic and services
  - `lib/data/`: Data models and mock data
  - `lib/types/`: TypeScript type definitions
- `public/`: Static assets
- `tests/`: Test files and test utilities
- `README.md`: Project documentation

## Key Guidelines
1. Make sure to evaluate the components you're creating, and whether they need 'use client'
2. Images should contain meaningful alt text unless they are purely for decoration. If they are for decoration only, a null (empty) alt text should be provided (alt="") so that the images are ignored by the screen reader.
3. Follow Next.js best practices for data fetching, routing, and rendering
4. Use proper error handling and loading states
5. Optimize components and pages for performance

Results are strongest when the initial prompt and setup file are thoughtful. Dropping a README into a new repo with a clear vision lets agent mode take a first pass at components, layouts, routes, and content. It won't be perfect immediately—it shouldn't be—but it gets closer to a usable starting point than a blank directory. Still, you need to stay engaged. Agent mode may occasionally run an unexpected command, touch a file you intended to leave alone, or take longer to reason through a larger codebase.

Matching the tool to the task

Power does not automatically mean the right choice. Sensitive, precision-dependent changes to a few files in a live system are better suited to edit mode, where every shift is visible in a diff. Large, exploratory, or cross-cutting work—scaffolding new structure or building a feature across multiple areas—is a stronger candidate for agent mode. For quick factual questions, ask mode is often all you need.

Surprisingly, experienced developers are often the ones who benefit most from agent mode. It works best when the operator can articulate clear constraints, knows the fragile edges of the codebase, and can judge when to review a change versus trust the flow. That judgment is not beginner territory.

Strong instruction clarity does more than speed up agent mode. When senior engineers codify the conventions they know implicitly—naming patterns, design principles, areas to handle with care—and version them with the project, the whole team gets consistent output and fewer course corrections. Without that explicit rule set, agent mode will not automatically inherit your team's preferences.

There will still be tasks where edit mode is the better fit, and that's expected. The modes are not competing implementations of the same idea. Ask mode answers, edit mode proposes, and agent mode acts. Trying each one where it fits—agent mode on a new repository, edit mode on a long-delayed refactor, ask mode on a Monday morning slice reducer syntax question—is the fastest way to find out which belongs where in your routine.

Regardless of mode, review each change as it lands. The tool may be autonomous, but the responsibility is not.