🤝 Das starke Argument

“KI-generierter Code durchläuft denselben Review-Prozess wie jeder andere Code.” Diesen Satz höre ich in fast jeder Diskussion über die Risiken von Copilot, Cursor und Co. Er klingt überzeugend, denn wer würde schon Code ohne Review in Produktion bringen?

⚖️ Was daran stimmt

Die meisten Teams haben tatsächlich Review-Prozesse etabliert, und statische Analyse fängt offensichtliche Fehler zuverlässig ab. KI-generierter Code ist syntaktisch sauber, oft sogar sauberer als menschlicher. Die Werkzeuge produzieren funktionierenden Code - das ist ihr Versprechen, und sie halten es oft.

🔍 Wo es brüchig wird

Veracode hat den Output von über 100 LLMs untersucht und festgestellt, dass 45% des generierten Codes Schwachstellen aus den OWASP Top 10 enthält. Bei Cross-Site-Scripting versagen die Modelle in 86% der Fälle, und Java-Code erreicht eine Fehlerquote von über 70%. Trotz aller Fortschritte bei der Codegenerierung hat sich die Sicherheitsqualität über die Zeit nicht verbessert.

Das eigentliche Problem ist dabei nicht der einzelne fehlerhafte Baustein. Es ist die Menge. Inzwischen berichten 42% der Entwickelnden, dass mindestens die Hälfte ihrer Codebasis KI-generiert ist. Gleichzeitig zeigen Studien der Georgetown University, dass Entwickelnde mit KI-Unterstützung nachweislich unsichereren Code schreiben - nicht weil die Werkzeuge schlecht wären, sondern weil das Vertrauen in den Output die Sorgfalt beim Review untergräbt. 81% haben Sicherheitsbedenken, und trotzdem nutzen alle die Werkzeuge. Tempo schlägt Vorsicht.

💡 Die unbequeme Wahrheit

Wer KI-Coding-Tools einsetzt, spart Zeit bei der Erstellung und müsste sie eigentlich in Review investieren. In der Praxis geschieht das selten. Die Werkzeuge sind nicht das Problem - unser Umgang mit ihrem Output ist es. Wer das Code-Volumen vervielfacht, ohne die Review-Kapazität mitzuziehen, fährt nicht schneller ans Ziel. Er schaltet in der Nacht bei höherem Tempo die Scheinwerfer aus.

📚🔍