Por que o Claude Code não consegue lidar com integrações

Toda equipe da Digibee usa o Claude Code. Queremos começar por aí, porque o que vem a seguir não é uma opinião de quem nunca testou essas ferramentas.

Os agentes de código mudaram a forma como nossos engenheiros trabalham, a velocidade com que prototipamos e o quanto reduzimos a carga cognitiva em tarefas rotineiras. Se a sua equipe ainda não usa um deles, está deixando um ganho real de produtividade na mesa.

Usar agentes de código significa revisar cuidadosamente o trabalho que eles produzem. E, fazendo isso, percebemos algumas limitações.

Uma das maiores? Integração.

O sucesso dos agentes de código em projetos greenfield criou a impressão de que eles podem ser aplicados a qualquer problema de software e entregar resultados. Equipes de integração estão recebendo ferramentas de IA com a orientação de acelerar o trabalho.

Mas integração corporativa não é um desafio greenfield. É uma categoria completamente diferente de trabalho, com modos de falha completamente diferentes daqueles para os quais os agentes de código foram projetados.

Passamos muito tempo entendendo as limitações dos agentes de código genéricos em trabalhos de integração e desenvolvendo soluções para superar essas limitações. Eis o que aprendemos.

Em quais trabalhos de integração os agentes de código realmente são bons

Agentes de código genéricos conseguem lidar bem com integrações dentro de um conjunto bastante restrito de condições:

• Os sistemas envolvidos são bem documentados.
• A tarefa é pontual, e não recorrente.
• Uma falha tem baixo impacto e pode ser recuperada facilmente.
• Nada em produção está em risco durante os testes.

Uma migração única de uma API REST para um CSV? Ótimo. Um script rápido para buscar dados de um endpoint público? Perfeito. Uma tarefa temporária de ETL sem dependências downstream? Vá em frente.

Os problemas começam no momento em que a integração encontra condições mais complexas. E, em ambientes corporativos, isso quase sempre acontece.

As empresas precisam de:

• Integrações que executem de forma confiável em horários programados ou em resposta a eventos em tempo real.
• Fluxos com lógica de retry e recuperação de falhas incorporadas.
• Trilhas de auditoria mostrando o que foi movimentado, quando e por quê.
• Gerenciamento de credenciais que não fique espalhado por dezenas de configurações personalizadas.
• Monitoramento capaz de identificar falhas silenciosas antes que um processo de negócio seja interrompido.
• Integrações que possam ser mantidas, transferidas e compreendidas por alguém além da pessoa que as criou.

Agentes de código não entregam nada disso. Eles entregam código. Código que muitas vezes funciona de forma brilhante, mas que precisa existir em algum lugar, ser protegido de alguma forma e ser mantido por alguém.

Em integração corporativa, ficar aquém disso gera problemas extremamente caros.

Por que essa lacuna é estrutural, e não circunstancial

Seria fácil tratar isso como uma questão de maturidade. Agentes de código são novos. Eles vão melhorar.

Mas as limitações dos agentes de código genéricos em integração decorrem de lacunas estruturais em relação ao que a integração corporativa realmente exige.

Integração depende de conhecimento acumulado e codificado em conectores prontos, desenvolvidos para lidar com detalhes como a forma como o NetSuite organiza operações, como o SAP trata idempotência ou como o Salesforce estrutura seu modelo de dados. Um agente de código precisa raciocinar sobre todas essas nuances do zero, toda vez. É aí que surgem bugs sutis que aparecem apenas em produção.

Há três pontos em que essa incompatibilidade fica mais evidente.

Agentes de código precisam entender cada sistema do zero, todas as vezes

Os sistemas que precisam ser integrados em empresas geralmente são mal documentados. Essa é a realidade de sistemas legados, contratos de dados acumulados e décadas de complexidade organizacional. Grande parte do comportamento realmente importante só aparece sob carga, e nada disso está na documentação.

Mesmo quando existe documentação, um agente de código pode simplesmente ignorá-la. Pesquisadores observaram que LLMs podem perder o contexto de informações que ficam no meio da janela de contexto. Esse fenômeno é conhecido como efeito “lost in the middle”. Quando isso acontece, o modelo passa a preencher as lacunas com base em seus dados de treinamento. Quanto mais obscuro for o pacote ou a API, maior a probabilidade de um agente gerar código incompatível com ela.

Esse problema não melhora automaticamente com o tempo. Agentes não acumulam entendimento. Eles precisam interpretar novamente sequências complexas de operações e regras de idempotência pouco óbvias sempre que executam uma nova tarefa. Além disso, o código gerado, sempre personalizado, costuma ser difícil de ler, difícil de depurar e praticamente impossível de governar de maneira consistente em todo o ambiente corporativo.

O resultado é uma categoria de bugs extremamente difícil de encontrar. Eles não quebram de forma evidente no deploy. Corrompem registros silenciosamente ou gravam transações em duplicidade em casos de borda que só aparecem quando o sistema está sob carga real.

E o CIO só descobre isso seis meses depois.

Agentes de código geram código. Integrações exigem muito mais do que isso

Integrações exigem muito mais do que código. Alguém precisa provisionar infraestrutura, garantir disponibilidade, lidar com escalabilidade, implementar lógica de retry, construir mecanismos de recuperação de falhas e criar visibilidade sobre o que acontece em produção.

Você até pode construir toda essa infraestrutura usando IA, adicionando retry, logging e outros componentes individualmente. Mas, nesse momento, você já não está apenas criando uma integração. Está criando uma integração mais cinco componentes de infraestrutura, cada um com seu próprio custo de manutenção.

Agentes de código também são otimizados para iterar rapidamente, e não para falhar com segurança. Quando uma integração falha em produção, pagamentos deixam de ser processados. Cotações de frete não acontecem. Pedidos deixam de ser enviados. Uma gravação incorreta gera impactos financeiros, reputacionais e regulatórios. Um agente que gera lógica de negócio sem logging, alertas ou circuit breakers entrega apenas metade da solução, justamente a metade mais fácil.

Depois vem o problema da manutenção. APIs mudam. Tokens expiram. Sistemas evoluem. O agente não mantém nenhum relacionamento com aquilo que construiu nem guarda memória sobre os motivos por trás das decisões tomadas. A integração passa a existir apenas na cabeça de quem escreveu o prompt. Quando essa pessoa sai da empresa, ou até entra de férias, toda a lógica por trás das decisões também vai embora.

Agentes de código não assumem responsabilidade pelo que constroem

Dívida técnica é visível. Dívida de governança não é, até que ela se transforme em uma violação de segurança, um problema de auditoria ou no último dia de trabalho de um colaborador.

Uma dimensão pouco discutida desse risco é o controle. Agentes de código genéricos geram código diretamente a partir de um prompt e dos materiais fornecidos. Não existe um artefato intermediário, nenhuma especificação, documento de mapeamento ou registro estruturado dos requisitos, casos de borda ou comportamentos esperados em caso de erro.

Isso representa uma lacuna de controle. E afeta qualquer equipe que precise entender, auditar ou modificar uma integração posteriormente.

Chaves de API, tokens OAuth e credenciais de serviços precisam ser armazenados, escopados e rotacionados corretamente. O código gerado não possui nenhuma opinião sobre isso, muito menos responsabilidade. Cada integração personalizada passa a ser um novo artefato a proteger, uma nova superfície de ataque e uma nova dependência sem um modelo claro de ownership.

Toda integração que movimenta dados entre sistemas precisa manter um registro confiável do que foi transferido, quando e por quê. Não é possível negar uma solicitação de crédito sem uma justificativa clara. Quando algo quebra, ou uma decisão de negócio é questionada, esse registro é o que permite entender o que o sistema realmente fez. Código gerado simplesmente não produz isso.

Agentes de código operando em ambientes ricos em credenciais, ou seja, praticamente qualquer ambiente corporativo de integração, têm acesso a segredos para os quais nunca foram projetados para serem confiáveis. Isso não é um argumento contra seu uso. Mas utilizá-los com segurança nesses ambientes exige integrar um sistema de gerenciamento de credenciais, ou seja, mais uma camada de infraestrutura para manter.

Escala torna tudo isso ainda pior. Uma integração criada por um agente é administrável. Cem integrações, cada uma com sua própria lógica de retry, tratamento de erros e premissas sobre credenciais, representam cem bases de código diferentes para proteger, atualizar e manter. O custo cresce continuamente.

O que as skills resolvem, e o que elas não conseguem resolver

Na Digibee usamos “skills” no Claude Code para acelerar o trabalho. Uma skill bem construída, com exemplos incorporados, casos de borda documentados e padrões validados, aumenta significativamente a eficiência de um agente em tarefas bem definidas.

Aplicar skills ao contexto de integração significaria pesquisar como cada sistema se comporta além da documentação oficial, incluindo casos de borda, limites de taxa e particularidades de versões específicas. Isso não é um trabalho único. Sistemas corporativos evoluem ao longo do tempo, exigindo manutenção constante dessas skills. O resultado seria um conjunto de instruções capaz de ajudar um agente a gerar código mais confiável para aquele sistema, embora nunca com 100% de garantia.

LLMs são probabilísticos. Uma skill bem construída aumenta as chances de sucesso, mas o código gerado ainda pode passar em todos os testes e falhar em produção, talvez de forma silenciosa. Violações de idempotência, por exemplo, normalmente não geram erros. Elas apenas acumulam gravações duplicadas até que a reconciliação falhe dias depois.

A plataforma AI-native que construímos não elimina o risco de um LLM errar, mas muda completamente onde e como esse erro aparece. O agente gera a lógica da integração sobre conectores determinísticos. Um erro resulta em uma arquitetura inadequada, algo que um especialista em integração identifica rapidamente, e não em uma interação silenciosamente incorreta com a infraestrutura principal, algo muito mais difícil de perceber.

Uma skill pode documentar como responder a uma falha. Mas não consegue detectá-la. O agente não acompanha a integração em execução. Uma plataforma acompanha, monitorando falhas silenciosas, emitindo alertas antes que problemas de reconciliação ocorram e mantendo a camada operacional funcionando continuamente.

Nossa equipe também mantém os conectores sempre atualizados. Quando o SAP altera a forma como trata idempotência, ou quando o Workday muda seu modelo de registros por data de vigência, existe uma equipe na Digibee responsável por acompanhar essas mudanças. Ela atualiza a base de código, controla versões e publica notas de atualização que documentam essas diferenças.

Uma skill é uma camada de conhecimento. O restante que integrações exigem, monitoramento em runtime, detecção de falhas e manutenção de conectores, pertence a uma categoria completamente diferente de trabalho e exige uma categoria diferente de ferramenta.

Usamos IA para reinventar a integração moderna

Nossos engenheiros identificaram essas lacunas e quiseram resolvê-las. Afinal, iniciativas corporativas de IA continuam adicionando trabalho ao backlog das equipes de integração. Por que justamente essas equipes não deveriam se beneficiar da IA?

Aplicamos anos de experiência em integração corporativa para usar LLMs da maneira que integração realmente exige. O agente continua sendo responsável por criar a lógica da integração, gerando mapeamentos e fluxos de negócio a partir de um prompt, rapidamente. Mas ele gera tudo isso sobre conectores validados e determinísticos. Depois de construída, a integração é executada sobre uma infraestrutura gerenciada que fornece retry, alertas e rotação de credenciais por padrão, além de produzir um artefato estruturado que funciona como trilha de auditoria.

Mantivemos toda essa experiência dentro do nosso próprio ecossistema. Poderíamos ter desenvolvido MCPs para agentes de código externos, mas preferimos oferecer aos nossos usuários uma experiência consistente e orientada. Na nossa abordagem AI-native, usuário e IA desenvolvem juntos um documento de especificação que busca entender tanto os requisitos atuais quanto os futuros do fluxo de trabalho antes que qualquer desenvolvimento comece.

É isso que AI-native significa na prática: o agente mantém tudo aquilo que o torna rápido; a plataforma assume toda a responsabilidade necessária para tornar a integração confiável.

Conclusão

Nós gostamos de agentes de código. Este não é um argumento para deixar de usá-los. É um argumento em favor de clareza sobre suas limitações em uma aplicação muito específica: integração.

Agentes de código continuarão apresentando limitações em integrações recorrentes, críticas e em escala corporativa. Não porque a tecnologia não seja impressionante, mas porque o problema simplesmente não corresponde à ferramenta.

Dizer às equipes de integração para acelerarem usando IA, sem considerar essa lacuna estrutural, significa colocá-las no caminho de construir algo que parece funcionar. Até que deixe de funcionar.

Nós construímos uma abordagem diferente. Se você é responsável pela infraestrutura de integração e quer ver na prática como funciona uma plataforma AI-native, teremos prazer em mostrar.

[Tenha acesso antecipado à primeira plataforma de integração AI-native →]