Concordo plenamente com o que o professor expôs, não apenas sobre evitar confiar 100% no código gerado pela IA, mas também sobre o perigo de não documentar as motivações por trás das mudanças. Essa documentação é essencial para dar contexto a futuras manutenções que serão feitas por outros desenvolvedores.
Gostaria de compartilhar uma experiência que tenho vivenciado com o uso de SDD (Spec-Driven Development). Tenho percebido que, na fase de planejamento e construção da solução, fornecer instruções específicas e objetivas sobre onde quero chegar e como validarei as entregas faz toda a diferença. Quando defino regras claras como guardrails, cobertura de testes, padrões de desenvolvimento, arquitetura e critérios para redução de carga cognitiva, o processo flui muito melhor. Ao estruturar isso sistematicamente e validar o planejamento gerado pelo modelo (abrangendo design e testes), a probabilidade da IA produzir um código defeituoso cai drasticamente.
O grande desafio, no entanto, surge na necessidade de revisar tudo o que foi gerado após uma implementação extensa. É aí que tenho tido mais dificuldade. Como consequência, acabo focando muito mais na validação via testes (unitários e de integração) e na verificação das regras estabelecidas, delegando o code-review do codebase para a própria IA.
Essa dinâmica tem me gerado certa insegurança, especialmente na hora de repassar as entregas ao time e justificar as decisões arquiteturais de alto nível que motivaram a solução, indo além do que está explícito apenas no código.
Para saber mais:
Conte com o apoio da comunidade Alura na sua jornada. Abraços e bons estudos!