Neste artigo
- Qual é a régua real de prazo por tipo de projeto?
- Por que a especificação decide o prazo inteiro?
- O que realmente atrasa um projeto tocado por agente?
- Dá para acelerar rodando dois agentes ao mesmo tempo?
- Como estimar um projeto que você ainda não entendeu?
- Esses prazos valem para quem está começando agora?
Um SaaS simples com cadastro, painel e uma integração sai em cerca de dois dias de trabalho real, quando a especificação existe antes do código. Um sistema grande e de verdade complexo leva de um a dois meses, e noventa por cento dos projetos ficam abaixo de trinta dias. O que decide esses números não é a velocidade do agente de código, é quanto tempo você gasta decidindo o que construir.
Abaixo está a régua que eu uso hoje, medida nos meus próprios projetos entregues, e o motivo de ela não bater com estimativa de time tradicional. Estimativa clássica embute reunião, alinhamento, espera por gente ocupada e repasse de contexto entre pessoas. Quando uma pessoa orquestra dois agentes, quase toda essa camada desaparece e sobra o tempo de pensar e o tempo de validar.
Qual é a régua real de prazo por tipo de projeto?
A régua abaixo assume um desenvolvedor experiente orquestrando dois agentes em paralelo, com especificação escrita e gates automáticos rodando. Ela não vale para quem está aprendendo a ferramenta durante o projeto, porque aí o tempo de aprendizado domina tudo. Também não vale para projeto com dependência externa mal resolvida, onde o prazo é ditado por terceiros. Dentro dessas condições, os números se repetem com bastante consistência.
| Tipo de projeto | Prazo real | Onde o tempo realmente vai |
|---|---|---|
| Aplicação simples com painel e webhook | 2 a 8 horas | Quase tudo em especificar e revisar |
| SaaS de primeira versão com pagamento | 3 a 10 dias | Integração de cobrança e isolamento de dado |
| Sistema com integração a ERP de terceiro | 15 a 45 dias | Depende do outro lado, não de você |
| Plataforma grande e realmente complexa | 30 a 60 dias | Arquitetura, migração e teste de carga |
| Fonte: prazos dos meus próprios projetos entregues, apurado em setembro de 2026. | ||
Essa régua incomoda quem estima em semana de time humano, e ela continua honesta para quem trabalha sozinho orquestrando agentes. A diferença não vem de digitar mais rápido, vem de eliminar a espera entre pessoas. Um time de quatro gasta uma parte grande do prazo em coordenação, alinhamento e repasse de contexto. Uma pessoa com dois agentes não tem essa camada, e o custo disso é não ter redundância nenhuma.
Por que a especificação decide o prazo inteiro?
Um agente de código escreve rápido exatamente o que você pediu, inclusive quando o que você pediu está errado. O custo desse erro não aparece na hora da entrega, aparece quando o recurso já está integrado a outros três. Desfazer uma decisão errada exige mexer em tudo que foi construído em cima dela. Por isso cada hora gasta escrevendo o critério de aceite economiza várias horas de reconstrução depois.
Na prática isso é o inverso do que a intuição sugere, porque escrever documento parece atrasar o começo do trabalho. O que acontece é que o começo fica mais lento e o fim fica muito mais rápido, com menos idas e vindas. Projeto que começa a codar na primeira hora costuma terminar depois de projeto que começa a codar no segundo dia. Eu detalhei esse fluxo em spec driven development com Claude Code e Codex.
O que realmente atrasa um projeto tocado por agente?
A lista de causas de atraso é curta e quase nunca tem a ver com o modelo estar lento ou com limite de uso. São sempre os mesmos quatro itens, e três deles são organizacionais e não técnicos. Reconhecer isso muda onde você investe atenção durante o projeto. Otimizar a ferramenta enquanto o gargalo é uma credencial pendente não adianta nada.
Decisão pendente do outro lado: esperar acesso, credencial ou resposta de quem controla o sistema de destino é a causa de atraso mais comum que eu vejo. Esse tipo de espera não aparece em cronograma e consome semanas inteiras. A defesa é resolver todo acesso na primeira semana, antes de precisar dele.
Escopo que muda no meio: trocar a regra depois que o código existe custa mais do que trocar antes, e essa diferença cresce a cada dia de projeto. Pedido pequeno somado a pedido pequeno vira um mês a mais sem ninguém ter percebido a soma. Registrar cada mudança com o impacto de prazo é o que mantém a conversa honesta.
Falta de gate automático: sem teste e sem verificação rodando a cada passo, o erro só aparece em produção, e consertar ali custa o dobro. Gate é o que permite aceitar trabalho de agente sem ler cada linha. Montei a lista do que cobrir primeiro em testes em projeto tocado por agente.
Revisar tudo na mão: ler cada linha do que o agente escreveu anula completamente o ganho de velocidade e ainda cansa quem revisa. A saída é revisar por prova e por amostragem dirigida ao que é arriscado. Código de autenticação e de cobrança merece leitura integral, e tela de listagem não merece.
Dá para acelerar rodando dois agentes ao mesmo tempo?
Dá, e o ganho é real quando as tarefas são de fato independentes uma da outra. Dois agentes na mesma pasta mexendo nos mesmos arquivos produzem conflito e retrabalho, não velocidade. O que funciona é separar as raias antes de começar, com cada agente numa cópia isolada do repositório. Cada um trabalha na sua frente e a junção acontece no fim, com revisão.
O arranjo técnico que sustenta isso usa cópias de trabalho separadas do mesmo repositório, sem duplicar o histórico. Assim cada agente enxerga o projeto inteiro e escreve só na própria área. Descrevi a configuração completa em Git e worktrees com Claude Code e Codex. O limite prático fica em duas ou três frentes, porque a partir daí a atenção de quem coordena vira o gargalo.
Como estimar um projeto que você ainda não entendeu?
A resposta honesta é que não dá para estimar, e fingir que dá é a origem de quase todo projeto que estoura prazo. O caminho útil é cobrar uma sondagem curta e paga antes de comprometer o prazo do todo. Um a dois dias investigando a parte mais arriscada devolvem uma estimativa que vale alguma coisa. Sem isso, qualquer número dito na primeira conversa é chute com aparência de compromisso.
A parte mais arriscada quase sempre é a integração com sistema que você não controla. Testar uma chamada real contra o ambiente do cliente na primeira semana revela em horas o que o cronograma esconderia por um mês. O custo dessa sondagem é sempre menor que o custo de um projeto que estoura. Cliente sério entende esse argumento quando ele vem com o número da sondagem na frente.
Esses prazos valem para quem está começando agora?
Não valem, e é importante dizer isso com clareza para ninguém se frustrar comparando. A régua acima pressupõe alguém que já sabe arquitetar sistema, avaliar risco e ler resultado de teste. Quem está aprendendo essas coisas durante o projeto vai levar várias vezes mais tempo, e isso é normal. O agente acelera quem já sabe julgar, e não substitui o julgamento de quem ainda não sabe.
Para quem está no começo, o caminho mais rápido é reduzir o escopo até caber em um fim de semana e terminar de verdade. Projeto pequeno concluído ensina mais que projeto grande abandonado no meio. Depois de três ou quatro ciclos completos, a régua de prazo começa a se aproximar da que está na tabela. A documentação oficial do Claude Code cobre bem o funcionamento das ferramentas por baixo, e o guia completo de Claude Code em português é por onde eu mando quem está começando.


