41 horas no relógio. Só 8 com a Fábrica trabalhando.
Você estranhou a estimativa de 13 horas, porque nunca levou mais de 8 horas com o Claude para criar algo de verdade. Você tem razão. Abri o banco do build da Peixaria, medi cada minuto e comparei com o que o mercado publica. O Claude não é o lento: o que atrasa é o que acontece em volta dele.
Três paradas somam 33 horas. O resto é trabalho.
Cruzei o horário de cada execução de agente e de cada rodada de portão do build da Peixaria (06 e 07/10). Onde não há nenhum evento, a Fábrica estava parada.
06/10, das 06h02 às 11h10. Não há erro registrado no banco. Compatível com pausa do build (limite de rodadas era 4) ou reinício.
06/10 15h00 até 07/10 12h58. A assinatura bateu o limite de sessão (volta às 15h50 UTC). 62 tentativas foram queimadas contra o limite e o build ficou esperando uma pessoa.
07/10, das 14h49 às 20h49. Sem erro registrado. Coincide com a pausa por limite de rodadas e as correções que fizemos na plataforma.
Duas tarefas ao mesmo tempo: 11,6 h de trabalho medido (agentes 3,6 h + portões 8,0 h).
Correção da minha estimativa anterior: eu tratei a espera como parcialmente inevitável (−50% só com lógica, −80% com motor por API). Pelos dados, ela é quase toda pausa que espera uma pessoa ou um reset de limite, e isso se resolve com retomada automática. Por isso o 13 h estava pessimista.
O Claude é rápido. O laço em volta dele é que não é.
Sobre "o Claude é barato, por que demora": medi o próprio agente separado do resto.
Execução: 0,9 min
As 237 execuções de agente somaram 3,6 h. A média é 0,9 min e a maior foi 7,4 min. Schema levou 0,4 min, seed 1,0 min, uma página 1,1 min.
Saída pequena
Cada execução escreve em média 4,9 mil tokens. O app inteiro consumiu 1,17 milhão de tokens de saída. É pouco texto; o tempo não está na geração.
Barato, mas com cota
Pelo preço de tabela, o build inteiro custaria US$ 106. Na assinatura é zero, mas ela tem limite por janela de 5 h: só a janela da tarde de 06/10 consumiu o equivalente a US$ 40 e bateu o teto.
Construir levou ~3 h. Conferir e consertar levou o triplo.
As 33 tarefas do plano (banco, dados, API, 13 telas, integração) ficaram prontas em 06/10 às 12h51. Depois vieram 8 rodadas de revisão e 33 tarefas de correção.
Correção custa como construir
As 33 tarefas originais tomaram ~106 min de agente. As 33 correções tomaram 110 min só de agente (139 execuções), fora os portões que rodam depois de cada uma.
37% de tentativas perdidas
Das 237 execuções, 88 falharam nos portões e 62 morreram no limite. Só 87 passaram.
Portões em fila única
Pelo código, os portões de um projeto rodam um por vez (banco de teste único). Os 2 agentes não aceleram a conferência: quem manda é o G3.
Três desperdícios medidos e dois que o código revela
G4 gasta 2 h e não entrega nada
Estoura o teto de 15 min nas 8 rodadas e devolve zero verificações. Dar teto de 2 a 3 min e resultado parcial devolve ~1,8 h de trabalho e ainda cobre as telas.
Correção que re-testa demais
G3 roda a cada tentativa de cada correção: 234 min e menos da metade passa. Testar só o fluxo da página afetada (e o juiz de triagem) corta boa parte.
Parada que espera pessoa
Pausa por limite de rodadas e limite de sessão da assinatura. Retomada automática no horário do reset (já existe desde 07/10) e aviso à equipe quando passa de 30 min.
Banco de teste único
Um schema de teste por projeto obriga os portões a entrar numa fila. Um schema descartável por tarefa (cópia de um modelo) deixa 2 conferências rodarem juntas.
Falso alarme vira tarefa
G1 (409/404) e o timeout do G4 viraram "problema grave". Cada tarefa de correção gasta em média 3,3 min de agente, mais a bateria de portões depois. O juiz de triagem evita as que não eram defeito.
Efeito somado (hipótese)
Tirar ~5 h dos 11,6 h de trabalho medido (estimativa minha). Com 2 conferências em paralelo, o relógio ativo cai de 8,2 h para algo perto de 4,5 h.
Rápido e verificado quase ninguém publica
Os números abaixo medem coisas diferentes. A faixa de minutos é protótipo sem teste. A faixa de semanas é software completo com gente no meio.
| Quem | Tempo | O que entrega |
|---|---|---|
| Bolt.new | 52 s a 2 min | Interface com dados falsos, sem backend de verdade |
| Lovable | ~4 min | App com esquema de banco e regras de acesso, sem bateria de testes |
| Replit Agent 3 | ~10 min; até 200 min sem supervisão | Primeiro app funcionando; depois testa sozinho em navegador real e corrige |
| Pixios (Peixaria) | ~3 h para as 33 tarefas | 13 telas, 5 regras, API, banco e 9 portões de verificação |
| Consultorias de SaaS com IA | 1 a 3 meses (MVP) | IA encurta 25 a 40% das fases; descoberta e design continuam iguais |
| Cursor (navegador do zero) | 1 semana | Mais de 1 milhão de linhas, com vários agentes em paralelo |
| Anthropic (compilador C) | 2 semanas, 16 agentes, US$ 20 mil | 100 mil linhas que compilam o kernel Linux |
Ninguém verifica em minutos
Nos números públicos, o que sai em minutos não passa por segurança, papéis e carga. Isso o Pixios entrega e eles não.
Você já é mais rápido que o mercado
O primeiro build completo das 33 tarefas leva ~3 h de atividade. Sua régua de "menos de 8 h" está dentro disso.
Cuidado com a manchete
Um estudo do METR achou desenvolvedores experientes 19% mais lentos com IA em repositórios que já conheciam. Velocidade depende do laço, não do modelo.
Tempos de Bolt, Lovable e Replit vêm de comparativos e documentação dos próprios produtos, medidos em apps simples. Não encontrei publicação de "SaaS completo, testado e seguro em menos de um dia" por nenhuma equipe.
Cinco estratégias que realmente funcionaram
Hierarquia, não enxame
O Cursor viu 20 agentes iguais renderem como 2 ou 3, porque ficavam esperando uns aos outros. Com planejador, trabalhadores isolados e um juiz que decide quando acabou, escalou. O Pixios já tem essa forma; falta o juiz de triagem.
Teste bom vale mais que mais agentes
Na Anthropic, o maior trabalho foi desenhar o ambiente e os testes. Teste vago faz o agente resolver o problema errado. Os 9 portões são seu ativo; o que precisa melhorar é a precisão.
Paralelo só onde é independente
Três funcionalidades em três cópias de trabalho (worktrees) saíram juntas no mesmo dia. Vale quando não compartilham arquivos nem banco, e é o que a fase "schema → api → páginas" já respeita.
Cache de prompt e esforço certo
Leitura de cache custa 10% do valor de entrada. Esforço baixo em sub-tarefas e alto só em planejamento e correções difíceis é o que a documentação recomenda.
Modo rápido, só onde cabe
O "fast mode" roda o mesmo modelo até 2,5× mais rápido, a 2× o preço, mas só nos Opus e na API. Serve ao planejador (5 min), não ao laço inteiro.
Mostrar cedo
O Replit abre o app para o usuário nos primeiros minutos e continua trabalhando. Isso é percepção de velocidade: o relógio total cai pouco, a espera percebida cai muito.
Haiku para o simples, Sonnet para o difícil, Batch só fora do laço
| Tarefa | Motor | Por quê |
|---|---|---|
| Schema, seed, i18n, páginas CRUD simples | Haiku, esforço baixo | Rodam em 0,4 a 1,1 min e são padrão. Ganho principal é gastar menos cota. |
| Juiz de triagem, relatório, explicação do achado | Haiku | Classificar e resumir; entra no código só como veredito. |
| Páginas com regra própria, correção de 1ª tentativa | Sonnet, médio | É o que roda hoje (sonnet-medio). |
| Planejador, 2ª correção do mesmo achado, segurança | Sonnet, alto | Poucas execuções, erro caro (sonnet-forte). |
Batch no laço do agente
- O Batch processa em até 24 h (a maioria em menos de 1 h) e não suporta laços de ferramenta no meio.
- Cada correção tem de 4 a 5 idas e voltas; com Batch cada uma esperaria na fila.
Batch fora do caminho crítico
- Tradução dos 3 idiomas, geração de dados de exemplo, relatório final, auditoria noturna e o plano grátis (sem pressa).
- Faixa "Econômica" do cliente: Batch e prazo maior. Faixa "Expressa": API com cache, minutos.
Importante: "barato" e "rápido" competem no Batch. Para a meta de poucas horas, o laço fica na API com cache de prompt (leitura a 10%). O Batch economiza onde ninguém está esperando.
De 41 h para perto de 5 h, sem tirar nenhum portão
Hipóteses minhas, para validar com 3 builds depois de cada etapa. A primeira etapa não mexe em portão nenhum.
| Etapa | Conta | Confiança |
|---|---|---|
| 1 · Sem parada | 41,3 h − 33,1 h parado = 8,2 h de relógio ativo | Alta: é aritmética dos dados |
| 2 · Sem desperdício | 11,6 h de trabalho − G4 (1,8 h) − G3 re-testando fora do afetado (~1,5 h) − correções de falso alarme e seus portões (~1,7 h) = ~6,6 h; com 2 conferências em paralelo ≈ 4,5 h de relógio | Média: a parcela de falso alarme é estimativa |
| 3 · Peças certificadas | Schema, seed e API de CRUD padrão (15 das 33 tarefas) deixam de ser escritas do zero pela IA; menos defeito, menos correção | Baixa até medir quantas são CRUD padrão |
Meta de produto: menos de 8 h, a sua régua de uso pessoal. A etapa 1 já cumpre; a 2 dá folga para a revisão de segurança e de acessibilidade ficarem sempre ligadas.
O que eu faria primeiro, em ordem de ganho por esforço
- Teto no G4 com resultado parcial (3 min por rodada e 8 rodadas por build viram ~10 min). Devolve ~1,8 h por build e é a mudança mais simples.
- Retomada sem pessoa: pausa por rodadas ou limite vira espera com horário, e alerta se a Fábrica ficar mais de 30 min sem nenhum evento. Elimina até 33 h.
- Rastro com causa de cada espera (limite, pausa, reinício, fila). Hoje o banco não diz por que houve 2 das 3 paradas. Sem isso, o ganho vira palpite.
- Haiku nas tarefas simples (schema, seed, i18n, triagem) pelo mesmo adaptador de assinatura, só nas contas de teste. Mede cota e tempo por tipo.
- Um schema de teste por tarefa (cópia de modelo) para o G2 e o G3 de tarefas diferentes rodarem juntos.
- Juiz de triagem + G3 só no fluxo afetado, que é a Onda 1 da apresentação anterior. Todas as demais ondas dela seguem valendo.
Aval para começar pelos itens 1 a 3
São de baixo risco e não removem portão. O 3 me deixa provar os números na próxima construção.
Teste do Haiku na assinatura
Posso rodar uma tarefa de cada tipo com Haiku e comparar. Se quiser o 5.5, me diga o identificador do seu painel.
Contato do colaborador
Nome, e-mail e WhatsApp para o alerta de parada. Pendente desde o limite de rodadas.
De onde vêm os números
Dados internos: banco do build da Peixaria (tabelas execucoes, rodadas_teste, tarefas, achados) e o log da API, em 07/10/2026. As fontes externas abaixo.
Investigação de 07/10/2026. A proposta geral da Fábrica 2.0 segue em pixios-fabrica-2.agenciaxara.com.br.