You stage a 300-line diff, the commit box opens, and the cursor just blinks. You know exactly what you changed. You just don't want to write the sentence. That small friction is the seam GitHub has been quietly filling with two very different tools: one that writes your commit message, and one that reviews your pull request. They arrived on the same "AI in git" wave, but after living with both on real work, I've landed on nearly opposite verdicts. One I let run on near-autopilot. The other I refuse to make a gate.
The commit generator earns its keep
In VS Code, Visual Studio, JetBrains, and on github.com itself, there's now a sparkle button next to the commit message field. Under the hood it's deliberately unfancy: a "simple-prompt flow" that sends your staged diff to the Copilot API, using the generic large language model with no additional trained model behind it. The clever part is the default behavior — it reads your recent git history and matches its style. If your log is all Conventional Commits, you get Conventional Commits. If it's terse one-liners, it stays terse.
Where it shines is the what. It's genuinely good at summarizing which files moved and what the mechanical change was. Where it falls down is the why. It can't see your ticket, your incident channel, or the bug you were actually chasing, so it will confidently produce "Update retry logic" when the message that matters is "Fix retry storm that took down checkout." It can also hallucinate — GitHub says so plainly in its own responsible-use guidance, and the quality of the suggestion is only as good as the context in the diff.
The fix is to stop accepting the defaults and hand it your house rules:
{
"github.copilot.chat.commitMessageGeneration.instructions": [
{ "text": "Use Conventional Commits: type(scope): summary" },
{ "text": "Imperative mood, subject under 50 characters" },
{ "text": "Explain the why in the body, not just the what" }
]
}
Put that in .vscode/settings.json and it becomes a team norm instead of a personal preference. My working rule: let it draft, always skim, and rewrite the body whenever the change has a reason a diff can't show on its own. That's a few seconds of editing against a few minutes of staring.
Code review is a second opinion, not a checkpoint
Copilot code review reached general availability in April 2025, after more than a million developers ran it in preview. There are two ways to invoke it: assign Copilot as a reviewer on a specific pull request, or configure automatic review at the individual, repository, or organization level so every opened PR gets a pass. It reads the diff and leaves inline comments — bugs, possible vulnerabilities, style inconsistencies — sometimes with a one-click suggested change you can commit.
Knowing its blind spots matters as much as its coverage. It skips dependency and lock files, log files, and SVGs, and GitHub is blunt that Copilot "is not guaranteed to spot all problems or issues in a pull request." It has been reaching further into big diffs, though — a July 2025 update lifted earlier file limits, which counts because roughly 30% of pull requests on GitHub touch more than 20 files.
Now the honest part: the signal-to-noise here is not the commit generator's. GitHub's own responsible-use page lists missed problems, false positives, plausible-but-wrong suggested code, and training-data bias as known issues. In practice a share of the comments will be irrelevant or subtly off, and the failure mode is quiet. A reviewer that cries wolf trains a team to rubber-stamp "no issues found" and skim past the one comment that actually mattered. A confidently bad suggested fix is worse than none — code that compiles, reads correctly, and slips a bug in behind it.
Always validate Copilot's feedback carefully. Supplement Copilot's feedback with a human review.
That line is GitHub's, and it's the right altitude. My rule follows from it: never make Copilot a required check. Keep it as an advisory reviewer that clears the boring stuff — a missing null guard, a leftover debug log, an off-by-one — before a person spends real attention. The human stays the merge gate.
Review takes instructions too, and this is where teams leave the most on the table. A .github/copilot-instructions.md sets repository-wide expectations; path-specific files under .github/instructions/ scope rules to parts of the tree; an AGENTS.md carries conventions across tools. Tell it "we dispose via IAsyncDisposable, flag synchronous disposal," and it stops nagging about your intentional patterns and starts catching genuine deviations from them.
The through-line: context is the whole game
Look at the pattern across both tools. The commit generator improves when it reads your git history and your instructions block. The reviewer improves when it reads your copilot-instructions.md. Out of the box, each one operates on a naked diff and produces generic output — which is precisely why so many people try them once, get bland results, and write the entire category off. The diff is what changed. The context is what you meant. An AI can infer the first almost perfectly and the second not at all, unless you've written it down somewhere it can read.
So here's the concrete move for this week, not a summary. First, add a commitMessageGeneration.instructions block to your repo's .vscode/settings.json and a short .github/copilot-instructions.md holding the three or four conventions you already repeat in review — you're just teaching the machine the notes you keep giving humans. Second, switch on automatic Copilot review as advisory, never a required status check. Let the tools draft your prose and catch your careless mistakes, and keep the two decisions that matter — the why behind a commit and the yes behind a merge — firmly in human hands.
Sources: Responsible use of GitHub Copilot commit message generation, About GitHub Copilot code review, Copilot code review: better handling of large pull requests (GitHub Changelog, July 2025)