Três palestras da AI Engineer World’s Fair 2026 compartilham um desconforto parecido: as ferramentas aceleram a produção de código, mas quem controla o que está sendo construído? Matt Dailey batiza a doença, Anirban Chatterjee mede a dívida de qualidade que ela deixa, e Arjun Singh mostra um caminho para manter agentes úteis sem perder o controle.

O custo oculto da aceleração com IA

Matt Dailey, CEO da Ref, tem um nome para o que acontece quando uma equipe inteira acelera 10x com IA: “velocity sickness”. O problema não é a velocidade em si, mas o que ela esconde. PRs se acumulam, cada um puxa o código numa direção diferente, e agentes rodam o dia todo para serem descartados à noite sem deixar progresso real. Dailey chama isso de “falência de agente”: você gasta tokens, cria e destrói agentes diariamente, e o retrabalho mascara que quase nada avançou.

O risco maior, segundo ele, não é a velocidade. É a perda de controle sobre decisões arquiteturais e de produto quando agentes atuam sem supervisão. A aceleração individual com IA não vira produtividade de equipe sozinha. Ela amplifica problemas de coordenação e propriedade que já existiam.

Anirban Chatterjee, da Sonar, olha para o mesmo fenômeno pela ótica da qualidade. Um estudo da Carnegie Mellon aponta que o ganho de produtividade com ferramentas como Cursor dura cerca de três meses. Depois disso, os problemas de qualidade de código crescem de forma persistente. Chatterjee chama essa diferença entre o código que a IA gera e o que aplicações críticas exigem de “dívida de verificação”. A resposta que ele propõe é uma camada de análise estática, tipo SonarQube, para medir e conter essa dívida antes de ela virar incidente.

Os dois vídeos formam um diagnóstico em duas partes. Dailey descreve o problema humano e organizacional; Chatterjee tenta medi-lo em código.

Velocity Sickness: What Happens When Your Whole Team Gets 10x Faster · Matt Dailey, Ref. · 20min37s

Guide, Verify, Solve — Anirban Chatterjee, Sonar · AI Engineer · 22min31s

Agentes que trabalham junto com a equipe

Arjun Singh, cofundador da Gradescope e atualmente na Superconductor, sai do diagnóstico e vai para a arquitetura. Para ele, sistemas multiagente só funcionam se duas coisas forem levadas a sério: ser agnóstico em relação a modelos e ferramentas, e transformar interfaces humanas existentes em interfaces para agentes.

A agnosticidade de modelos importa porque o melhor modelo muda semana a semana. Amarrar todo o fluxo a um único fornecedor quebra na primeira atualização. Modelos de peso aberto, como o GLM 5.2, já são viáveis e dão mais controle de custo e de experimentação. Singh também defende usar o Slack como interface de agentes: a equipe não precisa aprender uma ferramenta nova, e o agente entra no fluxo de trabalho que já existe.

Há uma tensão aqui com os vídeos anteriores. Singh fala em delegar decisões a agentes integrados ao Slack. Dailey alerta que agentes sem supervisão tomam decisões críticas e geram caos. Os dois estão certos ao mesmo tempo. A diferença está em quanto de controle humano existe no loop, e esse é exatamente o ponto que nenhuma das palestras resolve sozinha.

Multiplayer agentic engineering — Arjun Singh, Superconductor · AI Engineer · 18min44s

As três palestras juntas desenham um arco completo: a aceleração cobra um preço, o preço é mensurável, e existem formas de arquitetar o sistema para que o agente trabalhe para a equipe em vez de trabalhar contra ela.