Cómo mantener la calidad del código en el vibe engineering: 5 prácticas

La calidad en el vibe engineering no surge de la “buena disciplina”. Surge de cinco prácticas que, juntas, forman un escudo contra las regresiones. Una sola práctica no basta. Dos bastan para empezar. Tres dan tranquilidad. Con la cuarta y la quinta desaparecen la mayoría de los problemas del tipo “¿por qué se volvió a romper, si los tests pasaban?”.

Práctica 1: la spec como barrera

Todo cambio que toque más de tres archivos tiene un SPEC.md o un issue con requisitos no funcionales formales (latencia, costo de LLM, ruta de rollback) y funcionales. La spec es breve (400-800 palabras) y termina con una sección “Out of scope”. Sin esa sección, cualquier implementación se desvía un 30%.

La spec la escribes tú (el humano). El agente puede ayudarte con el primer borrador, pero la aprobación final es tuya. Sin concesiones: sin la aceptación de un humano, la spec se convierte en un placeholder generativo.

Práctica 2: dos revisiones

Primero, un agente revisa el PR (por ejemplo, un subagente revisor dedicado). Después, un humano. Las dos revisiones detectan clases de errores distintas. El agente detecta incoherencias de estilo, tipos que faltan y rutas de código ingenuas. El humano detecta lógica de dominio mal interpretada y el “problema resuelto a medias”.

Lo crucial: el agente revisor no puede aprobar por su cuenta. Solo puede comentar. Esa es la diferencia entre un ayudante y alguien que decide.

Práctica 3: tests de mutación o basados en propiedades

Un 80% de cobertura tradicional solo te dice que la línea se ejecutó. El mutation testing (Stryker, PIT, Cosmic Ray) cambia una instrucción y comprueba si algún test lo detectó. Si no, el test era una muleta.

El property-based testing (fast-check, Hypothesis) genera cientos de casos aleatorios. Basta con que uno de ellos detecte una regresión antes de producción para ahorrarte miles de horas de postmortem.

En el vibe engineering recomendamos al menos uno de los dos. Lo ideal: ambos en los módulos clave.

Práctica 4: barreras en CI

Barreras que no se pueden saltar:

• typescript strict sin errores;
• lint sin warnings (o con una lista explícita de excepciones);
• tests unitarios + e2e: completos (ningún .skip sin un issue);
• mutation testing: 70%+ de mutantes eliminados;
• delta del tamaño del bundle < 5% (alerta por encima);
• escaneo de seguridad: cero high+critical, cero secretos en el diff;
• evals de LLM sobre los prompts: 90%+ de tasa de aprobación en el conjunto de regresión.

Cada barrera detecta una clase de error distinta. Saltarse cualquiera “solo por esta vez” es el inicio de una deuda de calidad que pagarás de noche.

Práctica 5: telemetría en producción + auto-rollback

Después del deploy: alertas sobre la latencia p99, los errores 5xx y el costo de LLM por solicitud. Disparador de auto-rollback cuando se supera un umbral (API de rollback de despliegues de Vercel, rollback de Kubernetes).

Segunda capa: respuesta a incidentes. Un runbook de “qué hacer cuando salta la alerta”. Tercera: un postmortem sin culpables tras cada incidente, con 5 rondas de “por qué”.

Mito: la IA garantizará la calidad por sí sola

No lo hará. La IA es muy buena generando código que “parece funcionar”, pero que tiene problemas sutiles. Sin las cinco prácticas anteriores, un PR generado por un LLM se publica más rápido, pero llega a producción con más riesgo que el PR de un junior supervisado por un mentor. No porque la IA sea peor, sino porque escribe más rápido, así que cada hueco de tu proceso escala con esa velocidad.

Objeciones de los equipos

“Cinco prácticas son demasiado para nuestro pequeño equipo.” Cada práctica cuesta unas pocas horas a la semana. No tener ninguna cuesta varios días al mes rescatando producción. Las cuentas salen incluso en un equipo de tres personas.

“Somos una startup, no tenemos tiempo.” La spec, dos revisiones y un tipo de test son el mínimo para una startup a partir del primer cliente de pago. El resto llega con el tiempo.

Implantación por fases

1. Semanas 1-2: spec para cada cambio de > 3 archivos.
2. Semanas 3-4: agente revisor en CI (comenta, no bloquea).
3. Semanas 5-8: mutation testing en un módulo (el más crítico).
4. Semanas 9-12: barreras de CI con aplicación estricta.
5. Semana 13+: telemetría en producción, auto-rollback, runbooks.

TL;DR

La calidad en el vibe engineering se resume en cinco prácticas: spec, dos revisiones, tests de mutación/propiedades, barreras de CI y telemetría en producción con auto-rollback. Por separado no bastan. Juntas convierten el vibe engineering en una forma de trabajar que escala a producción real sin dramas nocturnos.