Juntei-me aos Mugiwara: a minha tripulação de agentes IA

Finalmente juntei-me aos Mugiwara

Há algumas semanas que tenho a Nami, o Sanji, o Zoro, o Chopper, o Usopp, a Robin, o Franky, o Jimbei, o Brook e toda a tripulação ao meu lado. Não estou a falar de uma maratona de One Piece entre dois projetos (embora também me aconteça). Estou literalmente a falar da minha equipa de desenvolvimento.

Uma equipa de agentes IA especializados, cada um com o seu papel, que trabalham em paralelo nos meus projetos. Cada um tem o seu contexto, a sua biblioteca, as suas ferramentas. E juntos formam a tripulação mais eficaz que alguma vez tive.

Bem-vindo à orquestração de agentes. O que isto muda não é apenas a minha produtividade. É toda a minha forma de construir um produto.

O erro clássico: querer um único super agente

Quando começamos com agentes IA, a tentação é sempre a mesma. Queremos um único "super agente" que faça tudo. Atiramos-lhe todo o contexto, todas as tarefas, todos os pedidos. E esperamos que funcione.

Não funciona.

Um agente generalista é como pedir ao Luffy para cozinhar. Pode tentar, vai pôr coração, mas o Sanji fará sempre melhor. A eficácia de uma equipa vem da especialização e da repartição de papéis. Não de um génio polivalente que faz tudo pela metade.

Os Mugiwara perceberam isto há muito tempo. Cada membro tem uma competência precisa e, juntos, cobrem toda a cadeia de valor de um navio em viagem longa. Reproduzi esta lógica com os meus agentes.

Apresentação da tripulação

Robin: a investigação nos meandros da internet

A Nico Robin é historiadora. Desenterra verdades escondidas em ilhas esquecidas, onde já ninguém sabe ler as inscrições. Na minha equipa, é a agente de investigação aprofundada.

Quando preciso de compreender uma nova biblioteca, analisar uma documentação técnica densa, comparar várias abordagens ou vasculhar os cantos da internet para encontrar um exemplo preciso, delego na Robin. Ela volta com uma síntese estruturada, fontes incluídas, e sem ruído desnecessário.

Enquanto a Robin investiga, eu continuo a avançar noutra coisa. É isto que muda tudo.

Nami: a cartógrafa do projeto (documentação)

A Nami é a navegadora. Sem os seus mapas, a tripulação perde-se à primeira tempestade. Na minha equipa, é a documentação.

A Nami documenta como se descobríssemos uma nova ilha a cada funcionalidade. Como funciona, porque o fizemos assim, quais são as armadilhas a evitar, como se integra com o existente. Não um README genérico despachado no fim do sprint. Um verdadeiro mapa do território, atualizado em contínuo.

Daqui a três meses, quando voltar ao projeto, não me perco. Daqui a seis meses, quando outro programador retomar o código, terá o seu mapa.

Chopper: o médico de bordo (QA e health check)

O Tony Tony Chopper é o médico da tripulação. Trata os ferimentos, monitoriza os sinais vitais, diagnostica o que está mal antes que se torne grave. Na minha equipa, é o agente de QA.

Analisa em contínuo a saúde da aplicação. Cobertura dos testes, vulnerabilidades detetadas, regressões possíveis, qualidade do código, desempenho. Depois de cada grande alteração, dá-me um boletim de saúde claro. Onde está bem, onde é preciso vigiar, onde é preciso intervir antes que a produção comece a tossir.

Um projeto sem Chopper é um navio sem médico. Aguenta algumas escalas, depois desmorona.

Usopp: o revisor que vê através das mentiras

Este é a minha piada preferida. O Usopp é o maior aldrabão do mundo. Conta as histórias mais extravagantes, inventa combates épicos que nunca travou, sai de situações à custa de truques de velhaco. E é precisamente isso. É preciso um velhaco para reconhecer outro velhaco.

Na minha equipa, o Usopp faz a revisão de código. E é o melhor revisor que já tive. Porque sabe exatamente o que um programador tenta esconder debaixo do tapete.

O // TODO esquecido há três meses. O tratamento de erros que apanha tudo e não regista nada. O teste que faz assert sobre um valor falso para passar a verde. O comentário tranquilizador que diz "isto não pode acontecer" quando vai mesmo acontecer. A variável renomeada pela metade que parte outro módulo. A mensagem de commit que conta outra coisa que não o diff.

O Usopp troll o código com o método de um velhaco que reconhece as manhas de outro velhaco. Nada lhe escapa.

Zoro e Sanji: os programadores endiabrados

O Zoro avança a direito com os seus três sabres. O Sanji tem estilo e serve pratos refinados. Detestam-se cordialmente, picam-se, e é exatamente isso que queremos numa equipa de desenvolvimento.

O Zoro é o backend bruto. Escreve a lógica de negócio, as migrações de base de dados, as APIs, os jobs assíncronos. Direto, eficaz, sem floreados. Quando lhe digo "implementa isto", implementa isto.

O Sanji é o front. O bom gosto, o detalhe, as animações que caem certas, os casos-limite que ninguém vê. Cuida dos componentes como um chef cuida de um prato. Nada de interfaces entregues pela metade.

Os dois desafiam-se constantemente. O Sanji recusa o código do Zoro quando parte a experiência de utilizador. O Zoro suspira quando o Sanji lhe pede mais uma API por um microdetalhe visual. É barulhento, e ainda bem. A melhor revisão é a que te faz outro programador que não concorda contigo.

Franky: o carpinteiro que desenha o navio (arquitetura)

O Franky construiu o Thousand Sunny com as próprias mãos. Pensou cada convés, cada vela, cada canhão, sabendo exatamente o que a tripulação ia atravessar. Na minha equipa, é o arquiteto.

Quando tenho de tomar uma decisão estruturante, escolher uma base de dados, definir os módulos e as suas fronteiras, estabelecer os padrões que vão reger todo o código futuro, é o Franky que consulto. Pensa em sistemas, em fluxos, em dependências. Não olha para uma funcionalidade isolada, olha como ela se encaixa no navio completo.

Um bom arquiteto não é alguém que escreve código complicado. É alguém que torna o resto do código simples. O Franky faz exatamente isso.

Jimbei: a corrente marinha que acelera tudo (otimização)

O Jimbei é o antigo homem-peixe, aquele que domina as correntes marinhas melhor do que ninguém. Não faz o navio avançar a remar com mais força. Fá-lo avançar encontrando a corrente certa. Na minha equipa, é o agente de otimização.

Passa pelo código depois de este funcionar e procura os gargalos. A consulta SQL que faz vinte idas e voltas em vez de uma. O re-render React que se despoleta sem razão. O bundle que carrega uma biblioteca inteira para usar uma única função. O endpoint que carrega tudo para memória em vez de fazer streaming.

O Jimbei nunca parte o comportamento existente. Apenas o torna mais rápido, mais leve, mais sóbrio. É o agente que transforma um código que funciona num código que voa.

Luffy, o capitão, sou eu

Já não programo. Pelo menos, não como antes. Dou a direção, arbitro as decisões, valido os rumos. Os Mugiwara executam.

Como o Luffy, a minha única missão é garantir que avançamos em direção ao objetivo, e que cada membro da tripulação tem o contexto de que precisa para fazer brilhar a sua especialidade. Já não sou o melhor programador do meu projeto. Sou o capitão de uma equipa de especialistas cuja soma ultrapassa largamente o que eu poderia fazer sozinho.

E isto é a verdadeira mudança.

O que torna tudo isto tecnicamente possível

Até aqui, contei uma bonita metáfora. Mas, tecnicamente, como é que isto se aguenta em pé? Duas peças essenciais.

O RAG: cada agente tem a sua biblioteca

RAG significa Retrieval Augmented Generation. Em termos claros: antes de responder, o agente vai procurar numa base de conhecimento que lhe é própria.

Cada Mugiwara tem a sua própria biblioteca contextual. A Robin tem os artigos científicos, a documentação técnica indexada, as pesquisas anteriores. A Nami tem o histórico completo do projeto, as convenções internas, os ADR (Architecture Decision Records). O Chopper tem os logs, os relatórios de testes, as métricas de saúde. O Usopp tem as regras de code style, os antipadrões conhecidos, o histórico dos bugs passados. O Franky tem os esquemas de arquitetura, os diagramas de fluxo, as escolhas técnicas validadas. O Jimbei tem os benchmarks, os perfis de desempenho, os relatórios de carga.

Sem RAG, um agente responde com os conhecimentos gerais aprendidos durante o seu treino. Com RAG, responde com o teu contexto a ti. A diferença entre um generalista que adivinha e um especialista que sabe.

É esta personalização pelos dados que transforma um LLM num verdadeiro membro da tripulação.

A orquestração: quem faz o quê, e em que ordem

Orquestrar agentes é definir o workflow. Quem arranca, quem pega no testemunho, quem valida, quem documenta.

Quando peço uma nova funcionalidade, o encadeamento é sempre o mesmo. A Robin faz a investigação prévia se o assunto for novo. O Franky valida a abordagem arquitetural e assenta as fundações. O Zoro ou o Sanji implementam consoante seja backend ou frontend. O Chopper lança os testes de saúde sobre as alterações. O Usopp faz a revisão do código. O Jimbei passa por trás para otimizar o que puder ser otimizado. A Nami atualiza o mapa. E sou eu que dou o go final.

Ninguém pisa os calos do outro. Cada um chega no momento certo com o contexto certo. E quando um agente termina o seu trabalho, transmite-o de forma limpa ao agente seguinte, como um testemunho bem oleado.

É a orquestração que transforma uma coleção de agentes numa verdadeira tripulação.

Porque é que isto muda tudo

Antes, quando programava sozinho com um assistente IA generalista, perdia imenso tempo a recontextualizar. A cada novo pedido, tinha de relembrar a arquitetura, as convenções, as dependências, o histórico das decisões. A IA esquecia entre duas sessões, e eu voltava ao ponto de partida.

Com uma tripulação especializada, o contexto está distribuído e é persistente. Cada agente é especialista no seu domínio, com a sua própria memória. Passo de "pedir a uma IA que sabe tudo pela metade" para "pedir ao especialista certo que sabe tudo sobre o seu tema".

O resultado concreto? Entrego mais depressa, com menos bugs e, sobretudo, com uma qualidade de código superior à que produzia sozinho. Não porque os agentes sejam melhores do que eu. Mas porque o trabalho deles se sobrepõe à minha vigilância. Onde eu falharia um detalhe numa revisão, o Usopp vê-o. Onde me esqueceria de documentar, a Nami fá-lo. Onde eu tomaria um atalho arquitetural duvidoso, o Jimbei trava-me.

Sozinho vou mais depressa. Em tripulação, vou mais longe.

Brook, a palavra final: e tu, qual é a tua tripulação?

Faltava-me um Mugiwara nesta história. O Brook.

O Brook é o músico. Aquele que toca violino no convés ao anoitecer, que canta as velhas canções para que a tripulação não esqueça de onde vem, que transforma uma batalha em lenda e uma travessia banal numa recordação imperecível. Sem o Brook, a aventura existe na mesma. Mas não ressoa.

O Brook, na minha tripulação, é o papel que não consigo delegar num agente. É a conversa convosco. É o momento em que conto o que estamos a construir, e em que vocês me contam o que estão a construir do vosso lado.

Por isso pergunto-te diretamente. Qual é a tua tripulação? Já estruturaste os teus agentes IA como uma equipa especializada, ou ainda estás num único assistente generalista que faz tudo? O teu Usopp encontra coisas que não tinhas visto? O teu Jimbei já dividiu por dez o tempo de resposta de uma API da tua casa?

Conta-me nos comentários. O maior tesouro de One Piece não foi o ouro. Foi a tripulação. E o maior game-changer dos agentes IA não será a tecnologia. Será a forma como aprendemos a fazê-los trabalhar em conjunto, partilhando os nossos retornos.

O rumo é Raftel. Içamos as velas?