IBM Bob entra nel firewall, e questo è il punto

IBM ha iniziato a offrire la sua piattaforma agentica di sviluppo software, IBM Bob, in forma self-hosted. Deployment on-premises, cloud privato, sovereign cloud e air-gapped sono tutte opzioni disponibili. I clienti scelgono la propria configurazione dei modelli, mantengono il codice sorgente e il contesto applicativo all'interno della propria rete e conservano il controllo su data residency e policy di sicurezza.

Sembra una nota a piè di pagina sul deployment. In realtà è più vicino a una tesi su chi può usare gli agenti di coding, e chi no.

Il divario che il self-hosting colma

Gli agenti di coding si sono mossi in fretta. Leggono un repository, propongono modifiche, eseguono test e aprono pull request. Per una startup, collegarne uno a un servizio cloud è un pomeriggio di martedì. Per un appaltatore della difesa, una banca o un sistema ospedaliero, la stessa mossa fallisce alla prima revisione legale. Il codice sorgente non può uscire dall'edificio. Anche il contesto interno, quella conoscenza istituzionale disordinata che rende comprensibile una base di codice, non può uscire. Gli ambienti air-gapped non hanno alcun percorso verso il cloud, per progettazione.

Questo lascia una larga fetta dell'economia a guardare l'era degli agenti da dietro un vetro. IBM sta vendendo a quella fetta, e non è la prima. La categoria oggi è piccola, soprattutto perché gli agenti self-hosted richiedono pesi dei modelli, hardware e un livello di orchestrazione che normalmente fornirebbe un vendor cloud. L'azienda che risolve l'idraulica si aggiudica una base di clienti che i laboratori API-first non riescono a raggiungere.

Perché è più difficile di quanto sembri

Un agente è più facile da capire come un ciclo che come una cosa singola: pianificare, agire, osservare, correggere. Nel cloud, gli strumenti che chiama sono servizi, e le modalità di fallimento sono un problema di qualcun altro. Dietro un firewall, l'agente deve raggiungere gli stessi repository, gli stessi sistemi di ticketing, gli stessi sistemi di build, solo che ora la rete è segmentata, le credenziali vengono ruotate secondo una pianificazione e metà dei servizi è stata aggiornata l'ultima volta prima che la parola «agente» significasse qualcosa.

La proposta di IBM si basa sul fatto che vende già in questi ambienti. I suoi clienti gestiscono mainframe e sistemi legacy che nessun altro vuole toccare. Far funzionare un agente lì è poco glamour, lento, ed è esattamente il tipo di lavoro che crea un fossato.

C'è anche un aspetto di governance, ed è quello che continua a emergere. Un agente self-hosted produce log che sono tuoi. In un audit regolamentato, puoi mostrare esattamente quale modello è stato eseguito, cosa ha letto e cosa ha modificato. In un setup cloud, quella prova è sparsa tra la console di un vendor e un contratto di servizio. Quando qualcosa va storto, la differenza tra «abbiamo i log» e «abbiamo richiesto i log» è la differenza tra un incidente chiuso e un trimestre di discovery.

La questione del modello che sta sotto

Fare self-hosting di un agente significa fare self-hosting di un modello, o almeno sceglierne uno che puoi mettere sul tuo silicio. IBM consente ai clienti di selezionare configurazioni supportate, il che in pratica significa un mix di modelli open-weight e modelli IBM. Le opzioni open-weight qui contano. Un modello di classe 70B in esecuzione su un cluster privato è più lento e meno capace del miglior modello ospitato. È anche disponibile quando la rete è giù, quando il vendor alza i prezzi o quando il vendor decide che il tuo caso d'uso viola una policy che non hai mai letto.

Le aziende fanno questo scambio da un decennio con i database, e il risultato è lo stesso: accettano un divario di capacità in cambio di controllo, poi lo colmano nel tempo con il miglioramento dell'hardware.

L'economia appare diversa dietro un firewall

Gli agenti di coding cloud hanno un prezzo per token, il che significa che il costo scala con la quantità di codice che l'agente legge e scrive. Per una startup, è una voce prevedibile. Per una grande impresa, dove un singolo repository può contenere decenni di storia e l'agente deve ingerire molto più contesto prima di poter essere utile, il contatore corre veloce.

Il self-hosting ribalta il modello. Il costo diventa hardware e operations, spese in conto capitale che l'organizzazione sostiene già. Una banca con un data center non paga di più quando l'agente legge un altro milione di righe. Il costo marginale di un'attività aggiuntiva dell'agente si avvicina all'elettricità e al tempo GPU, che sono costi affondati. È questa asimmetria che fa funzionare la proposta self-hosted anche quando il prodotto cloud è oggettivamente migliore.

C'è però un costo di conformità che il marketing salta. Il self-hosting sposta sul cliente l'onere di patch, monitoraggio e aggiornamenti dei modelli. Un vendor cloud rilascia una correzione e basta. Un deployment on-premises deve pianificare l'upgrade, testarlo contro i sistemi interni e sopravvivere a un comitato di change control. Lo strumento è più controllabile e più faticoso, e questo scambio è tutta la storia del software enterprise.

Il mercato adiacente che rende tutto questo sostenibile

Fare self-hosting di un agente funziona solo se c'è qualcosa che vale la pena eseguire dietro il muro, e quell'offerta è cresciuta. I modelli open-weight nella fascia in grado di svolgere vero lavoro di coding sono ormai comuni, rilasciati con licenze permissive da laboratori in diversi continenti. Il pezzo mancante non è mai stato il modello. Era il sistema di orchestrazione che trasforma un modello in qualcosa a cui uno sviluppatore può delegare all'interno di una rete controllata.

È questo il livello che IBM vende. Addestrare il modello migliore non è l'obiettivo. L'obiettivo è essere l'integrazione che rende utilizzabile un modello esistente nei luoghi dove una chiamata al cloud non è un'opzione. La strategia è l'immagine speculare dei laboratori API-first. Loro spingono la capacità verso l'esterno e lasciano che chiunque si connetta. IBM tira la capacità verso l'interno e la fa sopravvivere al perimetro.

Per gli acquirenti bloccati in quel perimetro, la scelta è stata spiacevole per due anni: guardare l'onda degli agenti da lontano, o infrangere una regola di sicurezza per unirsi a essa. Un'opzione self-hosted non rende l'onda più piccola. La rende solo raggiungibile, che per un'organizzazione regolamentata equivale a renderla reale.

Cosa tenere d'occhio

Le demo non sono la domanda onesta sul coding agentico self-hosted. La domanda onesta è se i risultati reggono su una base di codice con quindici anni di debito tecnico, scritta da persone che hanno lasciato l'azienda. Anche gli agenti cloud faticano con questo. La differenza è che un agente self-hosted non può essere migliorato da un vendor dall'oggi al domani senza che il cliente faccia il lavoro. Ogni guadagno deve essere conquistato dal team del cliente.

Questo rende l'adozione più lenta e più duratura, il che va bene a IBM. Sta costruendo per acquirenti che misurano il successo in anni, non in sprint, e che preferiscono possedere uno strumento leggermente peggiore piuttosto che affittarne uno migliore che non possono ispezionare. Per un mercato degli agenti di coding che ha passato due anni a inseguire benchmark, è una scommessa conservativa. È anche una scommessa sulla parte di mercato che non è ancora stata servita.

C'è una versione di questa storia che finisce male. Il tooling self-hosted ha la reputazione di essere rilasciato una volta e poi lasciato languire, perché il vendor non ha una spinta ricorrente a migliorarlo e il cliente non ha potere negoziale per pretenderlo. Se IBM Bob si stabilizza in un prodotto stabile che non migliora mai in modo significativo, gli acquirenti che attira otterranno esattamente ciò che hanno chiesto e meno di quanto speravano. L'alternativa, in cui un agente self-hosted migliora secondo un calendario controllato dal cliente, è più difficile da gestire e molto più preziosa. Quale delle due IBM consegnerà è la cosa da osservare nel prossimo anno.