Bob V2: Faster, better, smarter

Bob V2 wird am 24. Juni allgemein verfügbar und ist im täglichen Einsatz eine echte Verbesserung: Er ist schneller, kann Aufgaben im Hintergrund weiterlaufen lassen, während du an etwas anderem arbeitest, und basiert auf einem einzigen Agent, der sich in jedem Client identisch verhält. Dieser Agent erscheint zuerst in Bob IDE, Bob Shell folgt bald. Die neue Version zu installieren ist der einzige Upgrade-Schritt; bestehende Einstellungen, Rules-Dateien und MCP-Server werden übernommen.

Was dieser Beitrag behandelt:

• Was die neue Architektur tatsächlich ist
• Die Änderungen, die sich im täglichen Arbeiten bemerkbar machen: Performance, die neuen Modi, Hintergrundaufgaben, Rollback, das Arbeiten mit Dokumenten und Subagents
• Workflows — ein Framework, um große, mehrstufige Änderungen wiederholbar zu machen

Zuerst bei IBM getestet

Bobs erster Kunde ist IBM selbst, wo mehr als hunderttausend Entwicklerinnen und Entwickler ongeboardet sind — von Mainframe-Systemen bis hin zu cloud-nativen Services. V2 wurde einer großen internen Nutzergruppe deutlich vor dem GA-Termin vorgestellt. Die in diesem Beitrag beschriebenen Funktionen wurden ab Anfang Mai schrittweise ausgerollt, sodass jede einzelne vor dem Release echten Produktionseinsatz hinter sich hatte.

Ein Agent, ein Harness, viele Clients

Die IDE-Erweiterung und die Shell von Bob V1 basierten auf zwei getrennten Grundlagen. Das war eine bewusste Entscheidung, um Bob schnell in die Hände von Entwicklerinnen und Entwicklern zu bringen — bedeutete aber, dass jede Verbesserung zweimal umgesetzt werden musste. Genau das machte es schwierig, die oben genannten Anforderungen zügig zu liefern.

V2 ersetzt das durch eine dreistufige Architektur, die Reasoning, Infrastruktur und Interface sauber voneinander trennt:

Was sich im täglichen Arbeiten ändert

Noch vor den einzelnen Features hat sich die Oberfläche verändert, auf der sie leben. Der Chat in V2 ist bewusst ruhiger: Zwischenschritte bei Tool-Aufrufen und Sackgassen-Erkundungen werden ausgeblendet, sodass nur die Arbeit und ihr Ergebnis im Vordergrund stehen — nicht die Mechanik dahinter.

Subagents: Kontext sauber halten

Wenn Bob eine komplexe Aufgabe bearbeitet, füllt sich die Unterhaltung mit Datei-Lesevorgängen, Suchen und ergebnislosen Erkundungen. Die meisten dieser Details sind für die eigentliche Aufgabe irrelevant, verbrauchen aber trotzdem Kontext-Fenster.

Subagents lösen das Problem. Wenn Bob etwas in sich Abgeschlossenes erledigen muss — z. B. „herausfinden, wie Authentifizierung in dieser Codebase funktioniert" — startet er einen Subagent mit eigenem, sauberem Kontext. Der Subagent liest Dateien, verfolgt Aufrufe und erarbeitet das Muster; nur die Zusammenfassung geht zurück an den Haupt-Agent, die Zwischenschritte werden verworfen.

Paralleles, natives Tool-Calling

In V1 liefen Tool-Aufrufe nacheinander ab: Datei-Leseanforderung stellen, auf das Ergebnis warten, dann die nächste anfordern. Bei einer Aufgabe, die sich über fünf Datei-Lesevorgänge und drei Suchen aufteilt, summiert sich das Warten schnell. V2 erlaubt es dem Modell, mehrere Tools in einem Zug anzufordern und sie gleichzeitig auszuführen. Eine Aufgabe, die in V1 etwa 30 Sekunden dauerte, ist oft in unter 10 Sekunden erledigt.

Natives Tool-Calling entfernt außerdem das ausführliche XML, das V1 um jede Tool-Anforderung gewickelt hat — dieselbe Aufgabe verbraucht damit weniger Token. Das Kontext-Fenster ist ebenfalls größer geworden — von 200k auf 270k Token — sodass längere Aufgaben weiter laufen, bevor die Komprimierung einsetzt.

Drei Modi: Agent, Plan, Ask

V2 fasst Bobs fünf alte Modi zu drei zusammen:

• Agent — Bob handelt und schließt die Aufgabe ab, mit vollen agentischen Fähigkeiten.
• Plan — Bob durchläuft einen strukturierten Planungsprozess — Anforderungen sammeln, Kontext erkunden, Verständnis überprüfen — und erstellt einen umsetzbaren Plan für den Agent-Modus.
• Ask — nur lesend. Bob erklärt Architektur und Logik, ohne die Codebase anzufassen.

Der Rat hat sich nicht geändert: Bei unbekanntem Code oder einer Änderung mit größerer Auswirkungsfläche erst in Ask oder Plan starten und zu Agent wechseln, wenn die Arbeit klar ist.

Weniger Unterbrechungen, gleiche Kontrolle

Lesevorgänge — Dateien lesen, Verzeichnisse auflisten, Code durchsuchen — werden jetzt standardmäßig genehmigt, sodass Bob Kontext sammeln kann, ohne nachfragen zu müssen. Alles, was den Zustand ändert, erfordert nach wie vor eine explizite Genehmigung: Datei-Bearbeitungen, Befehlsausführung, MCP-Tool-Aufrufe, Skill-Aufrufe. Die Genehmigung ist eine Ebene unter mehreren — sie steht neben Rollback, benutzerdefinierten Regeln und Ignore-Dateien — und kann pro Tool-Klasse enger oder weiter gefasst werden.

Hintergrundaufgaben

Bob hält eine Sitzung nicht mehr auf eine einzelne Unterhaltung beschränkt. Entwicklerinnen und Entwickler können mehrere Aufgaben gleichzeitig laufen lassen, sie im Hintergrund belassen und weiterarbeiten. Jede Aufgabe hat ihren eigenen Thread und Kontext, sodass beim Wechsel zwischen ihnen der Stand erhalten bleibt. Das Aufgaben-Panel zeigt, was läuft, was fertig ist und was Aufmerksamkeit benötigt; abgeschlossene Aufgaben räumen nach sich auf. Und Bob bleibt dabei unauffällig — eine im Hintergrund fertig werdende Aufgabe unterbricht deinen Fokus nicht und wechselt nicht den Tab, in dem du gerade arbeitest.

Rollback, neu gebaut

V1 nannte das Checkpoints und baute es auf git auf, was es einschränkte: Ein Repository ohne git bekam überhaupt keine Checkpoints, und eine sehr große History verlangsamte alles. V2 vereinfacht das Ganze und benennt es in Rollback um. Es verfolgt nun den Dateizustand direkt — pro Aufgabe, pro Gesprächsschritt, pro einzelnem Tool-Aufruf — und jeder dieser Punkte kann wiederhergestellt werden. Da Rollback im Agent statt in einem Client lebt, funktioniert es überall gleich, wo der Agent läuft.

Mit Dokumenten arbeiten

Ein großer Teil des Kontexts für eine Aufgabe lebt außerhalb der Codebase — ein Design-Dokument, eine schriftliche Spezifikation, eine Tabelle mit Testfällen. V2 liest .docx-, .pdf- und .xlsx-Dateien nativ: einfach in die Unterhaltung ziehen und Bob arbeitet direkt damit, ohne Kopieren, Einfügen oder einen separaten Extraktionsschritt.

Das gilt auch für das, was herauskommt. Am Ende einer Analyseaufgabe kann Bob eine einzelne, eigenständige HTML-Zusammenfassung der Ergebnisse erstellen — eine Seite, öffnet sich in jedem Browser, braucht kein Tooling zum Lesen. Das Ergebnis einer Untersuchung ist dann etwas, das du an jemanden weitergeben kannst, der nicht in der Sitzung dabei war.

Bestehende Setups werden übernommen

Investitionen in ein anderes KI-Coding-Tool sollen nicht verloren gehen. V2 liest bestehende Konventionen, Rules-Dateien, Commands und MCP-Server und ergänzt die Unterstützung für das Plugin-Format, das sich als De-facto-Standard im Ökosystem etabliert hat — sodass gängige Tool-Sammlungen direkt in Bob laufen. MCP-Server hatten in V1 bereits einen eigenen Einstellungs-Tab; V2 fügt daneben einen dedizierten Skills-Tab hinzu, sodass Skills genauso hinzugefügt, konfiguriert und entfernt werden können — ohne Dateien manuell zu bearbeiten.

Workflows: mehrstufige Änderungen wiederholbar machen

KI ist gut im offenen Problemlösen und schlecht darin, dieselbe Sache zweimal zu tun. Bitte sie an zwei verschiedenen Tagen, „das auf Java 21 zu migrieren", und sie kann zwei verschiedene Ansätze und zwei verschiedene Ergebnisse liefern. Für einen Einmalfall ist das in Ordnung. Für große Enterprise-Arbeit — eine Mainframe-Anwendung modernisieren, Tausende von Dateien refaktorisieren, alles, was in Phasen abläuft — ist diese Variabilität genau das Problem.

Workflows geben dieser Art von Arbeit ein Rückgrat. Der Ausgangspunkt ist, dass nicht jeder Schritt KI braucht und nicht jeder Schritt vollständig automatisiert sein sollte:

• Einige Schritte sind reine Automatisierung — Abhängigkeiten scannen, Tests ausführen.
• Einige brauchen KI — komplexe Code-Transformationen, Musteranalyse.
• Einige brauchen einen Menschen — eine Strategie genehmigen, Diffs vor dem Commit überprüfen.

Ein Workflow definiert, wo jeder Schritt hingehört. Die Engine führt die Schritte der Reihe nach aus, hält den Zustand, behandelt Fehler und macht den gesamten Prozess wiederholbar.

Hier kommen IBMs Premium-Pakete ins Spiel. Jedes enthält getestete, meinungsstarke Workflows, die auf Jahrzehnten IBM-Arbeit in seinem Bereich aufbauen, und jedes ist ein eigenständiges Angebot mit einem eigenen Beitrag: das IBM Bob Premium Package for Java Modernization, das Premium Package for IBM i und das Premium Package for IBM Z. Zum GA-Zeitpunkt sind die verfügbaren Workflows diejenigen, die mit Bob und diesen Paketen ausgeliefert werden; eine breitere Authoring-Möglichkeit öffnet sich, sobald die API-Oberfläche sich bei frühen Anwendern eingespielt hat.

Ausblick

Dieselbe Architektur eröffnet Richtungen, die auf der alten Grundlage schlicht nicht realisierbar waren. Wir hängen bewusst keine Daten oder Zusagen daran, aber die breiten Bereiche, die wir erkunden, umfassen: Agents remote auszuführen und von jedem Client aus zu erreichen, mehrere Agents auf einer einzigen Aufgabe koordiniert zusammenarbeiten zu lassen und Bob auf weitere Clients zu bringen. Wo das konkret landet, wird davon abhängen, was frühe Anwender am meisten brauchen.

Update am 24. Juni

Bob V2 erscheint am 24. Juni als normales Versions-Update. Die Aktualisierung der IDE-Erweiterung schaltet sie auf die neue Architektur um; Bob Shell folgt bald. Es gibt keine Migrations-Schritte; Einstellungen, Rules-Dateien und MCP-Server werden übernommen.

Etwas, das sich in der ersten Woche lohnt auszuprobieren: Eine Aufgabe im Plan-Modus starten, den Plan an Agent übergeben und ihn im Hintergrund neben anderer Arbeit laufen lassen.

Links

• IBM Bob installieren
• Dokumentation
• Bob Shell
• Best Practices
• Community ↗