Vibe coding is useful for prototypes, learning, mockups, and personal projects, but professional work needs instructions, review, and version control.
2
VS Code lets teams shape Copilot with workspace instructions, scoped instructions, prompts, custom modes, tool sets, and MCP servers.
3
Developers should decide when Copilot can act independently, when it should write a plan or specification, and when a person must pause and review its work.
Summary
Harald Kirschner and Christopher Harrison demonstrate how GitHub Copilot in VS Code can support several levels of AI-assisted development. They begin with fast, low-constraint prototyping, using agent mode to create hydration-tracking apps from broad prompts. This approach is useful for mockups, learning, and exploring designs, although it can produce inconsistent code and unnecessary dependencies. The talk then moves toward structured development, where repositories include Copilot instructions, scoped rules, reusable prompts, custom modes, and selected tools. A test-driven development mode shows how a team can ask Copilot to understand a problem, write failing tests, request confirmation, and then implement the feature. The speakers also introduce MCP servers, including Playwright and Perplexity-based research, and explain how to control their tools and credentials. Their process advice is practical: commit working states often, pause when the agent behaves unexpectedly, keep instructions current, and use specifications when a task needs more control.
Fast vibe coding is useful when the goal is exploration
The speakers describe an initial stage they call "YOLO vibes," where the developer focuses on output and accepts changes quickly. They use VS Code agent mode to create a React and Vite hydration-tracking app with a broad prompt, a design preference, and few constraints. This approach can produce a working result quickly. They recommend it for rapid prototypes, proof-of-concepts, mockups, learning, and personal projects. Harald Kirschner describes learning 3JS more easily after getting generated code running, because the working example gave him something concrete to inspect and modify.
Popular frameworks reduce the guesses an agent has to make
For the first demo, the speakers choose React and Vite because they are common front-end technologies. Harald Kirschner says the model does not have to reason as much or make as many wild guesses when the stack is familiar and stable. They also give the app a design direction, first mentioning Apple design principles and then using Material Design. The resulting app includes progress tracking, buttons for adding and removing water, and a visual design produced with little detailed instruction. A second run with Fluent design produces a more corporate-looking result, showing how the same broad request can lead to different visual outcomes.
Visual references let Copilot change an interface without a long description
The demo uses VS Code's Simple Browser preview to work directly from the rendered page. A selection control lets the developer attach a particular page element as context for the current chat. Copilot receives the element's HTML and CSS description, along with the visual reference, so the user can ask for a change without explaining where the element is or how it is structured. The speakers use this to request a more animated progress header with particles. They also show that the generated change can be undone through checkpoints when the result is unwanted.
Structured vibe coding puts team rules around agent work
The structured approach keeps the speed of broad AI tasks while adding a starter repository, a consistent stack, instructions, and selected tools. The speakers describe this as a useful middle stage for companies that want non-technical people to work from approved templates. A project can already contain the team's design system, framework choices, deployment setup, and internal conventions. This prevents every new project from defaulting to whatever is most common in the model's training data. The result can be a more consistent starting point for greenfield work, while the team retains the ability to refine the rules as Copilot makes mistakes.
Repository instructions give Copilot a grounding document
The speakers show a repository instruction file at github/copilot-instructions.mmd. It is included with agent, chat, and inline chat requests, giving Copilot information about the codebase. Harald Kirschner recommends starting with a simple statement of the stack, including the frameworks and versions. Instructions can also describe syntax, formatting, conventions, and which tools to use. The speakers say the file should be treated as a team document that changes over time. They discuss the possibility of organization-level settings for shared instructions, while noting that teams may need different rules for different languages or projects.
Scoped instructions and prompts separate coding rules from reusable tasks
A newer instruction format uses front matter and glob patterns to scope rules to particular files. The speakers explain that, at the time of the demo, a relevant file may need to be in context before the scoped instruction is applied. Prompts have a different purpose. An instruction explains how Copilot should work, while a prompt packages a task that people can reuse, such as writing tests or creating a specification. Prompts can be attached manually or invoked with a slash command in chat. This gives a team a shared place for practices that might otherwise be copied through Slack.
Custom modes can encode a development method such as TDD
The speakers create a custom chat mode called TDD. Its generated rules tell Copilot to understand the problem, write failing tests first, wait for confirmation, implement the feature, and keep running tests while improving the code. They then use the mode for a GitHub issues dashboard with mock data. Copilot writes tests, finds a missing package, creates test utilities, runs the tests, and pauses because the mode asked for confirmation. The speakers also show that a custom mode can be kept in a user's folder for experimentation or stored in the repository when a team wants everyone to use it.
MCP becomes more manageable when prompts and modes limit the tools
The speakers introduce MCP through a Playwright server that can access a local browser, take screenshots, and run accessibility checks. They explain how VS Code can install MCP servers, store them in user or workspace settings, and keep credentials in secure key storage. MCP configuration supports inputs such as password values. Because adding servers can create a large tool list, the speakers recommend narrowing the available tools in a prompt or custom mode. They demonstrate a research tool set that uses Perplexity and fetch, then use it to research GitHub metrics and turn the findings into a specification.
A reliable workflow includes plans, commits, pauses, and review
The closing advice is to choose the amount of control for each task. A small change may go directly to an agent, while a larger feature may need a specification, an implementation plan, and then code. The speakers recommend committing whenever the project reaches a working state, so the developer has a safe point before Copilot makes further changes. They also advise pausing the agent when its actions are unclear, reviewing its output, and continuing with more specific feedback. Instructions should be updated when the agent makes mistakes, and codebases should be well structured and self-explaining.
"You can finally put these prompts into a place where they can just be used by everybody."42:53
Who should watch
You are evaluating whether fast AI-generated prototypes can fit into a professional development process, and want to see where the speakers draw the line between exploration and maintainable software.
Your team wants to give Copilot shared rules for a framework, testing style, internal tools, or design system instead of relying on individual prompts.
You are setting up MCP servers or custom Copilot modes in VS Code and need practical advice on tool selection, credentials, planning, and checkpoints.
