Vibe coding para pedir segunda opinião de IA sobre o projeto inteiro

A conversa em que você construiu o app a semana inteira é a pior fonte para saber o que já existe dentro dele. Martin esbarrou nisso enquanto construía o Fumava, o app dele para ajudar quem quer parar de fumar. Antes de perguntar qualquer coisa a alguém de fora, o estado de espírito era este, dito por ele mesmo na live:

"a gente já avançou bastante aqui no produto, estamos quase nas páginas finais do onboarding"

Então ele abriu uma sessão nova de IA, em outra ferramenta, diferente daquela em que vinha trabalhando desde o começo do projeto. Essa instância não tinha o histórico das conversas nem o acúmulo de decisões da semana, só o que estava escrito no código, e devolveu um diagnóstico que a rotina não vinha devolvendo.

A pergunta certa é de inventário

O pedido dele foi curto e nomeou o objetivo:

"eu gostaria que você analisasse o projeto como um todo, me desse um overview aqui [...] E o que que na sua visão falta para ter um MVP"

"O que falta" é uma pergunta de inventário. Ela abre espaço para o outro lado listar ausências, e ausência é verificável: ou a tela existe no repositório ou não existe. Perguntar o que a IA acha do projeto produz outro tipo de resposta, e elogio você já tem de sobra depois de uma semana de conversa em que tudo foi combinado com você mesmo.

Essa lista é misturada por natureza. Vale ver vibe coding para separar o que falta de codigo do que falta de configuracao, onde Martin descobriu que a maior parte das 12 horas estimadas era papelada de loja, não código. E também vale conferir vibe coding para confirmar deploy sem esperar verificacao completa, onde o caminho de aceitar um sinal antes da verificação completa pede que você saiba exatamente qual sinal é qual. A papelada vai além do código e atinge também decisões sobre segurança de dados, como em vibe coding para preencher seguranca de dados quando app cria conta anonima.

"A porta de entrada está pronta, a casa não está"

A resposta abriu assim:

"Isso é o resumo honesto. A porta de entrada está pronta, a casa não está."

Depois vieram os itens, secos. "Tracker não existe." "Notificações não existe." O achado mais duro foi o caminho inteiro: um testador que terminasse o onboarding cairia numa tela de desenvolvimento. O fluxo de entrada estava completo e do outro lado dele não havia produto. O mesmo inventário ainda apontou o que faltava para levar o app ao teste fechado da loja.

Conversa longa guarda memória de trabalho feito

A IA da rotina não estava mentindo em nenhum momento. Quem faz vibe coding conversa com a mesma sessão por dias, e uma conversa longa carrega tudo que já foi discutido: o que foi muito discutido começa a parecer resolvido. Planejar uma tela, decidir como ela se comporta e escrever a regra dela deixa lembrança de trabalho feito, do seu lado e do lado dela. Ninguém, dentro daquela conversa, está contando o que de fato existe no código. Foi o mesmo caminho de alucinação de número no vibe coding. Vale ver como isso terminou em como criar agente de ia.

A sessão nova não chegou mais esperta. Ela chegou ignorante do jeito certo: não participou de nenhuma promessa, não ouviu nenhum plano, e por isso só consegue responder pelo que encontra no repositório. Onde o código não tem nada, ela escreve "não existe", porque para ela nunca houve uma conversa dizendo que aquilo estava encaminhado.

No vibe coding, essa auditoria fica barata o bastante para virar rotina

O papel não depende de IA. Qualquer pessoa que não acompanhou a semana faz a mesma coisa, e faz há décadas: quem abre o projeto pela primeira vez enxerga o buraco porque não sabe o que foi prometido. O que muda no vibe coding é o preço. Abrir uma instância limpa e pedir o panorama custa alguns minutos e nenhuma agenda, então dá para repetir toda semana. O mesmo problema apareceu em como nao desistir de um projeto com vibe coding.

O custo de pular isso aparece depois. Você planeja o lançamento, recruta testador e marca data com a sensação de progresso no lugar do inventário, e a conta chega quando alguém de fora abre o app e para na primeira tela que não existe.

Isso aparece também em vibe coding para deixar usuario corrigir escolha do onboarding.

Vale separar essa prática de um movimento parecido, exigir evidência antes de confiar na IA: lá, o builder desconfia de uma alegação específica e vai conferir no banco. Aqui não havia alegação suspeita, havia uma auditoria geral pedida a quem não participou do processo. Um caso é verificação pontual, o outro é inventário.

Como pedir para não receber elogio

Faça isso antes de qualquer decisão que dependa de "estamos quase lá": marcar data de lançamento, chamar testador, prometer entrega para alguém. Abra uma sessão nova, de preferência em outra ferramenta, e não cole nenhum resumo do que você acha que já fez, porque o resumo é exatamente a parte contaminada. Aponte para o código e peça 2 listas: o que existe hoje, tela por tela, e o que falta para o objetivo que você nomear ("mandar para teste", "cobrar do primeiro usuário").

Formule sempre como ausência. "O que falta para X" gera lista; "o que você acha do projeto" gera parabéns. Se a resposta vier animada, devolva a pergunta pedindo os itens que não existem e onde deveriam estar. E leia a lista sem discutir com ela: o valor dessa sessão vem justamente de ela não saber o quanto você trabalhou.

Algumas decisões podem ficar em aberto enquanto o produto não existe. Vibe coding para decidir paywall sem trial gratuito mostra como Martin travou a escolha do trial até a tela de pagamento estar pronta, evitando defender uma decisão feita sem o contexto completo. O mesmo padrão de segundas opiniões independentes aparece em camadas de seguranca.

Quando você faz um pedido, o que faz a diferença é saber descrever por que está errado e que tipo de conhecimento o conserta: vibe coding para saber pedir para o agente mostra que o pedido precisa de hipótese e papel.

E para que o pedido seja bem executado, escreva a ordem antes: vibe coding para prompt de corrigir bug com plano antes de executar mostra como anexar as 4 exigências de processo no mesmo pedido.

Antes de tudo isso acontecer, porém, o projeto já precisa estar documentado: vibe coding para documentar projeto antes de codar lembra que o passo a passo do trabalho precisa estar escrito, não na cabeça do builder.

O pedido e a resposta inteira estão na live do Fumava.