Two weeks into a contract job, I inherited a Go service with about 1,400 files and a README last touched in 2021. My first question wasn’t how anything worked. It was simpler: of the eleven types named some variation of PaymentHandler, which one was actually wired into production? Grep returned 340 hits. Cody answered in roughly twenty seconds and handed me the call chain.
That is the pitch, but the pitch isn’t the useful part. What matters is the workflow around it. Below is the setup and the habits I’ve settled into after using Cody, an assistant that indexes your whole repository rather than just the file in your editor, across a handful of messy codebases.
Get it running without a two-hour detour
Install the extension for VS Code, JetBrains, or Neovim, sign in, and you’re most of the way there. The part people skip is the part that decides whether Cody is useful or just another autocomplete.
- Open the repository at its root. If you open a nested folder like services/payments, Cody’s view of the world shrinks to that folder. Repo-wide questions get folder-wide answers.
- Let the initial index finish. On a mid-size repo this takes a few minutes and it runs in the background. Ask questions before it’s done and you’ll wonder why it can’t find anything.
- Pick the plan that matches your question. The free tier is generous for chat and simple edits. Pro ($9/month at time of writing) unlocks the stronger models and larger context, which is where multi-file work gets tolerable.
- Connect a Sourcegraph instance if your company has one. That’s what gives you answers spanning more than one repository, which is the actual reason to choose Cody over a generic chat window.
Learn the @-mentions before you type a single question
The single biggest quality jump comes from telling Cody where to look instead of hoping it guesses. In chat you can @-mention a file, a symbol, a repository, or a URL. You also get implicit context from whichever tabs are open and whatever you have selected, so closing fifteen stale tabs before asking is not superstition.
Here’s the difference on a real bug I hit last month:
Weak prompt: “Why does checkout time out?”
Useful prompt: “@CheckoutService.java @payment-retry.yml @PaymentGatewayClient.java checkout times out after about 30 seconds whenever the provider returns a 503. Walk me through the retry path and tell me which config value controls the total wait.”
The second version names the files, names the symptom, and names the observation that matters (the 30-second ceiling). Cody stops summarizing and starts reasoning. The answer pointed at maxAttempts: 4 with a 10-second backoff multiplier, which is a 30-second wall by arithmetic and not a coincidence.
Three prompt patterns worth memorizing
- Trace it: “@symbol list every place this is called from and what each caller passes in.”
- Explain it to a newcomer: “@directory explain what this package is responsible for, then tell me what would break if I deleted it.”
- Constrain the change: “Suggest a fix for @file, but do not change any public method signature.”
Walkthrough: chasing that retry bug end to end
The pattern I use is three steps, and I rarely deviate.
Step one: map the path
Ask for the call chain first, before proposing anything. In the checkout case, Cody returned four hops from the controller down to the HTTP client, and flagged that one of them wrapped everything in a generic try/catch that swallowed the provider’s error body. I’d have spent an hour finding that myself.
Step two: find the decision point
Next question: “Which file actually decides whether to retry?” That led to a small `shouldRetry` method with a hardcoded list of status codes that didn’t include 503, even though the config file clearly intended it to. One-line fix, three-line explanation of why it was wrong.
Step three: verify, don’t trust
Cody will hand you confident answers about code it only partially read. Ask it to point at the exact file and line for every claim, then open that file. In this case the regression test already existed at CheckoutServiceRetryTest; I added one case for the 503 path and ran it. Forty minutes total, most of it reading.
Writing tests for code nobody documented
This is where Cody earns its subscription, because it’s tedious work that benefits from a second pair of eyes. Select a function, then either use the built-in test generation command or ask directly with the symbol mentioned.
One warning: default output skews toward the happy path. Ask for the ugly cases explicitly. For a date-parsing helper I got four cheerful tests and had to follow up with: “Add cases for an empty string, a leap-year date, a DST transition, and a timezone offset of +14:00.” Those four found a real bug in eleven seconds of test writing. That ratio doesn’t happen often, but it happens.
Multi-file refactors: make it plan before it edits
Renaming a parameter is easy. Renaming a concept across nine files is where assistants usually fall apart. The trick is separating the survey from the surgery.
Ask first: “List every file that references this interface, grouped by whether it implements, calls, or merely imports it.” Read that list, correct it if anything looks wrong, and only then say “now propose the change.” Cody will show diffs you accept file by file rather than rewriting everything at once, which is the only sane way to do this on a codebase with tests you trust.
If your team lives in IntelliJ rather than VS Code, the JetBrains AI Assistant handles refactoring differently and has its own rough edges, so a direct comparison is worth ten minutes before you commit to one.
Custom commands turn this into a team tool
You can save prompts as custom commands in a config file inside the repository. That means the whole team inherits the same questions.
Our most-used one is called explain-service. It asks for a service’s entry point, its external dependencies, the environment variables it reads, and the two most likely failure modes. New joiners run it on day one instead of booking a call. Another, pre-review, checks a diff for missing error handling and hardcoded credentials. Both live in version control next to the code they describe, so they evolve with it.
Where Cody still loses the plot
Autocomplete is not why anyone switches, and honestly the inline completions feel a step behind the dedicated completion tools in some languages. Chat is the strength.
The failure modes are predictable once you’ve seen them. After a big branch switch or a rebase that moves hundreds of files, the index goes stale and answers start citing code that no longer exists. Re-index, and the problem disappears. Very long files get truncated, so the model may miss a helper defined 3,000 lines down. Generated code and vendored dependencies confuse it more often than handwritten code does.
The countermeasure is the same in every case: narrow the question, name the symbols, and check the citation before you act on it. Cody is genuinely good at finding the two files you needed to see. It is not a substitute for reading them, and the moment you stop reading is the moment it starts costing you more than it saves.