Los desarrolladores ahora pueden iniciar varias sesiones de agentes de codificación a la vez sin temor a que se sobrescriban los archivos de estado o a que haya conflictos de archivos ocultos. Un patrón consultivo de tipo “share-nothing” aísla el espacio de trabajo de cada agente y advierte sobre posibles conflictos. Este enfoque sustituye los bloqueos estrictos por un registro ligero que señala el trabajo superpuesto antes de que ocurra, manteniendo la continuidad de los pipelines incluso cuando una sesión falla.

Por qué los agentes en paralelo causan problemas

Ejecutar más de un asistente de codificación automatizado en un único repositorio acelera la generación de código, las pruebas o la refactorización. En la práctica, surgen dos problemas de inmediato.

  • Corrupción de estado – Dos agentes escriben en el mismo archivo de estado; la escritura posterior sobrescribe la anterior, borrando el progreso.
  • Colisión de archivos – Dos agentes editan el mismo archivo fuente sin saber de la existencia del otro. El conflicto aparece más tarde, cuando un diff muestra cambios divergentes.

Ambos problemas hacen perder tiempo al desarrollador y pueden introducir errores difíciles de rastrear.

La regla de “share nothing”

La idea central es sencilla: cada agente tiene su propio espacio de trabajo privado en el disco y solo escribe en los archivos que pertenecen a esa sesión. Solo se permite un único archivo compartido deliberadamente por rama, y este sigue la regla de “el último en escribir gana” (last-writer-wins): el último agente en escribir determina el contenido final.

Una capa de presencia rastrea cada sesión activa:

  • Nombre de la rama
  • Lista de archivos que se están utilizando
  • Marca de tiempo de la última actividad

Cuando comienza una nueva sesión, esta consulta el registro. Si otra sesión ya está gestionando cualquiera de los mismos archivos, el desarrollador recibe una advertencia antes de que comience cualquier trabajo.

Bloqueos consultivos frente a bloqueos restrictivos

Los archivos de bloqueo tradicionales actúan como un camino sin salida: una vez que se toma un bloqueo, cualquier otro proceso debe esperar hasta que el bloqueo se libere. Si la sesión propietaria falla, el bloqueo puede persistir indefinidamente, obligando a una búsqueda manual de archivos de bloqueo obsoletos.

El modelo consultivo es más suave. Emite una advertencia cuando se detecta un conflicto potencial, pero no detiene la nueva sesión. Si una entrada del registro es antigua (es decir, el proceso que la creó ya no existe), el sistema simplemente emite una advertencia, dejando que el desarrollador decida si desea continuar.

Cómo implementar el patrón

  1. Particionar el estado por escritor – Asigne a cada agente su propio directorio para archivos temporales y estado. Reserve los archivos compartidos para datos verdaderamente globales y aplique la regla de “el último en escribir gana” solo allí.
  2. Inyectar conciencia al inicio – Antes de que un agente comience, lea el registro de presencia y compare la lista de archivos solicitados con las entradas existentes. Aborte o advierta si se encuentra una superposición.
  3. Verificar la actividad al momento de la lectura – Al consultar una entrada del registro, compruebe si el ID de proceso registrado todavía se está ejecutando en el SO. Descarte las entradas que pertenezcan a procesos terminados.
  4. Preferir lo consultivo sobre lo restrictivo – Permita que los desarrolladores mantengan el control. Una advertencia les permite continuar, pausar o cancelar, evitando el deadlock.
  5. Rastrear estados de espera – Cuando hay muchos agentes activos, la atención del desarrollador se convierte en el cuello de botella. Muestre qué agentes están esperando la intervención humana para que el trabajo pueda ser repriorizado.

Todo esto se puede construir con un simple directorio de archivos JSON; no se requiere una base de datos externa ni un bus de mensajes. El formato de almacenamiento sencillo hace que el sistema sea fácil de auditar y portátil entre entornos.

Riesgos y contraargumentos

Algunos equipos pueden argumentar que un bloqueo estricto garantiza la seguridad: ningún par de agentes podrá escribir nunca en el mismo archivo. La contrapartida es una menor resiliencia: las sesiones que fallan dejan bloqueos huérfanos que detienen todo el flujo de trabajo.

Qué tener en cuenta

Si está gestionando múltiples asistentes de código impulsados por IA, el patrón consultivo de “share nothing” ofrece una vía pragmática para evitar que se estorben entre sí. Al aislar el estado, exponer la intención de forma temprana y permitir que los humanos decidan cuándo proceder, el método equilibra la seguridad con la flexibilidad que exigen los pipelines de desarrollo modernos.