Como o Pixios constrói um app, e por que ele verifica tanto
Um caso real: o build da Peixaria. Todos os números vêm do banco de dados da Fábrica, lidos em 07/10/2026.
As 80 mil verificações parecem muito porque são pequenas, baratas e repetidas
Três ideias explicam quase tudo. As duas primeiras são de propósito. A terceira é um custo que dá para cortar.
Cada verificação é minúscula
Uma chamada à API, um item checado numa tela. Feitas por código, sem IA, em milissegundos. As 901 verificações da API levam cerca de 2 segundos.
Quem escreve não aprova
A IA escreve o código, mas quem decide se passou é o código do Pixios. Um agente nunca encerra uma tarefa só porque disse "terminei".
A conta multiplica
Toda tarefa roda os portões, e cada correção re-testa o app inteiro. As 29 correções geraram 73% das verificações.
E a demora? O build leva cerca de 40 horas no relógio, mas só cerca de 10h35 são trabalho medido. O resto é espera. Há desperdícios reais, que mostro nos slides 12 e 13, e dá para cortar boa parte.
Uma linha de montagem onde o código manda e a IA executa
O cliente aprova o escopo no chat. A partir daí, esta é a rota de um app até a entrega.
Só 2 papéis são de IA. Os outros 6 são código comum.
A IA é cara, lenta e pode errar. Por isso ela fica restrita ao que só ela faz: planejar e escrever. Todo o resto é determinístico.
Orquestrador
Fila no Postgres. Respeita o limite de 2 agentes, o horário, o orçamento (US$ 25 por build) e as dependências entre tarefas. Só existe um por banco.
Planejador
Lê o escopo e responde em JSON. O código valida; se estiver inválido, devolve o erro e a IA tenta de novo, até 3 vezes.
Esqueleto
Copia a base pronta e cria o schema do banco. É o que mais economiza: a IA não gasta nada refazendo login e menu.
Trabalhadores
Sonnet. Cada um pega 1 tarefa numa pasta isolada (git worktree) e só pode alterar os arquivos permitidos para ela.
Guarda do contrato
Impede o agente de "dar um jeito": remover rota, trocar papel, mostrar campo sensível para mais gente, afrouxar limite.
Portões G0 a G8
Nove famílias de verificação automática. Decidem se a tarefa passou e se o app pode ser entregue.
Integração
Junta o trabalho na versão principal, uma tarefa por vez, e re-confere se a versão principal mudou no meio do caminho.
Relatório
Monta o que o cliente enxerga, campo por campo, com lista de permitidos. Nunca expõe portões, modelos ou prompts.
Um build passa por estados fixos
O orquestrador move o build de um estado para o outro. A revisão e a correção ficam num vaivém até não sobrar problema grave.
Dentro de "construindo", as tarefas saem em fases
Na Peixaria o plano gerou 5 módulos, e cada um teve banco, dados, API, telas e integração. Isso dá 33 tarefas (13 de tela, 5 de cada um dos outros tipos). As outras 29 das 62 são correções criadas pela revisão geral.
Cada tarefa é um laço até passar
O agente não se auto-avalia. Ele escreve, o código mede, e o resultado volta como um relatório curto.
Se a mesma falha aparece duas vezes seguidas, a tarefa sobe para o motor mais forte. Se ainda assim não passar, o build pausa em vez de insistir às cegas.
Como foram as 233 tentativas da Peixaria
62 tarefas, média de 3,8 tentativas por tarefa. A mais difícil, a T05 (integração), levou 8.
Três travas impedem o agente de "dar um jeito"
Um modelo sob pressão para passar nos testes tem um atalho óbvio: mudar o teste, ou o combinado. A Fábrica fecha esse atalho.
Arquivos permitidos
Cada tarefa lista as pastas que pode tocar. O código compara o git antes e depois e reverte o que estiver fora da lista.
Contrato do app
O pixios.manifesto.json é o mapa do que existe e de quem acessa. O agente pode acrescentar, nunca remover rota, trocar papel ou liberar campo sensível.
Portões que leem o contrato
Os testes saem do manifesto, e quem o altera é o planejador, não o trabalhador. Por isso qualquer IA pode ser plugada: a qualidade está nos portões.
Nove verificações, cada uma cuida de um tipo de erro
Estático
O código compila? Tem segredo escrito nele? Os textos existem nos 3 idiomas?
API
Cada rota é chamada com caso feliz, sem login, com papel errado, com entrada inválida e com id inexistente.
Páginas
Cada tela × papel × aparelho × tema. Abre sem erro? Sem rolagem lateral? Nada atrás do menu? Contraste?
Fluxos
Roteiros reais: cadastrar, editar, filtrar, abrir detalhe, excluir.
Macaco
Clica em tudo, escreve valores ruins em todo campo e sorteia ações por minutos, com semente fixa para reproduzir.
Papéis
Cada papel só vê o que deve. Spread, lucro e taxas somem de quem não pode ver.
Visual
Prints de todas as telas e medidas de layout: texto cortado, número truncado, elemento fora da caixa.
Segurança
Injeção de SQL, XSS, cabeçalhos, limites de requisição, dados expostos.
Desempenho
Memória do app (limite de 256 MB), consultas em laço (N+1), listas sem paginação.
| Tipo de tarefa | G0 | G1 | G2 | G3 | G4 a G8 |
|---|---|---|---|---|---|
| banco, dados, API, textos | sim | sim | não | não | não |
| tela | sim | sim | sim | não | não |
| integração e correção | sim | sim | sim | sim | não |
| revisão geral | sim | sim | sim | sim | sim |
Uma verificação é um item conferido, não um teste inteiro
Dois exemplos reais da Peixaria mostram como o número cresce rápido sem ser pesado.
901 verificações em 2 segundos
Por rota: o caso feliz de cada papel (3), sem login, papel errado, entrada inválida, id inexistente e o limite de requisições. Tudo por HTTP contra um banco de teste descartável.
1.354 verificações na revisão geral
Uma combinação é tela × papel × aparelho × tema (claro e escuro; celular, tablet e PC). Em cada visita se confere erro de console, rolagem lateral, menu cobrindo botão, imagem quebrada, contraste e mais.
As verificações são contadas pela última rodada de cada portão em cada tarefa. As tentativas que reprovaram não entram, então o número de 80.688 ainda é conservador.
Onde estão as 80.688 verificações
Quase 83% vêm de só dois portões, a API e as páginas, porque rodam em toda tarefa.
G4, G6 e G8 contam zero. G6 e G8 medem coisas que não viram "itens conferidos". O G4 (macaco) deveria contar milhares de cliques, mas nunca terminou. Isso é um problema que mostro no slide 13.
As 29 correções geraram 73% das verificações
Uma correção costuma mexer em um lugar só. Mas, como está hoje, ela é conferida como se fosse o app inteiro.
Por que a correção sai tão cara
No código, a correção roda G0 a G3 sem lista de rotas. O G1 então testa as 39 rotas, e o G2 abre todas as telas, mesmo que o erro fosse em uma só.
O efeito em números
Uma tela nova gera cerca de 356 verificações de API. Uma correção gera cerca de 900, porque re-testa tudo.
Só 26% do tempo é trabalho. O resto é espera.
O build começou em 06/10 às 05h05 (UTC) e ainda está na revisão. São cerca de 2.418 minutos no relógio.
Limite da assinatura
60 tentativas bateram no limite de sessão do Claude e ficaram esperando o reset. Hoje o código trata isso como espera, não como tentativa gasta.
Fila e paralelismo
Só 2 agentes ao mesmo tempo, e os portões de um projeto rodam um por vez (fila exclusiva), para não brigarem pelo mesmo banco de teste.
Pausas e reinícios
O build pausou por limite de rodadas e a API foi reiniciada algumas vezes para ativar melhorias. Não consegui separar quanto de cada causa.
O que a malha pegou antes do cliente ver
30 problemas encontrados até agora: 1 crítico, 14 graves, 8 médios e 7 leves. Desses, 17 já foram corrigidos.
Problemas novos por rodada
Consertar cria problemas novos, por isso uma rodada só não basta.
O rigor é de propósito. Cinco pontos não são.
Estes são os custos que não compram qualidade, medidos no build da Peixaria.
O macaco (G4) estoura o tempo em toda rodada
Nas 6 revisões ele bateu o teto de 15 minutos e foi cortado, sem entregar resultado. Gastou 69% do tempo da revisão geral e zero verificações. Ainda não sei qual das três partes dele (aleatório, API, rastreador) consome o tempo.
A correção re-testa o app inteiro
Em tela e fluxo, as 29 correções gastaram 190 dos 293 minutos de portões das tarefas, para consertar problemas localizados.
Toda rodada de revisão refaz tudo
Restam 2 problemas e a rodada seguinte roda os 9 portões completos de novo, cerca de 22 minutos, só para confirmar 2 correções.
Falsos positivos do G1
Pelo menos 5 achados "esperava 200 e veio 409" parecem ser regra de negócio (ex.: não excluir bairro com pedidos), não defeito. Cada um custou uma tarefa de correção.
Tentativas queimadas no limite da assinatura
60 das 233 tentativas morreram no limite de sessão e contaram como tentativa. O código novo já trata como espera.
Quatro ajustes cortam o tempo sem afrouxar a qualidade
Nenhum remove um portão. Todos mudam só quando e onde ele roda. Os ganhos abaixo são estimativas minhas, a validar depois.
1. Correção cirúrgica
Rodar G1 só nas rotas do achado, G2 só na tela afetada e G3 só no fluxo afetado. O app inteiro continua sendo testado na revisão geral.
2. Conserto do macaco (G4)
Dar a cada parte um tempo próprio e gravar o progresso. Assim ele entrega resultado em vez de ser cortado. É o único portão hoje sem nenhum resultado.
3. Rodada de confirmação
Depois da 1ª revisão completa, as rodadas seguintes reconferem só os portões que tinham problema aberto, e uma revisão completa final fecha o build.
4. G1 entende regra de negócio
Não reprovar 409 de "tem vínculos" nem 404 de estado inválido, e testar exclusão num registro sem dependências.
O que levar desta apresentação
- A IA só escreve. Planejar, mandar, medir e liberar é código do Pixios.
- Os 9 portões existem para o cliente não achar bug. Eles pegaram 30 problemas, incluindo uma injeção de SQL.
- As 80.688 verificações são itens baratos, conferidos por código, e a maior parte vem das 29 correções.
- Das ~40 horas, só ~10h35 são trabalho; o resto é espera por limites, fila e pausas.
- Há desperdício real (macaco, correção que re-testa tudo, revisão completa repetida) e dá para cortar sem perder rigor.
Dados do banco da Fábrica em 07/10/2026 · build da Peixaria, em revisão geral na rodada 6