80 % des Codes schreibt jetzt Claude: Wie Google und Anthropic Delivery und CI in 6 Monaten skalierten
von Denis Shokhirev, Enterprise AI Architect aus Freiburg im Breisgau. Mein produktiver Stack: Claude, Supabase, n8n, Doppler und selbst gehostetes Postgres. In deutschen B2B-Projekten (Logistik, Fintech, Industrieautomation) liefert Claude heute 80 % des Codes – automatisiert, aber mit klaren Kontrollpunkten. Wer noch manuell Pull Requests reviewed, verliert Geschwindigkeit und Compliance-Fähigkeit im regulierten Markt. Claude im Produktivbetrieb: Was wirklich funktioniert Claude Code wird v
von Denis Shokhirev, Enterprise AI Architect aus Freiburg im Breisgau. Mein produktiver Stack: Claude, Supabase, n8n, Doppler und selbst gehostetes Postgres. In deutschen B2B-Projekten (Logistik, Fintech, Industrieautomation) liefert Claude heute 80 % des Codes – automatisiert, aber mit klaren Kontrollpunkten. Wer noch manuell Pull Requests reviewed, verliert Geschwindigkeit und Compliance-Fähigkeit im regulierten Markt.
Claude im Produktivbetrieb: Was wirklich funktioniert
Claude Code wird von vielen noch unterschätzt: „LLMs produzieren zu viele Fehler für Produktion.“ In meinen Projekten – inkl. öffentlich einsehbarem Multi-Agent-Stack (live.gerdennisai.com) – generiert Claude stabile CRUD-Endpoints, Datenintegrationen und sogar Testgerüste. Menschliches Review ist nur noch an Architektur- und Compliance-Schnittstellen nötig, nicht bei Routine-Code.
Der aktuelle Delivery-Workflow:
- Tickets werden in strukturierte Claude-Prompts übersetzt (Anthropic SDK, keine Copy-Paste-Prompts).
- Claude generiert Code mit Typisierung und Docstrings.
- Automatisierte statische Analyse (semgrep, bandit, gitleaks) für jeden Pull Request.
- CI/CD via GitHub Actions: Kein Merge ohne erfolgreiche Prüfungen.
- Manuelles Review nur bei Security-Funden oder Testabdeckung unter 92 %.
CI/CD skalieren – ohne Kontrollverlust
Sicherheitsprüfung ist Pflicht, keine Option
Laut Stanford CodeML (2024, Quelle) enthalten 38 % von LLM generierten Python-Snippets Muster für CWE-89 (SQL Injection). In meinen letzten drei Claude-Agent-Deployments wurden vergleichbare Schwachstellen im ORM-Code durch semgrep oder bandit erkannt. Automatisierte Security-Checks sind unverzichtbar, insbesondere unter DSGVO und BSI Grundschutz.
# Statische Analyse im CI
semgrep --config=python --error ./
bandit -r ./src
gitleaks detect --source=./src
Integriert in CI/CD bedeutet das:
- semgrep: blockiert unsichere SQL- oder OS-Aufrufe.
- bandit: prüft Python-Code auf Schwachstellen vor Merge.
- gitleaks: findet Secrets vor Bereitstellung.
Nur wenn alle Prüfungen erfolgreich sind, wird automatisch nach n8n/Supabase deployt. Bei Findings gibt es verpflichtende manuelle Prüfung – ohne Ausnahme.
Claude, Supabase, n8n und Postgres: Der erprobte Stack
Claude Code kennt keine spezifischen Datenmodelle oder Event-Flows. Ich arbeite daher mit Prompts, die Tabellenstrukturen, Event-Ströme und Postgres-Constraints (z. B. ENUMs, Foreign Keys) explizit enthalten, plus reale oder anonymisierte Datenbeispiele. Dadurch sinkt die Integrationsfehlerquote signifikant. Beispiel: CRUD-Endpoint-Generierung mit FastAPI und Supabase:
prompt = f"""
Sie schreiben Python-Code für einen FastAPI-Service. Tabelle users:
- id: UUID, PK
- email: TEXT, unique
- status: ENUM('active', 'blocked')
Erzeugen Sie CRUD-Endpunkte mit Validierung und Logging.
"""
antwort = anthropic_client.completions.create(
model="claude-3-opus-20240229", prompt=prompt, max_tokens=1000
)
Das gleiche Prinzip gilt für n8n-Flows: Ereignisstruktur, erwartete Inputs/Outputs und Fehlerbehandlung beschreiben. Claude liefert so Code, der sofort CI-fähig ist – kein Demo-Output.
Produktionssicherheit: Regressionen im laufenden Betrieb vermeiden
Dynamische Tests und Coverage-Verpflichtung
Ich verlasse mich nie nur auf statische Analyse. Runtime-Sandboxing ist Pflicht: Tests werden mithilfe von Claude (auf Basis von Spezifikation und Edge-Cases) generiert und isoliert via Docker Compose ausgeführt. Liegt die Coverage unter 92 %, wird der Merge blockiert. Diese Schwelle halte ich bei jedem B2B-Projekt mit Compliance-Anforderungen (z. B. Fintech, Logistik).
docker-compose -f docker-compose.test.yaml up --abort-on-container-exit
pytest --cov=src tests/
Wichtige Tools und Auslösezeitpunkte im Prozess:
| Tool | Zweck | Wann |
|---|---|---|
| semgrep | Statische Pattern-Erkennung | Bei jedem Commit |
| bandit | Python-Sicherheitsprüfung | Vor Merge |
| gitleaks | Secret-Erkennung | Vor Bereitstellung |
| pytest + coverage | Testabdeckung | Vor Merge |
FAQ
Schreibt Claude tatsächlich produktionsfähigen Code?
Ja, sofern Sie präzise Prompts und verpflichtende statische und dynamische Prüfungen einsetzen. Menschliches Review ist nur bei Architekturfragen oder komplexer Integration nötig.
Wie geht Claude mit Edge-Cases um?
Wenn Edge-Cases klar im Prompt und in Testfällen beschrieben sind, arbeitet Claude auf Mid-Level-Niveau. Ungenaue Prompts führen zu subtilen Fehlern.
Wird CI/CD jetzt zum Bottleneck?
Im Gegenteil: Automatisierte Prüfungen und Review reduzieren Engpässe. Menschliche Freigabe nur bei Findings oder komplexen Änderungen.
Welche Fehler übersehen die LLMs am häufigsten?
Fehler in der Validierung, falscher Umgang mit Nullable-Feldern und spezifische Business-Logik – immer dort, wo der Prompt nicht explizit genug ist.
Welche Tools sind unverzichtbar?
semgrep, bandit, gitleaks, pytest, docker-compose, Anthropic SDK. Alles Weitere ist projektspezifisch.
An welcher Stelle im LLM-Pipeline fangen Sie die meisten Fehler ab – statische Analyse, Sandbox-Tests oder menschliches Review? Ich möchte die produktiven Schwachstellen anderer Teams kennenlernen. Ich biete kostenfreie 30-min Stack-Audits für DACH-Teams mit KI unter Regulatorik. Schreiben Sie mir auf LinkedIn oder an @ger_dennis_ai.
Aus einem Ablauf ein System machen, das läuft
Gebaut für den Betriebsalltag, nicht als Demo.