← All speakers

Harald Kirschner is a principal product manager at Microsoft working on Visual Studio Code and GitHub Copilot. He develops the infrastructure that helps coding agents understand real projects, use external tools, coordinate complex work, and remain under developers’ control.

From Firefox to agentic development

Kirschner began building developer tools well before generative AI: his FancyUpload plugin combined MooTools, Ajax, and Flash to improve browser-based uploads. During nine years at Mozilla, he rose to lead Firefox Developer Tools, working across debugging, browser performance, web compatibility, accessibility, and developer experience. His Mozilla writing covered faster JavaScript debugging and integrating Webhint into Firefox DevTools.

He subsequently joined Microsoft as a senior product manager for VS Code and later became a principal product manager working on VS Code and GitHub Copilot. By 2024, he was helping Copilot reason about entire repositories through local keyword indexing, semantic retrieval, reranking, and language-aware code segmentation. His approach emphasizes executable code tests, repository-based evaluations, lightweight checks on pull requests, and larger recurring test suites.

In 2025, Kirschner authored VS Code’s introduction to agent mode and the Model Context Protocol, then coauthored its announcement of full MCP specification support. His work has since expanded into multi-agent orchestration, planning interfaces, and interactive applications embedded in agent conversations.

  • Structured vibe coding: Kirschner distinguishes rapid experimentation from production-ready development. Enterprise workflows need project-specific instructions, established design systems, scoped approvals, reusable prompts, tests, linters, frequent commits, and checkpoints. For larger projects, he advocates spec-driven development: establish the specification, create an implementation plan, then delegate execution. His enterprise coding-agent demonstration shows how those constraints preserve maintainability without sacrificing rapid prototyping.
  • Context-aware coding agents: Effective assistants must understand a repository’s actual languages, dependencies, conventions, and structure. Kirschner combines sparse keyword retrieval, semantic indexing, reranking, and code-aware chunking; he judges results against real repositories and executable tests, not convincing-looking model responses.
  • Full-spectrum MCP integration: Kirschner treats MCP as infrastructure for stateful, context-sensitive collaboration, not merely a catalog of tools. Workspace roots help servers recognize a project; dynamic discovery exposes capabilities only when relevant; authorization and sampling provide controlled access to services and client-side models. His explanation of the complete MCP architecture emphasizes that excessive, unrelated tools can degrade model performance.

Read the topics behind these talks

5 conference talks

Key ideas

Scroll to read ↓

MCP can do more than expose functions: dynamic discovery, resources, sampling and user input let servers adapt as a task and its context change.

  • Why does an MCP server fail to work?
    0:00 ↗
  • Give the model the tools it needs now
    3:25 ↗
  • Make available actions follow the game state
    5:20 ↗
  • Expose artifacts and understand the workspace
    6:31 ↗
  • Request model work through the client
    7:45 ↗
  • Keep both sides of the connection current
    8:53 ↗
  • Debug the process the host launches
    9:25 ↗
  • Exercise authorization and transport before they harden
    10:28 ↗
  • Help users find servers and supply missing information
    11:40 ↗
  • Make richer implementations useful enough to spread
    12:46 ↗

Key ideas

Scroll to read ↓

A live VS Code workshop follows a disposable frontend prototype into reusable instructions, custom TDD modes, MCP tools and a workflow that separates specifications, planning and implementation.

  • When a working app stops being enough
    0:32 ↗
  • Start with an empty workspace
    5:21 ↗
  • Give the hydration tracker a stack and a design direction
    8:30 ↗
  • Run a second design experiment
    15:32 ↗
  • Inspect what the model assumed
    19:43 ↗
  • Point at the element you want to change
    22:33 ↗
  • Arrange the conversation and keep experiments reversible
    26:04 ↗
  • Put the organization’s choices into a starter
    32:12 ↗
  • Separate repository guidance from scoped rules
    38:10 ↗
  • Turn a repeated task into a prompt—and a workflow into a mode
    42:18 ↗
  • A TDD mode needs real tools
    48:33 ↗
  • Install MCP capabilities without putting tokens in the file
    56:21 ↗
  • Connect, discover and execute remote tools
    1:00:01 ↗
  • Model availability depends on tool compatibility
    1:04:47 ↗
  • Inspect a research call before turning it into a spec
    1:06:39 ↗
  • A smaller tool set does not guarantee a tool call
    1:10:05 ↗
  • Write the spec, write the plan, then implement
    1:13:30 ↗
  • Make the process—and the codebase—easier to follow
    1:18:16 ↗

Key ideas

Scroll to read ↓

Build and deploy a Python chat app, add retrieval over database rows or documents, and follow the engineering decisions that turn a working demo into a testable application.

  • Getting an application running before building everything yourself
    1:25 ↗
  • Establish the account and model connection
    6:13 ↗
  • Open the template and understand its async backend
    17:39 ↗
  • Configure the connection and make the chat app your own
    23:21 ↗
  • Deploy with a separate environment configuration
    29:22 ↗
  • Recover from region and naming constraints
    37:48 ↗
  • Ground answers in retrieved database rows
    41:18 ↗
  • Turn documents into searchable, citable chunks
    46:04 ↗
  • Understand what changes when infrastructure changes
    52:52 ↗
  • Make quality observable and testable
    56:33 ↗
  • Inspect the failures behind retrieval scores
    1:03:29 ↗
  • Update embeddings deliberately, and retrieve code by structure
    1:09:38 ↗
  • Manage prompts and budget evaluation runs
    1:15:55 ↗
  • Separate model compatibility from reliable output
    1:20:53 ↗
  • Use computation when the question spans the whole dataset
    1:25:42 ↗

Key ideas

Scroll to read ↓

A hydration tracker, a mock GitHub dashboard and a broken TDD mode show how instructions, tools and specifications turn open-ended generation into a repeatable development process.

  • What happens when you stop looking at the code?
    0:25 ↗
  • Start the hydration tracker from an empty window
    5:23 ↗
  • Approval settings change the execution loop
    11:17 ↗
  • The scaffold exposes its assumptions
    19:44 ↗
  • Point at the interface, then keep or undo the change
    22:35 ↗
  • Make the starting point carry the team's knowledge
    32:13 ↗
  • Separate project guidance from reusable tasks
    39:16 ↗
  • Encode a development sequence in a custom mode
    46:20 ↗
  • A workflow prompt cannot supply missing capabilities
    53:43 ↗
  • Install MCP capabilities without embedding credentials
    57:37 ↗
  • Connect, discover and invoke an MCP server
    1:01:12 ↗
  • Keep research in a maintained specification
    1:07:45 ↗
  • Tool access still leaves a model decision
    1:11:14 ↗
  • Make the project observable, then separate decisions from execution
    1:14:36 ↗

Key ideas

Scroll to read ↓

A Copilot hydration-app demo shows how open-ended prototyping develops into a repeatable enterprise workflow through templates, instructions, review gates, and specifications.

  • From experiments to maintainable code
    0:17 ↗
  • Accept, reset, and learn
    3:12 ↗
  • Dictating a hydration tracker
    4:16 ↗
  • Model choice and the iteration controls
    7:06 ↗
  • What the agent can see when something fails
    8:29 ↗
  • Put the enterprise defaults in the starting point
    10:01 ↗
  • Encode the workflow and its approval boundary
    12:33 ↗
  • Preserve working states, then scale the plan
    13:46 ↗

References