Zero context - agent sees only the open file

At L1 (Ad-hoc), when you use an AI agent or chat assistant, it sees only what you give it: the file currently open in your editor, whatever code you paste into the chat window, and your current prompt. It has no knowledge of your repository structure, your architecture decisions, your naming conventions, or how the file it's editing relates to anything else in the system.

This isn't a bug - it's the natural starting state. A freshly installed AI tool has no configuration, no project-level context, no understanding of your tech stack beyond what it can infer from the snippet in front of it. The agent treats every interaction as if the current file is the entire universe.

This state has a name in the maturity matrix: zero context. The agent might be a powerful model capable of sophisticated reasoning, but without context, it's like hiring a brilliant engineer on their first day and only showing them one file at a time. They'll write technically correct code that may completely violate your project's patterns, import libraries you don't use, create abstractions that duplicate existing ones, or solve problems that were already solved elsewhere in the codebase.

The entire Context Engineering progression - from L2 through L5 - is the systematic response to this problem. Every level adds more context, in more structured forms, delivered more reliably to the agent.

Understanding the zero-context condition helps you diagnose why AI suggestions feel off. When the agent recommends a pattern you stopped using two years ago, or generates a module that already exists under a different name, or uses an HTTP client library when you've standardized on a different one - that's zero context in action.

• Suggestions violate invisible constraints - the agent can't know what it hasn't been told
• Duplicated code and abstractions - agent creates utilities that already exist elsewhere in the codebase
• Wrong dependency choices - agent imports libraries not in your stack, or the wrong version
• Pattern inconsistency - every agent session starts fresh, so suggestions vary based on what file happens to be open
• Compounding errors in agents - multi-step agents are especially dangerous: an error in step 1 (wrong assumption about project structure) propagates through all subsequent steps

Zero context isn't just an inconvenience. For teams considering AI agents for non-trivial tasks, L1 is a real ceiling. The agent can help with self-contained algorithmic problems. It cannot reliably help with anything that requires understanding "how we do things here."

1. Recognize the zero-context boundary - Before submitting a prompt, ask yourself: "What does the agent need to know about my project that it can't see from this file?" The gap between that answer and the current state is your context deficit.
2. Compensate manually - At L1, context engineering is manual: paste in relevant files, include explicit constraints in your prompt, tell the agent your tech stack and conventions before asking it to generate code.
3. Keep prompts concrete - Zero-context agents perform best on bounded tasks: "refactor this function to use async/await" is better than "improve this service." The more self-contained the task, the less missing context matters.
4. Open related files in your IDE tabs - Many tools (Copilot, Codeium) use open tabs as additional context. If you're working on a service, open the interface definition and a sibling service before generating code.
5. Validate all architectural suggestions - Never accept an agent suggestion that implies a new dependency, a new abstraction, or a new pattern without checking whether it already exists in your codebase.
6. Document what you had to manually provide - Track what context you keep pasting into prompts. This list becomes your CLAUDE.md backlog.

Accepting generated code without cross-referencing the codebase. The agent doesn't know you have a UserRepository class - it'll generate a new one inline. Always search the codebase before accepting any generated abstraction or utility.

Using agents on files that are highly coupled. Zero-context agents work best on files with few external dependencies. Using them on an orchestration layer, a shared utility module, or an event dispatcher without providing extensive context will produce suggestions that break implicit contracts throughout the system.

Mistaking pattern-matched plausibility for correctness. The agent produces code that looks right because it pattern-matches against training data. But "looks like the right kind of code" is not the same as "is correct for this system." Senior engineers are especially susceptible to this - the code is good enough that the review becomes superficial.

Not capturing what you manually provided. When you solve the zero-context problem by pasting in context manually, you're doing the work of building a CLAUDE.md file - but throwing it away at the end of the session. The fix is to write it down.