Agentes de IA programando en paralelo: gobernanza para proyectos web a medida

Los agentes de programación en paralelo tienen sentido cuando el proyecto se puede dividir en entregables limitados, verificables y con pocas dependencias compartidas. No deberían ser la opción predeterminada si varios trabajadores deben interpretar el mismo requisito, modificar los mismos archivos o tomar decisiones difíciles de revertir. Anthropic documenta cinco mecanismos de Claude Code para trabajar con varias tareas: subagentes, vista de agentes, equipos, proyectos y flujos dinámicos.

La regla operativa de CreatikLab es exigir cinco elementos antes de delegar: resultado esperado, superficie de cambio autorizada, comprobaciones obligatorias, condición de parada y persona que acepta o rechaza. Si alguno falta, abrir más sesiones incrementa la producción, pero no crea necesariamente software entregable.

Anthropic no promete que estas modalidades reduzcan plazos, costes o defectos. Sí advierte que varias sesiones o varios subagentes ejecutándose a la vez multiplican el uso de tokens. La decisión debe justificarse con resultados aceptados y evidencia, no con una demostración llamativa.

Un subagente realiza una tarea lateral en su propio contexto dentro de una sesión y devuelve un resumen. La vista de agentes, descrita como vista previa de investigación, permite despachar y vigilar sesiones independientes en segundo plano. Los equipos reúnen sesiones coordinadas, una lista compartida, mensajería y un agente principal; Anthropic los clasifica como experimentales y desactivados por defecto.

Los proyectos mantienen una conversación de larga duración y abren hilos paralelos en la nube con repositorios, instrucciones y memoria. La disponibilidad indicada es beta pública en Pro y Max. Los flujos dinámicos emplean un script para lanzar varios subagentes y contrastar resultados, especialmente cuando el trabajo requiere más escala o varias pasadas.

Anthropic también documenta los worktrees para separar checkouts de Git. Esa separación no se aplica a los compañeros de un equipo de agentes, por lo que deben asignarse archivos o componentes distintos. Para incorporar otra herramienta se puede exponer como servidor MCP. Ninguna de estas capacidades define por sí sola la política de calidad, seguridad o aprobación de una empresa.

Antes de elegir modalidad, clasifica cada acción por impacto. Leer código, recopilar registros y proponer un plan suelen admitir una revisión sencilla. Editar dependencias, cambiar contratos de API, migrar datos o desplegar requieren controles progresivamente más estrictos. Esta clasificación es metodología de CreatikLab; Claude Code no asigna automáticamente el nivel de riesgo empresarial.

Decide qué puede ejecutar el agente, qué necesita aprobación previa y qué queda fuera de la automatización. Documenta el acceso a archivos, red, secretos, servicios externos y entornos. Un permiso técnicamente disponible no equivale a un permiso empresarial concedido.

Reserva para una persona identificada la aceptación de arquitectura, credenciales, migraciones destructivas y publicación en producción, salvo que exista una política explícita con controles equivalentes. La responsabilidad no puede delegarse a una conversación que se declara satisfecha con su propio trabajo.

• Tarea principal con investigación lateral: subagente. Evidencia: hallazgos breves vinculados a archivos, comandos o registros. Responsable: sesión principal y revisor humano.
• Varias tareas independientes supervisadas por una persona: vista de agentes. Evidencia: brief, estado y aceptación separados para cada sesión. Responsable: quien despacha.
• Trabajo coordinado que necesita intercambio entre trabajadores: evaluar equipos solo tras registrar su carácter experimental y separar componentes. Evidencia: propiedad de tareas y mensajes. Responsable: líder técnico.
• Programa de trabajo prolongado con contexto estable: evaluar un proyecto. Evidencia: instrucciones mantenidas, decisiones registradas y puntos de intervención. Responsable: product owner o ingeniería.
• Proceso repetible, amplio o con contraste de resultados: flujo dinámico. Evidencia: orquestación versionada, entradas reproducibles y resolución de discrepancias. Responsable: mantenedor del flujo.

Cuando dos opciones parecen válidas, elige la que tenga menos coordinación y una frontera de aceptación más nítida. Pasa a un modelo más complejo solo si el anterior no conserva el contexto o no permite verificar el resultado.

La matriz no asigna agentes por organigrama. Asigna mecanismos según la forma del trabajo. Dos tareas de equipos distintos pueden compartir el mismo estado técnico y, por tanto, no ser seguras en paralelo.

Representa cada paquete como independiente, secuencial o de estado compartido. Los independientes pueden ser candidatos a concurrencia. Los secuenciales esperan una salida anterior validada. Los de estado compartido necesitan un único propietario o un protocolo explícito de integración. El dibujo debe incluir archivos, contratos, datos y entornos, no solo nombres de tickets.

En una plataforma web a medida podrían existir carriles de verificación funcional, interfaz, backend, migración, pruebas automáticas y accesibilidad. Eso no implica dedicar un agente a cada carril. La entrada debe ser estable, el área de modificación debe estar delimitada y el resultado tiene que poder comprobarse sin confiar en la explicación del trabajador.

Si dos paquetes tocan el mismo contrato, serialízalos o designa un propietario integrador. Si una tarea depende de una decisión todavía abierta, detén la ejecución. Paralelizar incertidumbre suele producir variantes incompatibles que después consumen revisión humana.

El contrato de tarea debe incluir objetivo, exclusiones, entradas autorizadas, repositorios o directorios permitidos, comandos admitidos, artefactos esperados y condiciones de parada. También debe identificar las suposiciones que necesitan confirmación. “Mejora la web” no ofrece un criterio de aceptación; una incidencia reproducible, un límite de archivos y una batería de pruebas sí lo hacen.

El expediente puede reunir inventario de cambios, resumen del diff, resultados de pruebas, capturas, trazas del navegador, revisión de seguridad, vista previa de migración y preguntas pendientes. No todos los proyectos necesitan todos los elementos, pero cada requisito debe responder a un riesgo concreto.

Escribe también el criterio de rechazo. Rechaza el resultado si rebasa el alcance, modifica un componente no asignado, carece de pruebas exigidas, no explica un fallo o no puede reproducirse. Definirlo antes evita aceptar trabajo débil solo porque ya consumió tiempo o tokens.

1. Topología de tareas — Evidencia: mapa de dependencias y cambios permitidos. Acción: dividir o serializar solapamientos. Responsable: líder técnico.
2. Cadena de instrucciones — Evidencia: normas vigentes por repositorio y directorio. Acción: eliminar contradicciones y fijar precedencia. Responsable: mantenedor.
3. Aislamiento — Evidencia: asignación de rama, worktree o entorno. Acción: impedir escrituras concurrentes sobre un componente. Responsable: ingeniería de entrega.
4. Permisos — Evidencia: lista de herramientas, red, secretos y despliegues. Acción: mínimo privilegio y aprobaciones. Responsable: seguridad.
5. Validación — Evidencia: comprobaciones ejecutables y salidas esperadas. Acción: separar generación y verificación cuando el riesgo lo exija. Responsable: QA o revisor.
6. Coste — Evidencia: consumo por tarea y por resultado aceptado. Acción: detener bucles improductivos. Responsable: propietario del presupuesto.
7. Integración — Evidencia: diff revisado, pruebas superadas y reversión. Acción: bloquear el merge si falta el expediente. Responsable: aprobador humano.
8. Incidentes — Evidencia: registros, identificadores y recuperación. Acción: preparar parada, revocación de accesos y restauración. Responsable: líder de incidente.

La auditoría no se cierra con una política escrita. Cada control debe poder inspeccionarse en una configuración, una prueba, un registro o una aprobación.

Mide el embudo de entrega: tareas iniciadas, aceptadas sin retrabajo, rechazadas, tiempo de revisión humana, defectos detectados después de integrar, reversiones y consumo total. Compara trabajos equivalentes; una investigación de registros no sirve como referencia para una migración amplia.

Especifica tasa de aceptación por clase de tarea, esfuerzo de revisión por cambio aceptado, motivos de retrabajo, uso por resultado y fase en la que aparece cada defecto. Registra primero una línea base del proceso humano o de una sola sesión. Una entrega correcta aislada no demuestra una mejora causal.

Si el sistema capta demanda, separa calidad técnica y calidad comercial. Define el lead cualificado mediante campos o etapas acordadas en el CRM y comprueba formularios, atribución, consentimiento y traspaso tras cada publicación. Más formularios enviados no prueban mejor software; más despliegues tampoco prueban una mejor captación.

Más agentes no garantizan menos tiempo transcurrido. La coordinación, la investigación duplicada y la revisión pueden consumir la ventaja de la concurrencia. Conversaciones distintas tampoco garantizan archivos aislados: Anthropic aclara que los compañeros de un equipo no disponen de aislamiento por worktrees.

El aumento de tokens es una consideración confirmada, pero la documentación no establece un coste universal. Tampoco promete resultados deterministas, cumplimiento normativo, menos vulnerabilidades, despliegues seguros ni integración con el proceso interno de una organización. Esas condiciones deben probarse en el entorno real.

Audita instrucciones obsoletas, permisos excesivos, cambios incompatibles, dependencias implícitas y saturación del equipo revisor. Son riesgos del diseño operativo, no tasas de fallo atribuidas a Claude Code. Las defensas son tareas pequeñas, observabilidad, validación separada y condiciones de parada estrictas.

Comienza con una tarea reversible y de impacto bajo cuyo resultado correcto ya conozcas. Ejecuta el contrato, recopila consumo y revisión, y registra defectos. Añade después una segunda tarea realmente independiente. Solo cuando ambas produzcan evidencia aceptable tiene sentido probar coordinación entre trabajadores o actividades de mayor duración.

Para comparar proveedores, solicita un ejemplo de contrato, expediente de aceptación, control de permisos, informe de consumo y procedimiento de incidente. Valora la trazabilidad y la calidad de los límites, no la cantidad de agentes o líneas generadas.

El diagnóstico principal de CreatikLab es una auditoría de preparación para entrega con agentes paralelos: topología, instrucciones, permisos, aislamiento, validación, observabilidad, coste y reversión. Puedes definir su alcance desde el servicio de automatización con IA y sistemas a medida y convertir los hallazgos en un piloto con un Experto en IA.

Explica a Lia qué sistema quieres construir, qué repositorios y herramientas intervienen, dónde se bloquea hoy la entrega y qué acciones deben seguir bajo aprobación humana. La respuesta será un diagnóstico contextual, no una promesa de ahorro, velocidad, volumen de leads o rendimiento.

¿Qué modalidades de trabajo paralelo documenta Claude Code?

Anthropic documenta cinco: subagentes, vista de agentes, equipos de agentes, proyectos y flujos dinámicos. Cambian el responsable de coordinar, la comunicación entre trabajadores y el lugar de ejecución.

¿Para qué conviene un subagente?

Anthropic lo plantea como un trabajador delegado dentro de una sesión. En el método de CreatikLab encaja con investigaciones acotadas, análisis de registros o tareas laterales que devolverán un resumen verificable.

¿Los equipos de agentes están aislados mediante worktrees?

No debe suponerse. Anthropic indica que los compañeros de un equipo no se aíslan mediante worktrees. También define los equipos como experimentales y desactivados por defecto.

¿Ejecutar más agentes reduce el coste?

No existe esa garantía. Anthropic advierte que ejecutar varias sesiones o subagentes simultáneamente multiplica el uso de tokens. El coste debe calcularse por resultado aceptado y no por sesión terminada.

¿Qué debe contener la evidencia de aceptación?

Como mínimo, alcance, archivos modificados, pruebas realizadas, resultados de validación, asuntos pendientes, revisión humana y plan de reversión cuando proceda. Los requisitos exactos dependen del riesgo del sistema.

¿Cómo se compara a dos proveedores de desarrollo con agentes?

Conviene exigir sus reglas de partición, diseño de aislamiento, permisos, puertas de aprobación, registros de costes, respuesta a incidentes y un ejemplo de expediente de aceptación. La cantidad de código generado no demuestra calidad.