A armadilha da velocidade da IA: meça o throughput real dos desenvolvedores antes de acreditar no hype

Desenvolvedores dizem que nunca se sentiram tão rápidos com IA. Dashboards mostram PRs voando. Mesmo assim, sua fila de incidentes e retrabalho subiu, e os releases parecem mais travados, não mais suaves. Esse gap entre velocidade percebida e valor entregue é a armadilha da velocidade da IA. Não é teórico; está aparecendo em equipes reais. Um líder de devs escreveu recentemente que a IA fez as pessoas se sentirem 20% mais rápidas enquanto a entrega medida ficou 19% mais lenta. E com novos recursos de agentes chegando em ferramentas como ChatGPT’s Workspace Agents e IDEs como o Zed experimentando agentes paralelos, a armadilha está se abrindo: mais edições, mais movimento, menos sinal.

Se você é CTO de uma startup ou scale-up nos US com times nearshore no Brazil, precisa de uma forma de medir a realidade, não sensações. Aqui vai um framework concreto e implementável que usamos com clientes para quantificar se copilotos e agentes de IA estão de fato melhorando o seu fluxo, ou apenas lixando as pontas do trabalho pesado enquanto, silenciosamente, taxam o throughput.

Por que percepção e throughput divergem com IA

Duas coisas são verdade ao mesmo tempo:

• A IA reduz drasticamente a fricção cognitiva. Ela rascunha boilerplate, lembra APIs e responde perguntas instantaneamente. Desenvolvedores sentem tudo mais fluido, o que muitas vezes interpretamos, erroneamente, como mais rápido.
• A IA aumenta o volume de edições. Agentes fazem over-editing, reformatam e refatoram além do escopo. O código “se mexe mais”, o que parece velocidade, mas infla o tempo de review e o risco de falha.

Adicione equipes distribuídas e fusos horários, e a ilusão se multiplica: quando seu time nos US acorda, o pod nearshore de São Paulo já empurrou cinco PRs assistidos por agentes. Mais superfície, mesmos ou piores resultados.

Nada disso significa que a IA é negativa no saldo. Significa que você precisa instrumentar a realidade. Fornecedores citam ganhos de 30–55% em microtarefas; seu fluxo em nível de sistema vai viver ou morrer pela latência de review, retrabalho e controle de regressões.

Defina o resultado que você realmente quer

Escolha métricas que reflitam valor entregue e estabilidade, não atividade. Ancoramos em um conjunto DORA modificado, mais duas medidas específicas de IA:

• Lead time para mudanças: Do primeiro commit ao deploy em produção. Acompanhe p50 e p90.
• Tempo de ciclo de PR: Da abertura ao merge, decomposto em autoria, espera por review e retrabalho.
• Taxa de falha de mudanças (CFR): Percentual de mudanças em produção que exigem hotfix/rollback em até 7 dias.
• Tempo médio para restaurar (MTTR): Do início do incidente até a mitigação.
• Razão de churn: (Linhas adicionadas + deletadas) / linhas líquidas alteradas por PR. Churn alto com alteração líquida baixa é um proxy de over-editing.
• Janela de revert/hotfix: Percentual de PRs que causam um hotfix em até 72 horas.

Não otimize por story points ou contagem bruta de commits. São fáceis de manipular e te jogam direto na armadilha.

Instrumente antes de experimentar

Tire duas semanas para criar a linha de base. Não mude o processo ainda. Foque em visibilidade que você consegue computar com ferramentas comuns:

Telemetria de controle de versão e review

• Puxe metadados de PR via APIs do GitHub ou GitLab: timestamps de abertura, primeiro review, aprovações, merge; número de rodadas de review; arquivos tocados; linhas adicionadas/deletadas. No GitHub, as APIs REST e GraphQL te dão tudo que precisa. Comece aqui: GitHub REST API.
• Compute a razão de churn por PR e a contagem de pushes emendados (quantos force-pushes ou novos commits após a revisão inicial). Picos geralmente sinalizam over-editing por agentes ou escopo pouco claro.
• Monitore a latência para o primeiro review. Um alvo saudável para equipes distribuídas US–Brazil com 6–8 horas de overlap é mediana abaixo de 12 horas.

CI e estabilidade em produção

• Registre a taxa de aprovação do CI na primeira tentativa. Se a IA aumenta a superfície de edição, testes flaky e drift de ambiente vão queimar tempo. Sua meta é p50 “red-to-green” abaixo de 60 minutos.
• Tagueie hotfixes e rollbacks; vincule-os aos PRs de origem. Aí estão seu CFR e a janela de revert.

Uso de IA e proveniência (sem logar segredos)

• Exija que desenvolvedores marquem commits assistidos por IA. Abordagem prática: um template de commit no repo inteiro adicionando um rodapé “Co-authored-by: ai” ou um prefixo convencional como “ai:”. Imponha via hook de pre-commit.
• Colete metadados de uso de ferramenta a partir de extensões da IDE ou faça proxy do seu tráfego de LLM. Logue apenas timestamps, IDs de modelo, contagem de tokens e tipos de requisição; nunca persista código bruto ou prompts. Privacidade importa — identificadores ocultos podem deanonomizar pessoas, como pesquisas recentes sobre identificadores de navegador lembraram a todos. Faça hash dos IDs de desenvolvedor no lado do cliente.

Congele o ambiente para testes justos

Reprodutibilidade não é acadêmica. Se seus containers e toolchains flutuam, as métricas ficarão ruidosas. Use imagens Docker pinadas ou até bases reprodutíveis bit a bit para build/test (a comunidade do Arch Linux acabou de publicar uma imagem Docker reprodutível; o princípio é o que importa). Trave versões de CI, linters e test runners durante a janela do experimento.

Over-Editing Index: um proxy simples que funciona

Grandes edições impressionam; edições desnecessárias desperdiçam tempo. Você pode identificá-las com um índice leve que não requer parsing de AST:

• Over-Editing Index (OEI) = razão de churn × arquivos tocados

Interpretação:

• OEI abaixo de 3: Mudança com escopo típico.
• OEI de 3–6: Zona de atenção. Muitas vezes OK para refactors ou migrações mecânicas.
• OEI acima de 6: Provável deriva de escopo (scope creep) ou reformat/refactor dirigido por agente além do pretendido. Espere reviews mais longos e CFR mais alto.

Defina limiares diferentes para refactoring e trabalho de feature. Para tickets que não são refactor, um OEI consistentemente acima de 4 é um sinal vermelho. Combine isso com a contagem de pushes emendados; edições repetidas pós-review somadas a OEI alto quase sempre predizem merge mais lento e maior risco de hotfix.

Desenhe um experimento crível

Você precisa de um teste de switchback, não de fé. Aqui vai um desenho pragmático que funciona com 2–3 pods de 4–8 engenheiros cada (setup comum para times nearshore US–Brazil):

1. Linha de base (2 semanas): Instrumente como acima. Sem mudanças de processo.
2. Switchback Fase A (2 semanas): Pod A usa copilotos e agentes à vontade. Pod B limita o uso a autocomplete apenas (sem agentes de geração de código). Pod C é controle (sem IA além de busca ou documentação).
3. Switchback Fase B (2 semanas): Rode a rotação: Pod A vira controle, Pod B com IA plena, Pod C limitado.
4. Fase C opcional (2 semanas): Introduza guardrails direcionados: limites menores de tamanho de PR, gates de test-first e um checkbox de “origem via IA” no template de PR.

Por que switchbacks? Eles cancelam efeitos baseados em tempo (releases, feriados) e revelam se os ganhos observados são robustos ou apenas ruído. Mire em pelo menos 30 PRs merged por condição por pod para ter medianas estáveis.

Limiares de decisão que mantêm a honestidade

Defina gates explícitos de aprovação/reprovação antes de olhar os dados:

• Tempo de ciclo: o p50 do ciclo de PR deve melhorar em pelo menos 15% sem piorar o p90. Se suas medianas melhoram, mas as caudas engordam, você não ficou mais rápido — ficou mais arriscado.
• Estabilidade: o CFR não pode piorar. Se sua linha de base é 12%, mantenha ou melhore.
• Over-editing: o OEI não deve aumentar para trabalho que não é refactor. Se aumentar, exija melhor escopo ou restrições ao agente.
• Latência de review: mediana de tempo até o primeiro review abaixo de 12 horas para pods US–Brazil. Se a IA aumenta o volume de edições, os reviews precisam ficar mais apertados, não mais soltos.

Se dois ou mais gates falharem para um pod, o uso de IA é negativo no saldo no processo atual. Não debata — corrija o processo ou reduza o escopo.

Guardrails que convertem atividade em throughput

Quando os dados dizem “você está ocupado, não melhor”, aplique estas restrições. Elas são simples, e funcionam.

1) Dimensione corretamente a unidade de trabalho

• Limites de tamanho de PR: Mire menos de 400 linhas líquidas alteradas e menos de 10 arquivos tocados. Bloqueie merges acima dos limites sem uma tag explícita de refactor.
• PRs de uma única intenção: Faça cumprir via template de PR com checklist: feature, bugfix, refactor, infra. Sem mistura.

2) Conter o agente

• Escopo de diretório: Configure o agente para limitar edições a diretórios-alvo, a menos que o PR esteja tagueado como refactor. Revise diffs de arquivos de configuração com cuidado — agentes adoram “ajudar”.
• Explique o diff: Exija uma seção de “justificativa do agente” na descrição do PR quando a IA tiver autoria de mais de 30% das mudanças. Mantenha curto: o quê, por quê, testes.

3) Teste antes de debater

• Testes de golden path: Para código de produto, mantenha uma suíte pequena de 10–20 fluxos centrais que devem passar localmente antes de abrir um PR. A IA é ótima em gerar testes; use-a aqui de propósito.
• Gates de CI em contratos: Mudanças de schema e modificações de APIs públicas devem incluir testes de contrato. Agentes tendem a ignorar casos de borda; contratos forçam clareza.

4) Sincronize entre fusos horários

• Janelas de review: Bloqueie duas janelas diárias de 60–90 minutos focadas em review que alinhem o overlap entre US e Brazil. A forma mais rápida de neutralizar over-editing por IA é acelerar os loops de feedback humano.
• Notas de handover: Exija notas de 5 minutos no fim do dia no PR para continuidade entre países. Corta um dia de latência por rodada.

Crie um “Effective Throughput Score” leve

Você quer um score composto que reflita valor entregue, não movimento. Mantenha transparente:

• ETS = score de tempo de ciclo de PR ajustado à linha de base × score de estabilidade × score de escopo

Onde:

• Score de tempo de ciclo de PR: p50 de base / p50 atual (limitado a 1,4). Se você melhorou de 40 horas para 30, o score é 1,33.
• Score de estabilidade: 1,0 se o CFR ≤ linha de base; 0,9 se o CFR subir até +3 pts; 0,8 se +3–6 pts; 0,6 caso contrário.
• Score de escopo: 1,0 se o OEI mediano ≤ linha de base; 0,9 se +0–1; 0,8 se +1–2; 0,6 caso contrário.

Busque um ETS de 1,15+ para afirmar “IA nos deixou mais rápidos”. Qualquer valor abaixo de 1,0 é ruído ou dano.

Política: clareza acima de teatro de controle

Redações estão publicando políticas claras de IA que dizem o que a equipe pode ou não pode fazer e como deve divulgar. Engenharia não deveria ser diferente. Mantenha sua política específica e sem glamour:

• Permitido: Autocompletar código, geração de testes, rascunhos de documentação, scaffolds de migração.
• Condicionalmente permitido: Código de feature nova atrás de feature flag com cobertura de testes adicional.
• Proibido: Exposição de segredos (keys, credenciais), copiar código licenciado literalmente, modificar caminhos críticos de segurança sem aprovação de um owner.
• Divulgação: PRs devem declarar se a IA escreveu mais de 30% do diff. Inclua “Co-authored-by: ai”.
• Tratamento de dados: Não logue prompts ou código bruto em serviços de terceiros. Retenha somente metadados de uso por 30 dias, anonimizados.

Se você adotar novos recursos de plataforma (por exemplo, Workspace Agents, bots organizacionais customizados), passe-os pela mesma política. Agentes que podem ler issues, criar branches e abrir PRs são ferramentas poderosas. Eles também amplificam incentivos ruins se você não os contiver.

Como é o “bom” em 6 semanas

Em times US–Brazil vimos ganhos críveis quando líderes seguram a linha no escopo e na disciplina de review:

• Redução de 15–25% no p50 do tempo de ciclo de PR, com p90 estável ou levemente melhor.
• CFR estável ou em queda de 2–4 pontos graças a melhor geração de testes e menos commits “ops”.
• OEI estável para trabalho de feature; modestamente maior apenas em refactors e migrações tagueados.
• Latência de review em queda para menos de 8 horas de mediana com duas janelas de review alinhadas.

Do outro lado, quando times se apoiam em agentes sem restrições, o padrão é consistente: a contagem de PRs dispara, o OEI salta, a latência do primeiro review deriva para além de 24 horas, e o CFR sobe 3–6 pontos. Parece ocupado. É ocupado. Não é melhor.

Específicos de nearshore: use o overlap, não a madrugada

• Agende reviews nas horas de overlap. Não dependa de merges à meia-noite. Os dados mostram que a latência, não a velocidade de digitação, é o gargalo do throughput.
• Centralize o experimento. Deixe seu pod no Brazil conduzir o runbook de switchback e a geração de relatórios. Constrói liderança local e evita viés só dos US.
• Use o fora do horário para testes, não merges. Enfileire execuções pesadas de CI à noite. Faça merge de dia, quando owners podem responder rápido a falhas.

Evite armadilhas comuns

• Backlog novo, testes antigos. Se os testes de aceitação são fracos, a IA vai “passar” por gates fracos e elevar o CFR. Reforce 10–20 testes de golden path antes de escalar agentes.
• Mudar variáveis demais. Congele toolchains durante o experimento. Se você adotar um novo modelo (digamos que teste um modelo on-prem forte de 27B parâmetros), pinar o resto.
• Medir com métricas de vaidade. LOC, commits e contagem de PRs são proxies de movimento. Seus investidores ligam para tempo de ciclo e indisponibilidades.
• Teatro de privacidade. Não colete prompts brutos. Use IDs com hash e retenção curta. Identificadores invisíveis voltam a pessoas mais rápido do que você imagina; mantenha a telemetria mínima e útil.

Checklist de implementação que você pode começar esta semana

1. Habilite analytics de PR: Conecte queries das APIs do GitHub/GitLab a um dashboard básico (Datadog, Grafana ou até uma planilha). Compute tempo de ciclo, latência do primeiro review, pushes emendados, OEI.
2. Tagueie a proveniência de IA: Envie um template de commit e um checklist de PR amanhã. Torne a divulgação algo normal.
3. Congele imagens de CI: Pinar imagens base e versões principais de ferramentas pela janela de 6–8 semanas.
4. Planeje o switchback: Escolha os pods, reserve duas janelas diárias de review entre US–Brazil, escreva os gates de aprovação/reprovação.
5. Rode e publique resultados: Compartilhe os deltas semanais internamente. Celebre melhorias e reverta o que falhar.

Você não precisa de uma plataforma de seis dígitos para fazer nada disso. Você precisa de disciplina, duas semanas de linha de base e disposição para olhar além das sensações. A IA pode ser um multiplicador de força. Também pode ser um multiplicador de edições. Seu trabalho é dizer qual dos dois você tem — e corrigir.

Pontos-chave

• Velocidade percebida não é throughput. Instrmente lead time, tempo de ciclo de PR, CFR, MTTR e um Over-Editing Index antes de julgar a IA.
• Rode testes de switchback entre pods com ambientes congelados. Mire pelo menos 30 PRs por condição.
• Defina gates duros: melhoria de 15%+ no tempo de ciclo, sem regressão de CFR, OEI estável ou menor e primeiro review em menos de 12 horas.
• Guardrails importam: PRs pequenos, mudanças de uma única intenção, escopos de diretório para agentes e justificativa obrigatória para diffs escritos por IA.
• Use o overlap US–Brazil para reviews mais rápidos, não merges noturnos. A latência, não a velocidade de digitação, é o gargalo.
• Mantenha a telemetria segura em privacidade: logue metadados de uso, não código; faça hash de IDs; retenção curta.