Real World Development with GitHub Copilot and VS Code — Harald Kirschner, Christopher Harrison

You build an app in a day, put it online and make money. Then it leaks data, and the experiment stops being fun. That is the opening problem behind Harald Kirschner’s progression from outcome-first coding to development with guardrails: as agents work longer and generate more code, what lets an engineer trust the result? He points to an Anthropic conference chart as motivation, but the practical question is how to add safeguards without losing the speed of experimentation.

These stages describe different needs. A throwaway experiment can prioritize immediate feedback; a product that someone else must maintain needs more structure around how the agent works.

The first stage stays almost entirely in natural language: request something, accept changes, inspect the output and ask for another attempt when it goes wrong. That makes sense for proofs of concept and UX mockups that help nontechnical colleagues communicate an idea in a meeting. It also creates a useful learning route. During a live game-building exercise at Build, Kirschner returned to Three.js after years away; once the generated application worked, he could inspect its structure and learn how it produced shapes. A water tracker or a weekend project with children can serve the same purpose: create something tangible, then explore it.

The prototype begins in a new VS Code window, opened with Command+Shift+N, with no folder selected and Copilot alongside the Explorer. Kirschner uses Claude Sonnet 4, his preferred model for frontend work. The recording mixes Stable and daily Insiders builds, and several controls differ across attendees’ installations; the steps here follow the demonstrated interface.

Switch Copilot to Agent mode before looking for the tools picker. Several attendees begin in Ask mode and cannot find it. Kirschner initially wants to disable Scaffold New Workspace so the model can produce a simple HTML experiment without a full project setup. When that control proves difficult to locate across versions, he changes course and keeps the scaffolding tool enabled. That choice determines the shape of the next demonstration.

The request supplies a familiar stack—React and Vite—and a loose product description: a water-consumption tracker with a large, accessible interface. Kirschner adds Apple-inspired design guidance and Material UI. He deliberately leaves button counts, mobile behavior and CSS choices unspecified. Popular frameworks reduce the amount of unfamiliar territory the model must navigate, while the broad design request exposes the assumptions it makes.

The New Workspace flow turns that request into a project:

1. Submit the app request from the empty window.
2. Continue when Copilot asks for an empty folder.
3. Create and open vibing-at-ai-engineering.
4. Let the agent continue scaffolding inside that folder.

The new-project command handles the initial stack and setup decisions that otherwise interrupt a greenfield experiment.

Next comes a consequential setting: search Settings for approve, select Workspace rather than User scope, and enable automatic approval. Kirschner explicitly cautions that this removes the Continue confirmations for tool actions. Workspace scope limits where the setting applies; it does not make every command safe. The agent’s visible plan includes installing Material UI, building the tracker and applying the requested design direction.

The live setup exposes two sources of confusion. Attendees reach different settings screens through different entry points, and the existing conversation continues asking for confirmation. Kirschner attributes the latter to enabling auto-approval after the chat began. He also distinguishes the more granular MCP permissions already available—such as approval for a session or workspace—from the broader automatic-approval setting.

While the first app runs, Kirschner opens another window, checks automatic approval before starting and requests a Fluent design variant in a second folder. This is where cheap generation becomes useful for design exploration: ask for several ways to solve the same problem, such as three signup flows, and compare what appears. The second session runs without repeated confirmations, although managing two windows makes it harder to remember which process belongs to which app. The agent also selects an incorrect Fluent dependency and attempts to repair it.

For attendees still searching, Command+, opens Settings, where they can search for Auto-approve. But finding the switch is only the usability problem. An audience member wants a middle ground between approving every command and approving everything. Kirschner explains why terminal permissions are difficult: a command can chain other commands, so allowing a familiar command name does not necessarily constrain everything the shell will execute. Finer terminal allowlisting is work in progress in this demonstration.

The generated project contains App.tsx, App.css and Copilot instructions. Those instructions translate the loose Apple-inspired request into a clean, minimal, intuitive and consistent interface. They also record choices the user never explicitly made, including CSS and responsive design. Generated instructions make some of the model’s assumptions visible, even when the initial request leaves much of the implementation open. In this run, the scaffolding flow creates them without another prompt.

The first Hydration Tracker presents daily progress, a quick-add control for 500 milliliters and plus/minus adjustments. Attendees obtain different designs from similar requests. Kirschner uses those variations to explore model design sense and praises Claude’s icons and colors. At this point, his judgment is still based on the interface and its behavior: he has not inspected the CSS, TSX or state-management approach.

To animate the progress header, Kirschner selects it in the rendered app and asks for particles. The selected component is identified as an MUI Paper; he does not have to know its name beforehand. The agent has started the development server with npm run dev and opened Simple Browser, the preview inside VS Code. Its injected selector can attach an element’s visual reference and HTML/CSS context to the conversation. In this attempt the element screenshot fails to attach, but the HTML and CSS arrive, giving the model a concrete target without a long positional description.

The Fluent version then provides a useful comparison. It includes goal completion and recent entries, suggesting similar assumptions about the product’s features, but Kirschner finds its appearance plainer and more corporate. The scaffolding tool also influences complexity: New Workspace tends toward npm and installed packages, while disabling it can make a single-file HTML experiment easier to obtain. Both the requested design system and the enabled tools shape the result.

An audience question about keeping up with Insiders leads to a practical distinction: release notes consolidate functionality during the release process, while daily builds are harder to track. Kirschner, who identifies himself as working on VS Code, points to release notes and entertains an AI summary or MCP server for recent changes. That summarizer remains an idea for a future demonstration.

Copilot conversations can move from the side panel into named editor tabs, sit beside the application or detach into a separate window. A detached chat can occupy another monitor and remain pinned on top. This lets the workspace emphasize the conversation and the running output while keeping code available when needed.

Kirschner then dictates a request for dark mode, a younger-audience name and a more child-friendly design. He describes Command+I as the default voice shortcut in his setup, says transcription uses a local model and points to optional spoken responses for accessibility. Hold-to-talk shortcuts can be customized; he also mentions the earlier Hey Copilot interaction. Voice, wireframe attachments, hot reload and element selection all shorten the path from a visible idea to the next request.

These controls serve different purposes. The particle animation makes the distinction tangible: Kirschner accepts the bubbles, undoes the change, restores it to look again and finally returns to the original version. Accepted edits remain reversible through the conversation’s stages.

That reversibility supports a particular style of experimentation. Give a model broad tasks to learn its design strengths and failure boundaries, use familiar frameworks such as Vite and Material, and treat the result as a whiteboard. If an experiment goes wrong, be willing to discard it and start again. This is useful precisely when preserving the implementation is less important than learning from the output.

Structured development begins by deciding which choices should stop being experiments. A starter can provide the stack, instructions and tools carrying internal knowledge. It can settle Fluent versus Material, require dark mode and responsiveness, and use an internal design system from the beginning. Nontechnical contributors can still describe what they want, but the generated work starts inside the organization’s conventions. This matters especially for internal workloads and deployment systems that are less represented in a model’s training examples.

For the structured exercise, Kirschner shares an existing starter identified as Sleep Vibes. Copilot writes a commit message, then Sync Changes sends the repository changes to GitHub. Attendees clone it and run npm install; Simple Browser: Show opens the preview. Codespaces and dev containers come up as ways to reduce setup work. An attendee informally estimates feature parity at 95%, with the remaining 5% enough to send users back to another tool. The point is the disruption caused by small incompatibilities, rather than a measured comparison of editors.

The repository turns out to already contain a Node.js dev-container configuration. Kirschner finds the earlier conversation in which he asked Copilot to inspect the codebase and update it. That is a useful companion to a starter: preserve the environment as well as the application conventions. The workshop shows repository sharing and development setup, without establishing a production deployment.

The starter’s persistent guidance lives in .github/copilot-instructions.md. Kirschner describes this Markdown file as grounding for agent, chat and inline-chat requests. His preferred starting point is small: name the frameworks and versions. That establishes the project’s technical context before adding detailed conventions, and avoids turning instructions into a redundant transcription of lint rules.

Treat that file as a team-maintained document. When an attendee asks how to standardize guidance without letting every application drift, Kirschner discusses user settings and separately shared guidance, while describing organization-level discovery and selection as a capability he wants to improve. Repository instructions should evolve as the team learns; they should not become an untouched policy file.

Instructions can also guide tool choice. The starter directs frontend QA toward Playwright MCP, research toward Perplexity and library documentation toward Context7. Kirschner supplies known Context7 library IDs so the agent need not repeatedly resolve them. This is specific operational knowledge: which tool to use for a task, and which lookup can be skipped because the project already knows the answer.

For narrower guidance, .github/instructions/name.instructions.md combines Markdown with front matter and a file glob. A compact TypeScript/React rule could look like this:

---
applyTo: "**/*.{ts,tsx}"
---
Use the React and TypeScript conventions already present in this project.
Keep frontend changes consistent with the existing design system.

In the demonstrated version, the matching file must actually be in the conversation’s context. Merely having a TypeScript file somewhere in the repository is insufficient, and an open editor file needs its context enabled. Kirschner identifies this as a limitation being worked on. The rule’s existence and its activation are separate things to check.

A well-crafted test-writing prompt should not require finding an old Slack message every time someone needs it. Reusable prompts put that task into the workspace or a user’s configuration, where the slash menu can invoke it. Kirschner also shows manually attaching instructions and a new prompt-configuration entry point. One of his own prompts bootstraps custom instructions for a project that does not have them yet; a broader prompt-sharing site remains an aspiration.

Multiple applicable instruction files can combine, so their requirements need to agree. A prompt inserts a task into the conversation and stays in that conversation’s context. This distinction becomes especially useful when an attendee asks for a stronger process: always use test-driven development.

Kirschner answers by creating a custom mode, an Insiders feature in the recording. The demonstrated repository location is .github/chatmodes; user storage is an alternative for private experiments. His rule for sharing is practical: experiment personally, then move a mode into the project once the team can trust its usefulness. He names the mode TDD and asks the AI to draft its behavior.

The requested workflow is explicit:

1. Understand the problem.
2. Write failing tests first.
3. Ask the user before implementing.
4. Implement and keep running the tests.
5. Refactor while preserving the tests.

The generated mode expresses the red/green/refactor cycle and prohibits implementation without tests. It also invents unnecessary framework details, which Kirschner notices and offers to remove. The process instructions are useful, but their generated configuration still requires inspection.

The next feature starts from a plain landing page running with npm run dev: build a GitHub issues dashboard with mock data and useful contribution metrics, without wiring it to GitHub. Kirschner selects the TDD mode for this broad request. A mode is backed by Markdown and can specify the tools the agent may use. He forecasts a Stable release the following week on the 11th; the VS Code 1.101 release notes record the eventual release as June 12, 2025.

While it runs, an audience member asks how to feed deployment errors back to Copilot without copying and pasting. The easiest route is to have Copilot run the command itself, which lets it inspect the resulting terminal output. For commands run separately, Terminal Last Command includes the output, and Terminal Selection supplies selected text. Kirschner distinguishes terminal output from the Problems view and cannot explain why those terminal context options are missing from the displayed Add Context menu.

Returning to TDD reveals why the mode initially behaved like a chat assistant: the generated configuration invented tool names and had no write access. It could describe code but could not make the intended edits. Kirschner repairs the configuration, then shows how a tools entry and the picker select actual tools for a planning prompt. Perplexity is selected for research. A persuasive workflow description cannot compensate for missing capabilities.

Tool sets address the growing list of capabilities as MCP servers accumulate. They can combine built-in and MCP tools: the editor’s own editing and codebase-search entries already group several underlying operations, including file search and grep. Kirschner’s research set combines Perplexity with Fetch. Selecting a smaller set for a particular domain reduces the number of unrelated actions the model must consider.

After the repair, the TDD run creates mock data, tests and a test utility, then attempts to run the tests. Kirschner notices a questionable interpretation of the package setup, reports that the tests are red and observes the requested confirmation pause. The demonstrated result is a tests-first stopping point awaiting permission to proceed, not a completed dashboard implementation.

Playwright MCP exposes browser automation to the agent: opening pages, interacting with them and taking screenshots. Kirschner also discusses accessibility-related inspection; access to browser accessibility information should not be confused with a completed comprehensive accessibility audit. Instead of copying a JSON configuration, he uses an Install Server link that opens VS Code through its protocol handler, much like installing an extension. The resulting server UI exposes its tools, configuration and diagnostic output.

His other examples include GitHub MCP and GistPad MCP. The demonstrated GistPad setup needs a GitHub token, but the token is not written literally into the configuration. VS Code’s inputs mechanism—also familiar from tasks.json—lets a configuration reference a prompted value. A compact input declaration has this shape:

{
  "inputs": [
    {
      "id": "github-token",
      "type": "promptString",
      "description": "GitHub token for the MCP server",
      "password": true
    }
  ]
}

The corresponding configuration value can reference ${input:github-token}. Kirschner says password inputs are prompted initially and retained encrypted in VS Code’s key storage, using Keychain on macOS. That is his explanation of the demonstrated credential handling.

GistPad uses GitHub Gists as storage for knowledge and reusable prompts. Kirschner recommends it as an example to explore because it adopts several MCP capabilities, while noting that these servers and their integrations are evolving rapidly. The distinction from the earlier starter instructions is useful: instructions carry guidance in the repository; an MCP server can provide access to another store of information or actions.

An attendee asks how to connect an already running Python MCP server, using an SSE endpoint on port 104 as a hypothetical example, rather than launching a local process through npx. The workspace configuration lives in .vscode/mcp.json and can be shared with collaborators. In the demonstrated interface, Add Server → HTTP accepts the remote endpoint; a manual entry needs a server name, an HTTP type and a URL. Autocomplete helps expose missing fields.

The transport distinction is precise even though the live explanation uses loose wording. stdio connects a client to a subprocess through standard input and output; a remote HTTP configuration connects to an endpoint. The March 2025 MCP transport specification replaced the older HTTP+SSE transport with Streamable HTTP, which can itself use SSE streams. Thus the deprecated item is the old transport, not SSE as a technology. The workshop’s HTTP setup includes compatibility with the older transport.

Starting a configured server manually checks that it works and allows the client to discover its tools. Kirschner explains that VS Code caches the discovered tool list so it does not need to start every server whenever Copilot opens. For ordinary automatic tool execution, use Agent mode. He qualifies his initial description of Ask mode by saying explicitly referenced tools can be invoked there, but the attempted Ask-mode demonstration does not succeed. Agent mode is the working path shown here.

The default models in this session come through the GitHub Copilot subscription, but Manage Models also accepts external provider configurations and API keys. Kirschner lists Anthropic, Azure, Cerebras, Gemini and Groq. His own examples include Gemma 3 running locally through Ollama and an OpenRouter entry he calls Perplexity R1, which he describes as a fine-tune of DeepSeek R1. He finds the practical capability of local models limiting even on his M4 Pro.

When an attendee cannot see an expected model, Kirschner first considers the provider’s account tier, then discusses Agent-mode filtering. In the preview integration, model availability depends on whether VS Code recognizes the provider’s tool-calling capabilities. Providers expose those capabilities differently, and the mapping is still being improved. A model missing from the Agent picker therefore does not necessarily mean the user lacks access to it at the provider.

To show what tool execution looks like, Kirschner navigates the tool list with Command+Up and Command+Down, keeps Context7 available and disables Playwright. A request can mention a particular tool or a named tool set. He asks for research into GitHub productivity metrics using the research set, which makes Perplexity and Fetch the relevant options.

The resulting call exposes the server and its input. Clicking the server reveals its origin; with approval enabled, the request arguments can be edited before sending. Here, automatic approval is still active from the earlier experiment, so the call has already gone out by the time Kirschner opens it. The _ask suffix in the Perplexity tool name is simply part of that tool’s name, unrelated to Copilot’s Ask mode.

The research includes a follow-up query. Kirschner then points to a community-dashboard specification he prepared earlier using the same pattern: research first, then use a reusable prompt to write the spec. Markdown file references can be clicked and checked for invalid paths. The prompt confines the work to the specification, asks for further research when needed and tells the agent to preserve details while updating the document.

A compact version of that document-focused task is:

Update the community-dashboard specification using the research in this conversation.
Work only on the specification; do not implement the dashboard.
Use Perplexity when additional research is needed.
Preserve existing details and incorporate the new findings into the document.

The useful boundary is the artifact being changed. Research can develop the requirements without silently turning into implementation.

MCP sampling reverses the usual direction of a model request: a server asks the client to use its language model. Kirschner describes experimental Insiders support and gives summarization as a use case, allowing information to be condensed before being returned to the main conversation. He presents it as an early capability with limited ecosystem integration.

The next audience question concerns a different uncertainty: can tool selection become deterministic? Kirschner recommends narrowing the tools available through a mode or prompt, possibly leaving only Perplexity for a research task. A user can also attach a specific tool, such as Resolve Library ID, rather than hoping a natural-language request makes the model choose it. These mechanisms reduce the action space and communicate intent more explicitly.

But the audience member’s end-user chatbot scenario exposes the remaining boundary. Restricting available tools is not the same as guaranteeing invocation. Kirschner agrees that even when the user explicitly requests a tool, the model might not call it. The controls shown improve guidance; they do not supply deterministic routing for the application.

The operational foundation extends beyond prompts. An agent can consult an existing implementation through cross-repository search; Kirschner uses the Model Context Protocol TypeScript SDK as a reference when building MCP servers. Starter templates should also configure tasks, linting and Problems integration so the agent can receive concrete feedback. During work, pause and steer the conversation, review changes and grant trust selectively to read-only tools. Refine instructions after mistakes and commit each working state so the next experiment has a reliable recovery point.

Spec-driven work adds an explicit specification and implementation plan to that foundation. MCP tools can supply database access, logs and project-tracking information; testing and debugging depend on the corresponding VS Code setup being in place. Kirschner mentions o3 for deeper reasoning, then suggests creating a specification from the project’s existing conversations. A meeting transcript is useful input only if the final decisions are clearly identified, so the generated document does not mistake every explored option for an agreed requirement.

An attendee proposes generating a spec, asking the model to critique it and arguing through omissions until it improves. Kirschner’s own Critique Idea prompt asks three questions about an idea. That moves the model’s role beyond producing code: use it to question assumptions, expose gaps and act as a design partner before implementation makes those decisions expensive to change.

The closing discussion compares this approach with planning in Cline and customizable modes in Roo. VS Code has no built-in Plan mode in the recording, but a custom mode can provide the behavior. Kirschner separates the work into three stages:

1. Specification: decide what the product should do.
2. Implementation plan: decide how to build it.
3. Implementation: execute the agreed plan.

Spending more time on the first two stages gives the agent clearer work to perform in the third.

The appropriate amount of structure depends on the task. Experiment to find where a direct request works and where writing a spec first pays off. When an answer is poor, give feedback and iterate; when a process works for the team, encode it in modes, prompts and instructions. An audience comparison with Emacs major and minor modes captures the growing overlap among those customization mechanisms, which Kirschner acknowledges still needs cleanup.

The final requirement is a codebase the agent can understand. Keep code well structured and self-explaining, plan with codebase context, and give the AI concrete examples in its guidance. Maintain the instructions and prompts as the project changes. Those practices let the workflow grow beyond a disposable hydration tracker without depending on the agent to infer every convention anew.