When GitHub Copilot first launched, it felt like a very clever autocomplete — one that could finish your function after reading a comment. That was already useful enough. But over the past year, Copilot has quietly grown into something much more interesting: an AI that can take on entire tasks end-to-end, leave review comments on your PRs like a senior teammate, and even follow you away from your desk via the GitHub mobile app.
If your mental model of Copilot is still "it fills in my code as I type", this post is for you. Let me walk through the three changes that have made Copilot genuinely indispensable in my day-to-day workflow.
🤖 Copilot Agents: Let It Do the Whole Thing
Agent mode is the headline feature of modern Copilot. Instead of suggesting the next line, you give Copilot a goal — "add input validation to the registration form and write tests for it" — and it figures out the steps on its own: reading the relevant files, making the changes, running tests, and fixing failures until everything is green.
What makes this feel different from just pasting code into Chat is that Copilot operates on your actual workspace. It reads the files it needs, edits them, runs your terminal commands, and iterates. It's the difference between asking someone for advice and handing them the keyboard.
Agent mode is available today in VS Code (as "Copilot Edits" and the experimental agent panel), JetBrains IDEs, and increasingly through GitHub itself for Copilot Workspace. The sweet spot for agents right now:
- 🧪 Writing test suites: Give it a module and ask for full coverage — it reads the code, writes tests, runs them, and fixes failures.
- ♻️ Refactoring: Rename a concept across the whole codebase, migrate to a new API, or split a large file — without touching every file yourself.
- 🐛 Bug fixing: Paste a failing test or error log. Copilot traces the cause, makes a fix, and confirms the test passes.
- 📄 Boilerplate generation: Scaffold a new feature end-to-end: component, service, types, and tests — all consistent with your existing patterns.
One thing I've learned: be specific about the outcome you want, not the steps. "Add form validation" is fine; "use Zod, keep existing field names, and make sure error messages are inline" is much better. The more constraints you give it, the less back-and-forth you need.
🔍 Copilot on Pull Requests: Your Always-Available Reviewer
One of the most underrated Copilot features is its ability to review pull requests. Once enabled for a repository, Copilot automatically reviews every PR and posts inline comments — the same way a human reviewer would — pointing out potential bugs, suggesting improvements, and flagging anything that looks off.
The comments appear in the standard GitHub PR review interface. You can respond to them, apply the suggested one-line fixes directly from the diff view, or dismiss them just like any other review comment. There's no separate workflow to learn.
Beyond line-level review comments, Copilot also generates a plain-language PR summary at the top — a quick paragraph explaining what changed and why — which is handy when you're reviewing someone else's work and want context before you dive into the diff.
What Copilot PR reviews catch well:
- Edge cases the author missed (empty arrays, null values, boundary conditions)
- Inconsistency with patterns used elsewhere in the codebase
- Security concerns in input handling or data access
- Missing error handling or inadequate logging
- Opportunities to simplify logic or remove duplication
It is not a replacement for human review — it occasionally flags things that are intentional, and it won't catch issues that require deep domain knowledge. But as a first pass that runs before anyone else even looks at the PR, it catches a surprising amount. On my team, the number of review rounds before merge dropped noticeably after we enabled it.
📱 Copilot on Mobile: Code Review in Your Pocket
This one surprised me more than I expected. GitHub's mobile app (iOS and Android) now has Copilot Chat built right in. That means you can pull up a PR on your phone during your commute and ask Copilot to summarise the changes, explain a confusing diff, or tell you if there are any concerns — all in plain English, without needing to mentally parse the raw diff on a small screen.
You can chat with Copilot about the specific PR you're looking at, ask it general questions about the repository, or even explore files. It's the same model as the desktop, just in a conversational format that works well on a phone.
In practice, I use it mostly for three things away from my desk:
- Quick PR triage — checking if a PR is ready to review or still needs work, without opening a laptop
- Async code questions — asking about a piece of code someone mentioned in a message, so I can respond with something useful
- Catching up after meetings — getting a plain-English summary of what changed while I was in calls
To enable it: update the GitHub app on iOS or Android, navigate to any repository or pull request, and look for the Copilot icon in the toolbar. Sign in with your GitHub account that has Copilot enabled and you're ready.
💡 Tips That Actually Help
Be specific about constraints, not just goals
"Add error handling" gives Copilot too much freedom. "Add error handling using our existing AppError class, log with the existing logger, and return a 422 for validation errors" gives it exactly what it needs.
Ask agents to explain what they did
After an agent finishes a task, follow up with "explain the changes you made". It forces you to actually review the output and often surfaces decisions that need your input.
Treat PR review comments as a starting point
Copilot's review comments are suggestions, not verdicts. Use them to catch things you might have missed, but dismiss anything that doesn't apply to your context. Over time you get a feel for which categories of comment are reliable for your codebase.
Use mobile Copilot for async, not deep work
The mobile experience shines for quick questions and triage. For anything requiring actual editing or multi-turn investigation, wait until you're back at your desk with the full IDE experience.
Always review before merging
Agent-generated code is often surprisingly good, but it is not infallible. Read through changes before committing them, especially in security-sensitive areas. Copilot moves fast — your job is to make sure it moved in the right direction.
⚠️ Things Worth Knowing
- Agents can go sideways: Occasionally an agent will loop on a failing test or make a change that breaks something else. Set a time limit in your head — if it's been more than a few iterations without progress, take back the keyboard.
- PR reviews are noisy at first: When you first enable Copilot reviews on a large codebase, it will flag patterns that are actually fine for your project. Spend 20 minutes on the first few PRs dismissing and categorising — it gets much cleaner quickly.
- Mobile is read-heavy by design: The mobile Copilot is great for understanding and discussion, not for large-scale edits. Don't try to use it to write features on your phone — that's not the use case it was built for.
- Security always needs human eyes: For authentication flows, cryptography, or data access, don't rely solely on Copilot's review comment or agent output. These areas need careful human review regardless of what AI suggests.
🎯 Final Thoughts
The version of Copilot in 2025 is meaningfully different from the one that launched. Agents let you delegate whole tasks rather than individual lines. PR review integration means every pull request gets a first-pass review before any human looks at it. And mobile support means you can stay informed and answer questions about your codebase from anywhere.
None of these features replace the judgment, taste, or domain knowledge that good engineers bring — but they do eliminate a lot of the friction that gets in the way of shipping. If you haven't revisited Copilot recently, it's worth a fresh look.
Top comments (0)