Quando a Meta lançou o Muse Code esta semana, a manchete foi sobre posicionamento competitivo: mais um agente de codificação baseado em terminal a juntar-se ao Claude Code, ao Codex e ao Cursor na disputa pelos fluxos de trabalho dos programadores. Mas, escondido na própria descrição que Mark Zuckerberg fez da ferramenta, está o sinal mais interessante para quem escreve ou revê código para viver.

"Quando uma tarefa é suficientemente grande, ela ramifica-se em subagentes separados a trabalhar em paralelo em worktrees isoladas", escreveu Zuckerberg, descrevendo a abordagem do Muse Code para tarefas de grande dimensão. "A sua cópia de trabalho nunca é tocada. Nos testes, conseguimos que ele construísse seis funcionalidades para um jogo em simultâneo, sem colisões."

Isso não é a descrição de uma funcionalidade. É uma descrição de função — a sua.

O que "worktrees isoladas" realmente significa

Uma worktree do git permite fazer checkout de vários branches do mesmo repositório em diretórios separados ao mesmo tempo, para que várias linhas de trabalho possam avançar sem que um checkout pise no outro. O Muse Code, segundo a explicação da Meta, usa este mecanismo para permitir que vários subagentes escrevam código ao mesmo tempo sem tocar na sua cópia de trabalho ativa nem nos ficheiros uns dos outros. É uma escolha de engenharia sensata: colisões ao nível dos ficheiros são o tipo mais fácil de conflito entre múltiplos agentes de prevenir mecanicamente, por isso previnem-se mecanicamente e liberta-se o modelo para se concentrar na codificação em si.

A palavra a reparar é "ramifica". Um programador humano não vive seis worktrees paralelas como seis fluxos de código para verificar manualmente um de cada vez, em sequência — são seis fluxos a chegar-lhe à secretária mais ou menos ao mesmo tempo, cada um exigindo uma decisão: isto entra ou não, precisa de retrabalho, entra em conflito com algo que um agente irmão acabou de fazer noutra worktree.

A competência que está de facto a mudar

Nos últimos anos, o modelo dominante de codificação assistida por IA tem sido conversacional e singular: um programador, um assistente, um fio único de idas e voltas, revisto praticamente em tempo real à medida que é produzido. Essa competência — saber formular bem os pedidos, apanhar uma sugestão má no momento, iterar — continua a ser necessária. Mas não é a competência para a qual o design do Muse Code está a otimizar. A ramificação para subagentes pressupõe que já se passou para um modo de trabalho diferente: decompor uma tarefa à partida em peças que possam correr de forma independente, e depois rever o resultado terminado (ou semiterminado) de vários agentes de uma vez, em vez de orientar um agente turno a turno.

Isso aproxima-se mais de ser um tech lead que divide um sprint por uma pequena equipa do que de um programador em par a partilhar o ecrã com um chatbot. As decisões de codificação individuais importam menos do que a decomposição (dividiu o trabalho por linhas que são realmente independentes?) e a passagem de revisão (consegue perceber, rapidamente, se seis diffs paralelos são, cada um, individualmente corretos e coletivamente coerentes?).

O isolamento resolve colisões, não coerência

Vale a pena parar para pensar nisto, porque é fácil de não perceber: as worktrees isoladas impedem que dois agentes sobrescrevam o mesmo ficheiro. Não fazem nada para impedir que dois agentes inventem, independentemente, duas formas diferentes de fazer a mesma coisa — um segundo auxiliar de formatação de datas, um segundo wrapper de retentativas, uma rota de API duplicada — porque nenhum dos agentes conseguia ver o que o outro estava a construir. O isolamento do git é uma garantia ao nível do sistema de ficheiros, não uma garantia de design. O revisor que junta de novo as seis worktrees é o único ponto de verificação onde uma abstração duplicada, uma convenção de nomenclatura inconsistente, ou duas funcionalidades que assumem silenciosamente formatos de dados diferentes são detetadas. Se esse revisor estiver a percorrer os diffs superficialmente porque o volume de output paralelo ultrapassa a capacidade de leitura cuidadosa, é exatamente este tipo de desvio que acaba por ir para produção.

Isso redefine o que "revisão de código" precisa de significar assim que as ferramentas de ramificação se tornarem normais: menos inspeção linha a linha de qualquer diff isolado (a sintaxe do agente costuma estar correta), mais reconciliação entre diffs — verificar se fluxos paralelos de trabalho gerado por IA concordam entre si quanto a convenções partilhadas, modelos de dados partilhados e tratamento de erros partilhado.

Para o que realmente vale a pena trabalhar

Nada disto exige o Muse Code especificamente — o mesmo padrão de ramificação está a surgir nos principais agentes de codificação, o que sugere que está a tornar-se uma arquitetura predefinida, em vez de uma aposta de um único fornecedor. Algumas coisas concretas que vale a pena praticar já, independentemente da ferramenta que se use:

  • Escreva especificações de tarefas que se decomponham de forma limpa. Antes de pedir trabalho paralelo, pergunte-se se as partes são genuinamente independentes — tocam os mesmos ficheiros, as mesmas constantes partilhadas, o mesmo contrato de API? Se sim, isso não é trabalho para seis agentes em paralelo; é trabalho para um agente a trabalhar sequencialmente, ou para você mesmo dividir primeiro à mão as partes partilhadas.
  • Pratique rever no ponto de fusão, não no ponto do diff. Habitue-se a puxar vários branches terminados lado a lado e a perguntar "estes concordam entre si", e não apenas "cada um está correto individualmente".
  • Conheça o básico das worktrees do git. Se as ferramentas que usa vão descrever o seu funcionamento interno desta forma, perceber o que uma worktree garante e o que não garante é o mínimo indispensável para confiar — ou desconfiar corretamente — do resultado.
  • Seja explícito quanto à propriedade das coisas partilhadas. Constantes, esquemas, utilitários partilhados, convenções de nomenclatura. Quanto mais destes forem definidos antes de a ramificação começar, menos trabalho de reconciliação terá depois.

As pessoas que vão tirar mais partido de ferramentas como o Muse Code não serão as que melhor sabem formular pedidos. Serão as que, discretamente, se tornaram boas a gerir uma equipa pequena, rápida e ocasionalmente desleixada — mesmo quando cada membro dessa equipa é um modelo.