[GN] नॉन-डेवलपर + Claude के साथ 238 दिन तक production चलाना — क्या काम किया और क्या नहीं?
(chajooin.com)मैं Chajooin.com बनाने वाला ऑपरेटर हूँ। हाई स्कूल ग्रेजुएट, 8 साल से मालवाहक ट्रक चला रहा हूँ (2017~)। कोड की एक लाइन भी लिखना नहीं जानता था, और 16 अगस्त 2025 को Claude के साथ अपना पहला commit किया। 238 दिन बीत चुके हैं, और अब यह सेवा हर दिन अपने-आप डेटा इकट्ठा करती है और रिपोर्ट प्रकाशित करती है。
यह लेख "बनाया" की कहानी नहीं, बल्कि "बनाकर चला रहा हूँ" का रिकॉर्ड है। vibe coding से prototype बनाने के अनुभव पर बहुत-सी पोस्ट हैं, लेकिन production operation को लगातार चलाने का अनुभव कम दिखता है, इसलिए लिख रहा हूँ। यह सफलता की कहानी नहीं, बल्कि क्या चला और क्या नहीं चला, उसका ईमानदार रिकॉर्ड है।
पृष्ठभूमि
- डोमेन: मालवाहक ट्रक market price comparison (17 ट्रिलियन won का बाज़ार, वास्तविक transaction price का कोई आधिकारिक रिकॉर्ड नहीं)
- पहला प्रयास: 2024 में turnkey outsourcing पर 30 million won → बदलावों का नियंत्रण outsourced टीम के पास था, इसलिए छोड़ दिया
- बदलाव: 2025 के जुलाई में 2 महीने AI सीखा → 16 अगस्त को पहला commit
स्टैक
Frontend Vite + React + TypeScript + Tailwind
Backend Node.js + Express + Prisma
DB PostgreSQL (Railway managed)
Collection Playwright (headless) + 46 source-specific parsers
ML LightGBM (Python, 75 features)
Deployment Railway (Docker)
Automation Node scheduler + Telegram alerts
AI collaboration Claude (main development) + GPT-4o (shorts scripts/prompts)
Auth Naver/Kakao OAuth
मैंने यह स्टैक "चुना" नहीं था। मैंने AI से पूछा, "इसे बनाना हो तो क्या इस्तेमाल करना चाहिए?" और उसने जो बताया, वही इस्तेमाल कर लिया। बाद में देखा तो यह काफ़ी तर्कसंगत संयोजन था। AI agent की व्यावहारिक वैल्यू यही है — वह selection का cognitive burden अपने ऊपर ले लेता है।
आँकड़े (2025-08-16 ~ 2026-04-12)
| मद | मान |
|---|---|
| कुल commits | 3,493 |
| commit वाले दिन | 189 दिन |
| code files की संख्या | लगभग 1,500 (js/ts/py के आधार पर) |
| rollback | 20+ बार |
| deployment failure | 39 बार (शुरुआती Railway setup के 2 दिन) |
| एक ही bug की अधिकतम पुनरावृत्ति | 7 बार (price unit) |
| सक्रिय listings | लगभग 48,000 |
| external source parsers | 46 |
| CLAUDE.md | 187 पंक्तियाँ, 24 पूर्ण नियम |
| memory files | 129 |
भाग 1. बनाना — जिन 3 चीज़ों ने इसे काम करने लायक बनाया
1.1 CLAUDE.md — नियमों से AI को नियंत्रित करना
अगर वही bug दो बार फट जाए, तो "ज़रा सावधान रहना" कहना बेकार है। ठोस नियम फ़ाइल में लिखो, और AI से हर session की शुरुआत में उसे पढ़वाओ।
"parser=raw → normalization=÷10,000 → DB=man-won. DB value पर ×10,000 मना है"
"parser में model year extraction fail हो तो getFullYear() डालना मना है"
"kakaotalk को vercel.json UA rewrite में जोड़ना मना है"
"setInterval value को Math.min(value, 2^31-1) से clamp करना अनिवार्य"
अभी 24 नियम हैं। ये सब किसी न किसी वास्तविक incident के बाद बने।
1.2 भूमिका अलग करना — planning/judgment इंसान, implementation AI
मैं code पढ़ नहीं सकता, लेकिन result का judgment कर सकता हूँ। अगर Porter 2-ton की कीमत 5 million won दिखे, तो मैं कह सकता हूँ "यह गलत है"। अगर wing body और cargo की कीमत एक जैसी आ रही हो, तो मैं कह सकता हूँ "इन्हें अलग करो"। domain sense यहाँ testing की भूमिका निभाता है।
1.3 memory files — session के बीच context बनाए रखना
129 memory files में decisions/failures/policies जमा किए। जब नया session खुलता है, तो उससे जुड़ी memory पढ़कर पिछला judgment बनाए रखा जाता है। यह AI context window की सीमा को file system से भरने वाली संरचना है।
भाग 2. ऑपरेशन — बनाना और चलाना, दोनों अलग समस्याएँ हैं
2.1 जो चीज़ें अभी अपने-आप चल रही हैं
- listing ingestion: scheduler external sources से data collect करता है → quality gate → DB में reflect
- market price reports: हर दिन auto-generate → blog/cafe पर auto-publish
- shorts script generation: tonnage के हिसाब से GPT-4o scripts/Sora prompts बनाता है (video synthesis अलग चरण है)
- ML retraining: हफ्ते में 1 बार नए data से market price engine को फिर से train करना
- monitoring: pipeline anomaly होने पर Telegram alert
डेवलपर मैं अकेला हूँ।
2.2 लागत
- infra: Railway (PostgreSQL + Node + Playwright)
- AI API: Claude subscription (development के लिए) + GPT-4o API (shorts generation के लिए,
api_usage_logके आधार पर लगभग $1 प्रति माह का अनुमान) - domain/OAuth: Naver/Kakao
2.3 incidents पर प्रतिक्रिया का रिकॉर्ड
- 1,138 data corruption cases (3/2): model year fallback bug मिला → DB patch + reprocessing pipeline + rule जोड़ा
- Slack alerts 6 महीने तक काम नहीं किए (3/18 को पता चला): environment variable/path समस्या → Telegram single path में दोबारा एकीकृत किया
- setInterval 32-bit overflow (4/10): login बंद → hotfix + clamping rule जोड़ा
- KakaoTalk blank screen (1/31): SEO UA rewrite ने KakaoTalk in-app browser को भी पकड़ लिया → UA list सुधारी
2.4 ऑपरेशन नियमों से कुछ अंश
CLAUDE.md में operation-oriented rules भी शामिल हैं।
"deployment के बाद 3 संख्याओं में रिपोर्ट करो: 服务器状态(health 200),
आज की crawl count (कल के ±20% के भीतर), active listings count (कोई अचानक बदलाव नहीं)"
"4 या उससे अधिक files में बदलाव हो, scheduler connection हो, DB schema change हो,
या पहले revert हुए क्षेत्र को फिर से बदला जा रहा हो → पहले से रिपोर्ट अनिवार्य"
"temporary changes (fallback/TODO/hardcoding) को रजिस्टर में दर्ज करो:
क्या, कब तक revert करना है, और revert न करने पर क्या टूटेगा"
AI हर बार ये नियम पढ़ता है, और ऐसी स्थिति आने पर काम शुरू करने से पहले रिपोर्ट करता है।
भाग 3. जो चीज़ें काम नहीं कर पाईं
3.1 एक ही bug 7 बार दोहराया गया — पूरे data path को नहीं देख पाना
price unit bug 7 बार इसलिए फटा, क्योंकि collection → parser → normalization → DB → API → UI की 6-stage pipeline में अगर सिर्फ एक जगह fix करो, तो दूसरी path से फिर वही bug आ जाता है। "पूरे सिस्टम को एक साथ देखने की क्षमता" non-developer + AI संयोजन की सबसे बड़ी कमी है। AI सिर्फ वहीं fix करता है जहाँ उसे कहा जाए, और इंसान को पता ही नहीं होता कि दूसरी paths भी हैं।
3.2 1,138 data corruption cases — AI के "दयालु" defaults
जब parser model year निकालने में fail हुआ, तो उसमें getFullYear() लौटाने वाला code डाल दिया गया। AI की नज़र में शायद "null से current year बेहतर है"। नतीजा: 2003 model का Porter, DB में 2026 model के रूप में दर्ज हो गया। अगर आप AI को अलग से नहीं लिखते कि "न पता हो तो null", तो वह कुछ-न-कुछ भर ही देता है।
3.3 Slack alerts 6 महीने तक बंद रहे — monitoring system की monitoring नहीं हुई
alert failure पर ख़त्म हो जाता था, और failure खुद log में नहीं रहता था, इसलिए 6 महीने तक सब शांत दिखा। इस दौरान pipeline में कुछ anomalies हुईं, लेकिन मैंने समझा कि "सब ठीक है"। AI से बने सिस्टम में सबसे ख़तरनाक स्थिति वह है जो 'ऐसा दिखे मानो सब ठीक चल रहा है'। अभी इसे Telegram single path में simplify कर दिया है।
3.4 setInterval 32-bit overflow — language trap
अगर आपको यह नहीं पता कि setInterval सिर्फ int32 लेता है, तो आपको यह भी नहीं पता होगा कि 30 दिन को milliseconds में डालने पर वह तुरंत चल पड़ेगा। login बंद हो गया। AI ऐसे edge cases के बारे में खुद से warning नहीं देता। bug फटने के बाद ही clamping rule जोड़ा गया।
3.5 ML overfitting — training MAPE 8.56% vs production 42%
LightGBM के 75 features से training MAPE 8.56% हासिल करके मैंने सोचा "हो गया"। production में 42%। वजह: asking-price data की structural limitations (वास्तविक transaction price की अनुपस्थिति, डाउन-कॉन्ट्रैक्ट, dealer margin)। कोई domain expert होता तो शायद शुरू से समझ जाता, लेकिन मैं "training result अच्छा है तो काफ़ी है" वाली सोच में फँस गया।
बाकी विचार
238 दिनों को पीछे मुड़कर देखें तो:
- AI implementation की speed को बहुत बढ़ा देता है। कोड न जानने वाला व्यक्ति भी चलने वाली service बना सकता है।
- लेकिन operation quality अपने-आप साथ नहीं आती। incidents बिना exception के होंगे, और AI खुद से warning नहीं देगा।
- non-developer का काम code लिखना नहीं, बल्कि rules, monitoring, और verification design करना बन जाता है। result का judgment और recurrence prevention ही मुख्य काम हो जाता है।
यह एक व्यक्ति द्वारा अकेले चलाया जा रहा production है, इसलिए sample n=1 है। मैं इसे generalize नहीं करूँगा। ऐसी ही conditions में और लोगों के अनुभव जानना चाहता हूँ।
लिंक
- सेवा: https://chajooin.com (मालवाहक ट्रक market price comparison·analysis)
फ़ीडबैक का स्वागत है। ख़ास तौर पर यह जानना चाहता हूँ कि आप अकेले 'ऐसी स्थिति जो देखने में ठीक लगे' की निगरानी कैसे करते हैं。
5 टिप्पणियां
जो स्थिति ऊपर से ठीक चलती हुई दिखती है, उससे जुड़ी समस्याओं को शायद समय-समय पर आपदा पुनर्प्राप्ति अभ्यास करके और यह परिभाषित करके कि डेटा की कौन-सी विशेषताएँ सामान्य हैं, कुछ हद तक कम किया जा सकता है।
हाँ, अच्छे सुझाव के लिए धन्यवाद.
यह सच है कि सिस्टम बड़ा होने पर उसे मैनेज करना मुश्किल हो जाता है.
अगर आप इसे अकेले ऑपरेट कर रहे हैं, तो मॉनिटरिंग सर्विस भी आपको खुद मैनेज करनी होगी, इसलिए मौजूदा स्थिति में यह आसान नहीं लगेगा। किसी बाहरी मॉनिटरिंग सर्विस का इस्तेमाल करना भी एक तरीका है।
वास्तविक फील्ड डेटा के लिए धन्यवाद।
हाँ, धन्यवाद