Das Spiel hat sich gedreht. Aus der Richtung “Die KI weiss Dinge” nach “Die KI macht Dinge”. Im letzten Jahr habe ich noch Vergleiche angestellt, was die verschiedenen KI-Modelle so wissen und wie sie reagieren. Auch heute gibt es noch Vergleichsvideos und Benchmarkseiten: GPT 5.4, 5.5., 5.6, Claude 4.5, 4.6, Mythos … es ist das übliche Prozedere des Vergleichs von Leistungsdaten, wie etwa auch in Autozeitschriften zwischen Autos oder in der Computer-BILD über PCs.
Eines ist jetzt schon klar: Die KI ist schlauer als der Mensch. Die Frage ist doch, was fangen wir damit an? In der generativen KI kann man Bilder und Videos generieren. Und das in einer Geschwindigkeit, in der früher Corel Draw oder Photoshop noch nicht mal gestartet sind. Dabei kann die KI das generierte Bild in eine Webseite einbetten, das komplette Layout dazu anpassen und die Seite im Web deployen. Die agentierte KI ist der grosse Durchbruch in diesem Jahr. Schauen wir uns das mal an einigen reellen Beispielen an.
Über OpenClaw will ich gar nicht so viel Worte verlieren, es ist alles schon schon gesagt. Dennoch passt es genau hierher, um den Status zu beschreiben:
“Eine KI, die Dinge für Dich tut”.
Der typische Anwendungsfall: OpenClaw wird mit einem Einzeiler auf einem Rechner installiert, wird an einen LLM-Provider mittels API angebunden und bekommt ebenfalls über API eine Anbindung an WhatsApp oder Telegram. Dort chattet man mit OpenClaw und kann ihm Aufträge erteilen. Dabei hat er quasi Vollzugriff auf den Rechner wo es installiert ist, incl. Werkzeugen wie bash, curl, apt bei Linux. Die Einsatzmöglichkeiten sind unbegrenzt. Auch gibt es Anbindungsmöglichkeiten an andere APIs wie etwa Google-Workspace und OpenClaw kann Google-Mail verwalten, oder Kalender, oder Google-Drive. Man hat vielleicht eine Vorstellung.
Über OpenCode spricht fast niemand. Es wird auch als Einzeiler installiert und präsentiert sich danach in einem Aussehen, der etwas an einen IRC-Client der frühen 90er Jahre erinnert. Aber natürlich steckt viel mehr darin, als ein Chat wie “Hallo, wie gehts?”. OpenCode brauch auch eine LLM-Anbindung und bringt dazu eine Fülle an Anbietern mit. Praktischerweise sind zwei eigene Dienste, Zen und Go, mit dabei und man kann sofort damit starten.
Vorher benutzte ich Claude Code, ein Programm, vom Aussehen ähnlich, dem sogenannten TUI (Terminal User Interface) verbindet man es mit Claude, wirft dort ein paar Münzen ein und kann ihm sagen: “Bau mir ein Kommandozeilentool in Go, um bestimmte Metriken im Prometheus von einem bestimmten Kubernetes-Cluster zu prüfen.”. Das Programm wird vielleicht ein paar Rückfragen stellen und dann geht’s los, der Programmcode wird erstellt. Das Ergebnis ist Clustercheck, was als Argument einen Clusternamen verlangt und als Umgebungsvariable eine PROMETHEUS_URL und schon klappert das Programm die Metriken ab und gibt als rot/grün-Ampel das Ergebnis aus. Das Programm wurde weiter durch Claude Code vervollkommnet, indem es als Parameter –gatecheck bekam, um ein Qualitätstor für einen Cluster zu bekommen: Sind unsere 15 Top-Metriken grün? Laufen alle Pods? Ist Flux happy? Daraus wird ein Index gebildet und die Frage beantwortet, ob das Cluster “ready for production” ist. Aber das nur so nebenbei. Eigentlich wollte ich von OpenCode schreiben und welche Anwendungsfälle es noch gibt und schon gegeben hat.
Bevor es mit den Beispielen losgeht, noch zwei wichtige Sachen in der agentierten KI.
Instruktionen bekommt Claude Code über eine CLAUDE.md Datei. Diese Verfahren hat sich verallgemeinert und Agenten beachten eine AGENTS.md Datei im Verzeichnis, wo das Programm gestartet wird. Inhalt der Datei sind Instruktionen an den Agenten, in welchem Kontext er arbeiten soll. Soll er etwa etwas Programmieren, weisst man ihn dort an, alles in Go zu schreiben, ohne jedes Mal nachzufragen. Oder ob Unittests immer erstellt werden sollen. Für den Betrieb sind Umgebungshinweise wichtig. Etwa: arbeite immer mit kubectl, benutze nur get, list, describe und frage immer nach, wenn create, delete, patch benutzt werden soll. Ist der Zielcluster ein Produktionscluster, warne noch mal extra.
Fertigkeiten (skills) sind ebenfalls Markdown-Dateien, in denen bestimmte Abläufe erklärt werden, die bestenfalls immer wieder kehren, die KI zwar irgendwann durch Thinking oder Brute Force herausfinden würde, oder sie guckt einfach in so eine Skill-Datei nach. Ein Skill ist zum Beispiel im Tenant-Cluster herauszufinden, was der dazugehörige CAPI-Cluster ist. Mit Brute Force wird der Agent alle Kontexte durchgehen, bis er einen Cluster findet, der nach dem Namen her ein Management-Cluster ist oder die CRD für CAPI dort installiert sind. Oder man gibt ihm einen einfacheren Weg auf den Weg, weil wir etwa eine Wiki-Seite dafür haben.
Und da sind wir schon bein nächsten Feature: Der Model-Context-Protocol-Server. Den kann man an den Agenten auch anbinden und ihm so weitere Fertigkeiten verleihen. Ein MCP-Server für Confluence kann mit der Confluence-API umgehen und so Kurzbefehle bereitstellen für Wiki-Seiten erstellen, editieren oder suchen. So ein Kurzbefehl heisst dann etwa confluence_page_create, das kann der Agent direkt verwenden, ohne die ganze Confluence-API auswendig lernen zu müssen. Oder vielleicht kommt er netztechnisch gar nicht da hin. Dann kann so ein MCP-Server auch als Proxy fungieren, oder noch viele andere Dienste bereitstellen, die der Agent immer extra anbinden müsste. Es gibt eine Vielzahl an MCP-Servern: Für Confluence, Kubernetes, Prometheus, Alertmanager…
Seit letzte Weihnachten habe ich eine GoPro Hero. Damit nehme ich meine Spaziergänge und Paddeltouren auf. Jetzt überkam es mich, damit einen Livestream zu veranstalten. Ging nicht, das Drame gibts im Unsupported Blog zu lesen.
Aber zu den technischen Details. Ich habe in einem leeren Verzeichnis opencode gestartet. Als LLM kam Claude Opus 4.7 zum Einsatz. Spitzenmodell zum jetzigen Zeitpunkt, aber es geht wahrscheinlich auch mit jedem anderen oder einerm Generation älteren. 4.6 funktioniert zum Beispiel genauso gut. Ich hab mein Problem also erstmal geschildert. Genaugenommen habe ich von Videostreaming überhaupt keine Ahnung. Nach paar Minuten Chat wusste ich, dass es Streamingserver gibt. Also sowas wie Youtube, bloss ohne Youtube. Ein weit verbreiteter und alt bekannter scheint NGINX mit RTMP-Erweiterung zu sein.
Nun, das Verzeichnis hiess nginx-rtmp-server und nachdem ich git init und git remote hinzugefügt habe und bei Github das Projekt anlegte, fing opencode an, ein Dockerfile zu erstellen, dass NGINX-RTMP enthielt, ein Helm-Chart dazu zu erfinden, das ganze auf Github zu puschen, eine Build/Push-Pipeline zu erstellen und das ganze im Kubernetes-Cluster zu deployen, auf den er mit einer KUBECONFIG Zugriff hat. Dabei hatte ich als Anforderungen: Hohe Sicherheitsstandards. So lief der NGINX natürlich nich im ReadOnlyRootFS, aber opencode hat das Deployment überwacht, festgestellt: CrashLoopbackOff des NGINX-POD und hat dann so lange was geändert bis es lief. Meine Aufgabe war es, ihm immer Bescheid zu sagen, wenn bei Github die Build-Pipeline durch ist, weil ich keinen gh auf meinem Rechner installiert hatte, mit der man den Pipelinestatus von der Kommandozeile überwachen kann.
Dann wurden noch Ende-zu-Ende-Tests mit Streamings gemacht, denn ein Ingress sollte auch mit dabei sein. Dabei kam heraus, dass ich vergessen hatte, um DSL-Router Port 1936 durchzureichen und auch das hat mir opencode nochmal erklärt. Fertig war der komplette Streaming-Server. Mit der GoPro geht’s zwar immer noch nicht, aber ich kann ein altes Handy nehmen und mit einer Streaming-App Bild und Ton streamen. Weitere Versuche waren mit einer alten Überwachungskamera. Das ging zwar mit ziemlichen Gewusel über http und ffmpeg-Konvertierung, um daraus RTSP zu machen, um das dann an den RTMP weiter zu schicken, hat aber technisch funktioniert. Opencode generierte auch noch HTML-Code zum Einbinden in eine Webseite, und: Es schrieb auch noch den Blog-Beitrag oben dazu - im selben Stil wie der restliche Blog gehalten ist.
Ein bisschen etwas aus der Arbeitswelt. Ich erwähnte ja oben schon die MCP-Server für Prometheus und Alertmanager. Zu den DevOps-Aufgaben gehört ein reibungsloser Betrieb und das Beheben von Störungen. Die Störungen kommen über den Alertmanager rein und werden aus Prometheus-Metriken generiert. Beide Dienste sind am OpenCode angebunden. Desweiteren hat er mit kubectl Zugriff auf den Cluster, dem die Störung betrifft.
Eine weitere Beigabe ist ein RAG (vgl. KI Chatbots 2025 - der grosse Vergleich in Form einer Wissensdatenbank, verfügbar auf Github, angebunden als MCP an OpenCode, um Lösungen zu Störungen oder Ursachen in eine Datenbank zu schreiben.
Wie ist derzeit noch der Ablauf?
Auftrag an OpenCode: Was gibt es für aktive Alarme?
OpenCode hat in der AGENTS.md den Hinweis, den Alertmanager für Alarme zu verwenden, falls vorhanden. Mit dem wird er sich also verbinden, kriegt über die Alertmanager-API alle aktiven Alarme bezogen, wird die nach Dringlichkeit, Menge und Cluster sortieren und uns eine Übersicht geben. Dann sagen wir vielleicht: Untersuche StorageCheckFailed Alarm im Cluster sowieso. Wenn Zugriff auf den Cluster mit kubectl besteht, wird er versuchen, das Problem herauszufinden. Eventuell muss er im Prometheus nachschauen, wie der Alarm gebildet wird, denn StorageCheck ist eine Eigenerfindung. Aber über den Namen ist es recht einfach das Ding im Cluster zu finden und dann ist dort meist ein PVC im Status Pending und in dessen Beschreibung findet man raus, dass irgendewas mit dem CSI auf dem Cluster nicht stimmt. Das sind alles Standard-Dienste wie vSphere, Portworx, Trident, was auch immer. OpenCode wird also die Pod-Logs des jeweiligen Controllers untersuchen und kommt dann vielleicht auf eine fehlende Netzwerkverbindung oder falsches Passwort. Der Mensch macht das genauso, aber er ist langsamer und unzulänglicher. Denn wenn das Problem gelöst ist, schreibt OpenCode das Problem und deren Lösung in die Wissensdatenbank. Gibt es einen Jira-Tasks dazu, kann es diesen ebenfalls über MCP aktualisieren und wenn die Kunden-Doku angepasst werden muss, kann man OpenCode auch sagen, dass es das tun soll, denn es hat ja über MCP auch dahin eine Verbindung.
Das Update von Grafana Mimir ist jetzt schon paar mal schiefgegangen. Immer lief irgendwas nicht, keine Ahnung warum, Rumgesuche, Rollback. Jetzt machen wir das mit OpenCode. Im Gitlab haben wir einen Branch vorbereitet mit der neuen Konfiguration. Gitlab ist als MCP an OpenCode angebunden. Also beschreiben wir die Ausgangssituation. Ach Nein, wir haben ja schon einen Jira-Task dazu! Also beauftragen wie OpenCode an diesem Jira-Task zu arbeiten und es ständig zu aktualisieren. Beginnen wir mit dem Upgrade. OpenCode hat an verschiedenen Stellen schon gemerkt, dass das Update nicht funktionieren kann, weil bei unserem Versionssprung von 5.8 nach 5.9 der NGINX rausgeflogen ist. Das muss an etlichen Stellen geändert werden, OpenCode findet alles. Dann gibt es einen ominösen Kafka-Bus als neue Komponente. Erst mal nachfragen, wozu das Ding gut ist: als Zwischenspeicher vor dem Ingester. Na gut. Standardvorhaltezeit: 24 Stunden. Bei 240 Mio Serien, brauch man 3x6TB. OpenCode hat alles schon ausgerechnet. Den Platz haben wir nicht, also downsize bis es passt.
Dann das Upgrade. Läuft alles vorher? Überwach mal den Status. Dann das Update … 4 Stunden später, die Session mit OpenCode läuft immer noch. Unzählige Probleme mit diesem Kafka-Dreck, ein paar mal gewiped, Anzahl Distributor-Pods extrem runtergeschraubt, weil die den Kafka zugehämmert haben. Mittlerweile hatte sich natürlich die Queue auf den Prometheus Agents erhöht, keine Chance das abzubauen, also alle Agents neu starten … OpenCode, respektive Claude Opus 4.7 überwacht alles gleichzeitig, möchte an der Stelle mal einen Parameter ändern, über Gitops einchecken und Flux ausrollen, mal einen Pod starten oder eine bestimmte Metrik von einem Tenant-Cluster an jeder einzelnen Mimir-Komponente abfragen. Dabei wird jeder Schritt im Jira-Task dokumentiert, die ganze Session sowieso mitgeschnitten und selbstredend jeder Mergerequest ausführlich beschrieben.
Und das ist genau der Punkt: Das Wissen kommt raus aus den Köpfen einzelner Personen und wird breit im Team verteilt: in Mergerequests, in Jira Tasks und UserStories, in Wiki-Seiten und nicht zu vergessen, die Wissensdatenbank. Denn sind wir doch mal ehrlich: Jedes Team hat ein Defizit an Dokumentation, weil keiner die mag, die Wichtigkeit nicht erkennt oder schlicht keine Zeit dafür ist. Die Wissensinseln verschmelzen, jedem stehen alle Informationen zur Verfügung. Das Team wird redundanter, der Betrieb stabiler.
Noch ein Anwendungsfall aus dem Heinbereich. Die Mediendatenbank läuft auf dem PHP-Framwork YII, quasi eine Visualisierung der Inhalte einer MySQL-Datenbank. Es lief Jahre vor sich hin, unlängst wurde (von KI) ein Medienplayer implementiert - quasi die Verbindung der Webseite zur Festplatte. YII hat sich weiterentwickelt, unlängst ist YII 3 erschienen. Die Migration und das Upgrade der 11 Jahre alten Software habe ich OpenCode überlassen. Ich habe ihm den Sourcecode zur Verfügung gestellt, indem ich diesen auf ein Dev-System kopiert habe und OpenCode in der WebRoot von YII gestartet habe und einfach den Upgrade beauftragte. Es gab dann etliche Rückfragen zur Entscheidungsfindung, und eine Stunde später erstrahlte die Webseite im neuen Bootstrap-Layout von YII 2. Version 3 wäre zu viel Aufwand gewesen und YII 2 wird noch voll supportet.
Zum Schluss noch ein Anwendungsfall, in dem uns die KI unterhalten soll. Den AI Thriller habe ich schon vor einem halben Jahr beschrieben. Mit dem lokalen LLM waren die Ergebnisse schon sehr gut, aber wie würde wohl das mit einem Premium-LLM laufen wie GPT-5.4? Nun, das Ergebnis kann man kaufen: Schattenknoten von Frank Klöker. Eigentlich ist das Buch von ChatGPT, und natürlich ist ein enstprechender Disclaimer gesetzt. Dennoch habe ich die Rahmenhandlung von einer Idee bis zum Storyboard vorgegeben. Das Schöne ist, dass ChatGPT mitdenkt. Wenn man in der Handlung des Buches an einer bestimmten Stelle angekommen ist, macht die KI Vorschläge wie es weitergehen könnte. Bei 2-3 Hauptakteuren im Buch, erfindet die KI noch Nebenhandlungen mit Nebendarstellern. Und so wird aus einem kurzen Manuskript ein Roman von über 300 Seiten. Schattenknoten ist auch nur ein Testballon. Der richtige Roman geistern schon lange in meinem Kopf herum.
Wenn man maximal 2 Jahre zurückblickt: Mit Code Suggestion haben wir in Visual Studio Code angefangen, eine Codezeile zu schreiben. Die KI hat sie dann vervollständigt und hat geraten wie es weitergehen könnte. Wir haben ChatGPT im Browser nach Rat gefragt, teilweise endlose Dialoge zur Lösung eines Problems geführt.
Dann kam Claude Code, der Programme schon selber schreiben konnte. Man gab nur die Sprache vor und dann legte er los. Zwar mit veralteten Versionen, etwa Go 1.21, wenn es schon 1.25 gab, aber es funktionierte. Man hat sich alles angeschaut, hat es ausprobiert, noch was verändert, dann eine Pipeline dazu geschrieben, committet und irgendwann war es gebaut und releast.
Jetzt ist es so, dass ich schon gar nicht mehr reinschaue, was die KI programmiert hat. Nach Meinung mancher Leute, kann die KI nur “dummen” Code schreiben. Na gut, dann bin ich eben noch viel dümmer. In mcp-kb habe ich weder Ahnung von einer Vector-Datenbank noch wie ein MCP-Framwork aussieht. Und: ich will es auch gar nicht wissen. Das Programm funktioniert und hilft mir weiter. Genauso ist es mit der Störungssuche bei DevOps. Klar, das kann ich auch alles selber machen, aber das dauert. Und ich kann nicht 5 Probleme gleichzeitig angehen, wie es die KI normalerweise tut.
Kommen wir also zu der Frage: “Wo sehen Sie sich in 5 Jahren?” Aber das ist schon viel zu spekulativ. Als Vision reicht schon der KI Report 2027. Ein paar Thesen:
Dennoch ist der Fortschritt jetzt schon beachtlich.