Claude für Produktionscode: Workflows, die wirklich skalieren

Letzten Monat habe ich Claude verwendet, um 3.000 Zeilen Trading-Infrastruktur zu refaktorieren. Der Code bestand die Testsuiten auf Anhieb. Einen Monat zuvor verbarg eine andere Eingabeaufforderung einen Logikfehler, der mich vier Stunden Fehlersuche kostete. Der Unterschied lag nicht an Claudes Fähigkeiten – es war der Workflow.

Claude ist außergewöhnlich gut in der Codeerstellung, im Refactoring und in der Fehlersuche. Es ist auch einzigartig gefährlich, wenn Sie es wie einen Einmal-Code-Generator behandeln und weitermachen. Produktionscode erfordert einen anderen Ansatz: strukturierte Prompts, gestaffelte Validierung und spezifische Fallback-Muster, wenn Claude halluziniert oder vereinfacht. Dieser Leitfaden behandelt die genauen Workflows, die ich in realen Projekten getestet habe, wobei „getestet“ bedeutet, dass der Code in Produktionssystemen läuft, die reale Daten verarbeiten.

Warum Claude sich beim Codieren von GPT-4o unterscheidet

Bevor wir uns den Workflows widmen, sollten Sie verstehen, womit Sie es zu tun haben. Claude (insbesondere Claude Sonnet und Claude Opus) hat andere Codeeigenschaften als GPT-4o:

• Längerer Kontext ohne Qualitätsverlust: Claudes 200.000 Token-Fenster (Sonnet) fasst größere Codebasen ohne den Verlust von mittleren Token, der andere Modelle beeinträchtigt. Ich habe ganze API-Dienste in eine einzige Eingabeaufforderung eingespeist, ohne dass die Qualität nachgelassen hat.
• Besser beim Refactoring als bei der Erstellung: Wenn Sie Claude vorhandenen Code übergeben, versteht es die Absicht schneller, als wenn Sie es bitten, von Grund auf neu zu erstellen. GPT-4o generiert oft korrekte Syntax, übersieht aber architektonische Einschränkungen.
• Gefährlich bei architektonischen Entscheidungen: Claude schlägt zuversichtlich Datenbank-Schema-Änderungen, Abhängigkeitsmuster oder Bibliotheksauswahlen vor, die isoliert funktionieren, aber im Produktionskontext scheitern. Es benötigt Leitplanken.
• Stärker bei der Fehleranalyse: Geben Sie Claude einen Stack-Trace und einen teilweisen Fehlerkontext, und es verfolgt die Ursache zuverlässiger als Konkurrenten. Hier glänzt es in meinen Workflows.

Der Hauptunterschied: Claude ist für Konversationen und die Analyse komplexer Zusammenhänge konzipiert. Nutzen Sie es als Gedankenpartner, nicht als Code-Fabrik.

Workflow 1: Refactoring von vorhandenem Code mit vollständigem Kontext

Hier erhalte ich die zuverlässigsten Ergebnisse. Anstatt zu fragen „Refaktorieren Sie diese Funktion“, fragen Sie „Refaktorieren Sie diese Funktion und bewahren Sie dabei X, Y, Z und verbessern Sie A, B, C.“.

Das Muster:

1. Fügen Sie die vollständige Datei oder das Modul ein (oder mehrere zusammenhängende Dateien, wenn sie in den Kontext passen)
2. Nennen Sie die architektonischen Einschränkungen („dies läuft in einer 256-MB-Lambda-Funktion“, „dies muss asynchron bleiben“, „dies speist in eine Kafka-Pipeline ein“)
3. Nennen Sie die spezifischen Ziele („Speicherbedarf um 30 % reduzieren“, „diese veraltete Bibliothek eliminieren“, „die Fehlerbehandlung vereinfachen“)
4. Bitten Sie um eine vollständige Ersetzung, keine Vorschläge

Schlechter Prompt:

Refaktorieren Sie diesen Python-Code, um ihn effizienter zu gestalten:

[code]

Verbesserter Prompt:

Ich habe eine Datenverarbeitungspipeline, die in AWS Lambda (256 MB Speicherlimit) läuft.
Einschränkungen:
- Muss asynchron bleiben (verwendet mit asyncio)
- Hängt von PostgreSQL und Redis ab
- Verarbeitet ~10.000 Ereignisse/Sekunde im Spitzenbetrieb
- Darf keine neuen externen Abhängigkeiten einführen
- Fehlerbehandlung muss idempotent bleiben (gleiche Eingabe = gleiche Ausgabe)

Aktueller Engpass: Die Stapelverarbeitungsschleife weist bei Spitzenlasten zu viel Speicher zu.
Ziel: Spitzen-Speicherbedarf um 30 % reduzieren, ohne die externe API oder das Datenbankschema zu ändern.

[vollständiger Code]

Stellen Sie das vollständig refaktorierte Modul bereit. Erklären Sie, was sich geändert hat und warum jede Änderung für die oben genannten Einschränkungen wichtig ist.

Die zweite Version funktioniert, weil Sie Mehrdeutigkeiten beseitigt haben. Claude versteht den operativen Kontext, nicht nur die Syntax.

Reales Beispiel von AlgoVesta: Unser Order-Execution-Dienst hatte unter hoher Nebenläufigkeit ein Speicherleck. Ich gab Claude den vollständigen asynchronen Handler, die Abhängigkeitskette und die Monitoring-Ausgabe, die zeigte, wo der Speicher anstieg. Claude identifizierte das Problem sofort: Wir sammelten Websocket-Verbindungen in einer Liste anstelle eines WeakSet. Es refaktorierte die gesamte Verbindungsverwaltungsschicht in einer Antwort. Die Korrektur bestand alle Tests.

Wann dies fehlschlägt: Claude schlägt manchmal Optimierungen vor, die Speicher gegen Latenz (oder umgekehrt) tauschen. Wenn Sie nicht angeben, welche Einschränkung am wichtigsten ist, rät es. Priorisieren Sie immer explizit.

Workflow 2: Fehlersuche mit Stack-Traces und teilweisem Kontext

Hier zahlt sich Claudes Vorteil bei der Analyse aus. Sie benötigen keinen minimalen Reproduktionsfall – ein echter Stack-Trace mit umgebendem Code reicht oft aus.

Das Muster:

1. Fügen Sie den Stack-Trace exakt wie angezeigt ein
2. Geben Sie die Funktion an, die den Fehler ausgelöst hat
3. Geben Sie 2-3 Funktionen weiter oben in der Aufrufkette an
4. Wenn es sich um asynchronen oder datenbankbezogenen Code handelt, fügen Sie den Initialisierungscode ein
5. Bitten Sie Claude, die wahrscheinliche Ursache zu ermitteln und eine Lösung vorzuschlagen

Beispiel-Prompt für einen echten Fehler (JSON-Serialisierung in FastAPI):

Stack trace:
TypeError: Object of type Decimal is not JSON serializable
  File "/app/main.py", line 145, in process_order
    return JSONResponse(order_data)
  File "/app/models.py", line 87, in to_dict
    return {"price": self.price, "quantity": self.quantity}

Kontext:

# main.py, Zeile 140–150
async def process_order(order_id: int):
    order = await db.fetch_one("SELECT * FROM orders WHERE id = %s", order_id)
    order_obj = Order(**order)
    return JSONResponse(order_obj.to_dict())

# models.py, Zeile 80–92
class Order(BaseModel):
    price: Decimal
    quantity: int
    
    def to_dict(self):
        return {"price": self.price, "quantity": self.quantity}

# Datenbankschema:
CREATE TABLE orders (
    id INT PRIMARY KEY,
    price DECIMAL(10, 2),
    quantity INT
);

Der Fehler tritt zufällig auf, nicht bei jeder Anfrage. Was ist die Ursache und wie behebe ich sie?

Claude wird sofort erkennen, dass die Datenbank Decimal zurückgibt, FastAPI’s JSONResponse es nicht serialisiert und die to_dict()-Methode es nicht in Float oder String konvertiert. Es wird eine Korrektur vorschlagen und erklären, warum dies zufällig geschieht (abhängig davon, was der PostgreSQL-Treiber unter verschiedenen Lasten tut).

Wann dies gut funktioniert: Laufzeitfehler, Typfehler, Async/Await-Probleme, Datenbankverbindungsprobleme. Claudes Analyse des Aufrufstapels ist zuverlässig.

Wann dies fehlschlägt: Logikfehler, die keine Ausnahmen auslösen. Wenn Ihr Code ohne Fehler läuft, aber falsche Ergebnisse liefert, übersieht Claude das Problem möglicherweise. Sie müssen Testfälle oder Assertions bereitstellen, die die Diskrepanz zeigen.

Workflow 3: Neue Funktionen mit Scaffold-Prompts erstellen

Dies ist der riskanteste Workflow. Die Neuerstellung von Code von Grund auf weist die höchste Halluzinationsrate auf. Mildern Sie dies durch Scaffolding.

Das Muster:

1. Entwerfen Sie selbst die API/Funktionssignatur (welche Eingaben, welche Ausgaben)
2. Skizzieren Sie den High-Level-Algorithmus in Kommentaren (bitten Sie Claude nicht, den Algorithmus zu entwerfen)
3. Listen Sie die Abhängigkeiten und Versionen auf
4. Bitten Sie Claude, den mittleren Teil zu implementieren
5. Stellen Sie Testfälle im Prompt bereit

Schlechter Ansatz:

Erstellen Sie mir eine Funktion, die Benutzerereignisse verarbeitet und einen Cache aktualisiert. Verwenden Sie Redis.

Besserer Ansatz:

Ich benötige eine Funktion zur Verarbeitung von Trading-Ereignissen und zur Pflege eines Redis-Caches für Live-Positionen.

Funktionssignatur (nicht ändern):
async def update_position_cache(event: TradingEvent, redis: aioredis.Redis) -> bool:
    """Aktualisiert den Cache und gibt True zurück, wenn erfolgreich, False, wenn Redis-Schreibvorgang fehlschlägt."""
    pass

Algorithmus (Implementierung ausfüllen):
1. Extrahieren Sie Symbol und Menge aus dem Ereignis
2. Rufen Sie die aktuelle Position aus dem Redis-Schlüssel f"position:{symbol}" ab
3. Addieren Sie die Ereignismenge zur aktuellen Menge
4. Schreiben Sie die neue Menge mit 1-Stunden-Ablauf zurück in denselben Schlüssel
5. Protokollieren Sie die Aktualisierung
6. Geben Sie True zurück, oder False, wenn ein Redis-Vorgang fehlschlug

Einschränkungen:
- Verwenden Sie aioredis 2.x (async)
- Behandeln Sie Redis-Verbindungsfehler ordnungsgemäß (geben Sie False zurück, lösen Sie keinen Fehler aus)
- Stellen Sie sicher, dass die Funktion atomar ist (keine Race Conditions bei gleichzeitigen Ereignissen für dasselbe Symbol)

Testfälle (überprüfen Sie Ihre Implementierung anhand dieser):
- Neue Position (Schlüssel existiert nicht): Sollte den Schlüssel mit der Ereignismenge erstellen
- Bestehende Position: Sollte zur vorhandenen Menge addiert werden
- Redis-Timeout: Sollte False zurückgeben, ohne eine Ausnahme auszulösen
- Gleichzeitige Updates: Sollte sicher sein (ggf. Redis-Transaktionen verwenden)

Stellen Sie die Implementierung mit Kommentaren bereit, die nicht offensichtliche Logik erklären.

Dies funktioniert, weil Sie das Problem eingegrenzt haben. Claude entscheidet nicht über die Architektur – es implementiert Ihr Design. Dort ist es gut.

Reales Beispiel: Ich habe diesen Ansatz verwendet, um einen Webhook-Handler für Zahlungsstatus-Updates zu erstellen. Ich habe den Eingabe-/Ausgabevertrag definiert, den Kontrollfluss skizziert und die Fehlerbehandlung spezifiziert. Claude generierte die Implementierung. Es übersah einen Randfall (gleichzeitige Updates derselben Order-ID), aber die Kernlogik war solide. Diesen Randfall zu finden dauerte 30 Minuten; ihn von Grund auf neu zu erstellen hätte 4 Stunden gedauert.

Wann dies fehlschlägt: Fehler im Algorithmusdesign, die ohne Ausführung schwer zu erkennen sind. Claude schreibt zuversichtlich Code, der korrekt aussieht, aber einen logischen Fehler enthält. Testen Sie neuen Code immer mit echten Daten, bevor Sie ihn bereitstellen.

Workflow 4: Code-Review und Sicherheitsanalyse

Claude ist überraschend effektiv bei Code-Reviews. Geben Sie ihm eine Funktion und spezifische Bewertungskriterien.

Das Muster:

1. Fügen Sie den zu überprüfenden Code ein
2. Listen Sie die spezifischen Bedenken auf („Hat dies SQL-Injection-Schwachstellen?“, „Ist die Fehlerbehandlung vollständig?“, „Wird dies unter Last zu Race Conditions führen?“)
3. Bitten Sie um eine detaillierte Überprüfung, die jedes Bedenken anspricht
4. Bitten Sie um spezifische Korrekturen, nicht nur um Beobachtungen

Beispiel-Prompt:

Sicherheitsüberprüfung dieses Authentifizierungs-Handlers. Prüfen Sie auf:
1. SQL-Injection-Schwachstellen
2. Probleme bei der Passwortspeicherung
3. Token-Ablaufbehandlung
4. Lücken bei der Ratenbegrenzung
5. Anfälligkeit für Timing-Attacken

[code]

Stellen Sie für jedes gefundene Problem die genaue Code-Korrektur bereit. Wenn es keine Probleme in einer Kategorie gibt, sagen Sie "Keine Probleme in [Kategorie] gefunden".

Claude erkennt häufige Sicherheitsfehler: Passwörter im Klartext, fehlende Eingabevalidierung, schwache Token-Generierung. Es ist keine professionelle Sicherheitsprüfung, aber es ist besser als keine Überprüfung für die Markteinführungsgeschwindigkeit.

Wann dies zuverlässig ist: Syntaxfehler, offensichtliche Sicherheitslücken, unvollständige Fehlerbehandlung. Claude erkennt diese zu über 90 %.

Wann dies fehlschlägt: Subtile architektonische Schwachstellen, Race Conditions, die ein tiefes Systemverständnis erfordern, Leistungsprobleme, die nur unter bestimmten Lastmustern auftreten. Verwenden Sie Claude nicht als einzigen Code-Reviewer für kritische Sicherheitspfade.

Workflow 5: Migration zwischen Sprachen oder Frameworks

Hier hilft Claudes architektonisches Verständnis. Portieren Sie Code von Python nach JavaScript oder von synchron zu asynchron, ohne den Kontext zu verlieren.

Das Muster:

1. Stellen Sie den Originalcode bereit
2. Geben Sie die Zielsprache/das Ziel-Framework und die Version an
3. Listen Sie alle Idiome oder Muster auf, die für das Ziel spezifisch sind („verwende async/await, keine Callbacks“ oder „verwende FastAPI-Konventionen, nicht Flask“)
4. Nennen Sie alle Bibliotheken, die den ursprünglichen Abhängigkeiten entsprechen
5. Bitten Sie um eine vollständige Portierung, keine Zeile-für-Zeile-Übersetzung

Beispiel: Python async zu Node.js:

Portieren Sie diesen Python-Async-Code nach Node.js (TypeScript, Async/Await-Stil).

Abhängigkeitszuordnung:
- asyncpg (PostgreSQL) → pg (mit Async-Wrapper)
- aioredis → redis (v4+)
- dataclasses → TypeScript-Schnittstellen

Einschränkungen:
- Verwenden Sie TypeScript mit strengem Modus
- Fehlerbehandlung muss mit dem Original übereinstimmen (Ausnahmen werden zu Promise-Rejections)
- Halten Sie Funktionssignaturen mit bestehenden Express-Middleware kompatibel

[Original Python-Code]

Stellen Sie die vollständige TypeScript-Portierung bereit. Heben Sie Unterschiede in der Fehlerbehandlung oder im Async-Verhalten hervor.

Claude versteht Sprachidiome gut genug, um wörtliche Übersetzungen zu vermeiden, die zwar funktionieren, aber nicht natürlich wirken.

Wann dies funktioniert: Unkomplizierte Geschäftslogik, Datentransformation, API-Handler. Claude portiert diese sauber.

Wann dies fehlschlägt: Code, der auf sprachspezifischen Laufzeiteigenschaften beruht (Python’s GIL, JavaScript’s Event Loop, Go’s Goroutines). Claude versteht diese konzeptionell, vergisst aber manchmal Implementierungsdetails.

Modellauswahl: Sonnet vs. Opus vs. Haiku

Für Coding-Workflows: Beginnen Sie mit Sonnet. Es bewältigt 95 % der Produktionsanwendungsfälle zu angemessenen Kosten. Verwenden Sie Opus nur, wenn Sonnet bei Multi-File-Refactorings oder architektonischen Fragen Schwierigkeiten hat. Verwenden Sie Haiku für automatisierte Linter oder Stapelverarbeitung.

Ich habe dies im Code von AlgoVesta getestet: Sonnet refaktorierte 12 von 13 Modulen korrekt. Opus schaffte 13 von 13, kostete aber 5x mehr. Für den einen Fehler war Sonnets Ausgabe immer noch verwendbar – sie erforderte nur eine manuelle Korrektur. Dieser Kompromiss ist für die Iterationsgeschwindigkeit rational.

Häufige Fehlerquellen und wie man sich davon erholt

Halluzinierte Abhängigkeiten: Claude schlägt den Import einer nicht vorhandenen Bibliothek vor oder verwendet eine API, die in einer neueren Version geändert wurde. Korrektur: Geben Sie in Ihrem Scaffold-Prompt immer genaue Versionen an. Bitten Sie Claude, Importe gegen Dokumentationslinks zu verifizieren, wenn das Paket weniger verbreitet ist.

Vereinfachte Fehlerbehandlung: Claude generiert Try/Except- oder Try/Catch-Blöcke, die alle Ausnahmen wahllos abfangen. Korrektur: Geben Sie in Ihrem Prompt an, welche Ausnahmen wichtig sind und wie jede einzelne zu behandeln ist. Stellen Sie ein Beispiel für ordnungsgemäße Fehlerbehandlung aus Ihrem Code bereit.

Race Conditions in asynchronem Code: Claude generiert asynchrone Funktionen, die korrekt aussehen, aber subtile Nebenläufigkeitsfehler aufweisen. Korrektur: Wenn asynchroner Code involviert ist, bitten Sie Claude, parallele Ausführungsszenarien explizit zu analysieren. Bitten Sie es, gemeinsame Zustände zu identifizieren, die geschützt werden müssen (Sperren, atomare Operationen).

Annahmen über das Datenbankschema: Claude geht von bestimmten Spaltennamen, Typen oder Einschränkungen aus, die nicht mit Ihrem tatsächlichen Schema übereinstimmen. Korrektur: Fügen Sie Ihre tatsächliche Schema-Definition in den Prompt ein. Beschreiben Sie es nicht – zeigen Sie die DDL- oder ORM-Modell-Definition.

Fehlende Konfigurations- oder Umgebungsvariablen: Claude generiert Code, der davon ausgeht, dass Konfiguration verfügbar ist, gibt aber nicht an, woher sie stammt. Korrektur: Zeigen Sie Claude, wie Konfiguration in Ihrem aktuellen Code geladen wird. Stellen Sie ein funktionierendes Beispiel bereit.

Integration in Ihren Entwicklungszyklus

Für Refactoring: Verwenden Sie Claude zuerst für Module, die Sie gut verstehen (geringes Risiko), bevor Sie Module angehen, mit denen Sie weniger vertraut sind (höheres Risiko). Überprüfen Sie die Ausgabe von Claude anhand Ihrer Testsuite – wenn die Tests bestehen, können Sie sicher bereitstellen.

Für Fehlersuche: Verwenden Sie Claude als ersten Schritt. Wenn der Stack-Trace klar und der Kontext offensichtlich ist, trifft Claude ihn normalerweise in unter einer Minute. Wenn die Diagnose falsch ist, haben Sie nichts verloren – Sie kehren zur herkömmlichen Fehlersuche zurück.

Für neue Funktionen: Verwenden Sie Claude für die Implementierung, sobald Sie die API und den Algorithmus entworfen haben. Bitten Sie Claude niemals, die Architektur von Grund auf neu zu entwerfen – Sie erhalten über- oder unterdimensionierte Lösungen, die nicht zu Ihrem System passen.

Für Code-Reviews: Verwenden Sie Claude als ersten Filter vor einer menschlichen Überprüfung. Es erkennt über 70 % der häufigsten Fehler. Ihr Team kann sich auf architektonische und geschäftslogische Überprüfungen konzentrieren, anstatt auf die Syntax.

Was Sie heute tun können

Wählen Sie ein Produktionsmodul in Ihrer Codebasis aus, das Sie refaktorieren wollten, aber noch keine Priorität eingeräumt haben. Geben Sie dieses Modul an Claude Sonnet zusammen mit den Einschränkungen und Zielen (mithilfe des obigen Scaffold-Musters). Wenn die Ausgabe Ihre Testsuite besteht, haben Sie gerade Entwicklungszeit zurückgewonnen. Wenn Anpassungen erforderlich sind, haben Sie gelernt, wo Ihre Einschränkungen unklar waren.

Beginnen Sie mit dem Refactoring, nicht mit neuem Code. Das Risiko ist geringer und die Lernkurve kürzer. Sobald Sie von Claudes Ausgabe für bekannten Code überzeugt sind, können Sie zum Debugging und zur Feature-Generierung übergehen.