Cody, Sourcegraph's AI coding assistant, understands your entire codebase, not just the file you have open. Here's how to use Sourcegraph Cody for real full-stack work without the hype.
Sourcegraph Cody isn't another autocomplete tool. It's a context-aware assistant that reads your repository, indexes your services, and answers questions about your actual architecture. I've used it on a Node.js/Postgres monolith and a React/GraphQL frontend, and the difference between Cody and generic AI tools is night and day.
Why Sourcegraph Cody Matters (and When to Skip It)
Most AI coding tools treat your code like a stranger looking at a single file. Sourcegraph Cody treats it like a senior dev who has read your entire repo. It can trace a bug from a React component through an API route down to a SQL query. That's genuinely powerful.
But skip it if you're working on a greenfield project with less than 5,000 lines of code. The setup overhead isn't worth it. Also skip it if your team isn't committed to writing meaningful commit messages — Cody's context quality depends heavily on your git history and file structure being sane.
Getting Started with Sourcegraph Cody
You need a Sourcegraph instance (cloud or self-hosted) and the IDE extension. Here's the minimal setup for VS Code:
# Install the extension
code --install-extension sourcegraph.cody-ai
Then authenticate and point it at your repo. For a self-hosted instance, add this to your .vscode/settings.json:
{
"cody.enabled": true,
"cody.serverEndpoint": "https://your-sourcegraph-instance.com",
"cody.codebase": "github.com/your-org/your-repo"
}
Once connected, you can ask Cody questions about your codebase directly in the chat panel. No need to copy-paste context — it already has it.
Core Sourcegraph Cody Concepts Every Developer Should Know
1. Context-Aware Chat
Cody can answer questions about your specific code, not generic programming trivia. Ask it about your actual functions:
// In your chat prompt, reference your actual code
// "Why does the `validateOrder` function in src/utils/orders.ts throw on empty arrays?"
Cody will pull the function, trace its callers, and explain the logic — including any edge cases you forgot about.
2. Codebase Search and Navigation
Instead of grepping through 50 files, use Cody to find patterns across your repo:
// Ask: "Find all places where we call the external payment API without error handling"
Cody searches your entire codebase and returns relevant snippets with file paths. This is a massive time-saver for refactoring.
3. Autocomplete with Repository Context
The autocomplete isn't just predicting the next token — it knows your naming conventions, your error handling patterns, and your project structure:
// With your repo indexed, Cody autocompletes based on your actual patterns
async function fetchUserProfile(userId: string): Promise<UserProfile> {
// Cody knows you use a specific API client, not fetch directly
return apiClient.get(`/users/${userId}`).then(res => res.data);
}
The suggestions match your existing code style because they're generated from your codebase, not from generic training data.
Common Sourcegraph Cody Mistakes and How to Fix Them
Mistake 1: Not Indexing Your Full Repository
Cody is only as good as what it can see. If you only index the frontend, it won't understand your backend schema. Fix: make sure your Sourcegraph instance has your entire monorepo indexed, including package.json files and type definitions.
Mistake 2: Asking Vague Questions
"Fix this bug" gets you garbage. "The createOrder function in src/api/orders.ts fails when the cart is empty, but only in production. Trace the flow and identify where the empty check is missing" gets you an actual answer. Be specific about file paths, function names, and error messages.
Mistake 3: Relying on Cody for Security-Critical Code
Cody can help you write code, but it won't catch all injection vulnerabilities or auth bypasses. I've seen it generate SQL queries that looked fine but had subtle injection points. Always review Cody's output for security-sensitive operations yourself.
When Should You Use Sourcegraph Cody?
Use Sourcegraph Cody when you're working on a large, established codebase where understanding the full context matters more than writing new code from scratch. It's ideal for:
- Onboarding: New devs can ask Cody "How does our auth flow work?" and get a detailed walkthrough.
- Refactoring: Cody can trace all usages of a deprecated function before you remove it.
- Debugging: When a bug spans multiple services, Cody can connect the dots faster than manual tracing.
Skip it for tiny projects, one-off scripts, or when your team values speed over context. The setup cost isn't worth it for a weekend hackathon.
Sourcegraph Cody in Production
Three things I've learned from running Cody on real projects:
1. Keep your Sourcegraph instance updated. The AI models improve constantly. If you're self-hosting, schedule regular updates. The difference between a 6-month-old model and the latest one is significant.
2. Create a shared prompt library. When your team finds a prompt that works well, save it. We have a cody-prompts.md file in our repo with templates for code review, bug tracing, and architecture questions. This standardizes how the team uses Cody and improves output quality.
3. Use Cody for documentation generation. It's excellent at generating README sections and inline comments from your actual code. Run it on your API routes before a release, and you'll have decent docs without spending hours writing them.
One more production tip: don't let Cody's suggestions replace your code review process. Use it to speed up your work, but treat its output like any other PR — review it, test it, and make sure you understand what it's doing. That's the difference between using an AI assistant and being used by it.
The concrete takeaway: set up Sourcegraph Cody on your largest repository today, ask it one specific question about your codebase that you've been putting off, and see if the answer saves you more time than the setup cost.