Stop Describing Your Codebase. Show It to the Agent.

You describe your project to the agent in English. "We use React with TypeScript, the API is REST, the auth is JWT, the styles are in Tailwind." The agent nods and produces generic code that does not match any of it.

You describe it again, more carefully. Same result. The agent is not being stubborn. It is being asked to remember something it has no way to verify.

Stop describing. Show.

The two moves that actually work

There are two ways to put real information into an agent's context window instead of a paraphrase. Both take ten seconds.

Mention a file with @

Type @ followed by a filename. The agent reads the file and its contents become part of the context window. Now the agent is not guessing your patterns. It is reading them.

Want the agent to follow your existing API client pattern? Mention the file where that pattern lives. Want it to match your component structure? Mention a representative component. The agent will produce output that follows the conventions in that file because those conventions are now in front of it.

A few practical details. Binary files are skipped. Images are attached as images. Text files come through as text, truncated at 500 lines and 2KB per line to avoid blowing the context budget. If the truncated part matters, the agent will usually read the rest on its own.

Run a shell command with $

Type $ followed by a terminal command. The command runs. The output lands in the context window.

This is how you give the agent current state without copying and pasting. Test results. Git log. Directory listings. Environment variables. The output of git diff. The exit code of the build you just ran.

If you want the agent to understand the current state of the project, do not describe the state. Run the command that shows the state.

Why showing beats telling

A description is a lossy compression of the actual file. You write "we use JWT auth" and the agent fills in the gaps from training data. Those gaps include assumptions about token storage, refresh logic, header format, and error handling that probably do not match your implementation.

When you mention the file, the agent sees the actual implementation. No assumptions. No gaps. The output matches your code because your code is the input.

The same applies to live state. "The build is broken" tells the agent nothing. $ pnpm build shows the agent exactly which line is failing.

Patterns that earn their keep

Mention the file that already does what you want done. If you want a new API endpoint, mention an existing endpoint. The agent will follow the existing pattern.

Mention the test file alongside the source file. The agent sees the contract the code is supposed to satisfy, not just the code that happens to exist.

Run git log --oneline -10 before asking about history. Run git diff before asking about uncommitted changes. Run the test command before asking why something does not work.

The pattern in every case: do not paraphrase what the agent can read directly.

When description still wins

Showing is not always better. If the file is huge and only one function matters, mentioning the file floods the context with noise. If the live state is sensitive (production secrets, customer data), running the command is the wrong move.

In those cases, paste the specific snippet or the specific output. Targeted showing beats blanket showing.

But the default should be show. Most of the time, the agent's output is generic because the input was generic. Mention the file. Run the command. Watch the output change.