Die «Tag 2» AI-Herausforderung

Leitplanken, Kultur und der neue Lebenszyklus der Softwareentwicklung

TL;DR

Das Software-Engineering erlebt gerade einen massiven Wandel, da autonome KI-Agenten sich von experimentellen Werkzeugen zu aktiven Akteuren in der Codebasis entwickeln. Ohne einen modernisierten Softwareentwicklungszyklus (SDLC) können diese zwar äusserst leistungsfähigen, aber von Natur aus chaotischen Agenten schnell unüberwindbare technische Schulden verursachen und operative Risiken mit sich bringen. Dieser Beitrag beleuchtet die «Day 2»-Realität von KI-generiertem Code, den Engpass beim Code Review, die Gefahr unstrukturierter AI-Auftragsvergabe über Slack und wie Unternehmen einen sicheren, deterministischen Entwicklungszyklus aufbauen müssen. Indem sie klare Leitplanken festlegen und die Kultur in Richtung Problemdefinition verlagern, können Organisationen Multi-Agenten-Systeme sicher zähmen und ihre Teams befähigen, die tatsächliche Innovationsgeschwindigkeit voranzutreiben, anstatt nur die Geschwindigkeit der Codegenerierung zu maximieren.

Der «Wilde Westen» der Multi-Agenten-Systeme

KI-Agenten arbeiten mit unglaublicher Geschwindigkeit, doch ihnen fehlt das intuitive Verständnis eines menschlichen Entwicklers für den «Auswirkungsbereich». Wir befinden uns nicht mehr im Zeitalter der einfachen Autovervollständigung; Multi-Agenten-Systeme haben heute die Aufgabe, Codebasen eigenständig zu erkunden, Logik zu ändern und Änderungen zu übernehmen.

Wenn man ihnen freien Lauf lässt, verhalten sich diese Agenten unvorhersehbar. Sie könnten kritische Authentifizierungsabläufe ändern, überflüssige Datenbankmigrationen durchführen oder versehentlich Zugangsdaten in Anwendungsprotokollen offenlegen. Das Kernproblem, mit dem wir heute konfrontiert sind, ist keine existenzielle Science-Fiction-Bedrohung, sondern ein äusserst praktisches technisches Problem: eine chaotische Ausführung, die alle Umgebungen – von der lokalen Entwicklung über das Staging bis hin zur Produktion – destabilisiert und dabei die üblichen Sicherheitsmassnahmen komplett umgehen kann.

Die Realität von «Tag 2» und die glänzende Hülle

Das Generieren von Code ist mittlerweile der einfachste und kürzeste Teil der Softwareentwicklung geworden. Die wirklichen Herausforderungen liegen in den «Tag 2»-Aufgaben: dem Reviewen, Testen, Sicherheitsaudits und der langfristigen Wartung dieses Codes.

Eine der problematischen Eigenschaften von KI-generiertem Code ist, dass er auf den ersten Blick fast immer perfekt aussieht. Er wird oft in einer «glänzenden Hülle» geliefert – syntaktisch einwandfrei, sauber formatiert und begleitet von glaubwürdigen, gut geschriebenen Kommentaren. Doch unter dieser makellosen Oberfläche kann die KI subtile logische Fehler, architektonische Anti-Patterns oder unsichere Datenverarbeitung einschleusen. Um diese tiefsitzenden Probleme zu erkennen, muss ein erfahrener Entwickler tief graben, die Prozesspfade nachvollziehen und den grösseren Systemzusammenhang wirklich verstehen.

Das führt zu einem massiven Ressourcenengpass für die Entwicklerteams.

Stellt euch ein typisches Entwicklerteam aus vier Leuten vor. Jeder Entwickler koordiniert eine ganze Horde hochmotivierter KI-Agenten, die täglich 10 Pull Requests (PR) generieren – also insgesamt 40 PRs für das Team. Da KI-Code einer gründlichen, kritischen Prüfung bedarf, um hinter seine glänzende Fassade zu blicken, dauert eine sorgfältige Überprüfung mindestens 45 Minuten pro PR. Um diese 40 PRs zu mergen, benötigt das Team täglich 30 Stunden. Das entspricht einer Arbeitsbelastung von 7.5 Stunden pro Entwickler und Tag ausschliesslich für Code Review.

Wenn eure Entwickler ihren gesamten 8-Stunden-Arbeitstag damit verbringen, einfach nur die Arbeit der KI zu überprüfen, ist das nicht nur anstrengend und demotivierend. Die natürliche Folge ist eine Kultur des «Durchwinkens», in der Entwickler nur einen flüchtigen Blick auf die glänzende Verpackung werfen, die Änderungen genehmigen und stillschweigend zulassen, dass sich Sicherheitslücken und massive technische Schulden in der Codebasis ansammeln.

Weniger ist mehr: Der Einstein-Ansatz für AI-Engineering

«Hätte ich eine Stunde Zeit, um ein Problem zu lösen, und hinge mein Leben von der Lösung ab, würde ich die ersten 55 Minuten damit verbringen, die richtige Frage zu formulieren; denn sobald ich die richtige Frage kenne, könnte ich das Problem in weniger als fünf Minuten lösen.» — Albert Einstein

Die moderne Bequemlichkeit von Slack-Ops verschärft den Engpass beim Review. Die Möglichkeit, einen Agenten mit einer kurzen Slack-Nachricht wie «Untersuche und behebe diesen Bug» sofort auf eine Aufgabe anzusetzen, fühlt sich unglaublich schnell an, trägt aber aktiv zur Realität von «10 PRs pro Entwickler und Tag» bei – einem chaotischen Gewirr aus parallelen, schlecht abgegrenzten Aufgaben. Wenn Agenten beim ersten Gedanken an eine Aufgabe sofort losgeschickt werden, verursachen sie Unruhe, Doppelarbeit und überfluten die Pipeline mit spekulativen Korrekturen.

Um im KI-Zeitalter zu bestehen, braucht Ingenieurskultur keinen radikalen Paradigmenwechsel – sie muss zu ihren Wurzeln zurückkehren. Die Lösung liegt darin, Dieter Rams’ berühmtes Designprinzip «weniger, aber besser» mit Einsteins Ansatz zur Problemlösung zu kombinieren. Teams sollten der Versuchung widerstehen, auf jede Idee oder jedes Problem sofort einen KI-Agenten anzusetzen. Stattdessen sollten wir den Einstein-Ansatz verinnerlichen und den Grossteil unserer Zeit damit verbringen, das eigentliche Problem und die zugrunde liegenden Nutzerbedürfnisse gründlich zu verstehen, die genauen Grenzen zu definieren und erst dann einem Agenten eine klar abgegrenzte, eng gefasste Aufgabe zuzuweisen.

Man könnte natürlich dagegen argumentieren. Wenn die Code-Generierung durch KI praktisch kostenlos ist, warum dann nicht einfach die Brute-Force-Methode anwenden? Warum nicht die Agenten chaotisch experimentieren lassen – indem sie Dutzende von uneingeschränkten, spekulativen Lösungen auf ein Problem anwenden, um zu sehen, was tatsächlich kompiliert wird und funktioniert? Das geht schon. Aber wenn ihr diesen Brute-Force-Ansatz verfolgt, können menschliche Entwickler nicht mehr als Qualitätsfilter fungieren. Das führt direkt wieder zum Review-Engpass. Wenn ihr Agenten ermöglichen wollt, schnell zu experimentieren, müsst ihr eine automatisierte Infrastruktur aufbauen, die den schlechten Code gnadenlos aussortiert.

Infrastruktur als Leitplanke

Wenn Organisationen KI sicher skalieren wollen, müssen sie von einer richtlinienbasierten Sicherheit (bei der Agenten aufgefordert werden, sich korrekt zu verhalten) zu einer deterministischen Infrastruktur übergehen (die es ihnen physisch unmöglich macht, sich falsch zu verhalten). Agenten benötigen sterile, isolierte Umgebungen, in denen Fehler keinerlei Konsequenzen haben.

• Immutable Execution: Wenn ein Agent halluziniert oder ausser Kontrolle gerät, muss dies in einer kurzlebigen microVM geschehen, die sofort zerstört werden kann, um einen Ausbruch aus der “Sandbox” ins Host-Netzwerk zu verhindern.
• Credential Brokering: Agenten müssen auf geschützte Tools und APIs zugreifen können, aber ohne dabei jedoch jemals Zugangsdaten oder Schlüssel im Klartext zu speichern oder einzusehen. Indem Anfragen beispielsweise über einen sicheren Proxy geleitet werden, lässt sich das Risiko ausschliessen, dass ein Agent einen API-Schlüssel in eine Logdatei oder an einen externen LLM-Anbieter weitergibt.
• Automated Verification: In diesen isolierten Ausführungsumgebungen müssen robuste, automatisierte End-to-End-Tests laufen, um logische Fehler und fehlerhafte Zustände zu erkennen, bevor ein menschlicher Reviewer überhaupt benachrichtigt wird.

Das gesamte Produktteam stärken

Wenn die zugrunde liegende Infrastruktur absolute Sicherheit bietet und die Agent-Aufgaben von Menschen sorgfältig definiert werden, wandelt sich die KI von einem chaotischen Disruptor zu einem zuverlässigen, unternehmensweiten Motor.

Ein deterministischer KI-Entwicklungszyklus demokratisiert die Produktentwicklung. Da die Sicherheitsvorkehrungen sicherstellen, dass niemand versehentlich die Produktion lahmlegen oder Kundendaten preisgeben kann, können Produktmanager, QA-Tester und UX-Designer sicher mit den Agenten interagieren. Sie können neue Funktionen prototypisieren, komplexe Geschäftslogik testen oder Frontend-Komponenten in streng isolierten Vorschauumgebungen anpassen, ohne dass ein erfahrener Entwickler ihnen dabei über die Schulter schauen muss. Und wenn die Änderungen zufriedenstellend sind, landen sie über einen sicheren und deterministischen Weg in der produktiven Umgebung.

Den SDLC für autonome KI neu überdenken

Die Skalierung von KI innerhalb einer Engineering-Organisation ist nicht mehr nur eine Frage des Prompt-Engineering. Es geht vielmehr um Infrastruktur und Disziplin. Unternehmen müssen ihre aktuellen CI/CD-Pipelines, ihr Secret-Management und ihre Kultur der Code-Reviews kritisch unter die Lupe nehmen.

Der Weg nach vorne erfordert, dass wir uns von der Eitelkeitskennzahl der Code-Generierungsgeschwindigkeit verabschieden. Stattdessen müssen wir uns darauf konzentrieren, eine streng gesicherte, deterministische AI-Infrastruktur und Prozesse aufzubauen, in der Menschen die Probleme definieren und Agenten innerhalb strenger Grenzen agieren. Indem wir unseren Software Development Lifecycle (SDLC) modernisieren, um autonome Agenten zu unterstützen, können wir KI-Fähigkeiten nachhaltig in konkrete Produktentwicklungs- und Innovationsgeschwindigkeit ummünzen.