Ainda faz sentido atribuir tarefas a desenvolvedores quando agentes de IA escrevem o código?

Resposta curta: você ainda atribui o trabalho a uma pessoa, porque alguém tem de responder pelo resultado, mas a tarefa deixou de ser aquilo que você está atribuindo. A unidade que de fato move o código é a sessão do agente. Medido no repositório deste site em 13 de agosto de 2026: 214 dos 251 commits sem merge feitos entre 18 de julho e 10 de agosto de 2026 saíram de 24 sessões de agente de IA, e a sessão mediana produziu 7 commits em 48 minutos, tocando 21 arquivos. Uma tarefa dimensionada para uma pessoa trabalhar dois dias hoje é menor que uma sentada de um agente. Atribua a sessão, revise a sessão, e deixe a tarefa para o que ela sempre fez bem, que é dizer por que aquele trabalho existe.

O que mudou na unidade de trabalho quando os agentes de IA chegaram?

Antes dos agentes de IA de programação, tarefa e unidade de trabalho eram quase o mesmo objeto. O desenvolvedor pegava um cartão, trabalhava por horas ou dias, e os commits que saíam dali eram artefato da atenção daquela pessoa. O planejamento funcionava porque o cartão era a menor coisa que dava para entregar a alguém, e entregar significava entregar por inteiro.

Com Claude Code, Codex ou qualquer CLI de agente no circuito, a menor coisa que dá para entregar é uma sessão: uma conversa, com um objetivo, que roda até o objetivo ser cumprido ou abandonado. A sessão é o que tem começo, fim, contexto e resultado. A tarefa virou um rótulo colado em algo entre uma fração de sessão e várias delas. Isso não é afirmação filosófica, é um formato que você mede no seu próprio histórico do git, e os números abaixo são os nossos.

A consequência prática é que as perguntas que um processo existe para responder mudaram de lugar. "Quem está trabalhando nisto" identificava uma pessoa e um cartão. Agora precisa identificar uma pessoa, uma sessão e a branch ou worktree em que aquela sessão escreve, porque alguém pode iniciar uma sessão e sair de perto enquanto ela continua produzindo.

Qual é o tamanho de uma sessão de agente de IA, medido?

Medimos o repositório deste site, que é uma amostra útil justamente por ser extrema: o site é escrito por agentes de IA trabalhando em worktrees paralelas do git, com um operador humano revisando e commitando. Todo commit feito dentro de uma sessão de agente carrega um trailer Claude-Session, então as sessões se reconstroem só com o histórico do git.

Dos 251 commits sem merge entre 18 de julho e 10 de agosto de 2026, 214 carregam o trailer, ou seja 85,3%, e eles se agrupam em 24 sessões distintas. Mediana aqui significa o décimo segundo valor dos vinte e quatro valores ordenados, e usamos essa definição única em tudo abaixo. Um aviso antes de você ler a tabela: os três valores da coluna Maior vêm todos da MESMA sessão, então aquela coluna é um único caso atípico descrito de três jeitos, e não três exemplos distintos de sessão grande.

Dois números dessa tabela pedem leitura conjunta. A sessão mediana é curta, 48 minutos, e 14 das 24 sessões terminaram em menos de uma hora. Mas a sessão mediana toca 21 arquivos, que é mais largo do que uma tarefa costuma ser escrita para cobrir, e essa comparação é julgamento nosso, não uma segunda medição. O formato, então, não é "pedaços menores de trabalho". É o contrário: uma sentada curta que alcança longe. Quanto ao caso atípico que é dono da coluna Maior inteira, as 65 horas dele são dias de retomada e não uma maratona contínua, o que é limitação de como medimos tempo e não façanha.

As sessões de agente de IA rodam mesmo em paralelo?

Foi aqui que o nosso próprio dado surpreendeu. Se você reduzir cada uma das 24 sessões a uma janela, do primeiro ao último commit dela, e perguntar quantos dos 276 pares possíveis de janelas se sobrepõem no tempo, a resposta é 4. Menos de dois por cento. Num repositório construído especificamente para rodar vários agentes de IA ao mesmo tempo, o histórico do git parece quase inteiramente sequencial.

A conclusão errada é que o paralelismo não aconteceu. Esses 4 pares são 4 trechos em que duas sessões comprovadamente escreviam ao mesmo tempo, e as worktrees isoladas existem justamente para que mais possam. A conclusão certa é mais estreita e mais útil: o registro que o git guarda é serial mesmo quando o trabalho foi paralelo, porque uma sessão que roda uma hora e commita no fim aparece no histórico como um instante. Hora do commit é hora da entrega, não hora do trabalho.

Isso importa para desenhar processo, porque significa que qualquer painel construído sobre atividade do git vai subnotificar quanto está em andamento. Se o seu time está decidindo quantos agentes uma pessoa consegue supervisionar, o histórico do git vai contar uma história confortável que não é a história da tarde. A observação tem de vir do runtime do agente, não do repositório.

O que se atribui a uma pessoa, então?

Você atribui a sessão e a revisão do que ela produziu, e nomeia o destino antes de começar. Na prática, três coisas viajam juntas em vez de um cartão: o objetivo em palavras sobre as quais o agente consegue agir, o lugar isolado em que ele vai escrever, que aqui é uma worktree e uma branch dedicadas, e a pessoa que vai ler o resultado e responder por ele. Tire qualquer uma das três e o trabalho fica difícil de situar depois.

O motivo de o destino ser decidido antes é banal e caro: duas sessões escrevendo no mesmo diretório de trabalho produzem mudanças quase impossíveis de separar depois. Escrevemos sobre a mecânica disso em como rodar vários agentes de IA sem um sobrescrever o outro. O motivo de a pessoa ser nomeada é que o git vai nomeá-la de qualquer jeito: nos nossos 251 commits, o campo de autor traz um único nome humano em todos, que é o assunto de quem responde pelo código que um agente de IA escreveu.

As tarefas não desaparecem nesse arranjo. Elas deixam de ser a unidade de execução e voltam a ser o que sempre fizeram melhor: um registro durável de por que uma mudança existe, que sobrevive à sessão e é o que alguém lê daqui a seis meses quando o código parecer estranho.

O que quebra se você continuar atribuindo tarefas do jeito antigo?

Três coisas quebram, e quebram em silêncio. A primeira é a estimativa: um cartão dimensionado para o dia de uma pessoa não mapeia para nada, porque uma sessão ou o resolve em 40 minutos, ou abre um problema maior do que o cartão jamais descreveu. Velocidade medida em cartões para de acompanhar qualquer coisa real.

A segunda é a revisão. Se a tarefa é a unidade, a revisão chega no fim, sobre um diff que pode atravessar os 21 arquivos que a sessão mediana tocou aqui. Revisar 21 arquivos como um ato só é onde os times começam a carimbar. Fatiar a revisão por sessão, enquanto o contexto de cada uma ainda é recuperável, é a versão disto que se sustenta.

A terceira é a atribuição do problema. Quando um defeito aparece e você pergunta qual mudança o causou, um número de tarefa aponta para um corpo de trabalho espalhado por várias sentadas. Um identificador de sessão aponta para uma conversa com um objetivo, e é a única coisa que permite perguntar o que foi dito ao agente na hora. Esse registro só existe se algo o escreveu no momento do commit, e não se reconstrói depois.

Isso quer dizer que uma pessoa só consegue supervisionar um agente?

Não, e os nossos números não devem ser lidos assim. Os 4 pares sobrepostos em 276 medem janelas de commit, não atenção, e este repositório tem um operador que trabalha em rajadas, não um time de cinco pessoas rodando agentes o dia inteiro. O que o número diz é que o registro do git não vai responder a essa pergunta, então um time que queira saber quantos agentes por pessoa funciona precisa medir isso em outro lugar.

O limite na prática não é quantos agentes conseguem rodar, é quantos conseguem ficar esperando por você sem que você perceba. Um agente parado numa pergunta não produz nada e, na maioria das ferramentas, é idêntico a um agente pensando com afinco. É por isso que o estado de cada sessão, e não a contagem de sessões, é o que vale colocar na tela. O CanvasCode, o app de Mac a que este site pertence, lê esse estado pelos hooks da própria CLI do agente e avisa quando uma sessão precisa de resposta, inclusive quando ela está num projeto para o qual você não está olhando.

Como medir isso no seu próprio repositório?

Se a sua ferramenta escreve um trailer de sessão, são três comandos e todos só leem. Primeiro descubra se você tem algum, porque a resposta vazia também é resposta:

git log -1 --format='%(trailers)'

Depois agrupe os commits por sessão, imprimindo contagem de commits e minutos de relógio de cada uma. Troque Claude-Session pela chave que a sua ferramenta escreve:

git log --no-merges --pretty=tformat:'%(trailers:key=Claude-Session,valueonly,separator=%x2C)%x09%at' |
awk -F'\t' '$1 != "" {
    n[$1]++
    if (!($1 in lo) || $2+0 < lo[$1]) { lo[$1] = $2+0 }
    if ($2+0 > hi[$1]) { hi[$1] = $2+0 }
  }
  END { for (s in n) { printf "%d commits\t%d min\n", n[s], (hi[s]-lo[s])/60 } }' |
sort -n

E então pergunte quanto disso realmente rodou ao mesmo tempo, que é o número que vale discutir numa reunião de planejamento:

git log --no-merges --pretty=tformat:'%(trailers:key=Claude-Session,valueonly,separator=%x2C)%x09%at' |
awk -F'\t' '$1 != "" {
    if (!($1 in lo) || $2+0 < lo[$1]) { lo[$1] = $2+0 }
    if ($2+0 > hi[$1]) { hi[$1] = $2+0 }
  }
  END {
    n = 0
    for (s in lo) { n++; a[n] = lo[s]; b[n] = hi[s] }
    pairs = 0; overlap = 0
    for (i = 1; i <= n; i++) {
      for (j = i + 1; j <= n; j++) {
        pairs++
        if (a[i] < b[j] && a[j] < b[i]) { overlap++ }
      }
    }
    printf "sessions=%d overlapping_pairs=%d of %d\n", n, overlap, pairs
  }'

Neste repositório o segundo comando imprime sessions=24 overlapping_pairs=4 of 276. Os dois comandos usam apenas git e awk, então se comportam igual no macOS e no Linux sem instalar nada.

O que esta medição não mostra

É um repositório, 24 dias, um operador, e um projeto cujo propósito inteiro é rodar agentes em paralelo, então o formato de uma sessão aqui não é média de mercado. O trailer marca a sessão, nunca a autoria de uma linha: uma sessão pode assinar dezenas de commits, e um humano editando dentro de uma sessão produz um commit idêntico ao que o agente produziria sozinho. O tempo de relógio é medido entre o primeiro e o último commit da sessão, o que subconta o tempo de raciocínio antes do primeiro commit e conta o intervalo quando a sessão foi retomada dias depois. E os 37 commits sem trailer não são ruído a ignorar: 26 deles caíram num único dia, 20 de julho, o que lembra que registro só existe onde algo foi configurado para escrevê-lo.

O que sobrevive a tudo isso é a razão entre os dois formatos: uma sentada mediana de menos de uma hora, alcançando 21 arquivos. Essa é a parte que esperaríamos ver em outros lugares, e é a parte que torna a tarefa o recipiente errado.