De In-the-Loop para On-the-Loop: O Que Empresas Operando Agentes de IA Fazem Diferente

O relatório State of Software Delivery 2026 da CircleCI analisou mais de 28 milhões de workflows. Um número se destaca: os times no percentil 95 dobraram seu throughput no último ano, com crescimento de 97%. A mediana? Queda de 7% na frequência de commits na branch principal. Taxa de sucesso geral: 70,8%, a mais baixa em cinco anos.

Menos de 1 em 20 times alcançou crescimento equilibrado de velocidade e estabilidade. Os outros 19 ou aceleraram sem controle ou desaceleraram tentando manter qualidade.

Esses números não medem adoção de IA. Medem entrega de software. Mas a coincidência temporal é difícil de ignorar: o ano em que ferramentas de codificação com IA se tornaram onipresentes é também o ano em que a maioria dos times entregou menos. A IA comprimiu a geração de código. Não comprimiu a validação, os testes, a integração, o deploy.

Código ficou barato. Entrega continua cara.

A Distinção Que Importa

Martin Fowler cunhou em fevereiro de 2026 uma distinção que organiza o problema. Ele separou “in the loop” de “on the loop.” A terminologia vem do Departamento de Defesa americano, que a usa desde 2012 para classificar níveis de autonomia em sistemas de armas. Fowler a adaptou para desenvolvimento de software.

In-the-loop significa que o humano revisa cada output antes que ele avance. Cada diff, cada pull request, cada sugestão de código passa por olhos humanos. É o modelo padrão de pair programming com IA: o agente gera, o desenvolvedor aprova.

On-the-loop significa que o humano projeta o sistema de supervisão, mas não revisa cada output individual. Em vez de ler diffs, o engenheiro constrói testes, define constraints, monitora métricas agregadas. O agente opera dentro de limites projetados. Quando algo viola um limite, o sistema sinaliza. O humano intervém na exceção, não na regra.

A diferença parece semântica. Na prática, é operacional.

No modelo in-the-loop, a velocidade do sistema é limitada pela velocidade de revisão humana. Um agente que gera mil linhas por hora conectado a um revisor que processa duzentas cria um gargalo previsível. Quanto melhor o agente, pior o gargalo.

No modelo on-the-loop, a velocidade do sistema é limitada pela qualidade do harness de validação. Se os testes cobrem o comportamento esperado, se o CI detecta regressões, se os guardrails capturam violações de padrão, o agente pode operar sem aprovação linha a linha. O investimento muda: em vez de revisar output, você projeta o sistema que o valida.

Readiness É Propriedade da Base de Código

A Factory, empresa de US$ 300 milhões de valuation com 55 pessoas, construiu um modelo de readiness com cinco níveis e mais de 60 critérios. O insight central deles merece repetição: agent readiness não é uma propriedade das pessoas. É uma propriedade da base de código.

Uma base de código com testes abrangentes, CI confiável, documentação de padrões e convenções claras de estilo permite autonomia agêntica. A mesma equipe, com os mesmos agentes, trabalhando numa base de código sem testes e com convenções ambíguas, precisa de revisão humana constante.

Isso inverte a conversa habitual. Empresas perguntam “nosso time está pronto para usar agentes?” A pergunta certa é “nosso código está pronto para ser operado por agentes?”

A diferença não é filosófica. É prática. Preparar o time significa treinamento e adoção de ferramentas. Preparar o código significa testes, CI, documentação, linting, type checking, convenções explícitas. O segundo é mais trabalhoso. Também é mais durável. Um desenvolvedor novo precisa ser treinado. Uma base de código bem preparada treina qualquer agente que a acesse.

Como exploramos em Times de Agentes: Quando o Modelo Operacional Muda de Vez, o experimento de Carlini com 16 instâncias do Claude construindo um compilador C demonstrou exatamente isso. O trabalho não foi escrever prompts. Foi projetar o ambiente: suíte de testes, ciclos de feedback, restrições. Design de ambiente, não design de prompt.

Os Níveis da Ramp

A Ramp oferece um caso concreto. Com US$ 1 bilhão em receita e aproximadamente 311 engenheiros, a empresa publicou um modelo de proficiência em quatro níveis para operação de agentes.

L0: o desenvolvedor usa assistência básica de código. Autocomplete, sugestões inline. A IA é uma ferramenta passiva.

L1: o desenvolvedor delega tarefas definidas. “Escreva um teste para esta função.” “Refatore este método.” A IA executa dentro de escopo explícito.

L2: o desenvolvedor especifica o resultado esperado e o agente determina a abordagem. “Implemente o endpoint de autenticação OAuth conforme esta spec.” O agente decide a estrutura, os arquivos, a sequência.

L3: o desenvolvedor define o problema e o agente propõe a solução. O humano valida a abordagem, não a implementação. É o ponto onde on-the-loop se torna o modo natural de trabalho.

O dado mais revelador da Ramp: com 25 product managers e mais de 500 features entregues, a proporção de PMs por engenheiro é significativamente menor que a média da indústria. Isso sugere que parte do trabalho de coordenação que tradicionalmente exigia humanos foi absorvido pela infraestrutura de agentes.

Duas ressalvas. Os números da Ramp não foram verificados independentemente. E empresas em hipercrescimento frequentemente operam com eficiências que não se replicam em organizações maiores e mais complexas. Dito isso, o modelo de níveis é útil como framework, independente dos números específicos.

O Gargalo de Validação

Os dados da CircleCI iluminam algo que os cases da Ramp e da Factory confirmam por outro ângulo: o gargalo migrou.

Há dois anos, o gargalo era escrever código. Desenvolvedores passavam a maior parte do tempo produzindo linhas de código, e tudo que acelerasse essa produção gerava ganho direto.

Hoje, para times usando agentes, escrever código é quase instantâneo. O gargalo agora é validar, testar, integrar e fazer deploy do código gerado. É por isso que os dados da CircleCI mostram queda na taxa de sucesso: mais código entrando no pipeline sem aumento proporcional na capacidade de validação.

Como discutimos em A Regra dos 65%, a telemetria de workflows reais mostra que 65% dos nós de IA agêntica em produção executam como código determinístico. Os nós determinísticos fazem exatamente o trabalho de validação: rodar testes, executar linting, verificar tipos, aplicar formatação. A parte agêntica gera. A parte determinística governa. O investimento na camada determinística é o que separa os times do percentil 95 dos demais.

A McKinsey publicou uma projeção para o setor bancário que ilustra o destino desse modelo: funcionários passariam de 80% do tempo em coordenação para 80% em decisão, com uma pessoa supervisionando 20 a 30 agentes. A projeção é especulativa, mas a direção é consistente com o que Factory e Ramp já praticam em menor escala.

O Flywheel Agêntico

Os times que funcionam no percentil 95 da CircleCI não chegaram lá comprando ferramentas melhores. Chegaram construindo um ciclo de retroalimentação.

O ciclo funciona assim. O agente produz código. O harness de validação (testes, CI, linting, type checking) identifica falhas. As falhas alimentam melhorias no harness. O harness melhorado permite ao agente operar com menos intervenção. Menos intervenção libera o engenheiro para melhorar o harness ainda mais. O ciclo se reforça.

É um flywheel. Cada volta aumenta a autonomia do agente e reduz a carga cognitiva do humano. Mas o flywheel só gira se o investimento inicial for no harness, não no agente. Comprar um agente melhor sem melhorar o harness é como colocar um motor mais potente num carro sem freios.

Esse é o erro mais comum que vejo em organizações adotando agentes. Elas investem no agente (escolha do modelo, customização de prompts, integração com IDE) e subestimam o harness (cobertura de testes, confiabilidade do CI, clareza das convenções). O resultado é previsível: mais código gerado, mesma capacidade de validação, taxa de sucesso em queda. Exatamente o que a CircleCI mediu.

O Que “Projetar Sistemas” Significa na Prática

Quando digo que os times bem-sucedidos projetam sistemas em vez de revisar diffs, não estou falando em abstrato. Significa investimento concreto em cinco áreas.

Cobertura de testes como especificação. Testes não são apenas verificação. São a linguagem pela qual o humano comunica ao agente o que “correto” significa. Uma base de código com 90% de cobertura é uma base de código onde o agente sabe, em 90% dos casos, se seu output funciona antes de qualquer humano olhar.

CI como guardrail automático. Cada commit passa por validação automatizada. O humano não revisa o código. O humano projetou o pipeline que revisa o código. A diferença é entre fazer o trabalho e projetar o sistema que faz o trabalho.

Convenções explícitas e documentadas. Linting rules, formatação automática, ADRs (Architecture Decision Records), guias de estilo. Tudo que remove ambiguidade para o agente remove também a necessidade de revisão humana sobre decisões de estilo.

Métricas agregadas em vez de inspeção unitária. Em vez de ler cada PR, monitore taxa de sucesso do CI, tempo médio de merge, frequência de rollback, cobertura de testes por módulo. Se as métricas estão saudáveis, os outputs individuais provavelmente estão corretos. Quando uma métrica deteriora, investigue.

Feedback loops documentados. Quando o agente falha de um modo novo, a resposta não é corrigir manualmente. É adicionar um teste, uma regra de linting ou um check no CI que previna a recorrência. Cada falha melhora o sistema.

A Transição Silenciosa

O relatório da CircleCI captura uma transição em andamento. Os times no topo não são necessariamente os que usam os melhores agentes. São os que construíram a infraestrutura de validação que permite aos agentes operar com autonomia crescente.

A linguagem de Fowler organiza essa transição. De in-the-loop (reviso cada output) para on-the-loop (projeto o sistema que valida outputs). A linguagem da Factory a materializa: readiness é propriedade do código, não das pessoas. A linguagem da Ramp a gradua: L0 a L3, de ferramenta passiva a agente autônomo supervisionado.

Nenhuma dessas empresas fala em substituir desenvolvedores. Todas falam em mudar o que desenvolvedores fazem. Menos escrever código. Menos revisar código. Mais projetar os sistemas dentro dos quais código é produzido e validado automaticamente.

Essa é a mudança operacional real. Não é sobre qual modelo de IA você usa. É sobre se sua base de código, seus pipelines e suas convenções estão prontos para que agentes operem com a autonomia que a tecnologia já permite.

A pergunta para toda organização usando agentes de IA não é “quanto código seus agentes geram?” É “quanto desse código chega a produção sem intervenção manual?”

Se a resposta é “pouco”, o problema não está no agente. Está no harness.

Fontes

CircleCI. “2026 State of Software Delivery.” Fevereiro 2026.
Martin Fowler. “On the Loop.” martinfowler.com, fevereiro 2026.
Factory. Modelo de agent readiness com 5 níveis e 60+ critérios. 2026.
Ramp. Modelo de proficiência L0-L3 para operação de agentes. 2026.
McKinsey & Company. Projeção sobre coordenação vs. decisão no setor bancário. 2026.

Na Victorino Group, ajudamos organizações a construir o harness de validação que transforma agentes de IA em capacidade operacional confiável: contato@victorino.com.br | www.victorino.com.br