5 antipatrones del vibecoding que arruinan un proyecto

El vibecoding no arruina un proyecto por sí solo. Lo arruinan tus hábitos, los que arrastras de la época en que escribías código despacio y a mano. Cuando un modelo genera cien líneas en tres segundos, cada mal hábito empieza a costar diez veces más, porque escala con la velocidad. A continuación, cinco antipatrones que aparecen en todos los proyectos rescatados después de dos meses de “entregar rápido”. Para cada uno: por qué duele, cómo saber que has caído en él y qué hacer al respecto.

Antipatrón 1: sin especificación y con prompts vagos

El error más común. Escribes “hazme un panel de administración” y le das a Enter. El modelo adivina. Adivina las tablas, adivina los roles, adivina si el filtrado se hace en el servidor o en el cliente. Algunas conjeturas salen bien y otras, fatal, y no tienes ninguna referencia con la que decir que adivinó mal.

Por qué duele: sin especificación, el “resultado correcto” no existe. Cualquier cosa que devuelva el modelo es igual de aceptable, así que te conformas con la primera versión que compila. Una semana después tienes diez pantallas, y cada una interpreta “usuario” de forma distinta.

Síntoma: muchas rondas de “no, así no, corrígelo”. Si mantienes con el agente un diálogo de cinco o seis turnos para llegar a lo que tenías en la cabeza desde el principio, la especificación vivía en tu cabeza, no en el prompt.

Solución: antes de pedir código, escribe una descripción breve: de tres a cinco frases sobre entradas, salidas y restricciones. No hace falta que sea un documento formal; basta con una lista: qué recibe la función, qué devuelve, qué queda fuera del alcance, cuáles son los casos límite. Para cambios más grandes (más de unos pocos archivos), escribe un SPEC.md de verdad y pide al agente que primero resuma cómo ha entendido la tarea, antes de escribir una sola línea.

Antipatrón 2: aceptar el código generado sin leerlo

El diff tiene 200 líneas, parece razonable, los tests están en verde, así que haces clic en “accept all”. Ese es el momento en que dejas de ser ingeniero y te conviertes en una cinta transportadora entre el modelo y el repositorio.

Por qué duele: los modelos generan código que parece funcionar. Las cosas sutiles (una condición invertida, un caso de lista vacía que se olvidó, un catch que se traga el error) pasan la prueba visual de “parece que está bien”. Peor aún: un modelo añadirá encantado una dependencia que no necesitas o duplicará lógica que ya existe tres carpetas más allá. Si no lees, la deuda se acumula en silencio.

Síntoma: no sabes explicar por qué funciona una función concreta. Cuando un compañero pregunta “¿por qué hay aquí un setTimeout de 250 ms?”, respondes “lo puso el modelo”. Es una señal de alarma: el código que no entiendes es código que no puedes mantener.

Solución: lee cada línea que apruebas como si estuvieras revisando el código de un compañero. Si un diff es demasiado grande para leerlo con atención, es demasiado grande para un solo commit: pide pasos más pequeños. Pregunta al agente “¿por qué así y no de otra forma?” ante cualquier fragmento que te sorprenda. Trata el código generado como un PR de un junior rapidísimo pero con un exceso de confianza.

Antipatrón 3: saltarse los tests porque “funciona”

Haces clic por la aplicación, todo funciona, así que ¿para qué perder tiempo con tests? El vibecoding te tienta activamente a pensar así: como el código aparece tan rápido, los tests parecen un freno. Es una trampa que se cierra justo cuando el proyecto empieza a tener valor.

Por qué duele: “funciona” significa “funcionó una vez, en mi máquina, en el camino por el que casualmente hice clic”. Sin tests, cada nuevo cambio generado por el modelo es una apuesta: no sabes si ha roto algo tres módulos más allá. Y con el vibecoding los cambios son muchos y rápidos, así que la regresión te alcanza en un abrir y cerrar de ojos.

Síntoma: te da miedo hacer cambios. Cada refactor es una ruleta, porque la única verificación es hacer clic a mano. Los bugs que “ya estaban arreglados” vuelven una y otra vez. Es el clásico caso de trabajar sin red de seguridad.

Solución: escribe tests para lo que de verdad duele cuando se rompe: lógica de negocio, validación, cálculos, rutas de error. No persigas una cobertura del 100%; persigue la cobertura del riesgo. Los modelos son muy buenos generando tests, así que aprovéchalo: pide los tests antes de la implementación o junto con ella, y comprueba tú mismo que prueban el comportamiento y no la implementación. Un buen test en una ruta crítica vale más que diez sobre un getter.

Antipatrón 4: context rot, o meter todo el repo en el prompt

“Para que el modelo tenga todo el contexto”, le pegas cincuenta archivos o el repositorio entero. La intuición dice: cuanto más contexto, mejor. Aquí la intuición se equivoca.

Por qué duele: la atención de un modelo es un recurso finito. Cuantos más archivos irrelevantes metes, más se difumina la señal. El modelo empieza a mezclar convenciones de distintos módulos y a tomar patrones del código que casualmente estaba en la ventana, en lugar del código que importa. Esto se llama context rot: la calidad de las respuestas cae a medida que aumenta el ruido, aunque formalmente todo quepa en la ventana.

Síntoma: cuanto más larga es la sesión, peores son las respuestas. El modelo empieza a “olvidar” decisiones de hace diez mensajes, confunde nombres y propone soluciones incoherentes con el resto del proyecto. Pegas cada vez más y los resultados son cada vez más flojos.

Solución: dale al modelo solo lo relevante para la tarea: dos o tres archivos y una nota breve sobre la arquitectura, no todo el grafo de dependencias. Usa archivos como CLAUDE.md, donde dejas por escrito las convenciones una sola vez en lugar de pegarlas en cada prompt. Empieza una sesión nueva para cada tarea nueva: un contexto fresco y limpio gana a una conversación larga y abarrotada. Menos, pero más certero.

Antipatrón 5: megaprompts que piden todo a la vez

“Hazme autenticación con OAuth, un panel de usuario, un sistema de pagos, notificaciones por email y un dashboard de analítica”, todo en un solo prompt. El modelo producirá algo, porque siempre produce algo. La única pregunta es cuánto de eso se puede usar.

Por qué duele: cuanto mayor es el alcance de una sola respuesta, más decisiones toma el modelo sin ti y menos atención dedica a cada una. Obtienes cinco funcionalidades que funcionan a medias en lugar de una buena. Depurar se convierte en una pesadilla, porque cuando algo falla no sabes si el problema está en los pagos, en la autenticación o en cómo el modelo conectó una cosa con la otra. Todo está a medio hacer al mismo tiempo.

Síntoma: recibes un muro gigante de código que no puedes verificar ni fusionar con seguridad. Tu primera reacción es “OK, pero ¿por dónde empiezo siquiera a revisar esto?”. Si la respuesta a un prompt no cabe en una revisión razonable, el prompt era demasiado grande.

Solución: divide la tarea en los pasos razonables más pequeños y entrégalos de uno en uno. Primero la autenticación: léela, pruébala, fusiónala. Luego el panel. Después los pagos. Cada paso termina con una pieza que funciona y está verificada, sobre la que se apoya la siguiente. Parece más lento y en realidad es más rápido, porque no vuelves atrás constantemente para desenredar la madeja. Prompts pequeños, diffs pequeños, riesgo pequeño.

Por qué estos cinco van de la mano

Estos antipatrones se refuerzan entre sí. Sin especificación (1), no sabes qué buscar al leer un diff (2). Como de todas formas no lees, ¿para qué molestarse con tests (3)? Para que el modelo “lo deduzca solo”, le metes todo (4) y le pides todo a la vez (5). Cada uno por separado es superable; juntos dan lugar a un proyecto que funciona en la demo y se desmorona con el primer usuario real.

Comparten un denominador común: le cedes al modelo decisiones que deberían quedarse contigo. El vibecoding no es “el modelo lo hace por mí”, sino “el modelo escribe, yo decido”. Cuando esa línea se difumina, la velocidad se convierte en deuda.

TL;DR

Cinco antipatrones que arruinan un proyecto: (1) sin especificación y con prompts vagos: escribe una descripción breve de entradas, salidas y restricciones antes de pedir código; (2) aceptar código sin leerlo: lee cada línea como si estuvieras revisándola; (3) saltarse los tests porque “funciona”: prueba el riesgo, no los porcentajes; (4) context rot: pasa solo los archivos relevantes y empieza sesiones nuevas; (5) megaprompts: divide en pasos pequeños y verificables. La cura común: quédate tú con las decisiones y deja al modelo solo el tecleo.