Qué se rompe cuando el vibe coding llega a un repositorio compartido

Todo lo del vibe coding cambia cuando el repositorio tiene a más gente dentro. No porque el código empeore, sino porque la manera en que falla deja de ser visible.

En tu propia máquina, un error aparece como algo que no funciona. En un repositorio compartido, el fallo característico es código que funciona, se lee razonable, pasa la revisión y aun así está mal — porque rompió una regla que nunca se escribió en ningún sitio que el modelo pudiera leer.

Cómo es la forma

A un agente se le pide añadir un campo a un formulario. Lo hace, con competencia. También añade una migración de base de datos, porque eso es lo que normalmente hace falta para añadir un campo.

La migración está bien. El problema es que este equipo aplica las migraciones a mano, en un orden concreto, después de una revisión de la persona que es owner del schema — una convención que existe por un incidente de hace dieciocho meses, la conocen cuatro personas, y no está escrita en ninguna parte.

Nada en ese diff parece mal. Ése es el fallo. No es código malo; es código localmente razonable y globalmente equivocado, y la distancia entre esas dos cosas es exactamente la distancia entre lo que hay en el repositorio y lo que hay en la cabeza de alguien.

¿Por qué no lo detecta la revisión?

La revisión lee el diff y pregunta si es bueno. Esta clase de problema es invisible para esa pregunta, porque el diff sí es bueno. El defecto vive en la relación entre el cambio y una pieza de contexto que no está en pantalla.

Quien revisa lo detecta sólo si da la casualidad de que lleva la convención encima y de que se acuerda de ella mientras lee. Eso funciona, a veces, cuando quien revisa es una de esas cuatro personas. Deja de funcionar en cuanto sube el volumen — y que suba el volumen es justo el sentido de usar agentes.

Así que el consejo habitual, revisa el código generado por IA con más cuidado, es medio cierto y no escala. Revisar línea a línea y con cuidado todo elimina la razón de generarlo para empezar.

¿Cuál es el fallo que más cuesta?

Dos agentes, a la vez, en el mismo repositorio.

Cada uno es correcto por separado. Cada uno pasa sus propios tests. Uno refactoriza un helper del que el otro depende; o los dos tocan la misma configuración desde direcciones opuestas; o uno mueve un fichero en el que el otro está escribiendo. Nada falla. Las dos ramas están en verde.

La pérdida aparece días después como un cambio que se hizo y luego ya no estaba, y nadie sabe decir cuándo dejó de existir. Es caro precisamente porque no hay un momento de fallo al que señalar — estás reconstruyendo un negativo a partir del historial de git.

Esto no es hipotético y no es raro. Es la consecuencia ordinaria de correr más de un agente en un repositorio, que hoy es un martes cualquiera.

¿Cómo sé si esto ya está pasando?

No llega como un incidente, y ésa es la dificultad. Llega como un conjunto de hechos pequeños que cada uno tiene una explicación individual plausible:

• Trabajo que se hizo y luego no estaba. Alguien recuerda haberlo escrito. Git dice que existió. Nadie puede nombrar el commit que lo quitó.
• El mismo bug arreglado dos veces, con tres semanas de diferencia, por dos personas que cada una creía ser la primera.
• Una convención reexplicada en tres sesiones distintas, porque cada sesión empezó sin memoria de la anterior y nadie la escribió entre medias.
• Un pull request que toca ficheros que nadie esperaba, donde los ficheros de más son todos individualmente defendibles.
• «¿Quién cambió esto?» respondido por un mensaje de commit que dice refactor y un autor que no estaba leyendo con atención.

Cualquiera de éstas por separado es una mala semana normal. Todas juntas son el fallo, y la razón por la que se queda sin nombre tanto tiempo es que no hay ningún error que buscar. Estás buscando la ausencia de algo, y las ausencias no avisan a nadie.

¿Y si las otras personas son mis propios agentes?

La inversión que pilla a más gente: no necesitas un equipo para tener un problema de repositorio compartido. Con dos terminales basta.

Un repositorio no sabe que dos sesiones pertenecen al mismo humano. Todas las propiedades que hacen esto difícil en un equipo están presentes cuando estás solo — escrituras concurrentes a los mismos ficheros, ninguna memoria compartida entre las sesiones, convenciones que existen sólo en tu cabeza — y una propiedad es estrictamente peor. En un equipo, el trabajo del segundo agente al menos lo lee una persona distinta. Cuando los dos son tuyos, apruebas los dos, rápido, la misma tarde, y no hay un segundo lector en ninguna parte del circuito.

Por eso «soy desarrollador en solitario, esto no va conmigo» suele ser falso ya en el momento en que alguien lo dice. El umbral no es el número de personas. Es el número de cosas escribiendo en el repositorio a la vez.

¿AGENTS.md y CLAUDE.md arreglan esto?

La respuesta estándar es un CLAUDE.md o un AGENTS.md con tus convenciones dentro. Escríbelo. Ayuda de verdad, y es lo más barato de esta lista.

También se degrada, por la misma razón por la que se degrada toda la documentación: es una foto de lo que alguien recordaba el día que lo escribió, y nada obliga a revisarlo cuando cambia aquello que describe. Seis meses después es una mezcla de cierto, caducado y aspiracional, y un agente que lo lee no puede distinguir qué línea es cuál. Una persona recién incorporada tampoco.

Un fichero de contexto es necesario y no es suficiente, y el hueco entre esas dos cosas es donde está el trabajo interesante.

¿Qué ayuda de verdad?

Nombra los paths donde equivocarse sale caro. No todo — la mayor parte de un repositorio es genuinamente segura de cambiar, y tratarlo todo como peligroso significa que nada lo es. Una lista corta de los paths que harían daño vale más que una exhaustiva, porque una lista corta se lee.

Dale a cada uno un owner. No por burocracia: para que «¿esto debería cambiar?» tenga a quién preguntar. Una regla sin owner es una regla que se esquiva al primer inconveniente, tanto por humanos como por agentes.

Acota el trabajo antes de que empiece, no después. Qué debe hacer esto, qué no debe hacer, qué áreas toca. Escrito antes de que el código exista, eso es una especificación. Escrito después, es una excusa.

Haz posible ver qué tocó de verdad una pieza de trabajo, frente a lo que dijo que tocaría. Esa diferencia es donde están las sorpresas, y es una pregunta que git puede responder si alguien se la hace.

Nada de eso necesita un producto. Necesita que la lista exista en algún sitio que puedan leer tanto las personas como los agentes.

¿Qué puedo hacer el lunes, sin comprar nada?

En orden, porque hacer las dos primeras es la mayor parte del valor:

1. Escribe los cinco paths donde equivocarse sale caro. Cinco, no cincuenta — el sentido es que la lista se lea. Migraciones, auth, el código de pagos, la configuración compartida, los que sean los tuyos.
2. Pon un nombre junto a cada uno. Para que «¿esto debería cambiar?» tenga a dónde ir. No hace falta que sea un owner formal; hace falta que sea una persona.
3. Empieza cada pieza de trabajo diciendo qué no debe tocar. Una línea, antes de que el código exista. Ésta es la frase de mayor rendimiento del desarrollo agéntico y no cuesta nada.
4. Una vez a la semana, mira qué cambió de verdad frente a lo que creías que se estaba trabajando. No una revisión del código: una comparación de dos listas. El hueco es donde viven las sorpresas, y una vez a la semana basta para pillarlas mientras siguen siendo baratas.

Nada de eso es un producto y nada de eso necesita permiso. Si resulta que te importa, la siguiente pregunta es qué lo impone cuando todo el mundo está ocupado — que es donde el resto de esto se pone interesante.

Dónde encaja CommitCycle

Esa lista es la cosa sobre la que construimos. Las zones son los paths que harían daño, cada una con un owner y un risk level. Una task declara lo que toca antes de empezar, y mover un muro requiere una aprobación con un motivo. Cada agente recibe un grant atado a una task y a una rama que caduca por sí solo, así que dos sesiones en sus propios worktrees no pueden autorizarse mutuamente en silencio — si comparten un mismo directorio, todavía pueden, y por eso el worktree es la instrucción y no una preferencia. Cada task cierra con un registro de lo que declaró frente a lo que tocó.

Dónde está de verdad, dicho llanamente: el enforcement se instala hoy como plugin de Claude Code; el paquete commitcycle de npm pone cycle en tu PATH y no lleva hook, así que te da el proceso sin el muro. El board alojado es sólo por invitación mientras esto es pequeño. El modelo de zones es agnóstico del agente, pero el punto de enforcement necesita un pequeño adaptador por harness, y hoy se publica exactamente uno.

Y el límite honesto que merece la pena repetir: denegar una llamada a una herramienta en vuelo no es lo que hace esto distinto. Varios fabricantes lo publican y Claude Code lo incluye gratis. La parte que es nuestra es el grant atado a una única task, atribuido a un owner, y que caduca por sí solo — y el registro posterior que dice qué pasó de verdad.

Si eres una persona sola con un prototipo, nada de esto es tu problema todavía, y el post de los primeros pasos es el más útil — o el del setup, si el prototipo ha empezado a parecer que sobrevivirá al mes.