Vibe coding con criterio: dirigir a un agente de código sin perder el control
El vibe coding se vende como escribir en español y ver aparecer una app. En la práctica es dirigir: tú defines el problema, el agente escribe, tú verificas. La distancia entre un atajo útil y un desastre silencioso está en lo que haces ante
Puntos Clave de este Análisis
- El vibe coding no elimina la ingeniería: mueve el trabajo al que dirige.
- Si no puedes describir el alcance en una página, el agente inventará el resto.
- Una especificación sin criterios de aceptación es una sugerencia.
- Revisa el diff como si lo hubiera escrito un desconocido con prisa.
- Cada atajo que no documentas se convierte en deuda que pagas tú.
- Si llevas dos vueltas con el mismo error, el problema es el contexto, no el intento.
El vibe coding se vende como escribir en español y ver aparecer una app. En la práctica es dirigir: tú defines el problema, el agente escribe, tú verificas. La distancia entre un atajo útil y un desastre silencioso está en lo que haces antes y después de pedir.
Qué es y qué no es vibe coding
Vibe coding es delegar la escritura del código a un modelo con feedback en lenguaje natural, aceptando que no vas a leer cada línea en el momento. Es una decisión sobre dónde pones tu atención, no una excusa para apagarla.
Lo que no es: programar sin saber programar, prototipar sin rumbo o aceptar todo porque las pruebas pasan.
La distinción que importa es el destino del código. Un prototipo puede descartarse: si el error se ve en dos minutos, la chapuza cuesta poco. El código de producción tiene otro contrato: alguien lo mantendrá y depurará un fallo a las tres de la mañana. Probablemente tú.
Hay una asimetría que casi nadie menciona. El vibe coding rinde mejor donde el error se ve rápido —una pantalla, un script, una consulta sobre una muestra— y peor donde es silencioso: permisos, cobros, fechas, concurrencia. Esa asimetría debería decidir dónde lo usas, no la moda.
El orden correcto: alcance, especificación, datos, construir, verificar
El orden separa dirigir de reaccionar.
- Alcance: una frase de resultado y una lista de lo que queda fuera.
- Especificación: estados, datos y criterios de aceptación.
- Datos: el modelo de datos antes de la pantalla.
- Construir: bloques pequeños, un objetivo por bloque.
- Verificar: prueba y diff antes de seguir.
Cuando empiezas construyendo, el agente decide el producto por ti y lo esconde en el código. Elige nombres, estados y casos límite sin avisar. Dos horas después tienes una app que funciona y no es la que querías.
Los datos van antes porque el modelo de datos revela requisitos que la prosa esconde. Si una reserva puede cancelarse, necesitas un estado intermedio, una fecha y una regla sobre quién puede hacerlo. Eso no aparece en "hazme una app de reservas". Aparece cuando escribes las columnas.
Cómo escribir una especificación que el agente pueda ejecutar
Una especificación útil no es un brief creativo: es un contrato de aceptación con contexto suficiente para no adivinar.
Contenido mínimo:
- Resultado esperado en una frase.
- Archivos y zonas del repo que puede tocar.
- Contrato de datos: campos, tipos, obligatoriedad, estados válidos.
- Criterios de aceptación que se puedan comprobar.
- Límites: qué no instalar, qué no modificar, qué no inventar.
- Un ejemplo de entrada y salida, y cómo se verifica.
Un ejemplo para un formulario de cobro: "Acepta tarjeta y transferencia. Tarjeta exige titular, número y vencimiento; transferencia, IBAN y titular. No inventes campos. Si falta un dato, muestra el error junto al campo, no un alert. Un envío fallido no limpia el formulario. La prueba cubre ambos métodos y un fallo."
La parte que más se olvida son los estados: los agentes fallan más por ambigüedad que por lógica. Si no defines qué significa pendiente, confirmada y cancelada, el agente inventará una transición y la esconderá.
Un agente no adivina lo que no escribiste: lo inventa y lo esconde.
Pide el plan antes del código: diez líneas se corrigen en un minuto; un diff de cuatrocientos archivos, en una tarde.
Revisar código que no escribiste
Revisar no es leer. Es buscar lo que el agente no dijo.
- Lee el diff completo una vez sin detenerte. Busca la forma del cambio, no los detalles.
- Vuelve a las zonas de riesgo: autenticación, dinero, fechas, consultas, migraciones.
- Sigue el flujo de datos de entrada a salida. Ahí aparecen los campos que se pierden y los errores que se tragan.
- Mira las pruebas. Una prueba que solo comprueba que la función no explota no prueba nada.
- Revisa lo que quedó fuera del alcance: dependencias nuevas, configuración global, archivos que nadie pidió tocar.
Puedes preguntarle por qué tomó una decisión. Úsalo para entender su razonamiento, no como prueba: su explicación es otra generación de texto. La verdad está en el código.
Señales de alarma:
- Dependencia nueva sin justificación.
- catch vacío o errores convertidos en null.
- Lógica duplicada en dos archivos que deberían compartir una función.
- Cambios en configuración global para que pase una prueba.
- Nombres que no coinciden con el dominio: reserva, turno y plaza usados como sinónimos.
- Un diff grande para un pedido pequeño.
La deuda invisible
La deuda normal se ve: está en el backlog y tiene ticket. La invisible no: se acumula en cada aceptación sin lectura y se paga cuando alguien tiene que cambiar algo.
Se manifiesta de tres formas: nadie sabe por qué existe una función, un bug de una hora tarda un día, y el siguiente prompt se apoya en supuestos falsos. El proyecto parece sano mientras no lo tocas.
Antídoto parcial: una línea por cada cambio no obvio. Por qué este estado, esta tabla, esta librería. Y una regla dura: el código que no entiendes no se queda. Se reescribe, se reduce o se documenta hasta que lo entiendas.
Cuándo apagar el agente y escribir a mano
El vibe coding no es una obligación moral. Hay tareas donde el agente es la peor herramienta disponible.
Tarea | Modo | Por qué Pantalla CRUD interna | Agente | El error se ve al abrir la página Script de un solo uso | Agente | Desechable, sin mantenimiento Migración de datos | Agente con muestra | Se verifica con conteos y totales Formulario de cobro | Mixto | La estructura la defines tú; el agente rellena Permisos y roles | A mano | Un error no se ve hasta que alguien entra donde no debe Bug de concurrencia | A mano | El agente tiende a parchear el síntoma Refactor estructural | Plan a mano, ejecución asistida | El agente pierde el mapa del repo
Hay una señal: si llevas dos vueltas corrigiendo el mismo error, para. El bucle indica que el agente no tiene el contexto correcto, no que le falte un intento. Cambiar el prompt sin cambiar el contexto produce el mismo fallo.
Para cuando el cambio es más pequeño que la explicación: veinte líneas en el editor son más rápidas y más seguras que un párrafo para que otro las escriba.
Seguridad mínima: secretos, permisos, datos
- Secretos: nunca en el prompt ni en el repo. Usa variables de entorno y revisa que el agente no las escriba en logs ni las deje fijas en configuración.
- Permisos: el agente trabaja con credenciales locales y datos falsos. Nunca con acceso a producción.
- Datos: no pegues datos de clientes en el chat. Anonimiza o usa fixtures; lo que entra en un prompt sale de tu control.
- Dependencias: cada instalación es superficie de ataque y mantenimiento. Exige una razón.
- Acciones destructivas: sin borrados masivos, sin migraciones ni force push sin confirmación humana.
- Salida: el agente puede inventar endpoints y campos. Verifica contra la documentación real, no contra su respuesta.
El riesgo no es un agente malicioso, sino uno convincente y equivocado. Un endpoint inventado con nombre plausible pasa la revisión si no lo compruebas.
Un flujo semanal realista
Un flujo que no convierte la semana en una demo:
- Lunes: alcance y especificación de una sola cosa. Treinta minutos, no tres horas.
- Martes y miércoles: construir en bloques pequeños, con verificación antes de seguir.
- Jueves: revisión de diff, pruebas y limpieza de lo que quedó a medias.
- Viernes: documentar decisiones y escribir a mano lo que quedó raro. Una hora, sin excepción.
No más de dos frentes abiertos: el agente pierde contexto y tú también. Al cerrar el día, anota lo que quedó sin revisar. Si la lista crece tres días seguidos, el viernes se paga.
El criterio no está en el prompt. Está en lo que aceptas.
Actúa como ingeniero senior en este repo. Antes de escribir código: 1. Resume el alcance en cinco líneas y lista lo que queda fuera. 2. Señala los archivos que vas a tocar y los criterios de aceptación. 3. Espera mi confirmación. No instales dependencias ni toques configuración. Si algo no está claro, pregunta en vez de asumir.