Estimativa no vibe coding: o agente refez a conta de 8 para 4 horas

Um prazo dado antes de os requisitos estarem fechados precifica o desconhecido, não a tarefa. Você só descobre qual parte daquele número era trabalho de verdade quando a dúvida some e alguém refaz a conta.

Martin constrói o Fumava, o app dele para parar de fumar, e usa um agente orquestrador que mantém o roadmap do projeto. O primeiro marco desse roadmap é criar o esquema do banco de dados, e o roadmap dizia 8 horas para ele. Assim que a lista de campos do onboarding ficou definida, o agente voltou ao assunto por conta própria e cortou o próprio número pela metade.

O agente abriu a fala com a palavra correção

Ninguém tinha perguntado nada sobre prazo. Ele interrompeu a explicação que estava dando sobre outro assunto, marcou a frase como correção e reabriu a estimativa:

O roadmap dizia 8 horas para M0, porque na época a gente não sabia quais campos existiam.

Com a lista de campos na mão, o mesmo marco ficou mais perto de 4 horas. E deu o motivo:

A estimativa antiga estava inflada pela incerteza que a gente acabou de eliminar.

Os campos tinham acabado de ser definidos ali mesmo, no trabalho anterior daquela sessão (como os campos foram descobertos).

As 4 horas nunca foram testadas

A live terminou poucos minutos depois dessa fala, com o marco ainda por construir. Martin encerrou a transmissão avisando que tinha sido uma live curta, e nada foi cronometrado.

Então o que aconteceu ali não foi resolver a incerteza e cortar o trabalho pela metade. Foi o próprio estimador, refazendo a conta sem a dúvida, cortar o próprio número. Isso não mede o trabalho, mede quanto da estimativa original era colchão para o que ninguém sabia ainda.

É fácil sair dessa cena com a conclusão de que definir requisito faz o desenvolvimento andar duas vezes mais rápido, e não foi isso que ficou provado. As 4 horas continuam sendo um palpite, só que um palpite feito com mais informação. Se o marco tivesse sido construído naquele dia, o cronômetro poderia ter desmentido os dois números.

O que perguntar ao agente que te dá um prazo no vibe coding

Pergunte o que ele ainda não sabe sobre esse trabalho. Ele soa igualmente confiante sabendo e não sabendo, então o tom da resposta não serve de medida.

O conteúdo da resposta serve. Se ele diz que não sabe quais campos a tabela vai ter nem quantas telas dependem daquilo, o prazo está pagando por essas dúvidas antes de pagar por qualquer linha de código. Feche uma delas e peça o número de novo. A distância entre os dois números é o preço que a incerteza estava cobrando.

No vibe coding dá para ver esse preço, porque o agente escreve o roadmap e depois escreve a revisão, e as duas versões ficam no histórico, uma embaixo da outra. Quem estima de cabeça guarda a margem em silêncio, e ninguém nunca descobre o tamanho dela.

Definir requisito não é burocracia que atrasa o começo

Enquanto os campos do onboarding não estavam decididos, a tarefa parecia maior do que era, e o roadmap dizia 8 horas por causa disso. Fechar o requisito é o que faz o número parar de mentir sobre o tamanho do trabalho.

Repare que ninguém acelerou nada. O marco sempre foi do tamanho que ele é. O que mudou foi a informação de quem estava estimando.

E o caminho contrário conta a mesma coisa: se a lista de campos tivesse saído mais complicada do que se supunha, a revisão teria empurrado a estimativa para cima, e isso também seria um bom sinal. O sinal de saúde é a estimativa se mexer quando a informação muda, e não o número cair. Um agente que revisa o próprio prazo quando o contexto muda vale mais que um que defende o prazo antigo até o fim do projeto.

Abra o roadmap do seu agente e refaça uma conta

Escolha o item mais caro da lista e pergunte o que ainda não está definido nele. Feche o que der para fechar hoje e peça a estimativa de novo, sem dizer qual número você esperava ouvir. Se ele repetir o mesmo prazo depois de receber informação nova, você não tem uma estimativa, tem um chute com cara de planilha.

Dá para assistir à live e ver a correção acontecer sozinha, no meio de uma explicação sobre outra coisa. Esse tipo de detalhe, o momento em que alguém muda de ideia sobre o próprio prazo, é o que o vibe coding feito ao vivo entrega e o repositório pronto esconde.