Check out my configuration for Continue that finally made it useful for Go development.

That's a fantastic example of the core principle in tool adoption, especially with AI coding assistants. The "generic answers" problem usually means the tool lacks context. You didn't just configure settings, you essentially built a lightweight, project-specific knowledge profile.

Your question about "training" it hits the nail on the head. For any non-trivial codebase, yes, you absolutely have to. I treat it like onboarding a new junior dev from a different background. You have to point them at the style guide, show them the important directories, and explain your local idioms. The system prompt and targeted ignore lists are your first-day orientation.

For refactoring prompts, I've found success with a two-part structure. First, state the concrete change, like "convert these switch statements to a map." Second, and this is key, add the constraint that defines success for your team: "...while preserving our existing error wrapping pattern using `fmt.Errorf`" or "...ensuring the new function signatures match our internal middleware interface." That second part pulls from the context you just configured.

That junior dev analogy is spot on. It makes the effort feel less like tweaking a tool and more like setting someone up to help you.

So for those refactoring prompts, does the two-part structure help even with smaller, single-file changes? Or is it mainly for bigger tasks where the assistant might lose the thread?

The two-part prompt works fine for small changes, but I'm skeptical we need that much structure just to rename a variable. Sounds like more process for process's sake.

The real test is whether it helps with the ambiguous stuff. Try asking it to "make this function more idiomatic Go" without a two-part prompt and see if you get back something useful or just a lecture on using `defer`.

This "training" phase is exactly why these tools waste more time than they save. You're writing documentation and building a context system for a black box that forgets everything when you close the editor.

Just use `gopls`. It knows Go. It understands your workspace. Zero config.

Absolutely, it helps for the small stuff too, even if just as a habit. The structure isn't for the tool as much as it is for my own thinking.

For a simple rename, the "two parts" just take ten seconds: "We're changing `clientId` to `clientID`. The new name should match the `UserID` field in the struct on line 47." It prevents the assistant from overthinking and changing the wrong variable three functions up.

The habit pays off when the task *seems* small but is actually ambiguous, like "make this error check more consistent." The first part defines "consistent," the second part shows it where to look.

Your "training" phase sounds suspiciously like writing a spec for a consultant who only speaks in probabilities. So you spent weeks configuring it to understand your own codebase? The vendor didn't mention that in the demo.

The real question is, what happens when you add a new dependency pattern or change your logging middleware? Do you go back and update the prompt again? That's not onboarding a junior dev, that's constantly rewriting the employee handbook for a temp who keeps getting amnesia.

I've seen this movie before with other "intelligent" tools. The initial setup cost gets quietly amortized into every project change.

Your point about the system prompt focusing on Go conventions is a good one. That's less about "training" and more about providing necessary constraints, like you'd give any code formatter or linter. The alternative of it randomly suggesting Python is just noise.

I've found that for refactoring prompts, being specific about the scope helps a lot. Instead of "refactor this," try "find all the hardcoded timeouts in this handler package and extract them to a config struct." It gives the assistant a clear search pattern and a concrete output format. That tends to work across different languages.

Exactly, framing it as a "constraint" feels more accurate. It's like narrowing the search space, not teaching it facts.

The "find all the hardcoded timeouts" example works because it gives the assistant a simple pattern to match, which is something these models are decent at. The real trick is figuring out which tasks are pattern-matching versus which require actual codebase understanding.

That's where the system prompt pays off, by establishing the baseline for what "understanding" looks like, like whether to use `errors.Is` or a custom type for comparisons. Without that, even a well-scoped prompt can go off the rails with a technically correct but wildly unidiomatic solution.

>which tasks are pattern-matching versus which require actual codebase understanding.

That's the million-dollar question. I've been trying to track when my prompts fail, and it's almost always on tasks that need that deeper map of the codebase - like "find all the places we call this deprecated API" when the function name changed last month.

For those, a good system prompt with project conventions gets you halfway. But the other half feels like... hoping your mental model matches its latent one. Sometimes the best constraint is just pointing it at the commit where the change happened and saying "use this as a reference." It's a bit clumsy, but it works better than expecting it to infer the pattern from the current state alone.

That latent model mismatch is the core problem. You can point it at the commit, but then you're just feeding it another pattern to parrot. The real risk is when the model's guess at the "right way" subtly conflicts with your actual architecture.

I've had it confidently "find all the places" based on a function name, only to miss the three services that call it via a gRPC client stub because that's not how its training data structured programs. So you get a false sense of security. You still need to grep for the protocol buffer message name yourself.

It's less a junior dev and more a savant intern who's read every textbook but has never seen your build pipeline.