Vibe engineering
Vibe engineering es el modo de trabajo robusto en desarrollo asistido por IA: una idea validada, a menudo explorada antes mediante vibe coding, se convierte en software mantenible, seguro y liberable mediante Spec-Driven Development, revisión humana, pruebas, QA y una Definition of Done reforzada.
Vibe engineering es el complemento del vibe coding. Mientras el vibe coding prioriza aprender rápido, el vibe engineering prioriza construir con rigor.
El término no debe entenderse como un estándar formal de la industria, sino como una etiqueta útil para describir el carril robusto de trabajo en equipos que usan IA generativa para construir producto. Su valor está en poner nombre a una transición crítica: pasar de “esto parece funcionar” a “esto puede mantenerse, auditarse y llegar a producción”.
Por qué hace falta
La IA generativa ha reducido de forma drástica el coste inicial de producir código. Un equipo puede crear prototipos, pantallas, integraciones simples o pruebas de concepto en mucho menos tiempo que antes.
Pero esa velocidad inicial no resuelve los problemas clásicos de la ingeniería de software. De hecho, puede intensificarlos:
- código que funciona en el caso feliz, pero falla en escenarios límite;
- decisiones técnicas implícitas que nadie revisó;
- duplicación de lógica;
- dependencias innecesarias;
- errores de seguridad;
- integración deficiente con la arquitectura existente;
- pruebas generadas por la misma IA que produjo el código;
- falsa sensación de avance porque el prototipo “se ve bien”.
Vibe engineering responde a ese problema separando dos momentos que no deberían confundirse: exploración y producción.
Diferencia entre vibe coding y vibe engineering
| Aspecto | Vibe coding | Vibe engineering |
|---|---|---|
| Propósito | Aprender rápido, explorar ideas y validar hipótesis. | Construir software de producción con estándares técnicos completos. |
| Resultado esperado | Prototipo, prueba de concepto o evidencia de aprendizaje. | Incremento mantenible, verificable y liberable. |
| Calidad del código | Secundaria mientras el código no llegue a producción. | Central: seguridad, mantenibilidad, testing, integración y trazabilidad. |
| Artefacto principal | Conversación con la IA, prompts y pruebas rápidas. | Spec, criterios de aceptación, tareas, controles y Definition of Done reforzada. |
| Riesgo principal | Confundir una demo funcional con software listo. | Convertir el rigor en burocracia innecesaria. |
Ambos modos pueden ser útiles. El error no está en usar vibe coding, sino en no reconocer cuándo una idea ya necesita pasar a vibe engineering.
Cuándo pasar a vibe engineering
Una idea debería pasar del carril rápido al carril robusto cuando:
- la hipótesis ha sido validada con usuarios reales o stakeholders relevantes;
- el prototipo demuestra suficiente valor como para invertir en producción;
- la funcionalidad va a afectar a usuarios, datos, seguridad, permisos, pagos o procesos críticos;
- el código tendrá que mantenerse o evolucionar;
- existen requisitos claros que pueden convertirse en una spec;
- la solución debe integrarse con una arquitectura existente;
- el riesgo técnico justifica testing, revisión y trazabilidad;
- el coste de rehacer bien la solución es menor que el coste de arrastrar un prototipo frágil.
El paso a vibe engineering no significa necesariamente reutilizar el código generado durante el vibe coding. A menudo, el prototipo sirve como aprendizaje, no como base técnica.
Cómo funciona
Un flujo de vibe engineering puede organizarse así:
- Validar la oportunidad: antes de construir con rigor, el equipo confirma que el problema merece inversión.
- Escribir la spec: se define qué debe construirse, qué queda fuera, qué restricciones existen y cómo se verificará el resultado.
- Preparar el contexto para la IA: el agente recibe arquitectura, estándares, APIs, modelos de datos, ejemplos, criterios de aceptación y límites.
- Dividir el trabajo en tareas revisables: la implementación se descompone en unidades pequeñas, verificables y con criterios claros.
- Ejecutar con IA bajo control: el agente genera código, tests, documentación o cambios técnicos siguiendo la spec.
- Aplicar sensores técnicos: linters, tests, análisis estático, revisión de dependencias, comprobaciones de seguridad y validaciones de integración.
- Revisión humana: un product builder revisa el resultado, valida las decisiones y asume responsabilidad operativa.
- Integrar y liberar: el incremento entra en el flujo normal de entrega si cumple la Definition of Done.
La diferencia con “pedirle a la IA que lo haga” es que en vibe engineering la IA no opera en vacío. Opera dentro de un sistema de restricciones, controles y responsabilidad.
Elementos principales
Spec
La spec es el artefacto que transforma una intención en un encargo verificable. No tiene que ser larga, pero sí suficientemente clara para evitar que el agente invente decisiones críticas.
Una buena spec incluye:
- comportamiento esperado;
- criterios de aceptación;
- límites de alcance;
- restricciones técnicas;
- casos borde;
- dependencias relevantes;
- requisitos no funcionales;
- señales para saber que el resultado es correcto.
Definition of Ready para IA
Antes de asignar trabajo a un agente, el equipo debe comprobar que tiene el contexto necesario. En un entorno humano, nadie esperaría que una persona nueva entregara bien sin onboarding. Con la IA ocurre lo mismo.
Un ítem está preparado para trabajo con IA cuando:
- la spec está completa y revisada;
- el agente tiene acceso al contexto relevante;
- los criterios de aceptación son verificables;
- existen estándares técnicos claros;
- se ha estimado el tiempo de revisión humana;
- el equipo sabe quién se responsabiliza del resultado.
Definition of Done reforzada
En vibe engineering, “done” no significa que el agente haya terminado de generar código. Significa que el incremento cumple los criterios técnicos y de producto acordados.
Puede incluir:
- análisis estático sin errores críticos;
- tests unitarios, de integración o end-to-end según el caso;
- revisión de seguridad;
- verificación de no duplicación;
- revisión humana del diff;
- comprobación de que el resultado cumple la spec;
- trazabilidad de qué fue generado por IA y qué fue revisado por personas.
Revisión humana
La revisión humana no es una cortesía. Es parte del sistema de calidad.
La IA puede producir soluciones plausibles pero frágiles. El product builder debe evaluar si el código encaja con la arquitectura, si cubre casos reales, si introduce deuda técnica y si puede sostenerse en producción.
QA y seguridad
El vibe engineering incorpora QA desde el diseño del flujo. No espera al final para descubrir si el incremento funciona.
Las comprobaciones pueden incluir:
- generación y revisión de casos de prueba;
- tests automatizados;
- análisis de vulnerabilidades;
- revisión de dependencias;
- validación de permisos y manejo de datos;
- pruebas sobre casos límite;
- revisión de logs, observabilidad y errores.
Vibe engineering en Scrum con IA
En equipos Scrum con IA, vibe engineering se sitúa en el carril robusto del sistema de trabajo.
El product owner o product architect decide cuándo una idea merece pasar del carril rápido al carril robusto. Esta decisión no se basa solo en si la idea gusta, sino en si hay evidencia suficiente para justificar el coste de construir bien.
Los product builders convierten esa decisión en specs, tareas, implementación revisada y controles técnicos. Su valor no está en producir más líneas de código, sino en asegurar calidad, mantenibilidad y robustez.
El scrum master o agile enabler facilita el sistema completo: ayuda a que el equipo no caiga ni en la confianza ciega en la IA ni en la desconfianza paralizante. También observa si el flujo genera cuellos de botella, especialmente en revisión e integración.
Relación con Spec-Driven Development
Spec-Driven Development es una de las prácticas centrales del vibe engineering.
SDD aporta el método: antes de generar código, el equipo define una spec que guía el trabajo del agente. Vibe engineering aporta el contexto de uso: esa práctica forma parte de un carril robusto orientado a producción.
Dicho de forma simple:
- SDD responde a “¿cómo guiamos a la IA para construir con precisión?”.
- Vibe engineering responde a “¿cuándo y con qué rigor llevamos una solución asistida por IA a producción?”.
Relación con la deuda técnica
Vibe engineering existe, en parte, para evitar que el vibe coding se convierta en deuda técnica.
Un prototipo puede estar lleno de atajos aceptables si su objetivo es aprender. El problema aparece cuando esos atajos se conservan sin decisión explícita.
La deuda técnica no nace solo de escribir mal código. También nace de no distinguir entre:
- código para aprender;
- código para demostrar;
- código para operar;
- código para mantener.
Vibe engineering fuerza esa distinción.
Métricas útiles
Algunas métricas ayudan a saber si el carril robusto está funcionando:
- Cycle time: tiempo desde que se empieza la implementación hasta que llega a producción.
- Lead time: tiempo desde que se identifica la necesidad hasta que se entrega valor.
- Tiempo de revisión humana por tarea IA: permite detectar cuellos de botella reales.
- Ratio refactoring vs. código nuevo: ayuda a vigilar salud técnica.
- Duplicación de código: especialmente importante cuando se usa IA generativa.
- Defectos escapados a producción: indica si los controles están siendo suficientes.
- Cambios rechazados en revisión: señala problemas de spec, contexto o calidad del agente.
La métrica más peligrosa en este contexto es contar solo cuánto código genera la IA. Producir más código no equivale a entregar más valor.
Señales de alarma
El vibe engineering está fallando cuando:
- el equipo genera specs largas pero poco útiles;
- las revisiones humanas se acumulan y bloquean el sprint;
- los agentes producen mucho código que luego se descarta;
- los tests los genera la IA y nadie los revisa;
- el equipo acepta código porque “pasa los tests”, aunque nadie entienda bien la solución;
- la Definition of Done se relaja para no frenar la velocidad aparente;
- el prototipo del carril rápido entra en producción sin reconstrucción ni revisión;
- cada cambio generado por IA introduce más deuda que valor.
Estas señales no indican que la IA no sirva. Indican que el sistema de trabajo alrededor de la IA no está suficientemente diseñado.
Error frecuente
Creer que vibe engineering es vibe coding con más cuidado. Vibe engineering no consiste en pedirle a la IA el mismo código y revisarlo un poco más. Implica cambiar el sistema de trabajo: escribir specs, preparar contexto, dividir tareas, aplicar controles técnicos, estimar revisión humana y asumir responsabilidad sobre lo que llega a producción.
Recursos
🏦 IA aplicada al trabajo ágilSkill Arena · Scrum Manager
📄 Scrum Master en equipos con IADescarga gratuita · Scrum Manager
Referencias
- 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.
- GitHub. (2025). “Spec Kit”, GitHub.
- Veracode. (2025). “Insights from 2025 GenAI Code Security Report”, Veracode.
Véase también
¿Quieres avanzar en agilidad? Puedes buscar convocatorias de cursos y exámenes o ir a tu ritmo haciéndote miembro del Club Agile. Esta membresía incluye recursos exclusivos, aulas e-learning y acceso a Skill Arena: un espacio para practicar y medir tus habilidades ágiles a tu ritmo.