"Definição de pronto pra não-dev: 6 perguntas antes de aceitar qualquer entrega da IA"

"Com vibe coding, levei 1 hora codando e 10 horas testando e corrigindo erros."

É de um brasileiro num fórum, e está na pesquisa deste blog. Relato, não estatística. Mas a proporção é a que eu vejo: a construção ficou rápida, e o tempo foi parar depois dela. Boa parte dessas dez horas não é erro novo. É entrega que foi aceita como pronta sem estar, e que voltou dois pedidos depois, mais cara.

Ninguém te deu a sua definição de pronto

Em time de software, "pronto" não é sensação. Tem nome e tem papel. O Guia do Scrum, o manual de um dos métodos de trabalho mais usados por times de software, na versão de 2020, chama de Definição de Pronto (em inglês, Definition of Done): "uma descrição formal do estado do incremento quando ele atinge as medidas de qualidade exigidas pelo produto". Incremento é o pedaço novo que entrou. E o guia é seco: o que não passa na definição não pode ser lançado nem apresentado. Volta pra fila.

O time escreve isso uma vez, e toda entrega passa pelo mesmo crivo. Ninguém decide no olho, cansado, às onze da noite.

Você nunca recebeu a sua. Não foi descuido seu: a ferramenta termina toda resposta com "pronto", e não tinha nenhum papel na mesa dizendo o que essa palavra precisa provar. Esse papel cabe num cartão. Ele é a versão por entrega do checklist "Protótipo ou produto?", que eu uso pra medir o app inteiro.

As seis perguntas

1. Fez o que eu pedi? Antes do pedido, escreva a frase de conferência: "vou saber que está pronto quando, fazendo X, eu vir Y". Depois, faça X e olhe se aparece Y. Se a frase não existe, a pergunta não tem resposta, e o problema começou no pedido. Se for não: uma correção, com o que apareceu na tela colado.

2. Não fez o que eu não pedi? Abra a lista do que mudou (o diff, que é o "antes e depois" de cada arquivo) e procure arquivo que não tem nada a ver com o pedido. Pediu um campo de observação e mexeu no cálculo do total? Isso é um não. Já mostrei onde fica o diff e como ler sem programar. Se for não: volte pro ponto de retorno e peça de novo, cercando o que não pode ser tocado.

3. O teste está verde? Teste é um pequeno programa que confere se uma regra do app faz o que devia. Verde é passou; vermelho, falhou. Vale a saída colada, inteira, não o "todos os testes passaram". O pedido que já chega exigindo isso está aqui. Se for não: não existe teste pra essa regra? Então a resposta é não, e a regra está no "acho que sim".

4. Roda no ar, e não só na pré-visualização? A pré-visualização é a tela de teste dentro da ferramenta. O link que o cliente abre é outra coisa. A documentação do Lovable avisa que as mudanças não vão pro ar sozinhas: cada publicação é uma foto do projeto, e quem continua mexendo precisa publicar de novo, no botão Publish changes. Confira no link de verdade, numa janela anônima (a que não guarda o seu login), e no celular. Se for não: publique. Se mesmo publicado não roda, é outro tipo de erro, que mora no painel e não no código.

5. O dado ficou certo no banco? Toda entrega que mexe em cadastro, pedido ou cálculo grava alguma coisa. A tela pode mostrar certo com o dado errado por baixo, e eu já caí nisso com um acento. Abra a tabela no painel do banco e leia a linha que a sua conferência criou. Se for não: o conserto é na entrada, não na tela. Diga isso no pedido.

6. Dá pra voltar? Existe um ponto de retorno marcado antes desta mudança, e você sabe usar? Se a resposta for "acho que a ferramenta guarda", é não. Quatro comandos marcam e voltam. Se for não: marque agora, antes de publicar, e só depois siga.

A ordem em que se pergunta

Não é a ordem da lista. A 6 vem primeiro: ponto de retorno marcado antes de pedir. Depois, ainda na pré-visualização, 1, 2 e 3. A 5 em toda mudança que grava dado. A 4 por último, depois de publicar, que é quando você descobre se o que funcionou na ferramenta funciona no mundo.

Um "não" em qualquer uma é não. Não existe "pronto, menos o teste".

O cartão, pra hoje

Copie, cole onde você anota as coisas do app, ou no arquivo de regras da sua ferramenta:

ANTES DE ACEITAR QUALQUER ENTREGA
[ ] 6. Marquei o ponto de retorno ANTES de pedir
[ ] 1. Fiz X e vi Y (a frase de conferência)
[ ] 2. O diff só mexeu onde eu pedi
[ ] 3. Saída do teste colada, verde
[ ] 5. Li a linha no banco, e está certa
[ ] 4. Publiquei e conferi no link real, em janela anônima e no celular
Um "não" = não está pronto.

Na próxima entrega da IA, passe ela pelo cartão antes de pedir a próxima. Anote quantos "não" apareceram. Esse número é quanto do seu "pronto" era palavra dela.

Era uma parede de várias

O cartão julga uma entrega. Ele não diz se o app inteiro aguenta cliente: se o código e o banco são seus, se o login protege ou só aparece, se alguém de fora usa sem você do lado. Essa é a pergunta de cima, e ela tem dez itens, não seis. Contei como ela funciona em por que oito horas não bastam. Uma entrega pronta é o tijolo. A casa tem ordem própria.

Fontes

• Ken Schwaber e Jeff Sutherland, "The Scrum Guide", versão de novembro de 2020 (Definição de Pronto: "a formal description of the state of the Increment when it meets the quality measures required for the product"; o que não passa não é lançado nem apresentado). É um guia de times de software, não mede ferramentas de IA: https://scrumguides.org/scrum-guide.html
• Lovable Docs, "Publish" (cada publicação é uma foto do projeto; mudanças posteriores não vão pro ar sozinhas; publicar de novo em "Publish changes"): https://docs.lovable.dev/features/publish