Ein Sprachmodell kann in Sekunden Code vorschlagen, eine Fehlermeldung erklären oder eine Testidee formulieren. Das ist beeindruckend und in vielen Situationen nützlich. Software ist jedoch kein Text, der allein durch Plausibilität richtig wird. Sie läuft mit echten Daten, echten Berechtigungen und echten Folgen. Je schneller AI Code erzeugt, desto wichtiger wird ein Prozess, der Fehler sichtbar macht, bevor sie zu Abhängigkeiten werden.
KI ist ein Verstärker, kein Senior Engineer
AI-Werkzeuge erkennen Muster in Code und schlagen auf dieser Grundlage wahrscheinlich passende Fortsetzungen vor. Sie kennen aber nicht automatisch die Ziele des Produkts, die nicht dokumentierten Randbedingungen eines Systems oder die Verantwortung, die mit einer Datenverarbeitung verbunden ist. Ein Vorschlag kann syntaktisch korrekt sein und trotzdem die falsche Schnittstelle, ein unsicheres Standardverhalten oder eine unwartbare Abkürzung wählen.
Die richtige Frage lautet deshalb nicht: Kann die KI diese Funktion programmieren? Sondern: Welche Arbeit kann sie vorbereiten, ohne dass das Team Verständnis und Kontrolle verliert? Diese Unterscheidung trennt echte Produktivität von einer bloßen Verschiebung der Kosten in spätere Fehlersuche, Sicherheitsarbeit und Betrieb.
Wo AI Entwicklung sinnvoll beschleunigt
Bei klar begrenzten Aufgaben kann ein Modell viel mechanische Arbeit abnehmen. Es kann Boilerplate erzeugen, vorhandene Codepfade erklären, Testdaten variieren, Dokumentationsentwürfe erstellen oder eine Migration in kleine Schritte zerlegen. Auch bei Logs und Fehlermeldungen kann eine Zusammenfassung helfen, schneller eine Hypothese zu bilden.
Der wichtigste Zusatz lautet: Die Aufgabe muss klein genug sein, dass ein Mensch das Ergebnis verstehen und prüfen kann. Ein Team, das eine Änderung in einen überschaubaren Diff, eine aussagekräftige Testausführung und eine klare Rückfallmöglichkeit übersetzt, gewinnt Tempo ohne die Kontrolle aufzugeben.
- Boilerplate, Adapter und wiederkehrende Testfälle für klar beschriebene Schnittstellen vorbereiten.
- Bestehenden Code erklären und mögliche Abhängigkeiten oder Randfälle sichtbar machen.
- Refactorings und Datenmigrationen in überprüfbare, kleine Schritte zerlegen.
- Dokumentation, Changelogs, Beispiele und interne Übergaben als Entwurf beschleunigen.
- Fehlerberichte und Logs strukturieren, ohne die Originaldaten oder Beweise zu ersetzen.
Wo sie Schaden verursachen kann
Das größte Risiko ist nicht nur ein offensichtlicher Fehler. Gefährlicher ist Code, der vernünftig aussieht und deshalb zu wenig geprüft wird. Ein Modell kann eine API erfinden, eine veraltete Bibliotheksversion verwenden, Berechtigungen zu großzügig setzen oder eine Eingabevalidierung auslassen. Wenn Tests ebenfalls automatisch erzeugt werden, können sie die Implementierung bestätigen, statt das gewünschte Verhalten unabhängig zu hinterfragen.
Dazu kommen organisatorische Risiken. Quellcode, Kundendaten, Zugangsdaten oder interne Architektur dürfen nicht ungeprüft in ein externes Modell kopiert werden. Herkunft und Lizenz von vorgeschlagenem Code müssen nachvollziehbar bleiben. Und wenn ein Team nicht mehr erklären kann, warum eine wichtige Entscheidung getroffen wurde, ist Geschwindigkeit kein Fortschritt, sondern eine neue Form von technischer Verschuldung.
- Halluzinierte APIs, falsche Annahmen und veraltete Beispiele können unbemerkt in Produktion gelangen.
- Sicherheitslücken entstehen durch fehlende Validierung, zu breite Rechte oder unsichere Defaults.
- Vertrauliche Daten und Secrets können durch unbedachte Prompts offengelegt werden.
- Unklare Herkunft kann Lizenz-, Urheber- und Lieferkettenfragen auslösen.
- Automatisierte Tests können Lücken verdecken, wenn sie nur den erzeugten Code wiederholen.
- Zu große, schwer erklärbare Änderungen erhöhen Betriebsrisiko und langfristige Wartungskosten.
Sicherheit und Qualität müssen im Prozess liegen
Verantwortungsvolle AI-Nutzung ist kein Appell an besondere Vorsicht einzelner Entwickler. Sie braucht Leitplanken, die für jeden Vorschlag gelten: keine Secrets oder personenbezogenen Daten in nicht freigegebenen Tools, minimale Berechtigungen, reproduzierbare Builds, automatisierte Tests, statische Analyse, Dependency- und Secret-Scans sowie eine menschliche Prüfung mit klarer Zuständigkeit. Die OWASP-Risiken für LLM-Anwendungen und das NIST-Profil für generative AI zeigen, warum diese Kontrollen nicht erst nach einem Vorfall eingeführt werden sollten.
Auch die Änderungsgröße ist ein Sicherheitswerkzeug. DORA beschreibt kleine Batches als eine Fähigkeit, die Teams schneller testen, überwachen und korrigieren lässt. Ein kleiner Pull Request mit einem klaren Ziel ist nicht nur leichter zu reviewen. Er macht auch sichtbar, welche Annahme die AI unterstützt hat und wie ein Fehler sicher zurückgenommen werden kann.
- Jeden Vorschlag in einen kleinen, verständlichen Diff mit Tests und Review zerlegen.
- Automatische Prüfungen unabhängig vom Modell ausführen: Tests, Linter, Typen, Security- und Dependency-Scans.
- Produktionszugriffe nach dem Least-Privilege-Prinzip begrenzen und Secrets aus Prompts fernhalten.
- Abhängigkeiten, Lizenzen, Quellen und Modellannahmen vor der Übernahme prüfen.
- Monitoring, Rollback und ein klarer Owner gehören vor dem Launch zur Definition of Done.
Eine praktikable Teamregel
Ein Team muss nicht jede Nutzung von AI verbieten oder jedes Ergebnis manuell neu schreiben. Es sollte festlegen, welche Aufgaben als Unterstützung erlaubt sind, welche Daten geschützt werden müssen und wann eine zweite Person zwingend prüft. Für eine harmlose Dokumentationsstruktur gelten andere Regeln als für Authentifizierung, Zahlungen, Gesundheitsdaten oder produktionsnahe Infrastruktur.
Ein guter Standard ist einfach genug, um im Alltag befolgt zu werden: AI darf Vorschläge machen, aber nicht unbemerkt freigeben. Jede wichtige Änderung braucht einen verständlichen Zweck, überprüfbare Kriterien und eine Person, die sie verantwortet. So wird AI zu einem Werkzeug für mehr Durchsatz, ohne dass das Team sein technisches Urteil outsourct.
RECHERCHEQUELLEN