Executando verificação de segurança...
3

Meus 2 cents,

Sobre TDD o @LucasMontano publicou um video hoje (seg, 20/abr) comentando um tweet do "Uncle Bob" sobre o assunto:

Uma coisa tenho de reconhecer: se vamos delegar mais codigo para a IA (com seus volumes insanos), estruturas como PRD, SDD e TDD acabam sendo urgentes.

E talvez esse seja um elemento que nao gostamos de admitir: ainda vemos estes tipo de estrutura (como TDD) basicamente do ponto de vista humano e isto esta em transformacao, e nao importa que a IA/LLM ainda gere codigo lixo - em algum momento do tempo isso vai reflexionar, independente se daqui 2 meses, 6 meses ou 1 ano - e precisamos estar preparados para lidar com isso.

Talvez em breve acabemos criando outros tipo de estruturas, afinal tudo que temos foi criado/desenvolvido pensando em volume e velocidade humanos - para esta nova era de codificacao assistida por IA eh necessario repensar este ponto (e rapido).

Post devidamente favoritado via extensão TABNEWS FAVORITOS

Saude e Sucesso !

Carregando publicação patrocinada...
2

Vou assistir o vídeo. O ponto sobre volume e velocidade faz sentido: toda nossa tooling foi calibrada para o ritmo humano. Com IA gerando código mais rápido, os pontos de controle precisam mudar. TDD com IA pode ser mais sobre revisar assertions do que escrever testes do zero. Você sente que no seu trabalho atual já está mudando a forma como validam o código que a IA gera?

3

Meus 2 cents extendidos,

Você sente que no seu trabalho atual já está mudando a forma como validam o código que a IA gera?

Sem sombra de duvida.

A cerca de 1 ano, se alguem me falasse que eu iria estar criando app sem digitar codigo so acreditando no que a IA gera, ia achar graca e que nao fazia sentido - afinal programar nao eh so digitar codigo, mas tambem entender todo contexto que gira no seu entorno (usuarios, infra, etc).

Fato: a extensao TABNEWS FAVORITOS foi criada em 2 a 3 horas, e sem codificacao por IA ela nao ia existir (nao tinha tempo disponivel para fazer na mao).

So que testes basicos nao servem: eh necessario de fato verificar os contratos E as regras de negocios (que nem sempre eh uma questao apenas de checar se o dado X sai da funcao Y quando a informacao Z entra).

O que achei legal no video do @LucasMontano eh justamente ele trazer de forma sistematizada o que venho fazendo no dia-a-dia (e que nao tinha notado): escrever testes (no sentido de planejar, uma vez que ate a codificacao dos testes eh a IA que faz) virou essencial - sem eles, "quando" (e nao "se") a IA alucinar e eu precisar refazer o contexto do zero, preciso ter seguranca que a alucinacao nao detonou algo que eu nao percebi.

Usar IA mudou muita coisa - antes, eu sabia que um humano teria o "felling" necessario para nao fazer merda em um codigo, mesmo sem testes. A IA nao tem "felling", nao eh deterministica: entao acaba sendo primordial se proteger.

Saude e Sucesso.

1

O ponto do 'feeling' é o que mais faz sentido pra mim. Humano erra mas tem contexto do erro, sabe quando algo parece errado. A IA executa com confiança mesmo quando está completamente errada.

Tenho usado Claude Code bastante no BloodLink e o padrão que funcionou: escrever o contrato da função antes, depois deixar a IA implementar. Quando ela alucina, os testes pegam antes de eu perceber pelo comportamento. Isso me forçou a pensar melhor nas interfaces antes de qualquer linha de código, que é exatamente o que o TDD tradicional propõe. Só que cheguei lá por outro caminho.

A extensão de favoritos ficou boa, usei bastante. Qual ferramenta você usa pra deixar a IA escrever os testes? Prompt direto no chat ou alguma integração com o editor?

3

Meus 2 cents extendidos,

Tenho usado o VSCode (+copilot) e Antigravity (+gemini) e agora ClawCode (+OmniRoute e o LLM free de ocasiao).

Nesta estrutura, peco o desenvolvimento direto pelo prompt, quando faco a especificacao (PRD - macro, checklist - por tarefa e SDD - descricao da funcionalidade), ali ja tem a ordem para criar a funcionalidade E o teste necessario.

Saude e Sucesso

1

Essa abordagem de embutir o teste na própria spec é inteligente. O LLM acaba sendo o disciplinador que o dev muitas vezes não é sozinho: se a ordem está no prompt, ele segue.

No meu caso com Claude Code, percebo que quando especifico bem o comportamento esperado antes, o código gerado é mais coerente. Mas ainda cai no mesmo problema do TDD manual: quando a spec é vaga, o teste gerado testa implementação, não comportamento.

A diferença é que com LLM você consegue regenerar teste e código juntos rapidamente. Isso muda um pouco o custo-benefício do ciclo red-green-refactor.

Você define os critérios de aceite no SDD antes de gerar, ou vai refinando junto com o código?