Duas pesquisadoras da Rochester Institute of Technology vasculharam 25.264 pull requests geradas por agentes de programação no GitHub (Copilot, Codex e Claude Code, entre maio e julho de 2025, em repositórios com pelo menos 100 estrelas). O achado que mais chama atenção não é sobre qual agente ganhou. É sobre quem usa mais: times de 1 a 5 desenvolvedores geraram, em média, 50,2 PRs de agente por trimestre. A mediana geral do estudo, somando times de todos os tamanhos? Só 1 a 2 PRs.
Ou seja: o time pequeno não está "brincando" com IA nas horas vagas. Ele constrói produto com agente de programação em ritmo de produção, enquanto o resto do mercado ainda está testando a água.
O que a pesquisa encontrou nos 25 mil PRs?
O recorte por tamanho de time é só a primeira camada. A segunda é sobre como esse código é revisado antes de virar merge. Segundo a cobertura da Help Net Security sobre o estudo, 78,9% dos PRs de agente passam pela mão de um único revisor humano: alguém lê o que o agente escreveu, corrige o que precisa e faz o merge sozinho. Contando também os casos em que o revisor único aprova sem tocar em nada, esse número sobe pra perto de nove em cada dez PRs.
E não é um efeito de time pequeno e desorganizado. Entre os repositórios mais ativos, com mais de 30 PRs de agente no trimestre, o padrão de revisor único continuou dominante. Mais volume não gerou mais gente olhando o código.
Revisor único é risco? Os números dizem que não
A reação instintiva de quem lidera engenharia é achar que código de agente precisa de mais olhos, não de menos. Os dados batem de frente com esse instinto.
| Métrica | Revisor único | Múltiplos revisores |
|---|---|---|
| Fatia dos PRs de agente | 78,9% | 21,1% |
| Taxa de merge | 81,2% | 80,3% |
| Foco predominante | Features novas | Correção de bugs |
A taxa de merge com um revisor só (81,2%) é praticamente idêntica à de PRs revisados por várias pessoas (80,3%). Adicionar gente na revisão não travou mais código ruim, só encareceu o processo. O dado que separa de verdade os dois grupos é o tipo de trabalho: quem revisa sozinho tende a aprovar feature nova; quem revisa em grupo gasta mais tempo em correção de bug.
Nem tudo são flores: no mesmo estudo, apenas 25 dos projetos analisados geraram PRs de agente no nível de saída considerado profissional pelo benchmark Worklytics, segundo a mesma cobertura. Ter revisor único funcionando não significa que qualquer PR gerado por agente está pronto pra produção sem trabalho humano.
Por que times pequenos usam tanto agente de programação?
Aqui está o ângulo que os números sugerem e que ninguém comentou: se revisor único trabalha melhor aprovando feature nova, e time pequeno gera 25 vezes mais PR de agente que a mediana do mercado, a conclusão é que essas equipes usam o agente pra construir, não só pra remendar código legado.
Construir feature nova não é tarefa de sessão curta. É iteração: o agente escreve, você testa, pede pra ajustar o schema, refaz a rota, adiciona validação, volta pro componente de novo. Cada rodada consome contexto. Em time grande, com processo de revisão em comitê, esse ciclo tende a ser cortado em pedaços pequenos pra caber no orçamento de tokens de cada dev. Em time pequeno, sem esse gargalo de processo, o ciclo roda inteiro, do jeito que o problema pede.
Como estruturar esse fluxo de revisor único sem virar bagunça?
Dá pra copiar o padrão dos times de 1 a 5 devs sem copiar a parte ruim (revisor único distraído aprovando qualquer coisa). Três passos práticos:
- Separe sessão por escopo. Uma sessão de agente por feature, não uma sessão só pra tudo. Isso facilita o revisor único acompanhar o raciocínio do início ao fim, em vez de garimpar contexto misturado.
- Escolha o modelo pelo tamanho do problema. Refactor grande e feature que toca módulos antigos pedem modelo com contexto largo. No Verboo Code, isso é trocar o modelo ativo direto no terminal:
$ verboo
> /model deepseek-v4-flash- Não corte a sessão no meio por causa de cap de token. É exatamente aí que o padrão do revisor único quebra: se o agente para no meio da terceira iteração porque estourou limite, o humano perde o fio e passa a revisar pedaços desconexos, o que é o oposto do que os dados mostram que funciona.
Esse último ponto é o motivo pelo qual token ilimitado importa mais pra time pequeno do que pra enterprise: quem revisa sozinho precisa que a sessão termine o pensamento, não que pare na metade por causa de fatura.
O que isso muda pro dev brasileiro?
O Verboo Code nasceu pra atender exatamente esse perfil: fundador técnico, time de 1 a 5 devs, sem squad de revisão dedicada. Hoje a plataforma roda 7 modelos open source em GPU dedicada (deepseek-v4-flash, mimo-v2.5, glm-4.7-flash, glm-5.2, kimi-k2.7, minimax-m3 e qwen3.6-27b), com tokens ilimitados em todos os planos, do Junior (R$ 75/mês) ao Ultra (R$ 900/mês). Os números da base bateram R$ 30.409,90 de MRR em julho, alta de 43% no mês, com 167 assinantes ativos.
Se o seu time é pequeno e o gargalo real não é revisor, é sessão de agente interrompida no meio da feature, o problema não é o seu processo. É o cap de token do agente que você usa.
Quer rodar sessões longas de feature nova sem parar no meio por causa de limite? Conheça o Verboo Code, agente de programação com tokens ilimitados.
