Das KI-Tretrad: Warum Schritthalten die eigentliche Engineering-Herausforderung ist

Drei Jahre in der generativen KI fühlen sich an wie ein Jahrzehnt in jedem anderen Bereich. Seit Ende 2022, als ChatGPT große Sprachmodelle unübersehbar machte, beschäftigen wir uns voll und ganz damit, diese Technologie auf das Software-Engineering anzuwenden. Das Tempo war unerbittlich.

Die Entwicklung, vor der niemand warnt

Die Anfänge waren vielversprechend, aber holprig. Das erste brauchbare Werkzeug, dem die meisten Entwicklerinnen und Entwickler begegneten, war GitHub Copilot. Dieses Produkt entstand sogar noch vor der Welle der generativen KI und übernahm rasch Next-Token-Prediction-Modelle, um ein intelligenteres IntelliSense zu bieten. Es konnte die nächste Zeile oder die nächsten paar Zeilen Code automatisch vervollständigen. Nützlich, aber begrenzt. Das Denken blieb bei Ihnen. Die KI tippte nur schneller.

Dann verschob sich das Feld. Cursor baute einen ganzen Editor um ein grundlegend anderes Interaktionsmodell: Sie konnten mit Ihrer Codebasis sprechen, sie in natürlicher Sprache abfragen und Antworten erhalten, die den vollständigen Kontext Ihres Projekts kannten. Windsurf, Ende 2024 von Codeium veröffentlicht, führte agentische Workflows ein und bezeichnete sich als erste agentische IDE. Claude Code und Codex erschienen Anfang 2025 fast gleichzeitig und trieben die Dinge in Richtung autonomes, mehrstufiges Reasoning über ganze Repositories. Jeder dieser Schritte war ein echter Sprung, kein bloßes inkrementelles Update.

Um wirksam zu bleiben, mussten Sie mitspringen. Und wieder springen. In drei Jahren haben wir mit mindestens fünfzehn bis zwanzig verschiedenen Tools und Modellen gearbeitet. Nicht aus Neugier, sondern aus Notwendigkeit. Das Modell, das im März auf dem neuesten Stand war, wurde im Juli übertroffen. Das Tool, das im ersten Quartal eine neue Schlüsselfunktion einführte, wurde im zweiten Quartal von einem Mitbewerber eingeholt oder überholt.

Die Kosten, die die meisten Teams unterschätzen

Darüber spricht man selten: "Mit dieser Entwicklung Schritt zu halten ist ein Vollzeitjob." Es geht nicht nur darum, ein Tool gegen ein anderes auszutauschen. Jedes neue Modell hat andere Stärken, andere Fehlermuster, andere optimale Prompting-Strategien. Jedes neue Tool zwingt dazu, Workflows neu zu durchdenken, Guardrails neu zu bewerten und neu zu lernen, was funktioniert.

2023 brauchten Sie umfangreiche manuelle Aufsicht und ausgiebiges Prompt-Engineering, um brauchbare Codegenerierung zu erreichen. Modelle ohne Reasoning konnten Datenabfragen über natürliche Sprache bewältigen, scheiterten aber an allem, was eine mehrstufige Analyse erforderte. Bis 2025 veränderten agentische Architekturen und Reasoning-fähige Modelle vollständig, was möglich war. Aber nur, wenn Sie Ihren Ansatz entsprechend neu aufbauten.

Nur wenige Teams haben dafür die Kapazität. Die meisten Unternehmen führen ein Tool ein, lernen seine Eigenheiten und bleiben dabei, selbst wenn es zurückfällt. Andere jagen jedem neuen Release hinterher, ohne die nötige Tiefe, um echten Mehrwert herauszuziehen. Beide Wege lassen erhebliche Möglichkeiten ungenutzt.

Jetzt passiert dasselbe im Betrieb

Alles oben Beschriebene spielte sich in der Software-Entwicklung ab. Doch nun sehen wir genau dasselbe Muster im Software-Betrieb entstehen. KI-gestützte SRE-Agenten, automatisierte Incident-Analyse, intelligente Runbooks, modellgesteuerte Root-Cause-Erkennung. Die Tools und Ansätze entwickeln sich genauso schnell, und dasselbe Tretrad gilt.

Ein perfektes Beispiel spielte sich in wenigen Monaten ab. Im November 2024 stellte Anthropic das Model Context Protocol (MCP) vor, einen offenen Standard, um KI-Modelle mit externen Tools und Datenquellen zu verbinden. Bis Mitte 2025 war MCP regelrecht explodiert. Die Server-Downloads wuchsen von rund 100.000 auf über 8 Millionen. OpenAI, Google und Microsoft übernahmen es alle. Tausende MCP-Server entstanden. Einen Moment lang sah es aus wie die endgültige Integrationsebene für KI-Agenten, auch für den Einsatz im Betrieb.

Dann holte die Realität ein. Sicherheitsforscherinnen und -forscher fanden gravierende Schwachstellen im gesamten MCP-Ökosystem: sieben CVEs in einem einzigen Monat, Path-Traversal-Risiken in 82 % der analysierten Implementierungen, Prompt-Injection-Angriffe über Tool Poisoning. Gleichzeitig begannen Entwickler und SREs, lokale Agenten per MCP mit Produktivumgebungen zu verbinden und mit Kubernetes-Clustern, Cloud-CLIs und Infrastruktur-Tooling zu interagieren. Mächtig, aber riskant. MCP hebt im Grunde die eigenen Berechtigungen des Nutzers auf das Modell, mit wenig Guardrails.

Und jetzt, nur wenige Monate später Anfang 2026, verschiebt sich die Erzählung bereits. Viele sprechen noch immer von MCP als dem Standard. Doch unter Praktikern, die an die Grenzen gehen, bildet sich ein anderer Konsens: "Modelle arbeiten am besten nicht mit eigenen Protokoll-Schnittstellen, sondern mit den Schnittstellen, die in ihren Trainingsdaten bereits tief verankert sind." CLI-Tools und Shell-Ausführung. Ein einzelner MCP-Server kann Zehntausende Tokens an Schema-Overhead verbrauchen, bevor ein Modell überhaupt zu arbeiten beginnt. Ein CLI-Befehl kostet einen Bruchteil davon und nutzt Wissen, das das Modell bereits aus Milliarden Zeilen Terminal-Interaktionen in seinem Trainingskorpus mitbringt.

Dieser Wandel dauerte Monate, nicht Jahre. MCP beherrschte 2025 die Diskussion. Ende 2025 gewann die CLI-Erzählung an Zugkraft. Bis März 2026 überholt sie MCP in der Praxis bei den Teams, die sich am schnellsten bewegen. Die meisten sind noch nicht so weit. Das ist das Tretrad in Aktion, jetzt im Betrieb.

Warum der Betrieb einen anderen Aufbau verlangt

Ob Engineers MCP oder CLI einsetzen: Der aktuelle Ansatz für KI-gestützten Betrieb bedeutet meist, Agenten lokal auszuführen. Auf der eigenen Maschine, mit den eigenen Zugangsdaten, unter eigener Aufsicht. Für die Software-Entwicklung funktioniert das. Sie schreiben Code, prüfen Diffs, führen Tests aus. Der Agent läuft in Ihrer Entwicklungsumgebung, und Sie sind da, um ihn zu beobachten.

Der Betrieb ist grundlegend anders. Incidents warten nicht, bis jemand am Schreibtisch sitzt. Eine Root-Cause-Analyse sollte nicht davon abhängen, ob die Maschine einer einzelnen Person online ist. Der Zugriff auf die Produktivumgebung braucht organisatorische Kontrollen, Audit-Trails und Berechtigungsgrenzen, nicht die persönlichen Zugangsdaten eines Entwicklers, die an ein Modell durchgereicht werden. Und die Sicherheitsrisiken, die schon in der Entwicklung Sorgen bereiten, werden im Produktivbetrieb untragbar: offener Tool-Zugriff, Privilege Escalation, ungeprüfte Integrationen, die gegen die laufende Infrastruktur arbeiten.

Die lokale Ausführung von Agenten erfüllt die Anforderungen des Produktivbetriebs schlicht nicht.

Wo Hyground sich abhebt

Genau hier kommt Hyground ins Spiel. Wir haben drei Jahre auf dem KI-Tretrad verbracht und jeden Wandel bei Modellen, Tools, Architekturen und Integrationsmustern verfolgt. Wir tun das, damit unsere Kunden es nicht tun müssen.

Hyground verbindet sich mit jedem großen Sprachmodell. Unsere Architektur ist darauf ausgelegt, sich anzupassen, damit wir jederzeit die jeweils stärksten Modellfähigkeiten nutzen können. Als Reasoning-Modelle echte Incident-Analyse möglich machten, haben wir sie integriert. Als agentische Architekturen reif genug für zuverlässige mehrstufige Betriebs-Workflows waren, haben wir sie übernommen. Als sich die Integrationslandschaft von MCP zu CLI-nativem Tooling verschob, haben wir bereits evaluiert und nachjustiert.

Doch bei den Modellen am Ball zu bleiben ist nur die Hälfte. Hyground ist eigens für den Betrieb gebaut, was bedeutet, dass wir die Probleme lösen, die lokale Agenten-Setups nicht lösen können. Wir bieten kuratierte, sicherheitsgeprüfte Integrationen statt offenem Tool-Zugriff. Wir setzen Berechtigungsgrenzen und Laufzeitkontrollen durch, die Privilege Escalation verhindern. Wir verfolgen CVEs im gesamten Agenten- und Tooling-Ökosystem. Und Hyground arbeitet unabhängig von der Maschine einer einzelnen Person, sodass Incident-Analyse, Monitoring und betriebliche Aufgaben fortlaufend laufen, nicht nur dann, wenn gerade jemand am Schreibtisch sitzt.

Unsere Kunden müssen nicht verfolgen, welches Modell die Root-Cause-Analyse in diesem Quartal am besten beherrscht, oder ob die Integrationsebene, die sie vor sechs Monaten gebaut haben, bereits ein Sicherheitsrisiko ist. Das tun wir. Wir evaluieren, wir benchmarken, wir justieren nach, und wir liefern die Verbesserungen direkt in die Plattform aus.

Das Fazit

Das Tempo der KI-Entwicklung lässt nicht nach. Das Tretrad, das in der Software-Entwicklung seit drei Jahren läuft, läuft nun im Betrieb. Die Organisationen, die aus KI in ihren betrieblichen Workflows echten, sich summierenden Wert ziehen, werden jene sein, die entweder stark investieren, um an der Spitze zu bleiben, oder mit jemandem zusammenarbeiten, der das bereits tut.