Lo que el sistema Task de Claude Code revela sobre el ingeniero AI-nativo

La semana pasada, Claude Code renombró discretamente Todo a Task. Parece un simple cambio de terminología, pero marca el comienzo de un sistema completamente diferente.

Todo era una lista que Claude mantenía solo: la memoria personal de un único agente. Task es una unidad de trabajo compartida entre múltiples agentes. Esa diferencia cambia el paradigma de las herramientas de codificación con IA.

En otras palabras, nació una nueva unidad de abstracción necesaria para los enjambres de IA.

La clave es la delegación, no la automatización

El antiguo Claude Code era un solo cerebro. Si le dabas un proyecto complejo, se olvidaba de los pasos anteriores a medio camino, y terminabas reiniciando alrededor del 60% una y otra vez.

El nuevo sistema Task tiene una arquitectura fundamentalmente distinta:

• Le hablas a un líder de equipo. El líder no escribe código directamente. Planifica, delega y sintetiza.
• Una vez que apruebas el plan, se crean agentes especialistas que trabajan en paralelo.

Esto no es automatización, es delegación. La diferencia importa. Automatizar es programar una secuencia conocida. Delegar es definir resultados y confiar en un equipo estructurado para que encuentre el camino de ejecución.

El grafo de dependencias es el arma real

La característica central del sistema Task son las dependencias entre tareas (blockedBy). La tarea 3 no puede arrancar hasta que las tareas 1 y 2 estén completas.

¿Por qué importa tanto?

Antes, Claude tenía que mantener todo el plan en la cabeza. Conforme el contexto se hacía más largo, naturalmente se le iban olvidando partes del plan. Entre más duraba la sesión, más se acumulaba la desviación.

Ahora el plan mismo está externalizado y estructurado. Aunque el contexto se comprima o un agente sea reemplazado, el plan sobrevive. El grafo de dependencias funciona como una capa de coordinación persistente que trasciende la memoria de cualquier agente individual.

El procesamiento paralelo viene de regalo

Asigna de siete a diez tareas y el sistema ya no las procesa una por una. Las tareas sin dependencias corren al mismo tiempo. Las búsquedas rápidas van a Haiku, la implementación a Sonnet, los juicios complejos a Opus: la asignación de modelos pasa automáticamente según las características de cada tarea.

Esta es una consecuencia directa del diseño estructurado de tareas. Entre más limpia sea la descomposición y mejor definidas las dependencias, más paralelismo extrae el sistema. No optimizas el paralelismo a propósito: lo obtienes como subproducto de una buena arquitectura de tareas.

El trabajo se vuelve orquestación

La documentación de Swarm revela patrones claros:

• Parallel Specialists: múltiples expertos revisan al mismo tiempo - seguridad, rendimiento, verificación de tipos, todo de una vez.
• Pipeline: investigación → planeación → implementación → pruebas - etapas secuenciales donde cada una depende de la anterior.
• Self-Organizing Swarm: los agentes jalan tareas de un pool compartido, agarrando las que no están bloqueadas ni asignadas.

El trabajo ya no es escribir código. Es diseñar qué agentes hacen qué, en qué orden y con qué dependencias entre ellos.

La eficiencia del Swarm depende del diseño de tareas

Hay tres palancas para optimizar el rendimiento de un Swarm:

• Granularidad de tareas: tareas más chicas aumentan la tasa de paralelización, pero la sobrecarga de comunicación entre agentes crece con cada división.
• Separación de roles: la especialización mejora la calidad, pero puede crear cuellos de botella en agentes con cargas desproporcionadas.
• Diseño de dependencias: estructurar qué debe terminar antes de que lo siguiente pueda arrancar sin bloqueos - esta es la topología de tu flujo de trabajo.

Según mis propios experimentos, la tercera palanca tiene el impacto más significativo. La granularidad y la separación de roles son relativamente intuitivas. El diseño de dependencias requiere pensar en la forma del trabajo en sí - lo que yo llamo diseño de topología de dependencias.

Esta es la verdadera habilidad de la era Swarm. No se trata de escribir código más rápido ni de elegir mejores modelos. Se trata de estructurar el flujo de trabajo para que la mayor cantidad de agentes pueda operar sin esperas.

De escribir código a diseñar cómo se trabaja

La progresión es clara:

Primero, escribíamos código. Luego, diseñábamos sistemas. Ahora, diseñamos la forma en que el trabajo se estructura.

No estás usando herramientas de IA. Estás dirigiendo un equipo de IA. La persona que entienda esta distinción primero va a dominar el próximo año del desarrollo de software.

El cambio de Todo a Task se ve chico en la superficie. Abajo, es el andamiaje de un mundo donde la producción principal del ingeniero no es código, sino la arquitectura de la colaboración entre máquinas.