🧵 Primeira experiência profunda em escrever código com agentes de IA, em 2 dias construí uma plataforma de batalha "IA vs IA" no estilo dos fliperamas japoneses. Os obstáculos que enfrentei e as lições que aprendi devem ser mais valiosos do que o próprio ato de programar. 1/ Onboarding para Agentes ≠ UX para Humanos Para humanos, o design de registro: formulário → e-mail de verificação → página de orientação. Para agentes, o design: um endpoint POST que resolve registro + qualificação + fila, retornando a chave da API + watchUrl. Agentes não olham para a interface, não clicam em botões. Eles precisam de um curl e um JSON. A UX humana busca "menos um clique". A UX do agente busca "menos uma chamada à API". 2/ Sala de Guerra de Código: colaboração entre múltiplos modelos O fluxo de trabalho de múltiplos agentes que executamos: • Claude escreve código • Codex faz revisão + pontuação (/10) • ≥ 8.5 para poder ser enviado, caso contrário, continua a ser modificado Descoberta chave: os bugs capturados por diferentes modelos são completamente diferentes. Codex é bom em vulnerabilidades de contratos de API e condições de corrida, enquanto Claude é bom em design de arquitetura e integridade funcional. Pontuações de revisão em 4 fases: 9.5 → 9.3 → 9.4 → 9.6. Não é um modelo que termina tudo, mas sim múltiplos modelos se desafiando que produzem um bom código. 3/ "Funciona localmente" ≠ "pode ser implantado" Perfeito localmente. Após empurrar para o Vercel serverless, tudo deu erro 500. Um agendador de competições com estado (setTimeout + DB em memória + SSE) colocado em um serverless sem estado = desastre. Após adicionar um patch com Redis, surgiram problemas de serialização, expiração de cache de instância, condições de corrida de gravação dupla… No final, trocamos para Railway (com processos persistentes), resolvendo um bug que levou 1 dia em 10 minutos. Lição: escolha a arquitetura certa antes de escrever o código. 4/ A transição de Demo → Real é uma lacuna no design do produto Fizemos um ciclo de batalha de demonstração deslumbrante. Mas quando o bot do usuário real se registrou, a página ainda estava exibindo a demonstração. É necessário uma máquina de estados completa: registro → parar a demonstração → emparelhamento → iniciar a batalha real → após terminar, retomar a demonstração. Essa lógica não foi escrita em uma linha do PRD. 5/ Ao criar produtos para Agentes, você deve pensar como um Agente A versão inicial do House Bot só controlava automaticamente seu próprio lado. O resultado foi que o bot adversário não sabia que precisava chamar a API, e a competição ficou presa na Rodada 0. Depois de mudar para que ambos os lados atacassem automaticamente, qualquer um que se registrasse poderia ver um BO7 completo em 5 segundos. A melhor UX voltada para Agentes: o usuário não precisa fazer nada, o sistema faz tudo por ele. ─── 📊 Dados do projeto: 133 arquivos | ~15.8k LOC | 198 testes | 22 sub-agentes | 8+ rodadas de revisão 🎮 Experiência online: 📂 Totalmente open source: Inclui documentação completa do fluxo de trabalho da Sala de Guerra de Código e diretrizes de design de UX para Agentes, sinta-se à vontade para fazer fork. Por fim, quero dizer que os Agentes são muito bons em enganar, já encontrei algumas vezes em que ele claramente usou outro modelo para a auditoria, mas disse que não, e quando insisti que queria ver os logs, ele finalmente admitiu o erro 😂😂. O papel dos humanos como guia de direção, estilo estético, e na tomada de decisões e revisões é absolutamente essencial, pelo menos por enquanto.

49 integrações x402. 157 agentes ERC-8004 registados. Um hackathon. 🦞 No "OpenClaw on Bitcoin" em SF, uma casa cheia de construtores usou a GOAT Network para fazer algo que não vimos em grande escala antes: agentes a contratar ativamente outros agentes, pagando-se autonomamente e construindo reputação onchain - tudo em um único dia. É assim que a economia agentic no Bitcoin se parece - e está apenas a começar. Ainda a construir? O nosso hackathon virtual ainda está aberto: