Crenças merecem
pressão.

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:

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:

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.