अब आई बारी फेज़ 3 "बनाना" की। अध्याय 2 में तय किए स्पेक और अध्याय 3 में चुनी टेक्नोलॉजी-टूल को हाथ में लेकर, हम असल में चलती हुई चीज़ जोड़ेंगे। यहाँ लड़खड़ाने वाले ज़्यादातर लोग, असल में इसलिए नहीं अटकते कि "कोड नहीं लिख पाते"। वे इसलिए हार मानते हैं कि एक झटके में पूरा कर डालने की कोशिश करते हैं। इस अध्याय में, AI को साथी बनाकर "छोटा बनाओ और चलाओ" को तेज़ी से घुमाने का तरीका, बिगिनर और प्रैक्टिकल — दोनों रूट में बताएँगे।

इस अध्याय में सीखने वाला "बनाने का तरीका"

लक्ष्य है "एक झटके में पूरा" नहीं, बल्कि "छोटा-छोटा आगे"

घुमाने वाला तरीका
"बनाओ → चलाओ → सुधारो" को छोटा और तेज़ दोहराने की आदत बनेगी।
रूट के हिसाब से इंप्लीमेंट
🌱बातचीत से सुधारने वाला बिगिनर रूट और 🔧स्पेक सौंपने वाला प्रैक्टिकल रूट — दोनों के तरीके।
AI जोड़ना
ऐप में AI डालने के विकल्प (API, कई मॉडल, RAG) चुन पाना।

इंप्लीमेंटेशन का मूल रवैया — छोटा घुमाएँ

इंप्लीमेंटेशन में सबसे अहम रवैया, बस एक है। "छोटा बनाओ, चलाओ, और सुधारो" को तेज़ी से दोहराना। दिमाग में मौजूद पूरे रूप को एक ही झटके में बनाने की कोशिश न करें, पहले सबसे छोटा "चलता हुआ टुकड़ा" बनाएँ, और उसे थोड़ा-थोड़ा बढ़ाते जाएँ।

यह असरदार क्यों है? क्योंकि प्रोग्राम चलाने पर ही पता चलता है कि क्या गलत है। 100 लाइन लिखकर एक बार में चलाएँ, तो कहाँ गड़बड़ है यह न समझकर सिर पकड़ लेते हैं। 10 लाइन लिखकर चलाएँ, तो गलती उन्हीं 10 लाइनों में कहीं होगी। AI से लिखवाने पर भी बिलकुल यही है — छोटा माँगो, और तुरंत जाँचो — यह तरीका आखिरकार कहीं ज़्यादा तेज़ और पक्का निकलता है।

😓 अक्सर होने वाली नाकामी

"सारे फ़ीचर एक झटके में बना दो" — AI को सब कुछ फेंक देना। ढेर सारा कोड निकलता है, पर चलाओ तो एरर ही एरर। कहाँ वजह है समझ न आना, सुधारने का हौसला भी खत्म।

🚀 सफल होने वाला तरीका

"पहले बस लिस्ट दिखाने वाली स्क्रीन" — एक-एक फ़ीचर माँगें। चले तो अगला, यह जोड़ते जाएँ। हमेशा "चलती हुई हालत" बनाए रखकर आगे बढ़ पाते हैं।

⚠️ AI का कोड भी गलत होता है — इसलिए हमेशा खुद चलाएँ। AI ने लिखा कोड, देखने में सही-सा लगे तब भी चलाओ तो एरर हो, या इरादे से अलग चले — ऐसा अकसर होता है। "AI ने लिखा है तो सही ही होगा" — यह वर्जित है। जो कोड निकले, उसे हमेशा अपने हाथ से चलाकर, आँखों से जाँचें। पर्सनल डेवलपमेंट में सबसे पहले यही सुनहरा नियम अपनाएँ। बिना चलाए आगे बढ़ें, तो गलतियाँ जमती जाती हैं और हाथ से बाहर हो जाती हैं।

"बनाओ, चलाओ, सुधारो" लूप के कदम

इस "छोटा घुमाना" को ठोस 4 कदमों में उतारने पर नीचे का चित्र बनता है। एक फ़ीचर भर को, इसी लूप में घुमाते जाएँ। एक चक्कर कुछ मिनट से लेकर कुछ दसियों मिनट का। जितना तेज़ घुमाएँ, उतना निखार आता है।

STEP 1
छोटा माँगें

"अब बस यह एक फ़ीचर" — AI को ठोस रूप से कहें। दायरा जितना सिमटा, सटीकता उतनी ज़्यादा।

STEP 2
तुरंत चलाएँ

निकलते ही फ़ौरन रन करें। ब्राउज़र या टर्मिनल में अपनी आँखों से नतीजा जाँचें।

STEP 3
सुधारें, सँवारें

एरर या खटक हो तो "यहाँ ऐसे सुधारो" कहकर बातचीत में ठीक करें। चलने तक दोहराएँ।

STEP 4
सेव करके अगला

चले तो एक पड़ाव की तरह सेव (कमिट) करें। अच्छी हालत सहेजें, और अगले फ़ीचर पर।

💡 STEP 4 "सेव" को हल्के में न लें। हर फ़ीचर चलते ही सेव (Git का कमिट) कर लें, तो अगले बदलाव में कुछ टूटे भी, तो पिछली चलती हुई हालत पर लौट सकते हैं। "कल तो चल रहा था" वाले हादसे से बचाने वाली जान-रस्सी है यह। सेव करने का ठोस तरीका अगले अध्याय 5 में विस्तार से।

बिगिनर रूट और प्रैक्टिकल रूट की इंप्लीमेंट शैली

"छोटा घुमाना" साझा रवैया है, पर घुमाने का ठोस तरीका रूट के हिसाब से बदलता है। अध्याय 1 में चुने अपने रूट के मुताबिक, बढ़ने का तरीका देख लें। बेशक, बीच में मिलाना या रास्ता बदलना भी चलेगा।

🌱 बिगिनर रूट — बातचीत से रूप देना
कोड पढ़ने की ज़रूरत नहीं

वाइब कोडिंग से, AI के साथ बातचीत करते हुए ऐप जोड़ें। "लिस्ट स्क्रीन बनाओ" → "बटन का रंग नीला करो" → "दबाने पर सेव हो जाए" — अपनी भाषा में माँगें, स्क्रीन देखें, फिर माँगें। यही दोहराव सीधे "छोटा घुमाने वाला लूप" बन जाता है।

कुंजी: एक बार में बस एक चीज़ माँगें। ठीक न बने तो "अभी वाला बदलाव वापस लो" कह देना काफ़ी।

🔧 प्रैक्टिकल रूट — स्पेक सौंपकर काम छोड़ना
AI एडिटर से ऑटोमेट करें

Claude Code जैसों को पूरा स्पेक सौंपकर, इकट्ठा इंप्लीमेंट का काम छोड़ें। काम की मात्रा के हिसाब से एफ़र्ट (effort) एडजस्ट करें, और फ़ाइलें ज़रूरत से ज़्यादा न बदल जाएँ इसके लिए परमिशन मोड बदल-बदलकर सुरक्षित ऑटोमेशन करना ही पॉइंट है।

कुंजी: बड़ा काम छोड़ें, पर जाँच छोटी रखें। अटकें तो एरर संग्रह में उपाय ढूँढें।

दोनों में से किसी भी रूट में, जो नहीं भूलना है वह है "जो निकले उसे खुद चलाकर जाँचना" वाला मूल रवैया। बातचीत से बनाएँ या ऑटोमेट करवाएँ, जाँचना इंसान का काम है। यह एक मेहनत न छोड़ना ही, पूरा होने और न होने के बीच का फ़ैसला बनता है।

AI फ़ीचर जोड़ना हो तो

जो बना रहे हैं वह "AI इस्तेमाल करने वाला ऐप" हो — मसलन टेक्स्ट का सार बनाना, सवाल का जवाब देना, इमेज परखना — तो ऐप के भीतर से AI को बुलाने वाला ढाँचा चाहिए। यहाँ थोड़ा तकनीकी हो जाता है, पर विकल्प मोटे तौर पर 3 में समेटे जा सकते हैं। अपने ऐप को जो चाहिए, बस वही चुनें, काफ़ी है।

① AI को बुलाना
पहले तो यही

एक AI मॉडल को ऐप से इस्तेमाल भर करना हो, तो AI API बुलाना बुनियादी है। "टेक्स्ट भेजो, तो AI का जवाब लौटता है" वाली खिड़की समझ लें, चलेगा।

② कई मॉडल संभालना
बदलना, तुलना करनी हो तो

कई AI को हालात के हिसाब से बदल-बदलकर इस्तेमाल करना हो, तो Vercel AI SDK से एक जैसा तरीका अपनाएँ। ऑपरेशन में एक जगह से संभालना हो तो LLM गेटवे सुविधाजनक है।

③ अपने डेटा से जवाब
अपना खास ज्ञान देना हो तो

अपने दस्तावेज़ या सामग्री के आधार पर जवाब दिलवाना हो, तो RAG। AI को "आपके लिए खास सामग्री" देकर जवाब दिलवाने का ढाँचा, जिससे अपनी अलग पहचान बनती है।

🧭 दुविधा हो तो बस ① काफ़ी है। पहले MVP में, ज़्यादातर बस एक AI API बुलाना ही काफ़ी होता है। ②③ को "कई मॉडल की तुलना करनी है", "अपने डेटा से जवाब दिलवाना है" ऐसी ज़रूरत पड़ने पर जोड़ें, चलेगा। यहाँ भी "छोटा बनाना" ही सही जवाब है।

अटकने पर कैसे बढ़ें

इंप्लीमेंट के दौरान, कहीं न कहीं ज़रूर अटकेंगे। एरर आना, सोचे जैसा न चलना — यह नाकामी नहीं, बनाने का सबूत है। अहम है, अटकने पर घबराए बिना, क्रम से छाँटना। AI के होते हुए, अटकन पहले से कहीं जल्दी सुलझ जाती है।

1. एरर टेक्स्ट वैसे ही AI को दें

लाल अक्षर पूरे कॉपी करके "यह एरर आया। वजह और सुधार क्या है?" पूछें। एरर टेक्स्ट ही सबसे बड़ा सुराग। अपने तरीके से बदले बिना, पहले पेस्ट करें।

2. छोटा करके छाँटें

"कहाँ तक चल रहा था" याद करें। ठीक पहले बदली एक जगह ही वजह होती है, ज़्यादातर। दायरा सँकरा करें तो वजह ज़रूर मिलेगी।

3. चलती हुई हालत तक लौटें

उलझ जाए, तो सेव की हुई ठीक पहले वाली चलती हालत पर लौटकर फिर से करें। गहराई में उतरने से, एक बार लौटना अकसर तेज़ पड़ता है।

🔧 प्रैक्टिकल रूट वालों के लिए। Claude Code आदि में अक्सर आने वाले एरर और उपाय एरर संग्रह में समेटे हैं। एक ही एरर में जूझते रहना समय की बर्बादी है। अटकें तो पहले ढूँढें, फिर भी न बने तो AI से पूछें — इसे आदत बनाएँ।

इस अध्याय का सार

फेज़ 3 "बनाना" का दिल, तकनीक से ज़्यादा "छोटा बनाओ, चलाओ, सुधारो" को तेज़ी से घुमाने वाले रवैये में है। एक झटके में पूरा करने की कोशिश न करें, चलते हुए टुकड़े को थोड़ा-थोड़ा बढ़ाते जाएँ।

इस अध्याय का सार
  • मूल रवैया है "छोटा बनाओ और चलाओ → सुधारो" को तेज़ी से घुमाना। एक झटके में पूरा करने की कोशिश न करें।
  • AI का कोड भी गलत होता है। जो निकले उसे हमेशा खुद चलाकर जाँचें।
  • 🌱बिगिनर वाइब कोडिंग से बातचीत करते हुए, 🔧प्रैक्टिकल स्पेक सौंपकर एफ़र्ट और परमिशन मोड से सुरक्षित ऑटोमेट।
  • AI डालना हो तो API से। कई मॉडल के लिए Vercel AI SDK／LLM गेटवे, अपने डेटा के लिए RAG।
  • अटकें तो एरर टेक्स्ट दें → छोटा करके छाँटें → चलती हालत पर लौटें। एरर संग्रह भी काम आएगा।

चलती हुई चीज़ बन जाए, तो अगली बारी है उसे सुरक्षित तरीके से दुनिया के सामने लाने की। पिछले अध्याय 3 "टेक्नोलॉजी और टूल चुनना" पर लौटकर तैयारी दोबारा देख सकते हैं, पर इंप्लीमेंट घूमने लगे तो, टेस्टिंग और सिक्योरिटी पक्की करके पब्लिश करने वाले अध्याय 5 "टेस्ट करके दुनिया के सामने लाना" की ओर बढ़ें।