Revisão Obrigatória por Agentes: O Que o Crescimento de 2,2x do VS Code Realmente Exigiu

A manchete circulou rápido: VS Code aumentou commits em 2,2x e fechou 2,9x mais issues em um trimestre. A leitura superficial é tentadora. Mais IA, mais produção, caso encerrado.

Só que a equipe do VS Code publicou como chegou lá. E a história que contam não é sobre velocidade. É sobre as barreiras que tornaram a velocidade possível.

Os Números Que Todo Mundo Citou

Entre janeiro e março, comparando ano contra ano: 2.339 commits viraram 5.104. Issues fechadas saltaram de 2.916 para 8.402. A cadência de releases, mantida mensal por dez anos, passou a semanal. Cada membro da equipe passou a operar três a quatro sessões de agente em paralelo.

Números impressionantes. E completamente insuficientes para entender o que aconteceu.

O Número Que Quase Ninguém Citou

Revisão por Copilot é obrigatória em todo pull request. Não opcional. Não recomendada. Obrigatória. Um gate de governança que precisa ser aprovado antes de qualquer merge.

Peng Lyu, um dos engenheiros da equipe, explicou o raciocínio com uma frase que merece ser lida devagar: “Sem o harness correto, nas primeiras uma ou duas semanas sua produtividade é muito alta. Depois você rapidamente atinge um teto onde fica regredindo.”

A palavra que importa ali é “harness.” Não “modelo.” Não “agente.” Harness. A infraestrutura de contenção que determina o que o agente pode fazer, como o resultado é verificado, e onde o humano entra no ciclo.

Como exploramos em A Diferença do Harness, o mesmo modelo produz resultados radicalmente diferentes dependendo do que está ao redor dele. O VS Code demonstrou isso na escala de uma equipe inteira operando em produção contínua.

Três Camadas, Não Uma

A equipe não confiou apenas na revisão automatizada. O sistema opera em três camadas:

Copilot review obrigatório. Todo PR passa por análise automatizada antes de qualquer humano olhar. 80% das sugestões do Copilot são aceitas pela equipe. 20% são ignoradas. Esse número importa porque estabelece uma linha base de confiança calibrada: a equipe não aceita cegamente, nem ignora por padrão.

Validação por Playwright MCP. Testes automatizados verificam se o que foi gerado funciona como esperado. Não se trata de coverage por compliance. É verificação funcional de que o código produzido pelo agente atende ao comportamento especificado.

Revisão humana de “taste.” O último filtro é explicitamente subjetivo. Engenheiros revisam se o código se encaixa na arquitetura do projeto, se respeita convenções, se é a solução certa para o problema certo. Peng Lyu não deixou ambiguidade sobre quem decide: “São nossos engenheiros que continuam responsáveis pelo resultado.”

Cada camada captura uma classe diferente de erro. A automação pega defeitos estruturais. Os testes pegam defeitos funcionais. O humano pega defeitos de adequação. Remova qualquer camada e os defeitos correspondentes passam direto para produção.

A Lição da Nango: Escala Sem Supervisão Tem Prazo de Validade

A Nango oferece um contraponto instrutivo. A empresa construiu mais de 200 integrações com APIs usando agentes, levando 15 minutos e menos de 20 dólares por integração. Antes: aproximadamente uma semana cada.

Os ganhos de produtividade são reais. Mas a Nango publicou junto os guardrails que tornaram esses ganhos sustentáveis: sandbox de execução isolado, verificação pós-conclusão, contenção de escopo dos agentes. Sem esses controles, 200 integrações geradas em velocidade seriam 200 superfícies de falha não verificadas.

O padrão que emerge é consistente. Equipes que escalam produção com agentes e publicam os resultados sempre publicam junto a infraestrutura de contenção. Equipes que não publicam guardrails tendem a publicar postmortems.

O Que Velocidade Sem Governança Produz

Lyu descreveu o cenário sem harness como um “teto seguido de regressão.” Produtividade sobe. Depois cai. Depois consome mais tempo corrigindo do que teria levado para fazer manualmente.

Isso não surpreende quem acompanha os dados. A Amazon documentou o mesmo padrão internamente: agentes com permissões amplas e supervisão mínima produziram “código de pior qualidade e mais trabalho para todos.” O memorando do SVP Dave Treadwell exigiu aprovação sênior para mudanças em produção assistidas por IA.

A mecânica é previsível. Agentes produzem código plausível em volume. Sem verificação, o código plausível mas defeituoso se acumula. O custo de correção cresce mais rápido que o ganho de produção. O “teto” de Lyu é o ponto onde a dívida técnica gerada por agentes excede a capacidade da equipe de absorvê-la.

O Gate Como Pré-Requisito, Não Obstáculo

A decisão do VS Code de tornar revisão por Copilot obrigatória parece, à primeira vista, um freio na produtividade. Mais um passo no processo. Mais tempo entre commit e merge.

Na prática, o gate é o que permitiu a escala. Sem ele, três a quatro sessões paralelas por engenheiro seriam três a quatro fontes simultâneas de código não verificado. A revisão obrigatória transformou produção em volume em produção verificável em volume.

A distinção importa. Volume sem verificação é acumulação de risco. Volume com verificação é capacidade produtiva real. O gate não reduziu a produção. Tornou-a contável.

O Que Isso Significa Para Equipes Menores

A objeção mais frequente: “Isso funciona para o VS Code porque têm uma equipe grande e recursos da Microsoft.”

A objeção ignora que a Nango fez algo equivalente com uma equipe pequena e orçamento restrito. O princípio não requer escala. Requer disciplina. Revisão automatizada antes de merge. Testes funcionais do output. Humano no loop para decisões que exigem julgamento.

Nenhuma dessas camadas exige infraestrutura proprietária. Copilot review está disponível no GitHub. Playwright é open source. Revisão humana é prática de engenharia de software que existe há décadas.

O que a experiência do VS Code demonstra não é que governança de agentes requer investimento excepcional. É que governança de agentes é pré-requisito para que investimento em IA produza retorno sustentável.

A Pergunta Que Fica

Todo líder de engenharia que viu a manchete de 2,2x deveria se perguntar: minha equipe está implantando os gates ou apenas os agentes?

Porque os dados do VS Code provam que a segunda opção tem prazo de validade. E o prazo é mais curto do que parece.

Fontes

Boggan, Pierce. “How VS Code Builds with AI.” March 2026.
Guldener, Robin. “What We Learned Building 200+ API Integrations with OpenCode.” March 2026.

Victorino Group ajuda equipes de engenharia a construir o harness de governança que torna a velocidade com IA sustentável: contato@victorino.com.br | www.victorino.com.br