원본 영상을 바탕으로 AI의 도움을 받아 작성했습니다. 원본 영상이 기준입니다.
Log in to leave a comment
아직 작성된 글이 없습니다
Generative KI produziert Code mit erschreckender Geschwindigkeit. Das wirkliche Problem für Senior Engineers und Technical Leads liegt jedoch woanders: in der kognitiven Überlastung, die entsteht, wenn man Code, den eine Maschine in einer Sekunde geschrieben hat, verifizieren und in bestehende Systeme integrieren muss. Der DORA 2025-Bericht von Google Cloud zeigt, dass die Einführung von KI zwar die Bereitstellungsfrequenz erhöht, aber gleichzeitig die Systeminstabilität verschärft. Das bedeutet, dass Menschen die ganze Nacht damit beschäftigt sind, die „Senkgruben“ zuzuschütten, die durch blindes Kopieren und Einfügen von Code entstanden sind. Ein manueller Prozess, bei dem Menschen jede Zeile Code lesen und debuggen, kann mit dieser Geschwindigkeit nicht Schritt halten. Um zu verhindern, dass der Code zu technischem Abfall wird, muss man von Anfang an eine Architekturumgebung schaffen, die der von der KI erstellten Logik misstraut, und die Verifizierung automatisieren.
Der von der KI vorgeschlagene Code kennt den Geschäftskontext nicht. Selbst wenn er oberflächlich betrachtet in Ordnung aussieht, bricht er oft subtile Regeln innerhalb der Domäne. Daher sollte die von der KI erstellte Logik wie ein externes System behandelt werden, das jederzeit ausfallen kann. Aus diesem Grund ist es unerlässlich, bereits in der Entwurfsphase einen Anti-Corruption Layer (ACL) zu implementieren, der eine klare Abstraktionsschnittstelle definiert, um zu verhindern, dass Schadstoffe in den bestehenden Domänenbereich gelangen.
Es reicht nicht aus, lediglich die Softwarearchitektur zu trennen. Es besteht die ständige Gefahr, dass KI-Code bösartige Bibliotheken importiert oder das lokale Dateisystem durcheinanderbringt. Das Beispiel von Stripe bei der Entwicklung von „Minions“, einem autonomen Agentensystem, ist aufschlussreich: Der KI-generierte Code wird in einer isolierten virtuellen Maschine ausgeführt, die vom Host-Rechner abgeschirmt ist, und der Netzwerkzugriff wird auf Protokollebene blockiert. Um die Produktionsumgebung zu schützen, müssen innerhalb der CI/CD-Pipeline Steuermechanismen auf Kernelebene eingeführt werden.
Es muss eine Zero-Trust-Ausführungsumgebung geschaffen werden, die verhindert, dass unzuverlässiger Code überhaupt nach außen gelangt. Die Reduzierung der Reaktionszeit bei Systemausfällen ist dabei ein willkommener Nebeneffekt.
Es ist gefährlich, wenn Entwickler Hunderte von Codezeilen, die die KI ausgespuckt hat, mit bloßem Auge überprüfen. Wenn das Gehirn ermüdet, greift ein Automatisierungs-Bias, bei dem man Code, der oberflächlich korrekt aussieht, einfach durchwinkt. Mängel in der von Maschinen erstellten Logik sollten nicht von Menschen, sondern von ausführbarem Testcode erkannt werden. Man muss die Reihenfolge umkehren und die KI zwingen, zuerst Testfälle zu erstellen, die die Funktionsspezifikationen definieren, bevor sie den eigentlichen Implementierungscode schreibt. Dies erzwingt Regeln, die fünf Kategorien definieren: Normaler Ablauf, Grenzbedingungen, Ausnahmebehandlung, anormale Eingaben und Szenarien zur Fehlerbehebung.
Die Abdeckung durch manuell per Prompt erstellten Code ist nicht sehr hoch. Laut den Betriebsdaten der Agenten von Diffblue lag die Testabdeckung, die menschliche Ingenieure im Dialog mit der KI erreichten, im Durchschnitt bei nur 32 %. Wenn hingegen die statische Quellcode-Analyse und der Laufzeit-Sandbox-Build als automatisierte Test-Agenten gebündelt wurden, konnte ohne menschliches Eingreifen eine durchschnittliche Regressionstest-Abdeckung von 81 % erreicht werden. Eine Struktur, in der eine Maschine die andere überwacht, ist wesentlich lückenloser.
Für Logiken, bei denen Ausgabestrings nicht einfach 1-zu-1 verglichen werden können – wie bei Übersetzungen natürlicher Sprache oder dynamischen JSON-Objekten – wird die LLM-as-a-Judge-Technik eingesetzt. Frameworks wie AgentProctor werden in die Testinfrastruktur integriert und Bewertungsvorlagen in das Beurteilungsmodell eingespeist. Wenn man ein System schafft, bei dem ein Bewertungsmodell quantitativ feststellt, ob der zurückgegebene Code Sicherheitsbeschränkungen verletzt, und bei Nichteinhaltung den Build stoppt, können „Guardrails“ errichtet werden, die den Menschen den Schmerz ersparen, Rohcode selbst durchforsten zu müssen.
Je mehr Code von Maschinen geschrieben wird, desto mehr kognitive Schulden häufen sich im System an. Es kommt zu bizarren Situationen, in denen der Code zwar läuft, aber niemand weiß, warum er so läuft. Da KI-Tools sich nur darauf konzentrieren, das unmittelbare, lokale Problem zu lösen, verursachen sie bei einem Refactoring des gesamten Systems nach einigen Monaten enorme Kosten. Um die hinter dem Code verborgenen Designabsichten zu bewahren, sollte der Agent Decision Record-Prozess als Teamstandard eingeführt werden. Dabei geht es darum, in einem maschinenlesbaren Format festzuhalten, warum eine bestimmte Struktur gewählt und welche Alternativen verworfen wurden.
Da das menschliche Gedächtnis unzuverlässig ist, sollte auch die Kennzeichnung, dass der Code von einer KI stammt, in die Commit-Historie automatisiert werden. Tools wie die git-ai-Erweiterungsbibliothek ermöglichen es, Beiträge von Agenten in einem unabhängigen Metadatenpfad wie refs/notes/ai zu erfassen, ohne den Hauptteil der Commit-Nachrichten zu verunreinigen. Der Aufbau der Git-Pipeline ist klar:
pre-commit hooks in der lokalen Entwicklungsumgebung und auf dem CI-Server-Repository.AI-Footprint: model=gpt-4o), sowie Informationen zum Co-Autor zwingend in die Metadaten eingefügt.Durch die Anhäufung solcher Metadaten lässt sich in Echtzeit eine Lieferkettenstatistik erstellen, die aufzeigt, bei welcher KI-Modellversion sich bestimmte Fehler oder Sicherheitslücken gehäuft haben. Dies ist eine Sicherheitsvorkehrung, die den „Höllentrip“ verhindert, bei dem man zehntausende Zeilen Code durchsuchen muss, weil keine Übergabedokumentation vorhanden ist.
Wenn ungefiltert generierter Code die Pull-Request-Warteschlange überschwemmt, wird das manuelle Code-Review gelähmt. Um die Produktivität aufrechtzuerhalten, muss der Review-Prozess in ein maschinenzentriertes, deterministisches Feedback-Gate und eine menschenzentrierte Bewertung der strukturellen Auswirkungen aufgeteilt werden. Ein dreistufiges Qualitätssicherungs-Gate, das sofort nach dem Hochladen des Codes in die CI-Umgebung greift, ist die Alternative:
Erstens gibt es ein High-Speed-Linting-Gate, das innerhalb von 5 Sekunden über die Gültigkeit der Syntaxstruktur und die Übereinstimmung der Typ-Hinweise entscheidet. Wenn der Code hier aussortiert wird, erfolgt eine sofortige Ablehnung. Zweitens wird ein selektiver Impact-Test durchgeführt, bei dem nur die Unit-Tests ausgeführt werden, die innerhalb des Einflussbereichs der geänderten Dateien liegen (ca. 2 %).
Drittens wird bei einem Testfehler eine automatisierte Korrekturschleife gestartet, die den Fehler-Stack als Kontext an den Agenten zurückgibt, damit dieser den Fehler bis zu zweimal selbst korrigieren kann.
Nur die sauberen Code-Fragmente, die diese automatisierte Korrekturschleife durchlaufen haben, erscheinen auf dem Bildschirm eines menschlichen Senior-Entwicklers. Der menschliche Reviewer verschwendet keine Zeit mehr mit der Suche nach Tippfehlern oder dem Hinweis auf Konventionen. Die Zeit der Senior Engineers sollte ausschließlich in die makroskopische Kontrolle fließen: die Prüfung, ob durch die direkte Kopplung zwischen Komponenten Domänengrenzen verletzt wurden; die Sicherstellung, dass bei plötzlichen Verkehrsspitzen ein Backpressure-Mechanismus zum Schutz der darunter liegenden Persistenzschicht vorhanden ist; und die Analyse der strukturellen und infrastrukturellen Effizienz, wie etwa bei SQL N+1-Performance-Problemen. In einer Flut von hereinbrechendem Code ist dies der einzige Weg, das Produktionssystem zu schützen.