O que o sistema Task do Claude Code revela sobre o engenheiro AI-nativo

Na semana passada, o Claude Code discretamente renomeou Todo para Task. Parece uma simples mudança de terminologia, mas marca o começo de um sistema fundamentalmente diferente.

Todo era uma lista que o Claude mantinha sozinho - a memória pessoal de um único agente. Task é uma unidade de trabalho compartilhada entre múltiplos agentes. Essa distinção muda o paradigma das ferramentas de codificação com IA.

Em outras palavras, surgiu uma nova unidade de abstração necessária para enxames de IA.

O ponto central é delegação, não automação

O antigo Claude Code era um cérebro único. Entregue um projeto complexo e ele esquecia os passos anteriores no meio do caminho, forçando você a recomeçar na marca dos 60%, repetidamente.

O novo sistema Task tem uma arquitetura fundamentalmente diferente:

• Você fala com um líder de equipe. O líder não escreve código diretamente. Ele planeja, delega e sintetiza.
• Uma vez aprovado o plano, agentes especialistas são criados e trabalham em paralelo.

Isso não é automação - é delegação. A diferença importa. Automatizar é programar uma sequência conhecida. Delegar é definir resultados e confiar em uma equipe estruturada para encontrar o caminho de execução.

O grafo de dependências é a arma real

A funcionalidade central do sistema Task são as dependências entre tarefas (blockedBy). A tarefa 3 não pode iniciar até que as tarefas 1 e 2 estejam concluídas.

Por que isso é tão importante?

Antes, o Claude precisava manter o plano inteiro na cabeça. Conforme o contexto ficava mais longo, ele naturalmente esquecia pedaços do plano. Quanto mais longa a sessão, mais desvio se acumulava.

Agora o plano em si é externalizado e estruturado. Mesmo quando o contexto é comprimido ou um agente é substituído, o plano sobrevive. O grafo de dependências funciona como uma camada de coordenação persistente que transcende a memória de qualquer agente individual.

O processamento paralelo vem de graça

Atribua sete a dez tarefas e o sistema não as processa mais sequencialmente. Tarefas sem dependências rodam simultaneamente. Buscas rápidas vão para o Haiku, implementação para o Sonnet, decisões complexas para o Opus - a alocação de modelos acontece automaticamente com base nas características de cada tarefa.

Isso é consequência direta de um design estruturado de tarefas. Quanto mais limpa a decomposição e melhor definidas as dependências, mais paralelismo o sistema extrai. Você não otimiza o paralelismo explicitamente - ele vem como subproduto de uma boa arquitetura de tarefas.

O trabalho vira orquestração

A documentação do Swarm revela padrões claros:

• Parallel Specialists: múltiplos especialistas revisam simultaneamente - segurança, performance, verificação de tipos, tudo ao mesmo tempo.
• Pipeline: pesquisa → planejamento → implementação → testes - etapas sequenciais onde cada uma depende da anterior.
• Self-Organizing Swarm: agentes puxam de um pool de tarefas compartilhado, pegando o que não está bloqueado nem atribuído.

O trabalho não é mais escrever código. O trabalho é projetar quais agentes fazem o quê, em que ordem e com quais dependências entre eles.

A eficiência do Swarm depende do design de tarefas

Existem três alavancas para otimizar a performance de um Swarm:

• Granularidade das tarefas: tarefas menores aumentam a taxa de paralelização, mas o overhead de comunicação entre agentes cresce a cada divisão.
• Separação de papéis: a especialização melhora a qualidade, mas pode criar gargalos em agentes com cargas desproporcionais.
• Design de dependências: estruturar o que precisa terminar antes que o próximo passo possa rodar sem bloqueio - essa é a topologia do seu fluxo de trabalho.

Nos meus próprios experimentos, a terceira alavanca teve o impacto mais significativo. Granularidade e separação de papéis são relativamente intuitivas. O design de dependências exige pensar na forma do trabalho em si - o que eu chamo de design de topologia de dependências.

Essa é a habilidade real da era Swarm. Não é escrever código mais rápido nem escolher modelos melhores. É estruturar o fluxo de trabalho para que o número máximo de agentes possa operar sem espera.

De escrever código a projetar como o trabalho é feito

A progressão é clara:

Primeiro, escrevíamos código. Depois, projetávamos sistemas. Agora, projetamos a forma como o trabalho em si se estrutura.

Você não está usando ferramentas de IA. Você está comandando uma equipe de IA. A pessoa que entender essa distinção primeiro vai dominar o próximo ano do desenvolvimento de software.

A mudança de Todo para Task é pequena na superfície. Por baixo, é a estrutura de um mundo onde o principal output do engenheiro não é código - é a arquitetura da colaboração entre máquinas.