Testamos o Claude Opus 5.5 na criação de fluxos de integração. Fornecemos uma especificação e a documentação necessária e deixamos o modelo executar a tarefa.

Em uma das métricas, o Opus alcançou um resultado muito próximo ao do nosso novo skeleton builder, que utiliza principalmente os modelos Sonnet e Haiku (0,72 contra 0,70). Mas essa métrica, baseada na avaliação de um LLM, tem suas limitações. Ao analisar os resultados de forma mais ampla, identificamos que dois dos 21 fluxos gerados pelo Opus apresentaram esquemas inválidos. O modelo também cometeu o dobro de erros de fluxo de dados, levou quase três vezes mais tempo por caso e custou quase sete vezes mais do que nosso sistema.

O Opus é um modelo horizontal, desenvolvido para atender a diferentes tipos de tarefas. Já o skeleton builder é um sistema vertical, que combina modelos horizontais com o conhecimento que acumulamos sobre integração. Esse sistema, que substituiu um módulo anterior, aumentou de 78% para 96,8% a proporção de fluxos gerados que atendem aos nossos critérios de aceitação, ao mesmo tempo que reduziu o tempo de construção em 69% e os custos em 72%.

O desenvolvimento desse sistema vertical de IA exigiu centenas de experimentos, mais de 350 execuções em lote ao longo de quase 90 revisões do builder e semanas de trabalho para entender onde um LLM realmente agrega valor ao nosso domínio e onde seu uso apenas aumenta os custos.

Horizontal e vertical

A IA horizontal é impulsionada pelos fornecedores de modelos e pelas plataformas de uso geral, como Google, Anthropic, OpenAI, outros participantes do mercado e a comunidade de modelos com pesos abertos. Seu objetivo é atender a uma ampla variedade de necessidades. Um mesmo modelo precisa raciocinar sobre legislação tributária, Python e poesia usando os mesmos parâmetros. A cada nova geração, esses modelos elevam o nível mínimo de capacidade disponível para todos.

A IA vertical é desenvolvida por empresas que incorporam esses modelos a sistemas construídos com conhecimento especializado de determinado domínio. Isso proporciona eficiência e confiabilidade, não necessariamente uma capacidade maior do modelo em si. Essas empresas identificam quais decisões exigem julgamento e quais podem ser resolvidas mecanicamente. Também aprendem quais erros passam despercebidos pelos validadores da plataforma e quais aspectos do ambiente de execução nunca foram documentados.

A Bessemer Venture Partners considera a IA vertical uma oportunidade ainda maior do que o SaaS vertical. Dois de seus dez princípios estão diretamente alinhados à nossa experiência.

O oitavo princípio afirma que a vantagem competitiva depende de "combinar diferentes tipos de dados e integrações de fluxos de trabalho, e não apenas de modelos proprietários".

O nono recomenda desenvolver sistemas capazes de "incorporar de forma flexível os melhores modelos à medida que a IA evolui".

Esse último princípio se aplica diretamente à nossa abordagem. Podemos substituir os modelos utilizados na maioria dos componentes conforme a necessidade, e já fizemos isso. Uma versão anterior do nosso sistema utilizava o Claude Sonnet 4.6 para construir fluxos e o Haiku 4.5 para testá-los. Hoje, utilizamos o Sonnet 5.5 e o Haiku 5.5. Essa flexibilidade nos permite escolher o modelo mais eficiente para cada tarefa.

Um bom modelo pode resolver o problema, mas de forma ineficiente

Um bom modelo consegue resolver uma parcela significativa da maioria dos problemas. No entanto, tende a fazer isso de forma ineficiente e com menor confiabilidade à medida que as tarefas se tornam mais longas, como apontam os estudos CompWoB e TheAgentCompany. O problema não está necessariamente na capacidade dos LLMs de resolver etapas individuais, mas no tamanho do espaço de possibilidades. Quanto mais etapas uma tarefa envolve, mais decisões um agente precisa acertar. E um agente de uso geral dispõe de poucos recursos para restringir essas possibilidades.

A comunidade de pesquisa já começou a mensurar esse problema.

Agentes podem custar mais sem oferecer ganhos de precisão. No estudo AI Agents That Matter, pesquisadores de Princeton mostram que, no benchmark HumanEval, diversas arquiteturas de agentes de última geração não apresentam vantagens significativas de precisão em relação a abordagens básicas mais simples, apesar de terem custos de inferência consideravelmente maiores.

Um pipeline fixo pode superar um agente. O Agentless substituiu um agente autônomo de programação por um pipeline fixo que primeiro localiza o problema e depois executa a correção. A abordagem resolveu 32% dos problemas do SWE-bench Lite, um desempenho comparável ao das melhores soluções, frequentemente por uma fração do custo.

Os próprios fornecedores reconhecem isso. No guia Building effective agents, a Anthropic recomenda fluxos de trabalho predefinidos quando uma tarefa é bem compreendida. A empresa também alerta que sistemas agênticos oferecem mais flexibilidade, mas aumentam a latência e os custos.

O teste: um modelo de ponta, com (quase) nada do nosso sistema

Em outubro, testamos o Claude Opus 5.5, modelo de ponta da Anthropic, como um agente de uso geral por meio do Claude Agent SDK, utilizando os 21 casos do nosso principal conjunto de dados.

Fornecemos ao Opus o que um engenheiro capacitado teria à disposição: a especificação, a documentação dos conectores e as mesmas ferramentas de validação e teste utilizadas pelos nossos builders. O modelo podia realizar até 80 interações para construir os fluxos, mas sem acesso ao nosso planejador, aos normalizadores, à análise estática do fluxo de dados ou a uma definição clara dos critérios de conclusão.

Avaliamos o Opus da mesma forma que o skeleton builder, considerando diferentes fatores, incluindo a pontuação média atribuída por três LLMs avaliadores independentes. Segundo essas avaliações, o desempenho do Opus foi praticamente equivalente ao do skeleton builder, mas ficou atrás em todos os outros aspectos.

O principal resultado desse experimento foi que o Opus custou 6,8 vezes mais e levou 2,9 vezes mais tempo do que nosso builder, mesmo apresentando desempenho inferior. Ele gerou esquemas inválidos em dois dos 21 casos e cometeu o dobro de erros de fluxo de dados, como referências a campos inexistentes. O modelo chegou a executar testes, mas sobre partes modificadas dos pipelines, e não sobre os pipelines efetivamente entregues. Por isso, esses testes não permitem confirmar se os fluxos finais funcionariam. O experimento consistiu em uma execução com 21 casos, e nossa variação entre execuções é de aproximadamente um caso. Portanto, a diferença de 0,02 na avaliação dos LLMs deve ser interpretada como um empate.

De onde vieram os ganhos de eficiência

Nosso skeleton builder passou por várias fases de desenvolvimento. A maior parte dos ganhos veio de decisões que só fazem sentido quando se conhece profundamente o domínio.

Priorizar código em vez de prompts para tarefas mecânicas. Instruções em prompts não conseguiram corrigir falhas estruturais. Já normalizadores, sanitizadores e verificações de aceitação implementados em código funcionaram de maneira consistente. Estabelecemos uma regra simples: se uma verificação pode ser expressa em código, ela não deve depender de um prompt.

Organizar o trabalho de acordo com as dependências dos dados. Os erros de fluxo de dados eram nossa maior fonte de falhas: etapas que tentavam acessar campos substituídos por etapas anteriores ou que nunca haviam sido produzidos. Agora, preenchemos primeiro as etapas que produzem os dados e depois aquelas que os consomem, em grupos organizados conforme suas dependências. Isso reduziu em 65% os erros no preenchimento inicial.

Utilizar feedback externo, em vez de depender da autocorreção. Pesquisas do Google DeepMind mostram que os modelos têm dificuldade para corrigir o próprio raciocínio sem sinais externos. Nosso builder utiliza a validação da plataforma, a análise estática do fluxo de dados e testes instrumentados no mecanismo de execução. Correções geradas por LLMs só são aceitas quando essas verificações determinísticas não identificam regressões.

Selecionar modelos conforme a complexidade da tarefa. Depois que a arquitetura tornou mecânico o preenchimento de cada etapa, a substituição do Sonnet pelo Haiku reduziu os custos em mais 39%, sem perda mensurável de qualidade. Por outro lado, utilizar o Haiku para correções ou atribuição de credenciais dobrou o número de falhas do builder. Isso está alinhado às conclusões do FrugalGPT, de Stanford, mas nossos resultados acrescentam uma condição importante: o direcionamento de tarefas para diferentes modelos gera benefícios quando a engenharia especializada no domínio já tornou essas tarefas suficientemente previsíveis.

A especialização deixou de estar nos parâmetros dos modelos e passou para o sistema

Houve um período em que especialização em um domínio significava treinar um modelo específico para ele. A Bloomberg treinou o BloombergGPT com dados financeiros. Alguns meses depois, um estudo apresentado na EMNLP constatou que o GPT-4, um modelo de uso geral, superava o BloombergGPT em quatro dos cinco benchmarks financeiros avaliados. O trabalho da Microsoft com o Medprompt demonstrou algo semelhante na medicina: o uso cuidadoso de prompts e da orquestração permitiu que um modelo generalista superasse modelos ajustados especificamente para aquele domínio.

A conclusão não é que o conhecimento especializado deixou de importar. Ele apenas mudou de lugar. Agora, está presente no que Andrej Karpathy descreve como uma camada cada vez mais robusta de software responsável por coordenar chamadas individuais a LLMs: quais informações entram em cada contexto, em que ordem, sob quais restrições e como cada resultado é verificado. É nessa camada que uma empresa especializada em determinado domínio constrói sua vantagem competitiva.

É também onde fica o conhecimento mais difícil de adquirir. Grande parte do comportamento de uma plataforma não está documentada e, portanto, não faz parte dos dados de treinamento de nenhum modelo. O que uma etapa retorna quando falha, mas o fluxo continua em execução? O que um template escreve quando um campo não existe? Executar um pipeline mínimo no mecanismo real permite responder a cada uma dessas perguntas em poucos minutos.

Uma dessas descobertas, por si só, mudou nosso builder. Por padrão, uma transformação que falha não interrompe o fluxo. Por isso, uma verificação de duplicidade que havia falhado silenciosamente estava direcionando todos os registros para o caminho de "criação", e nossos testes continuavam passando. Nenhum dos LLMs avaliadores identificou o problema, porque nenhum deles conhecia o comportamento do mecanismo de execução. Quando a documentação não oferece a resposta, um experimento é a única fonte confiável de informação.

A experimentação é parte do produto

As centenas de experimentos que realizamos não foram trabalho adicional desnecessário. Elas foram parte essencial do processo de engenharia e nos permitiram descobrir quais premissas estavam erradas, quais abordagens realmente funcionavam e, surpreendentemente, em quantas situações nossos próprios instrumentos de medição estavam nos levando a conclusões equivocadas.

Ao longo do projeto, encontramos mais de vinte problemas nesses instrumentos:

• Contagens de tokens que consideravam apenas um dos modelos.

• Ausência de informações de preço para modelos recém-lançados.

• Um LLM avaliador cujos critérios de avaliação mudaram no meio do estudo.

• Denominadores de métricas que favoreciam sistematicamente um dos builders.

Muitas dessas descobertas eram sutis. Nossa taxa de aprovação nos testes considerava apenas os casos que chegavam à etapa de testes. Isso significava que as falhas mais graves de um builder, aquelas que nem sequer passavam pela validação, não entravam no cálculo da média. Como a versão anterior do nosso builder falhava mais cedo, essa métrica fazia seu desempenho parecer melhor do que realmente era.

Os LLMs avaliadores também se mostraram insuficientes para detectar falhas mecânicas. Um pipeline com uma etapa de deduplicação defeituosa recebeu a mesma pontuação que sua versão corrigida.

Cada domínio tem seus próprios tipos de falha, fontes de ruído e pontos cegos nas medições. Identificá-los exige experimentação contínua com casos reais, conhecimento especializado e julgamento de engenharia para distinguir melhorias genuínas de distorções provocadas pelos instrumentos de avaliação.

A experimentação não é apenas a forma como avaliamos o produto. Ela faz parte de como o construímos.

Por que não deixar um agente fazer a otimização?

Uma objeção natural seria: se o problema é o tamanho do espaço de possibilidades, por que não automatizar a busca? Poderíamos deixar um otimizador, ou um meta-agente, testar diferentes configurações até encontrar a melhor.

Mas os números não fecham. Escolher qual dos cinco modelos utilizar em cada uma das seis fases do nosso builder, por exemplo, significaria testar 15.625 configurações. E isso antes mesmo de alterar um único prompt, critério de validação, modo de documentação ou política de novas tentativas.

Uma avaliação completa dos nossos dois conjuntos de dados custa aproximadamente US$ 30. A variação entre execuções é de cerca de um caso por execução, o que significa que precisamos de pelo menos cinco repetições por configuração para distinguir diferenças reais de variações aleatórias. Testar exaustivamente apenas essa dimensão custaria cerca de US$ 2,3 milhões. Estratégias de busca mais inteligentes poderiam reduzir esse custo, mas não o suficiente. Além disso, os testes continuariam otimizando o sistema com base em instrumentos de avaliação que, posteriormente, descobrimos apresentar falhas.

Pesquisas recentes apontam na mesma direção.

O desenvolvimento automatizado de agentes é caro. O estudo Automated Design of Agentic Systems (2025) relata que uma única busca realizada por um meta-agente custa centenas de dólares, mesmo em benchmarks acadêmicos de pequena escala.

O investimento raramente se paga. Um estudo posterior, Inefficiencies of Meta Agents for Agent Design, constatou que o custo de desenvolver um agente dessa forma foi recuperado em apenas dois conjuntos de dados, e somente após sua utilização em mais de 15 mil exemplos. Em todos os outros conjuntos, os ganhos nunca foram suficientes para compensar o custo de desenvolvimento, independentemente da escala.

É o conhecimento especializado que reduz o espaço de busca. Uma única execução com o Haiku revelou erros em funções aninhadas que um modelo pequeno não conseguia corrigir. Um engenheiro que conhecia a plataforma entendeu o motivo, e seguimos em frente. Uma busca combinatória precisa de conhecimento prévio para orientar suas escolhas. Em um domínio vertical, esse conhecimento vem da experiência especializada.

O que isso significa

Para as empresas que estão adotando IA, o acesso a modelos cada vez mais capazes e baratos se tornará algo comum. O diferencial estará na eficiência com que esses modelos são aplicados a problemas reais de negócio.

Isso exige conhecimento profundo do domínio, integração com fluxos de trabalho reais, validação confiável e experimentação contínua e disciplinada.

Essas práticas não são soluções temporárias enquanto esperamos por modelos melhores. São recursos de engenharia que transformam a inteligência de uso geral em resultados de negócio confiáveis.

Conheça a primeira plataforma de integração AI-native →