Inline suggestions are Copilot's original feature: ghost text that predicts the next line or function as you type, accepted with a single Tab press. It's fastest for code you could write yourself but would rather not type out — boilerplate, repetitive patterns, obvious test cases, config files that follow a template.
Copilot Chat lives in the sidebar and handles the questions inline suggestions can't: "why is this test failing," "explain what this function does," "refactor this to use async/await." It can see your open files and, depending on setup, search across the repo, which makes it useful for onboarding onto unfamiliar code as much as writing new code.
The two work best together rather than as alternatives. Use Chat to plan an approach or understand a confusing error, then drop into the file and let inline suggestions handle the actual typing once you know what you're building. Jumping straight to code without a plan is where Copilot suggestions start feeling more like noise than help.
Slash commands in Chat — things like explaining a selection, generating tests, or fixing a specific error — are easy to miss but save real time over typing out a full prompt each time. They also tend to produce more consistent, scoped answers than an open-ended question.
Copilot's suggestions are only as good as the context around them. Clear variable names, a docstring above a function, or comments describing intent all noticeably improve what autocomplete offers you next — it's reading your codebase the same way a new teammate would.
The realistic ceiling on productivity gains here isn't the tool, it's review habits. Accepting suggestions faster than you can verify them is how subtle bugs slip through. Treat every accepted suggestion the way you'd treat a teammate's pull request: quick to trust, but never unread.