Getting started
You’ve just joined the Platform squad at a mid-size company, and two repositories landed in your lap on day one. One is orders-service — an order-management API your squad owns. The other is shared-lib, an internal library that orders-service and about a dozen other services all depend on. Both are brownfield: built by people who’ve since moved on, lightly documented, with conventions you’ll have to reverse-engineer. Your first real assignment — add an approval step for large orders — is going to make you touch both. But not yet.
This chapter is the first half-hour. The goal is narrow on purpose: get GitHub Copilot running inside VS Code, learn the two different ways it shows up, and use it to ship one small, reviewed change to orders-service — so that when the real work starts in the next chapter, the tool is already familiar and you’re spending your attention on the code, not the buttons.
The audience here is the engineer who already lives in VS Code — an extension or two, inline suggestions already humming in the gutter — and is eyeing the agent side of Copilot with reasonable suspicion. You don’t have to give up the editor you know. By the end of the half-hour Copilot is working inside that editor, and you’ve used it to fix a real bug in code you didn’t write.
The half-hour we’ll follow
Section titled “The half-hour we’ll follow”orders-service has a visible, low-stakes bug: the “recent orders” endpoint returns the list in the wrong order — oldest first, when the UI clearly expects newest first. It’s the perfect warm-up ticket: small, real, and verifiable against output you can read with your own eyes. We’ll go from a fresh install to that fix shipped, in three moves:
- Set it up — install Copilot in VS Code, sign in, and confirm it’s alive — Set up Copilot in VS Code
- Learn the two surfaces — ghost-text completions and the Chat view are different tools for different moments — Completions vs chat
- Ship the fix — hand the ordering bug to chat, review the diff, and commit it — Your first reviewed change
None of it is hard. The reason to do it as one continuous task — on a repo you’ve genuinely just inherited — is that the habit you pick up here is the one every later chapter leans on: read the diff before you accept it. Copilot will get faster and more autonomous as the course goes on, but the review never goes away. On code you didn’t write and don’t fully trust yet, that habit isn’t optional polish. It’s the whole game.