IBM i Aktuelles · Praxiswissen

IBM Bob – Praxiseinschätzung für IBM i Teams

IBM Bob ist IBMs neuer AI Coding Agent – angekündigt für Entwicklungs- und Modernisierungsaufgaben im Enterprise-Umfeld. Hier lesen Sie, was Bob für IBM-i-Teams konkret leisten kann und wo spezialisierte IBM-Werkzeuge die bessere Wahl bleiben – basierend auf offiziellen IBM-Quellen und unserer IBM-i-Praxiseinordnung.

IBM-Ankündigung: Oktober 2025 Stand: März 2026 rsb-Schulung UG

IBM Bob: offizielle Einordnung

IBM stellte Project Bob im Oktober 2025 auf der IBM TechXchange Conference offiziell vor. Seitdem positioniert IBM Bob als AI Coding Agent – als breiten Entwicklungs- und Modernisierungspartner für Aufgaben im Software-Lebenszyklus. Spätestens Anfang 2026 ist Bob auf offiziellen IBM-Produkt- und Trial-Seiten sichtbar positioniert; in der offiziellen Bob-Dokumentation ist zu diesem Zeitpunkt bereits Version 1.0.1 dokumentiert.

Bob ist damit kein klassisches Code-Vervollständigungswerkzeug. IBM beschreibt Bob breiter: als agentische Unterstützung für Entwicklung, Refactoring, Modernisierung, Dokumentation, Automatisierung und Zusammenarbeit mit weiteren Tools und Systemen.

Offizielle IBM-Ankündigung

Oktober 2025

IBM-Positionierung

AI Coding Agent / Development Partner

Von IBM hervorgehobene Schwerpunkte

Refactoring, Modernisierung, Doku, Analyse

Von IBM genannte Modernisierungsbezüge

Java, COBOL, RPG, Mainframe-Systeme

Was laut IBM belastbar belegt ist

Nach offizieller IBM-Produktkommunikation und Dokumentation umfasst Bob insbesondere folgende Bereiche:

Agentische Entwicklungsunterstützung über mehrere Aufgaben im Software-Lebenszyklus hinweg
Codeverständnis und Refactoring
Unterstützung bei Modernisierungsvorhaben
Dokumentations- und Analyseaufgaben
MCP-basierte Integration externer Tools, APIs und Datenquellen
Sicherheits- und Compliance-nahe Funktionen, etwa integrierte Prüfungen und sicherheitsbezogene Scans im Entwicklungsprozess

Wichtige Einordnung Für Modernisierungsszenarien nennt IBM ausdrücklich Bezüge zu Java, COBOL, RPG und Mainframe-Systemen. Aussagen darüber hinaus – etwa zu einem offiziell klar definierten Schwerpunkt auf CL oder DDS – behandeln wir bewusst vorsichtig, weil diese Punkte in den geprüften IBM-Primärquellen nicht gleich stark und direkt abgesichert sind. Die folgenden Tabellen spiegeln deshalb unsere fachliche Einordnung wider, keine IBM-offizielle Produktmatrix.

Unsere fachliche Einordnung für IBM-i-Teams

Das Wichtigste zuerst Bob ist ein Coding-Assistent – kein Allzweckwerkzeug für das gesamte IBM-i-Umfeld. Das ist keine Schwäche, das ist ein klares Produktprofil. Den größten Nutzen bringt Bob dort, wo Code verstanden, erklärt, dokumentiert oder vorsichtig verändert werden soll. Für klassische Systemadministration und DBA-Aufgaben auf Db2 for i ist Bob nicht konzipiert – wer das von Anfang an klar kommuniziert, vermeidet die größten Enttäuschungen.

Fünf Fragen – fünf direkte Antworten

Unsere Einordnung auf Basis offizieller IBM-Informationen und IBM-i-Praxisperspektive

Frage	Einschätzung
Soll ein IBM-i-Team KI aktiv einsetzen?	Ja – aber der Einstiegspunkt entscheidet. Wer mit den richtigen Use Cases startet, hat schnell messbare Ergebnisse. Unser Vorschlag: zuerst Entwicklung, Wartung, Dokumentation und Testvorbereitung.
Ist Bob dafür ein guter Einstieg?	Ja. Bob unterstützt RPG, SQL und viele typische Entwicklungsaufgaben bereits in einer Breite, die für einen produktiven Pilotbetrieb interessant ist – mit technischem Review als Pflicht.
Ist Bob die Komplettlösung für alle IBM-i-Rollen?	Nein. Das ist keine Kritik – das ist die Realität des Produktportfolios. Für RPG-zentrierte Modernisierung positioniert IBM watsonx Code Assistant for i, für Db2-Administration den Db2 Database Assistant.
Wo liegt der Hauptnutzen?	Überall dort, wo Zeit draufgeht für Dinge, die eigentlich niemand machen will: Code verstehen, Altbestand dokumentieren, Testfälle ableiten, Abhängigkeiten analysieren. Genau das ist Bobs Stärke.
Wo liegt das Hauptrisiko?	Bob liefert Antworten, die klingen, als kämen sie von jemandem, der das Thema kennt. Manchmal stimmt das. Manchmal nicht. Deshalb bleibt Review Pflicht – das gilt für jeden KI-Assistenten, nicht nur für Bob.

Übersicht nach Aufgabengebiet

Eine ehrliche Einordnung aus IBM-i-Praxissicht: Was funktioniert, was funktioniert mit Einschränkungen – und wo sollte man Bob nicht als primäres Werkzeug positionieren.

Unsere fachliche Einordnung – keine IBM-offizielle Produktmatrix. CL und DDS: siehe Hinweis oben.

Aufgabengebiet	Bob?	Hauptnutzen	Grenzen	Empfehlung
RPG-Entwicklung und -Pflege	Ja, klar	Fremdcode schnell verstehen, Refactoring vorbereiten, Testfälle ableiten	Fachlogik wird manchmal falsch interpretiert – nie ungeprüft übernehmen	Als täglichen Assistenten einsetzen
CL-Entwicklung und -Pflege	Häufig brauchbar	Ablauf- und Steuerlogik erklären, Doku und Standardmuster ableiten	Gefahr falscher Umgebungsannahmen oder unpassender Befehlsfolgen	Prüfpflichtig – jede produktive Änderung gegenlesen
SQL im Anwendungscode	Ja	Embedded SQL erklären, dokumentieren, Auswirkungen einschätzen	Plausibel ist nicht dasselbe wie performant oder betriebssicher	Für Entwickler nutzen – kein DBA-Ersatz
DDS-Bestand verstehen	Oft hilfreich	Altbestand schneller erfassen und dokumentieren	Implizite Altlogik und Seiteneffekte werden nicht immer erkannt	Gut für Analyse und Wissenssicherung – mit Prüfung
DDS → SQL DDL / Modernisierung	Bedingt	Gute Vorarbeit: Analyse, Strukturierung, Migrationsplanung	Hohes Risiko stiller Semantikänderungen – das ist der kritische Punkt	Nur mit starker Fachprüfung und Tests
Tests / QA / Regression	Ja	Testfälle, Randfälle und Prüfpfade schneller ableiten	Testabdeckung wirkt oft vollständiger als sie ist	Als Beschleuniger einsetzen, nicht als Alleinlösung
Dokumentation / Wissenssicherung	Ja, sehr	Hoher Nutzen in gewachsenen Anwendungen – besonders beim Onboarding	Erklärungen können überzeugend und trotzdem verkürzt sein	Früh pilotieren – der schnellste Mehrwert
Change-Impact-Analyse	Ja	Schnellere Voranalyse vor Änderungen	Seiteneffekte außerhalb des sichtbaren Kontexts können übersehen werden	Gut geeignet – immer mit technischem Review
IBM i Modernisierung allgemein	Ja	Refactoring, Doku, Testvorbereitung, Codebasis-Verständnis	Nicht so fokussiert wie spezialisierte Modernisierungswerkzeuge	Als breiten Assistenten einsetzen
RPG-zentrierte Modernisierung	Nur teilweise	Analyse und Vorbereitung – da hilft Bob	Für Fixed-to-free, ILE-Strukturierung: nicht die präziseste Lösung	watsonx Code Assistant for i bevorzugen
Db2 for i DBA / Tuning / Troubleshooting	Eher nein	Allenfalls beim Verstehen von SQL im Anwendungscode	Nicht für echte DBA-Arbeit konzipiert	Db2 Database Assistant bevorzugen
Systemadministration IBM i	Eher nein	Allenfalls bei CL, Runbooks und technischer Doku	Kein Werkzeug für PTFs, Security-Admin, Backup/Recovery, HA/DR	Nicht mit Bob als Kernargument starten

Rollenbezogene Einordnung für ein IBM-i-Team

Nicht jede Rolle profitiert gleich. Diese Übersicht zeigt, wo Bob konkret helfen kann – und wo andere Lösungen den Vorrang haben sollten.

Unsere fachliche Einordnung aus IBM-i-Praxisperspektive

Rolle	Primärwerkzeug	Geeignete KI-Aufgaben	Weniger sinnvoll	Kontrollbedarf
IBM i Entwickler	Bob	RPG, CL, SQL, DDS verstehen; Doku, Tests, Refactoring, Voranalyse	Tiefes Db2-Tuning und Systembetrieb	Mittel bis hoch
Senior Developer / Maintainer	Bob	Fixed-to-free vorbereiten, Modularisierung, Bereinigung gewachsener Codebasen	Produktivänderungen ohne Regressionstests	Hoch
Tech Lead / Architekt	Bob + watsonx Code Asst. for i	Codebasis analysieren, Modernisierungspfade definieren, Standards festlegen	Reine Betriebs- oder DBA-Themen	Hoch
QA / Tester	Bob	Testfälle, Randfälle, Review-Fragen und Prüfpfade ableiten	Freigabe ohne fachliche Validierung	Mittel bis hoch
Application Manager	Bob	Wissenssicherung, Onboarding, Doku, Voranalysen	Betriebsentscheidungen allein auf KI-Ausgaben stützen	Mittel
Db2 for i Admin / DBA	Db2 Database Assistant	Troubleshooting, Metriken, betriebsnahe Datenbankfragen	RPG-/CL-zentrierte Codearbeit als Hauptfall	Sehr hoch
Systemadministrator IBM i	Keines als Primärwerkzeug	Allenfalls Runbooks, CL-Doku und Begleitdokumentation	Benutzer, Rechte, PTFs, Backup/Recovery, HA/DR, Betriebssteuerung	Sehr hoch bis maximal

Wo Bob den größten Nutzen bringt

Fünf Bereiche, in denen Bob schnell spürbaren Mehrwert liefert:

Legacy-Code verstehen – besonders in Anwendungen, wo viel implizites Wissen in RPG, CL, DDS und SQL steckt und die Leute, die das ursprünglich geschrieben haben, längst nicht mehr da sind.
Dokumentation und Wissenssicherung. Das klingt unspektakulär, ist aber in vielen Unternehmen das eigentliche Problem.
Refactoring- und Wartungsarbeit, weil Voranalysen und technische Einordnungen deutlich schneller vorliegen als ohne KI-Unterstützung.
Testvorbereitung – Ideen für Randszenarien, Prüfpfade und Regressionstests, die man selbst vielleicht übersehen hätte.
Modernisierungsvorbereitung: Strukturen, Abhängigkeiten und Risiken transparent machen, bevor irgendjemand anfängt zu ändern. Das ist oft der wertvollste erste Schritt.

Empfohlene Einführungsreihenfolge

Pragmatisch und mit realistischen Erwartungen:

Bob-Pilot im Entwicklerteam mit klar abgegrenzten Use Cases starten: Codeverständnis, Dokumentation, Testvorbereitung, Refactoring-Vorschläge. Kein Big Bang – ein konkreter Anwendungsfall reicht für den Anfang.
Ausbau auf Modernisierungsszenarien, wenn die ersten Erfahrungen im Team vorliegen. Bei starkem RPG-Modernisierungsfokus: gezielte Bewertung von watsonx Code Assistant for i parallel dazu.
Separater DBA-Pilot nur dann, wenn Datenbankbetrieb, Performance und Troubleshooting ausdrücklich verbessert werden sollen – und dann mit Db2 Database Assistant, nicht mit Bob.
Systemadministration bewusst aus dem Primärpilot herausnehmen. Nicht weil es nicht wichtig wäre – sondern weil falsche Erwartungen am Anfang den größten Schaden anrichten.

Fazit Bob kann IBM-i-Teams vor allem dort konkret helfen, wo Entwicklung, Pflege, Dokumentation, Testvorbereitung und Modernisierungsvorbereitung beschleunigt werden sollen.

Genau dort verlieren viele IBM-i-Teams im Alltag am meisten Zeit. Für klassische Systemadministration und echte Db2 for i DBA-Aufgaben braucht es spezialisierte Werkzeuge – und das sollte von Anfang an so eingeplant werden.

Für IBM-i-Teams lässt sich Bob deshalb am sinnvollsten als breit einsetzbarer AI Coding Agent für Entwicklungs- und Modernisierungsvorbereitung einordnen – aber nicht als Ersatz für spezialisierte Werkzeuge und nicht als Grundlage dafür, Ergebnisse ungeprüft zu übernehmen.

IBM i Know-how aufbauen

IBM i Wissen, das im Team bleibt.

rsb-Schulung vermittelt Administration, Db2 for i, RPG und CL – praxisnah, seit über 35 Jahren.

IBM i Seminare ansehen →

Quellenhinweis: Sachliche Grundlage dieser Einordnung sind offizielle IBM-Ankündigungen, offizielle IBM-Produktseiten und die offizielle Bob-Dokumentation. Versionsangaben unterhalb von 1.0.1 sowie ein exaktes IBM-Freigabedatum haben wir bewusst nicht übernommen, weil sie in den geprüften IBM-Primärquellen nicht eindeutig belegt sind. Die Tabellen zur Aufgaben- und Rolleneinordnung – insbesondere zu CL und DDS – spiegeln unsere fachliche Einschätzung aus 38 Jahren IBM-i-Praxis wider, keine IBM-offizielle Produktmatrix. Alle Bewertungen bilden den Stand zum Zeitpunkt der Erstellung ab; IBM entwickelt dieses Produktfeld aktiv weiter.

Wer Bob im eigenen Team prüfen möchte: Der Einstieg erfolgt am besten über die offizielle IBM-Bob-Produktseite mit den dort verlinkten Produkt-, Trial- und Dokumentationsinformationen.