O gargalo está na interface, não no modelo
Quando os agentes de código ficaram bons o suficiente para produzir trabalho útil, a pergunta natural foi qual modelo usar. Passado o entusiasmo inicial, a pergunta que sobrevive é outra: por que duas pessoas com o mesmo modelo, o mesmo editor e a mesma tarefa chegam a resultados tão distantes?
A resposta mais consistente está em duas variáveis que o modelo não controla. A primeira é a distância entre o que quem dirige sabe e o que consegue transmitir. A segunda é a qualidade do ambiente onde o agente trabalha. Modelos melhoram de forma incremental; essas duas variáveis mudam por decisão de quem opera, e é ali que os ganhos se acumulam.
Isso desloca o que vale aprender. Decorar a sintaxe de um harness produz pouco, porque a interface muda. O que se transfere entre ferramentas é engenharia de contexto, de verificação e de processo, aplicada a um executor que interpreta texto literalmente e nunca vai ler a mente de ninguém.
O abismo entre intenção e instrução
Existe um abismo entre quem pede e quem executa. Ele aparece igual nos dois casos, humano falando com humano e humano falando com agente. Quando alguém descreve um sistema para outra pessoa, a outra não recebe o sistema. Recebe uma descrição e completa as lacunas com suposições próprias.
Com um agente, a diferença é que ele não pergunta por educação. Ele preenche. Se uma decisão importante não foi mencionada, o agente trata como irrelevante e segue, ou inventa um critério. Segurança, estratégia de deploy, comportamento em falha parcial, política de retenção de dados: tudo isso fica invisível até alguém dizer que importa.
O que separa quem obtém bom trabalho de quem obtém resultado medíocre é a consciência dos próprios desconhecidos desconhecidos: aquilo que você não sabe que não sabe, e que por isso não aparece na especificação. Prompts mais sofisticados não cobrem essa lacuna, porque o problema não está na formulação do pedido e sim no que ficou de fora dele.
Há uma técnica simples para isso, e ela é pouco usada porque parece lenta. Antes de construir, peça ao agente que conduza um questionamento estruturado. A sequência de perguntas deve forçar a explicitação de objetivo, restrições, o que não pode acontecer e como o resultado será julgado. O agente é bom nisso justamente porque não compartilha os seus pressupostos. Ele pergunta o que você não teria pensado em responder.
Uma variação ataca o mesmo problema por outro ângulo: construir o vocabulário junto com o código. Os termos que aparecem no modelo de dados, na interface, na conversa com o cliente e na documentação deveriam ser o mesmo conjunto de palavras com o mesmo significado. Quando "pedido", "solicitação" e "requisição" circulam como sinônimos para coisas ligeiramente diferentes, o agente escolhe uma e propaga a escolha por todo o sistema. Fixar a linguagem antes reduz uma classe inteira de erro.
É design orientado a domínio aplicado a um executor que interpreta texto literalmente. A diferença é que, com um agente, a ambiguidade lexical não gera discussão: gera código.
O código é o ambiente operacional
Um agente produz de acordo com o ambiente que encontra. Base de código sem testes, com padrões contraditórios e sem verificação automática produz alterações frágeis, porque não há nada que impeça uma alteração de parecer razoável e estar errada. O ambiente é a variável causal; o agente responde a ele e não consegue distingui-lo de um ambiente saudável.
A pergunta operacional que ajuda é contra-intuitiva. Em vez de "como faço o agente trabalhar melhor", pergunte: se eu tivesse cem desenvolvedores humanos no meu time, como eu elevaria o nível do pior deles? As respostas são as mesmas de sempre: testes que falham quando o comportamento quebra, verificações que impedem regressões, padrões que reduzem a chance de erro, documentação que encurta a distância até o entendimento. Aplicado a agentes, isso tem efeito composto, porque cada verificação que você adiciona deixa de ser uma coisa que você precisa revisar manualmente.
Aqui convém separar esta posição de um discurso vizinho. A ideia de que a especificação é o novo código sustenta que basta escrever um documento detalhado para que o agente produza o sistema. O padrão que aparece quando se tenta sustentar esse modelo por meses é previsível: a especificação cresce, o código se degrada, e a distância entre os dois aumenta. O motivo é estrutural. O código é onde as fraquezas do design ficam visíveis. Uma decisão que parece limpa em um documento revela acoplamentos e casos de borda quando vira código. Se você só refina o documento, descobre os problemas tarde, quando corrigi-los custa mais.
Especificação tem função. Ela organiza intenção, alinha vocabulário e serve de contrato para testes. Tratada como insumo do código, ela reduz retrabalho; tratada como substituta, desloca o esforço para o documento e adia a descoberta dos acoplamentos para o momento mais caro.
Verificabilidade decide onde delegar
Agentes são notavelmente bons em código porque código é fácil de verificar. Você roda, testa, compara. O laço de retroalimentação é curto e objetivo. É o mesmo motivo pelo qual são bons em matemática: uma prova é verificável, mesmo quando a descoberta é difícil.
Trabalho real raramente tem essa propriedade. Uma decisão de produto, um diagnóstico de organização, um texto que precisa convencer alguém: nada disso tem um teste que diga "passou". É por isso que a mesma pessoa que entrega software em velocidade inédita trava quando tenta delegar o resto.
A implicação prática é escolher a delegação pela verificabilidade, não pela dificuldade. Se você consegue definir, antes de começar, qual evidência provaria que o resultado está certo, o agente tem chance real de acertar. Se não consegue, ele vai produzir algo que parece certo e você não terá como distinguir.
Isso coloca verificação como trabalho de projeto, não como etapa final. Definir o critério de aceite é o que converte uma tarefa em algo delegável.
Calibração: começar onde o custo do erro é baixo
A ordem de investimento segue o custo do erro, e não o potencial do modelo. Delegar primeiro o que você detecta e corrige rápido constrói familiaridade justamente onde uma falha sai barata. Rascunhar respostas repetitivas, primeiras versões de texto, refatoração mecânica: é ali que o retorno é imediato e o risco é contido. A tentação de entregar de saída as tarefas mais ambiciosas inverte essa ordem e cobra o preço na primeira falha que ninguém consegue avaliar.
Confiança se constrói na mesma direção. A analogia da direção ajuda: o primeiro pedal que se aprende é o freio. Quem começa acelerando esgota limite de uso, produz coisa que não queria e não desenvolve intuição sobre o comportamento da ferramenta. A sequência que funciona é observar de perto, entender o que o sistema oferece, reconhecer o momento em que você está confiando sem verificar, e só então paralelizar.
O nível de esforço responde ao mesmo critério. Existe a tendência de configurar o máximo de raciocínio possível por padrão, associando esforço a qualidade. Quando o ambiente já garante que o resultado passa nas verificações, o esforço adicional compra latência e consumo sem mudar a saída, porque a triagem passou a ser feita pelos testes. Reduzir o esforço e deixar a verificação filtrar costuma render mais.
Por último, a escolha de ferramenta. Modelo e harness definem o teto, mas o retorno sobre essa escolha decresce rápido: entre dois modelos próximos em capacidade, a diferença de resultado tende a ser menor do que a diferença entre um ambiente preparado e um ambiente improvisado. O tempo gasto comparando harness rende mais quando investido em contexto e verificação.
Resta um ajuste que costuma passar em branco: dar ao agente acesso ao ambiente real. Um agente que consegue abrir a aplicação, navegar e ver o resultado tem informação que nenhuma descrição substitui, e isso fecha o laço de verificação em vez de apenas instruí-lo. É a mesma lógica da seção anterior aplicada ao próprio agente.
O que ainda não está resolvido
Agentes são ruins em pensar a longo prazo sobre uma base de código. Eles otimizam para a tarefa presente e raramente assumem o custo de manutenção que estão criando. O que falta é o comportamento do desenvolvedor chato que sempre está na equipe e diz que é melhor fazer do jeito certo, para o benefício de quem vem depois. Transformar esse comportamento em processo é um problema aberto, e não há resposta consolidada para ele.
Orquestração de muitos agentes também não tem forma canônica. É possível manter vários em paralelo, com escopo separado e revisão, e o ganho é real. Mas não existe estrutura demonstrada para coordená-los, e as configurações que funcionam dependem de supervisão próxima, o que reintroduz o gargalo humano que a paralelização tentava reduzir.
Um caminho possível é tratar a base como fábrica: automatizar o início das tarefas e usar cada ciclo para melhorar a base, de modo que a próxima alteração seja mais barata que a anterior. Isso só se sustenta com o que este texto vem argumentando: ambiente verificável, vocabulário estável e critério de aceite explícito. Sem esses três, o ciclo acelera a produção de dívida em vez de reduzir o custo de mudança.
O que fazer na prática
Se o objetivo é obter trabalho de qualidade com agentes, a ordem de investimento é esta. Primeiro, instrumente o ambiente: testes, verificação automática e padrões que reduzam a chance de erro. Segundo, reduza o abismo de comunicação: questione antes de construir e fixe o vocabulário. Terceiro, classifique as tarefas por verificabilidade e delegue as que têm critério de aceite objetivo. Quarto, calibre esforço e confiança de forma incremental, começando pelo trabalho de baixo risco.
Esse argumento tem limite, e vale explicitar qual é. Se o custo de transmitir contexto cair o suficiente, ou se a verificação automática cobrir domínios hoje fora do alcance de testes, a vantagem de investir em ambiente diminui. Enquanto nenhuma das duas coisas acontece, a ordem acima se sustenta: um modelo melhor executa melhor aquilo que entende, e continua sem saber o que importa para você até que você diga.
