Warum Ihr KI-Agent zu viel Code schreibt – und wie Sie das beheben

Mein Name ist Denis Shokhirev, Enterprise AI Architect aus Erlangen. In meiner Rolle bei DennisCraft AI Studio habe ich in den letzten sechs Monaten 14 produktive KI-Agenten für DACH-B2B-Kunden aus Logistik, Fintech und Industrieautomation geliefert – auf Basis von Claude, Supabase, n8n, Doppler und selbstgehostetem Postgres. Immer wieder stoße ich auf denselben Schmerzpunkt: KI-gestützte Agenten produzieren erheblich mehr Code als für die eigentliche Geschäftslogik erforderlich. Das hat direkte Folgen für Wartbarkeit, Sicherheit und Compliance. Hier ist mein Ansatz, wie ich diese Problematik strukturiert adressiere.

Wie kommt es zur Code-Überproduktion durch LLM-Agenten?

Große Sprachmodelle wie Claude, GPT-4 oder Gemini wurden auf riesigen Mengen Code (GitHub, Stack Overflow, Dokumentationsdatenbanken) trainiert. Die Modelle bevorzugen „Vollständigkeit“ – besser zu viel als zu wenig –, was zu übermäßigen Hilfsklassen, Boilerplate und unnötigen Schichten führt.

Praktisches Beispiel

Für einen Fintech-Kunden generierte ein Claude-basierter Agent über 3.000 Zeilen Python-Code für eine einfache ETL-Task, die mit weniger als 200 Zeilen in einer ORM-Klasse lösbar gewesen wäre. Fünf nicht genutzte Hilfsdateien, mehrere „Manager“-Klassen und zahlreiche tote Methoden schafften es in den Review. In einer schnellen Pipeline wäre das direkt in die Produktion gelangt.

Risiken durch überflüssigen KI-Code – auch für Compliance

Laut einer Stanford CodeGen-Studie von 2023 enthielten 38% des von LLMs generierten CRUD-Python-Codes CWE-89-Muster (SQL Injection). Quelle: arxiv.org/abs/2307.07924. In meinen Projekten steigt mit der Codebasis die Zahl der Funde durch bandit und semgrep signifikant.

Warum LLM-Agenten zu viel liefern: Ursachen

1. Bias zur Überproduktion

LLMs optimieren auf „Vollständigkeit“ und antizipieren Edge Cases, die für Ihre konkrete Anwendung meist irrelevant sind. Das Resultat: zusätzliche Hilfsmethoden, Dummy-Implementierungen und unnötige Abstraktionen.

2. Fehlende harte Grenzen im Prompt

Ohne klare Vorgaben zu Umfang und Dateistruktur („maximal 80 Zeilen, eine Datei“) generiert das Modell stets das „komplette“ Paket – inklusive vieler nicht genutzter Komponenten.

3. Fehlende automatisierte Nachbearbeitung

Viele Teams übernehmen LLM-Code direkt in die Pipeline. Kein statisches Trimming, keine Toter-Code-Erkennung, kein Pre-Review. Das ist ineffizient und problematisch im Hinblick auf ISO 27001 oder BSI Grundschutz.

Produktiv bewährte Gegenmaßnahmen

1. Prompts mit harten Limiten

Ich setze in jedem Prompt für Claude oder GPT-4 explizite Grenzen: maximale Zeilenzahl, nur eine Datei, Dokumentation nur für öffentliche Methoden. Das reduziert Codeumfang und bremst Redundanzen effektiv aus.

PROMPT = """
Schreibe eine Python-Klasse zum Connect mit Supabase.
Nur eine Datei, maximal 80 Zeilen.
Dokumentiere ausschließlich öffentliche Methoden.
Keine Tests, keine unnötigen Abhängigkeiten.
"""

2. Automatisierte statische Analyse und Trimming

Direkt nach der KI-Generierung prüfe ich den Code mit semgrep und bandit (Sicherheits-/Pattern-Analyse). Anschließend werden nicht genutzte Funktionen und Importe mit einem Python-Skript entfernt.

import ast

def remove_unused_functions(code):
    tree = ast.parse(code)
    used = {node.id for node in ast.walk(tree) if isinstance(node, ast.Name)}
    new_body = []
    for node in tree.body:
        if isinstance(node, ast.FunctionDef):
            if node.name in used:
                new_body.append(node)
        else:
            new_body.append(node)
    tree.body = new_body
    return ast.unparse(tree)

3. n8n-basierter QA-Workflow

Mit n8n baue ich Pipelines, die nach der LLM-Generierung automatische Prüfungen (semgrep, bandit, gitleaks) durchführen und den Code dann an einen Reviewer weiterleiten. Erst nach menschlichem Freigabeprozess erfolgt die Bereitstellung.

- name: LLM Code QA
  steps:
    - run: semgrep --config=auto src/
    - run: bandit -r src/
    - run: gitleaks detect --source=src/
    - assign: code-reviewer
    - if: passed
      then: merge

Vergleich: Statische Analyse-Tools für KI-Code

FAQ

Kann man KI-Code nicht einfach manuell kürzen?

Manuelle Kürzungen sind ineffizient, fehleranfällig und nicht skalierbar. Automatisierte statische Analyse spart Zeit und erhöht die Qualität.

Hilft ein ORM gegen Boilerplate-Code?

ORMs wie SQLAlchemy helfen, aber LLMs erzeugen trotzdem oft unnötige Abstraktionen. Klare Prompts und automatisierte Checks bleiben Pflicht.

Kann das Trimming automatisiert komplett vertrauenswürdig sein?

Nein – der finale menschliche Review bleibt essenziell, gerade für kritische oder regulierte Systeme. Automatisiertes Trimming entfernt aber die offensichtlichen Redundanzen.

Wie verbessert das die Sicherheit und Compliance?

Weniger Code reduziert die Angriffsfläche und vereinfacht Audits für DSGVO/NIS2. Tools wie bandit und semgrep entdecken Schwachstellen früh im Prozess.

Wie lässt sich das in existierende Pipelines integrieren?

Integrieren Sie statische Analyse und Trimming direkt in n8n oder Ihre CI/CD-Strecke und setzen Sie Prompt-Limits als Standard. Rollieren Sie Änderungen schrittweise aus.

In welcher Pipeline-Phase entdecken Sie die meisten überflüssigen oder sicherheitsrelevanten KI-Code-Anteile: Prompting, statische Analyse oder manueller Review? Ich bin an echten Praxisfällen interessiert. Ich biete einen kostenlosen 30-minütigen Stack-Audit für DACH-Unternehmen in regulierten Sektoren an. Kontaktieren Sie mich auf LinkedIn oder unter @ger_dennis_ai.