Por qué los bugs de vibe coding se agrupan
Un agente optimiza para el camino que describiste. Tú describes lo que quieres que ocurra, así que el happy path se construye con cuidado y todo lo que lo rodea se construye de forma plausible. Plausible es la palabra clave: el código compila, la pantalla se renderiza y las suposiciones nunca se contrastaron con la realidad.
Por eso los fallos son predecibles. Siempre están en los bordes de la descripción.
Los cuatro grupos, en el orden en que te pasan factura
Persistencia. La pantalla se actualiza, la base de datos no. Una recarga lo revela al instante. Recarga después de cada escritura antes de dar nada por hecho.
Estados vacíos y de error. Cero resultados, una petición fallida, una entrada rechazada. Nada de esto estaba en tu prompt. Prueba cada caso a propósito. Se rompen más a menudo que el happy path.
La segunda cuenta. La propiedad, los permisos y la visibilidad se dan por supuestos a partir de la única sesión con la que se construyó la app. Inicia sesión como otra persona antes de que lo haga alguien más.
El cuarto es más sutil: las funcionalidades de ayer. Cada nueva instrucción puede deshacer en silencio algo que funcionaba, y nadie está comprobando el comportamiento antiguo porque la conversación ya avanzó.
La comprobación que escala con los prompts
Comprobar a mano funciona durante una tarde y luego se degrada, porque la superficie crece cada vez que escribes un prompt y tu paciencia no. Lo que quieres es tener las comprobaciones escritas en lenguaje natural y ejecutándose de forma automática, para que las funcionalidades de ayer se vuelvan a verificar sin que tú lo decidas.
La configuración pone eso en manos del agente, de modo que comprobar ocurre junto con construir y no como una tarea aparte.
Nada de esto necesita una terminal. Crea un proyecto en el dashboard de TestSprite, describe la comprobación en lenguaje natural y apúntala a tu app. Los desarrolladores de tu equipo pueden hacer lo mismo desde la línea de comandos si lo prefieren, disponible en el repositorio del CLI.
Diez minutos que detectan la mayor parte
Regístrate, cierra sesión y vuelve a entrar. El fallo total más común, y lo primero que hace un usuario real.
Crea algo, recarga y confirma que sobrevivió. Detecta directamente el grupo de la persistencia.
Envía algo inválido. Estás comprobando que falle con claridad en lugar de aceptarlo en silencio.
Haz el flujo principal desde una cuenta recién creada. Detecta el grupo de los permisos.
Ninguna de estas comprobaciones requiere leer código y, juntas, encuentran la mayor parte de lo que, si no, encontraría un desconocido.
Por qué el mismo bug vuelve una y otra vez
La queja más habitual sobre construir así no es que las cosas se rompan, sino que arreglar una cosa rompe otra, una y otra vez. Eso no es un fallo del modelo. Es la falta de un registro.
Cada instrucción se interpreta contra el estado actual del código y nada más. No hay una lista de comportamientos que ya tenían que seguir funcionando, así que el agente no tiene forma de saber que el cambio que pediste choca con algo que estableciste el martes pasado. Desde su punto de vista no hay conflicto, porque el martes pasado no está presente.
Las comprobaciones escritas son ese registro. No hacen al agente más inteligente, hacen que tu intención perdure. El efecto práctico es que la tercera y la cuarta ronda de cambios dejan de deshacer las dos primeras, que es el momento en el que construir así empieza a sentirse fiable en lugar de agotador.
Antes de que llegue a un entorno real
En cuanto otras personas vayan a usar la app, las comprobaciones deberían ejecutarse en cada cambio y no cuando te acuerdes.
La GitHub App es un webhook que configuras en el dashboard de TestSprite. Escucha el evento de despliegue que tu pipeline ya genera, así que nada cambia en tu repositorio.
GitHub Actions coloca el paso dentro de tu propio workflow, configurado desde la terminal.
Deja que las comprobaciones se ejecuten solas
TestSprite es la forma de que los diez minutos de comprobación de esta página dejen de ser algo que haces a mano. Describes cada flujo una vez, en lenguaje natural, y TestSprite los ejecuta contra tu app después de cada cambio.
Eso resuelve directamente lo que más frustra a la gente al construir así. Las comprobaciones escritas son el registro de lo que ya tenía que seguir funcionando, de modo que una instrucción nueva se verifica contra ellas en lugar de interpretarse de forma aislada. El bucle en el que arreglar una cosa rompe otra deja de ser lo normal.
Nada de esto necesita una terminal ni un archivo de tests. Crea un proyecto en el dashboard, apúntalo a tu app y describe las cuatro comprobaciones anteriores. Los desarrolladores de tu equipo pueden hacer lo mismo desde la línea de comandos si lo prefieren.
¿El vibe coding es simplemente más arriesgado?
Cambia dónde está el riesgo. Menos riesgo de una errata, más riesgo de una suposición sin examinar. La respuesta no es volver a leer cada línea, sino comprobar el comportamiento de forma sistemática.
¿Por qué arreglar una cosa rompe otra?
Porque cada instrucción se interpreta en el contexto del código actual, no frente a un registro de lo que ya tenía que seguir funcionando. Las comprobaciones escritas aportan ese registro.
¿Necesito escribir tests?
En código no. Describe el flujo en lenguaje natural, consérvalo y haz que se ejecute automáticamente después de cada cambio.
¿Cómo sé que la comprobación es real?
Rompe algo a propósito y confirma que la comprobación falla. Una comprobación que nunca falla no protege nada, y verificarlo lleva un minuto.
¿Cuándo debería empezar a comprobar?
Antes de enseñárselo a nadie. El costo de una comprobación escrita ahora son minutos; el costo después de que otra persona haya encontrado el bug es mucho mayor.
Revisa los cuatro grupos, no el código.
Los bugs de vibe coding se concentran en la persistencia, los estados vacíos, las segundas cuentas y las funcionalidades que construiste ayer. Diez minutos cubren la mayoría, y escribir esas comprobaciones es lo que evita que vuelvan mientras sigues escribiendo prompts.