Cómo trabajamos Fer y yo el mismo proyecto con IA en paralelo

Dos personas. El mismo proyecto. Dos agentes de IA trabajando a la vez.

Suena a idea brillante hasta que los dos agentes tocan el mismo archivo con diez minutos de diferencia y te encuentras el proyecto hecho un cristo.

Nos pasó. Y de ahí salieron cuatro reglas que ahora nos parecen obvias y que nadie nos había contado.

¿Qué teníamos antes?

Un proyecto compartido y dos formas de trabajar completamente distintas.

Yo trabajo con Claude Code en la terminal, con instrucciones largas y mucho contexto cargado. Fer trabaja más a ráfagas, tareas cortas, y con un estilo bastante más ordenado que el mío.

Mientras cada uno tocaba su parte, no pasaba nada. El problema empezó cuando los dos empezamos a tocar la misma zona.

Porque una cosa es que dos personas editen el mismo proyecto (eso está resuelto desde hace treinta años) y otra muy distinta es que dos agentes de IA hagan cambios amplios en el mismo proyecto al mismo tiempo. Un humano toca tres líneas. Un agente al que le pides "reorganiza esto" toca cuarenta archivos en dos minutos.

Y ahí el sistema de siempre se te queda corto, no porque falle, sino porque no está pensado para ese ritmo.

El día que se lió

Yo le pedí a mi agente que reordenara la estructura de una parte del proyecto. Se puso a ello. Movió archivos, renombró cosas, actualizó referencias. Trabajo limpio.

Fer, a la vez, le estaba pidiendo al suyo que añadiera una función nueva. También trabajo limpio.

El problema es que la función de Fer se escribió en el sitio donde los archivos estaban antes. Y mi reorganización pasó por encima de un sitio que ya no era el mismo sitio que Fer creía.

Cuando juntamos las dos versiones, la cosa no explotó. Eso habría sido lo cómodo. Lo que pasó fue peor: se juntó sin protestar, y quedó una versión que parecía correcta y no lo era. Referencias apuntando a archivos que ya no existían con ese nombre, funciones duplicadas en dos sitios.

Tardamos una tarde entera en desenredarlo. Y no había forma de saber quién había hecho qué, porque los dos habíamos hecho cambios enormes con mensajes del tipo "reorganización" y "función nueva".

¿Cómo se trabaja en equipo con agentes de IA?

Con cuatro reglas. Las escribo tal cual las tenemos.

Regla uno: una zona por persona, y se dice en voz alta.

Antes de ponerse, cada uno dice en qué parte va a trabajar. Literalmente, un mensaje: "voy a tocar la zona de administración toda la mañana". No es burocracia, son cinco segundos, y evita el ochenta por ciento de los choques.

Y si los dos necesitamos la misma zona, uno espera. No hay una forma elegante de que dos agentes reorganicen lo mismo a la vez. La solución elegante es no hacerlo.

Regla dos: cambios pequeños y frecuentes, nunca la gran reforma.

Antes yo trabajaba en bloques grandes. Una tarde entera de cambios y al final lo subía todo junto. Con un agente, un bloque grande son cientos de líneas modificadas, y juntar eso con lo de otra persona es imposible de revisar.

Ahora la unidad es mucho más pequeña: una cosa, se prueba, se sube. Varias veces al día. Si algo choca, choca en algo pequeño y se arregla en cinco minutos.

Regla tres: las reglas del proyecto están escritas en el proyecto.

Esta es la que más nos cambió la vida.

En la raíz del proyecto tenemos un archivo con las instrucciones: cómo se nombran las cosas, dónde va cada tipo de archivo, qué está prohibido tocar, qué convenciones seguimos. Los dos agentes lo leen antes de hacer nada.

Antes de eso, mi agente escribía con mis manías y el de Fer con las suyas, así que el proyecto tenía dos estilos peleándose. Con el archivo de reglas, los dos agentes escriben igual aunque las personas de delante seamos distintas.

Y hay un efecto secundario que no esperaba: escribir esas reglas nos obligó a ponernos de acuerdo en cosas que llevábamos meses haciendo cada uno a su manera sin hablarlo.

Regla cuatro: nadie sube nada que no haya leído.

Un agente puede generar en dos minutos más cambios de los que puedes revisar en veinte. La tentación de aceptar sin mirar es enorme, sobre todo cuando lleva veinte veces seguidas acertando.

La regla es simple: si no lo he leído, no sale. Y si es demasiado para leerlo, es que el cambio era demasiado grande, así que vuelta a la regla dos.

Esto ha frenado más de un desastre. No porque el agente haga cosas mal a menudo, sino porque cuando las hace mal las hace mal con una convicción impresionante.

La parte de control de versiones

Sí, usamos el sistema de control de versiones de siempre. No hay atajo mágico aquí.

Pero lo usamos de una forma bastante más disciplinada que antes, precisamente por la velocidad a la que se generan cambios. Cada tarea va en su rama, las ramas duran horas y no días, y los mensajes describen qué hace el cambio y no quién lo hizo.

Si esta parte te suena a chino, es la barrera más común para la gente que no viene de programar y tiene solución. Lo expliqué desde cero en usar GitHub con Claude Code sin saber Git, que es literalmente la guía que le pasé a una persona del equipo cuando entró.

Lo que no funcionó

Probamos que los dos agentes compartieran memoria del proyecto. Idea bonita, resultado malo: acababan arrastrando decisiones a medias del otro, sin el contexto de por qué se tomaron. Un agente leyendo notas sueltas de otro es como llegar a una reunión por la mitad.

Probamos también dividir por tipo de tarea en vez de por zona. Yo la parte de datos, Fer la parte visual. En teoría perfecto. En la práctica, casi ningún cambio real es solo de una cosa, así que acabábamos invadiéndonos igual. Dividir por zona del proyecto funciona mucho mejor que dividir por tipo de trabajo.

Y probamos hacer revisión cruzada de todo, cada uno revisando lo del otro antes de subir. Duró tres días. Con el volumen que genera un agente, eso no escala: pasas más tiempo revisando que trabajando. Ahora solo se revisa cruzado lo que toca zonas compartidas o lo que es delicado.

¿Qué haría distinto?

Escribiría el archivo de reglas el primer día, no el mes tres. Todo el desorden de estilo que tuvimos que limpiar después se habría evitado.

Y habría hablado antes de las zonas. Nos pasamos semanas dando por hecho que cada uno sabía dónde andaba el otro, cuando bastaba con decirlo.

Lo que sí hicimos bien desde el principio: mantener el proyecto pequeño y bien separado por partes. Cuando cada trozo está en su sitio, dos agentes trabajando en trozos distintos casi no se rozan. El caos aparece cuando todo está mezclado, y entonces da igual cuántas reglas te pongas.

Si vienes de fuera del mundo de la programación y todo esto te suena lejano, el punto de entrada está en Claude Code para no programadores. Y si quieres ver el resultado de trabajar así durante meses, contamos el proceso completo en la app interna que montamos entre Fer, Sara y yo.

Cuatro reglas. Ninguna es lista. Todas salieron de una tarde perdida arreglando algo que no se debería haber roto.

Si quieres montar tu propio sistema de trabajo con IA, con las reglas, el contexto y los flujos que hacen que funcione también cuando no estás solo, lo enseño entero aquí.

Ver Yo SA