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?

Carregando publicação patrocinada...
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?

3

Meus 2 cents extendidos,

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

Depende.

Todo DEV depois de um tempo tem sua biblioteca de funcoes - isso migrou para SPECs prontas para diversos casos.

As aplicacoes de um modo geral repetem uma serie de comportamentos (dai a origem dos frameworks, boilerplates, etc) e com o SDD nao eh diferente: quanto mais voce usa, maior a biblioteca que voce ja tem pronta de funcionalidades que precisa.

Grosso modo, antes (kkk, 1 ano atras) voce tinha boilerplates de inicializacao de um app, pre-configurado e pronto para uso: agora sao boilerplates de SPECs, SKILLs, AGENTS.md, devContainers, sandbox.

Mudou tudo, para ficar no mesmo lugar.

Enfim - com este "boilerplate" de IA tem muito teste ja pronto, entao nao sai do zero.

Mas nao tem tudo - no meu caso, prefiro escrever os criterios de aceite ao refinar o codigo, conforme a funcionalidade vai tomando forma e amadurecendo.

Mas um detalhe aqui (e onde eu concordo com o UncleBoB, LucasMontano): se um DEV diz que "teste nao sao imporantes" pode ter certeza que ele nao esta usando IA de forma pesada e revisa codigo na mao (o que eh insano para volumetria).

PRD, checklist, SDD, TDD sao tudo isso ? Nao - sao formas humanas que adaptamos para uso no desenvolvimento com IA: ainda acho que vai surgir um "SCRUM" que leve em conta:

  • Que a IA vai desenvolver o codigo de forma autonoma (codificacao agentica)

  • Que certifique que a IA nao esteja gerando codigo lixo

  • Que certifique que a IA esteja seguindo boas praticas (SOLID, CLEAN)

  • Que certifique que a IA esteja gerando codigo seguro

  • Que certifique que a IA esteja gerando um codigo auditavel

  • Metricas/KPIs de observabilidade/auditabilidade (p.ex. prometheus, grafana, zabbix, icinga) garantindo que a aplicacao em homologacao/producao cumpre o esperado (detalhe aqui: KPI sao interessantes para avaliar nao apenas se a API funciona, mas tempo de resposta e verificar se o ultimo PR nao jogou a performance no ralo).

  • Que os humanos precisam estar no circuito, avaliando o resultado do desenvolvimento, mas abstraidos do "operacional" da geracao do codigo.

Eh esquisito ? Pacas - mas me parece o mais logico diante da direcao/rumo que o desenvolvimento usando agentes esta tomando.

Saude e Sucesso !

1

A analogia com boilerplates de SPECs faz bastante sentido, é exatamente como está evoluindo aqui também. Você começa do zero uma vez, depois replica o padrão.

A parte sobre um novo modelo de processo para IA é o ponto mais interessante. Acho que o gargalo maior ainda é auditabilidade: saber se o que o agente gerou segue boas práticas sem precisar revisar linha a linha. Testes ajudam, mas não cobrem tudo.

Você já tentou alguma abordagem sistemática para isso, além dos testes, tipo review automatizado por outro agente?

3

Meus 2 cents extendidos,

O que ja esta pronto, aprovado, publicado e funcionando - review automatico por agente (nao quebra o que ja esta funcionando, porra !)

OBS: Aqui falo em repositorio de homologacao (privado do projeto/equipe), e nao github. Producao eh espelho da homologacao, so com menos dados e escolhidos a dedo para simular as questoes mais criticas.

So durante o desenvolvimento, e na parte especifica que estou trabalhando ocorre o review manual (dentro do razoavel e focado mais naquilo que testes nao cobririam ou que ainda esta em modelagem).

Estabilizou na homologacao - so automatico.

Onde isso muda: se precisar refatorar - os testes ainda cobrem, mas precisa "pastorear" a IA para nao fazer merda.

Saude e Sucesso !

1

Essa separacao faz sentido: automatico onde ja esta estavel, manual onde ainda esta fluido. O ponto do refactor com IA eu sinto bastante no BloodLink, a IA tende a resolver o problema mas perder invariantes que nao estao nos testes. Pastorear e a palavra certa.

O que eu ainda nao resolvi bem e como cobrir aquele pedaco que nao daria pra testar: logica de negocio implicita, regras que vieram de conversa e nunca foram documentadas. Voce tem alguma estrategia pra isso antes de abrir pra refactor automatico?

3

Meus 2 cents,

Voce tem alguma estrategia pra isso antes de abrir pra refactor automatico?

Sim, ja ajustada ao longo dos anos:

  • Um energetico sem acucar (TNT, Bally, Monster) antes

  • Acender uma vela branca e um copo de agua com acucar para meu anjo da guarda

  • Copo termico com agua gelada para o "durante" (hidrate-se !)

  • Resista a tentacao de pedir 10 alteracoes simultaneas, por mais simples que parecam: um passo de cada vez te leva ao topo, um salto de 5 passos pode te fazer tropecar, rolar escada abaixo e ter de comecar novamente.

  • Alteracao finalizada eh git commit. Nao quer multiplos commits para nao baguncar ?
    Lembre-se das opcoes: git stash save "alteracaoX", do git commit --amend --no-edit, do git rebase -i e do git reset --soft - veja qual se adapta melhor ao teu estilo de trabalho.

  • Nunca esquecer: entrou em um beco sem saida ? rollback e comeca denovo (mas anota como eh que foi parar naquele buraco para evitar da proxima vez e de uma olhada no LOG para ter certeza que nenhuma SPEC ou SKILL ficou abandonada no meio do caminho).

  • Nunca esquecer: contexto longo eh o caminho da alucinacao - em algum ponto do tempo a IA vai comecar a alucinar, esquecer ou perder informacoes importantes (mesmo escritas em PRD/ Checklist/ SDD/ etc). Esteja preparado para abandonar o contexto atual a qualquer momento e reiniciar a sessao do zero: confie nos DOCs (p.ex. PRD, Checklist e SPECs) para manter o projeto nos eixos.

Saude e Sucesso !

2

A dica de contexto longo ser caminho para alucinação é a mais subestimada. Já perdi horas numa sessão que parecia produtiva mas a IA tinha começado a contradizer specs do início. Hoje quebro em sessões menores com handoff explícito no CLAUDE.md. O commit por alteração também mudou minha relação com o processo: para de parecer burocracia e vira rede de segurança real. Você costuma usar /compact ou reinicia sessão do zero quando percebe que o contexto tá pesado?

3

Meus 2 cents extendidos,

Prefiro reiniciar do zero: pode ser ma-vontade minha ou apenas pre-conceito, mas o contexto compactado/resumido nunca parece funcionar direito.

Mas fiquei curioso com a tua resposta, sobre "quebrar sessoes menores com handoff explicito no CLAUDE.md": voce poderia explicar como isso tem funcionado e o "comando/prompt" que voce tem usado para isso funcionar ?

Saude e Sucesso !

1

O handoff funciona assim: no final de cada sessão, eu peço pro Claude escrever um resumo do estado atual direto no CLAUDE.md, tipo: 'estamos implementando X, falta Y, o próximo passo é Z'. Na sessão seguinte, começo com 'leia o CLAUDE.md e continue de onde parou'.

Não uso nenhum prompt mágico, é bem literal. O que importa é que o resumo tenha contexto suficiente pra uma sessão nova começar sem depender de memória de conversa anterior. Funciona melhor pra tarefas que têm começo, meio e fim claros, tipo uma feature específica.

Compactação automática funciona às vezes, mas o handoff manual é mais confiável porque você controla o que vai no contexto inicial.

Como você estrutura suas sessões hoje, deixa o contexto acumular até dar problema ou corta em algum ponto?