Skip to content
Notifications
Clear all

How do I get Copilot to understand our internal domain language and acronyms?

3 Posts
3 Users
0 Reactions
4 Views
(@vendor_side_eye_5)
Eminent Member
Joined: 5 months ago
Posts: 12
Topic starter   [#360]

Everyone's talking about Copilot like it's magic. It's not. It's trained on public code. It doesn't know your "S4R" means "System for Reporting" or that "CustEng" is Customer Engineering.

The out-of-the-box suggestions are useless if you use internal jargon.

I've seen the vague docs about "fine-tuning" or "context." The vendor promises are light on actual implementation.

What's the real, technical method to make it learn our terms?

* Is it about feeding it specific files in the workspace?
* Do we have to create a custom model? (If so, the cost claim is a lie)
* Are code comments with glossary lists actually effective?

Or is this just a fundamental limitation they don't advertise?



   
Quote
(@test_harm)
Active Member
Joined: 2 months ago
Posts: 10
 

Exactly. It's a limitation they gloss over. You can't "teach" it like a team member.

I've found code comments with explicit definitions *sometimes* nudge it in the right direction for a few lines. But it doesn't stick. You're just adding more context for that single suggestion.

Creating a custom model? That's enterprise-tier money and effort. Complete fantasy for most teams. So you're stuck working around its ignorance, which kills the promised efficiency. Feels like a bad trade-off most days.


If it's not flaky, is it even tested?


   
ReplyQuote
(@crusty_pipeline)
Estimable Member
Joined: 2 months ago
Posts: 142
 

You're right about the custom model route being a fantasy. It's the vendor's classic "solutions" slide that always ends with "and for that, you'll need our premium enterprise package."

But I think you're underselling the code comments trick, or maybe we're doing it differently. It's not about a glossary at the top of a file. That's indeed useless. You have to weaponize the context window right before the suggestion you need.

If I'm writing a function that uses "S4R", I'll write a preceding comment block describing the function signature in plain language *using the acronym*, then immediately follow it with a one-line comment that's just a direct mapping. Only then do I start typing the function.

```python
# Fetches reconciliation data from the System for Reporting (S4R) and transforms it.
# S4R = System for Reporting
def fetch_s4r_reconciliation
```
If you do that consistently at the point of use, the model's immediate context includes the definition. It won't "learn" it, but you've effectively created a local alias for the next 40 lines. It's a hack, but it shifts the work from fighting the tool every time to a deliberate, if annoying, pattern.

The real trade-off isn't the lost efficiency, it's the cognitive load of maintaining this documentation-for-a-machine alongside your actual code. That's where it feels like a bad trade. You're writing comments for an intern who can't take notes.



   
ReplyQuote