An AI model can talk fluently about almost anything, which makes it easy to assume it knows the project at hand. It doesn't. Its working knowledge at any moment is exactly what's in front of it: the current conversation, the files attached to it, and general training data frozen at a cutoff date. Everything else, from the product's purpose to who'll use it, has to be supplied.

That gap explains the most frustrating moments in AI-assisted building. When context is missing, the model doesn't ask; it fills the gap with the most common assumption and presents the result with total confidence. In 2025 the industry named the fix, context engineering, marking a shift from hunting for magic prompt words to deliberately deciding what the AI needs to know.

This lesson covers how the model's knowledge actually works, why more context isn't always better, and the everyday habits, from attaching references to starting fresh conversations, that keep an AI collaborator working from the right information.

What does the AI actually know?

At any given moment, an AI model's working knowledge of a project is exactly what sits in front of it: the messages in the current conversation, any attached files or images, whatever it generated earlier in that same chat, and its general training data, which is frozen at a cutoff date. Anthropic defines context as "the set of tokens included when sampling from a large-language model (LLM)" [1]. In plain terms, context is everything the model can currently see, and nothing more.

The model doesn't know the builder's company, product, or users. It can't see other conversations, open browser tabs, or anything on the screen. Training gives it the public, general version of the world, so it talks fluently about almost any topic, but the specifics of one particular project enter its knowledge only when someone puts them there. That single fact drives everything else in this lesson: what to supply, how much of it, and why the model sometimes gets things confidently wrong.

From prompts to context engineering

For a few years, getting better AI output was framed as prompt engineering, a hunt for the right words and phrases. In 2025 the framing shifted. Shopify CEO Tobi Lütke wrote that he preferred the term "context engineering" because "it describes the core skill better: the art of providing all the context for the task to be plausibly solvable by the LLM" [2]. Andrej Karpathy amplified the idea, calling context engineering "the delicate art and science of filling the context window with just the right information for the next step" [3].

The rename relocates the skill from wording to information. Anthropic describes building with language models as becoming less about finding the right words and more about deciding what configuration of context is most likely to produce the desired behavior [4]. For anyone vibe coding, the engineering half can be ignored; the useful habit is the question itself. It stops being "what magic words unlock a good result?" and becomes "what does the AI need to know to do this task?" Attaching a sketch, naming the audience, and starting a clean chat all qualify.

The attention budget

The attention budget

Context is finite, and quality drops as it fills. Anthropic explains it with a human analogy: like people, who have limited working memory, LLMs have an "attention budget" they draw on when parsing large volumes of context, and every new token introduced depletes it [5]. The same post cites benchmarking of a phenomenon called context rot: as the number of tokens in the window grows, the model's ability to accurately recall information from that context declines.

The effect is visible in everyday tools, not just research. Claude Code's own documentation warns that the context window fills up fast and performance degrades as it fills [6]. The practical takeaway is a mindset shift: context isn't a bucket that holds whatever gets poured in; it's a budget that every pasted paragraph, attached file, and earlier message spends down.

References over descriptions

A reference is anything shown to the model instead of described to it: a screenshot, a sketch, a link, or an example of the desired output. Anthropic's guidance puts it memorably: "For an LLM, examples are the 'pictures' worth a thousand words" [7], with the advice to curate a few diverse, representative examples rather than a laundry list of edge cases.

Evidence backs the instinct. In Nielsen Norman Group's evaluation of AI prototyping tools, prompts with attached artifacts produced more streamlined outputs, and the higher the fidelity of the attached file, the more accurately the design was translated; a Figma link produced the most accurate translations of all [8]. In another test, a screenshot of a Pinterest moodboard attached to a broad text prompt yielded a design that visibly adopted the board's style, with zero technical skill required [9].

Describing from memory stays tempting because typing feels like the natural unit of chat. The stronger habit is the opposite: when an artifact exists that shows the intent, attach it and let the words carry only what the artifact can't.

The world's most fluent stranger

A useful mental model for AI collaboration: the model is the world's most fluent stranger. It speaks confidently about nearly everything because training gave it the public, general version of nearly everything, yet it has never met the builder's product, team, or users. Fluency creates a false sense of familiarity.

Anthropic names falsely assuming shared context as a canonical failure mode when writing instructions for models [10]. Nielsen Norman Group's CARE framework for prompts makes context the first component: the audience, the product, and the task [11]. With human collaborators, spelling out those basics feels condescending because colleagues already share the office, the product, and the users. With a model, none of that is shared, so the "obvious" facts are exactly the ones most likely to be missing.

The habit that follows: state the situation and the constraints every time, even the parts that seem too basic to mention.

Confident wrongness

When a prompt leaves a gap, the model doesn't stop to ask about it. It fills the gap silently, defaulting to the statistically most common interpretation in its training data, and then presents the result with full confidence.

Nielsen Norman Group demonstrated this cleanly. Asked for a "profile page" with no disambiguating context, several AI design tools produced a social-media-style public profile, complete with a banner, when the actual need was a private page for course attendees [12]. Nothing signaled the mismatch; the tools simply built the most common meaning of the words. NN/g's conclusion was that designers need to disambiguate the language of their prompts as much as possible.

The misconception to drop is "if it needed more information, it would ask." Human collaborators ask; models mostly assume. Newer tools increasingly do pose clarifying questions on their own, but the safe habit is to expect silence and close the gaps up front.

Pro Tip! Asking the tool to pose its own clarifying questions before it starts building flips the silent-assumption default [13].

Fresh starts and kitchen sinks

A single conversation that runs for days feels like a colleague who finally knows the project, and starting over feels like throwing that away. The reality is closer to the opposite. Anthropic's guidance for Claude Code names this failure the kitchen sink session: one everything-conversation whose irrelevant history actively degrades results [14].

What the AI "knows" in a stale session includes every dead end that was tried and abandoned, every tangent, and every correction along the way, all competing for the same attention budget as the current task. Long sessions also explain a common mystery. When a conversation nears its limit, many tools summarize it and continue from the summary, which is why the AI can seem to forget what happened an hour ago [15].

The fix costs nothing: start a fresh conversation for each new task, and carry forward only the facts and references the next task actually needs.

How AI memory works

Some AI tools do seem to remember. ChatGPT's custom instructions and memory carry stated facts across conversations, and coding tools like Claude Code re-read a plain project file at the start of every session. None of this is memory in the human sense: each feature is an engineered workaround that copies selected facts back into the context window, where the model can see them again.

Anthropic's demonstration of an agent playing Pokémon makes the mechanism vivid. The agent keeps tallies and maps in notes stored outside the conversation, then re-reads those notes after its context resets, rebuilding what it "knows" from a file [16]. Consumer memory features work the same way at a smaller scale, and most offer controls to switch them off.

Understanding the mechanism removes the mystery from tool differences. Whatever a tool appears to remember is just text being quietly re-supplied, and anything not written down somewhere is gone.

Pro Tip! A line earns its place in a project memory file only if removing it would cause the AI to make mistakes [17].

Is more context always better?

If the model only knows what it's given, more information should always help, or so the reasonable instinct goes. The research disagrees. Anthropic's guidance is that good context engineering means finding the smallest possible set of high-signal tokens that maximize the likelihood of the desired outcome, and that context must be treated as a finite resource with diminishing marginal returns [18].

The overload failure appears even with genuinely useful material. Nielsen Norman Group flags that long code snippets can overload the model's context window and cause performance issues [19], and Claude Code's documentation warns that bloated memory files cause the model to ignore actual instructions [20]. Bigger context windows won't dissolve the trade-off either; Anthropic expects windows of all sizes to face pollution and relevance concerns for the foreseeable future, because the binding constraint is attention, not storage.

The skill is curation rather than accumulation: everything the task needs, nothing it doesn't.