Vibe engineering
Vibe engineering is the complement to vibe coding. While vibe coding prioritizes learning fast, vibe engineering prioritizes building with rigor.
The term should not be understood as a formal industry standard, but rather as a useful label for describing the robust lane of work in teams that use generative AI to build product. Its value lies in naming a critical transition: moving from "this seems to work" to "this can be maintained, audited, and taken to production."
Why it is needed
Generative AI has drastically reduced the initial cost of producing code. A team can create prototypes, screens, simple integrations, or proofs of concept in much less time than before.
But that initial speed does not solve the classic problems of software engineering. In fact, it can intensify them:
- code that works on the happy path but fails in edge cases;
- implicit technical decisions that no one reviewed;
- duplicated logic;
- unnecessary dependencies;
- security flaws;
- poor integration with the existing architecture;
- tests generated by the same AI that produced the code;
- a false sense of progress because the prototype "looks good."
Vibe engineering addresses this problem by separating two moments that should not be confused: exploration and production.
Difference between vibe coding and vibe engineering
| Aspect | Vibe coding | Vibe engineering |
|---|---|---|
| Purpose | Learn fast, explore ideas, and validate hypotheses. | Build production software with full technical standards. |
| Expected result | Prototype, proof of concept, or evidence of learning. | Maintainable, verifiable, and releasable increment. |
| Code quality | Secondary as long as the code does not reach production. | Central: security, maintainability, testing, integration, and traceability. |
| Main artifact | Conversation with the AI, prompts, and quick tests. | Spec, acceptance criteria, tasks, controls, and reinforced Definition of Done. |
| Main risk | Mistaking a working demo for ready software. | Turning rigor into unnecessary bureaucracy. |
Both modes can be useful. The mistake is not using vibe coding, but failing to recognize when an idea needs to move on to vibe engineering.
When to move to vibe engineering
An idea should move from the fast track to the robust track when:
- the hypothesis has been validated with real users or relevant stakeholders;
- the prototype demonstrates enough value to justify investing in production;
- the functionality will affect users, data, security, permissions, payments, or critical processes;
- the code will need to be maintained or evolved;
- there are clear requirements that can be turned into a spec;
- the solution must integrate with an existing architecture;
- the technical risk justifies testing, review, and traceability;
- the cost of properly rebuilding the solution is lower than the cost of dragging along a fragile prototype.
Moving to vibe engineering does not necessarily mean reusing the code generated during vibe coding. Often, the prototype serves as a learning exercise, not as a technical foundation.
How it works
A vibe engineering workflow can be organized as follows:
- Validate the opportunity: before building with rigor, the team confirms that the problem is worth the investment.
- Write the spec: it defines what must be built, what is out of scope, what constraints exist, and how the result will be verified.
- Prepare the context for the AI: the agent receives the architecture, standards, APIs, data models, examples, acceptance criteria, and boundaries.
- Break the work down into reviewable tasks: the implementation is broken down into small, verifiable units with clear criteria.
- Execute with AI under control: the agent generates code, tests, documentation, or technical changes following the spec.
- Apply technical sensors: linters, tests, static analysis, dependency review, security checks, and integration validations.
- Human review: a product builder reviews the result, validates the decisions, and takes on operational responsibility.
- Integrate and release: the increment enters the normal delivery flow if it meets the Definition of Done.
The difference from "asking the AI to do it" is that in vibe engineering, the AI does not operate in a vacuum. It operates within a system of constraints, controls, and accountability.
Key elements
Spec
The spec is the artifact that turns an intention into a verifiable assignment. It does not have to be long, but it must be clear enough to keep the agent from inventing critical decisions.
A good spec includes:
- expected behavior;
- acceptance criteria;
- scope boundaries;
- technical constraints;
- edge cases;
- relevant dependencies;
- non-functional requirements;
- signals that the result is correct.
Definition of Ready for AI
Before assigning work to an agent, the team must check that it has the necessary context. In a human setting, nobody would expect a new person to deliver well without onboarding. The same is true with AI.
An item is ready for AI work when:
- the spec is complete and reviewed;
- the agent has access to the relevant context;
- the acceptance criteria are verifiable;
- clear technical standards exist;
- the human review time has been estimated;
- the team knows who is accountable for the result.
Reinforced Definition of Done
In vibe engineering, "done" does not mean that the agent has finished generating code. It means that the increment meets the agreed technical and product criteria.
It may include:
- static analysis with no critical errors;
- unit, integration, or end-to-end tests, as appropriate;
- security review;
- verification that there is no duplication;
- human review of the diff;
- a check that the result meets the spec;
- traceability of what was generated by AI and what was reviewed by people.
Human review
Human review is not a courtesy. It is part of the quality system.
AI can produce plausible but fragile solutions. The product builder must assess whether the code fits the architecture, whether it covers real cases, whether it introduces technical debt, and whether it can be sustained in production.
QA and security
Vibe engineering builds QA into the workflow from the design stage. It does not wait until the end to find out whether the increment works.
Checks may include:
- generation and review of test cases;
- automated tests;
- vulnerability analysis;
- dependency review;
- validation of permissions and data handling;
- edge case testing;
- review of logs, observability, and errors.
Vibe engineering in Scrum with AI
In Scrum Teams with AI, vibe engineering sits in the robust lane of the work system.
The Product Owner or product architect decides when an idea deserves to move from the fast lane to the robust lane. This decision is not based solely on whether people like the idea, but on whether there is enough evidence to justify the cost of building it properly.
Product builders turn that decision into specs, tasks, reviewed implementation, and technical controls. Their value lies not in producing more lines of code, but in ensuring quality, maintainability, and robustness.
The Scrum Master or agile enabler facilitates the whole system: they help the team avoid falling into either blind trust in AI or paralyzing distrust. They also watch whether the flow creates bottlenecks, especially in review and integration.
Relationship with Spec-Driven Development
Spec-Driven Development is one of the core practices of vibe engineering.
SDD provides the method: before generating code, the team defines a spec that guides the agent's work. Vibe engineering provides the context of use: that practice is part of a robust, production-oriented track.
Put simply:
- SDD answers "How do we guide AI to build with precision?"
- Vibe engineering answers "When, and with what rigor, do we take an AI-assisted solution to production?"
Relationship with technical debt
Vibe engineering exists, in part, to prevent vibe coding from turning into technical debt.
A prototype can be full of acceptable shortcuts if its goal is learning. The problem arises when those shortcuts are kept without an explicit decision.
Technical debt doesn't come only from writing bad code. It also comes from failing to distinguish between:
- code for learning;
- code for demonstrating;
- code for operating;
- code for maintaining.
Vibe engineering forces that distinction.
Useful metrics
Some metrics help determine whether the robust lane is working:
- Cycle time: time from when implementation starts until it reaches production.
- Lead time: time from when the need is identified until value is delivered.
- Human review time per AI task: helps detect real bottlenecks.
- Refactoring vs. new code ratio: helps monitor technical health.
- Code duplication: especially important when using generative AI.
- Defects escaped to production: indicates whether the controls are sufficient.
- Changes rejected in review: points to problems with the spec, the context, or the agent's quality.
The most dangerous metric in this context is simply counting how much code the AI generates. Producing more code is not the same as delivering more value.
Warning signs
Vibe engineering is failing when:
- the team writes long but unhelpful specs;
- human reviews pile up and block the sprint;
- agents produce a lot of code that is later discarded;
- tests are generated by AI and nobody reviews them;
- the team accepts code because it "passes the tests," even though nobody really understands the solution;
- the Definition of Done is relaxed so as not to slow down apparent velocity;
- the prototype from the fast lane goes into production without being rebuilt or reviewed;
- every AI-generated change introduces more debt than value.
These signals do not mean that AI is useless. They mean that the work system around AI is not sufficiently designed.
Common mistake
Believing that vibe engineering is just vibe coding done more carefully. Vibe engineering is not about asking the AI for the same code and reviewing it a bit more. It involves changing the way of working: writing specs, preparing context, breaking down tasks, applying technical controls, estimating human review time, and taking responsibility for what reaches production.
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
References
- Becker, Joel; Rush, Nate; Barnes, Beth; Rein, David. (2025). "Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity," METR.
- Böckeler, Birgitta. (2025). "Understanding Spec-Driven-Development: Kiro, spec-kit, and Tessl," MartinFowler.com.
- METR. (2026). "We are changing our developer productivity experiment design," METR.
See also
Want to advance in agility? You can search for calls for courses and exams, 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.