A Era Centauro do Software Começou. Meça o Time, Não o Modelo.

Em maio de 1997, o Deep Blue venceu Garry Kasparov. A manchete foi que as máquinas haviam passado os humanos no xadrez. A história mais longa, a que durou as duas décadas seguintes, foi outra. Por cerca de vinte anos depois da partida, a entidade mais forte no tabuleiro não era humana nem máquina. Era um humano em par com um motor: um centauro. O par vencia o motor sozinho e atropelava o humano sozinho. Essa era acabou só recentemente, quando os motores finalmente superaram até o jogo guiado.

O ensaio de Richard Marmorstein, Software’s Centaur Era, argumenta, de forma convincente, que o software acaba de entrar na mesma janela. Agentes de código hoje não conseguem sustentar trabalho de longo horizonte sem um humano no leme. Deixados sozinhos, eles derivam, alucinam contexto e produzem código que compila, mas não pertence ao sistema que deveria servir. Direcionados, eles avançam mais rápido do que qualquer das partes sozinha. Estamos nos anos centauros, e os anos centauros costumam durar mais do que se espera.

Se essa leitura está correta, e acreditamos que está, a implicação para governança é a parte sobre a qual ninguém está falando alto o suficiente. A pergunta de medição deixa de ser sobre o modelo. Passa a ser sobre o par.

O que “centauro” significa como unidade de trabalho

A analogia do xadrez nunca foi sobre xadrez. Era sobre uma classe de problemas em que o motor tem profundidade tática que falta ao humano e o humano tem julgamento de longo horizonte que falta ao motor. O software, hoje, encaixa quase exatamente nesse formato. Um agente consegue triturar mil refatorações candidatas, sustentar a árvore sintática em memória de trabalho e escrever o comando bash mais rápido do que você consegue soletrar. Não consegue, de forma confiável, decidir qual dessas refatorações importa no próximo trimestre. Não sabe de qual abstração seu time vai se arrepender em seis meses. Não sabe quando parar.

O humano no centauro fornece exatamente essas coisas: a regra de parada, o gosto arquitetural, a memória institucional, a relação com a pessoa que vai cuidar do código às três da manhã. O agente fornece vazão e recall. Qualquer um dos dois sozinho é um engenheiro pior do que o par.

Isso soa como um enquadramento simpático até você tentar medir. No momento em que você pergunta “quão produtivo é o agente”, está fazendo a pergunta errada, porque o agente não é a unidade de produção. O par é. Uma arquitetura de medição que rastreia a saída do agente sem rastrear a condução humana está medindo metade de um centauro e chamando isso de cavalo.

A régua para ferramentas que poupam energia é mais alta do que para as que poupam tempo

Marmorstein refina esse ponto com uma restrição que merece ser citada em todo lugar em que times de governança se reúnem. A régua de uma ferramenta que poupa energia é mais alta do que a régua de uma ferramenta que poupa tempo.

Quem poupa tempo só precisa ser mais rápido, no líquido, que a alternativa. Você tolera atrito porque o relógio de parede venceu. Quem poupa energia precisa fazer com que o humano sinta que está executando menos trabalho cognitivo, não mais, depois que a ferramenta entra na malha. A maioria dos agentes de código hoje poupa tempo e queima energia. O desenvolvedor babá da saída, relê o diff, roda os testes, sustenta o quadro arquitetural na cabeça porque o agente não o faz, e termina o dia mais cansado do que começou. As horas ficam bonitas no relatório. O humano fica moído na sexta-feira.

É por isso que “ganho de produtividade” medido em tempo-até-merge engana. Se o agente corta 30% do ciclo, mas o desenvolvedor agora carrega o esforço mental de duas pessoas, o centauro está quebrado. O par não é mais rápido em nenhum sentido que componha. É mais rápido em um sentido que erode. No final do trimestre, os melhores engenheiros do time são os que desligam silenciosamente os agentes, porque para eles a matemática do centauro virou negativa dois meses atrás e ninguém estava medindo o eixo certo.

A implicação de governança: qualquer adoção de agentes que não instrumente a carga cognitiva humana ao lado da vazão do agente está voando cega na variável que decide se o par é sustentável.

Por que “controlar a IA” é o enquadramento errado

A maior parte da literatura atual de governança trata o agente como a coisa a restringir. Guardrails, sandboxes, andares de identidade, modelos de permissão. Tudo necessário. Nenhum suficiente. Eles respondem à pergunta “o que o agente não pode fazer”. Não respondem à pergunta “o par está funcionando”.

Você pode ter um agente perfeitamente contido operando dentro de um ambiente perfeitamente seguro e ainda assim ter um time quebrado. O agente não derruba o banco de produção. O humano queima no terceiro mês porque o par nunca foi dimensionado corretamente: threads demais de agente por humano, sem regra clara de parada, sem arquitetura para devolver contexto ao operador, sem medição de quando o operador está sobrecarregado.

A conversa de controle está madura. A conversa de medição mal começou. Já escrevemos sobre lacunas de adoção, em que a pergunta é se as organizações estão usando IA (AI Eats the World 2026). Já escrevemos sobre On the Loop, não In the Loop, em que a pergunta é qual papel o humano deve ocupar na operação de agentes. Esses enquadramentos seguem válidos. O enquadramento do centauro se sobrepõe a eles: uma vez que você decidiu que humanos estão sobre a malha, ainda precisa decidir se a malha, como par, produz mais do que a soma das partes. Isso exige medir o par, não as partes.

Como medir o time, na prática

Concretamente, uma arquitetura de medição consciente do centauro tem três camadas.

A primeira camada é a vazão do agente, que a maioria dos times já rastreia: tarefas concluídas, PRs abertos, testes escritos, linhas de código geradas. Essa é a metade visível do par. É necessária e insuficiente.

A segunda camada é carga cognitiva humana. É a camada que praticamente nenhuma implantação em produção instrumenta hoje. Sinais úteis: tempo gasto revisando saída do agente versus produzindo; frequência de troca de contexto por hora; razão entre mudanças iniciadas pelo agente e iniciadas pelo humano; energia autorrelatada no fim da semana. O objetivo não é vigiar. O objetivo é saber quando o centauro está pedindo demais da sua metade humana, para corrigir antes que o humano silenciosamente desista.

A terceira camada é saída do par, que é o que o negócio de fato olha. O produto melhorou? Defeitos caíram? Tempo até valor encolheu com custo de energia humano constante ou menor? É aqui que vive a distinção entre poupar tempo e poupar energia. Um par que entrega mais rápido, mas exaure o humano, é um par que se dissolve. Um par que entrega mais rápido preservando energia é um par que compõe.

Um time medido só na primeira camada vai otimizar para atividade de agente. Um time medido só na terceira camada não sabe que alavanca puxar quando algo dá errado. As três camadas juntas permitem a pergunta diagnóstica certa: qual metade do centauro é o gargalo desta semana e o que mudamos para reequilibrar?

O que a era centauro não promete

Duas coisas que esse enquadramento não promete.

Não promete que a era dure para sempre. Motores de xadrez acabaram superando o jogo guiado. Agentes de código provavelmente vão superar também, em alguns workloads, em algum horizonte. A posição honesta é que ninguém sabe quanto tempo a janela fica aberta. Vinte anos não seriam surpresa. Cinco também não. A postura correta é construir para os anos centauros enquanto se observa o sinal de que estão terminando.

Não promete que o centauro seja sempre a resposta certa. Existem tarefas em que trabalho humano puro é mais rápido, e tarefas em que trabalho de agente puro é suficientemente bom. O centauro é a unidade certa para o trabalho de longo horizonte, denso em julgamento e dependente de gosto que define a maior parte da engenharia de software em produção. Não é a unidade certa para scripts de uso único nem para geração de alto volume e baixo risco em que a sobrecarga de revisão excede o próprio trabalho.

O enquadramento do centauro é um padrão, não um universal. O trabalho é descobrir onde se aplica e instrumentar quando se aplica.

Faça isso agora

Escolha um time rodando agentes de código em produção. Passe 45 minutos com ele. Faça três perguntas: como medimos vazão do agente hoje; medimos carga cognitiva humana de alguma forma; e o que o par produz que nenhuma das metades produziria sozinha? Se você não consegue responder à segunda pergunta com algo mais específico do que “eles dizem que está tranquilo”, você está operando um centauro sem painel para metade dele. Construa a metade que falta neste trimestre, antes que seus melhores engenheiros decidam, em silêncio, que a matemática não fecha.

Os anos centauros são bons anos. Recompensam os times que levam o par a sério como unidade de trabalho. Punem os times que continuam medindo o modelo e ignorando o cavaleiro.

Fontes

Richard Marmorstein. “Software’s Centaur Era.” Maio de 2026.

A Victorino ajuda equipes a projetar arquiteturas de medição para trabalho humano-mais-IA onde as duas metades do centauro contam: contato@victorino.com.br | www.victorino.com.br