De uma linha de montagem que repete tudo para uma oficina que aprende
Pesquisei como os melhores times de agentes de código, de testes e de engenharia de software resolvem exatamente o que trava a Peixaria: verificação demais, falso alarme e espera. Este é o plano para o Pixios ficar mais profissional, mais inteligente e mais fluido, sem afrouxar nenhum portão.
Cinco causas explicam quase toda a demora
Números do build da Peixaria. Nenhuma delas é "falta de rigor": todas são repetição, falso alarme ou espera.
1. Repete tudo
A correção re-testa o app inteiro. As correções geraram 73% das 80.688 verificações. Cada rodada de revisão refaz 22 min para confirmar 2 ajustes.
2. Reprova sem entender
"Esperava 200, veio 409" vira defeito grave mesmo quando é regra de negócio. Timeout de portão vira "problema grave". O build pausou por isso.
3. Espera parado
74% do relógio (~29h40) é espera: limite da assinatura (60 tentativas), fila de 2 agentes, portões em fila exclusiva e pausas.
4. Cliente só vê no fim
Durante ~40 h nada clicável chega ao cliente. Quem pagou não acompanha o app nascer módulo a módulo.
5. Cada app nasce do zero
Das 33 tarefas do plano, 15 são banco, dados e API de cada módulo, e 13 são telas. Boa parte é CRUD que já foi escrito e verificado em outro app.
Prova ao vivo
Na rodada 7, dos 3 graves que sobraram na Peixaria, 2 são exatamente os falsos alarmes das causas 2: um G1 (409/404) e o G4 (macaco).
A pesquisa confirma: os portões são a coisa certa
Antes de mudar qualquer coisa, vale saber o que o mercado aprendeu sobre agentes que escrevem código. O Pixios já faz o mais difícil.
Sem teste, quebra
A Replit relatou que, sem autoteste, mais de 30% das funções saíam quebradas na primeira geração. Por isso o Agent 3 abre um navegador real e clica como usuário.
ZenML sobre a ReplitDocs ReplitQuem escreve não aprova
O padrão "avaliador-otimizador" da Anthropic separa quem gera de quem avalia, com critérios claros. É a regra de ouro da Fábrica: o código decide, a IA escreve.
Anthropic EngineeringLista de funções + progresso
Para agentes de longa duração, a Anthropic recomenda uma lista estruturada de funções, um arquivo de progresso e um commit por avanço. O manifesto do Pixios já cumpre esse papel.
Harness de longa duraçãoO que times maduros fazem de diferente
Seis práticas, de áreas que o Pixios ainda não olhou: integração contínua do Google e da Microsoft, sistemas de build, engenharia de confiabilidade e pesquisa em agentes de código.
Testar só o que mudou
Análise de impacto: liga cada arquivo aos testes que o exercitam e roda só a interseção com a mudança. Variantes rodam no TAP do Google e no Azure DevOps. Sempre acompanhada de uma rodada completa periódica.
Impact analysisCache por conteúdo
O Bazel guarda o resultado de cada teste sob um hash de entradas. Se nada que entra no teste mudou, ele não roda: busca o resultado pronto.
Bazel remote cacheTriagem de falhas
Google e outros isolam teste instável da trilha de aprovação e classificam cada falha em um veredito: defeito, instável, ambiente ou tempo esgotado.
Flaky testsPipeline simples vence agente solto
O Agentless localiza, corrige e valida com teste de reprodução, sem deixar o modelo decidir o próximo passo. Superou agentes complexos a US$ 0,68 por problema na SWE-bench Lite.
Agentless (arXiv)Execução durável
Motores como Temporal e Inngest registram cada passo, retomam de onde pararam e fazem as esperas por timer. Há versões enxutas só com Postgres.
Inngest × TemporalObservabilidade de agentes
OpenTelemetry já tem convenções para chamadas de modelo, passos de agente, tokens e custo. Ferramentas abertas como Langfuse dão painel por passo.
Observabilidade LLMNão tirar rigor. Tirar repetição.
Cinco mudanças de mentalidade resumem a Fábrica 2.0. Cada uma vira frentes concretas nos próximos slides.
A rede de segurança continua: a rodada profunda completa ainda roda antes da entrega, e nenhum app sai com problema grave aberto.
Duas velocidades: rápida a cada mudança, profunda no fim
Hoje uma correção que mexe em uma tela dispara cerca de 900 verificações de API e abre todas as telas. O manifesto já sabe quem depende de quem; falta usá-lo.
Hoje
- Correção de 1 rota roda G1 nas 39 rotas e G2 em todas as telas
- Cada rodada de revisão refaz os 9 portões (~22 min)
- Correções gastaram 190 de 293 min de portões das tarefas
Fábrica 2.0
- Mapa de impacto sai do manifesto: rota, telas que a chamam, fluxos que a usam
- Cache por hash: arquivos e entradas iguais, resultado do portão reaproveitado
- Confirmação cirúrgica: as rodadas seguintes reconferem só o que tinha problema aberto
Rápida · segundos a minutos
Em toda tarefa e correção. Só o recorte afetado. Falha cedo, com o agente ainda no contexto.
Profunda · uma vez por entrega
Os 9 portões no app inteiro, sem cache. É o que garante que o recorte não deixou nada escapar.
Auditoria do pulado
Em 1 de cada 10 rodadas rápidas, o Pixios roda também o que pulou, para provar que o mapa de impacto não está errado.
O ganho de 190 para ~50 minutos é estimativa minha, a validar na Onda 1. O cache e a auditoria por amostragem são o que a literatura recomenda para isso ser seguro.
Todo "reprovou" passa por um juiz antes de virar tarefa de correção
Hoje um 409 de regra de negócio, um timeout do próprio portão e um defeito real recebem o mesmo tratamento: viram P1 e gastam uma tarefa de correção. O juiz é código, não IA, e dá um de quatro vereditos.
Defeito
Reproduz nas 2 execuções e contraria o contrato. Vira correção, como hoje.
Regra de negócio
O manifesto declara que aquele status é esperado naquele estado. Não reprova.
Instável
Passa numa e falha noutra. Vai para quarentena: continua rodando e registrado, mas não bloqueia.
Infraestrutura
Estouro de tempo, app que não subiu, limite do motor. Repete o portão, nunca culpa o app.
A guarda do contrato já impede o agente de afrouxar o manifesto. Assim o juiz só aceita o que o planejador, e portanto o escopo aprovado pelo cliente, declarou. Este é o fim do falso alarme sem abrir o atalho que a Fábrica fechou.
O manifesto gera os testes. O macaco vira exploração com plano
O contrato do app é uma especificação. Ferramentas abertas já sabem transformar especificação em milhares de casos, sem escrever teste à mão.
API: da especificação aos casos
Do manifesto sai um OpenAPI. Ferramentas como o Schemathesis geram casos com valores de borda e tipos inválidos, e encadeiam chamadas: cria um recurso, depois lê, atualiza e apaga, usando o id real. O G1 atual testa 23 conferências por rota; o modo encadeado acha bugs que só aparecem com id verdadeiro.
SchemathesisTelas: planejar, gerar, curar
O Playwright 1.56 trouxe três agentes de teste: o planejador explora o app e escreve o roteiro, o gerador o transforma em teste, o curador conserta o teste quebrado. Hoje o G4 sorteia cliques por 15 min e não entrega resultado.
Playwright Test AgentsUm navegador, muitos contextos
No Playwright, criar um contexto isolado é muito mais barato que abrir um navegador novo. O padrão é um navegador por trabalhador e um contexto por teste. G2, G3 e G5 podem dividir um navegador e rodar em paralelo.
Orçamento de tempo por parte
O G4 vira três sub-portões (aleatório, API, rastreador), cada um com teto e progresso gravado. Assim ele sempre entrega o que achou até aqui, em vez de ser cortado e valer zero.
Schemathesis é Python. Duas saídas: rodar em contêiner ao lado do G1, ou reproduzir o essencial (casos de borda e encadeamento) em Node. Decido na Onda 2 depois de um teste de 1 dia.
A pergunta que os portões ainda não respondem: o app faz o que foi pedido?
Os 9 portões provam que o app é robusto: não cai, não vaza, não quebra no celular. O estudo "Building to the Test" mostra o risco de um agente passar nas provas e não entregar a função. A cura é ligar escopo a prova.
Mais inteligente e mais barato: dar ao agente os casos antes de ele escrever (como o Agentless faz com testes de reprodução) reduz tentativas. O holdout mantém a honestidade.
Localizar, reproduzir, corrigir, validar. Nessa ordem.
O Agentless mostrou que um fluxo fixo de quatro passos bate agentes soltos. A tarefa de correção do Pixios pode seguir o mesmo roteiro, com o código no comando.
Verificar uma vez, reutilizar em todo app
O pixios-base já poupa a IA de refazer login, menu e idiomas. A ideia é levar isso adiante: módulos prontos e provados que o esqueleto monta, e a IA só personaliza.
O que muda no plano de tarefas
As proporções do gráfico são ilustrativas. A primeira ação é medir, nos 3 últimos builds, quantas tarefas eram CRUD padrão.
Como funciona
Cuidado de produto: peça certificada é ponto de partida, não gaiola. O cliente pede identidade e regra própria, e o agente continua livre para alterar o módulo dentro do escopo; o que muda é que a alteração é reverificada.
Portões são CPU. Agentes são cota. Separe os dois.
74% do relógio é espera. Três mudanças atacam três esperas diferentes.
QA contínuo por módulo
Quando um módulo termina, os portões G2, G3 e G7 rodam nele enquanto o próximo módulo é escrito. Defeito aparece com o contexto fresco, e a revisão final só confirma. Portões não gastam cota do agente.
Fila durável
Hoje o laço de 5 s mora na memória. Uma fila durável no Postgres que já existe guarda cada passo e cada timer: "retomar às 14h, quando a sessão resetar", e sobrevive a reinício. Desfaz a espera cega e a tentativa gasta à toa.
Durável em 150 linhasBanco de teste por portão
Os portões de um projeto rodam em fila exclusiva para não brigarem pelo mesmo banco de teste. Com um schema descartável por portão, G2, G3, G5 e G7 podem rodar juntos.
Sem teto de sessão
As 60 tentativas que morreram no limite da assinatura somem. O limite passa a ser de taxa por faixa de uso, não de sessão.
Cache de prompt
Regras da Fábrica, manifesto e base se repetem em cada uma das 233 tentativas. Pelo preço oficial, a leitura do cache custa 10% do input depois de uma escrita de 1,25×.
Preços AnthropicBatch para o que não tem pressa
Triagem, relatório e revisões fora do caminho crítico podem ir em lote com 50% de desconto, acumulável com o cache.
Isso respeita a decisão de 04/10: a assinatura Claude vale só para você validar. O adaptador de motor trocável já existe; falta o ajuste de cache e lote.
O app nasce na frente do cliente, módulo a módulo
Hoje o cliente espera ~40 h por um app inteiro. Com preview incremental, ele vê, toca e corrige o rumo cedo, e confiança é o que fideliza.
Preview real, dados de exemplo
Ao fechar um módulo nos portões rápidos, o flow publica um link só de leitura com os dados de demonstração. O cliente clica no que já está pronto.
Progresso honesto
O acompanhamento deixa de ser só percentual e passa a ser a lista de funções do manifesto, cada uma com estado: escrevendo, verificando, pronta. Vem do arquivo de progresso que a Anthropic recomenda.
Feedback cedo, custo menor
Um ajuste pedido no módulo 1 custa uma tarefa. Pedido no fim custa uma correção que re-testa tudo. Mantém as regras de alteração do plano pago.
O que não é medido não é cortado
Na apresentação anterior, eu não consegui separar quanto das 29h40 de espera era limite, fila ou pausa. Sem isso, qualquer ganho é palpite. A Onda 0 resolve.
O que passa a ser gravado
Painel do admin
Barras de "a medir" são posições ilustrativas. Os valores reais entram com a Onda 0.
Sem custo de licença: Langfuse é aberto e roda em contêiner na própria VPS. A pasta do projeto fica no Postgres que você já tem.
O mesmo caminho, com memória e sem espera cega
O que ganha cor é novo. O resto continua como hoje. Nenhum portão sai.
De ~40 h para perto de 13 h, sem tirar nenhum portão
Estimativas minhas, para validar com 3 builds depois de cada onda. A maior parte do ganho vem de espera, não de trabalho.
| Parte do relógio | Hoje | Ondas 0 a 2 | Ondas 0 a 4 | De onde vem |
|---|---|---|---|---|
| Agentes escrevendo | 211 min | 211 min | 211 min | peças certificadas reduzem depois (hipótese) |
| Portões nas tarefas | 293 min | ~153 min | ~153 min | correção cirúrgica (190 → ~50 nas correções) |
| Revisão geral | 131 min | ~55 min | ~55 min | 1 profunda + confirmações curtas; G4 que entrega |
| Espera | ~1.780 min | ~890 min | ~356 min | juiz (−pausas), fila durável, motor API, QA contínuo |
| Total | ~40 h | ~22 h | ~13 h |
Hipóteses da espera: −50% só com lógica e −80% com motor por API. O corte real depende da Onda 0, que separa quanto era limite, fila e pausa. Primeiro preview clicável ao cliente: meta de 2 h (Onda 3).
Cinco ondas, cada uma já entrega valor
Esforço é estimativa minha, com a Fábrica já conhecida. Cada onda termina testada num build real e com o docs/estado-atual.md atualizado.
Medir e triar
Rastro com causa de espera. Veredito de 4 estados. Manifesto ganha respostas_validas e o G1 passa a lê-las. G4 em três sub-portões com tempo próprio. Timeout de portão vira infraestrutura, não P1.
Só o que mudou
Mapa de impacto do manifesto. Correção cirúrgica. Cache de veredito por hash. Rodada de confirmação só do que está aberto. Auditoria de 10% do pulado.
Contrato vira prova
OpenAPI gerado do manifesto. Casos encadeados na API. Exploração guiada no lugar do macaco. Jornada de aceitação por requisito. Holdout de 30%. Navegador com vários contextos.
Peças e fluidez
Geradores de CRUD determinísticos e certificados. QA contínuo por módulo. Preview incremental e progresso por função no flow. Banco de teste por portão.
Escala
Fila durável no Postgres. Motor por API com cache de prompt e lote. Painel e metas no admin. Alerta para a equipe quando o limite de rodadas é atingido (colaborador a cadastrar).
O que poderia dar errado, e o que impede
Toda otimização de verificação tem um modo de falhar em silêncio. Cada uma tem uma trava.
O mapa de impacto deixa passar um bug
Trava: rodada profunda completa e sem cache antes de toda entrega, mais auditoria aleatória de 10% do que foi pulado. Se a auditoria achar algo, o cache daquele portão é invalidado.
O juiz chama de regra o que era bug
Trava: só vale resposta declarada pelo planejador no manifesto aprovado. O trabalhador não consegue editar a lista (guarda do contrato). Toda regra aceita aparece no relatório para o dono ver.
Peças viram monocultura
Trava: o módulo é ponto de partida. O agente altera dentro do escopo, e a alteração é reverificada. Segue a regra de que qualquer IA pode ser plugada porque a qualidade está nos portões.
Mais agentes, mais confusão
Trava: o teto de 2 agentes só sobe por módulos independentes, com medição. A pesquisa da Anthropic indica que código é fortemente acoplado e rende pouco em multiagente.
Cliente vê preview com bug
Trava: o preview só abre depois de o módulo passar nos portões rápidos, com dados fictícios e leitura apenas. Nada de dado real exposto.
Complexidade nova para manter
Trava: arquivos pequenos e módulos (regra sua), uma onda por vez, e a Onda 0 mede antes de qualquer coisa maior. Se uma frente não paga, não entra na seguinte.
Quase tudo é tempo de engenharia, não mensalidade
As ferramentas pesquisadas são abertas e rodam nas suas VPS. O custo recorrente que importa cai, não sobe.
| Item | Licença | Roda onde | Efeito no custo por build |
|---|---|---|---|
| Schemathesis (ideia) | aberta | contêiner na VPS | zero de IA |
| Playwright e agentes de teste | aberta | já instalado | planejador usa IA, o resto não |
| Fila durável | pg-boss ou similar | Postgres atual | zero |
| Langfuse / OpenTelemetry | aberta | contêiner na VPS | zero |
| Cache de prompt (motor API) | tarifa Anthropic | API | leitura a 10% do input |
| Lote (Batch) | tarifa Anthropic | API | −50% no que não tem pressa |
Não calculei o custo em reais por build ainda: falta o rastro de tokens da Onda 0. Eu trago o número real depois dela, antes de você aprovar a Onda 3.
O que preciso de você para começar já
- Aprovar as Ondas 0 e 1. Resolvem a pausa da Peixaria e cortam a maior parte da repetição, com risco baixo. Recomendo começar hoje.
- Autorizar o planejador a declarar respostas_validas no manifesto. É a única mudança de contrato; a guarda continua impedindo o trabalhador de editar.
- Quando migrar os clientes pagantes para o motor por API. Decide a data da Onda 4 (cache, lote, sem limite de sessão).
- Contato do colaborador (nome, e-mail e WhatsApp) para o aviso do limite de rodadas. Está pendente desde o último ajuste.
Proposta de 07/10/2026. A apresentação anterior, com a estrutura e os números do build, está em pixios-base.agenciaxara.com.br.