Todas as equipes da Digibee usam Claude Code. Queremos começar por aí, porque o que vem a seguir não é uma opinião de quem nunca experimentou essas ferramentas.

Agentes de código mudaram a forma como nossos engenheiros trabalham, a velocidade com que criamos protótipos e o esforço mental gasto em tarefas rotineiras. Se suas equipes ainda não usam um, estão deixando ganhos reais de produtividade na mesa.

Usar agentes de código também significa revisar cuidadosamente o trabalho que eles produzem. E, nesse processo, vimos suas limitações.

Uma das principais? Integração.

O sucesso dos agentes de código no desenvolvimento greenfield criou a percepção de que eles podem ser direcionados a qualquer problema de software e entregar resultados. Equipes de integração estão recebendo ferramentas de IA e sendo pressionadas a ganhar velocidade.

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

Passamos bastante tempo entendendo as limitações dos agentes de código generalistas em trabalhos de integração e desenvolvendo soluções para essas lacunas. Aqui está o que aprendemos.

No que agentes de código realmente são bons quando o assunto é integração

Agentes de código generalistas conseguem lidar bem com integrações em um conjunto restrito de condições:

• Os sistemas envolvidos têm boa documentação.
• A tarefa é pontual, e não recorrente.
• Uma eventual falha tem baixo impacto e pode ser revertida.
• Nada em produção corre risco durante os testes.

Uma migração pontual de uma API REST para CSV? Ótimo. Um script rápido para extrair dados de um endpoint público? Perfeito. Uma tarefa de ETL descartável, sem dependências posteriores? Pode funcionar muito bem.

Os problemas começam quando a integração enfrenta condições mais complexas. E, em integrações corporativas, isso quase sempre acontece.

Empresas precisam de:

• Integrações executadas de forma confiável, de acordo com uma programação ou em resposta a triggers em tempo real.
• Workflows com lógica de retry e recuperação de falhas integradas.
• Trilhas de auditoria que mostrem o que foi movimentado, quando e por quê.
• Gerenciamento de credenciais que não se espalhe 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 outras pessoas além de quem as construiu.

Agentes de código não entregam nada disso. Eles entregam código. Muitas vezes, um código que funciona muito bem, mas que precisa rodar em algum lugar, ser protegido de alguma forma e mantido por alguém.

Em integração corporativa, não atender a esses requisitos pode gerar problemas muito 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 generalistas em integrações vêm de lacunas estruturais em relação ao que a integração corporativa exige.

Integrações dependem de conhecimento acumulado e incorporado a conectores pré-construídos, desenvolvidos considerando como o NetSuite sequencia operações, como o SAP lida com idempotência e como o Salesforce estrutura seu modelo de dados. Um agente de código precisa raciocinar sobre cada uma dessas particularidades do zero, todas as vezes. É assim que surgem bugs sutis que aparecem apenas em produção.

Há três áreas em que essa incompatibilidade fica especialmente evidente.

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

Os sistemas envolvidos em integrações corporativas muitas vezes têm documentação limitada. Essa é a realidade de sistemas legados, contratos de dados acumulados ao longo do tempo e décadas de complexidade organizacional. Grande parte do comportamento que realmente importa só aparece sob carga, e nada disso está na especificação.

Mesmo quando a documentação existe, um agente de código pode ignorar partes dela. Pesquisadores observaram que LLMs podem perder informações localizadas no meio de suas janelas de contexto. Esse fenômeno é chamado de “lost in the middle”. Quando isso acontece, o modelo recorre aos dados usados em seu treinamento. Quanto menos conhecido for o pacote ou a API, maior a probabilidade de um agente de código gerar um código que falhe ao interagir com ele.

Esse problema não desaparece automaticamente com o tempo. Agentes não acumulam conhecimento sobre o sistema. Eles precisam interpretar novamente lógicas complexas de sequenciamento e regras pouco óbvias de idempotência a cada execução. Além disso, o código sempre personalizado pode ser difícil de entender, depurar e governar de maneira consistente em toda a empresa.

O resultado é uma categoria de bugs difíceis de identificar. Eles não causam uma falha evidente no momento do deploy. Em vez disso, podem corromper registros silenciosamente ou duplicar transações em casos extremos que só aparecem quando o sistema está operando sob carga real.

E o CIO só fica sabendo seis meses depois.

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

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

Você pode usar vibe coding para resolver individualmente a lógica de retry, logging e outras lacunas. Mas, nesse ponto, está construindo uma integração e mais cinco componentes de infraestrutura, cada um com sua própria necessidade de manutenção.

Agentes de código também são otimizados para iterar rapidamente, não para falhar com segurança. Uma integração que falha em produção significa pagamentos que não são processados, cotações de frete que não são realizadas e pedidos que não são enviados. Uma gravação incorreta pode trazer consequências financeiras, reputacionais e regulatórias. 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.

E ainda existe o problema da manutenção. APIs mudam. Tokens expiram. Sistemas são atualizados. Um agente não mantém uma relação com aquilo que construiu e não tem memória dos motivos por trás das decisões tomadas. A integração fica na cabeça de quem escreveu o prompt. Quando essa pessoa sai, mesmo que seja apenas de férias, o contexto por trás de cada decisão de arquitetura vai junto.

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é se transformar em uma violação de segurança, um problema de auditoria ou aparecer no último dia de um funcionário na empresa.

Uma dimensão pouco considerada desse risco é o controle. Agentes de código generalistas geram código diretamente a partir de um prompt e dos materiais fornecidos. Não existe um artefato intermediário, como uma especificação, um documento de mapeamento ou um registro estruturado de requisitos, edge cases e comportamento em caso de erro.

Essa é uma lacuna de controle. E afeta qualquer equipe que precise entender, auditar ou alterar uma integração posteriormente.

Chaves de API, tokens OAuth e credenciais de serviço precisam ser armazenados, ter seu escopo definido e ser rotacionados corretamente. O código gerado não assume responsabilidade por nada disso. Cada integração personalizada representa um novo artefato a ser protegido, uma nova superfície de ataque e uma nova dependência sem um modelo claro de responsabilidade.

Qualquer integração que movimente dados entre sistemas precisa manter um registro confiável do que foi movimentado, quando e por quê. Você não pode negar uma solicitação de empréstimo sem uma justificativa clara. Quando algo falha ou uma decisão de negócio é questionada, esse registro permite entender o que o sistema realmente fez. Código gerado, por si só, não produz esse registro.

Agentes de código operando em ambientes repletos de credenciais, como acontece em qualquer ambiente corporativo de integração, têm acesso a segredos para os quais não foram projetados para serem confiáveis. Isso não significa que agentes de código não devam ser usados. Mas usá-los com segurança nesses ambientes exige integrar o gerenciamento de credenciais, ou seja, mais um componente de infraestrutura para manter.

A escala agrava o problema. Uma integração criada por um agente de código é administrável. Cem delas, cada uma com sua própria lógica de retry, tratamento de erros e premissas sobre credenciais, representam cem bases de código que precisam ser protegidas, atualizadas e mantidas. O custo se acumula.

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

Na Digibee, usamos “skills” no Claude Code para acelerar nosso trabalho. Uma skill bem construída, com exemplos incorporados, edge cases documentados e padrões validados, aumenta a eficácia do agente em tarefas bem definidas.

Aplicar skills à integração significaria pesquisar como cada sistema se comporta além do que está documentado, incluindo edge cases, rate limits e particularidades de cada versão. Esse não é um trabalho pontual. Sistemas corporativos mudam com o tempo, o que exige manter e evoluir a skill junto com eles. As instruções resultantes ajudariam o agente a produzir código mais confiável para aquele sistema, mas não 100%.

LLMs têm comportamento probabilístico. Uma skill bem construída aumenta as chances de sucesso, mas o código produzido pode passar nos testes e ainda falhar em produção, talvez silenciosamente. Violações de idempotência, por exemplo, não geram erros. Gravações duplicadas se acumulam até que a reconciliação falhe dias depois.

A plataforma AI-native que construímos não elimina o risco de uma LLM cometer um erro, mas muda onde e como esse erro aparece. O agente gera a lógica de integração usando conectores determinísticos. Um caminho incorreto resulta em uma arquitetura inadequada, algo que um especialista em integração consegue identificar facilmente, e não em uma interação silenciosamente quebrada com a infraestrutura central, algo muito mais difícil de detectar.

Uma skill pode documentar como responder a uma falha, mas não consegue perceber quando ela acontece. O agente não permanece em execução junto com a integração. Uma plataforma, sim: monitora falhas silenciosas, envia alertas antes que a reconciliação seja comprometida e mantém a camada operacional funcionando entre cada build.

Nossa equipe também mantém os conectores atualizados. Quando o SAP muda a forma como trata idempotência ou o Workday altera sua abordagem para registros com data de vigência, é responsabilidade de alguém na Digibee acompanhar essas mudanças. A equipe atualiza a base de código, com versionamento e release notes que documentam as alterações.

Uma skill é uma camada de conhecimento. Integrações também exigem monitoramento em runtime, detecção de falhas e manutenção de conectores. Essa é outra categoria de trabalho e exige outra categoria 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 aumentando o backlog das equipes de integração. Por que essas equipes também não deveriam se beneficiar da IA?

Aplicamos anos de experiência em integração corporativa para usar LLMs de acordo com o que integrações realmente exigem. O agente continua responsável por criar a lógica da integração, gerando mapeamentos e fluxos de negócio a partir de um prompt, com velocidade, mas faz isso utilizando conectores determinísticos e validados.

Depois de construído, o workflow roda em uma infraestrutura gerenciada que oferece retry, alertas e rotação de credenciais desde a sua concepção, além de produzir um artefato estruturado que funciona como trilha de auditoria.

Mantivemos toda essa interação dentro do nosso ecossistema. Poderíamos ter criado MCPs para uso com agentes de código externos, mas queríamos oferecer aos usuários uma experiência consistente e orientada. Em nossa interface AI-native, usuário e IA desenvolvem juntos um documento de especificação para compreender os requisitos atuais e futuros do workflow antes mesmo do início da construção.

É isso que AI-native significa na prática: o agente mantém aquilo que o torna rápido, enquanto a plataforma cuida de tudo o que é necessário para tornar a integração confiável.

O ponto principal

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

Agentes de código continuarão encontrando limitações em integrações recorrentes, high-stakes e em escala corporativa. Não porque a tecnologia não seja impressionante, mas porque o problema não corresponde à ferramenta.

Pedir que suas equipes de integração ganhem velocidade com IA sem considerar essa lacuna estrutural é colocá-las em uma posição em que constroem algo que parece funcionar. Até deixar de funcionar.

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

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

‍