Most developers already work in the terminal. You initialize projects there, run tests there, debug CI failures there. The friction in AI-assisted coding has always been the moment you have to leave the terminal, open a browser tab, copy a prompt, wait for a response, and paste the result back. GitHub Copilot CLI (a command-line interface, a program you run in a terminal) closes that loop. You describe intent in your shell, the agent proposes commands and edits, you approve, and the change lands in your branch. After about three months of daily use on a small team, here is what worked, what did not, and what I would tell past me.
What Copilot CLI is, and what it is not
Copilot CLI is a GitHub-aware coding agent that runs in your terminal. You install it with npm install -g @github/copilot, you authenticate with copilot auth login, and you start a session with copilot (interactive) or copilot -p "your prompt" (one-shot). It reads your repository context, your open issues, and your recent commits, and it uses that context to suggest concrete commands and file edits. You stay in control of what runs and what changes. The agent does not silently execute code. Every shell command and every file modification requires your explicit approval.
A few things it is not. It is not a replacement for design work. It is not a way to skip code review. It is not a system that ships to production on its own. It is a tool that takes intent (“add user authentication”, “refactor this module to use the new API”, “explain why this test is failing”) and turns it into a draft diff that a developer reviews and merges. The review is still on you. The merge is still on you. The on-call is still on you. Copilot CLI is a productivity multiplier, not an autopilot.
What surprised me is how well it fits the existing developer flow. Most of my work happens in a terminal window with three or four panes. I have Neovim for editing, htop for monitoring, and a shell for everything else. Adding Copilot CLI did not require me to learn a new tool surface. It shows up as a prompt in the shell I am already using, with the file context it already had, and it produces output I can pipe into my editor. The learning curve was about an hour, mostly spent on the right way to phrase intents so the agent proposes useful work.
The workflow I have landed on
For a small team of two to four developers, the workflow I have used most is this. Start every new feature with an intent, not a framework choice. The copilot interactive session opens, you type something like “Add a /api/orders endpoint that returns a paginated list of orders for the authenticated user, including the user’s name and the order total”, and the agent proposes a plan. You read the plan, you adjust the wording, you approve, and the agent starts writing.
Use the /plan mode before touching code. This is the single biggest productivity gain. /plan tells the agent to outline the changes in a numbered list before it edits any file. The plan shows up in the terminal, you read it, you push back on the parts that look wrong, and the agent revises. By the time the agent moves from plan to implementation, the high-level shape of the change is already aligned with what you actually wanted. This cuts the back-and-forth in half. It also produces a paper trail. The plan is logged, you can refer back to it in a code review, and the next developer who works in that file can see the reasoning.
Keep the change set small. Copilot CLI works best when the intent maps to a 50-200 line diff. Larger changes still work, but the agent’s proposals get noisier, and the review burden grows. The discipline of “small commit, one intent, clear review” is the same discipline the team needed before the agent existed. The agent just makes it easier to ship a clean small diff on the first try.
Approve in chunks, not all at once. The agent edits a file, shows you the diff, and asks for approval. You can approve one file at a time, or you can approve the whole batch. For a 50-line change I usually approve the whole batch. For a 300-line change I approve in chunks of 50-100 lines, which gives me a checkpoint to catch a wrong direction before it propagates.
Five small habits that compound into a smoother workflow:
- Start every session by reading the plan, not by reading the diff. The plan is the contract. The diff is the implementation. Reviewing the contract first catches design mistakes before they propagate into code.
- Name the intent with a verb, not a noun. “Add user authentication” produces a more useful plan than “user authentication.” The verb gives the agent a direction, the noun gives it a topic. The combination is the right shape.
- Reject the entire plan with a one-line reason. When the plan is wrong, the fastest move is “no, this should not touch the database schema, do it via the existing user table.” One sentence, the agent revises, and the next plan is closer.
- Run the test suite after the agent finishes. Copilot CLI does not run your tests by default. A 30-second test run is the difference between “the change looks right” and “the change works.”
- Commit the agent’s diff in a single commit with a clear message. Squash the small “wip” commits the agent sometimes generates, and write the commit message yourself. The commit is for the next developer, not for the agent.
Where Copilot CLI does not help
Three places where I have stopped using the tool. Greenfield architecture decisions. The agent is good at “given a clear spec, write the code that implements it.” It is bad at “given a vague business problem, design the system that solves it.” Architecture decisions need judgment about trade-offs, and the agent does not have the context to make them. For these, the team lead writes a design doc, the team reviews it, and Copilot CLI helps with the implementation.
Production debugging under time pressure. When the prod system is down and I am reading logs at 2 AM, I want a tool that is fast, predictable, and that I have used a thousand times. Copilot CLI is a tool I have used a hundred times. For prod-debugging I am still in raw grep and kubectl logs mode. The agent is great for “explain why this is failing in a test environment where I have time to read the explanation.” It is not great for “tell me the answer in the next 30 seconds or I am paging the on-call.”
Code that touches money, identity, or cryptography. The agent is not bad at these domains, but the failure modes are catastrophic. A wrong suggestion in a payments flow is a wire transfer to the wrong account. A wrong suggestion in a crypto flow is a key leak. For these, the team writes the code by hand, the team reviews it carefully, and Copilot CLI is not in the loop. The productivity gain is not worth the risk surface.
The honest part about the productivity claim
Marketing materials for AI coding tools talk about ten-times or thirty-times productivity gains. Those numbers are not real. The honest number I have observed is more like 30% to 50% faster on the categories of work the tool is good at, and zero improvement on the categories it is bad at. Net productivity is closer to 15% to 25%, weighted by how the team spends its time. That is still meaningful, but it is not a revolution. It is a steady, incremental improvement, like moving from a 4-core to an 8-core machine.
Where I have seen the bigger gains is in onboarding. A new developer on the team can be productive in a week with Copilot CLI, where the previous ramp-up was three to four weeks. The agent acts as a senior developer who is always available to explain the codebase, suggest patterns, and review diffs. For a small team that is hiring, the ramp-up gain is more material than the per-developer productivity gain.
Trade-offs
Copilot CLI is not free in dollars. The Individual plan is $10 per month, the Business plan is $19 per user per month, and the Enterprise plan is $39. For a four-person team on the Business plan, the annual cost is $912. That is not nothing. The cloud-hosting cost for a similar-sized Cursor or Windsurf deployment is in the same range, so the market has converged on this price point. The savings compared to a senior developer is enormous. The savings compared to a junior developer is more modest.
Copilot CLI is not free in trust. Every suggestion is a third-party model looking at your code. For most teams this is fine. For teams working on classified, regulated, or proprietary code, the data-handling question needs a real answer before the tool gets installed. GitHub has a clear data-handling policy, and the Business plan has the no-retention guarantee. The team should still read it.
The tool is a moving target. GitHub ships updates weekly. Features that exist today may behave differently in a month, and features I rely on may get deprecated. The team should expect to revisit workflows every quarter, not every year. This is a different maintenance pattern from a stable tool like git or vim, and the team should plan for it.
If your team writes code in a terminal, ships small diffs, and does not touch regulated data, Copilot CLI is worth the $19 per month per developer. If your team is on a regulated codebase, or if your work is dominated by architecture decisions and prod debugging, the tool is not going to be worth the cost.
What I would tell past me
If I could send a message back to the version of me that installed Copilot CLI for the first time, I would say three things.
- Always use
/planmode before the agent writes code. The plan is a forcing function. It makes the agent’s reasoning explicit, and it makes your review possible. Skipping the plan mode is the difference between “this change took an hour and shipped clean” and “this change took three hours and had to be rewritten.” - Keep the change set small. A 50-line diff reviewed and merged in 15 minutes is better than a 300-line diff that needs two rounds of code review. The agent makes it tempting to write larger diffs because it can produce them in a few minutes. The review burden is the same, and the merge risk is higher.
- The productivity gain is real, but it is not a revolution. Treat the tool as a 20% productivity improvement on work it is good at, and zero on work it is bad at. Budget accordingly, and do not reorganize the team around the tool.
If you only do one thing from this article, install Copilot CLI and use /plan mode on your next code change. The 20 minutes you spend on the first try is enough to know whether the tool fits your workflow.