🏗️ Projeto 2: Equipe de Desenvolvimento Autonoma

O oh-my-openagent (OMO) e um dos sistemas multiagentes mais sofisticados em producao. Sua arquitetura e um pipeline hierarquico onde um orquestrador central — chamado Sisyphus — coordena uma equipe de agentes especializados: o Prometheus (planejador) que cria a spec, o Hephaestus (coder) que implementa, o Reviewer que avalia a qualidade e o Test Engineer que valida o resultado. Cada agente usa um modelo de IA diferente deliberadamente, criando uma diversidade cognitiva que captura erros que um unico modelo ignoraria.

Neste projeto, voce vai replicar essa arquitetura do zero. O objetivo nao e copiar o OMO linha por linha, mas entender os principios que fazem ele funcionar e construir sua propria versao. O Sisyphus e um "loop incansavel" — ele delega, recebe resultado, avalia, e se nao estiver satisfeito, delega novamente. Ele nunca para ate que a tarefa esteja completa e aprovada. Esse padrao de persistencia e o que diferencia swarms de producao de demos.

A fase de planejamento e onde a maioria dos projetos de software falha — e com swarms nao e diferente. Um agente coder que recebe uma instrucao vaga vai produzir codigo vago. O agente planejador (Prometheus) resolve isso fazendo discovery questions — perguntas de clarificacao que forcam o usuario a definir exatamente o que quer. "Qual framework usar?", "Precisa de autenticacao?", "Qual banco de dados?" — cada pergunta elimina ambiguidade que geraria retrabalho na execucao.

O resultado do planejamento e um arquivo spec.md que contem: descricao do projeto, requisitos funcionais e nao-funcionais, stack tecnologica escolhida, lista de tasks atomicas (cada uma com escopo claro e criterios de aceitacao) e dependencias entre tasks. Esse arquivo e o "contrato" entre o planejador e o coder — tudo que nao esta na spec nao sera implementado, e tudo que esta na spec deve ser implementado completamente.

A execucao paralela e o santo graal dos swarms de desenvolvimento — multiplos agentes codificando simultaneamente, cada um em sua tarefa, produzindo em minutos o que levaria horas sequencialmente. Mas paralelismo sem coordenacao e receita para desastre: dois agentes editando o mesmo arquivo geram conflitos de merge, um agente importando um modulo que outro esta modificando causa erros em cascata. A solucao e o conceito de zonas seguras.

Zonas seguras significam que cada agente tem ownership exclusivo sobre os arquivos que esta modificando. O orquestrador distribui tasks de forma que dois agentes nunca editem o mesmo arquivo simultaneamente. Quando isso nao e possivel (ex: dois agentes precisam adicionar rotas no mesmo router.ts), a task e dividida em sub-tasks sequenciais ou o arquivo conflitante e tratado por um unico agente. Cada task atomica define explicitamente quais arquivos serao criados ou modificados, e o sistema valida que nao ha sobreposicao antes de iniciar a execucao paralela.

A revisao cross-model e uma das tecnicas mais poderosas e menos intuitivas dos swarms: usar um modelo de IA diferente do que escreveu o codigo para revisao-lo. Se o Hephaestus codou usando Claude Sonnet, o Reviewer usa GPT-5.3 (ou vice-versa). A razao e que modelos do mesmo provider tendem a ter os mesmos blindspots — padroes que eles nao conseguem detectar em seu proprio output porque sao inerentes ao seu treinamento. Usar um modelo de provider diferente introduz uma "perspectiva alternativa" que captura erros que o modelo original nunca veria.

O Reviewer nao faz apenas code review tradicional. Ele avalia contra uma checklist estruturada: corretude (o codigo faz o que a spec pede?), seguranca (ha vulnerabilidades OWASP?), performance (ha gargalos obvios?), manutenibilidade (o codigo e legivel e bem estruturado?) e completude (ha TODOs, stubs ou placeholders?). O resultado e binario: APPROVED ou NEEDS_REVISION com feedback especifico sobre o que precisa ser corrigido.

O agente testador (Test Engineer) e responsavel por gerar e executar testes que provam que o codigo funciona corretamente. Mas ha uma armadilha fundamental: IAs sao excelentes em gerar testes que parecem corretos mas nao testam nada de verdade. O fenomeno do "testing theater" — 268 assertions testando strings de prompt em vez de comportamento real — e um caso real documentado em projetos open-source gerados por IA.

Para evitar testing theater, o Test Engineer deve gerar tres tipos de testes: testes unitarios que verificam funcoes individuais com inputs variados (incluindo edge cases), testes de integracao que verificam que componentes funcionam juntos e testes adversariais que tentam deliberadamente quebrar o codigo com inputs maliciosos, volumes extremos e condicoes de corrida. Os testes devem verificar comportamento, nao implementacao — testar que a funcao retorna o resultado correto, nao que ela usa determinada variavel interna.

A documentacao automatica e o ultimo elo da cadeia de desenvolvimento autonomo. O agente documentador (Documenter) nao apenas gera README e docstrings — ele registra o racional de decisoes tomadas durante o desenvolvimento. Por que escolhemos Redis em vez de PostgreSQL para o cache? Por que o endpoint usa POST em vez de GET? Essas decisoes sao obvias no momento mas esquecidas em semanas. O decision log preserva esse conhecimento.

O Documenter gera tres artefatos: changelog (o que mudou e por que), decision log (decisoes de arquitetura com contexto e alternativas consideradas) e API docs (documentacao tecnica dos endpoints, funcoes e modulos). Cada artefato e gerado automaticamente a partir das tasks completadas, do historico de revisao e dos testes executados. O resultado e documentacao que nasce junto com o codigo, nao como afterthought.