Es war 2 Uhr morgens an einem Dienstag, als mir klar wurde, dass das Abrechnungssystem den Nutzern den doppelten Betrag berechnete. Der Bug war bereits seit sechs Stunden in der Production. 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 des Aufbaus von LemonData: 274 API-Routen, 46 Datenbankmodelle und über 100.000 Zeilen Code mit einem AI-Coding-Assistant. Nicht die geschönte „Sehen Sie, wie produktiv AI Sie macht“-Geschichte. Die echte, mit den Fehlern, den Debugging-Sessions um 3 Uhr morgens und den Momenten, in denen ich mich fragte, ob AI-gestützte Entwicklung wirklich eine gute Idee war.
Der Pitch vs. die Realität der AI-gestützten Entwicklung
Der Pitch für AI-Coding-Assistants ist verführerisch: Sie beschreiben, was Sie wollen, die AI schreibt es, Sie prüfen es und gehen live. In der Theorie 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, refactorisierte dateiübergreifend. Ich lieferte schneller aus als je 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 zufälligen Stellen hardcoded. Typdefinitionen widersprachen sich paketübergreifend. Die Codebase wuchs schnell, wurde aber auch zu einem Labyrinth aus „funktioniert, aber ich weiß nicht warum“-Code.
Und dieser Abrechnungs-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 AI hatte keine Möglichkeit, von diesem Edge Case zu wissen, weil ich ihn nicht explizit erwähnt hatte, und die Test-Suite, die ebenfalls teilweise AI-generiert war, 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 sie waren nicht Claudes Schuld, zumindest nicht ganz. Sie waren das vorhersehbare Ergebnis einer AI, die auf „Code, der jetzt funktioniert“ optimiert, statt auf „Code, der morgen funktioniert“.
1. Das Konsistenzproblem
Claude implementierte dieselbe Logik unterschiedlich, je nachdem, in welcher Datei es arbeitete, welche Beispiele es zuletzt gesehen hatte oder scheinbar einfach nach Zufall. Ein API-Endpoint gab { data: users } zurück, ein anderer { users }. Beides funktionierte. Nichts passte zusammen. Debugging wurde zur Archäologie.
2. Das Copy-Paste-Problem
Warum sollte eine AI ein gemeinsames Utility erstellen, wenn das Duplizieren von Code schneller geht und nicht das Risiko birgt, bestehende Funktionen zu zerstören? Jedes Mal, wenn ich nach einem neuen Feature fragte, das einem bestehenden ähnelte, erhielt ich eine neue Implementierung anstatt einer refactorisierten gemeinsamen Lösung. Nach drei Wochen hatte ich fünf verschiedene „format currency“-Funktionen über die Codebase verteilt.
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 davon ab, aber nicht die semantischen Unstimmigkeiten – die Fälle, in denen die Typen technisch korrekt, aber logisch inkonsistent waren.
4. Das Konfigurations-Streuungs-Problem
Datenbank-URLs, API-Keys, Feature-Flags und Rate Limits landeten 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
AI-generierte Tests neigen dazu, den Happy Path gründlich zu testen und Edge Cases komplett zu übersehen. Der Abrechnungs-Bug war ein perfektes Beispiel: Die Test-Suite deckte normale Zahlungsabläufe wunderbar ab. Sie testete nie, was passiert, wenn zwei Zahlungsbestätigungen innerhalb derselben Millisekunde eingehen.
6. Das Problem des lautlosen Scheiterns
Claude fügte catch (error) { console.log(error) }-Blöcke hinzu, die Exceptions verschluckten. In der Entwicklung sah das gut aus, weil Fehler in der Konsole erschienen. In der Production wurden kritische Fehler lautlos protokolliert und vergessen.
7. Die Dokumentationslücke
Claude schreibt exzellente Code-Kommentare. Es schreibt schreckliche Architekturdokumentation. Es kann erklären, was eine Funktion tut, aber es kann nicht erklären, warum das System so strukturiert ist, wie es ist, oder welche Einschränkungen zu einer bestimmten Designentscheidung 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 alle Konventionen, Einschränkungen und Architekturentscheidungen enthält, die Claude kennen muss.
Keine Dokumentation für Menschen. Dokumentation für die AI.
## API-Antwortformat
Immer verwenden: { success: true, data: T } oder { success: false, error: string }
Niemals Rohdaten ohne Wrapper zurückgeben.
## Währung
Interne Speicherung: USD. Anzeige: formatCurrency(amount, currency, rate).
Wechselkurse niemals hardcoden. CNY niemals direkt speichern.
## Fehlerbehandlung
Niemals catch(e) { console.log(e) } verwenden.
Immer den Logger verwenden: 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 hinweisen, und es korrigierte sich selbst.
Aber CLAUDE.md allein reichte nicht aus. Ich brauchte eine automatisierte Durchsetzung.
Das Sicherheitsnetz aufbauen: CI-Gates für AI-generierten Code
Wir haben eine CI-Pipeline mit Gates aufgebaut, die in einer traditionellen Codebase paranoid erscheinen würden, weil sie dazu dienen, AI-generierte Bugs abzufangen, bevor die Nutzer es tun:
- Typprüfung über das gesamte Monorepo hinweg
- SSOT-Audits, die sicherstellen, dass keine doppelten Implementierungen existieren
- Enum-Sync-Checks zwischen Datenbank-Enums und TypeScript-Enums
- Validierung des API-Antwortformats
- Security-Gates für Abrechnungs-, Berechtigungs- und Authentifizierungscode
Die wichtigste Erkenntnis ist einfach: Claude ist ein Verstärker, kein Ersatz. Es verstärkt Ihre Produktivität, aber es verstärkt auch Ihre Fehler. Wenn Sie keine starken Konventionen haben, wird Claude seine eigenen erfinden, und die werden nicht konsistent sein. Wenn Sie keine automatisierten Prüfungen haben, werden Claudes Bugs die Production schneller erreichen, als menschliche Bugs es jemals könnten.
Der Abrechnungs-Bug konnte nicht mehr passieren. Nicht weil Claude klüger wurde, sondern weil die Pipeline nun eine explizite Behandlung von asynchronen Race Conditions erforderte, verifiziert durch ein Gate, das auf korrektes Locking in Zahlungsflüssen prüfte.
Was „AI Native Development“ wirklich bedeutet
Wenn ich sage, LemonData ist eine „AI Native Infrastructure“, meine ich nicht, dass wir einem bestehenden Produkt AI-Features hinzugefügt haben. Ich meine, dass der gesamte Entwicklungsprozess von der Realität der Arbeit mit einem AI-Coding-Partner geprägt wurde.
Unsere Dokumentation ist detaillierter, als sie es sonst wäre, weil Claude expliziten Kontext benötigt, den ein menschlicher Teamkollege vielleicht ableiten würde. Unser Typsystem ist strenger als nötig, weil Claude jede Mehrdeutigkeit ausnutzen wird. Unsere CI-Pipeline hat Gates, die in einer traditionellen Codebase paranoid erscheinen würden, weil sie dazu dienen, AI-generierte Bugs abzufangen, bevor die Nutzer es tun.
Das Ergebnis ist eine Codebase, die tatsächlich wartbarer ist als die meisten, an denen ich gearbeitet habe. Nicht weil AI besseren Code schreibt als Menschen, sondern weil der Aufbau für AI-gestützte Entwicklung mich dazu zwang, all die Konventionen und Prüfungen explizit zu machen, die normalerweise nur in den Köpfen von Senior-Entwicklern existieren.
Für mehr Informationen darüber, was AI Native als Philosophie bedeutet, siehe What Is AI Native?
Wenn Sie die praktischere Seite suchen („Wie fange ich an, das anzuwenden?“), sind die beiden besten weiterführenden Artikel der Agent-First API Design Guide und der Migration Guide. Der eine erklärt die API-Struktur. Der andere zeigt, wie schnell ein Team tatsächlich die Richtung ändern kann, sobald der Workflow für den Modellwechsel ausgelegt ist.
Lektionen für Entwickler, die mit AI-Coding-Assistanten bauen
Wenn Sie ein Projekt mit Claude Code, Cursor oder einem anderen AI-Coding-Assistant starten:
- Erstellen Sie Ihre
CLAUDE.mdam ersten Tag, nicht erst in der dritten Woche wie ich. - Automatisieren Sie die Durchsetzung von Konventionen. Verlassen Sie sich nicht darauf, dass die AI sich an Regeln erinnert.
- Überprüfen Sie AI-Code so, 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. AI-generierte Tests decken Happy Paths ab, keine Race Conditions.
- Zentralisieren Sie die Konfiguration von Anfang an. Das Streuungsproblem verschärft sich schnell.
- Verwenden Sie striktes TypeScript. Es ist Ihre beste Verteidigung gegen Type Drift.
- Bauen Sie frühzeitig CI-Gates 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 statt in der dritten Woche. 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 AI-Modelle, eine einheitliche API, Multi-Währungs-Abrechnung und 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.
AI-gestützte Entwicklung ist keine Magie. Es ist eine neue Art von Engineering-Disziplin. Und wie alle Disziplinen belohnt sie diejenigen, die ihre Einschränkungen respektieren.
FAQ
Kann ein einzelner Entwickler wirklich eine produktionsreife Plattform mit Claude Code bauen?
Ja, aber mit Vorbehalten. Die AI übernimmt die Codegenerierung und das Refactoring in unglaublicher Geschwindigkeit, aber man braucht immer noch ein starkes architektonisches Urteilsvermögen, automatisierte Quality-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 AI-Coding-Assistants für den Kontext lesen. Sie enthält Coding-Konventionen, Architekturentscheidungen und Einschränkungen, die die AI befolgen sollte. Betrachten Sie es als Onboarding-Dokumentation für Ihren AI-Teamkollegen.
Wie verhindert man AI-generierte Bugs in der Production?
Automatisierte CI-Gates sind unerlässlich: Typprüfung, SSOT-Audits, Enum-Sync-Verifizierung und domänenspezifische Security-Gates. Die wichtigste Erkenntnis ist, dass AI sowohl die Produktivität als auch die Fehler verstärkt, sodass man automatisierte Prüfungen benötigt, um die verstärkten Fehler abzufangen.
Ist AI-gestützte Entwicklung für Abrechnungs- und Zahlungssysteme geeignet?
Ja, aber mit besonderer Vorsicht. Zahlungscode benötigt eine explizite Behandlung von Race Conditions, ordnungsgemäßes Locking und gründliche Edge-Case-Tests. AI-generierte Tests decken eher Happy Paths ab, daher müssen Sie Fehlerszenarien und gleichzeitige Operationen manuell testen.
LemonData bietet Ihnen Zugriff auf über 300 AI-Modelle über eine einzige API. Starten Sie kostenlos und testen Sie die Plattform mit 1 $ Guthaben.
