bkit — Context Engineering के साथ Claude Code को “ठीक से” इस्तेमाल करना
दिसंबर 2025 में, मैंने bkamp.ai नाम की एक सेवा लॉन्च की।
- 11 माइक्रोसर्विसेज
- Next.js आधारित पोर्टल
- AWS EKS + GitOps (ArgoCD)
- Terraform इन्फ्रास्ट्रक्चर
और यह सब मैंने सिर्फ 9 दिनों में प्रोडक्शन में डाल दिया।
डेवलपर सिर्फ मैं था,
AI के लिए मैंने Claude Code का इस्तेमाल किया।
यह लेख “तेज़ी से बनाया” वाली कहानी नहीं है
AI डेवलपमेंट के कई उदाहरण इस तरह समझाए जाते हैं:
- “AI से N दिनों में बना दिया”
- “बस prompt अच्छे से लिखने होते हैं”
लेकिन असल में 9 दिनों तक डेवलपमेंट करते हुए मुझे जो महसूस हुआ, वह बिल्कुल अलग था।
AI कोड अच्छी तरह लिखता है।
लेकिन क्या लिखना है, यह AI तय नहीं करता।
आखिरकार यह तय करते हैं:
- डिज़ाइन
- नियम
- काम की इकाइयाँ
- वेरिफिकेशन का तरीका
इसे मैंने Context Engineering के रूप में परिभाषित किया।
Context Engineering क्या है
सरल शब्दों में कहें तो:
यह prompt अच्छे से लिखने की बात नहीं है,
बल्कि AI के काम करने वाले पूरे वातावरण को डिज़ाइन करने की बात है
उदाहरण के लिए:
- पहले डिज़ाइन दस्तावेज़ बनाए जाते हैं
- काम की इकाइयाँ दस्तावेज़ के आधार पर बाँटी जाती हैं
- परिणाम को verify करने के नियम बनाए जाते हैं
- दोहराई जा सकने वाली cycle बनाई जाती है
यानी,
AI “लेखक” नहीं रहता,
बल्कि तय किए गए context को render करने वाला engine बन जाता है
bkamp में वास्तव में अपनाया गया तरीका
1. Day 0 — कोड लिखने से पहले नियम बनाना
पहले commit में कोई कोड नहीं था।
उसकी जगह मैंने यह बनाया:
.claude/CLAUDE.md(लगभग 150 लाइनें)- requirements document
- strategy document
इनमें यह परिभाषित था:
- PDCA cycle (Plan → Do → Check → Act)
- हर परिणाम का human verification
- planning हिन्दी में नहीं, बल्कि कोरियाई में; code अंग्रेज़ी में; commit कोरियाई में
- काम की इकाइयाँ और प्रगति का तरीका
लगभग 100 लाइनों के इन नियमों ने बाद के पूरे डेवलपमेंट को तय किया।
2. काम की इकाई “feature” नहीं, “document”
आम तौर पर अनुरोध इस तरह किया जाता है:
- “chat feature बना दो”
लेकिन मैंने वास्तव में इस तरह काम किया:
- “document 7 की section 3.2 implement करो”
यह फर्क बहुत बड़ा है।
AI के नज़रिए से:
- feature → interpretation की ज़रूरत (uncertainty)
- document → जैसा है वैसा implement (deterministic)
नतीजतन:
output की variability लगभग खत्म हो जाती है
3. एक दिन = एक PDCA cycle
डेवलपमेंट इस तरह चलता है:
- Plan (डिज़ाइन)
- Do (implementation)
- Check (gap analysis)
- Act (सुधार)
और इस cycle को हर दिन दोहराया जाता है।
इस तरीके के फायदे:
- context हमेशा latest बना रहता है
- काम की सीमा स्पष्ट रहती है
- AI के लिए “अभी क्या करना है” साफ रहता है
4. checkpoint बनाओ और ज़रूरत पड़े तो निडर होकर सब बदल दो
चौथे दिन मैंने frontend को पूरी तरह फिर से बनाया।
लेकिन उससे पहले एक काम ज़रूर किया जाता है:
- rollback किया जा सकने वाला checkpoint बनाना
इससे:
असफलता होने पर भी सुरक्षा रहती है
→ इसलिए बड़े architectural बदलाव संभव हो जाते हैं
5. इन्फ्रास्ट्रक्चर को अंत में एक साथ जोड़ा जाता है
आठवें दिन, पूरे एक दिन में:
- Terraform
- Kubernetes
- CI/CD
- ArgoCD
को एक साथ जोड़ा गया।
यह संभव होने की वजह सरल थी:
क्योंकि उससे पहले सारी संरचना पहले से aligned थी
यहाँ से निकला मुख्य पैटर्न
इन 9 दिनों में जो पैटर्न बार-बार दोहराया गया, वह यह था:
- पहले नियम परिभाषित करो
- पहले डिज़ाइन बनाओ
- दस्तावेज़ के आधार पर काम करो
- PDCA cycle से दोहराओ
- checkpoint बनाओ
- असंगति को document में हल करो
- कोड सबसे अंत में आता है
लेकिन क्या इसे लगातार बनाए रखा जा सकता है?
यहीं पर समस्या आती है।
यह तरीका शक्तिशाली है, लेकिन:
इंसान के लिए इसे लगातार बनाए रखना बहुत कठिन है
- नियम लगातार याद रखने पड़ते हैं
- दस्तावेज़ लगातार sync में रखने पड़ते हैं
- हर बार PDCA का पालन करना पड़ता है
इसीलिए मैंने bkit बनाया।
bkit क्या है
bkit, Claude Code का एक प्लगइन है।
लेकिन यह सिर्फ एक साधारण tool नहीं है।
bkamp में इस्तेमाल किए गए काम करने के तरीके को
जैसा का तैसा एक system में बदला गया है
सबसे महत्वपूर्ण विचार: PDCA = state machine
bkit में PDCA को इस तरह implement किया गया है:
- state: plan, design, do, check, act आदि
- transition: states के बीच move करने के नियम
- guard: condition checks
उदाहरण के लिए:
- डिज़ाइन और implementation की matching rate 90% से अधिक → pass
- नहीं तो → अपने-आप correction loop चलती है
यानी,
“review → correction” अपने-आप दोहराया जाता है
Context Engineering को system में बदलने वाली संरचना
bkit इन घटकों से बना है:
- Skills (domain knowledge)
- Agents (role-based behavior)
- PDCA state machine
- Context injection system
- Quality Gate (validation)
- Audit Log (record)
- Feedback Loop (automatic repetition)
इसे एक वाक्य में कहें तो:
बात AI का उपयोग करने की नहीं है,
बल्कि AI के काम करने वाली system बनाने की है
परिणाम
इस तरीके से मिले नतीजे इस प्रकार हैं:
- Claude Code के 79 versions के साथ लगातार compatibility
- 4,000+ tests, विफलता 0
- 200+ CI validation rules
- Docs और Code पूरी तरह synchronized
निष्कर्ष
यह कहानी AI के और अधिक स्मार्ट हो जाने की नहीं है।
यह कहानी इंसानी काम को पहले चरण में आगे ले आने की है
- पहले डिज़ाइन
- पहले नियम
- पहले validation
उसके बाद:
- AI execute करता है
- system verify करती है
- इंसान approve करता है
TL;DR
- सिर्फ prompt से काम की सीमा है
- Context Engineering ही मुख्य बात है
- AI लेखक नहीं, renderer है
- workflow, model से ज़्यादा महत्वपूर्ण है
लिंक
अगर इस तरीके पर आपके विचार या feedback हों, तो उनका दिल से स्वागत है।
अभी कोई टिप्पणी नहीं है.