…denn genau so hat es sich für mich angefühlt: kein großes Auspacken im klassischen Sinn, sondern eher das vorsichtige Öffnen einer Werkzeugkiste. Einer Werkzeugkiste, bei der man anfangs noch nicht genau weiß, was alles darin steckt und vor allem, wie gut sich die einzelnen Werkzeuge im Alltag wirklich bewähren.

Installation und erster Eindruck

Die Installation von IBM Bob verlief für mich angenehm unspektakulär. Ohne größere Hürden war das Werkzeug schnell einsatzbereit, was gerade im Enterprise-Umfeld alles andere als selbstverständlich ist. Besonders positiv fiel mir direkt die sehr gute Integration in Visual Studio Code auf. Da VS-Code für mich ohnehin das zentrale Arbeitswerkzeug ist, fühlte sich IBM Bob vom ersten Moment an nicht wie ein Fremdkörper an, sondern wie eine sinnvolle und gut durchdachte Erweiterung der bestehenden Entwicklungsumgebung.

Ein Punkt blieb für mich zunächst offen. Es war nicht eindeutig ersichtlich, wie sich andere Large Language Models einbinden lassen. Gerade für erfahrene Anwender, die bewusst mit unterschiedlichen Modellen arbeiten oder diese vergleichen möchten, wäre hier etwas mehr Transparenz wünschenswert. Dieser Aspekt trübt den insgesamt positiven Ersteindruck nicht wesentlich, zeigt aber, dass es an einigen Stellen noch Entwicklungspotenzial gibt.

Zusammenarbeit mit Legacy-Sprachen

Besonders spannend war für mich die Arbeit mit klassischen Legacy-Sprachen. IBM Bob richtet seinen Fokus sehr klar auf Technologien, die in vielen Unternehmen nach wie vor geschäftskritisch sind. Dazu zählen unter anderem COBOL, PL/I, HLASM sowie REXX. Genau in diesem Umfeld kann das Werkzeug seine Stärken ausspielen.

Sehr positiv empfand ich die Möglichkeit, Komplexitätsanalysen nach McCabe oder Halstead direkt auf ganze Verzeichnisse oder einzelne geladene Quellen anzuwenden. Gerade bei der Analyse größerer, historisch gewachsener Codebasen ist das ein echter Mehrwert. Auffällig war allerdings, dass für identischen Code teilweise unterschiedliche Komplexitätswerte ausgewiesen wurden. Das ist kein gravierendes Problem, wirft aber Fragen auf, insbesondere wenn solche Kennzahlen als Grundlage für Entscheidungen dienen sollen.

Produktivität im Alltag

Die oft zitierte höhere Produktivität konnte ich im täglichen Arbeiten klar nachvollziehen. Überarbeitungen und Refactorings gelingen erstaunlich einfach. Häufig reicht ein sauber formulierter Prompt oder eine entsprechende Anweisung direkt im Quellcode aus. Änderungen lassen sich so sehr schnell anstoßen, ohne dass man sich sofort manuell durch jede einzelne Codezeile arbeiten muss. Gerade in Umgebungen, in denen regelmäßig kurzfristige Anpassungen erforderlich sind, etwa bei Banken oder Versicherungen, dürften hier spürbare Zeiteinsparungen erzielt werden.

Bei COBOL-Quellen zeigte sich allerdings auch eine typische Schwäche automatisierter Refactorings. Häufig wird bei Umstrukturierungen mit einem GO TO zum Ende einer SECTION gearbeitet. Das ist funktional korrekt, entspricht aber nicht mehr dem heutigen Verständnis von sauberem und modernem COBOL-Code. Aktuelle COBOL-Versionen bieten mit EXIT SECTION deutlich bessere Möglichkeiten. Hier würde ich mir wünschen, dass man künftig die Version des eingesetzten Compilers oder zumindest den gewünschten Sprachstandard konfigurieren kann, um solche Ergebnisse gezielt zu vermeiden.

Screenshot Nutzeroberfläche IBM Project Bob beim Test mit COBOL

PL/I als angenehme Überraschung

Auch die Verarbeitung und das Refactoring von PL/I-Quellen verliefen für mich sehr zufriedenstellend. PL/I ist keine einfache Sprache, insbesondere wenn sie über Jahrzehnte gewachsen ist und unterschiedlichste Programmierstile vereint. Umso erfreulicher war es zu sehen, wie souverän IBM Bob mit diesen Quellen umgeht. Die vorgeschlagenen Änderungen waren in der Regel gut nachvollziehbar, sauber strukturiert und respektierten die Eigenheiten der Sprache.

Begeisterung beim Assembler

Meine größte Begeisterung stellte sich jedoch bei der Arbeit mit Assembler ein. Gerade hier finden sich in vielen Programmen alte, historisch bedingte Konstrukte, die zwar funktionieren, aber längst nicht mehr dem heutigen Stand der Technik entsprechen. Besonders beeindruckend war für mich, wie einfach sich beispielsweise eine klassische Druckaufbereitung mit MVZ durch einen deutlich eleganteren Einsatz von ED ersetzen ließ.

Aus reiner Neugier habe ich zudem versucht, eine Assemblerquelle nach COBOL umzuwandeln. Das Ergebnis war überraschend gut, zumindest solange keine sehr systemnahen Anweisungen verwendet wurden. An dieser Stelle stößt auch IBM Bob an natürliche Grenzen. Das ist weder überraschend noch negativ zu bewerten, denn bestimmte systemnahe Logik lässt sich nicht ohne Weiteres in eine höhere Programmiersprache übertragen.

Screenshot Nutzeroberfläche IBM Project Bob beim Test mit Assembler

Erste Eindrücke bei REXX

Die refrakturierten REXX-Quellen konnte ich bislang nur oberflächlich prüfen. Der erste Eindruck ist jedoch durchweg positiv. Die Ergebnisse wirken aufgeräumter und besser lesbar. Eine tiefergehende Bewertung steht für mich noch aus, dennoch zeigt sich bereits hier, dass IBM Bob auch in diesem Umfeld das Potenzial hat, die tägliche Arbeit spürbar zu erleichtern.

Ein notwendiger Realitätscheck zum Schluss

Bei aller Begeisterung ist mir ein Punkt besonders wichtig. IBM Bob ersetzt kein fachliches Verständnis der Programme, mit denen man arbeitet. Das Werkzeug kann Syntax und Semantik verbessern, modernisieren und vereinheitlichen. Den fachlichen Kontext, die Geschäftslogik und die historischen Entscheidungen, die in vielen Programmen stecken, kann und wird es jedoch nicht vollständig erfassen.

Ebenso unerlässlich bleibt ein solides Sprachverständnis. Ohne Kenntnisse der jeweiligen Programmiersprache ist eine sinnvolle Kontrolle der Ergebnisse kaum möglich. IBM Bob ist ein leistungsfähiges Werkzeug, aber es bleibt eine Unterstützung. Die Verantwortung für den Code und dessen fachliche Korrektheit liegt weiterhin beim Entwickler.

IBM Bob fühlt sich für mich nicht wie ein weiteres kurzlebiges KI-Experiment an, sondern wie ein ernst gemeinter Ansatz, die Realität moderner IT-Landschaften abzubilden. Legacy-Code wird hier nicht als Altlast betrachtet, sondern als wertvolle Substanz, die gepflegt, verstanden und behutsam modernisiert werden soll. Genau das macht IBM Bob für mich so interessant und so relevant für den täglichen Einsatz.

Über den Autor: Uwe Graf ist Lead Modernization Architect bei der EasiRun Europa GmbH und gilt auf LinkedIn als eine der profiliertesten Stimmen in Sachen Mainframe-Modernisierung. Seine Beiträge sind fachlich präzise, pointiert – und unverkennbar durch den kleinen Dino, der als Symbol für den Brückenschlag zwischen Tradition und Innovation steht. Für sein Engagement in der Mainframe-Community wurde er 2025 sowohl als IBM Champion als auch als „Influential Mainframer“ von planetmainframe.com ausgezeichnet