# Training Copilot on Your Codebase
Copilot doesn’t actually learn from your private code—but you can make it act like it does. Here’s how to get better suggestions by feeding it the right context.
## The Misconception
You can’t “train” Copilot in the traditional sense. GitHub Copilot is a cloud model trained on public code, and you can’t upload your private codebase for fine-tuning. What you *can* do is feed it context so it understands your patterns, conventions, and codebase structure.
I’ve tested this extensively. The difference between generic suggestions and context-aware ones is night and day. Here’s what actually works.
## Custom Instructions: Your First Lever
VS Code lets you add custom instructions that Copilot reads before generating code. Create a `.github/copilot-instructions.md` file in your repository root.
“`markdown
# Custom instructions for this codebase
## Code style
– Use TypeScript strict mode
– Prefer functional components in React
– Use 2-space indentation
## Naming conventions
– Components: PascalCase (e.g., UserProfile)
– Hooks: camelCase with “use” prefix (e.g., useAuth)
– Utilities: camelCase (e.g., formatDate)
## Patterns
– Always use error boundaries around async operations
– Export types before implementations
– Use early returns to reduce nesting
“`
Copilot reads this file automatically. It won’t memorize everything, but it’ll follow these guidelines when generating new code.
## The @workspace Command
In VS Code with Copilot Chat, you can reference your entire workspace:
“`
@workspace How do I add a new API endpoint to the user service?
“`
Copilot scans your codebase and returns suggestions based on your actual files. This works because it indexes your project locally—not uploading it to GitHub, just making it available to the extension.
For better results, be specific:
“`
@workspace /src/users/ Look at the existing user controller patterns and suggest how to add a password reset endpoint
“`
The more specific you are about which files to reference, the better the output.
## File References in Prompts
When writing code with Copilot, open relevant files first. Copilot sees your active editor tabs as context:
“`typescript
// Open userService.ts first, then ask Copilot to add a method
// Copilot will match your existing patterns automatically
“`
This is simpler than it sounds—Copilot picks up on:
– Your function signatures
– Return types
– Import patterns
– Error handling style
If you’re working on a new feature, open 2-3 similar files first. Copilot will mirror the patterns.
## Using GitHub Copilot Enterprise (If Available)
If your team has Copilot Enterprise, you get additional features:
– **Knowledge base**: Connect internal documentation that Copilot can reference
– **Repository-wide context**: Better understanding across multiple repos
– **Organization-level custom instructions**: Set conventions for your whole team
The knowledge base feature is the closest to “training” you’ll get. You upload markdown docs, architecture decision records (ADRs), and API specs. Copilot Chat then references this when answering questions.
“`bash
# Enterprise setup requires admin access
# 1. Go to github.com/settings/copilot
# 2. Enable Copilot Enterprise
# 3. Add knowledge sources via the admin dashboard
“`
Not every team has access to Enterprise. If you’re on the individual plan, the custom instructions approach works fine.
## What Doesn’t Work
I’ve seen claims about “training” Copilot by writing specific code patterns repeatedly. That’s not how it works. Copilot doesn’t learn from your usage to improve future suggestions—that’s not the architecture.
Also avoid:
– **Putting secrets in copilot-instructions.md** — it’s not secure
– **Expecting it to read your entire repo** — it only sees open files and workspace context
– **Relying on outdated context** — if you refactor, update your instructions file
The model doesn’t actually “remember” your codebase between sessions. Each conversation starts fresh. That’s why explicit context matters.
## Making It Stick
Here’s what produces consistent results:
1. **Keep custom instructions updated** — Review quarterly, update when you change patterns
2. **Open relevant files before prompting** — Don’t start a new tab and expect context
3. **Use specific file paths** — `@workspace /src/auth/` beats “the auth code”
4. **Chain your prompts** — “First explain the pattern, then write the code” works better than dumping everything in one prompt
“`typescript
// Example chain:
// 1. Open existing service file
// 2. Ask: “@workspace /src/users/ what patterns do you see for error handling?”
// 3. Then ask: “Add a new method following those patterns”
“`
This approach consistently gets you 80%+ relevant suggestions. Without it, you’re essentially using a stranger’s code generator.
—
## Key Takeaways
– You can’t actually train Copilot on private code—feed it context instead
– Create `.github/copilot-instructions.md` for persistent style guidelines
– Reference specific files and directories in prompts for better results
– Copilot Enterprise offers knowledge bases for team-wide context
– Open relevant files before prompting; context doesn’t persist across sessions
## Next Steps
1. Create your `copilot-instructions.md` file this week
2. Test it by generating code in a new file—compare before/after
3. If your team uses Copilot Enterprise, set up a knowledge base with your internal docs
4. Make a habit of opening relevant files before asking Copilot for help
The difference between “generic AI code” and “actually useful suggestions” is almost entirely about context. Put in the minimal setup work, and Copilot stops feeling like a random generator.
