# Nunca mais rápido que o entendimento ## Contexto Gerar software está ficando barato. Código, testes, documentação, migrações, refatorações e implementações exploratórias podem ser produzidos em volumes antes impraticáveis. Isso não elimina a escassez. Muda a escassez de lugar. Os recursos cada vez mais limitados passam a ser: - atenção; - entendimento; - julgamento de produto; - capacidade de revisão; - feedback de produção; - coordenação; - confiança; - a capacidade de distinguir evidência de uma resposta apenas plausível. Por isso, não organizamos a engenharia para maximizar a produção de código. Organizamos a engenharia para maximizar aprendizado útil e mudança segura. --- ## Nossa posição ### 1. Valor acima de volume 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. --- ### 2. Fluxo acima de utilização 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. --- ### 3. Mudanças pequenas acima de geração barata 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. --- ### 4. Evidência acima de confiança 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. --- ### 5. Feedback rápido acima de longas execuções autônomas Um agente trabalhando por trinta minutos sem feedback pode avançar depressa na direção errada. Preferimos agentes operando dentro de ciclos curtos de feedback: ```text intenção -> premissa -> mudança pequena -> teste -> feedback -> refatoração -> integração ``` Autonomia é útil quando o feedback continua frequente. --- ### 6. Entendimento acima de volume gerado 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: ```text 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. --- ### 7. Propriedade coletiva acima de conhecimento restrito ao agente 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. --- ### 8. Design simples acima de abstração especulativa 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. --- ### 9. Integração contínua acima de conclusão na branch 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. --- ### 10. Premissas explícitas acima de premissas escondidas na implementação Premissas importantes devem estar visíveis antes de virarem arquitetura. Exemplos: - uma API externa é idempotente; - uma tabela tolera uma migração que gere lock; - consistência eventual é aceitável; - um evento é entregue pelo menos uma vez; - um fluxo de cliente tolera determinado atraso. Sempre que for prático, uma premissa importante deve acabar se tornando um ou mais destes elementos: - um teste; - um contrato; - uma invariante; - um monitor; - um registro de decisão; - o resultado de um experimento. --- ### 11. Responsabilidade humana acima de culpa delegada 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. --- ### 12. Aprendizado acima de conformidade com processo 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. --- ## O modelo operacional que queremos explorar ```text problema -> hipótese -> menor mudança útil -> evidência -> produção -> aprendizado ``` em vez de: ```text ticket -> implementação -> pull request -> aprovação -> pronto ``` "Pronto" deve significar que a incerteza relevante diminuiu, não apenas que o código recebeu merge. --- ## O que este manifesto não é Ele não é: - uma política de uso de IA; - uma lista obrigatória de ferramentas; - uma proibição de mudanças grandes quando elas forem realmente necessárias; - uma exigência de 100% de TDD; - um substituto fixo do Scrum; - um placar de produtividade de desenvolvedores; - uma justificativa para medir engenheiros por volume produzido. É um conjunto de crenças a ser testado contra trabalho real de engenharia. --- ## Uma declaração compacta > Quando gerar código fica barato, a engenharia deve otimizar fluxo, feedback, entendimento e evidência. Lean nos ajuda a controlar o sistema de trabalho. XP nos ajuda a manter mudanças seguras e baratas. A IA aumenta a capacidade de execução, mas a responsabilidade continua humana.