Code Review 2026: Drei Wege. Gleiche Zeit. Anderes Ergebnis.
Zeit verschwindet nicht. Sie wandert zwischen Vorbereitung, Erstellung und Nacharbeit.
Code Review in CI/CD
Tools, Reviews und Tests prüfen an definierten Punkten. Das bleibt wertvoll. SAST, DAST, SCA und Pentest liefern Evidenz, die keine KI ersetzt. Aber jede Prüfung sieht nur ihren Ausschnitt. Die Frage nach dem Zusammenspiel beantwortet keine davon automatisch und bedeutet einen nicht unerheblichen und unberechenbaren Zusatzaufwand. Gerade bei Großprojekten, wo verschiedenste Anforderungen von Business, Technik, Normen, Compliance und Legal mit unterschiedlichen Partnern und Lieferanten Software erstellen, wo auch Intellectual Property und Fähigkeiten eine Rolle spielen, wird die Prüfung zum strategischen Bottleneck mit einer unbekannten Anzahl an Blindspots. Das Risiko von „Drift“ entsteht. Und so werden eigentlich „verbotene Funktionen“, weil ohne Kontext und ohne Dokumentation, eingebaut, bei der Prüfung nicht erkannt und entwickeln sich zum Business Risk.
Vibe Code und LLM Code Review
Schnell produziert, spät verstanden. Effizienzansprüche und auch Early-Access Mentalität zur frühzeitigen Monetarisierung sind durch KI-Unterstützung heute realistisch, aber haben auch ihre Tücken. Wir haben eine bewusst verwundbare Node.js-App (Test für Erkennung von Vulnerabilities, Open Source Quelle) mit identischem Prompt und ohne jeden Kontext durch mehrere LLMs geschickt, um zu verstehen, welche Auswirkungen das hat.
→ Von 8 bekannten Schwachstellen im File fanden die Reviews zwischen 3 und 8.
→ Dazu kamen bis zu 9 zusätzliche Befunde mit unterschiedlichem Schweregrad.
→ Nach der Kontextprüfung blieben 4 handlungsrelevante Findings.
Der übrigen Findings: eine Architekturentscheidung (Risk Acceptance) , ein Honeypot (bewusst eingebaut), eine kompensierende MFA-Kontrolle (Risk Compensation), ein weiteres akzeptiertes Risiko. Ohne den Kontext werden False Positives zum Daily Business. Die Klärung dieser verschwindet aber nicht. Sie wartet im Backlog. Ohne Requirements und ohne Erkenntnis der Intention hinter den Codezeilen, misst man gegen alles, was auffällig ist, denn praktisch stellt alles ein Risiko dar. Jedes Mal. Immer wieder. Daher der Begriff „Finding Produktion“. Das ist auch eine gute Antwort auf die Frage „Ja, wo ist sie denn nun, die Produktivität durch KI?“ – auch hier wird die Prüfung zum strategischen Bottleneck, wegen überquillender Backlogs.
Intentional Code Review
Erst das Requirements-Gerüst bauen: Anforderungen, Bedrohungen, Assets, Compliance, Akzeptanzkriterien, Lastenheft und Vertrag. Das kostet vorne mehr Zeit, aber dafür prüft das Review danach gegen einen Maßstab anstatt gegen ein generisches „Was ist hier falsch?“. Es geht um Kontext – die neue Superpower. J-ede bestätigte Entscheidung fließt als Prozess-Gedächtnis in die nächste Änderung zurück. Kurzum: Die Requirements sind ein Aufwand, den man nur am Beginn erledigt, und der durch bewusstes Lernen und Nachschärfen immer besser performed und eher als 1x Aufwand zu verstehen ist.
Die Tabelle unten ist ein qualitatives Zielbild, keine Messung. Sie zeigt, wo der Aufwand jeweils landet.
Unterm Strich: Produktivität misst sich am verifizierten Deliverable, nicht am ersten Build.
KI findet mehr und schneller. Der Lifecycle sagt uns, was davon zählt.
Mehr dazu: https://aigis.one/codex
**Bilder KI generiert und Text wie Layout mit Hilfe von KI strukturiert.
#CodeReview #AppSec #SSDLC #KI #Cybersecurity #DevSecOps