Vibe coding, y la primera semana que no acaba en un desastre
El vibe coding consiste en construir describiendo lo que quieres y aceptando lo que el modelo escribe sin leerlo todo. Funciona cuando equivocarse cuesta poco y el feedback es inmediato — prototipos, scripts, herramientas desechables. Deja de funcionar cuando el código sobrevive a la sesión, porque lo que te saltaste es justo lo que después hay que entender.
El vibe coding consiste en construir describiendo lo que quieres y aceptando lo que el modelo escribe sin leerlo todo. El término es de Andrej Karpathy, y lo que lo distingue no es que la IA escribiera el código — eso ya es lo normal — sino que nadie lo revisó línea a línea.
Eso es un intercambio, no un error. Que sea un buen intercambio depende por completo de una pregunta: ¿cuánto tiempo tiene que vivir este código?
¿Dónde funciona de verdad el vibe coding?
Prototipos que piensas borrar. El coste de equivocarte es que lo tiras, que es lo que ibas a hacer de todos modos.
Scripts y herramientas de un solo uso. Algo que reordena un CSV, siembra una base de datos, hace scraping de una página una vez. Si produce la salida correcta has terminado; nadie va a mantenerlo.
Aprender la forma de algo que no conoces. Conseguir un ejemplo funcionando de una biblioteca que no has usado nunca es más rápido así que leerte antes la documentación, y puedes leer la documentación después con algo concreto delante.
Cualquier cosa donde el feedback sea inmediato y total. Si funciona, funciona, y te enteras en diez segundos.
El hilo común es que equivocarse es barato y evidente. Ésa es la condición. No el tamaño del proyecto, ni el lenguaje, ni si es «real» — sólo si un error aparece de inmediato y cuesta poco.
¿Cuándo deja de funcionar?
En el momento en que el código sobrevive a la sesión que lo produjo.
Esto no es un juicio moral. Es aritmética: compraste velocidad saltándote la comprensión, y la factura llega cuando alguien tiene que cambiar código que nadie entendió cuando se escribió. Si nadie lo cambia nunca, la factura no llega nunca y la velocidad te salió gratis. Ése es un resultado real y ocurre mucho.
Lo que hace que salga mal es no saber en cuál de los dos casos estás. Casi todas las malas experiencias empiezan como un prototipo que se volvió crítico en silencio, sin que nadie decidiera nada.
¿Cómo sé en qué caso estoy?
Tres preguntas, y van sobre la situación más que sobre el código:
| Pregunta | El vibe coding vale cuando | Deja de valer cuando |
|---|---|---|
| ¿Con qué rapidez me entero de que me equivoqué? | En segundos. Lo ejecutas y lo ves | En semanas, a través de un cliente |
| ¿Qué cuesta equivocarse? | Lo borras y empiezas otra vez | Dinero, datos o la confianza de alguien |
| ¿Quién más depende de esto? | Nadie | Cualquiera que no seas tú |
Las tres apuntando en la misma dirección es el caso para el que se hizo esto. Las tres apuntando en la otra y no estás haciendo vibe coding, estás apostando con pasos extra.
Lo útil es que esto se decide por pieza de trabajo, no por proyecto. La misma tarde puede contener un script desechable que no lees nunca y un cambio de permisos que lees dos veces. Tratar un repositorio entero como un único ajuste es lo que produce los dos errores habituales: leerlo todo en un prototipo, y no leer nada en la parte que muerde.
¿Qué no debería hacer nunca con vibe coding?
Una lista corta, y el motivo es el mismo en todos los puntos:
- Autenticación y permisos. Equivocarse aquí no lanza un error. Deja entrar en silencio a quien no debe, y te enteras por otra persona.
- Dinero. Precios, cargos, devoluciones, divisas. Un off-by-one en un bucle es un bug; un off-by-one en céntimos es un chargeback y un correo que no quieres escribir.
- Cualquier cosa que borre. Los borrados en cascada sobre todo. La prueba para esta categoría es si existe un deshacer.
- Migraciones de base de datos. Se ejecutan una vez, contra datos reales, y el fallo se descubre cuando los datos ya no están.
- Todo lo que maneje datos personales de otros. Equivocarse aquí lleva un regulador incorporado.
Fíjate en lo que no es el criterio: la dificultad. Algunas de éstas son código fácil. La propiedad que comparten es que equivocarse no se anuncia solo — que es exactamente el supuesto sobre el que corre el vibe coding.
Esto no es «escríbelo tú». Es «lee éste». Deja que el modelo lo escriba, después lee de verdad lo que escribió, y pídele que te explique las partes que no puedas seguir. La lectura es todo el coste, y en estas cinco merece la pena pagarlo.
La primera semana
Mantén las sesiones cortas, y termina cada una en algo que funcione. Éste es el hábito de mayor rendimiento y no va sobre la IA en absoluto. Una sesión larga acumula decisiones que nadie escribió, y cuando por fin algo va mal no hay ningún punto al que volver. Sesiones cortas con un commit que funciona al final te dan un sitio al que regresar.
Lee las partes caras. No todo — eso echaría a perder el propósito. Lee todo lo que toque dinero, autenticación, borrado de datos, o código en el que también trabaja otra persona. El resto, ojéalo. La habilidad que se construye aquí es el triage, y es una habilidad real: saber dónde equivocarse sale caro es la mayor parte de lo que sabe un ingeniero senior.
Di lo que no debe hacer. Casi todo el mundo describe lo que quiere y se para ahí. La instrucción que más tiempo ahorra es la que descarta cosas — no toques el módulo de auth, no añadas dependencias, no cambies el schema de la base de datos. Los modelos son complacientes y harán encantados algo útil que tú no querías.
Ejecútalo antes de creértelo. Código generado que parece correcto y no arranca es el fallo suelto más común, y el más barato de detectar.
Date cuenta de cuándo el prototipo dejó de ser un prototipo. Suele haber un momento concreto: alguien más lo abre, o se pone delante de un usuario, o lo despliegas. Ése es el momento en que el intercambio cambia, y la respuesta honesta es volver atrás y leerlo bien.
Cómo es una buena sesión, de principio a fin
En concreto, porque «mantén las sesiones cortas» es un consejo con el que puedes estar de acuerdo y aun así no aplicar:
- Empieza desde un commit. No desde un repositorio ordenado: desde uno con commit. Éste es el punto de guardado, y cuesta diez segundos.
- Di el objetivo y el límite en el mismo mensaje. Lo que quieres, y lo que está prohibido. La segunda mitad es la que la gente se salta.
- Déjalo trabajar sin interrumpir. Corregir el rumbo a mitad de vuelo produce un cambio que es medio de un plan y medio de otro, y eso es más difícil de leer que cualquiera de los dos.
- Lee el diff, no el código base. Cuántos ficheros, cuáles, y si se ha borrado algo que no pediste borrar.
- Ejecútalo. Antes de creerte nada.
- Haz commit, o tira la sesión entera. Los dos son resultados aceptables. El que no lo es: arrastrar un estado a medias hasta la siguiente sesión.
Alrededor de una hora es donde esto suele caer para la mayoría, y el número importa menos que la forma: la sesión es la unidad que puedes tirar. En cuanto una sesión lleva tanto tiempo que descartarla resulta impensable, has perdido la propiedad que hacía segura toda la aproximación — y eso pasa de forma gradual, que es justo por lo que vale la pena vigilarlo.
Las preguntas que la gente hace de verdad
«¿Sigo siendo un desarrollador de verdad si hago esto?»
La pregunta de debajo es si estás construyendo una habilidad o esquivándola. Estás construyendo una — triage, especificación, saber dónde vive el riesgo — y no es la misma habilidad que escribir tú la sintaxis. Las dos son reales. Ninguna se basta sola.
«¿Cómo evito que invente bibliotecas que no existen?»
Ejecuta el código. Los imports alucinados fallan de inmediato, lo que convierte a éste en el tipo de error menos peligroso. Preocúpate más por los que sí arrancan.
«Ha reescrito algo que no le pedí que tocara.»
Muy común, y el arreglo normal es decir qué está prohibido antes de empezar. En un repositorio en el que trabaja más gente, esto deja de ser una molestia y pasa a ser el problema de verdad — que tiene su propio post.
«¿Debería hacer commit de código que no he leído?»
En algo desechable, sí. En algo compartido, le estás entregando a tus compañeros un diff sobre el que no puedes responder preguntas, y eso es un problema social antes que técnico.
«¿Así es como trabajan ahora los equipos profesionales?»
En parte, y honestamente la respuesta todavía se está moviendo. Lo que sí está claro es que la restricción se ha desplazado de con qué rapidez se puede escribir esto a con cuánta confianza se puede cambiar después, y los equipos que van bien son los que tratan eso como el eje del diseño.
Hacia dónde va esto, y qué hacemos nosotros
Todo lo anterior funciona para una persona sola en su máquina. Los fallos interesantes empiezan cuando el repositorio es compartido — cuando el código generado es localmente razonable y globalmente equivocado porque el modelo no podía ver una convención que vive en la cabeza de alguien.
Ése es el problema en el que trabaja CommitCycle: cada agente recibe un grant atado a una task y a una rama que caduca por sí solo, los paths que harían daño llevan un owner, y cada task cierra con un registro de lo que declaró frente a lo que tocó.
Siendo claros sobre dónde está eso: el plugin instala hoy el enforcement, y el paquete commitcycle de npm instala la CLI — el proceso sin el muro. El board alojado es sólo por invitación mientras esto es pequeño. Y nada de eso es lo que necesitas en tu primera semana de vibe coding — en tu primera semana necesitas sesiones cortas y el hábito de leer las partes caras.
La semana siguiente, cuando ya hayas decidido que la cosa va a existir más allá del viernes, la pregunta pasa de hábitos a setup: qué tener montado antes del primer prompt, y por qué está ahí cada pieza.