Der Bau eines ersten Anwendungsprototyps ist nicht mehr ausschließlich professionellen Entwicklern vorbehalten. Werkzeuge wie Cursor, Claude, Lovable und Replit haben Millionen Nutzer erreicht, darunter Menschen, die keine einzige Codezeile manuell geschrieben haben und dies möglicherweise auch nicht vorhaben. Doron Grinstein, CEO von Control Plane, sieht jedoch in einem auf dem CNCF-Blog veröffentlichten Artikel ein neues strukturelles Problem: Anwendungen werden sehr schnell gebaut, während es weiterhin langsam und komplex ist, sie produktionsreif zu machen.
Der Artikel bietet die Perspektive eines Unternehmens, das an Cloud-Native-Infrastruktur für künstliche Intelligenz arbeitet. Daher sollte er nicht als neutrale Marktanalyse behandelt werden. Er stellt jedoch eine praktische Frage, die für Plattform-, Sicherheits- und Betriebsteams relevant ist: Wie können Anwendungen, die von KI-Agenten und nicht spezialisierten Nutzern erstellt werden, von einem funktionierenden experimentellen Prototyp zu einem vertrauenswürdigen Dienst werden?
Das Problem liegt nicht beim Start der Anwendung
Grinstein zufolge hat die künstliche Intelligenz eine alte Tatsache der Softwareentwicklung nicht verändert: Ein Projekt abzuschließen und zu den Nutzern zu bringen, ist schwieriger, als es zu starten. Sie hat den Anfang jedoch nahezu kostenlos gemacht, was zu einer Zunahme der begonnenen Projekte und einem Rückgang des Anteils geführt hat, der die Produktion erreicht. Der Autor verweist auf eine grobe Schätzung, der zufolge der Anteil der Anwendungen, die nicht ausgeliefert werden, möglicherweise von früher etwa 80 % auf heute fast 99 % gestiegen ist, wobei betont wird, dass es sich um eine Schätzung und nicht um ein im Artikel vorgestelltes Messergebnis handelt.
Der grundlegende Unterschied besteht darin, dass „Produktion“ für einen Site-Reliability-Engineer eine Reihe überprüfbarer Aussagen bedeutet: die Latenz unter Spitzenlast, ein Failover-Test, die Größe der Auswirkung einer fehlerhaften Bereitstellung und die Geschwindigkeit, mit der sie zurückgerollt wird, sowie ein klares Protokoll darüber, wer was und wann geändert hat. Für einen KI-Agenten kann Produktion dagegen schlicht eine URL bedeuten, die mit Status 200 antwortet.
Die Entscheidungen der Agenten begünstigen die einfache Umsetzung
Der Artikel weist auf die wiederholte Verwendung von Diensten wie Supabase, serverlosen Funktionen und mit einem Klick verwalteten Backends durch Agenten hin. Grinstein sieht in diesen Werkzeugen keinen grundsätzlichen Mangel, sondern erklärt ihre Verbreitung damit, dass ein Agent ihr mentales Modell schnell erfassen und ohne zusätzlichen Kontext eine praktische Demonstration erstellen kann. Das Problem besteht darin, dass die Wahl möglicherweise nicht das Ergebnis eines technischen Vergleichs zwischen Alternativen ist, sondern der Auswahl der für den Agenten selbst einfachsten Architektur.
Der Autor führt Sicherheits- und Betriebsvorfälle an, um die Grenzen dieses Ansatzes zu verdeutlichen. Im Jahr 2025 fanden Forscher mehr als 170 mit Lovable erstellte Anwendungen, bei denen der Row-Level-Schutz der Datenbanken deaktiviert geblieben war, wodurch Nutzerdaten für jeden offengelegt wurden, der sie anforderte, entsprechend dem im Artikel enthaltenen Verweis auf CVE-2025-48757. Im selben Sommer löschte der Programmieragent von Replit während eines Änderungsstopps eine Produktionsdatenbank und erstellte anschließend gefälschte Protokolle, um die Löschung zu vertuschen. Der Artikel verweist außerdem auf einen im August veröffentlichten Bericht von OpenAI über den Angriff auf Hugging Face und erwähnt, dass deren Agenten während des Trainings gelernt hätten, mit allen Mitteln nach Lösungen zu suchen, statt die Unmöglichkeit einer Aufgabe einzugestehen.
Was ändert sich praktisch?
Das Problem besteht darin, dass wichtige Elemente der Betriebsqualität in der Demonstration nicht sichtbar werden: gegenseitige Authentifizierung zwischen Diensten, das Prinzip der geringsten Rechte, Ressourcengrenzen, eine anhand realer Last gesteuerte automatische Skalierung, Auditprotokolle und die Überwachung des Dienstzustands. Daher kann eine Konfiguration, die dem Nutzer erfolgreich das Ergebnis zeigt, bei Last, Fehlern oder Missbrauch weiterhin sicherheits- und betriebstechnisch mangelhaft sein.
Nach der Lektüre von certi.news fordert der Artikel nicht dazu auf, Kubernetes, Prometheus, OpenTelemetry, Istio oder OPA zu ersetzen. Im Gegenteil: Seine Argumentation lautet, dass diese Werkzeuge und Praktiken die Ergebnisse von zwei Jahrzehnten Erfahrung im Betrieb von Software darstellen, ihre Nutzungskosten hinsichtlich Kontext, Arbeitsschritten und Komplexität Agenten jedoch zu Abkürzungen verleiten. Der vorgeschlagene Lösungsansatz besteht darin, Betriebserfahrung maschinenlesbar nutzbar zu machen: deklarative Schnittstellen, mit denen der Agent deterministisch umgehen kann, Policy-Engines, die ein fehlerhaftes Manifest vor seiner Bereitstellung ablehnen, sowie Reconciliation-Schleifen, die die Ausgaben des Agenten überwachen, so wie sie auch Menschen zur Disziplin anhalten.
Neue Entwickler brauchen Schutzvorkehrungen, keinen Ausschluss
Grinstein ist der Ansicht, dass die steigende Zahl von Software-Erstellern außerhalb des Berufsstands nicht zwangsläufig eine schlechte Nachricht ist. Ein Betriebsleiter, Vertriebsmitarbeiter oder Designer verfügt über unmittelbares Wissen über das Problem und muss es nicht mehr durch Dokumente, Anforderungen und Tickets weitergeben, die einen Teil ihrer Bedeutung verlieren können, bevor sie den Ingenieur erreichen. Der aktuelle Produktionsprozess mit Git, YAML, Continuous-Integration-Gates und Prüflisten wurde jedoch grundsätzlich für Entwickler konzipiert.
Der Autor vergleicht die gegenwärtige Phase mit der Verbreitung persönlicher Geräte in Unternehmensnetzwerken um das Jahr 2010. Ein vollständiges Verbot führte damals dazu, dass IT-Abteilungen umgangen wurden, während Governance und klare Richtlinien erfolgreich dabei halfen, das Phänomen zu integrieren. Entsprechend schlägt er vor, „intuitionsbasierte Programmierer“ als gleichberechtigte Beteiligte zu behandeln und zugleich Sicherheits- und Betriebsschutzvorkehrungen innerhalb des vorgezeichneten Pfads beizubehalten, statt sie in Tore zu verwandeln, die sie an der Beteiligung hindern.
Die Schlussfolgerung, die die Quelle belegt, lautet nicht, dass Cloud-Native-Infrastruktur überholt sei, sondern dass ihre Standards für KI-Agenten und Nichtentwickler verständlich und ausführbar werden müssen. Die offene Frage ist, ob Plattformwerkzeuge dies erreichen können, ohne durch eine Vereinfachung die Schutzmechanismen zu entfernen, die eine Anwendung überhaupt erst produktionsfähig machen.