Código fica barato.
Engenharia não.

Software funcionando só é útil quando muda um resultado que nos importa.

Código gerado é estoque até produzir evidência de valor.

Preferimos:

uma mudança menor e validada

em vez de:

uma implementação maior e impressionante.

Manter cada engenheiro e cada agente ocupado não é o objetivo.

Um sistema com dez mudanças simultâneas geradas por IA e um gargalo de revisão não é produtivo. Está congestionado.

Preferimos pouco trabalho em andamento, filas curtas e feedback rápido a maximizar a utilização local.

A IA deve aumentar a vazão dentro do limite de WIP, não servir de justificativa para aumentar o WIP.

A IA reduz o custo de produzir mudanças grandes.

Isso torna mudanças pequenas mais valiosas, não menos.

Preferimos mudanças que possam ser:

• entendidas;
• testadas;
• revisadas;
• implantadas;
• revertidas ou corrigidas adiante;
• observadas

de forma independente.

Geração barata não é permissão para lotes grandes.

Plausibilidade é uma das forças da IA e também um de seus riscos.

Uma implementação coerente ainda pode partir de uma premissa falsa.

Por isso, preferimos evidência executável ou observável:

• testes;
• contratos;
• invariantes;
• telemetria de produção;
• reconciliação;
• benchmarks;
• experimentos;
• comportamento de usuários

em vez de explicações confiantes.

O custo de entender uma mudança não pode ser empurrado para quem vem depois.

Quem assina uma mudança continua responsável por torná-la revisável, não importa quem ou o que a gerou.

Rejeitamos o padrão:

geração barata
-> revisão humana cara
-> custo organizacional oculto

Uma restrição útil é:

Nunca mais rápido que o entendimento.

Isso não exige memorizar cada linha. Exige entendimento suficiente para explicar o problema, as decisões importantes, as concessões, os modos de falha e as evidências.

Não queremos regiões do sistema que apenas um engenheiro e seu agente consigam modificar com segurança.

O conhecimento deve continuar transferível por meio de:

• mudanças pequenas;
• testes;
• contratos executáveis;
• design simples;
• operação compartilhada;
• pareamento ou trabalho conjunto quando for útil;
• feedback de produção.

A IA deve reduzir o custo de compartilhar conhecimento, não criar especialização sintética e privada.

A IA é muito boa em produzir abstrações com aparência de completas.

Parecer completa não é o mesmo que ser necessária.

Preferimos o design mais simples que satisfaça a evidência atual e preserve mudanças futuras baratas.

Refatoramos quando a pressão aparece.

Não pagamos complexidade antecipadamente só porque gerar ficou barato.

Integração é um mecanismo de feedback, não uma etapa administrativa.

Preferimos:

• desenvolvimento trunk-based;
• mudanças de vida curta;
• feature flags quando necessário;
• gerar uma vez e promover o mesmo artefato;
• validação reproduzível;
• integração frequente.

Uma branch com dias de trabalho de agentes representa feedback atrasado.

A IA pode gerar, inspecionar, explicar e propor.

Ela não pode assumir responsabilidade organizacional.

O engenheiro que aceita uma mudança continua responsável por:

• entender sua intenção;
• avaliar as concessões importantes;
• validar as evidências relevantes;
• escalar incertezas;
• operar o resultado.

"A IA gerou" não é exceção de qualidade nem explicação de incidente.

Lean e XP não são cerimônias.

Uma prática existe porque melhora um ciclo de feedback ou reduz uma forma conhecida de desperdício.

Quando uma prática deixa de melhorar o sistema, nós a mudamos ou removemos.

Preferimos evidência de melhora no sistema a evidência de mero cumprimento do processo.