SINTOMA 01
Adotamos assistentes de código e a produtividade não mudou
Os desenvolvedores dizem que economizam tempo. A percepção é honesta e o indicador não confirma. Não é o time que está errado nem a ferramenta que é ruim — é que o ganho está acontecendo num lugar que não é o gargalo.
atualizado em
Como isso aparece no dia a dia
- os desenvolvedores relatam economia de tempo, mas o lead time do time é o mesmo
- os pull requests ficaram maiores e demoram mais para ser revisados
- o volume de código cresceu sem que a entrega de valor acompanhasse
- a discussão sobre IA no time virou discussão sobre ferramenta, não sobre resultado
- ninguém consegue dizer qual era o número antes de adotar
Por que acontece
Um assistente de código acelera a etapa de escrever. Em quase todo time de porte médio, escrever não é onde o tempo se perde: o tempo se perde decidindo o que escrever, esperando revisão, alinhando com quem tomou uma decisão parecida em outro squad e refazendo o que saiu incoerente com o resto do sistema.
Acelerar a geração sem tocar nas outras etapas empurra mais trabalho para elas. O resultado previsível é uma fila maior na revisão e mais retrabalho — que consomem exatamente o tempo que foi economizado antes.
Há ainda um problema de medição: quase nenhum time registrou o baseline antes de adotar. Sem baseline, a discussão vira percepção contra percepção, e ganha quem fala mais alto na reunião.
Por que a correção óbvia não resolve
Comprar mais licenças, trocar de assistente ou treinar o time em prompts melhores.
Nenhuma dessas ações mexe na etapa que está limitando o fluxo. Trocar de ferramenta muda a qualidade da sugestão, não o tempo que ela leva para chegar a produção. É otimizar o trecho que já era o mais rápido.
O que muda o quadro
Isso não se resolve com mais uma ferramenta. Resolve-se instalando, no repositório, o sistema que a IA precisa ler — o que chamamos de Sistema Operacional de Engenharia.
A primeira coisa é medir onde o tempo realmente está — lead time por etapa, fila de revisão, proporção de código reescrito em 30 dias. Sem esse mapa, qualquer investimento seguinte é aposta.
A segunda é dar ao repositório o contexto que faz a geração sair certa na primeira vez: arquitetura descrita, padrões reutilizáveis, decisões registradas. É a diferença entre gerar rápido e gerar aproveitável.
No framework de transformação, isso é o pilar AI Engineering Workflow. A definição completa da categoria está em Sistema Operacional de Engenharia.
Como saber se melhorou
Nenhuma dessas métricas significa alguma coisa sem o valor de partida. O baseline é levantado antes de qualquer mudança, com a janela e a fórmula registradas junto — o método está em métricas.
- Lead time de desenvolvimento
- do primeiro commit ao deploy, por serviço
- Tempo médio de revisão de pull request
- da abertura ao primeiro parecer humano
- Redução de retrabalho
- proporção de código reescrito dentro de 30 dias
- Aceitação de sugestões geradas
- proporção aceita sem reescrita significativa
Por onde se começa
Para este problema, o degrau adequado costuma ser AI-Ready Engineering Assessment — 2 a 4 semanas, cTO ou head que precisa decidir onde investir antes de comprometer orçamento de transformação.
Antes disso, o diagnóstico gratuito já indica se o gargalo é mesmo este. Os outros quatro sintomas estão em problemas.