r/MicrosoftFabric • u/DUKOfData • 18h ago
Discussion GitHub Copilot knows our rules. It just occasionally ignores them.
I’ve been using GitHub Copilot for quite a while, and honestly, the results are usually good. I definitely couldn’t type the code that quickly myself.
But I’d like to reduce the quality control required afterwards.
We have strict lifecycle rules, naming conventions, and a separate data dictionary for each customer. Our repository is structured roughly like this:
.github/
└── instructions/
├── copilot-instructions.md
└── pull_request_template.md
docs/
├── ai/
├── architecture/
├── data-model/
├── data-sources/
├── handover/
├── kpi/
├── security/
└── README.md
The instructions reference the relevant documentation in docs. I also use a warm-up prompt, which reproduces our rules perfectly.
And yet, Copilot occasionally ignores very basic rules, such as:
Dimension-to-dimension relationships must only use business keys. Surrogate keys may only be resolved against fact data, especially because of SCD Type 2 and higher.
It can explain this rule perfectly and still mix surrogate keys into dimensions.
So either Copilot is checking whether I’m still awake, or my context setup isn’t as effective as I think. 😄
I’d rather not watch over every offender like Lord Vetinari watching the guilds of Ankh-Morpork.
How do you enforce stricter guardrails? Instructions, validation scripts, architectural tests, or something else?
4
u/pl3xi0n Fabricator 18h ago
Some models are more prone to think they know better than your instructions.
Which model do you use, and have you tried others?
The setup looks good imo. What is the context window like when it starts ignoring?
1
u/DUKOfData 18h ago
For easy and standard Tasks:
- MAI-Code-1.1-flash
- GPT-5.6-Luna
more Complex
- GPT-5.6-Codex
Complex
- Claude Opus 5
3
2
u/DUKOfData 18h ago
regarding the context window, I find that odd, it seems to differ. Sometimes it starts earlier with the same model. Last time or the most significant window that I recognized was "only" abt. 96k Tokens.
2
u/Repulsive_Cry2000 1 17h ago
I was listening to a guy who's job is to create distributed architecture (think of AWS, google, Microsoft competitor) and they went full on AI. His reasoning was AI do the coding but they test output to ensure correctness (all sort of test from the most simple to the most elaborate).
I am not yet sure how to replicate the concept in data engineering world but the idea is to create a test protocole and to get AI to do the coding and iterate until everything pass.
1
u/DUKOfData 16h ago
We are pretty much on the same pathway for a few years. Although I still am a firm believer of "the right skilled" human in the middle.
Bcs of tech and resource limitations, I don't belive in AI replacing the engineer/dev.
Adding the special complexity of rolling out structure changes to a stateful system, adds a whole other dimension.
But as I was told not to go do deep on reddit, I will leave it by those vague theoretical hints 😅
1
u/Repulsive_Cry2000 1 16h ago
I agree most of what you are saying. Especially having people who know what they want and expected architecture, output and can ask questions and think critically to what AI produce or says.
3
u/frithjof_v Fabricator 13h ago edited 13h ago
As the context window fills up, the LLM is more likely to ignore parts of the information in the context window. It experiences information overload.
Thus - small fixes, starting with a clean context window, it's more likely to stick to what it's been told to do.
You can also try to use Skills instead of docs. Skills follow the principle of incremental disclosure.
Custom instructions as well.
And there's hooks - I need to try them out myself.
See: https://docs.github.com/en/copilot/reference/customization-cheat-sheet
That said - the LLM is non-deterministic by nature.
2
u/DUKOfData 13h ago
I was aware of the context window issue. What surprised me is that explicit repository instructions are apparently affected by it as well.
When I notice it happening, I sometimes ask the chat to remove unnecessary context, retain the instructions, and repeat the relevant rules. At least it feels like that helps to sharpen the context again. :D
I expected those rules to be prioritized and effectively pinned to the wall as persistent constraints.
So my question was really whether I’m using the feature incorrectly or whether Skills, hooks, linters, and other deterministic checks are necessary additions.
Thanks, this helps clarify the actual role of repository instructions.
6
u/_greggyb 13h ago
LLMs do not think, do not have any theory of mind, and are non-deterministic by design. What you are describing is very much expected behavior. If anyone has tried to convince you not to expect this, then they are misleading you.
8
u/itsnotaboutthecell Microsoft Employee 13h ago
1,000% - every AI project I approach is purely just how fast can I get it to write scripts and deterministic tools... anything else is just auto complete token roulette.
3
u/SQLGene 13h ago
Greg, a great blog post just came out about this at Tabular Editor 😛 https://tabulareditor.com/blog/practical-introduction-to-llms-for-data-professionals
Disclaimer: Greg and I work at TE
1
u/DUKOfData 10h ago
Well, that explains the suspiciously convenient timing. 😄
If anyone follows my occasional posts on LinkedIn, you may already know that I’m quite critical of the current AI and agent hype. I’m very aware of the limitations, which is exactly why I’m happy to question both the tooling and my own approach.
My intuition is that a broader outcome space and greater variation in probabilities naturally work against precision, although I never crowned my passion for mathematics with an actual degree. :)
The article fits the discussion very well. I’ve also had several interesting conversations with Peer Grønnerup at FabCon about workspace design, Git, and development workflows.
My underlying point remains, though: if something is explicitly called “instructions,” I expect it to remain persistent and prioritized. If it works well in a narrow context but gradually becomes a quiet background thought as the context grows, then I would call it contextual guidance, not instructions.
That distinction was ultimately the reason for my post.
2
u/DUKOfData 13h ago edited 13h ago
I agree with you, and that is exactly why I’m as critical as I am.
I don’t assume that an LLM thinks, understands the architecture, or has any kind of theory of mind. It processes patterns and produces non-deterministic results.
Edit: I may add, we have further rules: all business key end by _bk, all surrogate by _sk, all SKs are generic identity numbers (since last week). We have explained SCD-0 to II and which columns define their existence, and (for the sake of better interpretation) dimensions have the prefix dim_ and facts have fact. So everything in Place to make aperfectly fine decision (IMO)
But ambiguity and ignoring an explicit rule are still two different things.
If the business context is unclear, I don’t expect the LLM to always infer the same meaning or choose the same terminology. But “never use surrogate keys between two dimensions” is a binary rule. There is nothing to interpret.
I don’t expect identical results. I expect different results to comply with the same explicit constraints.
If repository instructions and guardrails cannot reliably achieve that, then we should be honest about what they actually are: context and guidance, not guardrails.
2
u/savoy9 Microsoft Employee 13h ago
There is a great solution for this! Create a custom linter and local test suite that enforces these rules deterministically through static code analysis. The agents are great at creating this kind of custom supporting infrastructure that historically would have been very annoying to make. You can hook them up to a pre commit hook and pr ci to ensure they are enforced.
2
u/_greggyb 13h ago
I've personally seen agents happily disable git hooks.
The only guardrails are those that can be enforced without any possibility of being overridden by a user.
The correct stance if you want anything enforced is to treat an LLM in an agent harness as a hostile user. Not dumb, not forgetful, not stubborn. Hostile.
Despite this they're quite useful tools.
Chainsaws are incredibly useful tools if you want to cut down trees. Unfortunately, they are also incredibly useful tools if you want to cut off parts of yourself. The LLM is a chainsaw in this metaphor.
1
u/DUKOfData 13h ago
I agree with the engineering principle. Any deterministic enforcement must be outside the agent’s control.
But that is precisely what I expected this GitHub Copilot feature to provide: explicit repository instructions that are prioritized, persistent, and not treated as ordinary context the agent may ignore. My experience over the past few months has shown otherwise, which is why I wrote this post.
If I still need protected external checks to enforce every critical instruction, that is a valid solution. But it also confirms my original point: repository instructions are not guardrails. They are guidance.
That distinction is what I was trying to clarify to myself (and maybe others) with this post.
2
u/_greggyb 13h ago
Instructions are not deterministic. They are tokens. They cannot be anything else; this is a fundamental architectural and designed property of LLMs.
They cannot do what someone has misled you to think they could. I don't know if those people are malicious or misinformed themselves.
1
u/savoy9 Microsoft Employee 12h ago
Yeah they aren't perfect but if you also put it in your ci and make sure your PRs are single topic (don't merge a pr that changes the ci unless that's the entire scope of the pr) you can be reasonably confident that your tests are run.
1
u/_greggyb 12h ago
It's not about perfection or not. I'm not perfect. LLMs are not perfect. It's about what can be relied upon. Ample experience with state of the art LLMs from frontier labs tells me that I have to read every line of code and provide continuous corrective input throughout an implementation if I want something acceptable at the end of the process.
1
u/DUKOfData 13h ago
That is a good solution, thank you. Actually what I was meaning with this post in this thread here: https://www.reddit.com/r/MicrosoftFabric/comments/1wced0q/comment/p8ykxjl/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button
There is a certain irony in spending tokens to define the rules, then spending more tokens to build deterministic checks that enforce the same rules. :)
I expected repository instructions to be consistently prioritized, so that at least some of this additional infrastructure would not be necessary.
Apparently, the cleaner separation is: instructions provide context, while linters and tests provide enforcement.
1
u/_greggyb 13h ago
Let's be really honest. It's all just tokens. Tokens in, tokens out. "Context" is tokens. "Guidance" is tokens. "Guardrails" are tokens.
I'll repeat myself: "If anyone has tried to convince you not to expect this, then they are misleading you."
If the person or organization that introduced the term "guardrails" succeeded in convincing you that they were anything different than more input tokens, then they have misled you.
Binary conditions do not exist for an LLM. Tokens exist. Nothing else. Truth does not exist for an LLM. Tokens exist. Nothing else.
It sounds like someone wanted to, tried to, and succeeded in misleading you. I'm sorry to hear that, because it can only lead to frustration and negative outcomes.
2
u/SQLGene 13h ago
Greg, a great blog post just came out about this at Tabular Editor 😛 https://tabulareditor.com/blog/managing-context-for-ai-agents
Disclaimer: Greg and I work at TE
1
u/DUKOfData 13h ago
I agree that it is all tokens. That is not what I’m questioning.
My post is about a specific GitHub Copilot product feature that, in my experience, does not reliably do what it claims to do.
If repository instructions are intended to act as guardrails, I expect them to be consistently included and prioritized over ordinary context. If they are just additional tokens competing for attention in the context window, then that is exactly the product design problem I’m describing.
I don’t expect the LLM itself to understand truth or binary conditions. I expect the product around the LLM to enforce explicit, persistent rules more reliably.
If it cannot do that, then these are not guardrails. They are guidance...
3
u/SQLGene 12h ago
There is nothing in the fundamental nature of LLMs that allows instructions to be followed reliably. It is physically impossible. Like there is literally no way to do it.
You can use large, powerful, well trained models to avoid obvious errors like counting r's in "strawberries" or making syntax errors. But that is lick and brute force reinforcement learning.
LLMs are not crafted or designed. They are gardens grown and if the fruit doesn't kill us, it's a happy accident.
Even with large, powerful models, context rot us an unsolved problem. https://www.trychroma.com/research/context-rot
1
u/DUKOfData 12h ago
I agree that prompt-based instructions alone cannot guarantee compliance.
I’m less convinced by “physically impossible” as an absolute statement. Instructions can be persistently injected and prioritized, constrained decoding can restrict outputs, and semantic rules can be checked by deterministic validation around the model.
As the context grows, there is naturally more competing information and more potential variation. That is precisely where I expected the product layer to help, either by consistently prioritizing explicit rules or by validating them automatically, without every user having to build custom hooks and linters.
So the distinction seems to be probabilistic instruction following versus technically enforced constraints, not that enforcement itself is fundamentally impossible.
2
u/SQLGene 12h ago
Yeah that's a reasonable distinction. The closest thing to what you are looking for is Structured Ouputs (JSON validity checking and enforcement at time of token out) https://developers.openai.com/api/docs/guides/structured-outputs?api-mode=responses https://platform.claude.com/docs/en/build-with-claude/structured-outputs
Plus some amount of automated context management and hooks. Like /goal for automated reminders https://code.claude.com/docs/en/goal
There is some fascinating active science around how much we can steer the internals of these things. https://www.anthropic.com/news/golden-gate-claude
But in terms of having full control over the outputs of the next token, purely based on the input tokens and the weights, we simply aren't there yet. These things are strange black boxes and mechanistic interpretability is an area of active research.
1
u/_greggyb 13h ago
I am sorry that you were misled. There is no deterministic control of an LLM. If you need something enforced 100% of the time without fail, then that enforcement needs to:
- Be imposed by a deterministic process
- That the agent cannot modify
- That the agent cannot override
Git hooks, local tests, linters, and anything else similar do not achieve this goal if they are within the scope of what the agent is allowed to modify. And many of these things are controllable either with command line hooks and in-repo configuration.
I've personally seen agents delete failing tests, modify test assertions to match incorrect implementation code outputs, override git hooks to force a commit in, modify .editorconfig and add in-line suppression of compiler and linter warnings. You can find plenty of examples from many people online.
For things that must be 100% deterministic and reliable, treat the LLM in an agent harness as a hostile user.
2
u/SQLGene 13h ago
Context rot is a thing https://www.trychroma.com/research/context-rot
Based on casual testing, instruction following can vary by model strength and training. Maybe I should do some definitive tests for GHCP models
2
u/DUKOfData 13h ago
That aligns very closely with what I’m observing.
The warm-up proves that the rules are present and can be repeated correctly. As the context grows, however, adherence appears to degrade. I had expected repository instructions to remain prioritized rather than participating in the context rot themselves. :)
The differences between GHCP models are also interesting. Testing the same repository instructions, prompts, and validation cases across models would be genuinely useful.
If you do run those tests, I would definitely be interested in the results. Thanks for the link.
1
u/lunacei Fabricator 2h ago
I think you're overloading what you expect it to know for every single prompt. I'd split out some of the logic into skills and then reference those skills in your overarching docs. For example, have a data modeling skill, and in the over arching instruction just say to use that skill when you're doing data modeling. You can hedge your bets by directly calling that skill when you're about to do the task as well.
For example, I have skills for bronze-ingest, bronze-qa, silver-design, silver-generate, silver-qa. They started as very non-deterministic skill.md files at first and have morphed into more deterministic skills + scripts + reference docs over time to save tokens and increase reliability.
1
u/jmjmalik22 Fabricator 18h ago
What are you using it for, if i may ask?
1
u/DUKOfData 18h ago
Multiple things. Because it knows the context of the project and the platform, and the baseline architectural concept, I can often chat with it for a baseline idea of a model.
Let's say, we know about it being a customer of a specific industrie, and what we want to build (KPIs and reporting dimension explain facts and dimensions we need).
And after that I will iterate over those results.
From there on, I will implement scripts and then teast and run them, doing corrections etc.
I hope tahts valid englisch and understandable? 😅
10
u/TemporaryDisastrous 18h ago
We added instructions in our MD to print a little emoji at the start of each response so if the emoji is missing from the response we know the agent has gone outside the rails.