Executando verificação de segurança...
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 !

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