Wo KI-Coding-Agenten versagen – und wann du schuld bist

Die andere Seite

In den ersten drei Teilen dieser Serie ging es darum, was KI-Coding-Agenten können und wie man sie produktiv einsetzt. Dieser Teil dreht die Perspektive um.

Nicht als Rant. Sondern als ehrliche Bestandsaufnahme: Wo scheitern Claude Code, Codex und Co. tatsächlich? Wo liegt das Problem beim Entwickler? Und wo stößt die Technologie an echte Grenzen, die sich nicht durch bessere Prompts lösen lassen?

Die Unterscheidung ist wichtig. Denn wer nicht weiß, ob ein Problem am eigenen Kontext liegt oder an der KI, optimiert an der falschen Stelle.

Kategorie 1: Dein Problem, nicht das der KI

Zu wenig Kontext

Das häufigste Versagen ist keins. Der Agent liefert schlechte Ergebnisse, weil er nicht genug weiß. Kein Memory gepflegt, keine CLAUDE.md, keine Konventionen beschrieben. Der Agent rät — und rät falsch.

# Prompt:
> Erstelle eine neue API-Route für Bestellungen.

# Ergebnis: Express-Route mit MongoDB.
# Dein Projekt: Fastify mit PostgreSQL.

Das ist kein KI-Versagen. Das ist ein leeres Briefing. Mit einer gepflegten Kontext-Datei passiert das nicht.

Aufgabe zu groß

“Refactore das Auth-System komplett” ist keine Aufgabe, die man einem Menschen in einem Satz gibt. Einem KI-Agenten auch nicht. Große Aufgaben zerfallen in Teilschritte, und wer die nicht formuliert, bekommt inkonsistente Ergebnisse.

Die Faustregel: Wenn du die Aufgabe nicht in einem Commit zusammenfassen könntest, ist sie zu groß für einen einzelnen Prompt.

Fehlendes Domänenwissen im Prompt

Der Agent kennt dein Geschäftsmodell nicht. “Berechne den Rabatt” heißt für ihn: Prozent abziehen. Für dich heißt es vielleicht: Staffelrabatt nach Kundenkategorie, Mindestbestellwert, nicht kombinierbar mit Gutscheinen, zeitlich begrenzt.

Wer Domänenlogik nicht explizit beschreibt, bekommt generische Lösungen. Das ist nicht die Schuld der KI.

Ergebnis nicht geprüft

KI-Code kompiliert fast immer. Tests laufen meistens. Aber “kompiliert und Tests grün” ist nicht dasselbe wie “korrekt”. Wer KI-Output nicht reviewt wie den Code eines neuen Teammitglieds, übersieht subtile Probleme: fehlende Edge Cases, ineffiziente Queries, falsche Annahmen über Datentypen.

Kategorie 2: Geht noch nicht gut — aber wird besser

Große Codebasen mit tiefen Abhängigkeiten

Agenten werden besser darin, aber ab einer gewissen Projektgröße — 500+ Dateien, verschachtelte Abhängigkeiten, Legacy-Patterns — verlieren sie den Überblick. Nicht weil das Kontextfenster zu klein wäre, sondern weil die impliziten Regeln eines gewachsenen Projekts nirgends stehen.

Ein Mensch, der seit zwei Jahren im Projekt arbeitet, weiß: “Diese Klasse darf man nicht anfassen, weil drei andere Teams davon abhängen.” Ein Agent weiß das nicht — es sei denn, es steht in der Kontext-Datei.

Performance-Optimierung auf Systemebene

Agenten können eine langsame Funktion optimieren. Was sie nicht können: verstehen, warum das System insgesamt langsam ist. Datenbankindizes, Connection Pooling, Caching-Strategien, N+1 Queries über Service-Grenzen hinweg — das erfordert ein Verständnis der Laufzeitumgebung, das Agenten nicht haben.

Sie sehen den Code. Sie sehen nicht die Infrastruktur dahinter.

Datenbank-Migrationen in Produktion

Der Agent erstellt die Migration. Aber versteht er, dass die Tabelle 50 Millionen Rows hat und ein ALTER TABLE ADD COLUMN mit Default-Wert die Datenbank für 20 Minuten blockiert? Dass man stattdessen in drei Schritten migrieren muss — Column nullable, Backfill, dann Constraint?

Migrationen generieren: ja. Migrationen für Produktionssysteme planen: nein.

Debugging über mehrere Services

Microservices, verteilte Systeme, Event-Driven Architectures. Der Bug liegt nicht im Code, sondern im Zusammenspiel: Race Conditions, Message Ordering, Eventual Consistency. Der Agent sieht einen Service. Der Fehler entsteht zwischen dreien.

Security-relevante Entscheidungen

Der Agent schreibt Code, der funktioniert. Aber ist er sicher? SQL Injection in dynamischen Queries, fehlende Rate Limiting, unsichere JWT-Konfiguration, CORS zu weit offen — das sind keine Bugs, die Tests finden. Das sind Designentscheidungen, die Expertise erfordern.

KI-generierter Code ist nicht unsicherer als menschlicher. Aber er wird seltener hinterfragt — und genau das ist das Risiko.

Kategorie 3: Geht aktuell nicht — echte Grenzen

Architekturentscheidungen

“Soll ich einen Monolith oder Microservices bauen?” — darauf gibt es keine generische Antwort. Die richtige Architektur hängt von Teamgröße, Deployment-Strategie, erwarteter Last, Budget und Organisationsstruktur ab. Kein Agent kann das bewerten.

Agenten können Architektur implementieren. Aber Architektur entscheiden — das erfordert Urteilsvermögen über den Code hinaus.

Domänenmodellierung

Das Herzstück jeder Software: Welche Konzepte gibt es? Wie hängen sie zusammen? Was ist ein Aggregate, was eine Value Object? Wo zieht man Bounded Context Grenzen?

Agenten generieren Code für ein vorgegebenes Modell. Aber das Modell selbst entwerfen — die Abstraktion finden, die das Problem richtig abbildet — das können sie nicht. Sie kennen die Domäne nicht.

Langfristige Codepflege

Ein Agent löst die Aufgabe von heute. Aber wird der Code in sechs Monaten noch wartbar sein? Passt er zur Richtung, in die sich das Projekt entwickelt? Erzeugt er technische Schulden, die später teuer werden?

Agenten optimieren lokal. Langfristige Auswirkungen bewerten sie nicht.

Verhandlung und Priorisierung

“Der Kunde will Feature X, aber das Budget reicht nur für die Hälfte. Welchen Teil bauen wir zuerst?” — das ist keine technische Frage. Das ist Produktentwicklung, Kommunikation, Kompromissfindung. Kein Agent kann das.

Ästhetische und UX-Urteile

“Fühlt sich das richtig an?” — der Agent kann ein Layout umsetzen, aber nicht bewerten, ob es gut ist. Typografie, Whitespace, Interaktions-Feedback, Mikroanimationen — das erfordert gestalterisches Urteil, das sich nicht in Prompts fassen lässt.

Umgang mit widersprüchlichen Anforderungen

Reale Projekte haben widersprüchliche Requirements. “Muss schnell laden” und “muss alle Daten auf einer Seite zeigen”. “Muss sicher sein” und “Anmeldung in einem Klick”. Ein erfahrener Entwickler erkennt den Widerspruch und sucht den Kompromiss. Ein Agent implementiert, was man ihm sagt — auch wenn es sich widerspricht.

Die unterschätzte Fehlerquelle: Halluzinierte APIs

Ein Problem, das selten diskutiert wird: Agenten erfinden APIs, die nicht existieren. Nicht bewusst — sie generieren Code, der plausibel aussieht, aber auf Funktionen zugreift, die es in der verwendeten Library-Version nicht gibt.

// Agent generiert:
import { useServerAction } from 'next/server';

// Problem: Diese Funktion existiert nicht.
// Es gibt useFormState, useFormStatus -- aber nicht useServerAction.

Das passiert besonders bei:

• Neuen Framework-Versionen (Agent kennt die alte API)
• Nischen-Libraries mit wenig Trainingsdaten
• Verwechslung ähnlicher Libraries (Zustand vs. Jotai vs. Redux Toolkit)

Die einzige Absicherung: Ergebnisse gegen die offizielle Dokumentation prüfen. Nicht gegen das eigene Bauchgefühl — denn die halluzinierte API klingt oft plausibel genug, um durchzurutschen.

Das Muster dahinter

Das klingt nach einer großen Einschränkung. Ist es auch. Aber es ist gleichzeitig eine klare Abgrenzung: Wenn du weißt, wo die Grenzen liegen, kannst du die Tools dort einsetzen, wo sie stark sind — und dort selbst übernehmen, wo sie es nicht sind.

Die gefährliche Zone ist nicht da, wo die KI offensichtlich scheitert. Die gefährliche Zone ist da, wo das Ergebnis gut genug aussieht, um nicht hinterfragt zu werden.

Praktischer Selbsttest

Bevor du ein KI-Ergebnis übernimmst, drei Fragen:

1. Habe ich genug Kontext gegeben? Wenn nicht — nachliefern, nicht die KI beschuldigen.
2. Kann ich das Ergebnis bewerten? Wenn nicht — erst selbst verstehen, dann die KI nutzen.
3. Würde ich das bei einem menschlichen Kollegen durchwinken? Wenn nicht — Review ernst nehmen.

Wer diese drei Fragen ehrlich beantwortet, filtert 80 % der Probleme. Die restlichen 20 % sind echte Grenzen der Technologie — und die sollte man kennen, nicht bekämpfen.

Einordnung

KI-Coding-Agenten sind besser als ihr Ruf bei klar definierten, kontextreichen Aufgaben. Und schlechter als ihre Marketing-Versprechen bei allem, was Urteilsvermögen, Domänenwissen oder Langzeitdenken erfordert.

Das ist kein Widerspruch. Das ist eine Arbeitsteilung. Und je klarer man die Grenze kennt, desto produktiver wird die Zusammenarbeit.