O problema não é a IA escrever código errado, é ela decidir sem contexto suficiente
Pedir para um agente de IA "resolver a atividade X" parece simples até você lembrar como a maioria das atividades são escritas: um título, duas linhas de descrição, talvez um critério de aceite genérico. Suficiente para um humano que já conhece o sistema preencher as lacunas com contexto tácito. Insuficiente para uma IA, que vai preencher exatamente as mesmas lacunas, só que adivinhando, e sem avisar que estava adivinhando.
O sintoma não é código malformado. É decisão de design tomada silenciosamente, no meio da implementação, sem ninguém saber que ela foi tomada. Quando isso acontece, o bug não aparece no PR, aparece em produção, ou pior, nem aparece: só fica lá, dormente, até o dia em que o caminho que a IA decidiu ignorar for exatamente o caminho que um cliente real vai percorrer.
A resposta que organizou esse problema, na prática, foi inverter a ordem: gerar um ADR (Architecture Decision Record) e um SDD (Solution Design Document) junto com o agente, antes de qualquer linha de implementação, obrigando a IA a ler o código real do sistema antes de decidir qualquer coisa, e só depois disso liberar a implementação. TDD entrou como uma terceira camada, quase inevitável: se já existe uma decisão registrada (ADR) e um desenho de como implementá-la (SDD), o próximo passo natural é converter isso em testes que falham pela razão certa, antes do código que os faz passar.
