Eu sempre fui muito crítico ao modelo de TDD porque, como humano, muitas vezes você precisa resolver problema rápido e trivial. E ficar testando toda maldita função que você cria é tedioso, muitas vezes desnecessário. Boa parte dos devs pensa assim, eu aposto. E tem um argumento que sempre aparece: “a maior parte dos grandes softwares foi criada e testada na raça, sem teste automatizado”. Verdade. E, do mesmo jeito que acontece com documentação, a maioria dos projetos — open source ou dentro de empresa — chega em produção sem teste, sem doc, sem CI/CD… isso pra dizer o mínimo. É quase uma mágica: dar deploy e rezar pra nada dar pau.

Essa realidade dava pra empurrar até pouco tempo atrás.

Mas se você está pensando em usar IA em qualquer etapa do desenvolvimento — por menor que seja — recomendo fortemente ler isso até o fim e mudar a chave. Senão você vai ser só mais um negacionista da bolha da IA.

Não é mais uma questão de “se” a IA vai ocupar boa parte do setor. Ela vai. E honestamente? Vão sobrar poucas moscas brancas. Porque vai acabar a necessidade do dev que só implementa feature, o pedreiro digital. Se você vive de executar task, prepara o plano B: seus dias estão contados. O que vai sobrar é quem sabe operar modelo de LLM direito. Eles são mais rápidos, muitas vezes mais precisos, e, se usados do jeito certo, têm uma memória melhor que a sua.

Só que domar esses bichos é um experimento interessante.

No começo você deseja que o modelo fosse físico pra poder dar um soco quando ele faz merda: mete um git reset --hard em 5 horas de trabalho, ou um rm -rf no diretório errado porque você esqueceu de commitar. Só que dá pra criar guardrails e reduzir esse tipo de erro burro. Ainda depende muito do seu conhecimento técnico pra direcionar o desenvolvimento, mas na mão de gente experiente o resultado é absurdo. A IA vai gerar documentação e vai fazer todos os malditos testes que você pedir sem reclamar, sem enrolar. E sim: em muito cenário ela vai programar melhor que você.

Então por que essa “mágica” acontece?

Padrões. IA precisa de padrão bem definido. Precisa de regra. Precisa de rotina. É tipo uma criança de 5 anos… só que com QI 300. No dia 0, sua missão é criar um AGENTS.md, CLAUDE.md (ou o nome que a sua stack usa) e definir regras claras de como o modelo deve se comportar. Isso é fundamental. Sem isso você vai continuar brigando com a IA eternamente.

Não vou me aprofundar aqui porque isso sozinho vira outro post. Mas entenda: essa é a forma mais eficiente de dizer o que a IA pode e não pode fazer. Principalmente se você usa IDE tipo Cursor, Claude Code, etc., porque esses arquivos vão junto com o prompt. Ou seja: as diretrizes viram os fundamentos do resultado bom. E, óbvio: se você não entende nada de programação, vai criar um arquivo podre cheio de diretiva inútil. Foi por isso que eu me antecipei e criei uma ferramenta que faz isso por você: Rulebook. É o que eu uso hoje pra gerar meus AGENTS.md e gerenciar tarefas.

Agora vem o ponto principal.

O que antes era chato e às vezes desnecessário, pra IA é obrigatório.

A partir de hoje, todo sistema que você fizer com IA precisa ter testes, com a maior cobertura possível do que foi implementado. Não é “nice to have”. É pré-requisito.

O Rulebook já coloca regras claras pra IA não criar stub, não burlar teste, não manipular teste pra passar (sim, eles fazem isso). E ainda assim alguns modelos dão uma de espertinho e tentam maquiar resultado, então tem que ficar de olho.

E esses testes servem pra duas coisas:

  1. Garantir integridade mínima do sistema
    Você não quer regressão idiota quebrando coisa que funcionava ontem.

  2. Validar regra de negócio de forma sólida
    Pra você ter confiança real no comportamento do sistema e não ficar “achando” que está certo.

Isso evita um problema clássico de IA codando: ela altera uma função que tinha dependências internas e quebra silenciosamente um output de API, um formato de retorno, um comportamento esperado em vários pontos. Quem já tentou usar IA pra codar sabe: muitas vezes o modelo “corrige” erro que ele mesmo causou, mexendo em algo que estava certo. Se você não tem teste, você não sabe onde quebrou. Só vai descobrir lá na frente — quando alguém usar — ou quando a própria IA tentar usar e der ruim.

“Ah, mas fica burocrático.”

Fica. E muda um pouco o “realtime mágico” que a galera espera, porque toda hora vai ter teste rodando. Só que você ganha estabilidade e perde menos tempo corrigindo bomba futura. Você troca adrenalina por previsibilidade. E de brinde você ganha aquele código “padrão FIFA” que os puristas de TDD amam.

Mas calma: também não é bala de prata.

Você ainda precisa entender minimamente o que está fazendo e parar de mandar prompt genérico tipo “faz um e-commerce pra mim”. Sério: não faça essa porra. É o jeito mais estúpido de usar IA. Você precisa definir o como, o stack, as escolhas e o que é “certo” pra cada feature.

Faz o básico: pergunta pra IA qual linguagem faz sentido pro seu caso, qual framework, quais opções de banco, quais ferramentas de teste existem naquele ecossistema. Aí seu prompt começa a ficar decente, tipo:

“Planeje um sistema de e-commerce usando TypeScript, backend em NestJS + Prisma, PostgreSQL, frontend com React + TailwindCSS, pagamentos via fila em RabbitMQ. Preciso de estoque, atendimento, pedidos, etc.”

Percebe? Você ainda define o caminho: tecnologias, comportamento esperado, campos, validações, regras de negócio, edge cases. Só que o código em si você não vai mais escrever do jeito antigo.

Se você seguir nessa linha, em pouco tempo você vai estar criando sistemas bem estruturados, testados, documentados e prontos pra produção.

Sem isso, você é só mais um aventureiro tentando criar SaaS no modo vibe coder crazy train.