[GN] Nicht-Entwickler + Claude im Produktivbetrieb über 238 Tage — Was funktioniert hat und was nicht?

(chajooin.com)

7 Punkte von workdriver 2026-04-12 | 5 Kommentare | Auf WhatsApp teilen

Ich bin der Betreiber, der chajooin.com erstellt hat. Schulabschluss: Highschool, 8 Jahre im Güterkraftverkehr (seit 2017). Ohne auch nur eine Zeile Code schreiben zu können, habe ich am 16. August 2025 zusammen mit Claude meinen ersten Commit gemacht. 238 Tage sind vergangen, und dieser Service sammelt heute täglich automatisch Daten und veröffentlicht Berichte.

Dieser Text ist kein Bericht darüber, dass ich es "gebaut habe", sondern eine Aufzeichnung darüber, dass ich es "gebaut habe und im Betrieb halte". Es gibt viele Erfahrungsberichte darüber, mit Vibe Coding einen Prototypen zu bauen, aber Erfahrungen mit dauerhaftem Produktivbetrieb sind selten, deshalb schreibe ich das hier. Es ist keine Erfolgsgeschichte, sondern eine ehrliche Aufzeichnung dessen, was funktioniert hat und was nicht.

Hintergrund

Domäne: Vergleich von Gebrauchtpreisen für Lkw (Marktvolumen 17 Billionen Won, keine offiziellen Aufzeichnungen realer Transaktionspreise)
Früherer Versuch: 2024 Turnkey-Outsourcing für 30 Mio. Won → aufgegeben, weil die Kontrolle über Änderungen beim Dienstleister lag
Umstieg: 2 Monate AI-Lernen ab Juli 2025 → erster Commit am 16. August

Stack

Frontend    Vite + React + TypeScript + Tailwind  
Backend     Node.js + Express + Prisma  
DB          PostgreSQL (Railway managed)  
수집        Playwright (headless) + 46 Parser je Quelle  
ML          LightGBM (Python, 75 Features)  
배포        Railway (Docker)  
자동화      Node scheduler + Telegram-Benachrichtigungen  
AI 협업     Claude (Hauptentwicklung) + GPT-4o (Shorts-Skripte/Prompts)  
인증        Naver/Kakao OAuth

Ich habe den Stack nicht „ausgewählt“. Ich habe die AI gefragt: „Was muss ich verwenden, um das hier zu bauen?“ und ihre Antwort einfach übernommen. Im Nachhinein war es eine sinnvolle Kombination. Der praktische Wert eines AI-Agenten: Er nimmt einem die kognitive Last von Entscheidungen ab.

Zahlen (2025-08-16 ~ 2026-04-12)

Punkt	Wert
Alle Commits	3.493
Tage mit Commits	189 Tage
Anzahl Code-Dateien	ca. 1.500 (auf Basis von js/ts/py)
Rollbacks	20+
Fehlgeschlagene Deployments	39 (2 Tage frühes Railway-Setup)
Maximale Wiederholung desselben Bugs	7-mal (Preiseinheit)
Aktive Inserate	ca. 48.000 Fahrzeuge
Parser für externe Quellen	46
CLAUDE.md	187 Zeilen, 24 absolute Regeln
Memory-Dateien	129

Teil 1. Bauen — 3 Dinge, die es zum Laufen gebracht haben

1.1 CLAUDE.md — AI mit Regeln steuern

Wenn derselbe Bug ein zweites Mal auftritt, ist „Bitte pass besser auf“ bedeutungslos. Ich schreibe konkrete Regeln in eine Datei und lasse die AI sie zu Beginn jeder Session lesen.

"Parser=Quelle → Normalisierung=÷10.000 → DB=10.000 Won. Kein ×10.000 auf DB-Werte"  
"Wenn die Extraktion des Modelljahrs im Parser fehlschlägt, kein getFullYear() einsetzen"  
"kakaotalk nicht zu vercel.json UA rewrite hinzufügen"  
"setInterval-Wert muss mit Math.min(value, 2^31-1) gekappt werden"

Inzwischen sind es 24 Regeln. Sie sind alle erst nach realen Vorfällen entstanden.

1.2 Rollentrennung — Planung/Beurteilung beim Menschen, Umsetzung bei der AI

Auch wenn ich den Code nicht lesen kann, kann ich das Ergebnis beurteilen. Wenn ein Porter 2-Tonner mit 5 Mio. Won angezeigt wird, kann ich sagen: „Das ist falsch.“ Und wenn Wingbody und Cargo mit demselben Preis auftauchen, kann ich sagen: „Trennt das.“ Domaingefühl übernimmt die Rolle des Tests.

1.3 Memory-Dateien — Kontext über Sessions hinweg erhalten

In 129 Memory-Dateien sammle ich Entscheidungen, Fehlschläge und Richtlinien. Wenn eine neue Session beginnt, liest sie die relevanten Memorys und behält frühere Entscheidungen bei. So werden die Grenzen des AI-Kontextfensters über das Dateisystem ausgeglichen.

Teil 2. Betrieb — andere Probleme als beim Bauen

2.1 Was automatisiert läuft

Inserats-Ingestion: Der Scheduler sammelt Daten aus externen Quellen → Qualitäts-Gate → Übernahme in die DB
Preisberichte: Täglich automatisch erzeugt → automatisch in Blog/Café veröffentlicht
Erzeugung von Shorts-Skripten: GPT-4o erzeugt je Tonnageklasse Skripte/Sora-Prompts (die Videosynthese ist ein separater Schritt)
ML-Retraining: 1-mal pro Woche Retraining der Preis-Engine mit neuen Daten
Monitoring: Telegram-Benachrichtigung bei Pipeline-Anomalien

Ich bin der einzige Entwickler.

2.2 Kosten

Infrastruktur: Railway (PostgreSQL + Node + Playwright)
AI API: Claude-Abo (für Entwicklung) + GPT-4o API (für Shorts-Generierung, auf Basis von api_usage_log geschätzt etwa 1 USD pro Monat)
Domain/OAuth: Naver/Kakao

2.3 Aufzeichnung der Störfallbehandlung

1.138 Fälle von Datenkorruption (2.3.): Fallback-Bug beim Modelljahr entdeckt → DB-Patch + Reprocessing-Pipeline + Regel ergänzt
Slack-Benachrichtigungen 6 Monate ohne Funktion (am 18.3. entdeckt): Problem mit Umgebungsvariablen/Pfad → auf einen einzigen Telegram-Pfad konsolidiert und neu aufgebaut
setInterval 32-Bit-Overflow (10.4.): Login-Ausfall → Hotfix + Clamping-Regel ergänzt
Leerer Bildschirm in KakaoTalk (31.1.): SEO-UA-Rewrite erfasste auch den In-App-Browser von KakaoTalk → UA-Liste korrigiert

2.4 Auszug aus den Betriebsregeln

In CLAUDE.md stehen auch Regeln aus Betriebssicht.

"Nach dem Deployment mit 3 Zahlen berichten: Serverstatus (health 200),  
 Anzahl der heutigen Crawls (innerhalb von ±20 % zu gestern), Anzahl aktiver Inserate (keine sprunghafte Änderung)"  
  
"Bei Änderungen an 4 oder mehr Dateien, bei Scheduler-Anbindung, bei DB-Schema-Änderungen,  
 bei erneuter Änderung eines zuvor revertierten Bereichs → Vorabbericht Pflicht"  
  
"Temporäre Änderungen (Fallback/TODO/Hardcoding) im Register dokumentieren:  
 was bis wann zurückgebaut werden muss und was kaputtgeht, wenn es nicht zurückgebaut wird"

Die AI liest diese Regeln jedes Mal und meldet sich zuerst, bevor sie mit der Arbeit beginnt, wenn eine solche Situation eintritt.

Teil 3. Was nicht funktioniert hat

3.1 Derselbe Bug 7-mal wiederholt — die gesamte Datenkette wird nicht gesehen

Der Bug bei der Preiseinheit ist 7-mal aufgetreten, weil es nicht reicht, nur eine Stelle der 6 Stufen zu korrigieren: Erfassung → Parser → Normalisierung → DB → API → UI. Dann taucht er in einem anderen Pfad wieder auf. Die Fähigkeit, das Gesamtsystem zu sehen, fehlt in der Kombination Nicht-Entwickler + AI am meisten. Die AI behebt nur das, was man ihr sagt, und der Mensch weiß oft nicht, dass es noch andere Pfade gibt.

3.2 1.138 Fälle von Datenkorruption — die „freundlichen“ Defaults der AI

Als der Parser das Modelljahr nicht extrahieren konnte, wurde Code eingefügt, der getFullYear() zurückgibt. Aus Sicht der AI war wahrscheinlich „aktuelles Jahr ist besser als null“. Das Ergebnis: Ein Porter von Baujahr 2003 wurde als Baujahr 2026 in die DB geschrieben. Wenn man der AI nicht ausdrücklich sagt „Wenn du es nicht weißt, dann null“, füllt sie irgendetwas ein.

3.3 Slack-Benachrichtigungen 6 Monate ohne Funktion — das Überwachungssystem wurde nicht überwacht

Die Benachrichtigungen endeten einfach mit einem Fehler, und dieser Fehler selbst hinterließ keinen Log-Eintrag, deshalb blieb es 6 Monate lang still. In dieser Zeit gab es mehrere Pipeline-Anomalien, aber ich glaubte, es gäbe „kein Problem“. Der gefährlichste Zustand in einem mit AI gebauten System ist der Zustand, der so aussieht, als würde alles gut laufen. Inzwischen habe ich es auf einen einzigen Telegram-Pfad vereinfacht.

3.4 setInterval 32-Bit-Overflow — Sprachfalle

Wenn man nicht weiß, dass setInterval nur int32 akzeptiert, weiß man auch nicht, dass 30 Tage in Millisekunden zur sofortigen Ausführung führen. Login-Ausfall. Die AI warnt nicht von sich aus vor solchen Edge Cases. Erst nach dem Vorfall wurde eine Clamping-Regel eingeführt.

3.5 ML-Overfitting — Training MAPE 8,56 % vs. real 42 %

Mit LightGBM und 75 Features wurde im Training ein MAPE von 8,56 % erreicht, und ich dachte: „Geschafft.“ In der Realität: 42 %. Der Grund: strukturelle Grenzen der Angebotspreisdaten (keine realen Transaktionspreise, Down Contracts, Händlermargen). Ein Domain-Experte hätte das von Anfang an gewusst, aber ich war in der Vorstellung gefangen, dass „gute Trainingsergebnisse genügen“.

Verbleibende Gedanken

Wenn ich auf diese 238 Tage zurückblicke und sie zusammenfasse:

AI beschleunigt die Umsetzung erheblich. Auch jemand ohne Codekenntnisse kann einen funktionierenden Service bauen.
Betriebsqualität kommt aber nicht automatisch mit. Vorfälle passieren ausnahmslos, und die AI warnt nicht proaktiv.
Die Aufgabe eines Nicht-Entwicklers verlagert sich vom Schreiben von Code hin zum Entwurf von Regeln, Überwachung und Validierung. Ergebnisbeurteilung und Vermeidung von Wiederholungsfehlern werden zur eigentlichen Hauptaufgabe.

Es ist ein Produktivbetrieb, den ich allein betreibe, also Stichprobe n=1. Ich will das nicht verallgemeinern. Mich interessieren die Erfahrungen anderer unter ähnlichen Bedingungen.

Links

Service: https://chajooin.com (Vergleich und Analyse von Gebrauchtpreisen für Lkw)

Feedback ist willkommen. Besonders interessiert mich, wie ihr den Zustand „es sieht so aus, als würde alles gut laufen“ allein überwacht.

5 Kommentare

savvykang 2026-04-13

Ich denke, das Problem von Zuständen, die so wirken, als würden sie gut laufen, ließe sich bis zu einem gewissen Grad entschärfen, wenn man regelmäßig Übungen zur Störungsbehebung durchführt und definiert, welche Eigenschaften der Daten als normal gelten.

workdriver 2026-04-13

Ja, danke für die gute Anmerkung.
Es stimmt, dass die Verwaltung mit zunehmender Größe des Systems immer mühsamer wird.