Warum Ihre KI-Agenten schlechten Code schreiben: Orchestrierungsmuster und Prompt-Engineering-Fallen im Produktivbetrieb

von Denis Shokhirev, Enterprise AI Architect aus Erlangen. Bei DennisCraft AI Studio setze ich produktive KI-Systeme für DACH-Kunden um – u.a. auf einem Stack aus Claude, Supabase, n8n, Doppler und selbst gehostetem Postgres. In drei aktuellen Produktionsprojekten identifizierte ich kritische Schwachstellen im generierten Code von KI-Agenten: SQL-Injections, hartkodierte Zugangsdaten, fehlende Input-Validierung. Diese Fehler wurden erst durch bandit und semgrep entdeckt – automatisierte Checks fehlten im Orchestrierungsablauf. Das ist kein Einzelfall, sondern ein Musterproblem.

Orchestrierung: Wo der Qualitätsbruch im Code entsteht

Typische Produktionspipelines für KI-Agenten im DACH-Umfeld:

• n8n startet den Workflow, erstellt einen Prompt und ruft Claude Code per API auf
• Claude liefert Python- oder SQL-Code zurück
• n8n übernimmt diesen Code direkt ins Repository oder führt ihn über Supabase/Postgres produktiv aus

Das Problem: In vielen Setups gibt es keinerlei automatisierte Sicherheitsprüfung oder statische Analyse zwischen LLM-Ausgabe und Produktivbetrieb.

Typische Orchestrierungsfehler

• Keine nachgelagerte statische Analyse (bandit, semgrep, gitleaks werden nicht genutzt)
• Fehler werden erst beim Endnutzer in der Produktion sichtbar
• Keine Rollback- oder Atomizitätsmuster: Teilfehler beschädigen produktive Daten

Ein aktuelles Beispiel: In einem Fintech-Projekt (Deutschland, 2024) generierte ein Agent eine Logging-Funktion, die Logs öffentlich auf einen S3-Bucket schrieb – gitleaks hätte dies erkannt, die Orchestrierung ließ es aber durch.

Prompt-Engineering-Fallen im Produktivbetrieb

Immer wiederkehrende Fehler im Prompt-Design führen zu produktiven Schwachstellen:

Zu allgemeine Anweisungen

Prompts wie „Schreiben Sie eine Funktion zur Suche von Nutzern in der Datenbank“ führen fast immer zu unsicheren SQL-Statements ohne Input-Validierung oder Prepared Statements.

Fehlende explizite Sicherheitsvorgaben

Ohne klare Instruktionen für Prepared Statements oder Logging-Regeln generiert das LLM riskanten Code. Beispiel für einen unsicheren Prompt:

# Unsicherer Prompt
"""
Schreiben Sie eine Funktion, die einen Nutzer anhand der E-Mail-Adresse in Postgres sucht.
"""

Das LLM liefert typischerweise:

def find_user(email):
    query = f"SELECT * FROM users WHERE email = '{email}'"
    cur.execute(query)
    return cur.fetchone()

Dieses Muster ist direkt anfällig für SQL-Injection.

Fehlender Feedback-Loop

Ohne automatisierte statische Analyse (etwa semgrep + Claude) schleichen sich dieselben Schwachstellen wiederholt in produktive Deployments ein.

Produktionsbewährte Orchestrierungsmuster für LLMs

Beispiel: Claude Code + n8n + Supabase Stack

In meinem Workflow gibt es einen statischen Analyse-Schritt zwischen Code-Generierung und Ausführung:

import subprocess

def safe_exec(generated_code: str):
    with open("temp.py", "w") as f:
        f.write(generated_code)
    result = subprocess.run(
        ["bandit", "-r", "temp.py"],
        capture_output=True, text=True
    )
    if "No issues identified." not in result.stdout:
        raise Exception("Unsicherer Code blockiert")
    # Nur sicherer Code wird ausgeführt oder gemergt

Selbst wenn das LLM unsicheren Code liefert, verhindert die Orchestrierung die Produktionseinführung.

Human-in-the-Loop – Wann ist ein manueller Review Pflicht?

In 5 von 14 produktiven Agenten habe ich einen manuellen PR-Review eingeführt, sobald statische Analyse Fehler meldet. Das verlangsamt Releases, verhindert aber kritische DSGVO-relevante Vorfälle.

Automatisierte Human-in-the-Loop-Workflows

Mit n8n lassen sich PRs mit Findings automatisch an menschliche Reviewer eskalieren:

// n8n Custom-Node
if (staticAnalysis.findings.length > 0) {
  sendToHumanReview(prId, staticAnalysis.findings);
}

Realbeispiel aus 2024: In einem Logistik-Projekt erkannte gitleaks hartkodierte Zugangsdaten. Der PR wurde automatisch in den manuellen Review-Prozess überführt.

Externe Daten zu LLM-Code-Schwachstellen

Laut Stanford CodeLM-Studie (2023) wiesen 38% der von LLMs generierten Python-Codes mindestens eine Schwachstelle der OWASP Top 10 auf – selbst bei Prompts mit Sicherheitsanweisungen. Diese Quote deckt sich mit meinen Beobachtungen bei DACH-Kunden im regulierten Umfeld.

FAQ

Lassen sich Qualitätssicherungen für LLM-Code vollständig automatisieren?

Nein. Selbst Top-Tools wie bandit oder semgrep übersehen Spezialfälle. Für sicherheitskritische Bereiche ist ein manueller Review nach wie vor unerlässlich, insbesondere bei DSGVO-relevanten Prozessen.

Welche Minimal-Tools sind für die Orchestrierung Pflicht?

bandit, semgrep und gitleaks sollten immer genutzt werden. Bei sensiblen Daten empfiehlt sich zusätzlich ein OWASP-Checker. Für SQL-Code: Prepared Statements, z.B. mit psycopg2.

Wie schreiben Sie Prompts für sicheren Code?

Formulieren Sie explizite Constraints wie „Nur Prepared Statements verwenden“, „Kein eval nutzen“, „Logging ausschließlich über das Standardmodul“.

Wie erkennen Sie wiederkehrende Fehler im LLM-Code?

Sammeln Sie die Findings aus der statischen Analyse, kategorisieren Sie Fehler und passen Sie Prompts sowie Orchestrierungsschritte an. Verlassen Sie sich nicht allein auf Unit-Tests.

Was tun, wenn das LLM fortlaufend unsicheren Code generiert?

Passen Sie das Prompt-Wording an, nutzen Sie restriktivere System-Prompts, erwägen Sie Fine-Tuning und verzichten Sie nicht auf den Human-in-the-Loop.

In welcher Stufe Ihrer Orchestrierungspipeline treten produktiv die meisten Fehler auf – statische Analyse, Sandbox-Laufzeit oder manueller Review? Mich interessiert Ihr Vorgehen. Ich biete DACH-Entscheidern einen kostenfreien 30-Minuten Stack-Check für KI-Projekte im regulierten Umfeld an. Kontaktieren Sie mich auf LinkedIn oder unter @ger_dennis_ai.