AI Engineer World's Fair 2025
Vibe Coding at Scale: Customizing AI Assistants for Enterprise Environments - Harald Kirschner
Read the talk
Vibe Coding That Fits the Codebase
A Copilot hydration-app demo shows how open-ended prototyping develops into a repeatable enterprise workflow through templates, instructions, review gates, and specifications.
From a talk by Harald Kirschner
Before you start: Basic familiarity with VS Code, frontend project setup, and Git will help you follow the workflow.
From experiments to maintainable code
How do you keep the speed of asking an AI to build something while producing code another engineer can maintain? The environment for this walkthrough is VS Code Insiders. Harald Kirschner describes it as incorporating the team’s latest changes, with twice-daily builds, compared with the monthly stable release. These are recording-era details: his forecast of a release the following week on the 11th preceded the VS Code 1.101 release, which ultimately shipped on June 12, 2025.
The starting point is the idea Kirschner attributes to Andrej Karpathy: give yourself over to the experiment and stop thinking about the code. That freedom makes a prototype exciting. It also leaves a gap between getting a website on screen and operating it responsibly. Kirschner describes the familiar failure mode: an experiment reaches production, things gradually fall apart, and bills rise. Speed, simplification, creativity, and fast learning are useful goals, but they do not establish production readiness.
He introduces three provisional names for progressively more constrained workflows:
| Workflow | Main purpose | What constrains generation |
|---|---|---|
| YOLO vibes | Explore and learn quickly | The desired outcome |
| Structured vibes | Produce maintainable work for handoff | Stack choices and conventions |
| Spec-driven vibes | Make reliable changes in large codebases | A specification and implementation plan |
The transition is about making generated code fit its destination. Structured work puts guardrails around the model’s creativity; spec-driven work aims to preserve that fit as the codebase and the number of contributors grow. In the exploratory starting point, however, the interaction remains outcome-focused: describe what you want, preferably in natural language or speech, and judge what appears.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Accept, reset, and learn
In the exploratory loop, accepting changes automatically is part of the bargain. You ask for an outcome, inspect the result, and let the implementation accumulate without reviewing every edit. When the direction goes wrong, undo it or discard the code and start again. This works for rapid prototypes and proofs of concept because the implementation is still disposable.
It can also be a way to learn an unfamiliar stack. Kirschner’s example moves from making a Rust game to making Frogger, then to making a neon, flickering Rust Frogger. Once there is something interesting to inspect, look at the code and ask the AI to explain how it works. Personal projects occupy a similar space: he describes building an app with his children over a weekend to meet a family need, explicitly without shipping it to production. The value is exploration and understanding, without assuming a long-term maintenance commitment.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Dictating a hydration tracker
The live example begins in a new VS Code Insiders window with Copilot agent mode selected. Agent mode was not yet the default in the demonstrated build. Kirschner then shows Auto Approve, which suppresses confirmation prompts and, in that version, can be enabled for the workspace alone. He presents it with caveats as a way to keep an exploratory session moving, not as a general production setting.
The microphone provides another way to remove friction. Kirschner describes local speech recognition and notes that spoken responses can also be enabled; his shortcut for the interaction is Command+I. The privacy boundary matters: VS Code Speech supplies local transcription through an extension. Local dictation does not mean that the subsequent Copilot interaction runs entirely on the machine.
He dictates a concrete request: build a water-hydration tracking app in React and Vite, use Material UI, and follow an Apple-esque visual design. Copilot first invokes its create-new-workspace tool. An audience question establishes that this is ordinary Copilot agent mode, rather than a separate application-building product. After Kirschner chooses a location, the agent can continue inside the new workspace.
Copilot shares a high-level plan reflecting the requested stack and design, then proceeds with scaffolding and installation work while the presentation returns to the slides. Kirschner refers to install and development commands as the work continues. This is a demonstration of delegating the setup and implementation process; the recording does not establish a completed, tested, or deployed hydration app.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Model choice and the iteration controls
Asked which model is doing the work, Kirschner identifies Claude Sonnet 4, which he likes for this UI example. His experience running the same request with different models produces an informal comparison:
| Model named in the talk | Kirschner’s aesthetic impression |
|---|---|
| Claude Sonnet 4 | Good at UI, but can overuse dark backgrounds, gradients, and large lettering |
| 4.1 | More like a wireframe |
| 2.5 Pro | A distinctive, variable design sense |
These are observations about generated designs, not benchmark results. His warning about Sonnet is especially concrete: insufficient direction can yield something resembling a blockchain landing page, regardless of the application’s actual purpose.
The surrounding controls make the prototype easier to steer and recover:
- Workspace creation: The new-workspace flow reduces setup work, but requesting a new app from inside an existing project can trigger it unexpectedly.
- Visual context: Kirschner describes opening the result in VS Code’s browser preview and selecting specific page elements to guide subsequent changes. He does not demonstrate a finished hydration app using this interaction.
- Continuous updates: Delayed auto-accept and auto-save can keep changes flowing into a running preview.
- Recovery: Undo and revert let the developer back out of an unwanted direction.
Together with agent mode and voice dictation, these controls support a short cycle of asking, inspecting, and revising.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
What the agent can see when something fails
An audience question exposes an important boundary: how does the agent learn about errors? For failed terminal commands, Kirschner explains a direct feedback loop. The agent reads command output, identifies a problem such as a missing dependency, and can issue another command to address it. His example is a change in the shadcn installation process: if an error tells the agent to use a different package, that message can guide the next attempt.
The audience then distinguishes browser-console errors from terminal output. Kirschner responds by discussing background terminals and ongoing work to make their output discoverable. That does not establish comprehensive browser-console visibility. An error can guide the agent only if it reaches the agent’s context. Selecting a browser element and reading a failed terminal command provide different kinds of evidence; neither should be assumed to capture every runtime failure.
This is why open-ended experimentation has value beyond the prototype itself. It builds a personal baseline for what the AI handles well, where it struggles, and how much steering it needs. Kirschner chooses React and Vite because they provide familiar, stable grounding for the demo. With newer frameworks, he recommends being explicit about where the documentation lives and how the agent should consult it. Treat the work like a whiteboard: erase an approach, restart, or refine one part, while deliberately learning from each iteration.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Put the enterprise defaults in the starting point
Structured work begins by replacing the blank canvas with a shared template. A repository or development container can already contain the internal stack. A contributor checks it out, opens it in VS Code, enables agent and voice modes, and starts exploring. Even a nontechnical teammate working on UX can begin from the same foundations as engineering. The template carries instructions that guide Copilot toward the team’s existing conventions.
Custom tools, including MCP integrations, extend that foundation by giving the agent access to information and context it would otherwise lack. The UI-library choice illustrates the difference. The hydration prompt explicitly requested Material UI; without that constraint, the model might have selected another framework, such as Tailwind. In an organization using Fluent UI, the template can instead specify Fluent UI and where to obtain its package. A repeated architectural decision becomes part of the starting context rather than something every contributor must remember to request.
The intended result is a greenfield prototype that engineering can accept without rejecting its basic stack choices. Extra instructions also help when a framework or version is less familiar to the model. Kirschner uses a particular Spring Boot version as an example: give the agent the missing guidance instead of expecting its default knowledge to match the project.
For the customization walkthrough, he opens the Frontend Vibes Template under his digitarald GitHub account. This is a separate template example from the hydration app being generated in the background. The focus now shifts from requesting an application to defining the environment in which future requests will run.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Encode the workflow and its approval boundary
The first customization is a chat mode. In the demonstrated version, files under .github/chatmodes define the mode’s instructions and available tools, and the developer selects that mode in place of the usual agent behavior. VS Code later renamed custom chat modes to custom agents and introduced .github/agents; the recording uses the earlier terminology and directory.
Kirschner’s example mode applies test-driven development. The red, green, and refactor framing becomes a concrete interaction sequence:
- Have the agent write tests first.
- Pause for the developer to review those tests and explicitly confirm that implementation should proceed.
- Have the agent write the implementation and make the tests pass, with refactoring as part of the workflow.
The approval boundary sits before implementation. Kirschner prefers reviewing the proposed tests because they are easier for him to assess than reviewing all the generated code afterward. The mode describes how the agent should work; the presentation does not show this test sequence being executed to completion.
Reusable prompts serve a different purpose: they package tasks that a team repeats. A design team needing micro-landing pages can reuse a prompt defining how those pages should be structured across successive requests. Instruction files under .github/instructions supply another layer, explaining particular areas of the codebase. Modes define workflow behavior, prompts define repeatable requests, and instructions supply the local conventions those requests must respect.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Preserve working states, then scale the plan
The final layer connects customization to the development feedback already present in the workspace. Kirschner recommends workspace instructions and reusable prompts, with instructions applied dynamically to the relevant parts of the codebase. MCP can bring in further context and tools, although it is not demonstrated here; he points to his companion Full Spec MCP talk for those examples.
Configured VS Code tasks, linters, and the Problems view give the agent evidence of mistakes as it works. That turns existing development checks into corrective context: generated code produces diagnostics, and those diagnostics can guide the next edit. Once the code reaches a working state, preserve it in a commit. Kirschner points out the commit UI’s sparkle control, but the substantive practice is frequent checkpoints so a later experiment does not destroy the last recoverable version. Review changes, begin with reported errors, and pause the agent when inspection is needed.
The closing extension is specification → plan → implementation. Start by describing the required change, turn that specification into a plan, and then implement the plan. Kirschner presents this briefly as the direction for larger codebases, supported by reusable prompts, additional MCP integrations, and tools tailored to the task. The same ability to generate code remains, but the work now proceeds inside an explicit account of what should change and how it should fit.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Resources
From the talk
Kirschner’s public frontend template, with a Next.js starter and workspace configuration.
Kirschner’s companion presentation on richer MCP capabilities through VS Code examples.
Further reading
- VS Code 1.101: custom chat modes and MCPDocumentation
Historical release notes covering custom chat modes and expanded MCP support.
Explains reusable prompts, diagnostic feedback, workspace creation and selecting browser elements as chat context.
Updates since the talk
- From chat modes to custom agentsDocumentation
Documents the later custom-agent terminology and configuration directory.
Read the complete timestamped transcript
- 0:00
[upbeat music] Uh, gonna dive right in, no introductions.
- 0:17
Um, if you wanna follow along, get out your VS Code. Uh, some of the things I'm showing are VS Code Insiders. Who's an Insiders user? Anybody? Oh, I gotta explain that.
- 0:26
So Insiders is our pre-release that's built basically by whatever the build- the team landed the day before. It's gonna release actually twice a day, um, and it has all the latest things we're working on.
- 0:39
Uh, VS Code otherwise releases on a monthly basis. The next release is coming up next week on the 11th. So,
- 0:46
uh, who has done vibe coding? Anybody? Some, some. Who has negative feelings about vibe coding?
- 0:57
Okay, some. Uh, so yeah, it's, it's... We wanna fully give into the vibes in this presentation. Uh, it's gonna be a lot of screenshot-able slides to bring home to your team, so get your phones out now.
- 1:08
We're gonna embrace exponentials and forget that code even exists, how Andrej Karpathy created that vibe coding idea.
- 1:16
So vibe coding in itself and why it, well, it has these negative connotations. It starts in this fun chaos mode. I think it's part of the journey, what I'm presenting, looking at the clock and 13 minutes and 40 seconds, is how we get to this other side of professional zen vibes.
- 1:33
And to break it down a bit, this initial vibe coding, what you see most people do on YouTube when they sh- work on websites and ship them to production and then wonder why everything is slowly falling apart and their, their builds go up, that's the YOLO vibe coding and not meant to ship to production.
- 1:52
It's about speed in simplification. There's creativity in there. And it's really about this fast learning. Hopefully, I can highlight that.
- 2:01
Then next, uh, and these are all made-up terms. This is a [laughs] ever-evolving space. You can find-- If you have better words, please bring them to me. But structured vibes br- brings guardrails to how these things actually act.
- 2:13
And if you have an LM in this first space, it will just do creative things. Guardrails add it to, uh, br- en- enter this state of maintainability and balance it to bring you some more sustainable code in the end.
- 2:26
YOLO vibes are not meant to be used in a long term. Structured vibes are what, where you bring actually the, the enterprise state in, in the end that somebody, you feel comfortable handing it over.
- 2:38
And lastly, we have the spec-driven vibes, where I think most of you probably wanna end up with. And that's where vibes, the idea of vibe coding, scales up to large code bases with scale and reliability and really that, that velocity of everybody feeling the vibes and generating code, but in a-- generating code in a way that, that
- 2:57
fits into the code base. So quick YOLO, uh, outliner. Um, as Karpathy termed it, it's all about the outcomes. You don't look at code. You iterate using language. Best even talk to the AI.
- 3:12
Then auto-accepting is really part of it. You don't wanna-- You talk to the AI, you look at what it creates, and all the rest just lands. Um, if it ever goes wrong, you just reset everything completely.
- 3:23
You throw out the code or you undo, and you keep going. And there is a place for YOLO vibe coding. It's not just weird weekend things. It's rapid prototyping and proof of concept.
- 3:34
You just wanna explore. It's where creativity really shines, and you can focus on the outcome, and that's, that's a thing where vibe coding really shines. And while you do it, you can learn.
- 3:44
You can try something in a Rust code base. Make a Rust game. Make a Rust Frogger. Try a different stack. Make a neon flickering Rust Frogger. Just-- And then look at the code in the end, like how do games work actually in Rust?
- 3:59
Have AI explain the code back to you. And lastly, personal projects is, uh, where we see it most. Just over the weekend, my kids needed an app to do X, and we build it together, and now we have an app to do X.
- 4:11
And I'm not shipping it to production, but it's my app.
- 4:16
So we can do some demos. I think the easiest way to show it off, um, just open a new VS Code window. This is my Insiders. Uh, if you haven't done it-- Oh, I have an update pending.
- 4:24
Oh, this is Insider, so it's every day something new. I'm excited. But not updating now. Okay, um, in--
- 4:31
So make sure you're in agent mode, which right now isn't yet the default. We're working on that. Uh- We don't see it. Oh, shoot. Dun, dun, dun. Same problem, I guess.
- 4:43
Auto sharing to... Don't monitor. Change. W- Entire screen.
- 4:55
Ta-da. Okay. Thank you. Um, yeah. So let's start with the don't care about the code, and one way to do this is Auto Approve. If you look at chat Auto Approve, it's a, with caveats, cool option.
- 5:10
Um, and you can enable it also for, for example, your workspace only. Uh, but Auto Approve allows you to avoid all these confirmation buttons that the chat otherwise annoyingly throws at you while you're trying to vibe.
- 5:23
So while we're here, let's start this. Um, you see this little microphone button down here, and that is built in to VS Code. It's actually a local model. Nothing leaves your machine, and it's really, uh, it's, it's a great way to just chat with the AI.
- 5:38
I-- You can actually set it back that it responds everything back to you. Let's try the, uh, let's make our first app and then go back to the slides 'cause we wanna just make Copilot vibe what we ask for.
- 5:50
So, um, actually, the shortcut is, for me, is Command+I. Like that one.
- 5:56
Let's make an app for, uh, water hydration tracking in React and Vite. It should use Material UI and follow nice Apple-esque design principles. So yeah. Thank you.
- 6:10
Okay, and off it goes. So what, what you see now first is actually we have a create new workspace tool which lets you vibe code, um, a little bit easier.
- 6:20
It's... Let's do my-
- 6:22
Is this, uh, just Copilot or is this something else?
- 6:25
Just Copilot.
- 6:26
Okay.
- 6:26
Yeah, the Copilot agent mode. It comes with, with that tool. So demo one two, whatever. [laughs] It's vibe coding, so we don't care about the code,
- 6:36
but it has to be somewhere. Okay. Um, now because we have the repo, or workspace, it will just continue. And now it will actually just see how it starts it off.
- 6:47
Create a React workspace, water hydration tracking app, Material UI, Apple S design. It made a plan in the background, and now it shares the Hyro plan with us, and it goes off.
- 6:57
So we can go back to the slides and not care about the code.
- 7:02
Uh, npm install, npm dev. So I trust it. It will do stuff. [laughs]
- 7:06
And the model used is the one that was at the bottom?
- 7:09
Yes. Yeah. So this is using Claude Sonnet 4, which I, I found really good at, um, UI. I, I actually ran the same demo with different models. 4.1 makes it look very wireframey.
- 7:18
Uh, 2.5 Pro has a interesting design sense where it always looks somewhat different. And Claude Sonnet makes it always look like a blockchain landing page, uh, if you make it wrong. [laughs]
- 7:29
So, so lots of gradients and dark and big letters.
- 7:34
So to kind of as we... Seven minutes. So we have, uh, Yolo Toolbox is UH mode. Um, there's a new workspace flow that's really interesting, so if you wa- haven't tried it out yet.
- 7:43
Um, it can also trip you off if you ask for something, a new app in an existing project. Make sure sh- make sure you... if you hit that. Voice dictation built in.
- 7:51
Visual context I might get to showing around. So once it actually, it starts finishing, it will open up the page in browser preview in VS Code, and I can actually select specific elements.
- 8:01
And then the auto-accept, uh, option, there's another auto-accept after delay if you don't have that on in VS Code. There's an auto-save that I really like to drive any live updates in the background that are running.
- 8:12
And the undo and revert I quickly show up here. If anything goes wrong, there's always these buttons up here for undo and going back. So see where it is.
- 8:22
Still installing. Our beautiful Wi-Fi making demos easier. Um-
- 8:29
It's working. With this approach, so how do you get console errors and things like that? Are you able to-
- 8:34
Yes. Actually, when it-
- 8:35
Yeah
- 8:35
... when this is runs, and it runs in the terminal commands, and the terminal commands fail, it will actually look at the output.
- 8:40
Okay.
- 8:40
So if there's any, any dependencies missing, it will go off and install them. It's still like shadcn had some changes in how you install it, for example. It will figure out because the error message is, "Use this package instead," and the next command will use it right.
- 8:52
Yeah, but for example, there are console errors that do not show up in the terminal.
- 8:56
Terminal. Sometimes it run things in the background terminal, but there's on- ongoing fixes to make it basically always find it. Okay, let's keep going. Um,
- 9:05
next one, while runs. Um, it's use vibe co- use a little vibe code. So I really tried out, uh, embrace the exponentials to build that AI intuition. Like what is AI good at?
- 9:17
What AI can't do yet? And find that for yourself, just baseline what AI can do. And that's where Yolo vibe coding with like a very open canvas and being able to steer AI is this extremely powerful skill to inform all of other AI usage.
- 9:33
Then the second one is use known frameworks. I picked React and Vite in my demo because it gives a nice grounding, and it's something that hasn't changed in a while.
- 9:40
So that's a good way. If you use any, any new ones, you wanna be more explicit about how to read the docs and where to find information. And lastly, it's all about it- iteration.
- 9:50
So it's a whiteboard. You wanna, uh, wipe things off completely. You wanna start from scratch. You wanna work on specific items. But really about like having this, this iterative workflow outlined.
- 10:01
Quick check-in. Still working on some files. Okay, we keep going. So structured vibe coding, and that's where we bring in a template, and that template comes with a consistent tech stack, and that could be your internal stack.
- 10:14
It could be a container that you give to developers. So if, if you wanna work on UX, um, bring this template in, and you can just start vibing. That could be even for non-technical people.
- 10:24
Just check out this repo or work from this template on GitHub, open in VS Code, engage agent mode and voice mode, and start vibing. But because it's a template, it comes with this consistent tech stack, and it comes with instructions to guide, uh, the Copilot flow onto specific conventions that you're already running with.
- 10:46
And then lastly, we want, like, custom tools using MCP and other things to make sure, like, if it needs information or needs more context, that can that get. And that's really more high-- more reliable and more consistent than Yolo mode.
- 10:58
If you ask Yolo mode, and if it wouldn't have given it Material UI, it might have picked any other design framework. It might have went with Tailwind. So and that allows you to internally we use Fluent UI.
- 11:08
So you're gonna use Fluent UI. This is where you get the package, and just it, it's outlined, and it's clear. And so it's really great for bootstrapping these screen-filled projects because you end up with something people can hand over to engineering, and engineering doesn't say like, "This is totally not what we're doing."
- 11:23
Um, and this thing also, it's, it's better at the off mainstream, like anything that's non- not popular, like Spring Boot, whatever latest version you have that the AI struggles with.
- 11:32
You can add more instructions on top that it gets it right more often.
- 11:38
Gonna show a quick how does it look like. Still vibing.
- 11:44
Yeah, I think it's mostly internet speed here making it slow. So let's figure out, um... This is a nice repo. It's actually on the, on the internet. Um, if you go to [REDACTED:url],
- 11:58
and then I put it up. I think it's still on there.
- 12:02
Frontend Vibes Template. So let's zoom in if you want to take a screenshot for later.
- 12:07
I-- Well, now you know this is-
- 12:08
Again?
- 12:09
Yeah
- 12:11
How's this screen sharing working? I don't know. I'm not technical. Um, is this entire screen, right? So- It says you're one on desktop too. Okay. Yeah, I think e- each time I switch back to PowerPoint, it, it tries to do the mode screen again.
- 12:25
Okay. So, uh- Where's the GitHub again? GitHub again.
- 12:33
Sharing the vibes here. Two minutes. Okay. We got it good. Um, yeah, so that's the nice template. Just gonna do a quick roundup. So one, we have chat modes.
- 12:41
That's what I'm highlighted here on the left, GitHub dot, uh, root folder, chat modes, and you can define already tools. You define what, what tools are in the mode, and what's the system prompt, and then they show up down here.
- 12:53
Actually, you can switch out agent. It's a new agent that's now doing test-driven development for you. And that description here I wrote in another demo [laughs] earlier about how to do test-driven development.
- 13:04
I didn't know there's a red, green, and, and, uh, for anything else. So that's up to you how you define that mode. But this basically now guides it. You have to write tests first, and then you write code, and then it has to pass.
- 13:16
And only as- only move to writing code after I confirm, because I wanna review the test, and that's much easier for review to me. Um, you can also create prompts, and that's a way for your team to create these reusable tasks that are then used across different iterations.
- 13:29
It could be a new landing page for your design team. Like, we need a new micro-landing page. This is how you structure it, and then they can just, just create it.
- 13:37
And lastly, instructions. Those are new. Those are in .github/instructions, and those can outline what specific parts of the code base do.
- 13:46
So to go back to the slides. Yeah. The, the thing again. So you wanna bring in workspace instructions. There's a good document on VS Code documentation on customization. If you wanna go deeper, there's, um, the instructions files I showed and prompts.
- 14:02
You wanna make them dynamic for specific parts of the code base, and you wanna start bringing MCP. Couldn't show off MCP right now because we've run out of time.
- 14:09
Um, check out my MCP talk from the MCP track if you wanna see some of those demos. Um, also VS Code has access to problems and tasks, so if you have your task runner set up in VS Code and your linters properly, it will actually start fixing code as it makes mistakes, which is a really powerful context
- 14:27
to have for the AI. And lastly, if you haven't found that little spark like in any commit, it's really important once you start working and having workable code to keep committing the, that workable code so you don't get into weird areas where it worked before and now my vibe coding broke it, and that's always sad.
- 14:45
So review's important. Um, always says on these, instructions are important. Start with errors. Committing is important, so commit often. Pause the agent to inspect.
- 14:57
Lastly, in ten seconds, spec-driven really brings this often repeated idea, which you'll see here as well. You start with a spec, you make a plan, and then you implement the plan.
- 15:07
And that really brings it up to the large scale. And the features we have here I showed off, prompts, more MCPs, and more task-specific tools that you can bring in.
- 15:17
And we're out. Happy to chat more outside. [outro music]