KI-Code: Warum der Hype an der Realität vorbeirauscht

Letzte Woche habe ich zugeschaut, wie ein Kollege npm test auf einem Pull-Request ausgeführt hat, der von einem KI-Assistenten "implementiert" wurde. Die Tests sind nicht einfach nur fehlgeschlagen – sie sind spektakulär eingefahren. Fehlermeldungen, bei denen selbst ein Junior-Entwickler peinlich berührt wäre. Keine API-Keys konfiguriert. Endpoints, die JSON in völlig falschem Format zurückgeben. Authentication-Middleware, die rein gar nichts authentifiziert.

Die Commit-Nachricht lautete: "User Authentication Flow implementiert 🍕"

Dieses Pizza-Emoji hätte uns stutzig machen sollen.

Das ist keine Geschichte darüber, dass KI schlecht ist. KI-Code-Generierung hat meine tägliche Arbeit wirklich verbessert. Das hier ist eine Geschichte über die gefährliche Illusion von Kompetenz – das Uncanny Valley selbstsicherer KI-Ausgaben, die so poliert aussehen, dass niemand auf die Idee kommt, sie zu hinterfragen. Bis dann um 2 Uhr nachts in Production alles abraucht.

Das Ja-Sager-Problem

Was kaum jemand thematisiert: KI-Coding-Assistenten sind die ultimativen Jasager. Sie pushen nicht zurück. Sie stellen keine Clarifying Questions – nicht mal um 3 Uhr nachts, obwohl man die selbst hätte stellen sollen. Sie generieren, was man von ihnen verlangt hat – oder das, was sie denken, dass man gemeint hat. Mit dem unverdienten Selbstvertrauen eines Berufseinsteigers.

Dein Senior Developer, der vielleicht gesagt hätte "Nee, das ist ne schlechte Idee, weil…" – diese Person existiert nicht in deiner IDE. Da bist nur du. Ein Autocomplete-Engine. Und 10.000 Zeilen Code, die "richtig aussehen", bis man sie tatsächlich ausführt.

Das ist die Falle. Der Weg des geringsten Widerstands führt immer dazu, KI-Vorschläge zu akzeptieren. Und wie jeder Muskel, den man nicht trainiert, verkümmert die Fähigkeit, architektonische Entscheidungen zu bewerten – leise, bis man merkt, dass man seit Monaten schlechten Code abnickt.

Das Test-Defizit

Hier eine Zahl, die jeden Engineering Manager aufwecken sollte: Studien zeigen, dass Entwickler weniger als 20% ihrer Zeit tatsächlich damit verbringen, das zu testen, was sie bauen. Jetzt legt KI-generierten Code oben drauf – und du hast das Rezept für eine Katastrophe.

Wenn KI Code generiert, dann immer ohne jemals diesen Code in deiner spezifischen Umgebung auszuführen. Ohne deinen spezifischen Datenbankzustand. Gegen deine spezifischen Third-Party-Dependencies. Der Code existiert im Vakuum – technisch korrekt, kontextuell bankrott.

Die Lösung ist nicht, KI abzuschalten. Die Lösung ist, pingelig zu werden bei einer simplen Praxis: Niemals Code mergen, den man nicht persönlich in der lokalen Umgebung getestet hat.

Ja, das ist langsamer. Ja, es fühlt sich an, als würde man gegen die KI-Produktivitätsgewinne ankämpfen. Aber mal ehrlich: Die versprochenen 10x-Engineering-Produktivitätssteigerungen? Die werden zum Nettominus, wenn du Bugs schneller verschiffst, als du sie fixen kannst.

Die kognitive Absturzkante

Denk an KI-Assistenz wie an einen Taschenrechner beim Mathematiklernen. Taschenrechner haben Menschen nicht schlechter in Mathe gemacht – sie haben uns von der Plackerei befreit, damit wir uns auf höhere Konzepte konzentrieren konnten. Aber wenn du nie schriftliche Division gelernt hast, verstehst du nicht, was der Taschenrechner eigentlich macht, wenn er dir eine Antwort gibt.

Genauso verhält es sich mit Softwareentwicklung. Wenn du zulässt, dass KI die "langweiligen Teile" übernimmt, ohne je zu verstehen, was diese Teile tun, erreichst du irgendwann den Punkt, an dem du nicht mehr beurteilen kannst, ob die KI-Ausgabe korrekt ist. Du nimmst einfach das Wort der Maschine – und das ist ungefähr so klug, wie ein Auto ohne auf die Straße zu gucken durch eine Baustelle fahren zu lassen.

Es geht nicht darum, Programmieren als artisanal Handwerk für Puristen zu bewahren. Es geht darum, die Fähigkeit zu behalten, katastrophale Fehler zu erkennen, bevor sie bei den Usern ankommen.

Den Mittelweg finden

Ich bin nicht anti-KI. Bei uns auf der Plattform nutzen wir selbst KI, um Entwicklern schnelleres Shippen zu ermöglichen. Die Tools sind fantastisch – solange sie als Verstärker menschlichen Urteilsvermögens eingesetzt werden, nicht als Ersatz dafür.

Die gesunde Beziehung zu KI-Coding sieht so aus:

• Nutze KI für Boilerplate, Scaffolding und erste Entwürfe
• Nutze KI um unbekannte APIs und Dokumentation zu erkunden
• Nutze NIEMALS KI als Ersatz dafür, deinen eigenen Codebase zu verstehen
• Teste IMMER, was KI produziert, bevor es Production berührt
• Behandle KI-Vorschläge wie Code-Review-Feedback – nützlicher Input, kein Evangelium

Der Entwickler, der diesen ungetesteten PR rausgehauen hat? Der war weder faul noch inkompetent. Der ist in eine Falle getappt, die gerade die gesamte Branche sich selbst buddelt: Die Verführung von Momentum über Qualität.

Ship fast, break things, move quick – das Mantra. Aber irgendwann haben wir vergessen, dass kaputte Dinge echtes Geld kosten. Echte Nutzer. Und echtes Vertrauen, das man erst wieder aufbauen muss.

Das Fazit

KI-Coding-Assistenten verhalten sich zu moderner Entwicklung wie die Rechtschreibprüfung zum Schreiben – nützliche Tools, die Tippfehler erwischen, aber nicht beurteilen können, ob dein Argument Sinn ergibt. Du brauchst immer noch das menschliche Gehirn, um zu fragen: "Sollten wir dieses Feature überhaupt bauen?" Und: "Löst das tatsächlich das Problem des Users?"

Die Entwickler, die in dieser neuen Ära thrive werden, sind nicht die, die am meisten KI nutzen. Es sind die, die KI strategisch einsetzen und dabei ihr fundamentales Engineering-Urteilsvermögen scharf halten. Diejenigen, die immer noch verstehen, was unter der Haube passiert – auch wenn sie nicht mehr jede einzelne Schraube von Hand drehen.

Die KI ist nicht das Problem. Die Annahme, dass KI menschliche Aufsicht überflüssig macht – das ist das Problem.

Also, ja, vibesCod dich ruhig durch das MVP. Aber bevor du auf Merge klickst, denk daran: Das Pizza-Emoji in der Commit-Nachricht wird nicht mehr da sein, wenn deine Nutzer um Mitternacht einen 500er kriegen.