What GitHub Copilot Agent Mode and How Do You Use It?

GitHub Copilot agent mode is a VS Code chat mode in which GitHub Copilot plans, creates files, runs commands, and writes code autonomously until the feature you described exists. The video walks through building a complete todo API this way, and the deciding factor is a written spec: without one, the agent guesses.

What GitHub Copilot Agent Mode in VS Code?

GitHub Copilot agent mode is the autonomous chat mode in VS Code where GitHub Copilot, GitHub's AI pair programmer, plans and executes work instead of only answering. In the other chat modes you ask for something and receive a response. In agent mode you describe what you want built, and the agent plans the work, creates folders and files, writes the code, and installs what it needs.

Autonomy comes with checkpoints. The agent asks for permissions before running commands or fetching web content, and you can pause it mid-task to add context. The transcript's standing advice is blunt: read everything the agent generates, because output you did not review can hurt the project. The chat also accumulates context from the whole conversation, so starting a new chat clears that conversational memory while the agent still understands your code, because it works inside your workspace.

Why a spec.md Comes Before Any Agent Build

A spec is a written specification of your project, and the video treats it as the difference between a controlled build and wasted tokens. Asking the agent to 'create a system like Rocketseat' makes it guess: it will start producing something, but you will burn context and tokens before anything actually works.

The recommended habit is to plan in a markdown file named spec.md inside the project. The video suggests two ways to produce it. If you do not know where to start, open ask or plan mode and ask GitHub Copilot to draft a spec from your idea, including the technologies you already know you will use. If you already know exactly what you want, write the spec yourself. Hand-writing it keeps control of route names, function shapes, and even the language of the generated app, which the agent otherwise decides for you.

In the demo, the planning path also produced an implementation plan with a 'start implementation' button that switched the session into agent mode automatically. The manual path skips that step entirely: write the spec, then tell the agent to read it.

Writing the Todo App Spec: Interface, API, and Rules

The example project is a todo app: the user adds, views, and removes tasks in the browser. The spec divides into three parts, which is a reusable shape for any small project.

• Interface. A single index.html page, responsive, with a text field for the task, an add button, and a task list with a remove button on each item.
• API backend. A GET /tasks route returning all tasks, a POST /tasks route creating a new task, and a DELETE /tasks/:id route removing a task by ID.
• Rules. The title cannot be empty, tasks are saved in memory, and each task has an id, a title, and a created timestamp recording when it was added.

Stating the stack in the spec matters. The video declares the frontend in HTML and the backend in Node.js, which requires installing Node.js from nodejs.org first. Knowing the technology you want and writing it down prevents the agent from choosing for you.

Preparing the Workspace So the Agent Understands the Stack

Context is not only text; it is also the project's own files. Before invoking the agent, the demo opens a VS Code terminal and runs npm init -y, which generates the package. that marks the folder as a Node.js project. Then it runs npm install express, adding Express, the Node.js web framework used for the routes and for serving the frontend.

With package. and node_modules in place, the workspace itself tells the agent the backend runs on Node with Express. The final prompt to the agent is then one sentence: read the spec.md and create the complete project, starting with the backend.

What the Agent Generated: A Working Express Backend

The agent read the spec, read package., proposed a server.js file, and asked permission to run node server in the terminal. The generated backend implements everything the spec asked for, and reviewing it route by route is where the validation lesson lives.

• GET /tasks returns the full task list as JSON from the in-memory array.
• POST /tasks reads the title from the request body and applies the spec's rule: if the title is missing or empty after trimming, it responds with HTTP status 400 saying the title cannot be empty. On success it returns status 201 with the created task.
• DELETE /tasks/:id converts the URL parameter from string to integer, because comparing a string with a number never matches, uses findIndex to locate the task, and returns a not-found error or removes it with splice and reports success.

The task model uses an incremental counter for IDs, applies .trim() to the title as the spec required, and stores created as new Date().toISOString(), giving a clear date string for every task. The spec's rules translated directly into code, which is the whole argument for writing them down.

The In-Memory Limit and When to Add a Real Database

Because the spec says tasks are saved in memory, the array in server.js is the database. Restarting the server loses every task. That is acceptable for a lesson but not for a product.

The transcript's recommendation is to ask the agent to add a database when you evolve the project, and to use ask or plan mode first to compare options such as MongoDB or PostgreSQL. That upgrade is deliberately left out of this lesson as a more advanced topic. The practical point stands: persistence is a spec decision, and if you want it, write it into the spec rather than hoping the agent chooses it.

Frequently Asked Questions

• What is the difference between ask mode and agent mode? In ask mode you request something and GitHub Copilot replies. In agent mode GitHub Copilot acts: it plans the work, creates files, asks for permission to run commands, and writes the code, while you supervise and can pause it to add context.
• Do I need a spec.md before using agent mode? It is strongly recommended. Without a spec the agent guesses routes, naming, and structure, consuming context and tokens on results you did not ask for. A short markdown file listing interface, API routes, and business rules makes the output match your intent.
• What does the demo's backend include? An Express server with GET /tasks, POST /tasks with empty-title validation returning status 400, DELETE /tasks/:id with string-to-integer parameter conversion, incremental task IDs, a trimmed title, and a created timestamp.
• Why do tasks disappear when the server restarts? The spec stores tasks in memory, so the array lives only while the Node process runs. To keep data, write persistence into the spec and have the agent add a database such as MongoDB or PostgreSQL.
• Can the agent write the spec for me? Yes. The video shows drafting a spec in ask or plan mode from a plain description of the app and the chosen technologies, then refining it before handing it to agent mode.

Turn Your Own Walkthroughs Into Written Guides

A structured spec turned a vague idea into a working backend in one session, and the same structure helps written tutorials: clear interface, clear API, clear rules. If your own explanations live inside YouTube videos, like this workflow demo, that knowledge deserves the same treatment.

With Skala Blog you paste a YouTube URL, get a transcription, and generate a structured article from it, so a video walkthrough becomes a written guide readers can search and follow at their own pace.

Source video