Velocidade sem Controle: o Preço Técnico da Corrida dos Agentes de Código

Resumo

Este artigo responde a uma pergunta: por que medir apenas a velocidade de entrega leva times que usam agentes de código a acumular dívida técnica, e o que os times que evitam isso fazem de diferente?

O raciocínio parte de um modelo simples: entregar software confiável é uma cadeia de etapas, e o ritmo de uma cadeia é dado pela etapa mais lenta, o gargalo. Agentes de código barateiam a primeira etapa (escrever). A hipótese que decorre disso é que o gargalo se desloca para as etapas humanas: especificar, verificar, entender. O artigo testa essa hipótese com quatro perguntas, respondidas em sequência com a evidência disponível:

1. A geração ficou mesmo mais rápida? A evidência é mista e está mudando. O ensaio controlado do METR (2025) mediu lentidão de 19% em desenvolvedores experientes que se percebiam 20% mais rápidos. Em fevereiro de 2026, o próprio METR estimou ganho (18% e 4%, com intervalos que incluem zero) e declarou os dados comprometidos por viés de seleção. O que se mantém é o alerta: a sensação de velocidade não é medida.
2. A verificação acompanha? Três estudos independentes (METR, 2025; Perry et al., 2023; Lee et al., 2025) mostram a confiança na IA se descolando da qualidade real ou da atenção crítica.
3. Onde a dívida aparece? Em sinais indiretos: a DORA associa mais adoção de IA a mais vazão e mais instabilidade; a GitClear, fornecedora de analytics, aponta queda de refatoração e reuso.
4. Como os times maduros controlam isso? Mudando o processo, não só a velocidade: o Spotify (em relato próprio) ampliou monitoramento, rollback e sinais de qualidade de longo prazo; o DoorDash combina aprovação humana antes da mudança com validação automatizada depois.

A tese "o julgamento humano virou o gargalo" é coerente com os dados, mas não está demonstrada causalmente; as limitações estão na seção 10.

1. O Modelo: Entregar Software É uma Cadeia de Etapas

Durante a última década, o argumento para automatizar a escrita de código era simples: escrever código é caro e lento. Agentes de código (ferramentas que planejam, editam vários arquivos, executam testes e abrem PRs com pouca intervenção) atacam esse custo diretamente.

Mas código em produção não é o objetivo final. O objetivo é software que faz o que deveria, continua compreensível e pode ser alterado com segurança. Entre "código escrito" e "software confiável" há uma cadeia de atividades:

especificar a intenção → ESCREVER → revisar → testar → operar → diagnosticar
        (humano)        (agente)   (humano)  (misto)  (humano)   (humano)

Em qualquer cadeia, a vazão total é limitada pela etapa mais lenta. Acelerar uma etapa que não é o gargalo não aumenta a entrega; só acumula trabalho na frente da etapa seguinte.

Daí a hipótese central: se escrever fica muito mais barato e as demais etapas não, o sistema passa a ser limitado pelas etapas humanas, sobretudo a verificação. E se a métrica de sucesso continua sendo volume (PRs, commits, tickets fechados), o time otimiza a etapa que deixou de ser escassa e consome a que ficou escassa: a atenção crítica humana.

Para aceitar essa hipótese, é preciso responder quatro perguntas. As seções 2 a 5 fazem isso, uma de cada vez.

2. Pergunta 1: A Geração Ficou Mesmo Mais Rápida?

2.1 O ensaio controlado de 2025

O estudo mais citado é o ensaio controlado randomizado do METR (Becker, Rush, Barnes e Rein, 2025). Nele, 16 desenvolvedores experientes de projetos open source maduros completaram 246 tarefas, cada uma sorteada para permitir ou proibir o uso de IA (principalmente Cursor Pro com Claude 3.5/3.7 Sonnet).

Os autores são cuidadosos sobre o que não afirmam (METR, 2025): não dizem que a IA não acelera a maioria dos desenvolvedores, nem que o resultado vale para outros contextos ou para modelos futuros. Entre os fatores prováveis, apontam padrões altos de qualidade (documentação, testes, formatação) e requisitos implícitos dos projetos.

2.2 A atualização de 2026

Em fevereiro de 2026, o METR publicou os resultados de um segundo experimento, conduzido entre agosto de 2025 e o início de 2026 (METR, 2026):

• Entre os desenvolvedores do estudo original que participaram de novo, a estimativa passou a ser de redução de 18% no tempo (intervalo de −38% a +9%); entre novos recrutados, redução de 4% (intervalo de −15% a +9%). Os dois intervalos incluem zero.
• Os autores consideram os dados comprometidos por viés de seleção: muitos desenvolvedores recusaram participar por não querer trabalhar sem IA; entre 30% e 50% relataram evitar submeter tarefas que não queriam fazer sem IA; e o pagamento caiu de US$ 150 para US$ 50 por hora. Medir o tempo de quem usa vários agentes em paralelo também se mostrou pouco confiável.
• A conclusão deles é que "provavelmente" os desenvolvedores estão mais acelerados no início de 2026 do que em 2025, mas que os dados são evidência "muito fraca" do tamanho desse ganho. Por isso mudaram o desenho do experimento.

2.3 O que fica da resposta

A atualização muda a leitura do número, não a lição. Não é honesto usar os "19% mais lentos" como veredito sobre as ferramentas de 2026. O dado que sobrevive às duas rodadas é a distância entre percepção e medida: a sensação de velocidade não serve como métrica de gestão.

Consequência para o argumento: se nem a própria percepção de velocidade é confiável, confiar na percepção de qualidade é ainda mais arriscado. Isso leva à segunda pergunta.

3. Pergunta 2: A Verificação Acompanha a Geração?

A hipótese da seção 1 só se confirma se a verificação, além de mais demandada, tender a ceder. Dois estudos apontam nessa direção:

• Mais confiança, menos segurança. Em um estudo com usuários, Perry, Srivastava, Kumar e Boneh (ACM CCS 2023) observaram que participantes com assistente de IA escreveram código significativamente menos seguro e, ainda assim, tinham mais probabilidade de acreditar que o código era seguro. Quem confiava menos na IA e trabalhava mais a linguagem e o formato dos prompts produziu menos vulnerabilidades. O estudo usou um modelo antigo (codex-davinci-002) e tarefas de segurança específicas.
• Mais confiança na IA, menos pensamento crítico. Em uma pesquisa com 319 trabalhadores do conhecimento e 936 exemplos de tarefas, Lee et al. (CHI 2025, Microsoft Research e Carnegie Mellon) reportam que maior confiança na IA se associa a menos pensamento crítico, enquanto maior autoconfiança se associa a mais. A IA desloca o esforço de executar para verificar, integrar e supervisionar. Os dados são autorrelatados e correlacionais.

Somados ao METR, são três estudos independentes em que a confiança se descola da realidade. A conclusão para o argumento: se a etapa escassa passou a ser a verificação, o comportamento humano tende a relaxá-la exatamente quando ela mais importa.

Próxima pergunta: se a verificação cede, os problemas não verificados vão para algum lugar. Onde eles aparecem, e por que os painéis de velocidade não os mostram?

4. Pergunta 3: Onde a Dívida Aparece?

4.1 Por que a métrica de velocidade não a mostra

Métricas de volume (PRs mergeados, commits, tickets) medem a saída da etapa que ficou barata. Se a saída dobra, a métrica dobra, esteja o código correto ou não. Ou seja: a métrica mede exatamente a etapa que deixou de ser o gargalo. Por isso a dívida precisa ser procurada em sinais indiretos.

4.2 Sinal 1: estabilidade de entrega

A DORA, em síntese do relatório de 2025 sobre desenvolvimento assistido por IA, afirma que maior adoção de IA se associa ao aumento tanto da vazão quanto da instabilidade de entrega. O relatório descreve três tensões:

1. um "imposto de verificação": o tempo poupado na escrita vai para a auditoria;
2. um paradoxo de expertise: resolver rápido pula o aprendizado difícil;
3. uma lacuna entre protótipo e produção: a "reta final" de casos-limite e integração consome o ganho inicial.

O "imposto de verificação" é a hipótese da seção 1 com outro nome. A DORA recomenda medir impacto de forma holística, e não por volume; levar o feedback da IA ao autor durante a escrita, e não ao revisor depois; e manter lotes pequenos. É pesquisa por questionário, portanto associativa.

4.3 Sinal 2: manutenibilidade do código

A GitClear (2026), fornecedora de analytics de desenvolvimento, analisou 623 milhões de alterações de código de 2023 a 2026:

Cautelas: o estudo vem de uma empresa que vende métricas de código; as métricas são proxies de manutenibilidade, não medidas de defeitos; e não isolam o efeito da IA de outras mudanças no período.

4.4 Sinal 3: falhas silenciosas

Um texto recente de Reya Vir (Towards Data Science, 2026) ilustra o mecanismo: aplicações geradas por prompt em que a interface parece funcional, mas a lógica falha em silêncio. Por exemplo, a tela mostra "Discount applied!" sem que o novo total seja persistido. A ferramenta proposta, FlowCheck, detectou 30 de 30 bugs injetados em quatro aplicações-modelo, contra 26 de 30 do melhor LLM usado como comparação.

A evidência é limitada: bugs injetados pelos próprios autores, aplicações-modelo e foco em quem não programa. O valor do texto não é estimar prevalência, e sim mostrar onde procurar: fluxos de dados que atravessam handlers e ramos condicionais.

4.5 Síntese: onde a dívida se esconde

O tema comum é a assimetria de custo: gerar é barato, verificar é caro, e a verificação é a primeira coisa que cede sob pressão de prazo.

5. Como Isso Aparece numa Organização: os Relatos da Semana

As seções anteriores descrevem mecanismos. Relatos recentes mostram como eles se manifestam no dia a dia, com graus de confiança muito diferentes:

Dois cuidados de leitura: o relato de voxium fala em "big company", e não em "big tech"; e não há como saber se o padrão descrito é típico ou uma exceção que viralizou por ser chocante.

Descontada a incerteza, o relato contém um padrão organizacional que é a hipótese da seção 1 levada ao extremo. A gestão conclui, a partir de "escrever código ficou barato", que "então deveríamos estar mais rápidos", e o vazio entre as duas afirmações é preenchido com pressão sobre as pessoas. Se o relato for verdadeiro, as pessoas não estão programando nem revisando: estão aprovando. A frase "nobody is reading anything" descreve exatamente uma verificação que deixou de existir.

O Spotify e o DoorDash, por outro lado, mostram organizações que perceberam o deslocamento do gargalo e reagiram. É a quarta pergunta.

6. Pergunta 4: Como Controlar o Novo Gargalo?

Se o gargalo é a verificação, a resposta não pode ser "gerar mais rápido". Precisa atuar em três frentes: proteger a verificação onde há julgamento, automatizá-la onde há regra, e limitar o dano do que escapar.

6.1 O princípio de segurança: agência limitada

O OWASP LLM06:2025 (Excessive Agency) trata de sistemas baseados em LLM que executam ações danosas a partir de saídas inesperadas, ambíguas ou manipuladas. Aponta três causas: funcionalidade excessiva, permissões excessivas e autonomia excessiva (ações de alto impacto sem verificação independente). As mitigações incluem menor privilégio, aprovação humana para ações de alto impacto e autorização aplicada nos sistemas de destino (não pelo próprio LLM), além de logs, monitoramento e limites de taxa. Não é um estudo empírico, mas é a referência de consenso para desenhar controles.

6.2 Spotify: observabilidade e reversibilidade

Segundo o texto de Tyson Singer, o Spotify identificou quatro problemas:

1. falhas mascaradas e falta de capacidade no processamento de conteúdo;
2. uma atualização automatizada de dependências que "passed our checks, but still failed in production";
3. escassez de capacidade de computação, que tornou graves falhas antes triviais;
4. regressões graduais em apps móveis.

A frase-chave do texto é que "individual releases can look healthy while smaller regressions accumulate over time". Ou seja, o sinal de qualidade por release não capturava a deterioração gradual, o mesmo problema da seção 4.1 em outra escala.

As respostas foram monitoramento de ponta a ponta, salvaguardas mais fortes, maior capacidade de rollback, agendamento de mudanças automatizadas no horário de trabalho das equipes donas do código, o dobro de capacidade reservada na borda e sinais de qualidade mais amplos, com tendências de longo prazo. O texto afirma ainda que a taxa de retrabalho não subiu e que o trabalho de qualidade e otimização passou de 27% para 31% das mudanças mergeadas.

É uma leitura interna e favorável. A lição aproveitável é o desenho: o gargalo foi tratado com observabilidade e reversibilidade, e não com mais velocidade.

6.3 DoorDash: humano no julgamento, máquina na regra

É o caso mais informativo sobre arquitetura de controle. Segundo o InfoQ, o DoorDash tem mais de 60.000 feature flags em 623 repositórios, com mais de 1.000 obsoletas (sem alteração há 90 dias e ainda referenciadas no código). Um orquestrador consulta tickets e metadados, e agentes de limpeza trabalham em worktrees Git isoladas. Há dois pontos de controle:

1. Antes: engenheiros revisam e aprovam, confirmando o valor-alvo da flag antes de qualquer mudança de código.
2. Depois: os agentes executam build, testes, cobertura de patch (JaCoCo) e análise estática (Detekt) antes de abrir o PR.

Resultados nas 50 flags avaliadas:

Ressalvas: são 50 casos, escolhidos e relatados pela própria empresa, com horizonte curto para afirmar "zero regressões".

O que torna o caso relevante é o tipo de tarefa: mecânica, bem delimitada, com resultado verificável por ferramentas, e com a decisão semântica (qual valor manter) reservada ao humano. O humano decide onde há julgamento; a máquina executa onde há regra. É o oposto do relato de voxium, em que o humano só aprova.

6.4 O padrão generalizado

Um esboço ilustrativo desse padrão (não é a configuração real de nenhuma empresa):

# Ilustrativo: portões de controle para mudanças geradas por agente
pipeline:
  - etapa: intencao
    responsavel: humano          # decide O QUE deve mudar e por quê
    saida: especificacao_revisada
  - etapa: execucao
    responsavel: agente          # isolado (branch/worktree), permissões mínimas
  - etapa: validacao_automatica
    exige: [build, testes, cobertura_do_patch, analise_estatica, testes_de_dados]
  - etapa: revisao
    responsavel: humano          # PR pequeno, com descrição do "porquê"
    limite: 400 linhas alteradas # valor arbitrário, calibre para o seu time
  - etapa: liberacao
    exige: [rollout_gradual, monitoramento, rollback_testado]

Compare com a cadeia da seção 1: o humano continua nas etapas de julgamento (intenção e revisão), a validação por regra é automatizada, e a liberação tem proteção para o que escapar.

7. Avaliando a Tese com as Quatro Respostas

A formulação "o gargalo saiu do código e foi para o julgamento humano" é coerente com o "imposto de verificação" da DORA, com o deslocamento de esforço descrito por Lee et al. e com a arquitetura do DoorDash.

Ela não está demonstrada de forma causal em ambiente empresarial:

• os estudos controlados são pequenos, antigos ou, como admite o próprio METR, comprometidos por seleção;
• os grandes conjuntos de dados são observacionais ou de fornecedores;
• o principal exemplo de "ninguém lê nada" é anônimo.

O Spotify é um contraexemplo parcial: sugere que, com processos ajustados, o aumento de volume não gerou incidentes atribuíveis a código de IA. Isso reforça a leitura de que o processo faz a diferença, mas vem da própria empresa.

8. Aplicando a Dados e Analytics

O mesmo raciocínio vale para times de dados, com três agravantes:

1. Corretude semântica é difícil de testar. Um pipeline dbt ou uma transformação Spark pode terminar com sucesso e produzir números plausíveis e errados: uma junção que duplica linhas, um filtro de data que descarta a última partição, uma métrica redefinida. Sem testes de dados (unicidade, integridade referencial, reconciliação com a fonte), o "verde" do CI vale pouco.
2. O erro se propaga em silêncio. Uma métrica errada alimenta decisões antes que alguém perceba; não há "erro 500". É a falha silenciosa da seção 4.4, em versão de dados.
3. A dívida é de definição, não só de código. Quando um agente reescreve uma métrica, a mudança de significado pode ser mais grave que qualquer bug de sintaxe. Isso conecta com o ponto de Anderson sobre saídas que ninguém possui: definições de métricas sem dono e sem data de revisão.

9. Recomendações Práticas: o Time Está "Apertando Enter" ou Construindo?

Os itens combinam as fontes das seções anteriores com raciocínio próprio; são hipóteses de trabalho, não resultado de experimento. Estão agrupados pelas quatro perguntas do artigo.

Medir o que importa (perguntas 1 e 3)

1. Meça mais do que vazão. Junto com PRs mergeados, acompanhe taxa de falha de mudanças, tempo de recuperação, retrabalho, churn de duas semanas e incidentes. A DORA recomenda evitar métricas puramente de volume.
2. Faça um piloto medido. Antes de ampliar, compare com e sem agente em tarefas reais do seu time, medindo qualidade e tempo total (incluindo revisão e correção). As duas rodadas do METR mostram tanto o risco de confiar na sensação quanto a dificuldade de medir direito: defina o desenho antes de olhar os números.

Proteger a verificação (pergunta 2)

1. Aplique o teste de explicação. Para qualquer mudança gerada por agente: alguém do time consegue explicar por que ela está correta sem reler o prompt? Se não, não é aprovação, é carimbo.
2. Limite o tamanho do lote. PRs pequenos tornam a revisão viável. Defina um teto e trate excedê-lo como exceção que exige justificativa.
3. Pratique a desconfiança calibrada. No estudo de Perry et al., quem confiava menos na IA e reformulava os pedidos produziu código mais seguro. Incentive revisão adversarial: "onde isso quebra?".
4. Proteja a carga humana. Se as pessoas trabalham mais horas para "acompanhar" o agente, o processo está errado. Reduza o volume aceito à capacidade real de revisão, em vez de ampliar a jornada.

Controlar o processo (pergunta 4)

1. Separe intenção de execução. O humano revisa a especificação e o resultado esperado antes da geração, como no DoorDash.
2. Automatize o que é regra e reserve o humano para o que é julgamento. Build, testes, cobertura do patch, análise estática e testes de dados são portões automáticos; a revisão humana foca em semântica, arquitetura e riscos.
3. Aplique menor privilégio aos agentes. Segundo o OWASP LLM06, limite funcionalidades e permissões e exija aprovação humana para ações de alto impacto (escrita em produção, mudanças de permissão, exclusões).
4. Garanta reversibilidade. Rollout gradual, rollback testado e mudanças automatizadas agendadas quando os donos do sistema estão presentes, como fez o Spotify.
5. Instrumente para detectar falhas silenciosas. Monitoramento de ponta a ponta e alertas sobre resultados (contagens, distribuições, reconciliações), não só sobre execução.
6. Registre propriedade e prazo de revisão. Como propõe Anderson: inventário de artefatos gerados por IA com dono e data de revisão, incluindo definições de métricas e prompts/contexto versionados.

Sinais de alerta rápidos: ninguém abre os diffs; o tempo de revisão cai enquanto o volume sobe; incidentes "sem causa clara" crescem; o time não consegue dizer quem é dono de um artefato gerado; a gestão pergunta "por que estamos lentos" se o código "já é barato".

10. Limitações e o que Ainda Não se Sabe

• Não há estudo controlado recente, grande e em ambiente empresarial que separe o efeito de agentes de código sobre produtividade e qualidade a longo prazo. O METR é o mais rigoroso disponível, e seus próprios autores classificam a rodada de 2026 como evidência fraca.
• Muitos números vêm de fornecedores ou de relatos próprios (GitClear, Spotify, DoorDash). Não foram auditados externamente.
• O relato mais vívido é anedótico. O texto de voxium é anônimo e de fonte única.
• Proxies não são defeitos. Churn, duplicação e refatoração indicam risco de manutenção, mas não provam que o código tem mais bugs.
• Causalidade. As associações da DORA e da GitClear coexistem com outras mudanças (equipes, práticas, ferramentas).
• Horizonte curto. Quem afirma "zero regressões" (DoorDash) observou pouco tempo; dívida técnica costuma se manifestar em meses ou anos.

11. Recapitulando o Raciocínio

1. Entregar software confiável é uma cadeia de etapas; o ritmo da cadeia é dado pelo gargalo.
2. Agentes barateiam a etapa de escrever; a hipótese é que o gargalo se desloca para verificar e entender.
3. Pergunta 1: o ganho de velocidade é incerto e está mudando, mas a percepção de velocidade não é confiável.
4. Pergunta 2: a confiança na IA tende a reduzir a atenção crítica justamente na etapa que ficou escassa.
5. Pergunta 3: métricas de volume medem a etapa que ficou barata; a dívida aparece em instabilidade, perda de manutenibilidade e falhas silenciosas.
6. Pergunta 4: times maduros colocam o humano no julgamento, automatizam a regra e investem em observabilidade e reversibilidade.
7. A tese é coerente com os dados, mas não está demonstrada causalmente.

12. Conclusão

A resposta à pergunta tem menos a ver com a qualidade dos agentes e mais com o que o time decide medir e proteger. Quando o código deixa de ser o recurso escasso, otimizar a velocidade de geração é otimizar o que já sobra. A dívida se acumula onde ninguém está olhando: na semântica que os testes não cobrem, no código que ninguém consegue explicar e na carga de trabalho de quem carimba.

Os times que parecem lidar melhor com isso, pelo que os relatos indicam (com as ressalvas de fonte), fazem três coisas: colocam o humano onde há julgamento (intenção e semântica), automatizam onde há regra (validações) e investem em reversibilidade e observabilidade para o que escapar. A pergunta prática para a segunda-feira não é "quantos PRs a mais entregamos?", e sim "se um agente errar em silêncio hoje, quanto tempo levaremos para descobrir e desfazer?".

Nota Metodológica

Todas as fontes listadas foram lidas na origem (em 27/09/2026), e os números citados foram conferidos contra o texto original de cada uma. Cada fato recebe um nível de confiança conforme o tipo de fonte: estudo revisado por pares, pesquisa institucional, dado de fornecedor, relato da própria empresa ou relato anônimo. Ficaram de fora textos que não sustentariam nenhuma conclusão, como relatos pessoais com estatísticas sem indicação de origem e preprints que não puderam ser lidos na íntegra. Números de fornecedores e de empresas sobre si mesmas estão identificados como tal ao longo do texto.

Referências

1. voxium (citado por Simon Willison). (2026). Quoting voxium. Relato anônimo. Link

2. Singer, T. (Spotify Engineering). (2026). AI Changed How Spotify Builds. What We Learned (and Fixed) About Quality at Higher Velocity. Link

3. Kumili, L. (InfoQ). (2026). DoorDash Uses Multi Agent LLMs to Clean up 60,000 Feature Flags. Link

4. Anderson, D. (2026). Issue #70 – The Debt AI Creates. The Data Ecosystem. Link

5. Becker, J.; Rush, N.; Barnes, E.; Rein, D. (2025). Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity. arXiv:2507.09089 (METR). Link

6. METR. (2025). Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity (post com as ressalvas dos autores). Link

7. METR. (2026). We are Changing our Developer Productivity Experiment Design. Link

8. Perry, N.; Srivastava, M.; Kumar, D.; Boneh, D. (2023). Do Users Write More Insecure Code with AI Assistants? ACM CCS '23 (arXiv:2211.03622). Link

9. Lee, H.-P.; Sarkar, A.; Tankelevitch, L.; Drosos, I.; Rintel, S.; Banks, R.; Wilson, N. (2025). The Impact of Generative AI on Critical Thinking: Self-Reported Reductions in Cognitive Effort and Confidence Effects From a Survey of Knowledge Workers. CHI 2025. Link

10. DORA (Google Cloud). (2026). Balancing AI tensions: Moving from AI adoption to effective SDLC use (síntese do relatório State of AI-assisted Software Development 2025). Link

11. GitClear. (2026). The Maintainability Gap: AI Code Quality in 2026. Estudo de fornecedor. Link

12. Vir, R. (2026). Coding Agents Keep Shipping Silent Failures. Here Is How to Catch Them. Towards Data Science. Link

13. OWASP GenAI Security Project. (2025). LLM06:2025 Excessive Agency. OWASP Top 10 for LLM Applications. Link