Vibe coding
The term was popularized by Andrej Karpathy in February 2025 to describe a way of programming in which the developer goes with the flow of the conversation with the AI, accepts its suggestions, tests the results, and makes corrections along the way.
In practice, vibe coding consists of telling an AI assistant what you want to build, receiving generated code, running it, pasting in errors when something fails, and continuing to iterate until you get a result that seems to work.
Its appeal is obvious: it lets you go from an idea to a working prototype in very little time. The risk arises when that initial speed is taken as a guarantee of quality.
How it works
A typical vibe coding workflow usually follows this pattern:
- The person describes an intent in natural language: "create a login screen," "make a dashboard," "add email notifications."
- The AI generates a first version of the code.
- The person runs it or tests it manually.
- If an error appears, they copy the message and give it back to the assistant.
- The AI proposes a fix.
- The cycle continues until the result seems to meet expectations.
This way of working greatly reduces initial friction. It doesn't require writing out every detail up front or designing a complete architecture before trying something out. That is why it is especially powerful when the goal is to learn, explore, or visualize a possibility.
What it is for
Vibe coding can deliver a great deal of value when used with clear intent and boundaries.
It is especially useful for:
- creating rapid prototypes;
- exploring product ideas before investing in robust development;
- building proofs of concept;
- generating low-risk internal tools;
- validating interface flows with users;
- learning a technology through executable examples;
- experimenting with alternatives before settling on a final solution.
In these cases, the priority is not to produce maintainable code but to reduce uncertainty. The question is not "Is it ready for production?" but "Does it help us learn something useful?"
Not all AI use in programming is vibe coding
Not all AI-assisted programming is vibe coding.
Using AI to generate tests, review code, explain a function, or suggest a refactoring is not necessarily vibe coding. The defining feature of vibe coding is that the conversation with the AI temporarily replaces specification, explicit design, and structured review.
The difference lies in the level of control:
| Use of AI | Main characteristic | Is it vibe coding? |
|---|---|---|
| Asking the AI to explain a function | Support for understanding | Not necessarily |
| Generating tests from defined criteria | Bounded automation | Not necessarily |
| Asking for a complete feature and accepting iterations until it works | Conversation as a construction method | Yes |
| Implementing an approved spec | Specification-guided execution | No; it is closer to Spec-Driven Development (SDD) |
Where it stops working
The problem with vibe coding is not that it is useless. The problem is that it has a ceiling. That ceiling appears when the code stops being disposable and starts to affect a real product, real users, or an architecture that must be maintained.
The main risks are the following.
Implicit requirements
When the AI is asked to "implement authentication," "add notifications," or "create a permissions system," the agent has to make many decisions that have not been made explicit.
For example:
- which security policy to apply;
- how to handle errors;
- which dependencies to use;
- which edge cases to cover;
- how to integrate with the existing system;
- which behavior should take priority when there are conflicts.
If those decisions are not in a spec, the AI resolves them with probable patterns. Sometimes it gets them right. Other times it generates a solution that works in the demo but does not fit the real context of the product.
Review burden
Generated code appears quickly, but reviewing it properly is not instantaneous. The more code the AI produces, the more effort the team needs to understand it, check it, integrate it, and detect subtle errors.
This is one of the traps of vibe coding: the initial sense of progress can hide work still awaiting review and integration.
Context Contamination
Long conversations with AI agents accumulate decisions, corrections, changes of direction, and code fragments. Over time, the context can become muddled: the AI carries over earlier assumptions, mixes versions, and loses precision about what the team actually wanted.
When this happens, continuing to iterate in the same conversation can make the solution worse rather than better.
Technical debt
Vibe coding tends to optimize for short-term visible results. This can lead to duplicated code, tightly coupled solutions, unnecessary dependencies, or hard-to-maintain structures.
Technical debt does not always show up as an immediate failure. It often surfaces later, when the team tries to evolve the prototype, integrate it into the product, or fix bugs that the first demo did not reveal.
Security
AI-generated code can look correct and still introduce vulnerabilities, poor secrets management practices, insufficient validation, or problematic dependencies.
That is why vibe coding should not be used for changes affecting authentication, permissions, personal data, payments, security, or critical infrastructure without a rigorous technical review.
Relationship to the dual-track model
In Scrum teams with AI, vibe coding fits well as part of a dual-track model.
| Track | Purpose | Level of rigor | Expected outcome |
|---|---|---|---|
| Fast track: vibe coding | Validate ideas, explore alternatives, and learn quickly. | Low or medium. Code quality is secondary. | Prototype, learning, or evidence to support a decision. |
| Robust track: vibe engineering | Build production code. | High. Specs, review, testing, and a reinforced Definition of Done are applied. | Maintainable, secure, and releasable increment. |
The fast lane is not a sloppy version of the robust lane. It has a different purpose. Its value lies in learning early, not in skipping quality.
When to move from vibe coding to vibe engineering
An idea explored through vibe coding should move to a more robust approach when:
- the hypothesis has been validated with relevant users or stakeholders;
- the prototype shows enough value to justify investing in production;
- the code will need to be maintained;
- the feature affects important parts of the product;
- there are clear requirements that can now be turned into a spec;
- the technical, security, or business risk justifies a formal review.
At that point, the prudent course is usually not to "clean up the prototype a bit," but to decide what should be kept as learning and what should be rebuilt with rigor.
Vibe coding in Scrum with AI
In Scrum with AI, vibe coding can help accelerate discovery and validation, but it must be managed transparently.
A prototype built through vibe coding can be presented at a Sprint Review as evidence of learning, but it should not be mistaken for a releasable increment if it does not meet the Definition of Done.
It also affects the team roles:
- The product architect decides when an idea deserves to be explored in the fast lane and when it should move to robust construction.
- Product builders can use vibe coding to explore solutions, but they are responsible for critically reviewing what the AI generates.
- The agile enabler helps the team strike a balance between blind trust in AI and paralyzing distrust.
Vibe coding can accelerate learning, but it does not remove professional responsibility. If the code reaches production, it must pass quality, security, maintainability, and human review checks.
Best practices
To use vibe coding without turning it into a source of technical debt, it is advisable to apply a few simple rules:
- Define the hypothesis before building. The prototype should answer a specific question.
- Timebox the exploration. If an idea needs too many iterations to work, it may require a spec or a prior technical decision.
- Do not use sensitive data. Avoid real customer data, secrets, credentials, or confidential information.
- Keep prototype and production separate. Exploratory code should not enter the product without review.
- Record learnings. What is valuable in vibe coding is not just the code, but what the team discovers.
- Decide explicitly what to keep. Some parts may inspire the final solution; others should be discarded.
Warning signs
Vibe coding starts to cause problems when:
- the prototype is kept alive for several sprints without clear validation;
- the team avoids writing specs because "the AI already handles it";
- nobody really understands the generated code;
- changes are accepted without reviewing diffs;
- errors are fixed by pasting messages into the AI without investigating the root cause;
- generated code starts making its way into production without meeting the Definition of Done;
- the team mistakes how fast code is generated for how fast value is delivered.
These signs do not mean that AI should be abandoned. They mean that the work has outgrown the level of informality that vibe coding can sustain.
Difference from Spec-Driven Development
The fundamental difference between vibe coding and Spec-Driven Development lies in the order of work.
| Aspect | Vibe coding | Spec-Driven Development |
|---|---|---|
| Starting point | An intention expressed in natural language. | A reviewed and accepted spec. |
| Method | Conversation, testing, and correction. | Specification, design, tasks, and implementation. |
| Success criterion | The result appears to work for the immediate goal. | The result meets verifiable criteria. |
| Best use | Prototypes, exploration, rapid learning. | Maintainable code, production, risky changes. |
| Main risk | Invisible technical debt and a false sense of progress. | Bureaucracy if applied excessively. |
Both approaches can coexist. The key is not to ask vibe coding for what belongs to robust engineering, nor to impose SDD when all that is needed is to learn quickly.
Common mistake
Mistaking a working demo for production-ready software. The most common vibe coding mistake is accepting AI-generated code because the screen looks good or the happy path works. A prototype can validate an idea, but that does not mean it is secure, maintainable, scalable, or consistent with the product's architecture.
Resources
🏦 IA aplicada al trabajo ágil [AI Applied to Agile Work] (in Spanish)Skill Arena · Scrum Manager
📄 Scrum Master en equipos con IA [Scrum Master in Teams with AI] (in Spanish)Free download · Scrum Manager
🌐 Andrej Karpathy's original post on vibe codingPopular origin of the term · X · 2025
📄 Not all AI-assisted programming is vibe codingArticle by Simon Willison distinguishing vibe coding from other uses of AI in programming · 2025
📄 Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer ProductivityMETR study on productivity with AI tools in open source projects · 2025
📄 Insights from 2025 GenAI Code Security ReportVeracode report on the security of AI-generated code · 2025
References
- Becker, Joel; Rush, Nate; Barnes, Beth; Rein, David. (2025). "Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity," METR.
- GitClear. (2025). "AI Copilot Code Quality: 2025 Data Suggests 4x Growth in Code Duplication," GitClear.
- Karpathy, Andrej. (2025). "There's a new kind of coding I call vibe coding," X.
- METR. (2026). "We are changing our developer productivity experiment design," METR.
- Scrum Manager. (2026). SDD – Spec Driven Development en equipos ágiles [SDD – Spec-Driven Development in agile teams, in Spanish]. Scrum Manager.
- Willison, Simon. (2025). "Not all AI-assisted programming is vibe coding," SimonWillison.net.
See also
Want to advance in agility? You can search for course and exam calls or go at your own pace by becoming a member of the Agile Club. This membership includes exclusive resources, e-learning classrooms, and access to Skill Arena: a space to practice and measure your agile skills at your own pace.