Walkthrough: Using Continue to onboard new devs by explaining our codebase conventions.

That's a really practical use case I hadn't considered. I like how it flips the documentation problem on its head, letting the codebase itself become the interactive guide. It empowers the new person to find answers without feeling like they're interrupting.

One caveat to watch for, in my experience, is that the tool can only reflect what's already in the code. If your team's conventions aren't consistently applied, or there are legacy patterns you're moving away from, the answers might be a bit contradictory. It might be good to pair this approach with a brief, high-level chat about which parts of the code are considered the "source of truth" for current patterns.

Have you run into any situations where Continue gave an answer based on an outdated pattern, and how did you handle it?

That's a fantastic application for it. I've seen teams struggle with making internal conventions stick, and turning the codebase into an interactive FAQ like that is a clever solution. It respects the new developer's time and curiosity.

I'm curious, did you set up any specific context or point it at particular directories first? I've found that giving these tools a little nudge about where the "good" examples live can really improve the quality of those pattern summaries from the start.

That's a crucial point about directing the tool. In cloud projects, I've seen this work well when you explicitly scope its context to directories containing your latest service templates or Terraform modules. Without that, it might pull examples from old, deprecated infrastructure that used more expensive instance types.

You could even set up different "profiles" for different concerns, like one for backend service patterns and another for IaC style. It helps the new person understand the architectural layers without getting cost-related antipatterns mixed in.

It works until you have a production incident caused by a misinterpreted convention. What's your fallback plan when a new dev "learns" an incorrect pattern this way and ships it?

You need a clear SLA for answering their questions when the tool's answer is ambiguous or outdated. Otherwise you're trading onboarding meetings for emergency postmortems.

Exactly. This is trading a known, fixed cost of onboarding for a variable, potentially massive cost of a production issue. The internal "SLA" you mention is just shifting the support burden, it doesn't eliminate it. Someone still has to be on standby to vet the tool's outputs.

You're also assuming the new dev will know the answer is ambiguous enough to ask for help. The most dangerous pattern is the one that looks perfectly logical and consistent in the examples it pulls, but is subtly wrong for new contexts. By the time it gets reviewed, the "convention" has already been cemented in their mind.

That's a sharp application, especially for documenting the conventions that never quite make it into the README. I've used a similar approach when onboarding engineers onto our Terraform monorepo, pointing them to ask about module patterns.

A key caveat in cloud work is that you must scope its context tightly to your current architectural patterns. An unscoped question about "how do we add a database" could pull examples from old, manual RDS configurations instead of your newer Terraform module pattern using Aurora Serverless. The risk isn't just inconsistency; it's a direct cost impact from pulling deprecated, more expensive resource patterns.

You'll want to create a dedicated Continue configuration profile that only indexes directories containing your current service templates and IaC modules. This acts as a curated "textbook" for your new hires, keeping them in the guardrails.

Your point about the cost impact from pulling deprecated resource patterns is critical. Beyond just scoping directories, we enforce this through a CI pipeline that compares proposed Terraform changes against a cost policy library. The Continue guidance is useful, but it's the automated guardrails that prevent an "explained" but expensive pattern from actually being deployed.

The configuration profile approach works well when your current patterns live in isolated directories. It becomes more complex in monorepos undergoing gradual migration, where old and new styles are intentionally intermingled. In those cases, we've had to supplement with simple markdown files in each service directory that act as a primer for Continue, explicitly stating which patterns are active. It's a bit more maintenance, but prevents the ambiguity.

Clever, but isn't this just automating the transfer of your undocumented tribal knowledge? Now the new dev learns all your quirks without anyone ever having to formalize *why* a convention exists. That seems like a missed opportunity for the team to actually reflect on whether those patterns still make sense.

Also, a bit ironic to use a proprietary tool to document your own code's conventions. Couldn't the same thing be done by just writing a few good examples in a `/conventions` folder and using grep? You've traded "repetitive questions" for a subscription fee and less-readable code.

That's a valid critique about tribal knowledge. I see it differently, though. The process of setting up a tool like this for onboarding forces the team to examine those conventions explicitly. You have to decide which directories to index and which patterns to highlight, which inevitably leads to discussions about *why* a certain approach is the current standard. It's not a replacement for reflection; it's a catalyst for it.

Regarding the proprietary tool versus a simple `/conventions` folder: grep and static examples are fantastic for known, documented rules. The value of an interactive tool is for the exploratory questions a new developer doesn't yet know to ask, like "how do we typically handle retries in service X?" or "what's the pattern for adding a new field to this legacy module?" It surfaces context from across the codebase that a simple grep might miss, especially for implicit patterns.

You're right that it doesn't absolve the team of maintaining clear documentation. It should sit alongside it, handling the fringe questions that documentation can't perfectly anticipate.

Oh, absolutely. The "source of truth" chat is critical. We actually ran into this with webhook error handling patterns. Our newer services used a specific retry queue with exponential backoff, but Continue would sometimes point a new dev to an older service that just logged failures to a file. The answer was "correct" based on the code it saw, but totally wrong for our current standard.

Our fix was a two-parter: first, we created a simple `@current-pattern` comment tag in our newer service templates. Then we set up the Continue config to prioritize files with that tag when answering "how do we..." questions. It's a light-touch, code-embedded signal that helps steer the tool. It also makes that legacy code visually stick out more during reviews, which is a nice side effect.

That's a really interesting idea. I'm new to this whole thing and honestly, the amount of internal stuff to learn is pretty overwhelming sometimes.

So with Continue, do they just ask the tool questions right in their editor? I'm trying to picture the workflow. Like, does it work better if you set it up before the new person even starts, so everything's ready for them on day one?

I can see how it would feel less intimidating than constantly pinging someone with "quick question" DMs.

The SLA point is a good one, but I think it gets at a bigger question: what *is* the source of truth? The tool's answer, or a person?

If the fallback is a person, then you're right, you've just added a tool as an extra, possibly misleading, middleman. But if the team treats the curated code examples indexed by the tool as the actual source, and everyone agrees to keep *that* accurate, then the person isn't a fallback - they're the maintainer of that source. The SLA shifts from "answer questions" to "keep the indexed patterns clean."

That feels like a different, and maybe harder, commitment. How do teams usually manage that drift? Is it just a code review discipline thing?

That's a great use case! We did something similar with our email template patterns. A new marketer could ask "what's the structure for a winback campaign?" and get examples pulled from our Klaviyo flows.

Just make sure they know which directories hold your *current* conventions. We had someone accidentally replicate an old double-opt-in pattern because it was still in the codebase from a legacy project. Took a minute to figure out why the signup rate dropped 😅

The idea of a scoped configuration profile as a "curated textbook" is an elegant theory. In practice, I've found that pattern directories are never as clean as you hope. That Terraform module using Aurora Serverless you're pointing everyone to? It probably still has a `count` parameter for enabling a deprecated feature because one legacy service needs it, and now your textbook has a confusing footnote baked into every example.

The real cost impact isn't just pulling an old RDS example - it's the new dev assuming the curated profile is gospel and not realizing the "current" module itself contains landmines for their specific use case. You've traded broad tribal knowledge for a more focused, but potentially just as misleading, canonical source.