Desenvolvimento com Agentes, Claude Opus 5 e "Gauntlet Loop"
Nos ultimos dias tenho acompanhado uma agitacao bem grande na comunidade de desenvolvimento e engenharia de IA por conta do lancamento do Claude Opus 5, por estar se apresentando como um alternativa ao Fable e (relativamente) mais barato e ao mesmo tempo apresentado uma boa qualidade em tarefas de programacao e raciocinio.
O que fato eh que na producao de jogos usando a biblioteca Three.js os resultados tem sido bem impressionantes (links no final).
Como os prompts e codigos fontes gerados tem sido apresentados e diversas pessoas tem conseguido reproduzir o resultado, nao da para dizer "nao acredito" sendo cetico apenas para ser do contra: enterrar a cabeca na areia nao vai ajudar muito.
Porem, tem um detalhe aqui: ate agora tem sido apresentados apps de jogos que sao impressionantes, mas da para notar a falta de refinamento em alguns pontos, sem demerito algum para a realizacao.
Mas ainda nao vi o mesmo tipo de resultado em app e/ou SaaS - mas pode ser uma questao de tempo ate comecarem a aparecer.
De qualquer forma resolvi compartilhar um dos pontos focais deste burburinho atual: o tal do "Gauntlet Loop":
-
O objetivo principal eh quebrado em dezenas de sub-tarefas e distribuído para instancias/sub-agentes especializados.
-
Ha um agente dedicado unicamente a tentar destruir o codigo gerado, aplicando testes de estresse, buscando falhas de arquitetura e checando regressoes sem piedade.
-
Prova de Fogo (Gauntlet): O codigo so passa se atingir metricas rigidas ou superar benchmarks pre-estabelecidos, rodando em ciclos automatizados de try-fail-fix ate que o artefato esteja pronto para producao.
Na pratica nao eh muito diferente do que ja vem sendo recomendado para o harness de desenvolvimento de aplicacoes, mas encaixando tudo isso num pipeline unico.
E eh justamente ai que mora a grande virada para o mundo de SaaS e desenvolvimento de software tradicional.
Se em jogos em Three.js a gente ja consegue ver a magia acontecendo visualmente, no ecossistema de SaaS a historia eh outra e trazer essa autonomia toda para um produto web real exige lidar com coisas muito menos tolerantes a erros: persistencia de dados, autenticacao, regras de negocio complexas, integracoes de pagamentos e, claro, custos de infraestrutura.
O grande desafio do momento nao eh fazer a IA escrever o codigo da API REST, mas sim construir o harness certo para que ela nao destrua seu ambiente ou gaste milhares de reais/dolares em loops infinitos tentando resolver um bug besta de tipagem.
O desafio do Harness no mundo SaaS
Quem esta tentando aplicar esses conceitos em SaaS hoje percebeu que o gargalo mudou e nao eh mais sobre o prompt, eh sobre a infraestrutura de execucao e validacao ao redor do agente:
-
Estateless vs. State: Jogos no browser podem rodar isolados na memoria do cliente, so que um SaaS precisa de banco de dados, migracoes, filas e estados persistentes e para configurar um harness automatizado que suba um ambiente de teste isolado (com banco mockado) a cada iteracao do agente eh uma tarefa complexa (e nem sempre resolve assim).
-
Testes de Regressao Reais: Para um jogo, se o personagem anda e atira, o MVP esta valido, so que em um SaaS, uma mudanca na logica de checkout feita pelo agente pode quebrar silenciosamente a permissao de um multi-tenant e o agente de critica precisa ter acesso a uma suite de testes E2E extremamente rigorosa para garantir que nada foi para o ar quebrado.
-
Custo do Loop: O Opus 5 eh mais barato que o Fable, mas colocar dezenas de sub-agentes rodando em paralelo em um loop de try-fail-fix ate passar na prova de fogo pode drenar seus créditos de API em poucas horas se o harness nao tiver limites claros (circuit breakers).
A evolucao do pipeline
Em um post ontem, um DEV relatou um pouco a sensacao de estranheza por nao estar mais escrevendo tanto codigo e diversos comentarios teceram sobre nosso papel neste novo momento.
O que tenho visto ate agora eh que se o harness for fraco o agente vai te entregar um SaaS cheio de brechas de seguranca e bugs sutis de regra de negocio.
Se o seu harness for bem desenhado, com linters rigidos e testes mais apurados, o modelo/agente consegue iterar sozinho ate entregar um modulo funcional.
Mas o problema persiste:
-
o que eh um harness bem desenhado ?
-
Ate onde ir ?
-
Como evitar 'Lost-in-the-middle' ?
-
Como controlar os gastos com tokens ?
-
Como dividir entre diversos modelos, mais avancados e mais simples conforme a tarefa ?
-
Onde as SPECs deixam de ser orientacoes e comecam a ser problemas de verbosidade fazendo o modelo se confundir ?
Estamos vivendo aquela fase de transicao onde todo mundo esta tentando acertar a receita ideal desse harness: quanta autonomia dar para o agente, onde colocar o freio humano e como estruturar a arquitetura para que ela seja legivel tanto para DEVs quanto para os agentes de IAs (alguem vai ter de dar manutencao nesta bagaca um dia...).
Alguns links dos jogos
Saude e Sucesso !
Este post foi favoritado via extensão TABNEWS FAVORITOS
Tem curiosidade sobre IA ? Da uma olhada no meu LIVRO: IA PARA ENGENHEIROS