O gargalo mudou: algumas notas sobre engenharia de IA, do código ao produto

IA muda rápido, e acompanhar virou um trabalho à parte. O que segue é a minha leitura desse gargalo e de onde ele está em novembro de 2026, escrita a partir do dia a dia em produtos de IA, e não de um laboratório; partes disso podem soar erradas no mês que vem. Construir desse jeito mudou meu processo mais do que qualquer metodologia que já tenha adotado: ciclos menores que uma sprint, um plano que se move dentro do ciclo, protótipos que valem ser jogados fora e a necessidade de sair do código para olhar o cliente, os dados e a operação.

O artigo mistura dois assuntos fáceis de confundir: IA como ferramenta para um engenheiro de software e software AI-first, em que modelos, harnesses e agentes são o produto que o cliente usa. Os dois têm sido meu trabalho no último ano, um ano em que desenvolvimento de software e produto se aproximaram de um jeito que antes não era possível. O que segue não é a vida de todo desenvolvedor: são as opiniões de um engenheiro que constrói produtos de IA, e é por isso que o texto lê como notas, não como um argumento único. Avaliação, harnesses, eficiência e autonomia merecem, cada um, um artigo próprio.

Se existe uma versão curta, é esta: capacidade deixou de ser o gargalo em torno do qual eu planejo. Verificação virou o gargalo, e a confiança no que pode agir sozinho fica atrás disso. Gerar código ficou barato; fazer esse código sobreviver à produção e entregar algo que alguém pague, não.

Um desenvolvedor que se tranca no castelo do código, julgando diffs e nunca perguntando se aquilo deveria existir, fica confortável e substituível. Estou resolvendo um problema real aqui, ou implementando um card e chamando de pronto? Ser digitador de código não protege ninguém; é a primeira parte do trabalho que um modelo já faz mais rápido. Escrever código nunca foi a essência do trabalho — resolver problemas era —, e se a IA assume a digitação, ela devolve o tempo para enxergar o quadro inteiro: o cliente, a operação, o custo de errar. É nesse desenvolvedor que eu apostaria: o que sabe qual problema merece o código e consegue dizer se a resposta vale ser entregue. Nenhum modelo vai tomar essa decisão.

Onde as coisas estão

Estes são os julgamentos que eu defenderia numa revisão de design hoje. Juntos, eles são o argumento; o que vem depois é o desenvolvimento. As perguntas por trás deles são as mesmas que eu faço a um pull request e a um produto: onde está a capacidade, quanto custa uma tarefa concluída e quanto dela pode ficar sem supervisão.

O ganho está no ciclo, não na resposta. Em código, uma chamada escreve algo que parece código; é o ciclo que escreve algo que pode ser conferido contra um teste, um type checker ou um serviço rodando. Em produto, a diferença aparece como repetibilidade: uma demo roda uma vez com alguém guiando, enquanto uma feature precisa funcionar quando ninguém está olhando. O ciclo diminui essa distância sem fechá-la, porque só consegue checar o que alguém pensou em checar.

O harness é parte do modelo que você de fato usa. Em código, o mesmo modelo sob ferramentas, instruções, montagem de contexto e validação diferentes se comporta como um colega diferente. Em produto, o harness é o produto: ele decide o que o modelo pode tocar, o que ele lembra e o que ele nunca pode fazer. O modelo é alugado; o comportamento é construído.

Escrever não é mais o gargalo; verificar é. Em código, revisar o diff, decidir se os testes provam a coisa certa e julgar o encaixe arquitetural agora custam mais do que produzir a mudança. Em produto, o mesmo deslocamento aparece como uma pergunta de aceitação: quem confirma que a saída está certa, e o que acontece quando ninguém confirma. Nos dois casos, a senioridade sai de produzir e vai para julgar.

Código é o básico; o valor está no processo. Em código, gerar é o piso em que todo provedor compete, então o valor migrou para o que cerca a geração: testes, tipos, portões de revisão, checagens de CI e observabilidade. É esse ecossistema que pega o código gerado antes de ele chegar à produção, e o código agora aparece numa velocidade que nenhum time revisaria no ritmo antigo. Construir o aparato que prova que a saída é segura é o trabalho de verdade. Em produto, o cliente não está comprando um modelo; está comprando o desaparecimento de um passo manual. É por isso que os produtos que duram pegam uma rotina cara e a tornam definida e verificável.

Tarefas longas continuam sendo o ponto mais fraco, e a abertura mais clara. Em código, uma sessão de horas perde estado e o agente declara conclusão cedo. Em produto, a mesma falha aparece como um agente de suporte que esquece o ticket, ou um pipeline que reporta sucesso num lote processado pela metade. As respostas até aqui são respostas de harness — progresso incremental, estado externo, testes —, e nenhuma delas está pronta. Um produto que mantém estado, retoma de onde parou e consegue provar o que de fato concluiu já está à frente, seja qual for o caminho que escolheu até lá.

Benchmarks dão direção; suas tarefas dão a resposta. Em código, um painel de benchmarks reduz o campo a três ou quatro candidatos. Em produto, o problema maior é a não-determinação: a mesma entrada pode seguir caminhos diferentes, então o comportamento não pode ser previsto a partir de um ranking nem de uma execução isolada. Testar em casos reais e adaptar o sistema ao redor é como se chega perto, e nada é testado exaustivamente antes do lançamento, porque cobertura perfeita custa o tempo que o mercado não dá. Avaliar comportamento em produção e corrigir rápido passou a fazer parte do processo.

Custo é uma decisão por tarefa, não um critério de lançamento. Em código, a escolha muitas vezes não é o melhor modelo, e sim o modelo bom o bastante para cada passo. Em produto, a mesma decisão é economia unitária, e tomá-la cedo é armadilha: projeções raramente batem com o uso real, e cortar custo antes de alguém ter usado o produto gasta tempo num número que vai estar errado. Coloque na frente de uso real, meça o custo por tarefa e otimize depois que o valor estiver visível.

Autonomia é um limite que alguém define, não uma propriedade do modelo. Em código, um agente que lê um repositório e propõe um diff carrega um risco diferente de um que dá push na main, e a diferença é permissão, não um modelo melhor. Em produto, a linha aparece em verbos simples: rascunhar a resposta ou enviá-la, sugerir o reembolso ou emiti-lo, sinalizar o alerta ou silenciá-lo. Capacidade não move essa linha. O produto é que precisa decidir onde ela fica e impô-la.

Um aviso sobre o terceiro julgamento, porque é o mais fácil de repetir e o mais difícil de medir. Em 2025, a METR mediu 19% de lentidão em 16 desenvolvedores experientes usando as ferramentas da época, e os mesmos desenvolvedores continuaram acreditando ter ficado cerca de 20% mais rápidos. Em fevereiro de 2026, com 57 desenvolvedores e mais de 800 tarefas, a estimativa virou 18% de ganho para quem voltou ao estudo, com intervalo de −38% a +9%, e a equipe concluiu que o dado deixou de ser um sinal confiável: entre 30% e 50% dos participantes deixaram de submeter tarefas que fariam sem IA. Se a senioridade se move para julgar, a distância entre o que se sente e o que se mede passa a ser o problema de quem julga, não uma nota de rodapé de quem mede. Fontes: METR, 2025 e METR, 2026.

Daqui em diante, o artigo passa pela história que produziu esses julgamentos, pelo modelo e pelo harness que os sustentam e pelas decisões que eles impõem a um time que constrói tanto um código quanto um produto.

De respostas a agentes

A primeira versão que a maioria de nós conheceu era um modelo, não um produto. O GPT-3 chegou em 2020, primeiro como paper e depois como API atrás de uma lista de espera, e o que ele fazia era estranho o bastante para prender a atenção: completava texto a partir de um prompt, num registro próximo o suficiente da escrita humana para servir a alguma coisa. Ninguém que eu conhecia sabia dizer a quê. Era uma capacidade em busca de aplicação. Fonte: paper do GPT-3.

O ChatGPT, no fim de 2022, não acrescentou capacidade; acrescentou um lugar para colocá-la. Uma caixa de texto, instruções, uma conversa e um modelo respondendo a partir do que aprendeu no treino — um harness tão fino que mal conta como harness. Foi também um sucesso imediato, o que diz algo sobre quanto da adoção é interface e não modelo.

O que faltava apareceu nas falhas. Um modelo que responde de memória não tem como se checar, então errar não é caso de borda; é o resultado normal de confiança somada a informação faltando. Em fevereiro de 2023, o Google publicou uma demo promocional em que o Bard afirmava que o telescópio James Webb tinha tirado a primeira imagem de um exoplaneta — uma afirmação que uma única busca corrigiria, feita pela empresa cujo produto era a busca. A Alphabet perdeu cerca de US$ 100 bilhões em valor de mercado em um dia. Fonte: Reuters. Um ano depois, o nome Bard foi aposentado em favor de Gemini, apresentado como alinhamento do produto à família de modelos: correto, e também o tipo de explicação que uma empresa dá depois de um lançamento que preferiria esquecer. Fonte: Google.

O que mudou depois disso, em boa parte, não foi a inteligência do modelo. Foi o que o modelo conseguia alcançar.

Buscar antes de responder. Uma afirmação pode se apoiar numa página em vez da memória, e a resposta pode apontar o que leu.
Chamar código. Diante de um cálculo, o modelo escreve um script curto, executa e devolve o que o interpretador produziu. Aritmética deixou de ser previsão; o resultado é exato porque o modelo não é mais quem calcula.
Chamar ferramentas em geral. O modelo pede uma ação, observa o resultado e continua. É a diferença entre descrever um reembolso e emiti-lo.
Um padrão para as conexões. O MCP, aberto pela Anthropic em novembro de 2024, substituiu integrações sob medida por um protocolo único, de modo que um calendário, uma caixa de e-mail, um repositório ou a API de um banco possam ser expostos a um modelo do mesmo jeito. Fonte: Anthropic.

A outra mudança aconteceu dentro do modelo. Raciocinar costumava ser uma técnica de prompt: mandar pensar passo a passo, perguntar se tinha certeza, pedir para argumentar o contrário e iterar até a resposta se sustentar. Usuários cuidadosos obtinham raciocínio fazendo o modelo falar mais. Os modelos de raciocínio que chegaram a partir de 2024 levaram essa disciplina para o treino: o modelo gasta tokens no próprio argumento, tenta uma estratégia, percebe que não está funcionando e revisa antes de responder. Fonte: OpenAI.

Isso ainda é probabilidade, não prova. O modelo itera até julgar sua resposta provável o bastante para estar certa, o que não é o mesmo que estar certa, e as falhas que restam são mais interessantes do que “ele não sabe”.

Uso de ferramentas e raciocínio, juntos, são o que transformou isso numa categoria de produto em vez de uma demo: Cursor, Windsurf, Claude Code, Codex e tudo o que se inspira neles. Em cada caso, o modelo lê, edita, executa, checa e reporta, em vez de produzir texto para alguém colar.

Agentes levam essa capacidade por um fluxo inteiro. Neste artigo, agêntico descreve um sistema que recebe um objetivo e pode decidir, dentro de certos limites, quais passos e ferramentas usar para alcançá-lo. Uma chamada isolada produz uma resposta ou um trecho de código. Um agente usa essa resposta para escolher uma ferramenta, observa o resultado, atualiza o contexto e dá o próximo passo, até a tarefa terminar, um limite ser atingido ou uma pessoa ser necessária.

Diante de um bug, um agente de código pode:

Procurar no repositório onde o comportamento está implementado.
Ler o código e os testes relacionados.
Propor uma correção.
Rodar os testes disponíveis.
Analisar uma falha e ajustar a implementação.
Apresentar o diff e explicar o que foi validado.

Dependendo do ambiente e das permissões, ele também pode consultar documentação, chamar APIs, usar um navegador ou alcançar outros sistemas. Cada passo pode falhar: ele pode olhar no lugar errado, interpretar uma regra errado ou declarar o trabalho concluído sem testar o comportamento que importava. O ciclo de investigar, implementar, verificar e corrigir é o que cria a chance de pegar essas falhas antes da entrega. É também onde o trabalho ou se torna confiável, ou acumula dívida em silêncio.

Visto de fora do editor, a mudança de escala importa mais do que a de velocidade. Com um modelo que raciocina, busca e age sobre outros sistemas, o custo de um passo deixa de ser o custo de implementá-lo. Um processo que exigia um projeto e um trimestre — entrada de documentos, conciliação entre sistemas, triagem às três da manhã, acompanhamento para o qual ninguém tem tempo — pode ser enunciado como um objetivo com uma definição de pronto e transformado em software. O que um time consegue tentar deixa de ser limitado por quanto custa cada passo, e é daí que vem a sensação de que não há limite. Nada disso é mágica do modelo; nada num modelo inventa valor sozinho. O gargalo mudou, e mudou para o lugar mais difícil: não se um problema pode ser resolvido, mas qual dos problemas resolvíveis vale resolver e qual das suas features um cliente vai pagar. Essa decisão não foi automatizada.

Modelo e harness: partes diferentes do mesmo sistema

Para entender de onde vem o progresso, ajuda separar o modelo do ambiente ao redor dele. O termo se fixou como Agent = Model + Harness: tudo o que não é o modelo é o harness, e é ele que dá ao modelo estado, ferramentas e laços de verificação (LangChain). Böckeler parte dessa definição e a estreita para quem usa um agente de código, separando guias que antecedem a ação de sensores que a corrigem (Böckeler).

O modelo de linguagem recebe contexto e gera respostas. Num fluxo com ferramentas, ele pode produzir uma chamada estruturada e depois interpretar o resultado.

O harness é a camada de software que organiza essa interação. Dependendo da implementação, ele pode:

Fornecer ferramentas para ler e editar arquivos, rodar comandos e acessar serviços.
Montar o contexto enviado ao modelo, incluindo instruções, histórico e resultados de ferramentas.
Gerenciar o ciclo entre chamadas ao modelo e execução de ferramentas.
Aplicar políticas de permissão, limites, sandbox e tratamento de erro.
Preservar ou resumir informação para tarefas que atravessam várias janelas de contexto.

Claude Code, Codex e outras ferramentas de desenvolvimento oferecem combinações dessas capacidades. O comportamento exato depende do produto e da configuração.

A distinção importa porque o resultado não depende só do modelo. O mesmo modelo se comporta de forma diferente sob ferramentas, instruções, contexto e validação diferentes, e a diferença é grande o bastante para ser medida: nas mesmas 25 tarefas, com o mesmo provedor e as mesmas ferramentas, oito harnesses diferentes levaram o mesmo modelo de 68% a 88% de sucesso (Marmelab). No Terminal Bench 2.0, o mesmo Opus 4.6 dentro do Claude Code fica bem abaixo do que o mesmo modelo entrega em outros harnesses, e trocar só o harness levou um agente do Top 30 ao Top 5 (LangChain).

É por isso que hoje eu avalio agentes como sistemas inteiros: modelo, harness, ferramentas, permissões, contexto e ambiente de execução. Uma comparação de modelos que ignora o harness mede algo que ninguém roda.

As limitações do modelo são também onde o harness se justifica. Em experimentos com agentes de longa duração, a Anthropic observou trabalho interrompido no meio, contexto perdido entre sessões e declarações prematuras de conclusão. Fonte: Anthropic. Nenhuma dessas falhas é resolvida por um modelo melhor sozinho; cada uma é tratada no sistema ao redor: progresso escrito à medida que acontece, estado mantido fora da janela de contexto, testes como definição de pronto e reinícios que retomam de um registro, em vez de um resumo que o modelo já esqueceu.

Consistência em tarefas longas continua sem solução, e eu não espero que o próximo lançamento resolva. O que o modelo não consegue carregar, o sistema ao redor precisa carregar. Isso é engenharia de harness, e é o mesmo requisito fora do código: um assistente que esquece o ticket, ou que declara um reembolso processado porque o pedido foi escrito com confiança, tem um problema de harness, não de inteligência.

O harness é o produto

O exemplo mais claro é o que começou o ciclo atual. O ChatGPT não chegou tanto como um modelo novo, mas como uma camada nova em volta de um: uma conversa, um conjunto de instruções e um limite sobre o que ele podia fazer. O que as pessoas adotaram foi o harness.

Esse padrão é hoje o modelo da maioria dos produtos de IA que eu vejo. Um agente de código, uma ferramenta de pesquisa, um assistente de suporte, uma automação interna: embaixo de cada um há um modelo, e em volta dele um harness que fixa o que ele pode tocar, o que lembra, quando para e o que nunca pode fazer. O modelo fornece a capacidade. O harness fornece o comportamento, e comportamento é o que um produto é.

É por isso que o assunto pesa agora. Lançamentos de modelos chegam a cada poucas semanas e em geral sobem o teto; o harness decide quanto desse teto um produto específico de fato alcança. Um time da OpenAI levou isso ao limite: cinco meses, cerca de um milhão de linhas e 1.500 pull requests sem uma linha escrita à mão, e o gargalo que apareceu não foi geração, foi capacidade humana de QA (OpenAI). Em escala menor, a consequência é a mesma: um time que consegue trocar o modelo atrás de um harness estável captura cada melhoria numa tarde; um time que soldou o fluxo às especificidades de um fornecedor não captura nenhuma, e descobre o custo dessa decisão quando o fornecedor muda alguma coisa.

Duas formas disso merecem ser separadas.

Harnesses especializados são dedicados a um único problema: revisão de código, triagem de incidentes, extração de contratos, análise de um formato de log. A vantagem não é um prompt melhor. É um problema menor: as ferramentas são as certas, os critérios de aceitação são conhecidos, a fronteira de permissão é estreita e o ciclo pode verificar contra algo que o domínio já define. Um agente geral precisa descobrir tudo isso em tempo de execução, toda vez, com o contexto que conseguir pagar.

Harnesses compostos são como isso escala para uma solução complexa: vários harnesses com contratos entre eles. Extração, validação, decisão, ação, cada um com suas ferramentas, modelo, verificação e orçamento, ligados por interfaces que dizem o que entra e o que precisa sair. A engenharia está nessas interfaces, muito parecido com dividir um serviço: uma etapa que mente sobre a própria saída é uma falha da qual a próxima não consegue se recuperar. Composição é também o que torna um modelo barato viável numa etapa e desnecessário em outra.

A consequência para os times é direta. O harness é onde o conhecimento de domínio é escrito: o que “pronto” significa aqui, quais sistemas podem ser tocados, o que precisa ser checado antes de um resultado ser aceito. É isso que faz dele a parte de um produto de IA que uma empresa pode possuir, já que o modelo em si é alugado. É também onde o risco se acumula: definições de ferramentas, credenciais e regras de permissão são superfície de ataque tanto quanto o modelo, e uma ferramenta permissiva é uma vulnerabilidade com boas maneiras.

O que sugere uma regra de design que comecei a aplicar: trate o modelo como um componente substituível atrás do harness, não como o fundamento do design. A escolha do modelo passa a ser uma decisão operacional, que pode ser revista quando preço, qualidade ou requisitos de hospedagem mudarem, em vez de um compromisso arquitetural assumido uma vez e defendido depois.

O papel do pós-treinamento

Se o harness decide o que um produto faz, o modelo ainda define o que ele consegue fazer, e o pós-treinamento é onde parte disso é decidida.

Modelos avançaram em várias frentes. Junto com mudanças de arquitetura e pré-treinamento, o pós-treinamento molda comportamentos específicos: seguir instruções, resolver problemas, usar ferramentas.

Uma técnica possível é o aprendizado por reforço. Em termos simplificados, o modelo tenta tarefas, recebe sinais de avaliação e passa por ajustes que favorecem certos comportamentos. Os métodos variam entre modelos e organizações.

Em código, testes podem fornecer parte desse sinal. Mas passar nos testes disponíveis não garante que uma implementação cubra todo requisito ou sirva para produção, que é a mesma lacuna descrita antes, agora levada para o treino.

O relatório técnico do DeepSeek-V3 descreve etapas de ajuste fino supervisionado e aprendizado por reforço. A Xiaomi também mantém uma página pública com métricas de RL do MiMo.

Dados, arquitetura, treino, infraestrutura de inferência e harness contribuem para o resultado. O que importa ao escolher um modelo é mais estreito que isso: como ele se comporta quando o harness em volta é o seu. Um modelo que só rende bem dentro do produto do fornecedor, com as ferramentas e os formatos de prompt daquele fornecedor, é um bom produto; não é evidência de um bom modelo para o trabalho que você constrói.

Isso faz da portabilidade um comportamento, não um item de checklist. Chat completions e um schema de chamada de ferramenta são a parte fácil. A pergunta mais difícil é se o modelo continua seguindo instruções, chamando a ferramenta certa e parando quando deve, quando as instruções, o conjunto de ferramentas e a regra de parada são escritos por você. Um ranking não roda esse teste; o seu harness roda, e é o único que decide.

Conhecimento não é a mesma coisa que utilidade. O GPT-3 carrega muito conhecimento, o suficiente para responder perguntas que impressionariam um leitor, e não consegue usar ferramenta, seguir uma convenção ou sustentar um ciclo, porque nada disso estava no treino dele. Um modelo que parece menos inteligente na conversa, mas roda o ciclo, chama a ferramenta certa e respeita as regras que o sistema definiu, entrega mais do que um mais conhecedor que apenas responde. Uma pessoa julgando inteligência e um harness julgando trabalho concluído medem coisas diferentes, e é sobre a segunda que um produto é construído.

Há razão para esperar que um modelo atual passe nesse teste. O pós-treinamento ensina uso de ferramentas e seguimento de instruções contra formatos concretos, então os provedores treinam contra as próprias convenções de chamada e, cada vez mais, contra convenções compartilhadas: saída estruturada em JSON-schema, MCP e os formatos de prompt que os agentes populares publicam. Um modelo ajustado nessas convenções se comporta de forma mais previsível num harness que as segue e menos previsível num que inventa as suas sem motivo. Construir um harness, portanto, não é invenção livre. Nomes e descrições de ferramentas, formatos de erro e condições de parada devem se parecer com o que o modelo foi treinado para ver; o conhecimento de domínio, a fronteira de permissão e a verificação são onde o seu design ganha valor.

O cenário, do uso diário

O que eu vejo na maior parte do tempo são ferramentas de código, porque é o trabalho: um editor com um modelo dentro, um agente que abre pull request, um bot de revisão, um gerador de testes. Dentro de desenvolvimento de software e automação, as opções incluem famílias como GPT, Claude, Gemini, Mistral, DeepSeek, GLM e Kimi, e capacidade, preço, integração com ferramentas e requisitos de hospedagem pesam de forma diferente conforme a carga.

No trabalho diário, acho GPT e Claude os mais convincentes para desenvolvimento e tarefas agênticas. Para o equilíbrio entre capacidade e custo, as alternativas que mais uso são DeepSeek, GLM e Kimi: nas automações que rodo, a saída costuma ser a mesma, o custo é muitas vezes uma ordem de grandeza menor e a resposta volta mais rápido; só raramente preciso trazer um modelo maior e mais caro. Gemini continua abaixo das minhas expectativas nesses usos. Isso é uma impressão dos modelos, versões e ambientes que de fato usei, não um resultado, e não uma comparação que outra pessoa consiga reproduzir só com este parágrafo.

O que me surpreendeu depois de um tempo no Cursor é o quanto o par barato vai longe. Grok com Composer resolve a maior parte do meu trabalho de código, e eu raramente recorro a um modelo maior — Opus ou Fable, Sol ou Astra — para terminar alguma coisa. Quando recorro, a limitação em geral é minha: um requisito vago, contexto faltando ou um sintoma descrito em vez do comportamento. Com um pedido bem escrito, a tarefa raramente precisa da fronteira. No plano do Cursor, esse par é barato o bastante para eu não pensar duas vezes antes de deixar um agente trabalhando em algo que não merece um modelo premium.

Minhas expectativas para o Google continuam altas pelo que a empresa reúne. Pesquisadores ligados a ela ajudaram a criar o Transformer, a arquitetura no centro dos LLMs de hoje. O Google também desenvolve as próprias TPUs, opera infraestrutura de nuvem em escala e tem canais de distribuição como Android e Search. A empresa publica seus próprios resultados de código e agentes e entrega integrações para desenvolvedores como o Gemini API Docs MCP. Minha crítica é que, nesses fluxos, esses recursos não se tornaram consistentemente uma experiência melhor, e tomo cuidado em notar que a percepção sozinha não prova que os processos internos da empresa expliquem isso. O Gemini 4 está sendo lançado agora, e vamos ver o que o Google entrega com ele.

Código é o básico; comportamento é o que separa

Código é o básico, e a maioria dos modelos já passou dele. Um modelo que não lidera nenhum benchmark ainda escreve código que passa na revisão: segue as convenções do projeto, trata os caminhos de erro e aceita uma correção sem precisar repetir. Julgar esses sistemas pelo código que produzem diz muito pouco, porque código aceitável agora é comum.

O que os separa é comportamento. Se o modelo trabalha com os sistemas que um time já roda, não só com os que estão dentro do produto dele. Se mantém esse comportamento sob um harness que outra pessoa escreveu. Quanto tempo opera sem alguém entrar no meio, e se para quando deve, em vez de reportar sucesso num trabalho que não terminou. Se segue as regras e diretrizes que recebeu quando o atalho é mais barato que a regra.

Nenhuma dessas quatro tem ranking. Todas as quatro só se respondem rodando o modelo no seu trabalho, com as suas ferramentas, por tempo suficiente para ver onde ele desvia.

Essas qualidades são também o que leva um modelo além do papel de respondente ou gerador de código. Responder bem a um prompt é um teste de conhecimento; resolver um problema real exige trabalhar dentro dos sistemas onde o problema vive, respeitar as regras em volta deles e continuar até o trabalho estar feito, não até a resposta soar completa. Sem elas, um modelo é um jeito mais rápido de produzir texto. Com elas, ele consegue assumir um processo.

A pergunta interessante não é o que esses sistemas fazem num editor. É o que um time faz com um modelo e um harness bem construído quando o problema não é um repositório, mas um processo.

O valor está no processo

Visto assim, um modelo mais um harness especializado é matéria-prima: um jeito de transformar uma rotina manual, cara e mal documentada em software. Entrada de documentos em formatos que ninguém combinou. Conciliação entre sistemas que nunca foram feitos para conversar. Triagem de alertas que alguém lê às três da manhã. Resumir um procedimento que ninguém teve tempo de ler até o fim. Cada um desses tem uma entrada conhecida, um resultado observável e um custo que uma planilha consegue mostrar.

Nada disso é demo. É o tipo de trabalho que antes exigia um projeto, um orçamento e um trimestre de reuniões. O que o cliente recebe não é um modelo; é o desaparecimento de um passo.

Acho que os product managers e executivos que já entenderam isso estão à frente dos que esperam uma diretriz mais clara. O que importa é quais processos são caros, repetitivos e verificáveis o bastante para valer virar produto, e depois ter a disciplina de terminar esse produto em vez de admirar a ideia num backlog. Testar uma ideia costumava custar um trimestre; hoje pode custar uma semana. O que não ficou mais barato é o julgamento sobre qual ideia merece essa semana e qual merece os meses seguintes.

Como o leque de processos é amplo, nenhum benchmark responde essa pergunta por você. O mesmo modelo pode lidar bem com triagem de alertas e mal com conciliação de notas fiscais, e a diferença está nas entradas, nas regras e no que conta como correto em cada caso, nada disso medido por um ranking. O que eu gosto num modelo no uso diário não é evidência de que ele vai funcionar num fluxo financeiro. O que decide isso é um conjunto de critérios de aceitação escrito para o fluxo e rodado contra o modelo em casos reais.

De benchmarks a evals

O que segue é sobre construir um produto de IA: o modelo dentro dele e — mais importante — as evals que decidem se esse modelo funciona ali. Não é sobre escolher um modelo para escrever seu código. São decisões diferentes. Um assistente de código pode ser trocado semana que vem e custa um hábito; um modelo dentro de um produto fica atrás dos seus prompts, das suas ferramentas e dos seus critérios de aceitação, então substituí-lo é uma mudança no produto. Benchmarks respondem à primeira pergunta muito melhor do que à segunda.

Benchmarks são o filtro. O Artificial Analysis agrupa avaliações por categoria — trabalho agêntico de conhecimento, uso de terminal, física (CritPt), além de índices de domínio para finanças, jurídico, saúde e engenharia —, e o LiveBench roda suítes de horizonte longo e reporta custo por tarefa bem-sucedida, que é mais próximo do número que me interessa. Com os dois, consigo montar em cerca de uma hora uma lista curta de três ou quatro candidatos para um trabalho específico.

Uma lista curta é tudo o que eles dão, por três razões. A nota é uma média sobre uma distribuição que não é a sua: um modelo no topo de um benchmark de física pode ser pior que um mais barato para extrair campos de notas fiscais digitalizadas, porque o benchmark mede raciocínio sobre problemas limpos e o trabalho é feito de entradas sujas, regras de negócio e um schema que ninguém documentou. As notas também envelhecem: em 2026 a OpenAI retirou a recomendação do SWE-bench Verified por problemas de teste e contaminação, depois encontrou problemas em boa parte das tarefas do SWE-bench Pro e retirou esse também. Fontes: análise do Verified e análise do Pro. E a mesma entrada pode seguir caminhos diferentes em execuções diferentes, então uma demonstração bem-sucedida prova muito pouco. Uma taxa de falha que você não mediu é uma taxa de falha que você vai encontrar em produção.

O que decide é a eval: um conjunto de tarefas tiradas da carga real, cada uma com um critério de aceitação escrito, rodadas contra todo modelo candidato sob o mesmo harness. É a parte de construir um produto de IA que os times pulam, e é a parte que responde o que o benchmark não conseguia. Uma eval diz se o modelo cobre o que o produto precisa — quais entradas ele trata, quais erra e como são as que erra — em vez de como ele se posiciona contra outros modelos num trabalho que ninguém na sua empresa faz. É também o único jeito de comparar dois candidatos antes do lançamento, porque mantém harness, prompts e critérios fixos e muda uma variável. A saída é uma distribuição, não um veredito: com que frequência um resultado é aceitável e quão ruim é a cauda.

Quando a eval existe, ela deixa de ser ferramenta de seleção e passa a ser a suíte de testes do comportamento do produto. Isso importa mais que a escolha do modelo, porque o comportamento depende de uma superfície que muda sem ninguém decidir mudar o produto: um prompt editado para corrigir um caso, uma ferramenta adicionada, a descrição de uma ferramenta reescrita, um campo renomeado num schema, um fornecedor lançando uma versão nova do modelo com o mesmo nome. Qualquer um desses pode mudar resultados em casos que funcionavam, e nenhum aparece num benchmark. Uma suíte de evals rodada a cada mudança transforma uma regressão invisível num caso que falha antes de o cliente perceber. Sem isso, toda edição de prompt é um lançamento sem teste.

Com essa suíte no lugar, as decisões operacionais ficam mais fáceis. Entre os modelos que passam do corte, ela diz qual é o mais barato por resultado aceito. E quando o modelo principal atinge limite de uso, falha ou é descontinuado, ela diz qual outro modelo ainda passa e quanto a saída muda quando ele assume. Registre versões, ferramentas e permissões em cada execução, junto com taxa de aceitação, latência, tentativas, custo e esforço de revisão; os números seguem comparáveis entre lançamentos porque as tarefas não mudam quando os modelos mudam.

Nada disso significa testar exaustivamente antes do lançamento. Cobertura custa tempo, e provar que todo caminho se comporta é tempo que um concorrente gasta lançando. O que importa é saber quais falhas você consegue encontrar em produção e quais não consegue, e então construir o monitoramento e o rollback que tornam a primeira categoria sobrevivível. Se orçamento não é um problema, usar o modelo mais capaz para tudo funciona; é também assim que um produto acaba pagando por capacidade que ninguém mediu.

Custo é a próxima pergunta, e é onde a maioria das comparações de modelo erra.

O que uma tarefa custa de verdade

Todo time que leva isso além do protótipo acaba perguntando quanto custa operar. O número que importa não é o da tabela de preços.

A unidade é a tarefa concluída

Entre as soluções que já atendem ao padrão de qualidade, custo decide o que é viável em escala. Uma solução precisa equilibrar qualidade, latência, vazão, disponibilidade e custo, e em muitos cenários um modelo bom o bastante e barato entrega mais valor do que um modelo de ponta usado em toda chamada. A maioria dos fluxos tem muito mais chamadas baratas do que difíceis.

Comparar preço por milhão de tokens de entrada não basta. A conta também depende de:

Preço de tokens de saída e de entrada em cache.
A quantidade de contexto enviada a cada chamada.
O número de chamadas, de chamadas de ferramenta e de tentativas por tarefa.
Frequência de erro e necessidade de reprocessamento.
Tempo de revisão humana.
Latência, disponibilidade, privacidade e requisitos de hospedagem.

A unidade de comparação é custo por tarefa concluída num nível de qualidade aceitável. Tentativas falhas entram no denominador, não numa nota de rodapé. Um modelo mais barato que exige mais tentativas, chamadas de ferramenta ou contexto ainda pode ganhar com folga, e um modelo barato que produz trabalho que precisa de revisão sênior pode perder mesmo com a conta parecendo pequena.

Nas minhas automações agendadas no Hermes, por exemplo, uso LLMs para processar dados complexos e não padronizados. Com o Claude Sonnet 5.5, o custo normalmente ficava entre US$ 15 e US$ 20 por dia. Depois de trocar para o DeepSeek-V4.1-Flash, caiu para menos de US$ 1 por dia, sem perda perceptível de precisão nessas tarefas.

Isso é uma carga e uma impressão de qualidade, não um experimento controlado. Gasto diário sozinho não estabelece custo por tarefa nem equivalência entre os modelos; reproduzir exigiria o período de observação, o volume de execução, os critérios de aceitação e o custo de cada etapa em volta do modelo. Menciono porque a diferença de magnitude é o argumento: nessa proporção, a pergunta deixa de ser qual modelo é melhor em geral e passa a ser qual modelo é bom o bastante aqui.

Uma lição chegou tarde e me custou tempo: não otimize custo antes de existir usuário. Uma projeção feita de preço por token e volumes estimados costuma errar nas duas direções, então as horas gastas cortando uma conta que ainda não existe são horas que não foram gastas descobrindo se alguém quer o produto. Coloque na frente de uso real, meça o custo por tarefa e otimize depois que o valor estiver visível. Otimização prematura é o velho aviso da engenharia de software, e vale para custo tanto quanto para velocidade: antes de existir usuário, o número é um palpite, e refinar um palpite não melhora o produto.

De onde vêm as economias

As opções para baixar esse número não são só comerciais. O relatório do DeepSeek-V3 descreveu Mixture of Experts e Multi-head Latent Attention como formas de baratear treino e inferência. Fonte. As gerações seguintes foram além. O DeepSeek-V4.1-Flash, lançado em setembro de 2026 e revisado depois, é um mixture of experts de 552 bilhões de parâmetros numa nova arquitetura causal encoder–decoder, com 8 bilhões de parâmetros ativos na entrada e 16 bilhões na saída, e um KV cache que precisa de um quarto da HBM e de um oitavo do armazenamento SSD da geração anterior. Fonte: DeepSeek.

Essas mudanças aparecem no preço. Servido como deepseek-flash, o V4.1-Flash custa US$ 0,15 por milhão de tokens de entrada e US$ 0,60 por milhão de tokens de saída no horário fora de pico, que é metade do preço de pico, com entrada em cache a US$ 0,003. Fonte: preços da DeepSeek. Mais revelador que o número absoluto é a comparação dentro de um mesmo fornecedor: a DeepSeek relata que o V4.1-Flash supera o V4-Pro em qualidade, custo e tempo de execução, e está aposentando o V4-Pro em vez de continuar vendendo o modelo mais caro. O GLM-5.3-Flash da Z.ai fica na mesma faixa, a US$ 0,15 de entrada e US$ 0,50 de saída contra US$ 1,40 e US$ 4,40 do GLM-5.3 da mesma família. Fonte: preços da Z.AI.

A competição entre provedores, incluindo empresas chinesas, ampliou as opções para equilibrar capacidade e custo, o que importa mais em trabalho de alto volume como análise contínua de logs, traces, métricas e documentos. Pesos abertos empurram isso adiante: como a DeepSeek publica o modelo, o preço não é definido por um fornecedor só. No OpenRouter, dezenas de provedores servem os mesmos pesos a preços que ficam abaixo da API oficial e se movem com a demanda, então a pergunta do comprador deixa de ser só qual modelo usar e passa a ser qual provedor de hospedagem rotear, checado contra o que cada um entrega de fato. Também não é mais uma história só chinesa: o GPT-6 Luna, da OpenAI, a US$ 0,10 por milhão de tokens de entrada e US$ 0,50 por milhão de saída, fica igual ou abaixo de todo número acima, e no trabalho agêntico que rodo entrega resultados que eu não esperaria nesse preço. Fonte: preços da OpenAI. É o único modelo de baixo custo de um fornecedor ocidental que hoje eu colocaria na mesma comparação.

Preço não é a única alavanca, e nem sempre a mais forte. Além de escolher um modelo mais barato, a mesma carga custa menos quando contexto repetido entra em cache, quando um passo é substituído por regras explícitas ou código puro e quando o fluxo é dividido para que um modelo pequeno faça o que um grande estava pagando. Essas mudanças muitas vezes economizam mais que um desconto, porque removem trabalho em vez de descontá-lo. É a próxima seção.

Custo é uma dimensão, não a tese. Ele estreita o campo depois da qualidade e não diz nada sobre o que pode agir sem supervisão. Uma solução barata com um erro que você não pode pagar não é solução.

Escolhendo a técnica para a tarefa

Boa parte do valor de engenharia no trabalho com IA é decidir qual modelo cada passo merece. O resto é decidir o que precisa ser checado.

Capacidade proporcional ao problema

Modelos de linguagem pequenos (SLMs) são candidatos para tarefas com escopo definido e resultado verificável. Considere uma automação que recebe dados em formatos diferentes, extrai campos relevantes e passa saída estruturada para outro sistema. Ainda que o fluxo processe grande volume, cada execução pode precisar só de um conjunto limitado de transformações. Gerar boilerplate, adaptar código a uma convenção existente ou resumir logs também podem ser ponto de partida para avaliar um modelo menor.

O risco define o quanto essa avaliação precisa ser rigorosa. Um campo interpretado errado pode afetar uma decisão de negócio, mesmo numa transformação aparentemente simples. Os casos relevantes precisam ser checados, e o fluxo precisa de uma resposta definida para saída incorreta ou incompleta.

Código, regras e modelos especializados

Um LLM pode acelerar a primeira implementação enquanto ainda estamos aprendendo sobre os dados e suas variações. À medida que padrões e requisitos ficam claros, parte do processamento pode ser melhor substituída por código, regras explícitas, expressões regulares ou parsers. Para classificação e previsão, algoritmos de machine learning especializados também são alternativa.

Outra opção para classificação e roteamento é um modelo de decisão System 1. Diferente de um LLM usado para gerar texto, modelos como o Jev, disponível no OpenRouter, recebem uma entrada e devolvem uma decisão estruturada, qual opção se aplica e com que confiança, em vez de prosa. Continuam sendo modelos estatísticos: saída estruturada não garante decisão correta.

O ganho precisa justificar o custo de implementação, manutenção e infraestrutura. Para um fluxo que roda poucas vezes, a migração pode nunca se pagar; em alto volume, a economia recorrente justifica o investimento. Conforme dados e padrões mudam, monitorar erros e revisar regras ou modelos passa a fazer parte desse custo.

Escalando o que precisa de mais capacidade

Retome o fluxo de notas fiscais de antes. Um parser lê os campos que um parser consegue ler: fornecedor, data, itens, total. O que ele não consegue ler vai para um modelo pequeno junto com o schema. As duas saídas passam pelas mesmas checagens: o total precisa ser igual à soma dos itens no centavo, o identificador do fornecedor precisa bater com o cadastro e a data precisa estar dentro do lote em processamento. O que falha numa checagem vai para um modelo maior com o documento e o motivo da falha. O que falha ali vai para uma pessoa, com uma explicação de uma linha. A maioria dos documentos nunca sai do parser, e a maioria do resto nunca sai do modelo pequeno.

O padrão tem nome — roteamento — e a Anthropic o descreve mandando a pergunta comum para um modelo menor e a incomum para um maior (Anthropic). No fluxo acima, o roteamento não é um julgamento sobre o quanto o documento parece difícil. São três checagens que você consegue escrever, mais um modelo validador que relê o documento e compara a resposta. Se um passo não consegue produzir uma checagem assim, você não está roteando, está adivinhando, e o palpite vai parecer bom nos casos que você por acaso vê.

Se vale a pena depende de quantos documentos cada etapa resolve. Se o parser resolve a maioria e só um punhado chega ao modelo grande, o custo médio por documento fica perto do custo do parser; se metade chega, as etapas baratas não serviram de nada. Essa proporção é mensurável numa amostra antes de você construir qualquer coisa. A pergunta mais difícil é se as escaladas foram as certas: rode a eval com a escalada desligada e compare. Se a maioria dos documentos escalados sai correta na etapa barata mesmo assim, o fluxo está pagando duas vezes pelo mesmo resultado.

Vários agentes, organizados em grafo

Outra opção é organizar o trabalho como um grafo: um nó por etapa ou papel, arestas que decidem o que roda em seguida e cada nó com seu próprio contexto, ferramentas, modelo e orçamento. Subagentes são a mesma forma sob um coordenador. Isso não substitui as técnicas acima, organiza elas, e um nó pode ser um modelo pequeno, uma regra ou um passo de escalada.

O trade-off é contexto contra coordenação. Cada agente vê menos contexto e menos ferramentas, o que dá ao modelo menos coisas para errar; etapas independentes rodam em paralelo; cada etapa pode usar o modelo que merece; e uma falha aparece na etapa que quebrou, em vez de dentro de uma conversa longa que não deu em nada. Em troca, toda aresta perde significado, porque o próximo agente recebe um resumo e não o raciocínio que o produziu, e toda passagem de bastão adiciona tokens, latência e tentativas. Coordenação traz loops e esperas travadas que nenhum teste de agente único cobre, e a eval cresce mais rápido que o número de etapas: a eval de cinco etapas não é a soma de cinco evals. Vale quando o trabalho realmente se separa em etapas, ou quando a verificação precisa de uma segunda parte que não compartilhe as instruções da primeira, como um escritor e um revisor. Quando um agente com boas ferramentas já funciona, o grafo adiciona coordenação e não remove nada.

A pergunta começa pela carga de trabalho, pelos riscos e pela taxa de sucesso exigida: qual combinação de código, modelos e validação resolve esta tarefa com qualidade e custo aceitáveis?

Autonomia exige limites proporcionais

Depois do fluxo, da sua qualidade e do seu custo vem a decisão que não pode ser medida: o que o agente pode fazer sem perguntar. Ferramentas definem o alcance de um erro. Um agente lendo uma cópia dos logs pode vazar esses logs; um agente com credenciais de produção e permissão para rodar comandos pode derrubar uma tabela. A diferença entre os dois é permissão, não um modelo melhor.

Duas coisas definem a linha: quanto dano uma ação errada causa e se esse dano pode ser desfeito. O impacto vem primeiro, porque as ações críticas são aquelas em que não existe desfazer — um pagamento, um e-mail enviado, um contrato assinado, uma exclusão sem backup. Uma cópia de logs vazada e um reembolso pago na conta errada não são o mesmo erro, digam o que disserem as permissões. A reversibilidade decide então como a barreira funciona: onde o desfazer é real, um checkpoint e um caminho de recuperação bastam; onde não é, a confirmação precisa vir antes da ação, sempre. Trabalho em lote adiciona um terceiro caso: um agente que para em 40% dos itens deixa um estado que alguém precisa reconciliar, então ele também precisa reportar quais itens terminou.

Onde a ação é crítica, a confirmação não pode ser um pedido que o modelo talvez ignore. Pedir para ele checar antes de reembolsar é um prompt, e um prompt é conselho: o modelo pode decidir que o caso é claro e seguir. A barreira precisa ficar fora do modelo, no código que executa a ação, onde a ferramenta se recusa a rodar sem um token de aprovação que o agente não consegue produzir sozinho. Aí “humano no ciclo” passa a ser uma propriedade do sistema, em vez de um comportamento que você espera, e continua valendo no dia em que o modelo está confiante e errado. Böckeler dá nome à diferença: o pedido ao modelo é um sinal inferencial, caro e não determinístico; o token conferido no código que executa a ação é computacional (Böckeler). Um portão construído com prompt é o primeiro tipo, apresentado como o segundo.

Isso também define o que a pessoa recebe: a ação, seus argumentos, a evidência que o agente usou e uma forma de rejeitar com um motivo. Um diálogo com um botão de aprovar e sem contexto treina as pessoas a clicar em aprovar, o que transforma a barreira num registro de consentimento em vez de uma checagem.

Para o cliente, nada disso aparece como modelo de permissão. Aparece como o que a ferramenta faz sozinha, o que ela pergunta antes e como se comporta depois de errar. Ninguém lê a matriz de permissões; o que fica é o primeiro erro sem supervisão.

Se o agente lê conteúdo não confiável — páginas, documentos, issues, mensagens —, parte desse conteúdo vai carregar instruções. Isso é prompt injection, e não se resolve pedindo ao modelo que ignore, porque o modelo é o que está sendo atacado. O que limita o dano é o que o agente consegue fazer depois de ser enganado: quais credenciais ele tem, quais ferramentas pode chamar e quais dessas chamadas precisam de uma pessoa. Fonte: Anthropic.

As práticas que decorrem disso são poucas:

Conceda a permissão que a tarefa precisa, não toda permissão que o conjunto de ferramentas torna conveniente.
Mantenha as credenciais para agir fora da etapa que lê entrada não confiável.
Separe leituras de escritas e dê ao agente apenas uma delas.
Exija confirmação onde a ação não pode ser desfeita.
Registre a ferramenta, os argumentos e o resultado, para que uma falha seja reconstruída em vez de discutida.

Permissões dizem o que o agente pode chamar. O que cerca a chamada decide quanto custa um erro: argumentos validados, sandbox para código, allowlist de destinos, limites de valor em dinheiro e rollback onde ele existe — escolhidos por ferramenta, e mais rígidos nas ações que não podem ser desfeitas.

Para que serve a capacidade extra

Ferramentas adequadas, validação e limites de autonomia ampliam a capacidade de um time investigar e implementar. O que essa capacidade produz depende de onde ela é aplicada.

Na maioria das empresas, ideias de produtos e features sempre superaram a capacidade de construí-las. Com tempo e pessoas limitados, só algumas ideias consideradas estratégicas avançavam; o resto esperava num backlog ou nunca era tentado.

A capacidade de gerar um protótipo ou prova de conceito rápido, muitas vezes arquivada como vibe coding, muda esse quadro. Uma ideia pode ser tornada funcional, testada e ajustada em ciclos mais curtos, então o time aprende mais cedo o que merece investimento e o que não resolve o problema, antes de comprometer pessoas numa implementação completa.

Um protótipo funcional não é um produto pronto para produção. Transformá-lo em software confiável ainda exige arquitetura, código, testes, segurança, integração, operação e manutenção. Alguém precisa definir requisitos, entender os dados, revisar mudanças e responder quando o sistema falha. Validar mais ideias também cria mais trabalho: as que se provam valiosas precisam então ser construídas, integradas e sustentadas.

É aqui que o domínio das ferramentas vira vantagem, não como substituto do julgamento de engenharia, mas como alavanca sobre ele. A oportunidade é encurtar a distância entre uma ideia e a evidência de se vale construí-la, aprender com isso e iterar. A capacidade de exploração cresce; quando a exploração produz valor, a demanda por engenharia cresce junto.

Por isso acho que empresas que fazem demissões em massa com a IA como justificativa podem estar cometendo um erro estratégico enquanto existem oportunidades de produto e o negócio consegue absorver um ritmo maior de entrega. Reduzir o time remove conhecimento e capacidade de execução exatamente quando testar mais ideias ficou mais barato. Um concorrente que mantém um time forte e aplica IA ao trabalho dele consegue tentar mais coisas e chegar ao mercado primeiro, desde que transforme a produtividade extra em software que clientes de fato querem. Produtividade que nunca sai do repositório não é vantagem.

Fechamento

O progresso em IA amplia o que um time pode investigar, implementar e operar. Ele não decide o que vale construir e não absorve as consequências quando algo falha em produção. Escolher ferramentas que sirvam ao problema, decidir o que precisa ser verificado por uma pessoa e conceder autonomia proporcional ao risco continuam sendo decisões de engenharia, e continuam pertencendo a pessoas que entendem o código, os dados e a operação.

Do meu ponto de vista, o trabalho já mudou. Ser desenvolvedor é menos sobre escrever código do que era, e cada lançamento move isso adiante: o código é o que um modelo produz mais rápido, e o que sobra para uma pessoa é o problema — qual, para quem, a que custo e se o resultado vale ser entregue. Isso não encolhe o ofício, muda o centro dele. Trabalhar assim exige uma base mais ampla que sintaxe: as ferramentas e técnicas disponíveis, os sistemas que o software toca e o domínio onde o problema vive, porque um modelo só pode ser tão útil quanto a pessoa que o dirige. O que fica para nós é a parte que nenhum modelo enquadra sozinho — notar uma oportunidade, decidir persegui-la e combinar o que sabemos em algo que não existia. É aí que a criatividade humana deixa de ser slogan e passa a ser a diferença entre uma feature e um produto.

Este artigo saiu um pouco do trilho, e eu misturei ideias que cada uma merecia um texto próprio. O que está acima é o que veio à cabeça enquanto eu escrevia, na ordem em que veio. Alguns desses assuntos — evals, harnesses, custo por tarefa, autonomia — vão voltar em artigos futuros, com mais espaço do que tiveram aqui. Espero que algo disso seja útil a quem está lendo, e nos vemos no próximo.

Referências e leituras

O que segue não é bibliografia: é a base que eu usei, e o que cada peça sustenta neste texto.

O argumento

METR, Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity e a atualização de fevereiro de 2026: os dois números da tese, e a admissão de que o instrumento deixou de medir.
Kasra Vaziri, The Verification Bottleneck: a versão para produto do mesmo diagnóstico, com METR e GitClear.
Riya Sharma, Verification is the bottleneck: um caso concreto de verificação virando feature.

O harness

Birgitta Böckeler, Harness engineering for coding agent users: o nome do modelo mental, e a distinção entre sinal computacional e inferencial que uso na seção de autonomia.
LangChain, The Anatomy of an Agent Harness: por que o mesmo modelo rende diferente sob harnesses diferentes.
OpenAI, Harness engineering: o que acontece com um time quando o gargalo vira capacidade humana de QA.
Marmelab, The State of AI Harness Engineering 2026: o único número da rodada que isola o harness do modelo.

Os limites

Anthropic, Building effective agents, Effective harnesses for long-running agents e Trustworthy agents: o que já está documentado sobre roteamento, estado e autonomia, para eu não apresentar como novidade.