YOLO vibe coding is useful for prototypes, personal projects, and learning, but it is not a long-term approach for production code.
2
Structured vibe coding adds templates, instructions, custom tools, and consistent technology choices so AI output fits a team's codebase.
3
Spec-driven development scales the workflow by starting with a specification, making a plan, and then implementing it with reusable prompts, MCP tools, and task-specific context.
Summary
Harald Kirshner presents a progression from fast, disposable AI coding to workflows that can work in enterprise codebases. YOLO vibe coding focuses on outcomes, auto-accepts changes, and uses resets when things go wrong. Kirshner says it is useful for rapid prototypes, proof-of-concepts, personal projects, and building intuition about what AI can do. Structured vibe coding adds a shared template, technology conventions, workspace instructions, reusable prompts, and custom tools through MCP. These controls help developers get output that matches internal standards, including less common frameworks. He then describes practices for larger systems: use codebase-specific instructions, expose problems and tasks from VS Code, commit working code often, pause the agent for review, and use spec-driven development. In that final workflow, the developer starts with a specification, creates a plan, and implements the plan with additional tools and context.
YOLO vibe coding is useful for exploration but should not be treated as production practice
Kirshner describes the first stage as the fast, chaotic form of vibe coding seen in many demos. It focuses on speed, instant feedback, creativity, and learning. The user talks to the AI, looks at the outcome, and may auto-accept changes without closely reading the code. If the result goes wrong, the workflow is to undo or throw the work away and continue. He gives rapid prototypes, proofs of concept, personal projects, and experiments such as building a Rust Frogger game as examples. The point is to learn what AI can do and to understand where it still fails.
Structured vibe coding uses a shared template to constrain the assistant
The next stage starts from a template with a consistent technology stack and instructions for the assistant. The template can be an internal starter repository, a container for developers, or a GitHub project that people open in VS Code. It guides Copilot toward the conventions the team already uses. Kirshner says this helps teams produce work that engineering can accept instead of rejecting because it uses the wrong design framework or structure. He gives Fluent UI as an internal choice and says a template can help an AI use that package instead of selecting something such as Tailwind.
Instructions and custom tools give the assistant context for unfamiliar code
Kirshner recommends adding instructions when the codebase uses technologies that are less common or versions that the AI handles poorly. Workspace instructions can describe conventions, while instructions for specific parts of a repository can explain what those areas do. Custom tools and MCP can provide information the model does not already have. In VS Code, access to problems and tasks gives the assistant another source of context. With task runners and linters configured, the agent can inspect command output and try to fix errors as it works. This approach makes the assistant more consistent than leaving it with an open-ended request.
Agent modes and prompts let teams package repeatable workflows
VS Code chat modes can define which tools an agent may use and what system prompt guides it. Kirshner shows a mode for test-driven development that tells the agent to write tests first, wait for review, and only then write implementation code. Teams can also create reusable prompts for recurring work, such as producing a landing page with a particular structure. These files turn individual instructions into workflows that different people can invoke across iterations. The developer still decides how the mode behaves, including when the agent must stop for confirmation.
Review and frequent commits keep agent mistakes recoverable
Kirshner advises developers to start with errors, use the available checks, and review the agent's work. He recommends committing whenever the code is in a workable state so the team can return to a known point if a later change breaks it. Developers should pause the agent and inspect what it has done instead of letting an uncertain sequence continue indefinitely. The workflow keeps the speed of AI assistance while preserving ordinary recovery points. In his phrasing, it is sad to discover that code worked before the vibe coding session and no longer works afterward.
Spec-driven development adds a planning step for large codebases
The final stage begins with a specification, followed by a plan and then implementation. Kirshner presents this as the repeated, structured workflow needed to bring vibe coding to larger systems. Prompts, MCP integrations, and task-specific tools can support each part of the process. The developer gives the agent a clearer target before code is generated, which makes the resulting work easier to fit into an existing codebase and easier to review. This is the point where the workflow moves beyond experimenting with isolated screens or small personal applications.
"And lastly, if you haven't found that little spark icon in your commit, it's really important once you start working and having workable code to keep committing the workable code."13:45
Who should watch
You are experimenting with AI-generated prototypes and need to decide when that workflow is safe to hand over to engineering.
Your team wants shared conventions for Copilot without taking away each developer's ability to steer the agent.
You maintain a large or unfamiliar repository and need practical ways to supply codebase context, tests, linters, tasks, and recovery points.
