Zwei Meldungen vom selben Tag zeigen dieselbe Entwicklungslinie aus unterschiedlichen Richtungen: KI-Unterstützung beim Programmieren wandert zunehmend in die eigene Infrastruktur. IBM stellt seinen Assistenten Bob, der bei der Modernisierung von COBOL-Beständen hilft, nun auch als selbstgehostete Variante bereit. Parallel dazu beschreibt ein Erfahrungsbericht, wie sich der quelloffene KI-Agent Hermes lokal einrichten lässt und worauf es dabei praktisch ankommt.
Für Unternehmen mit sensiblen Daten oder gewachsenen Altsystemen ist das die entscheidende Frage. Nicht, ob ein Modell beim Refactoring hilft, sondern wohin der Quellcode dabei fließt.
IBM Bob: Modernisierung ohne Cloud-Umweg
Bob richtet sich an Organisationen, die Anwendungen auf Basis von COBOL betreiben – einer Programmiersprache, die seit Jahrzehnten vor allem in Banken, Versicherungen und Verwaltungen im Einsatz ist und dort oft geschäftskritische Prozesse trägt. Genau dieser Code ist in der Regel der sensibelste, den ein Unternehmen besitzt: Er bildet Fachlogik ab, die nirgends sonst dokumentiert ist.
Dass IBM Bob nun als selbstgehostete Option anbietet, adressiert diesen Punkt direkt. Unternehmen können die KI-gestützte Softwareentwicklung in der eigenen Infrastruktur betreiben, statt Codebestände an einen externen Dienst zu übergeben. Für regulierte Branchen ist das häufig weniger eine Komfortfrage als eine Voraussetzung dafür, solche Werkzeuge überhaupt evaluieren zu dürfen.
Inhaltlich bleibt die Aufgabenstellung dieselbe: Bestandscode verstehen, dokumentieren und schrittweise in wartbare Strukturen überführen. Neu ist der Betriebsort, nicht der Zweck.
Hermes: Was ein lokaler Agent in der Praxis verlangt
Der zweite Blickwinkel kommt aus der Open-Source-Welt. Hermes tritt als lernfähiger KI-Agent an, also als System, das nicht nur Textvorschläge liefert, sondern eigenständig Werkzeuge aufruft und mehrstufige Aufgaben abarbeitet. Im Selbstversuch wurde der Agent lokal eingerichtet und daraufhin geprüft, was bei Modellen, Tools und Hardware tatsächlich zählt.
Diese drei Stichworte sind die eigentliche Botschaft. Ein lokal betriebener Agent ist kein Produkt, das man installiert und benutzt, sondern eine Kombination aus Entscheidungen:
- Modellwahl: Welches Sprachmodell lokal läuft, bestimmt Qualität und Antwortzeiten – und es gibt keine einzelne Option, die für alle Aufgaben passt.
- Werkzeuganbindung: Ein Agent ist nur so nützlich wie die Schnittstellen, über die er auf Repositories, Dateien oder Build-Prozesse zugreifen darf.
- Hardware: Lokaler Betrieb verlagert den Ressourcenbedarf ins eigene Haus. Rechenleistung ist damit kein abstrakter Posten auf einer Cloud-Rechnung mehr, sondern eine konkrete Anschaffung.
Der Titel des Erfahrungsberichts spielt ironisch mit der Frage, ob ein solcher Agent IT-Fachleute überflüssig macht. Die Testanordnung selbst deutet in eine andere Richtung: Wer einen Agenten lokal betreibt, braucht mehr Fachwissen, nicht weniger – nur an anderer Stelle.
Was die beiden Fälle unterscheidet
Bob und Hermes lösen nicht dasselbe Problem und richten sich an unterschiedliche Organisationen. Bob ist ein Herstellerangebot mit klarem Fokus auf Legacy-Modernisierung, Hermes ein quelloffener, generalistischer Agent, der im Selbstversuch erprobt wird. Das eine ist eine Beschaffungsentscheidung, das andere zunächst ein Experiment.
Gemeinsam ist beiden die Betriebsform. In beiden Fällen bleibt der Code dort, wo er entsteht. Das verschiebt die Diskussion von der Frage „Dürfen wir KI im Entwicklungsprozess einsetzen?“ hin zu „Unter welchen Bedingungen betreiben wir sie selbst?“.
Zu Leistungsdaten, Lizenzmodellen oder konkreten Hardwareanforderungen liegen aus den vorliegenden Meldungen keine belastbaren Angaben vor. Wer eine der beiden Optionen ernsthaft prüft, sollte diese Punkte früh im Evaluierungsprozess klären – insbesondere den tatsächlichen Ressourcenbedarf im Dauerbetrieb.
Einordnung für die Projektplanung
Selbstgehostete KI-Werkzeuge verändern die Kostenstruktur. Statt nutzungsabhängiger Gebühren entstehen Investitionen in Infrastruktur und Betrieb, dazu laufender Aufwand für Updates, Modellpflege und Zugriffsrechte. Das kann sich rechnen, muss es aber nicht – die Rechnung hängt stark von der Nutzungsintensität ab.
Ein zweiter Punkt betrifft die Erwartungshaltung. Agenten, die selbstständig Werkzeuge bedienen, benötigen klare Grenzen: Welche Systeme dürfen sie lesen, welche verändern, und wer prüft das Ergebnis? Diese Fragen gehören vor die Einführung, nicht danach.
Für Web- und Softwareprojekte heißt das konkret: Der Datenschutzvorbehalt verliert als pauschales Gegenargument an Gewicht, wenn KI-Assistenz auch im eigenen Rechenzentrum laufen kann. An seine Stelle tritt eine nüchterne Betriebsfrage – Hardware, Modellpflege, Zugriffskonzept –, die sich wie jede andere Infrastrukturentscheidung planen lässt. Wer ältere Systeme ablösen oder dokumentieren muss, hat damit einen Ansatz mehr zur Auswahl, sollte ihn aber an einem überschaubaren Teilbereich erproben, bevor er zur Grundlage eines ganzen Modernisierungsvorhabens wird.
