Wann ich AI-Code ablehne – selbst wenn er funktioniert

Vinicius Brasil beschreibt in When I reject AI code even if it works eine zunehmende Herausforderung: Review-Kosten werden zum neuen Bottleneck bei der Arbeit mit Coding Agents.

Das Problem

Früher verbrachte man Tage mit Codebase-Exploration, Experimenten und Lösungsentwürfen, bevor man einen PR submitterte. Das Resultat: hohe Confidence, einfache Erklärung gegenüber Reviewern.

Mit AI-Code-Generierung – selbst mit good practices wie Plan-Mode und kleinen Commits – entsteht kognitive Überlastung. Man reviewt Code, den man selbst nicht durchdacht hat.

Kriterien für AI-Code-Ablehnung

Brasil lehnt AI-Code ab, wenn:

• Man kann die Lösung nicht in eigenen Worten erklären
• Der Diff größer ist als das Problem (Over-Engineering)
• Abstraktionen eingeführt werden, bevor sie nötig sind (YAGNI-Verletzung)
• Code lokal funktioniert, aber das System schwerer verständlich macht
• Man dem Output mehr vertraut als dem eigenen Verständnis

Der letzte Punkt ist kritisch: Code, der läuft und CI-Tests besteht, kann trotzdem eine schlechte Lösung sein.

Die bessere Strategie

Brasil beobachtet oft, dass er in der zweiten Session alle AI-Änderungen verwirft und neu beginnt. Der Unterschied ist nicht das LLM-Modell, sondern die menschliche Konsolidierung des Problems:

With more time to consolidate the problem I’m trying to solve, I can drive the agent to a better solution instead of being driven by it.

Fazit

Coding Agents brauchen weiterhin exzellente Engineers am Steuer, um zu nachhaltigen Lösungen zu gelangen. Autonome AI-Programmierung in produktiver Weise gibt es noch nicht – und das ist gut so. Die Kombination aus menschlicher Urteilskraft und AI-Beschleunigung bleibt der Sweet Spot.