O Gargalo Nunca Foi Digitar

A IA não apenas tornou a digitação mais rápida — ela moveu o gargalo por completo. Os times que aprenderem a rodar agentes em paralelo vão parecer irreconhecíveis para os que ainda esperam um diff de cada vez.

A primeira versão do meu loop de desenvolvimento com IA era simples. Pedir ao assistente para fazer a coisa A. Esperar. Revisar o diff. Passar para a coisa B. O assistente era um parceiro de programação em par mais rápido. Ainda um par. Ainda uma coisa de cada vez.

Esse modelo durou cerca de três meses. Não é como eu trabalho agora.

O que eu faço agora é rodar múltiplos assistentes de codificação de IA em paralelo contra a mesma base de código, cada um em sua própria worktree do git, cada um em sua própria branch, cada um trabalhando em um problema diferente ao mesmo tempo. A qualquer momento dado, existem de cinco a dez branches ativas ao longo dos repositórios. Agentes diferentes empurrando partes diferentes do engine simultaneamente. Eu reviso e integro em vez de escrever e esperar.

A mudança no meu trabalho é o post.

Como é um fim de semana de verdade

Um fim de semana em meados de março. Ao longo dos cinco repositórios, 112 commits foram integrados entre o café da manhã de sábado e o jantar de domingo. 66 tinham uma IA como autor de registro. 47 tinham a mim. O resto foram merges e limpezas guiadas por revisão.

O trabalho não era um projeto. Eram cinco. Portes WASM para nove gêneros. Integração do renderizador Metal do iOS. Um executor de pacote de conteúdo com vinte e um assets passando por um pipeline de sete estágios. Estágios cinco a sete do gênero de batalha de cartas. Otimizações de desempenho para o build web. Tudo isso aconteceu ao longo dos mesmos dois dias em branches paralelas que foram integradas ao longo de cada tarde e noite.

Nenhum humano sozinho digita 112 commits em um fim de semana em uma mesa de cozinha. Nenhum humano sozinho consegue manter cinco fluxos de trabalho paralelos em uma única cabeça e escrever o código para cada um deles. O modelo que eu tinha três meses atrás não poderia ter produzido esse fim de semana.

O modelo que eu tenho agora produz.

O gargalo se move

Quando o trabalho é sequencial, o gargalo é digitar. A próxima linha de código não existe até alguém escrevê-la. A IA tornou aquela linha mais rápida. Não mudou qual etapa era lenta.

Quando o trabalho é paralelo, o gargalo é seleção. Quatro agentes voltam com quatro diffs. Dois deles são bons. Um está na direção certa mas precisa de trabalho. Um não deveria ter sido escrito. A etapa lenta é decidir qual é qual e integrar os dois que sobrevivem.

Esse é um trabalho completamente diferente daquele para o qual fui treinado. Menos digitação. Mais triagem. Menos síntese. Mais seleção.

A forma do fim de semana:

• Sábado de manhã: enquadramento. Quais quatro problemas valem quatro tentativas paralelas. Qual é o critério de sucesso para cada um. Qual é a forma aproximada de uma resposta aceitável.
• Ao longo dos dois dias: verificação pontual. Os agentes estão no caminho certo? Algum deles produziu algo errado com confiança nos primeiros trinta minutos? Alguém está travado?
• Final da tarde, ambos os dias: revisão e integração. Diffs chegam. Ler cada um com o critério de sucesso em mente. Integrar os que acertam. Refazer ou fechar os que não acertam. Capturar o que as tentativas fracassadas me ensinaram sobre o problema.
• Final do domingo: registrar o que o fim de semana entregou e quais são os próximos quatro problemas.

É mais parecido com ser um tech lead com um time de quatro do que ser um IC sênior com um copiloto. Usa músculos diferentes. Os que usa são incomumente fungíveis entre domínios.

Onde isso se combina com arquivos .raku

Os arquivos de experiência que nosso engine roda são arquivos .raku: JSON, versionados por schema, validáveis, revisáveis como código. O formato foi projetado com esse fluxo de trabalho de agentes paralelos em mente.

Quando um agente edita um arquivo .raku, o diff aparece do mesmo jeito que um diff de código aparece. Um segundo agente pode revisar o trabalho do primeiro agente. Eu posso rodar um terceiro agente para verificar pontualmente os dois. A decisão de integração é minha. A coisa toda cabe dentro da mesma disciplina de pull request que eu uso para o runtime.

Se .raku fosse um asset binário, nada disso funcionaria. A escolha do formato e a escolha do fluxo de trabalho são subordinadas à mesma decisão arquitetural: experiências são código, trabalho de desenvolvimento é revisão de código, agentes participam do loop porque o loop aceita código.

O formato de arquivo sustenta a estrutura. É o que permite ao time escalar por meio de agentes em vez de contagem de cabeças.

O que funciona na prática

Três padrões nos quais me firmei.

Um: emparelhar agentes em um problema. Quando algo não é trivial, dois assistentes com treinamentos diferentes tendem a discordar de forma produtiva. Eu os rodo em branches separadas com o mesmo prompt, depois comparo suas respostas por diff. As discordâncias são onde a atenção de revisão de verdade vai.

Dois: dedicar um agente à revisão. Mantenho um dos quatro assistentes em um papel apenas de revisão em qualquer dia dado. Ele nunca escreve o primeiro rascunho. Só critica diffs que os outros produzem. O custo de rodar um revisor dedicado é pequeno. A taxa de captura de bugs é significativa.

Três: manter o contexto do agente estreito. Um único agente em uma única branch em um único problema é rápido. Um único agente em um problema espalhado com cinco horas de contexto se desvia e produz trabalho de qualidade menor. A correção é quebrar problemas em pedaços menores e rotacionar o contexto com frequência.

O que quebra

Honesto sobre o que não funciona.

A sobrecarga de coordenação é real. Dois agentes no mesmo arquivo ao mesmo tempo produzem conflitos de merge que eu tenho que resolver. O custo é pequeno por conflito mas se acumula. Mitigação: manter agentes em arquivos diferentes quando possível, e aceitar que a etapa de convergência faz parte do fluxo de trabalho.

A fadiga de revisão é real. Revisar quatro diffs no final de cada dia é mais difícil do que revisar quatro diffs sequenciais ao longo de quatro dias. As decisões são mais densas. Corto o dia de trabalho mais cedo em dias de agentes paralelos do que fazia quando o trabalho era sequencial.

A tentação de manter tudo é real. Quando dois agentes produzem algo razoável, o movimento preguiçoso é integrar os dois. O movimento disciplinado é escolher um. Integrar os dois polui a base de código com duas formas de fazer a mesma coisa, o que custa mais do que apenas refazer o perdedor teria custado.

O desvio de contexto ao longo de sessões paralelas de longa duração é real. Uma branch que ficou aberta por um dia acumula suposições que o agente fez sobre a base de código no momento em que começou. Ao anoitecer, essas suposições podem estar desatualizadas. A correção é branches de vida curta, implacavelmente.

Nem tudo se paraleliza. Refatorações transversais com invariantes sutis querem uma única passagem cuidadosa, não quatro tentativas paralelas. A habilidade é saber quais problemas se dividem de forma limpa e quais não. Alguns dias ainda são dias sequenciais.

O que isso significa para líderes de engenharia

Se seu time está rodando o modelo sequencial com IA encaixada por cima, o próximo passo não é “use um modelo melhor.” É “use múltiplos agentes de uma vez.” O teto de capacidade é mais alto. O teto de habilidade também é mais alto, e move o papel sênior da produção para o enquadramento, validação, e seleção. Essa é a mesma direção de viagem que vejo em toda outra disciplina rodando IA bem agora.

Os times que descobrirem fluxos de trabalho de agentes paralelos ao longo dos próximos dois anos vão parecer irreconhecíveis para times ainda rodando o modelo sequencial. A forma do trabalho é o que muda. Não o ferramental.

112 commits ao longo de dois dias. Fechando o laptop no domingo com a maioria deles verde.