# Carta do Experimento ## Nome **Nunca mais rápido que o entendimento: experimento de modelo operacional para times** ## Propósito Testar se um time consegue usar engenharia assistida por IA para reduzir o tempo de entrega sem aumentar a carga de revisão, o retrabalho, o risco em produção ou a perda de entendimento do sistema. O experimento não pretende provar que IA é boa ou ruim. Ele pretende descobrir para onde a restrição migra quando implementar fica mais barato. --- ## Pergunta principal > Quando código deixa de ser o principal recurso escasso, o que passa a limitar nosso sistema de engenharia? Os candidatos mais prováveis incluem: - latência nas decisões de produto; - capacidade de revisão; - feedback da CI; - disponibilidade de ambientes; - entendimento do sistema; - coordenação; - verificação em produção. O experimento deve expor essas restrições, não escondê-las. --- ## Duração Execução recomendada: ```text Preparação / baseline histórico: 1 a 2 semanas Experimento: 6 semanas Síntese final: 1 semana ``` Se já houver dados históricos confiáveis, não atrase o experimento apenas para fabricar um novo baseline. --- ## Escopo Comece com um time e um fluxo de valor relevante de produto ou plataforma. Prefira um escopo em que o time: - seja responsável pela produção; - consiga implantar com frequência; - consiga observar resultados; - faça manutenção normal e trabalho de produto; - já tenha pelo menos uma validação automatizada básica. Evite começar com um protótipo greenfield descartável, no qual os custos normais de coordenação e manutenção não existem. --- ## Hipóteses ### H1: WIP baixo será mais importante quando a IA aumentar a capacidade de execução Se a IA reduzir o tempo de implementação, aumentar a quantidade de tarefas simultâneas criará filas nas etapas seguintes. Sinal esperado: - o WIP permanece estável ou diminui; - o tempo de fila diminui; - a vazão pode aumentar sem congestionamento proporcional na revisão. ### H2: Lotes menores reduzirão a amplificação de revisão causada por IA Se quem implementa limitar o trabalho gerado por IA a mudanças pequenas e revisáveis de forma independente, o esforço de revisão não deve crescer na mesma proporção que a capacidade de geração. Sinal esperado: - mudanças menores; - menor espera por revisão; - menor amplificação de revisão; - nenhum aumento em defeitos que escaparam. ### H3: Ciclos curtos de feedback de XP conterão erros de IA mais cedo Se agentes operarem por meio de testes, CI, contratos e integração frequente, premissas incorretas devem ser descobertas mais perto do momento em que surgiram. Sinal esperado: - mais falhas encontradas antes da revisão ou da produção; - menos retrabalho tardio; - menos tempo entre uma mudança incorreta e o feedback corretivo. ### H4: Premissas explícitas reduzirão implementações confiantes, porém inválidas Se premissas importantes forem registradas e validadas, o time deve identificar mais premissas inválidas antes que se transformem em mudanças caras. Sinal esperado: - premissas convertidas em testes, contratos ou observabilidade; - menos incidentes ou retrabalho causados por premissas ocultas. ### H5: A IA moverá o gargalo em vez de eliminá-lo Sinal esperado: Uma restrição se torna visivelmente dominante em uma ou mais destas etapas: ```text definição do problema revisão CI ambiente validação de produto implantação aprendizado em produção ``` Encontrar a nova restrição conta como resultado útil, mesmo que a vazão não aumente. --- ## Mudanças experimentais Durante o experimento, aplique as seguintes políticas operacionais. 1. Puxe trabalho conforme a capacidade, em vez de empurrar trabalho novo para o sistema. 2. Mantenha limites explícitos de WIP. 3. Prefira desenvolvimento trunk-based. 4. Prefira mudanças que possam ser integradas em horas, não dias. 5. Use feature flags ou técnicas de compatibilidade quando trabalho incompleto precisar coexistir com produção. 6. Mantenha o trabalho de IA dentro de ciclos técnicos de feedback. 7. Quem assina a mudança continua responsável por sua revisabilidade e pelo entendimento. 8. Torne explícitas as premissas importantes quando elas afetarem materialmente a correção ou a arquitetura. 9. Feedback de produção faz parte da mudança, não é um apêndice opcional. 10. O uso de IA em si não é uma métrica de desempenho. --- ## O que continua sem controle Este é um experimento com um sistema de engenharia, não um experimento de laboratório. Não tente controlar artificialmente: - o estilo exato de prompt; - o modelo exato de IA; - o número de interações com IA; - a preferência individual de cada pessoa pelo uso de IA; - a complexidade das tarefas; - incidentes de produção sem relação com o experimento. Registre os principais fatores de confusão em vez de fingir que eles não existem. --- ## Critérios de sucesso Não defina sucesso como "a IA aumentou a velocidade". Considere o experimento promissor se, em comparação com o baseline disponível: - a mediana do tempo de ciclo melhorar ou permanecer estável; - o tempo na fila de revisão não piorar materialmente; - o tamanho dos lotes diminuir; - os defeitos que escaparam e a taxa de falha de mudança não piorarem materialmente; - o retrabalho não piorar materialmente; - o time não relatar perda material de entendimento do sistema; - pelo menos uma restrição antes oculta se tornar mensurável; - o processo não exigir burocracia manual nova e significativa. Um aumento de vazão só tem valor quando não transfere custo para outra parte do sistema. --- ## Critérios de falha Trate o experimento como fracassado ou como algo que precisa ser redesenhado se um ou mais destes problemas persistirem: - a revisão se torna a fila dominante e continua crescendo; - o trabalho gerado excede repetidamente a compreensão do time; - a taxa de falha de mudança ou o retrabalho aumenta materialmente; - o WIP aumenta porque agentes podem "continuar trabalhando"; - engenheiros se tornam revisores e operadores de código que não conseguem explicar; - manter artefatos passa a consumir uma parte significativa do tempo de engenharia; - métricas são manipuladas ou usadas para medir produtividade individual; - o aprendizado de produto não melhora apesar do aumento no volume de implementação. --- ## Condições para interromper o experimento O time pode suspender parte do experimento se: - o risco em produção aumentar materialmente; - um incidente crítico revelar falta de responsabilidade ou entendimento; - uma exigência de segurança ou conformidade conflitar com o modelo operacional; - o time não conseguir reproduzir ou validar de forma confiável mudanças produzidas por agentes; - uma métrica estiver sendo usada para ranquear engenheiros individualmente. Interromper é evidência, não fracasso. --- ## Resultado ao final do experimento O resultado final deve separar: ### Observado O que de fato aconteceu. ### Inferido O que acreditamos explicar a observação. ### Não comprovado O que continua plausível, mas sem sustentação. ### Adotar Práticas que vale a pena manter. ### Modificar Práticas que merecem outra iteração. ### Rejeitar Práticas cujo custo não se justificou. Não atualize o manifesto automaticamente com os resultados do experimento.