Wann KI nicht nutzen: Die Grenzen kennen

Das schwierigste Kapitel dieser Serie. Nicht weil die Antwort „nie“ lautet — sondern weil sie „es kommt drauf an“ lautet. Und „es kommt drauf an“ ist genau die Antwort, die niemand hören will. Trotzdem gibt es klare Bereiche, in denen KI-generierter Code ein Risiko ist, das den Produktivitätsgewinn nicht rechtfertigt.

Kryptografie und Sicherheit — kein Platz für Experimente

Lass die KI niemals sicherheitskritischen Code schreiben. Authentifizierung, Verschlüsselung, Token-Handling, Session-Management — das sind Bereiche, in denen ein subtiler Fehler keine kaputte UI ist, sondern ein Datenleck. Ein falsch implementierter Passwort-Hash, ein unsicherer Zufallszahlengenerator, ein Token ohne Ablaufdatum — solche Fehler sehen im Code unauffällig aus und richten in der Produktion massiven Schaden an.

Die KI kennt die gängigen Patterns. Sie weiß, dass password_hash() besser ist als md5(). Aber sie kennt nicht die Feinheiten, die den Unterschied zwischen sicher und unsicher ausmachen. Welcher Algorithmus ist aktuell als sicher anerkannt? Welche Parameter-Konfiguration passt zu deinem Anwendungsfall? Was sind die aktuellen Best Practices der OWASP? Die KI antwortet auf Basis ihrer Trainingsdaten — und die können veraltet sein. Bei Sicherheit ist „wahrscheinlich aktuell“ nicht gut genug.

Die richtige Antwort ist fast immer: bewährte Bibliotheken verwenden, nicht selbst implementieren. Nicht weil du oder die KI zu schlecht dafür wärt, sondern weil kryptografische Implementierungen von Dutzenden Experten über Jahre geprüft und gehärtet wurden. Sie haben Side-Channel-Angriffe berücksichtigt, Timing-Attacken verhindert und Edge Cases abgedeckt, an die weder du noch die KI denkt. Deine selbstgeschriebene Variante — ob von Hand oder per KI — hat diese Prüfung nicht durchlaufen.

Komplexe Geschäftslogik — der blinde Fleck

Geschäftslogik ist der Bereich, den die KI am schlechtesten versteht — weil sie nicht aus dem Code ablesbar ist. Dein Kunde hat ein Preismodell mit acht Sonderregeln, drei davon undokumentiert, eine davon widerspricht einer anderen und wurde trotzdem vom Vorstand so beschlossen. Die KI kennt keine dieser Regeln. Sie generiert eine Preisberechnung, die mathematisch korrekt ist, aber an der geschäftlichen Realität vorbeigeht.

Ich habe das in einem Shopware-Projekt erlebt: Die KI hat eine Rabattberechnung implementiert, die technisch einwandfrei war. Unit-Tests grün, Code sauber, Performance gut. Nur: Im echten Geschäft dürfen Rabatte auf bestimmte Warengruppen nicht mit Gutscheinen kombiniert werden. Das stand in keiner Anforderungsdokumentation, das wusste nur der Vertriebsleiter — und er erwähnte es erst, als die erste Beschwerde eines Großkunden kam. Die KI konnte es nicht wissen, und selbst der beste Prompt hätte das nicht geändert.

Geschäftslogik gehört in Gespräche mit den Stakeholdern, nicht in Prompts. Du kannst die KI nutzen, um die technische Umsetzung zu beschleunigen — die Klasse zu scaffolden, die Datenbankstruktur vorzubereiten, die Test-Fixtures zu generieren. Aber die Regeln selbst musst du verstehen, verifizieren und formulieren. Die KI implementiert, was du sagst. Wenn du die Hälfte der Regeln vergisst, implementiert sie die Hälfte — und die fehlende Hälfte fällt erst in der Produktion auf.

Code, den du verstehen musst

Die wichtigste Frage bei jedem KI-generierten Code: Kannst du Zeile für Zeile erklären, was passiert? Wenn ja, nutze die KI — sie hat dir Zeit gespart, und du hast die volle Kontrolle. Wenn nein, hast du ein Problem. Nicht heute, aber in drei Monaten, wenn ein Bug auftaucht und du den Code debuggen musst, den du nie wirklich verstanden hast.

KI-generierter Code, den du nicht verstehst, ist keine Lösung — er ist eine Zeitbombe. Er funktioniert, bis er nicht mehr funktioniert. Und dann stehst du vor einem Algorithmus, den du nicht geschrieben hast, nicht verstehst und nicht debuggen kannst. Du öffnest die Datei, starrst auf die Zeilen und hast keine Idee, warum der Code unter bestimmten Bedingungen fehlschlägt. Die Versuchung ist groß, dann wieder die KI zu fragen — aber die erzeugt beim Bugfix oft neue Bugs, weil sie den Kontext des ursprünglichen Problems nicht vollständig erfasst.

Meine Regel: Wenn ich den generierten Code nicht in einer Minute einem Kollegen erklären könnte, schreibe ich ihn selbst. Ja, das dauert länger. Aber ich verstehe jede Zeile, ich kann jeden Bug finden, und ich kann den Code in sechs Monaten noch warten. Das ist der Unterschied zwischen produktiv und scheinbar produktiv. Letzteres spart heute zwei Stunden und kostet nächsten Monat zwei Tage.

Das gilt besonders für Algorithmen. Wenn die KI einen Sortier-, Filter- oder Transformationsalgorithmus generiert, der für dich wie eine Blackbox aussieht, dann ist er eine Blackbox — mit allen Risiken, die das mit sich bringt. Entweder du verstehst den Algorithmus nach dem Lesen, oder du implementierst ihn selbst. Es gibt keinen sicheren Mittelweg.

Debugging von KI-Code — die Abwärtsspirale

Ein Muster, das ich immer wieder sehe: Die KI generiert Code. Der Code hat einen Bug. Der Entwickler fragt die KI, den Bug zu fixen. Die KI fixt den Bug, führt aber einen neuen ein. Der Entwickler fragt wieder. Nach drei Iterationen ist der Code doppelt so lang, dreimal so komplex und hat immer noch einen Bug — nur einen anderen. Ich nenne das die Abwärtsspirale, und sie ist der teuerste Fehler, den man mit KI machen kann.

Das passiert, weil die KI bei jedem Fix den gesamten Kontext neu interpretiert. Sie vergisst nicht absichtlich, aber sie gewichtet Informationen anders, wenn sich der Prompt ändert. Die Lösung des einen Problems verschiebt oft nur das Symptom, weil die KI die Ursache nicht identifiziert, sondern das Symptom behandelt. Sie sieht die Exception, aber nicht den logischen Fehler drei Methoden weiter oben, der die Exception verursacht. Und mit jeder Iteration wird der Code komplexer, schwerer verständlich und schwerer zu warten.

Mein Tipp: Nach maximal zwei erfolglosen Fix-Versuchen durch die KI aufhören und selbst debuggen. Öffne den Debugger, setze einen Breakpoint an der Stelle, wo das unerwartete Verhalten beginnt, und arbeite dich durch. In 90% der Fälle findest du den Bug in wenigen Minuten — weil du das System kennst und die KI nicht.

Irgendwann musst du den Code selbst lesen. Breakpoints setzen, Variablen inspizieren, den Zustand Schritt für Schritt nachvollziehen. Das ist die Kernkompetenz, die Entwickler von Prompt-Eingebern unterscheidet. Debugging ist eine Fähigkeit, die du nicht an die KI delegieren kannst — und die du regelmäßig trainieren musst, damit sie nicht verkümmert. Wer nur noch per KI debuggt, verliert die Fähigkeit, Code zu lesen. Und Code lesen ist die fundamentalste Entwicklerfähigkeit überhaupt.

Lerneffekt nicht abgeben

Ein Aspekt, der in KI-Diskussionen selten vorkommt: Wer nur noch generieren lässt, hört auf zu lernen. Wenn du jedes Problem sofort an die KI delegierst, entwickelst du keine eigene Problemlösungskompetenz. Du weißt nicht mehr, wie ein Algorithmus funktioniert, weil du ihn nie selbst implementiert hast. Du verstehst nicht, warum ein bestimmtes Pattern existiert, weil du nie das Problem ohne Pattern lösen musstest.

Das bedeutet nicht, dass du alles von Hand schreiben musst. Es bedeutet, dass du bewusst entscheidest, wann du die KI nutzt und wann du selbst nachdenkst. Für ein neues Pattern, das du noch nicht kennst: erst selbst versuchen, dann die KI fragen. Für den hundertsten CRUD-Controller: direkt die KI machen lassen. Der Unterschied ist: Lernst du gerade, oder produzierst du gerade? Beim Lernen ist die KI ein schlechter Lehrer. Beim Produzieren ist sie ein guter Assistent.

Die Balance — 80/20 mit Verstand

Die Entwickler, die mit KI am produktivsten sind, nutzen sie für die 80% Routine: Boilerplate, CRUD-Operationen, Test-Scaffolding, Konfigurationsdateien, Dokumentation, Code-Transformationen. Das sind Aufgaben, bei denen wenig schiefgehen kann und die Zeitersparnis enorm ist. Eine KI, die zehn Getter/Setter generiert, spart dir zehn Minuten sinnloses Tippen. Eine KI, die dir die Grundstruktur eines REST-Controllers scaffoldet, spart dir zwanzig Minuten Boilerplate.

Die 20%, die den Unterschied machen, bleiben beim Menschen: Architekturentscheidungen, Sicherheit, komplexe Geschäftslogik, Performance-kritische Algorithmen, Edge Cases, die nur Domänenwissen aufdeckt. Das sind die Bereiche, in denen ein falscher Ansatz nicht nur einen Bug erzeugt, sondern das Projekt in die falsche Richtung lenkt. Hier brauchst du dein eigenes Urteil, deine Erfahrung und dein Verständnis des Gesamtsystems.

Die Kunst ist, zu wissen, in welcher Kategorie du gerade arbeitest. Ein neuer REST-Endpoint mit Standard-CRUD? 80% — lass die KI machen. Die Autorisierungslogik für diesen Endpoint? 20% — schreib sie selbst. Das Datenbankschema? 80% wenn es ein einfaches Entity-Mapping ist, 20% wenn es um Performance-kritische Indizes und Beziehungen geht, die unter Last standhalten müssen.

Die Zukunft ist Zusammenarbeit, nicht Ersetzung

Die besten Ergebnisse erzielst du, wenn du KI als Sparringspartner betrachtest, nicht als Ghostwriter. Du denkst nach, formulierst die Idee, und die KI hilft bei der Umsetzung. Du überlegst die Architektur, und die KI scaffoldet die Klassen. Du definierst die Testfälle, und die KI schreibt die Tests. Der kreative und analytische Teil bleibt bei dir — der mechanische Teil wird automatisiert.

In fünf Jahren werden KI-Tools deutlich besser sein als heute. Sie werden mehr Kontext verstehen, weniger halluzinieren, besseren Code generieren. Aber die Grundfrage bleibt dieselbe: Verstehst du, was der Code tut? Kannst du ihn verantworten? Wenn ja, nutze jedes Werkzeug, das dir zur Verfügung steht. Wenn nein, halt inne und lerne erst — denn kein Werkzeug ersetzt das Verständnis dessen, was du baust. Die Grenzen der KI zu kennen macht dich nicht zu einem schlechteren KI-Nutzer. Es macht dich zu einem besseren Entwickler.

KI ist das mächtigste Werkzeug, das Entwickler je hatten. Aber ein Werkzeug ist nur so gut wie die Person, die es führt. Wer seine eigenen Grenzen kennt, kann die KI sicher einsetzen. Wer die Grenzen der KI kennt, kann sie effektiv einsetzen. Beides zusammen macht den Unterschied zwischen einem Entwickler, der KI nutzt, und einem, der von ihr abhängt. Ersteres willst du sein. Denn der Tag wird kommen, an dem die KI etwas vorschlägt, das plausibel klingt und trotzdem grundfalsch ist — und an dem Tag entscheidet dein eigenes Wissen, ob du den Fehler erkennst oder durchlässt.

Alle Teile dieser Serie

Teil 1: Projekt vorbereiten — Dateien, Struktur, Kontext
Teil 2: Gute Regeln schreiben — der KI Grenzen setzen
Teil 3: Saubere Prompts — präzise formulieren, Token sparen
Teil 4: Modelle und Tools — Stärken, Schwächen, Einsatzgebiete
Teil 5: Sicherheit — was nicht in den Prompt gehört
Teil 6: Reviews — warum der Mensch das letzte Wort haben muss
Teil 7: Wann KI nicht nutzen — die Grenzen kennen
Glossar: Begriffe für Entwickler