O IBM Bob passa para dentro do firewall, e é exatamente esse o ponto

A IBM começou a oferecer sua plataforma agêntica de desenvolvimento de software, o IBM Bob, em formato auto-hospedado. Implantações on-premises, em nuvem privada, em nuvem soberana e em ambientes air-gapped estão todas no menu. Os clientes escolhem sua própria configuração de modelo, mantêm o código-fonte e o contexto da aplicação dentro da própria rede e conservam o controle sobre residência de dados e políticas de segurança.

Isso soa como uma nota de rodapé sobre implantação. Está mais para uma tese sobre quem tem direito de usar agentes de programação.

A lacuna que a auto-hospedagem fecha

Os agentes de programação avançaram rápido. Eles leem um repositório, propõem mudanças, rodam testes e abrem pull requests. Para uma startup, conectar um deles a um serviço de nuvem é coisa de uma tarde de terça-feira. Para uma empreiteira de defesa, um banco ou um sistema hospitalar, o mesmo movimento morre na primeira revisão jurídica. O código-fonte não pode sair do prédio. O contexto interno, o conhecimento institucional bagunçado que torna um código compreensível, também não. Ambientes air-gapped não têm caminho para a nuvem, por design.

Isso deixa uma fatia grande da economia assistindo à era dos agentes atrás de um vidro. A IBM está vendendo para essa fatia, e não é a primeira. A categoria é pequena hoje, principalmente porque agentes auto-hospedados exigem pesos de modelo, hardware e uma camada de orquestração que um fornecedor de nuvem normalmente proveria. A empresa que resolver a encanação ganha uma base de clientes que os laboratórios API-first não conseguem alcançar.

Por que isso é mais difícil do que parece

Um agente é mais fácil de entender como um loop do que como uma coisa única: planejar, agir, observar, ajustar. Na nuvem, as ferramentas que ele chama são serviços, e os modos de falha são problema de outra pessoa. Atrás de um firewall, o agente precisa alcançar os mesmos repositórios, os mesmos sistemas de tickets, os mesmos sistemas de build, só que agora a rede é segmentada, as credenciais são rotacionadas em um cronograma e metade dos serviços foi atualizada pela última vez antes de a palavra "agente" significar alguma coisa.

O pitch da IBM se apoia no fato de que ela já vende para esses ambientes. Seus clientes operam mainframes e sistemas legados que ninguém mais quer tocar. Fazer um agente funcionar ali é pouco glamouroso, lento e exatamente o tipo de trabalho que cria um fosso competitivo.

Há também uma questão de governança, e é a que não para de aparecer. Um agente auto-hospedado produz logs que são seus. Em uma auditoria regulatória, você consegue mostrar exatamente qual modelo rodou, o que ele leu e o que ele mudou. Em uma configuração de nuvem, essa evidência fica espalhada entre o console de um fornecedor e um contrato de serviço. Quando algo dá errado, a diferença entre "temos os logs" e "solicitamos os logs" é a diferença entre um incidente encerrado e um trimestre de discovery.

A questão do modelo por baixo

Auto-hospedar um agente significa auto-hospedar um modelo, ou pelo menos escolher um que você possa colocar no seu próprio silício. A IBM permite que os clientes selecionem configurações suportadas, o que na prática significa uma mistura de modelos de pesos abertos e modelos da própria IBM. As opções de pesos abertos importam aqui. Um modelo de classe 70B rodando em um cluster privado é mais lento e menos capaz do que o melhor modelo hospedado. Ele também está disponível quando a rede cai, quando o fornecedor aumenta os preços ou quando o fornecedor decide que seu caso de uso viola uma política que você nunca leu.

As empresas fazem essa troca há uma década com bancos de dados, e o resultado é o mesmo: elas aceitam uma lacuna de capacidade em troca de controle e depois fecham essa lacuna com o tempo, conforme o hardware melhora.

A economia parece diferente atrás de um firewall

Agentes de programação em nuvem são cobrados por token, o que significa que o custo escala com quanto código o agente lê e escreve. Para uma startup, isso é uma linha previsível no orçamento. Para uma grande empresa, onde um único repositório pode conter décadas de histórico e o agente precisa absorver muito mais contexto antes de poder ajudar, o medidor dispara.

A auto-hospedagem inverte o modelo. O custo passa a ser hardware e operações, despesas de capital que a organização já carrega. Um banco com data center não paga mais quando o agente lê outro milhão de linhas. O custo marginal de uma tarefa adicional do agente se aproxima da eletricidade e do tempo de GPU, e esses já estão afundados. Essa assimetria é o motivo pelo qual o pitch auto-hospedado funciona mesmo quando o produto em nuvem é objetivamente melhor.

Há, porém, um custo de conformidade que o marketing pula. A auto-hospedagem transfere ao cliente o ônus de aplicar patches, monitorar e atualizar modelos. Um fornecedor de nuvem empurra uma correção e pronto. Uma implantação on-premises precisa agendar a atualização, testá-la contra os sistemas internos e sobreviver a um comitê de controle de mudanças. A ferramenta é mais controlável e dá mais trabalho, e essa troca é a história inteira do software corporativo.

O mercado adjacente que torna isso viável

Auto-hospedar um agente só funciona se houver algo que valha a pena rodar atrás do muro, e essa oferta cresceu. Modelos de pesos abertos na faixa capaz de fazer trabalho real de programação agora são comuns, lançados sob licenças permissivas por laboratórios em vários continentes. A peça que faltava nunca foi o modelo. Era o arnês que transforma um modelo em algo ao qual um desenvolvedor pode delegar dentro de uma rede controlada.

Essa é a camada que a IBM está vendendo. Treinar o melhor modelo não é o objetivo. Ser a integração que torna um modelo existente utilizável nos lugares onde uma chamada à nuvem não é uma opção é o objetivo. A estratégia é a imagem espelhada dos laboratórios API-first. Eles empurram capacidade para fora e deixam qualquer um se conectar. A IBM puxa capacidade para dentro e faz com que ela sobreviva ao perímetro.

Para compradores presos nesse perímetro, a escolha tem sido desagradável por dois anos: assistir à onda dos agentes de longe ou quebrar uma regra de segurança para entrar nela. Uma opção auto-hospedada não torna a onda menor. Só a torna alcançável, o que, para uma organização regulada, é a mesma coisa que torná-la real.

O que observar

Demos não são a pergunta honesta sobre programação agêntica auto-hospedada. A pergunta honesta é se os resultados se sustentam em um código com quinze anos de dívida técnica, escrito por pessoas que já deixaram a empresa. Agentes em nuvem também sofrem com isso. A diferença é que um agente auto-hospedado não pode ser melhorado pelo fornecedor da noite para o dia sem que o cliente faça o trabalho. Cada ganho precisa ser conquistado pela própria equipe do cliente.

Isso torna a adoção mais lenta e mais pegajosa, o que convém à IBM. Ela está construindo para compradores que medem sucesso em anos, não em sprints, e que preferem possuir uma ferramenta um pouco pior do que alugar uma melhor que não podem inspecionar. Para um mercado de agentes de programação que passou dois anos perseguindo benchmarks, essa é uma aposta conservadora. Também é uma aposta na parte do mercado que ainda não foi atendida.

Existe uma versão disso que termina mal. Ferramentas auto-hospedadas têm reputação de serem lançadas uma vez e depois definharem, porque o fornecedor não tem um incentivo recorrente para melhorá-las e o cliente não tem poder de barganha para exigi-lo. Se o IBM Bob se acomodar em um produto estável que nunca melhora de forma significativa, os compradores que ele atrai receberão exatamente o que pediram e menos do que esperavam. A alternativa, em que um agente auto-hospedado melhora em um cronograma controlado pelo cliente, é mais difícil de operar e muito mais valiosa. Qual das duas a IBM entrega é o que se deve observar no próximo ano.