Welche Fehler machen Entwickler beim Programmieren mit KI-Assistenten?

KI-Assistenten wie Copilot, Claude und die eingebauten Modelle von Cursor haben die Geschwindigkeit des Programmierens verändert. Sie haben nicht verändert, wie sorgfältig der Code überprüft werden muss. Die meisten Schäden, die ich durch KI-gestützte Programmierung gesehen habe, kommen aus einer Handvoll wiederholbarer Gewohnheiten, nicht aus den Modellen selbst.

Vorschläge akzeptieren, ohne sie zu lesen

Das größte Problem ist, einen Completion per Tab zu akzeptieren, weil er plausibel aussieht und kompiliert. Plausibel ist nicht dasselbe wie korrekt. Ich habe gesehen, wie ein vorgeschlagenes SQL-Query während eines Refactorings stillschweigend eine WHERE-Klausel fallen ließ, und die Person hat es akzeptiert, weil die Variablennamen passten. Wenn du nicht jede Zeile, die ein Assistent dir gibt, mit der gleichen Geschwindigkeit liest wie den Pull Request eines Kollegen, wirst du etwas ausliefern, das du nicht verstehst. Behandle jeden Vorschlag wie einen ersten Entwurf eines Junior-Entwicklers, der schnell ist, aber keine Erinnerung an die Konventionen deiner Codebasis hat.

Ihm sicherheitsrelevanten Code anvertrauen

KI-Assistenten sind mit riesigen Mengen an öffentlichem Code trainiert, und viel davon hat eingebaute Sicherheitsprobleme. Frag nach einem schnellen File-Upload-Handler und du bekommst oft etwas ohne Extension-Check, ohne Größenlimit und mit einem Pfad, der durch String-Verkettung statt os.path.join oder einen sicheren Library-Call gebaut wird. Dasselbe bei Auth: Assistenten lieben es, JWTs in localStorage zu speichern oder Geheimnisse mit == statt mit einem constant-time-Vergleich zu vergleichen. Nichts davon ist bösartig, es ist einfach statistisch häufig in Trainingsdaten. Für alles, das Authentication, File-I/O, Deserialisierung oder SQL betrifft, schreib die Logik selbst oder führe die Ausgabe des KI-Assistenten durch die gleichen Threat-Modeling-Fragen, die du auch an jeden neuen Code stellen würdest: Was passiert mit böswilliger Eingabe, was passiert, wenn dieser Call fehlschlägt, wer sonst kann diesen Endpoint erreichen.

Es Abhängigkeiten und APIs erfinden lassen

Modelle erfinden Paketnamen und Funktionssignaturen mit totaler Selbstsicherheit. Das ist das "slopsquatting"-Problem — Angreifer registrieren die falschen Paketnamen, die Modelle häufig vorschlagen, sodass ein unverifizertes pip install oder npm install etwas herunterladen kann, das überhaupt nicht deine Logging-Library ist. Bevor du eine Abhängigkeit hinzufügst, die ein Assistent empfiehlt, überprüfe, ob sie wirklich auf PyPI oder npm existiert, überprüfe die Download-Zahlen und das letzte Veröffentlichungsdatum, und überflieg den Source-Code, wenn er klein genug ist. Die gleiche Vorsicht gilt für API-Calls: Wenn der Assistent eine Methode referenziert, die du nicht kennst, überprüfe die tatsächlichen Docs, bevor du annimmst, dass sie existiert.

Das mentale Modell deines eigenen Codes verlieren

Wenn du Code selbst schreibst, baust du dir eine mentale Karte auf, warum jedes Teil existiert. Wenn du über eine Session hinweg große Blöcke von KI-generiertem Code akzeptierst, wird diese Karte schnell dünn. Dann taucht ein Bug drei Wochen später auf und du debuggst Code, den du nie wirklich geschrieben hast und dich nicht vollständig erinnerst. Die Lösung ist nicht, KI-generierten Code zu vermeiden, sondern langsam genug zu werden, um jeden Chunk für dich selbst oder einen Teamkollegen zu erklären, bevor du ihn mergst. Wenn du nicht erklären kannst, was eine Funktion macht und warum sie das so tut, merge sie noch nicht.

Tests weglassen, weil der Code