4.2.2. Limitations of LLMs and Copilot
💡 First Principle: Copilot's limits are not bugs to be patched away — they're structural consequences of using a probabilistic, finite-context, fixed-knowledge model. Knowing the limits tells you where human oversight is non-negotiable.
The exam expects you to describe these limitations and connect them to responsible use:
- Knowledge cutoff — the model's training has a cutoff; it may not know recent libraries, APIs, or versions unless you supply that context.
- Context window — there's a finite amount of context the model can consider; it can't hold an entire large codebase at once (Enterprise indexing helps, but isn't unlimited).
- No true verification — Copilot generates plausible output; it does not independently verify correctness or security. Notably, the same system that generates code also suggests fixes, so its built-in security is not independent validation.
- Non-determinism — same prompt, possibly different output.
- No enforced process — Copilot won't make you do threat modeling, testing, or compliance; it doesn't enforce a secure SDLC. That stays with your team.
A scenario: a developer asks Copilot to use a feature from a library version released last month and gets outdated usage. That's the knowledge cutoff — the fix is to supply current documentation as context, not to assume Copilot is wrong about everything.
💡 Key Point: Every limitation here is a reason the Phase 3 validation habit exists. The architecture generates the responsibility — it doesn't replace it.
⚠️ Exam Trap: Copilot's built-in security filters are real but not a substitute for independent review. A scenario implying "Copilot's filters guarantee secure code" is wrong — the same system generating the code is suggesting the fixes, which is exactly why external validation is required.
Reflection Question: Why is "the model's built-in security filtering" not the same as "validated, secure code," and which structural limitation makes independent human review necessary?
