Aufbau einer produktionsreifen KI-Plattform mit Claude Code in 30 Tagen: Die ehrliche Geschichte
Es war Dienstagmorgen um 2 Uhr, als mir klar wurde, dass das Billing-System den Nutzern den doppelten Betrag berechnete. Der Bug war bereits seit sechs Stunden in der Produktion. Claude Code hatte die Logik für den Zahlungsabgleich an diesem Nachmittag generiert, und ich hatte sie überprüft, getestet und veröffentlicht. Der Code sah perfekt aus. Er bestand jeden Test. Und er war grundlegend fehlerhaft.
Dies ist die Geschichte über den Aufbau von LemonData — 274 API-Routen, 46 Datenbank-Modelle, über 100.000 Zeilen Code — mit einem KI-Coding-Assistant. Nicht die geschönte „Schau mal, wie produktiv KI dich macht“-Geschichte. Sondern die echte, mit den Fehlern, den Debugging-Sessions um 3 Uhr morgens und den Momenten, in denen ich mich fragte, ob KI-gestützte Entwicklung wirklich eine gute Idee war.
Der Pitch vs. die Realität der KI-gestützten Entwicklung
Das Versprechen von KI-Coding-Assistants ist verlockend: Du beschreibst, was du willst, die KI schreibt es, du prüfst es und veröffentlichst es. Theoretisch kann ein einzelner Entwickler nun die Arbeit eines ganzen Teams erledigen.
In der Praxis? Die ersten zwei Wochen waren unglaublich. Claude Code verstand meine Codebase, generierte vollständige Features und führte Refactorings über mehrere Dateien hinweg durch. Ich lieferte schneller aus als jemals zuvor in meiner Karriere. Der Dopamin-Kick, Issues so schnell abzuschließen, war berauschend.
Dann zeigten sich die ersten Risse.
Dieselbe Funktion tauchte in drei verschiedenen Dateien mit leicht unterschiedlichen Implementierungen auf. Konfigurationswerte waren an wahllosen Stellen fest im Code hinterlegt. Typdefinitionen widersprachen sich paketübergreifend. Die Codebase wuchs schnell, entwickelte sich aber auch zu einem Labyrinth aus „funktioniert, aber ich weiß nicht genau warum“-Code.
Und dieser Billing-Bug? Claude hatte eine völlig vernünftig aussehende Abgleichsfunktion generiert. Aber sie berücksichtigte keine Race Condition in unserem asynchronen Zahlungsbestätigungs-Flow. Die KI konnte von diesem Edge Case nichts wissen, weil ich ihn nicht explizit erwähnt hatte, und die Test-Suite — ebenfalls teilweise KI-generiert — hatte ihn auch nicht abgedeckt.
Die sieben Muster, die immer wieder scheiterten
Nach einem Monat Arbeit mit Claude Code fing ich an, eine Liste zu führen. Nicht direkt von Bugs, sondern von Mustern. Dieselben Arten von Fehlern passierten immer wieder, und es war nicht Claudes Schuld — zumindest nicht ganz. Sie waren das vorhersehbare Ergebnis einer KI, die auf „Code, der jetzt funktioniert“ optimiert ist, statt auf „Code, der morgen funktioniert“.
1. Das Konsistenz-Problem
Claude implementierte dieselbe Logik unterschiedlich, je nachdem, in welcher Datei gearbeitet wurde, welche Beispiele es zuletzt gesehen hatte oder scheinbar einfach nach dem Zufallsprinzip. Ein API-Endpoint gab { data: users } zurück, ein anderer { users }. Beides funktionierte. Nichts davon passte zusammen. Debugging wurde zur Archäologie.
2. Das Copy-Paste-Problem
Warum sollte eine KI ein gemeinsames Utility erstellen, wenn das Duplizieren von Code schneller geht und nicht das Risiko birgt, bestehende Funktionen zu beeinträchtigen? Jedes Mal, wenn ich nach einem neuen Feature fragte, das einem bestehenden ähnelte, erhielt ich eine neue Implementierung statt einer refactored gemeinsamen Lösung. Nach drei Wochen hatte ich fünf verschiedene „Währungsformatierungs“-Funktionen in der Codebase verstreut.
3. Das Type-Drift-Problem
Ein neuer Statuswert wurde in einer Datei hinzugefügt, aber nicht in der Enum-Definition. Ein Feld war in der API-Antwort optional, aber im Frontend-Typ erforderlich. TypeScript fing einige dieser Fehler ab, aber nicht die semantischen Diskrepanzen — die Fälle, in denen die Typen technisch korrekt, aber logisch inkonsistent waren.
4. Das Konfigurations-Chaos
Datenbank-URLs, API-Keys, Feature-Flags, Rate-Limits — Claude platzierte sie dort, wo es für die aktuelle Aufgabe gerade bequem war. Manchmal in Umgebungsvariablen, manchmal in einer Konfigurationsdatei, manchmal hardcoded. Alle Stellen zu finden, an denen ein Wert definiert war, wurde zur Schatzsuche.
5. Die Illusion der Testabdeckung
KI-generierte Tests neigen dazu, den Happy Path gründlich zu testen und Edge Cases komplett zu übersehen. Der Billing-Bug war ein perfektes Beispiel: Die Test-Suite deckte normale Zahlungsabläufe wunderbar ab. Sie testete jedoch nie, was passiert, wenn zwei Zahlungsbestätigungen innerhalb derselben Millisekunde eingehen.
6. Das Problem der lautlosen Fehler
Claude fügte oft catch (error) { console.log(error) } Blöcke hinzu, die Exceptions einfach verschluckten. In der Entwicklung sah das gut aus — Fehler erschienen in der Konsole. In der Produktion wurden kritische Fehler lautlos protokolliert und vergessen.
7. Die Dokumentationslücke
Claude schreibt exzellente Code-Kommentare. Aber es schreibt schreckliche Architektur-Dokumentationen. Es kann erklären, was eine Funktion macht, aber es kann nicht erklären, warum das System so strukturiert ist, wie es ist, oder welche Einschränkungen zu einer bestimmten Design-Entscheidung geführt haben.
Die CLAUDE.md Lösung
Der Wendepunkt kam in der dritten Woche, als ich CLAUDE.md erstellte — eine Datei im Projekt-Root, die jede Konvention, jede Einschränkung und jede architektonische Entscheidung enthält, die Claude kennen muss.
Keine Dokumentation für Menschen. Dokumentation für die KI.
## API Response Format
Always use: { success: true, data: T } or { success: false, error: string }
Never return raw data without the wrapper.
## Currency
Internal storage: USD. Display: formatCurrency(amount, currency, rate).
Never hardcode exchange rates. Never store CNY directly.
## Error Handling
Never use catch(e) { console.log(e) }.
Always use the logger: logger.error('context', { error }).
Der Effekt war sofort spürbar. Claude fing an, Konventionen konsistent zu befolgen. Wenn es Code generierte, der gegen eine Regel verstieß, konnte ich auf die spezifische Zeile in CLAUDE.md verweisen, und es korrigierte sich selbst.
Aber CLAUDE.md allein reichte nicht aus. Ich brauchte eine automatisierte Durchsetzung.
Das Sicherheitsnetz aufbauen: CI-Gates für KI-generierten Code
Wir haben eine CI-Pipeline mit Gates aufgebaut, die in einer traditionellen Codebase paranoid wirken würden — weil sie dazu da sind, KI-generierte Bugs abzufangen, bevor die Nutzer sie bemerken:
- Type-Checking über das gesamte Monorepo hinweg (fängt Type-Drift ab)
- SSOT-Audit, das verifiziert, dass keine doppelten Implementierungen existieren
- Enum-Sync-Check, der sicherstellt, dass Datenbank-Enums mit TypeScript-Enums übereinstimmen
- Validierung des API-Antwortformats (löst das Konsistenz-Problem)
- Security-Gates für Billing-, Berechtigungs- und Authentifizierungs-Code
Die wichtigste Erkenntnis: Claude ist ein Verstärker, kein Ersatz. Es verstärkt deine Produktivität, aber es verstärkt auch deine Fehler. Wenn du keine starken Konventionen hast, wird Claude seine eigenen erfinden — und die werden nicht konsistent sein. Wenn du keine automatisierten Checks hast, werden Claudes Bugs die Produktion schneller erreichen, als menschliche Bugs es jemals könnten.
Der Billing-Bug könnte so nicht mehr passieren. Nicht, weil Claude klüger geworden ist, sondern weil die Pipeline nun eine explizite Behandlung von asynchronen Race Conditions verlangt, verifiziert durch ein Gate, das auf korrektes Locking in Zahlungsabläufen prüft.
Was „AI Native Development“ wirklich bedeutet
Wenn ich sage, dass LemonData eine „AI Native Infrastructure“ ist, meine ich nicht, dass wir einem bestehenden Produkt KI-Features hinzugefügt haben. Ich meine, dass der gesamte Entwicklungsprozess von der Realität der Zusammenarbeit mit einem KI-Coding-Partner geprägt wurde.
Unsere Dokumentation ist detaillierter, als sie es sonst wäre — weil Claude expliziten Kontext benötigt, den ein menschlicher Kollege vielleicht schlussfolgern würde. Unser Typ-System ist strenger als nötig — weil Claude jede Mehrdeutigkeit ausnutzen wird. Unsere CI-Pipeline hat Gates, die in einer traditionellen Codebase paranoid wirken würden — weil sie existieren, um KI-generierte Bugs abzufangen, bevor Nutzer sie finden.
Das Ergebnis ist eine Codebase, die tatsächlich wartbarer ist als die meisten, an denen ich bisher gearbeitet habe. Nicht weil die KI besseren Code schreibt als Menschen, sondern weil der Aufbau für KI-gestützte Entwicklung mich dazu zwang, alle Konventionen und Prüfungen explizit zu machen, die normalerweise nur in den Köpfen von Senior-Entwicklern existieren.
Mehr darüber, was „AI Native“ als Philosophie bedeutet, finden Sie unter Was ist AI Native?
Lektionen für Entwickler, die mit KI-Coding-Assistants arbeiten
Wenn Sie ein Projekt mit Claude Code, Cursor oder einem anderen KI-Coding-Assistant starten:
- Erstellen Sie Ihre CLAUDE.md am ersten Tag — nicht erst in Woche drei wie ich.
- Automatisieren Sie die Durchsetzung von Konventionen — verlassen Sie sich nicht darauf, dass die KI sich an Regeln erinnert.
- Reviewen Sie KI-Code, als hätte ihn ein Junior-Entwickler geschrieben — er ist schnell und fähig, aber es fehlt ihm an Kontext.
- Testen Sie Edge Cases manuell — KI-generierte Tests decken Happy Paths ab, keine Race Conditions.
- Zentralisieren Sie die Konfiguration von Anfang an — das Streuungs-Problem verschlimmert sich schnell.
- Nutzen Sie striktes TypeScript — es ist Ihre beste Verteidigung gegen Type-Drift.
- Bauen Sie CI-Gates frühzeitig auf — sie zahlen sich bereits in der ersten Woche aus.
Würde ich es wieder tun?
Absolut. Aber ich würde am ersten Tag mit CLAUDE.md beginnen. Und ich würde daran denken, dass der 10-fache Produktivitätsmultiplikator auch einen 10-fachen Multiplikator für die Folgen von Fehlern beinhaltet.
Die Plattform, die wir aufgebaut haben — über 300 KI-Modelle, eine vereinheitlichte API, Multi-Währungs-Billing, Internationalisierung in 13 Sprachen — hätte ein traditionelles Team Monate gekostet. Wir haben sie in 30 Tagen veröffentlicht. Die Bugs waren real, aber die Geschwindigkeit war es auch.
KI-gestützte Entwicklung ist keine Magie. Es ist eine neue Art von Ingenieursdisziplin. Und wie alle Disziplinen belohnt sie diejenigen, die ihre Einschränkungen respektieren.
FAQ
Kann ein einzelner Entwickler wirklich eine produktionsreife Plattform mit Claude Code aufbauen?
Ja, aber mit Vorbehalten. Die KI übernimmt die Codegenerierung und das Refactoring in unglaublicher Geschwindigkeit, aber man benötigt immer noch ein starkes architektonisches Urteilsvermögen, automatisierte Qualitäts-Gates und die Disziplin, alles sorgfältig zu prüfen. Die 10-fache Geschwindigkeit beinhaltet 10-mal schnellere Bugs, wenn man nicht vorsichtig ist.
Was ist CLAUDE.md?
CLAUDE.md ist eine Instruktionsdatei auf Projektebene, die KI-Coding-Assistants für den Kontext lesen. Sie enthält Coding-Konventionen, architektonische Entscheidungen und Einschränkungen, die die KI befolgen sollte. Betrachten Sie es als Onboarding-Dokumentation für Ihren KI-Teamkollegen.
Wie verhindert man KI-generierte Bugs in der Produktion?
Automatisierte CI-Gates sind unerlässlich: Type-Checking, SSOT-Audits, Enum-Sync-Verifizierung und domänenspezifische Security-Gates. Die wichtigste Erkenntnis ist, dass KI sowohl die Produktivität als auch Fehler verstärkt — man braucht automatisierte Prüfungen, um die verstärkten Fehler abzufangen.
Ist KI-gestützte Entwicklung für Billing- und Zahlungssysteme geeignet?
Ja, aber mit besonderer Vorsicht. Zahlungs-Code benötigt eine explizite Behandlung von Race Conditions, korrektes Locking und gründliche Tests von Edge Cases. KI-generierte Tests decken oft nur Happy Paths ab — man muss Fehlerszenarien und gleichzeitige Operationen manuell testen.
LemonData bietet Ihnen Zugriff auf über 300 KI-Modelle über eine einzige API. Wir haben es mit KI gebaut, um KI zu dienen. Kostenlos starten — neue Nutzer erhalten 1 $ Startguthaben.
