Como um vibe coder documenta a falha de segurança antes de corrigir

danilixz recebeu do agente uma lista de falhas de segurança do próprio sistema e não mandou corrigir nenhuma. Mandou escrever um documento sobre elas, um PRD e um BRD das falhas encontradas, e só com esse documento pronto é que veio a auditoria profunda e a correção.

Ele tratou a segurança como trataria uma feature nova, com planejamento escrito antes de encostar no código, e tem de onde tirar isso: "Sou irmão, sou formado desde 2018." O gatilho foi desconfiar da lista que tinha acabado de receber.

"Mas eu acredito que deve ter mais coisa, entendeu?"

A primeira lista de falhas sempre parece completa

Ele começou pelo caminho de sempre. Copiou o material, colou no agente e pediu o mínimo:

"Eu copiei a parada, eu joguei aqui dentro, ó. Analista docum. [...] Analise documento. Vamos seguir passo a passo. Me entrega o brief."

Veio um primeiro apanhado, com um conflito no meio: "o conflito no cloud, ele deu um conflito aqui, tá ligado?". Ele mandou o agente resolver aquele conflito e continuou lendo o resto. Foi lendo que ele parou de acreditar na lista.

Uma lista gerada de primeira é o retrato do que o agente reparou naquela passada. Se você sai corrigindo item por item, fecha exatamente o que ele viu, e o que ele não viu desaparece junto, porque a partir dali existe a sensação de que segurança já foi tratada.

O pedido que troca o conserto por um plano

Em vez de mandar consertar, ele pediu o documento. A fala, com a legenda automática corrompida em um ponto:

"Mais um documento no artifact. para um PRD e um BRD de desenvolvimento para implementações de segurança em cima dessas [falhas]. E no documento tem que conter o que tem que proteger, como proteger e qual melhor forma de proteger tudo. uma análise detalhada de possíveis possibilidades."

A legenda comeu a emenda entre as 2 primeiras frases, e onde está escrito [falhas] a transcrição traz outra palavra, que pelo contexto do trecho é essa.

A parte que faz o trabalho é a última: análise detalhada de possibilidades. Repare no ponto de partida de cada pedido. Uma lista de falhas parte do que o agente reparou, e ela acaba quando ele acaba de reparar. Um documento de o que proteger e como proteger parte da superfície do sistema, e cada área que ele abre cobra uma linha escrita, mesmo quando a linha é "aqui não tem nada exposto". É essa diferença de ponto de partida que faz a análise detalhada alcançar o que a primeira passada deixou fora: ela é organizada pelo que existe para proteger, e o que o agente já tinha achado vira só um dos itens dentro dela.

Mais tarde ele resume assim o que fez:

"eu fiz um PRD, mano. Fiz um PRD, uma documentação das minhas falhas de segurança. E nessas falhas de segurança, eu eu criei um manual, vamos se dizer assim, a modo grosso, porque na faculdade de TI você aprende que precisa, precisa ter uma documentação antes de qualquer coisa, tá ligado?"

Documento se confere linha por linha

Quando o BRD ficou pronto, ele foi lendo na tela, item por item. O achado principal do documento caiu na exposição do deploy, uma área que a primeira passada, concentrada na lógica do código, tinha deixado passar.

E aí veio a parte que só acontece porque existe documento para ler. Entre os pontos dados como protegidos, ele lê em voz alta "Web hook strip com assinatura verificada" (a legenda escreve Stripe assim) e responde ali mesmo: "é porque eu não não não conectei com a stripe ainda". No item seguinte, sobre cobrança, a mesma coisa: "ainda não cadastrei". O documento tinha creditado proteção para uma integração que ainda não existe no sistema.

O agente errar isso é previsível e nem é o interessante. O que interessa é o formato em que o erro chegou. Documento se lê com o dedo em cada item, e cada linha ou bate com o que você construiu, ou não bate, e as duas coisas você percebe na hora. Uma resposta de chat rola para cima enquanto você lê a próxima, e o que fica dela é a impressão geral de que estava tudo certo. Impressão não tem item para conferir.

Isso é o que muda no passo seguinte, quando a auditoria de verdade acontece. Sem documento, você compara o relatório dela com a sua lembrança da conversa, e lembrança quase nunca discorda: o que o relatório afirmar vai soar plausível, porque plausível é o único critério que a memória tem. Com o documento aberto do lado, cada item do relatório cai sobre uma linha escrita antes, e ou confirma aquela linha, ou entra em conflito com ela.

Só depois disso é que ele soltou a auditoria pesada. Montou o pedido como um teatro, com o agente no papel de equipe de invasores contratada, e a instrução operacional dentro do teatro foi essa: "Analise minuciosamente cada falha, invocando cada especialista que você tem no seu time de hackers". A auditoria chegou depois do documento, então o relatório dela tinha contra o que ser conferido.

No vibe coding, o agente conserta exatamente o que você apontou

No vibe coding quem escreve a correção é o agente, e ele fecha o que você apontou e nada além. Sem documento, o ciclo de segurança inteiro vira uma sequência de tapa-buracos, cada um convincente sozinho. Foi o mesmo caminho de segurança do site.

O hábito não nasceu aqui. Ele já fazia a mesma coisa com o projeto inteiro, documentando antes de codar para não reinstruir o agente a cada sessão. O mesmo problema apareceu em como usar antigravity. A diferença é o que o documento cobre: lá é o projeto que ainda vai existir, aqui é a falha que já existe e que você está a um comando de apagar da tela sem ter registrado em lugar nenhum. Isso aparece também em tam sam som. O mesmo problema apareceu em embeddings.

Ele mesmo não vende isso como método certo:

"Eu eu eu fiz uma parada diferente, né? Talvez eu possa ter feito errado, tá ligado?"

O relatório de isolamento entre clientes virou argumento comercial, e essa parte está contada em multi tenant com isolamento verificado.

O que fazer da próxima vez que o agente listar falhas

Quando a lista chegar, segure a mão antes de mandar corrigir. Peça o documento primeiro, com o que precisa ser protegido, como proteger e a análise das possibilidades, e leia procurando 2 coisas: o que aparece lá e não estava na lista original, e o que o documento dá como protegido sem que você tenha construído aquilo. Vale ver como isso terminou em vibe coding para lancar mvp antes do paywall. Depois rode a auditoria e confira o relatório contra o documento, não contra a sua memória da conversa. Foi o mesmo caminho de vibe coding para prompt de corrigir bug com plano antes de executar. Vale ver como isso terminou em como fazer auditoria de segurança com vibe coding.

Dá para assistir à live e ver a ordem inteira acontecendo, do primeiro brief até o BRD sendo lido na tela.