GitHub Copilot's Technical Preview: Read the FAQ Before You Hit Tab

Last Tuesday GitHub announced a technical preview of GitHub Copilot, which it calls an AI pair programmer. The demos are genuinely impressive: you write a comment or a function signature and whole function bodies appear in grey, ready to accept. It’s also the first time a lot of us will have a tool that ships chunks of our editor buffer to someone else’s model as we type, so the fine print matters. GitHub has published a fair amount of it, and most of it is pretty candid.

What GitHub says it is

Copilot was developed with OpenAI and runs on OpenAI Codex, a new system from OpenAI. GitHub says Codex is significantly more capable than GPT-3 at generating code, partly because its training data has a much larger concentration of public source code. GitHub’s announcement says it works with a broad range of languages and frameworks, but that the preview does especially well with Python, JavaScript, TypeScript, Ruby, and Go. The pitch is whole lines or entire functions, alternative approaches, tests, and help with new APIs without leaving the editor.

The Copilot site’s FAQ is where the details live. It says Codex was trained on a selection of English text and publicly available source code, including code in public GitHub repositories. It also gives a benchmark: GitHub took Python functions from open source repos with good test coverage, blanked out the bodies, and asked Copilot to fill them in. It got them right 43% of the time on the first try and 57% of the time when allowed 10 attempts. That’s remarkable for a code generator, and sobering if you planned to accept suggestions unread: on the vendor’s own benchmark, the first answer is wrong more often than it’s right.

Access is through a waitlist. The FAQ says the preview is free for a limited number of testers, and that a commercial version is planned if it goes well.

How it works in VS Code

For now Copilot is only a Visual Studio Code extension, and the FAQ says flatly that other editors aren’t supported yet. It works anywhere VS Code runs, including GitHub Codespaces. If you install the extension without being admitted to the preview, the Marketplace listing warns that you’ll just get an error.

The extension sends your comments and code to the Copilot service, which uses Codex to produce suggestions that show up inline as you type. The Copilot site’s demo shows Tab to accept, and Option with the bracket keys to step forward and back through alternative suggestions. You can also edit whatever it gives you, which is the part I’d lean on hardest.

The FAQ is specific about context. Copilot uses the current file only and doesn’t yet look at other files in your project, so pasting a type declaration into the file you’re editing can improve the results. It also says long files get clipped: if a file runs past a few hundred lines, only the code right before your cursor is used. It recommends small functions, meaningful names, and good docstrings and comments, which is good advice anyway.

Does it copy code from its training set?

The FAQ describes Copilot as “a code synthesizer, not a search engine” and says most suggestions are newly generated, but that roughly 0.1% of the time a suggestion may contain snippets taken verbatim from the training set.

The detail behind that number is in a research write up on recitation by Albert Ziegler at GitHub. During internal testing, nearly 300 employees used Copilot, and he looked at 453,780 Python suggestions from that trial. He filtered for suggestions that overlapped training code by at least 60 “words” (in his counting, punctuation and brackets are words and whitespace is ignored), which left 473 cases. After removing duplicates and cases that weren’t really recitation, 41 remained, which he works out to about one recitation event every 10 user weeks.

None of them appeared in fewer than 10 files in the training data, and most showed up more than a hundred times. Recitation happened mostly when Copilot had little specific context, like an empty file, or when the problem was so generic that one well known solution dominates. In one case it suggested starting an empty file with the GNU General Public License text, which it had seen more than 700,000 times. GitHub says it is building an origin tracker so that when a suggestion matches training code, the editor can show you where it came from and you can add attribution or skip it. That doesn’t exist yet in the preview.

Licensing, as GitHub frames it

GitHub’s position in the FAQ has two halves. On training, it says training models on publicly available data is considered fair use across the machine learning community, while also acknowledging this is a new area and saying it wants to talk with developers about appropriate standards. On output, it says Copilot is a tool like a compiler, that the suggestions and the code you write with them belong to you, and that you are responsible for that code. You don’t need to credit Copilot.

That is GitHub’s framing, not a court ruling, and ownership and responsibility arrive in the same sentence for a reason. If a suggestion is a recognizable chunk of someone else’s licensed code, the responsibility for shipping it lands on you. Until the origin tracker exists, the practical move is to be extra suspicious of long, polished suggestions in a nearly empty file, or of anything that looks like it came from a well known project, and to search for a distinctive line before committing it to a codebase with licensing obligations.

Security of suggested code

The FAQ doesn’t sugarcoat this either. There’s a lot of public code with insecure patterns, bugs, and outdated APIs, and Copilot can synthesize suggestions with the same problems. GitHub says it will work to exclude insecure or low quality code from the training data over time, and in the meantime tells you to use Copilot alongside testing, security tools, and your own judgment. Elsewhere it notes that Copilot doesn’t test what it suggests, so the code may not even compile, and that it may suggest deprecated library usage.

There’s a personal data section too. The FAQ says verbatim personal data from training was extremely rare in internal testing, but that the model can sometimes produce things that look like emails, phone numbers, or access keys and are actually made up from patterns in the training data. The preview has a basic filter for emails in standard formats, and GitHub admits you can get around it if you try.

My take: treat every suggestion like a pull request from a confident stranger who’s read a lot of Stack Overflow. SQL built by string concatenation, disabled certificate verification, weak hashing, overly broad regular expressions, and hardcoded credentials are all common in public code, so expect to see them. Keep linters and static analysis in the loop, read generated tests as carefully as the code, and never accept anything that looks like a key or token.

What gets sent, and who can see it

To make suggestions, Copilot sends part of the file you’re editing to the service, and it records whether you accept or reject suggestions to improve future versions. The FAQ says GitHub doesn’t use your private code to generate suggestions for other users, and that users will get an option to control how their telemetry is used in the future.

The docs go further. About GitHub Copilot telemetry lists the metadata (pseudonymized VS Code machine and session IDs, VS Code and extension versions, OS, and city level location derived from your IP) and the events it records, such as requests for suggestions including cursor position and code snippets, the suggestions shown, whether you accept or reject them, and whether the accepted code persists afterward. Access is limited to named GitHub staff on the Copilot and platform health teams, select Microsoft personnel, and select OpenAI employees who work on Copilot.

The telemetry terms are the part I’d read twice. Accepting that telemetry is a condition of joining the waitlist. Snippets of files you edit are shared with GitHub and OpenAI, and the terms say Copilot relies on file content from the file you’re editing and potentially other files in the same VS Code workspace, which is broader than the FAQ’s current file description. To revoke that consent, the terms say you contact GitHub and ask to be removed from the preview.

Using it responsibly

If you get in, here’s how I’d approach it. Keep it on personal projects and open source first, and don’t point it at an employer’s code unless your employer has actually agreed to snippets going to GitHub and OpenAI. Keep secrets out of files you open in the editor where you can, and for repos that hold .env files, customer data, or anything under NDA, disable the extension for just that workspace from the gear menu in VS Code’s Extensions view. Read every suggestion as if you wrote it, because GitHub’s own FAQ says that’s the deal. Be most skeptical at the top of empty files, where GitHub’s study found recitation mostly happens.

Copilot looks likely to change how a lot of routine code gets written, and GitHub deserves credit for publishing recitation numbers and telemetry details up front. The code is still yours, though, including the bugs, the vulnerabilities, and any license you didn’t notice. Tab is easy to press, so read first.