Bob V2: Faster, better, smarter

Bob V2 raggiunge la disponibilità generale il 24 giugno, e rappresenta un vero salto di qualità nell'uso quotidiano: è più veloce, può mantenere le attività in esecuzione in background mentre ti occupi di altro, ed è costruito su un unico agente che si comporta in modo identico su ogni client. Quell'agente viene rilasciato prima in Bob IDE, con Bob Shell che seguirà a breve. Installare la nuova versione è l'unico passaggio di aggiornamento necessario; le impostazioni esistenti, i file di regole e i server MCP vengono mantenuti.

Cosa trovi in questo post:

• Cos'è la nuova architettura
• I cambiamenti che si notano nel lavoro quotidiano: prestazioni, le nuove modalità, le attività in background, il rollback, il lavoro con i documenti e i subagent
• I Workflow — un framework per rendere ripetibili le modifiche grandi e multi-fase

Prima testato su IBM

Il primo cliente di Bob è IBM stessa, dove più di centomila sviluppatori sono stati inseriti, su tutto ciò che va dai sistemi mainframe ai servizi cloud-native. V2 è stato messo davanti a una grande popolazione interna ben prima del GA. Le funzionalità descritte in questo post sono state distribuite in modo incrementale a partire dall'inizio di maggio, quindi ognuna ha avuto un utilizzo reale in produzione prima del rilascio.

Un agente, un harness, molti client

L'estensione IDE e la shell di Bob V1 erano costruite su due fondamenta separate. È stata una scelta deliberata per portare Bob nelle mani degli sviluppatori rapidamente, ma significava dover costruire ogni miglioramento due volte — e le richieste sopra citate erano esattamente il tipo che un codebase diviso rende lento da consegnare.

V2 sostituisce tutto questo con un'architettura a tre livelli che separa nettamente il ragionamento dall'infrastruttura dall'interfaccia:

Cosa cambia nel lavoro quotidiano

Prima delle singole funzionalità, è cambiata la superficie su cui vivono. La chat di V2 è deliberatamente più silenziosa: le chiamate agli strumenti intermedie e le esplorazioni a vicolo cieco collassano e si mettono da parte, così ciò che rimane davanti a te è il lavoro e il suo output, non i meccanismi che ci stanno dietro.

Subagent: mantenere il contesto pulito

Mentre Bob lavora su un'attività complessa, la conversazione si riempie di letture di file, ricerche ed esplorazioni a vicolo cieco. La maggior parte di quei dettagli non è rilevante per l'attività principale, ma consuma comunque la finestra di contesto.

I subagent gestiscono questo problema. Quando Bob ha bisogno di fare qualcosa di autonomo — "capire come funziona l'autenticazione in questo codebase" — avvia un subagent con il suo contesto pulito. Il subagent legge i file, segue le chiamate e ricostruisce il pattern; solo il riepilogo torna all'agente principale, mentre i passaggi intermedi vengono scartati.

Chiamate agli strumenti parallele e native

In V1, le chiamate agli strumenti venivano eseguite una alla volta: richiedi la lettura di un file, aspetta il risultato, poi richiedi il successivo. Su un'attività che si espande su cinque letture di file e tre ricerche, quell'attesa si accumula velocemente. V2 permette al modello di richiedere più strumenti in un singolo turno e di eseguirli insieme. Un'attività che in V1 richiedeva circa 30 secondi spesso finisce in meno di 10.

Le chiamate native agli strumenti eliminano anche il verboso XML che V1 inseriva attorno a ogni richiesta, quindi la stessa attività consuma meno token. Anche la finestra di contesto è più grande — da 200k a 270k token — quindi le attività più lunghe avanzano di più prima che entri in gioco la compattazione.

Tre modalità: Agent, Plan, Ask

V2 raggruppa le cinque vecchie modalità di Bob in tre:

• Agent — Bob agisce e completa l'attività, con tutte le capacità agentiche.
• Plan — Bob segue un processo di pianificazione strutturato — raccogliendo requisiti, scoprendo il contesto, verificando la propria comprensione — e produce un piano operativo da passare ad Agent.
• Ask — sola lettura. Bob spiega l'architettura e la logica senza toccare il codebase.

Il consiglio non è cambiato: su codice non familiare, o su una modifica con una superficie reale, inizia in Ask o Plan e passa ad Agent una volta che il lavoro è chiaro.

Meno interruzioni, stesso controllo

Le operazioni di lettura — lettura di file, elenco di directory, ricerca nel codice — sono ora approvate per impostazione predefinita, quindi Bob può raccogliere contesto senza fermarsi a chiedere. Tutto ciò che modifica lo stato richiede ancora un'approvazione esplicita: modifiche ai file, esecuzione di comandi, chiamate agli strumenti MCP, invocazione di skill. L'approvazione è uno dei livelli disponibili — si affianca al rollback, alle regole personalizzate e ai file di ignore — e può essere resa più restrittiva o più permissiva per classe di strumento.

Attività in background

Bob non vincola più una sessione a una sola conversazione. Uno sviluppatore può eseguire più attività contemporaneamente, lasciarle in background e continuare a lavorare. Ogni attività mantiene il proprio thread e contesto, quindi passare da una all'altra conserva il punto in cui ci si trovava. Il pannello delle attività mostra cosa è in esecuzione, cosa è terminato e cosa richiede attenzione; le attività completate si puliscono da sole. E Bob rimane fuori dai piedi mentre girano — un'attività che finisce in background non catturerà la tua attenzione né cambierà la tab su cui stai lavorando.

Rollback, ricostruito

V1 chiamava questa funzionalità checkpoint e la costruiva sopra git, il che la vincolava: un repository senza git non riceveva checkpoint, e una cronologia molto grande rallentava tutto. V2 semplifica l'intera cosa e la rinomina rollback. Ora tiene traccia dello stato dei file direttamente — per attività, per turno di conversazione, per singola chiamata agli strumenti — e qualsiasi di questi punti può essere ripristinato. Poiché il rollback risiede nell'agente e non in un client, funziona allo stesso modo ovunque l'agente venga eseguito.

Lavorare con i documenti

Gran parte del contesto per un'attività vive al di fuori del codebase — un documento di design, una specifica scritta, un foglio di calcolo con i casi di test. V2 legge nativamente i file .docx, .pdf e .xlsx: trascina uno nella conversazione e Bob ci lavora direttamente, senza copia-incolla o passaggi di estrazione separati.

Lo stesso vale per ciò che viene prodotto. Al termine di un'attività di analisi, Bob può produrre un singolo riepilogo HTML autonomo di ciò che ha trovato — una pagina, si apre in qualsiasi browser, non richiede strumenti per essere letta. Il risultato di un'indagine diventa così qualcosa che puoi consegnare a chi non era nella sessione.

Le configurazioni esistenti vengono mantenute

Il lavoro investito in un altro strumento di coding AI dovrebbe essere portato avanti, non ricominciato da capo. V2 legge le convenzioni esistenti, i file di regole, i comandi e i server MCP, e aggiunge il supporto per il formato di plugin diventato uno standard de-facto nell'ecosistema — così le raccolte di strumenti comuni girano direttamente in Bob. I server MCP avevano già il loro tab dedicato nelle impostazioni in V1; V2 aggiunge un tab dedicato alle skill accanto a esso, così le skill possono essere aggiunte, configurate e rimosse allo stesso modo, senza dover modificare i file a mano.

Workflow: rendere ripetibili le modifiche multi-fase

L'AI è brava nella risoluzione di problemi aperti e cattiva nel fare la stessa cosa due volte. Chiedi di "migrare questo a Java 21" in due giorni diversi e può restituire due approcci diversi e due risultati diversi. Per un lavoro una-tantum, va bene. Per grandi lavori enterprise — modernizzare un'applicazione mainframe, fare refactoring di migliaia di file, qualsiasi cosa che proceda per fasi — quella variabilità è il problema in sé.

I Workflow danno una struttura a questo tipo di lavoro. Il punto di partenza è che non ogni passaggio vuole l'AI, e non ogni passaggio deve essere completamente automatizzato:

• Alcuni passaggi sono pura automazione — scansione delle dipendenze, esecuzione dei test.
• Alcuni hanno bisogno dell'AI — trasformazioni di codice complesse, analisi di pattern.
• Alcuni hanno bisogno di un umano — approvare una strategia, revisionare le diff prima del commit.

Un workflow definisce dove appartiene ogni passaggio. Il motore esegue i passaggi in ordine, mantiene lo stato, gestisce gli errori e rende l'intero processo ripetibile.

È qui che entrano in gioco i pacchetti premium di IBM. Ognuno include workflow testati e strutturati, costruiti su decenni di lavoro IBM nel proprio dominio, e ciascuno è un'offerta separata con un proprio post dedicato: l'IBM Bob Premium Package for Java Modernization, il Premium Package for IBM i e il Premium Package for IBM Z. Al GA, i workflow disponibili sono quelli che vengono forniti con Bob e con questi pacchetti; la possibilità di crearne di propri si aprirà una volta che la superficie API si sarà stabilizzata con i primi adottatori.

In futuro

La stessa architettura apre direzioni che semplicemente non erano fattibili sulla vecchia fondazione. Non stiamo deliberatamente allegando date o impegni a nessuna di queste, ma le aree ampie che stiamo esplorando includono l'esecuzione di agenti da remoto raggiungibili da qualsiasi client, la coordinazione di più agenti su una singola attività e il portare Bob su ulteriori client nel tempo. Dove queste idee atterreranno effettivamente sarà determinato da ciò di cui i primi adottatori hanno più bisogno.

Aggiornamento il 24 giugno

Bob V2 viene rilasciato il 24 giugno come un normale aggiornamento di versione. Aggiornare l'estensione IDE la porta alla nuova architettura; Bob Shell seguirà a breve. Non ci sono passaggi di migrazione; le impostazioni, i file di regole e i server MCP vengono mantenuti.

Una cosa che vale la pena provare nella prima settimana: avvia un'attività in modalità Plan, passa il piano ad Agent e lascialo girare in background mentre lavori ad altro.

Link

• Installa IBM Bob
• Documentazione
• Bob Shell
• Buone pratiche
• Comunità ↗