Onde falha

Seja honesto sobre os limites, porque é aqui que o vibe coding sem supervisão queima as pessoas:

• Lógica profunda e inédita. Algoritmos sutis, concorrência, qualquer coisa onde estar 95% certo significa estar quebrado. O modelo é confiante mesmo quando está errado.
• Mudanças espalhadas por muitos arquivos. Ele perde o fio da meada em uma base de código grande e quebra coisas silenciosamente que não consegue enxergar.
• Segurança e dinheiro. Autenticação, pagamentos, permissões, qualquer coisa onde um bug com aparência plausível tem consequências reais. Revise isso como se seu emprego dependesse — porque pode ser que dependa.
• Problemas subespecificados. Se você não sabe como é o "correto", a IA não pode ler sua mente. Especificação ruim entra, código ruim sai.

O modo de falha é quase sempre o mesmo: código que parece certo, roda no caminho feliz, e está errado de um jeito que você teria pego se tivesse lido. A correção é o passo de revisão. Não há como pular isso.

Duas perguntas posicionam qualquer tarefa neste mapa — o padrão é comum, e o resultado é barato de checar:

                  EASY TO VERIFY      HARD TO VERIFY
                ┌──────────────────┬──────────────────┐
   COMMON       │   PURE UPSIDE    │   go slower,     │
   PATTERN      │   (scaffold,     │   demand tests   │
                │    boilerplate)  │                  │
                ├──────────────────┼──────────────────┤
   RARE /       │   read it, but   │   DANGER ZONE    │
   NOVEL        │   doable         │   (novel logic,  │
                │                  │    auth, money)  │
                └──────────────────┴──────────────────┘

Repare no inverso da regra acima: esses são os casos que são raros, sutis ou caros de verificar. O padrão é incomum, então o modelo está chutando; ou o bug é invisível no caminho feliz, então uma checagem rápida não vai pegá-lo. Isso não significa evitar a IA aqui — significa desacelerar, encolher os passos, exigir testes e ler cada linha como se ela fosse hostil.