AI
What Copilot Reads Before You Say Anything
Copilot’s context is wider than most developers realize. The agent pulls from a vector-based semantic search index, so a query for “authentication” finds a function named login without explicit filename matches. It also reads running task output, test results from VS Code’s built-in test runner, and linting errors from any installed language server. Each feeds the agent feedback after every edit.
Missing language extensions mean missing red squiggles, which means the agent works on false assumptions. Kirschner called out accessibility linting specifically: any extension that flags non-compliant markup gives the agent an additional signal at zero extra cost.
Copilot Instructions as a Codebase Mini-Map
The VS Code team stores a .github/copilot-instructions file in their public repo at github.com/microsoft/vscode. Kirschner called it:
“It’s really, at its core, a mini map of your code base.” — Harald Kirschner
It tells the agent where things live, which tasks to run after each edit, and how to run tests. Fewer turns spent on discovery.
Beyond that, domain-specific instruction files handle recurring errors. The VS Code team added one for their observable pattern after Copilot kept inventing APIs that didn’t exist. The agent loads the file only when it needs that context, keeping everything else out of the window.
Prompts, Custom Agents, and Sub-Agent Delegation
Reusable prompts encode chores you keep doing manually. Kirschner’s personal set includes one that takes staged changes, writes a commit message, and pushes. Another opens a PR. Custom agents go further: they constrain which tools the agent accesses and chain multiple steps into a workflow with handoffs between them.
Sub-agents solve context bloat. A sub-agent runs its own search loop and returns only the answer, keeping the parent conversation from inflating. Kirschner uses this pattern for all research prompts, which lets long agentic sessions run without exhausting the context window.
Test-Driven Development as a Composable Workflow
Kirschner walked through the TDD red/green/refactor demo (13:00) live. Three linked prompts form a chain: TDD red writes a failing test, TDD green adds minimum implementation, and a refactor prompt polishes the code. Each ends with a handoff so the developer reviews before the next prompt runs.
The pause at the test-review step matters. The test file acts as a contract: a developer who reads it before implementation catches misunderstandings when they cost nothing to fix.
Scoped Planning and Visual Iteration
VS Code’s built-in Plan Mode is a starting point, not a constraint. Kirschner wrote a “plan spike” prompt that restricts the agent to architectural proof-of-concept only: no test writing, no full feature build, just the backend design decisions that need reasoning before anything else gets built.
A separate designer mode isolates UI iteration from implementation. Both patterns follow the same logic: narrow what the agent reasons about at each step, so it focuses on what actually needs to be figured out at that moment.
Notable Quotes
It’s really, at its core, a mini map of your code base. Harald Kirschner · ▶ 5:42
Don’t give it a TypeScript expert. Harald Kirschner · ▶ 11:03
So think about what you can automate in multi-step flows, where the human Harald Kirschner · ▶ 14:12
Key Takeaways
- Set up language servers, linters, and tasks in VS Code — the agent reads all of them automatically.
- A copilot-instructions file is a standing brief that saves the agent from re-discovering your repo on every run.
- Split multi-step work into composable prompt modes with explicit handoffs so humans review at the right moments.