AI डेवलपमेंट और प्रोग्रामिंग

RAG, semantic search और सिफ़ारिशें सभी एक अनसुने मेहनती कारीगर पर निर्भर हैं: embedding (vector)। embedding टेक्स्ट (या छवि) के अर्थ को संख्याओं की एक श्रृंखला — एक vector — में बदलना है। "कुत्ता" शब्द सैकड़ों से हज़ारों संख्याओं की सूची बन जाता है जो "अर्थ के निर्देशांक" की तरह काम करती है, इसलिए अर्थ में नज़दीक शब्द पास-पास बैठते हैं ("कुत्ता" और "पिल्ला" नज़दीक; "कुत्ता" और "कार" दूर), और नज़दीकी को cosine similarity जैसे मापों से आँका जाता है। प्रसिद्ध उदाहरण: "राजा − पुरुष + स्त्री ≈ रानी"। इसी कारण, अक्षर मेल न खाने पर भी मशीन यह आँक सकती है कि अर्थ नज़दीक है या नहीं। यह शुरुआती गाइड बताती है कि embedding क्या है (एक "अर्थ का नक्शा"), नज़दीकी से अर्थ क्यों मापा जाता है (dimensions और cosine similarity), इसका उपयोग कहाँ होता है (RAG, semantic search, वर्गीकरण और दोहराव-हटाना, सिफ़ारिशें और multimodal), embedding model कैसे चुनें (API प्रकार जैसे OpenAI text-embedding-3, Cohere, Gemini, Voyage; open-source जैसे BGE-M3, Nomic, Qwen3; साथ ही Matryoshka, जो 3,072 dimensions को 1,024 तक घटाकर लगभग एक-तिहाई लागत पर लगभग 95% गुणवत्ता बनाए रखता है), और vector DB (Pinecone, Weaviate, Qdrant, Chroma, pgvector) के साथ तीन-चरण शुरुआत (model चुनें, दस्तावेज़ vector में बदलकर संग्रहित करें, सवाल को vector में बदलकर search करें)। embedding, RAG लागू करने की नींव हैं।

आपने prompts निखारे, RAG से ज्ञान जोड़ा, शायद fine-tuning भी की — तो कैसे पक्का करें कि यह सचमुच बेहतर हुआ? यहीं AI evals मुख्य भूमिका में आते हैं, और 2026 तक मूल्यांकन इतना ज़रूरी है कि इसे "infrastructure" कहा जाता है। AI evals का मतलब है किसी LLM के आउटपुट की गुणवत्ता (सटीकता, hallucinations, फ़ॉर्मैट पालन, लहजा) को अंदाज़े के बजाय एक तय पैमाने पर व्यवस्थित रूप से मापना; इनके बिना सुधार महज़ एक अंदाज़ा है। दो तरीके हैं: यांत्रिक रूप से मापने योग्य बातों के लिए code-based मूल्यांकन (सटीक मिलान, फ़ॉर्मैट, ज़रूरी/प्रतिबंधित शब्द — तेज़, सस्ता, स्थिर) और व्यक्तिपरक बातों के लिए LLM-as-judge (किसी शक्तिशाली LLM को रेफ़री बनाकर pairwise तुलना या एकल-आउटपुट स्कोरिंग से आँकना)। सिद्धांत: जो कोड माप सकता है उसे कोड से ही मापें। LLM-as-judge में verbosity, position और self-preference biases होती हैं; उपाय हैं अलग परिवार के मॉडल को मूल्यांकनकर्ता बनाना, क्रम बदलकर दो बार आँकना, rubric में संक्षिप्तता डालना, और मानवीय निर्णय के विरुद्ध calibrate करना। मोटे पैमाने (pass/fail या 1–3) बारीक 1–10 से बेहतर हैं। व्यवहार में तीन स्तर चलाएँ — हर बदलाव पर तुरंत code जाँच, रात्रिकालीन LLM-judge regression टेस्ट, और लगातार प्रोडक्शन निगरानी — CI के लिए DeepEval, Promptfoo, RAGAS तथा निगरानी के लिए Braintrust, LangSmith, Arize जैसे उपकरणों के साथ। शुरुआत 10 अच्छे और 10 बुरे आउटपुट इकट्ठा करके और उन्हें स्कोर करके करें।

जब आप AI को अपनी कंपनी के लिए कस्टमाइज़ करना चाहते हैं, तब फाइन-ट्यूनिंग एक विकल्प होता है — पर बिना सोचे-समझे इसमें कूदना महँगा है और गलत होना आसान। यह शुरुआती गाइड फाइन-ट्यूनिंग को समझाता है: पहले से प्रशिक्षित एक बेस मॉडल को लेना, उसे अपने उपयोग के अनुरूप डेटा पर और आगे प्रशिक्षित करना, और उसके वेट फिर से लिखकर "व्यवहार" (कंपनी की शैली, आउटपुट फ़ॉर्मैट, क्षेत्र की शब्दावली) को मॉडल के भीतर ही बैठाकर एक विशेषीकृत मॉडल में ढालना। फाइन-ट्यूनिंग व्यवहार बदलने में अच्छी है पर ताज़ा जानकारी याद रखने में कमज़ोर, इसलिए नियम है "तथ्य और ज्ञान → RAG, व्यक्तित्व और साँचा → फाइन-ट्यूनिंग, पहले प्रॉम्प्ट।" जैसा विशेषज्ञ कहते हैं, "हमें फाइन-ट्यूनिंग चाहिए" के लगभग 80% मामले बेहतर रिट्रीवल (RAG) या प्रॉम्प्टिंग से हल हो जाते हैं, इसलिए क्रम मायने रखता है। लेख समझाता है कि फाइन-ट्यूनिंग क्या है (नए कर्मचारी के प्रशिक्षण का उदाहरण), यह किसमें अच्छी और किसमें कमज़ोर है, फाइन-ट्यूनिंग बनाम RAG बनाम प्रॉम्प्टिंग की तुलना तालिका, मुख्य तरीके (full फाइन-ट्यूनिंग, LoRA, और QLoRA — 4-bit क्वांटाइज़ेशन जो शुरुआती के लिए काफ़ी हल्का है), क्या ज़रूरी है (कसौटी के तौर पर 500+ उच्च-गुणवत्ता वाले उदाहरण, जहाँ डेटा तैयार करना ही असली काम है; लागत $5,000 से $50,000 से अधिक तक, OpenAI की फाइन-ट्यूनिंग लगभग $25–$100 प्रति मिलियन ट्रेनिंग टोकन; OpenAI, Unsloth, Axolotl और Hugging Face जैसे टूल), और शुरू करने का क्रम। फाइन-ट्यूनिंग आखिरी उपाय है।

जिस युग में कोड AI लिखता है, वहाँ ज़्यादा मूल्यवान कौशल "कोड लिखने" से बदलकर "spec लिखने" की ओर जा रहा है — और इस बदलाव को दर्शाने वाला तरीका है Spec-Driven Development (SDD)। SDD में spec परियोजना के केंद्र में सत्य के स्रोत के रूप में रहता है, और एक AI agent तुरंत कोड लिखने के बजाय उसी से डिज़ाइन, विभाजन और इम्प्लीमेंटेशन निकालता है। अहम बात यह है कि हर चरण एक दस्तावेज़ (अक्सर Markdown) छोड़ता है जिसे अगला चरण पढ़ता है। यह शुरुआती-अनुकूल गाइड बताती है कि SDD क्या है (spec ही प्रामाणिक है; कोड एक व्युत्पन्न है), अभी यह क्यों मायने रखता है (यह vibe coding की तकनीकी ऋण और आवश्यकताओं के खिसकने वाली "तीन महीने की दीवार" को डिज़ाइन चरण में ही रोकता है — GitHub के अनुसार "शून्य से दोबारा बनाने" वाले चक्र लगभग दस गुना घटे), बुनियादी चार चरण (Specify → Plan → Tasks → Implement), प्रमुख टूल (90,000+ स्टार और 30 से ज़्यादा समर्थित agent वाला GitHub Spec Kit, Requirements → Design → Tasks प्रवाह और Auto router वाला AWS Kiro, साथ ही BMAD, OpenSpec, Tessl, Google Antigravity और Cursor), इसका उपयोग कब बनाम vibe coding (एक हाइब्रिड: खोजबीन के लिए vibe, डिलीवरी के लिए spec-driven, अनिवार्य इंसानी समीक्षा के साथ), और आज से इसे कैसे आज़माएँ। AI के युग में वे लोग आगे बढ़ते हैं जो ठीक-ठीक परिभाषित कर सकते हैं कि क्या बनाना है, न कि वे जो सबसे तेज़ कोड लिखते हैं।

AI के साथ काम करने में ध्यान का केंद्र prompt engineering से context engineering की ओर खिसक रहा है। Anthropic की परिभाषा उधार लें तो, context engineering है "उन रणनीतियों का समूह जिनसे आप inference के दौरान मॉडल को सौंपे जाने वाले tokens (जानकारी) के सबसे उपयुक्त समूह को चुनते और बनाए रखते हैं" — जो केवल prompt को नहीं, बल्कि context window की हर चीज़ को कवर करता है: system prompt, tools, बातचीत की history, और बाहरी डेटा। यह "context rot" के कारण मायने रखता है: आप जितने ज़्यादा tokens जोड़ते हैं, सटीकता असल में उतनी ही घटती है। Chroma के 2025 अध्ययन ने 18 अग्रणी मॉडलों (GPT, Claude, Gemini और अन्य) का परीक्षण किया और हर एक input के लंबा होते जाने के साथ कमज़ोर पड़ा, जहाँ लंबे context के बीच में रखी जानकारी को नज़रअंदाज़ करना खासकर आसान था ("lost in the middle")। यह शुरुआती-अनुकूल गाइड बताती है कि context engineering क्या है और prompt engineering से इसका क्या संबंध है, context rot क्यों होता है (attention एक सीमित बजट है), context में असल में क्या होता है, छह मुख्य तकनीकें (सही ऊँचाई पर निर्देश, tool चयन, just-in-time retrieval, compaction/सारांश संपीडन, बाहरी memory notes, और sub-agent अलगाव), RAG व Claude Skills से इसका संबंध, और आज से अपनाई जा सकने वाली आदतें जैसे विषय बदलने पर नया session शुरू करना और केवल मुख्य बिंदु पेस्ट करना। मूल विचार: केवल सबसे छोटे, सबसे उपयोगी tokens रखें।

9 जून 2026 को Anthropic के पहले सार्वजनिक "Mythos-class" model के रूप में जारी Claude Fable 5 की यहां सिर्फ़ coding के लिए पड़ताल की गई है (पूरी रिलीज़ अलग से कवर है)। संक्षेप में: coding जितनी कठिन, Fable 5 उतना आगे निकलता है। यह SWE-bench Verified पर 95.0% और कठिन SWE-bench Pro पर 80.3% देता है (Opus 4.8 69.2% और GPT-5.5 58.6% के मुकाबले), तथा कठिनतम FrontierCode Diamond पर 29.3% (Opus 13.4% और GPT-5.5 5.7% के मुकाबले, GPT से ~5 गुना), जबकि Terminal-Bench 2.1 पर 84.3% की कांटे की टक्कर है। लेख में तीन-बिंदु डेवलपर सारांश, side-by-side benchmark टेबल और उसे पढ़ने का तरीका, effort-scaling गुण (low 11.5% से max 30.9%, जबकि GPT-5.5 5-6% पर ठहर जाता है), यह असल में किसमें अच्छा है (बड़े multi-file refactor, लंबे autonomous agent run, screenshot से front-end, API डिज़ाइन + tests + docs; Simon Willison ने output को "कई दिनों जितना" आंका पर 5.5 घंटे में $110 से अधिक के साथ इसे धीमा और महंगा कहा), कमज़ोरियां ($10/$50, 500k-1M token session, कब रुकना है गलत आंकता है, review सटीकता में पीछे, Terminal-Bench के लगभग 20% trials में Opus 4.8 पर fallback), routing मार्गदर्शन (डिफ़ॉल्ट Opus 4.8, कठिन 10-20% Fable 5 को, terminal काम GPT-5.5 को), और कहां इस्तेमाल करें (Claude Code, GitHub Copilot, AWS Bedrock, Azure Foundry, Databricks, Anthropic API) कीमत, 1M-token context, 128k max output और June 9-22 मुफ़्त अवधि के साथ शामिल हैं। भारी एकमुश्त काम के लिए Fable 5, रोज़मर्रा के अधिकांश के लिए Opus 4.8। आंकड़े दिशासूचक और scaffold-निर्भर हैं।

"बिल्ड पूरा होने पर बता देना।" "अगर CI लाल हो जाए, तो ठीक कर देना।" "हर 5 मिनट पर डिप्लॉय पर नज़र रखना।" इन चिपके रहने वाले कामों को पूरी तरह AI को सौंपना — यही 2026 में Claude Code में जोड़ी गई /loop कमांड संभव बनाती है। यह शुरुआती गाइड बताती है कि /loop एक सेशन-स्कोप्ड शेड्यूलर है जो एक प्रॉम्प्ट या स्लैश कमांड को आपके तय किए (या AI के तय किए) अंतराल पर बार-बार चलाता है, फिर इसके इस्तेमाल के चार तरीके (① /loop 5m X = निश्चित cron अंतराल ② /loop X = सेल्फ-पेसिंग जहाँ AI अंतराल तय करता है ③ /loop 15m = बिल्ट-इन मेंटेनेंस प्रॉम्प्ट ④ /loop = ऑटो-मेंटेनेंस), अंतराल कैसे लिखें (संख्या + इकाई s/m/h/d, न्यूनतम 1 मिनट, "every 2 hours" जैसी प्राकृतिक भाषा, और आप स्लैश कमांड भी लूप कर सकते हैं: /loop 20m /review-pr 1234), सेल्फ-पेसिंग की ताकत (सक्रिय होने पर कम, शांत होने पर ज़्यादा इंतज़ार, 1 मिनट से 1 घंटे के बीच, और — सादे cron के उलट — काम पूरा मानते ही loop अपने-आप खत्म), व्यावहारिक रेसिपी (CI/डिप्लॉय देखना, PR की देखभाल, लंबे बिल्ड जाँचना, रिमाइंडर, ब्रांच ऑटो-मेंटेनेंस), इसे कैसे रोकें और सावधानियाँ (Esc से रोकें, सेशन-स्कोप्ड इसलिए नई बातचीत इसे साफ़ कर देती है, टर्मिनल बंद करने पर रुकता है, निश्चित अंतराल 7 दिन तक चलते हैं, प्रति सेशन अधिकतम 50 टास्क, टर्न के बीच jitter के साथ चलता है, स्थानीय टाइमज़ोन), तीन शेड्यूलिंग सुविधाओं में से कैसे चुनें (सेशन-भीतर निगरानी के लिए /loop, रेज़िडेंट लोकल काम के लिए Desktop scheduled tasks, बिना देखरेख क्लाउड ऑपरेशन के लिए Routines), और loop.md कस्टमाइज़ेशन साथ ही CLAUDE_CODE_DISABLE_CRON=1 से बंद करना — सब आधिकारिक डॉक्स (2026 तक) पर आधारित। /loop जो बदलती है वह है उस काम का समय-अक्ष जिसे आप AI को सौंप सकते हैं।

क्या आप उस तरफ़ होंगे जिसकी नौकरी AI छीन लेता है, या उस तरफ़ जो AI से दस लोगों का काम कर देता है? 2026 में इंजीनियरों के लिए यही दोराहा है। यह लेख "AI-नेटिव डेवलपर" बनने (LLM, एजेंट्स, RAG के साथ ऐप्स बनाना — मॉडलों पर शोध करने से अलग) को PhD नहीं बल्कि एक बनाने योग्य कौशल-ढेर के रूप में तीन परतों में पेश करता है: ① न बदलने वाली बुनियाद (Python AI डेव की मुख्य भाषा के रूप में, Git, कमांड लाइन, HTTP/REST/JSON — AI-लिखित कोड के दौर में भी बेसिक्स चाहिए); ② 5 मुख्य AI-नेटिव कौशल (प्रॉम्प्ट/कॉन्टेक्स्ट डिज़ाइन, एंटरप्राइज़ एजेंट्स की रीढ़ RAG, एजेंट्स बनाना, टूल-कनेक्शन का डी फ़ैक्टो मानक MCP, और eval डिज़ाइन — साथ ही कॉस्ट ऑप्टिमाइज़ेशन, गार्डरेल्स, ऑब्ज़र्वेबिलिटी); ③ वह बढ़त जिसे ज़्यादातर चूकते हैं — eval डिज़ाइन और कॉन्टेक्स्ट इंजीनियरिंग (evals लिख पाना "सच में LLM के साथ बनाया" का सबसे बड़ा संकेत है, और AGENTS.md/CLAUDE.md plus एक छोटा eval सेट "असिस्टेड" से "नेटिव" की छलांग है)। इसमें 8–12 महीने का रोडमैप (बुनियाद → LLM API/प्रॉम्प्टिंग → बिना फ़्रेमवर्क RAG बनाना → एजेंट्स + MCP → evals + डिप्लॉय + प्रकाशन), एक पोर्टफोलियो रणनीति जहाँ डिप्लॉय किया काम डिप्लोमा से बेहतर है, नुकसान (ट्यूटोरियल दलदल, टूल-जमाखोरी, बेसिक्स की उपेक्षा), और बाज़ार/माँग के आँकड़े (अमेरिका-आधारित, बड़ी क्षेत्रीय भिन्नता) शामिल हैं। सीमा यह है कि क्या आप AI को एक सिस्टम के रूप में इस्तेमाल करते हैं।

"पिछले महीने का API बिल… $1,800?" 2026 में, Claude Code को गंभीरता से एजेंट के रूप में चलाने पर यह हर महीने $500–2,000 तक पहुँचने की रिपोर्ट है। लेकिन सिर्फ इस्तेमाल का तरीका बदलकर, आप आउटपुट गुणवत्ता घटाए बिना लागत 70–85% घटा सकते हैं (कई वास्तविक रिपोर्टें यहाँ एकमत हैं)। यह गाइड पहले ऊँची लागत के असली चेहरे को खोलती है (महंगा मॉडल, लंबा कॉन्टेक्स्ट, बर्बाद कॉल; token बिलिंग कैसे काम करती है; एजेंट एक अकेली session का लगभग 7x खपत करते हुए), फिर सब्सक्रिप्शन बनाम API ब्रेक-ईवन (API मोटे तौर पर केवल महीने में 50 से कम session पर जीतता है; एक अनुमान सब्सक्रिप्शन को रोज के उपयोग के लिए 36x तक सस्ता बताता है), कीमतों का अवलोकन (Copilot Pro $10 / Cursor Pro $20, भारी होने पर $60–100 / Claude Pro $20, Max $100; Copilot 1 जून 2026 को उपयोग-आधारित AI Credits पर चला गया), लागत घटाने के छह उपाय (① मॉडल राउटिंग 40–70% छूट के लिए ② prompt caching लगभग 90% छूट पर 60–80% hit rate के साथ ③ कॉन्टेक्स्ट प्रबंधन ④ सब्सक्रिप्शन बनाम API चुनना ⑤ दोहरे सब्सक्रिप्शन का ऑडिट ⑥ memory फीचर), आज ही अपनाने योग्य बचत चेकलिस्ट, और खतरे — झूठी बचत, छिपी श्रम लागत, दोहरा बिलिंग, मीटर का झटका, कैश पर हद से ज्यादा भरोसा — साथ ही प्रकार के अनुसार अनुशंसित सेटअप। अनुकूलन कंजूसी करना नहीं है; यह सही चीज के लिए सही रकम चुकाने का डिज़ाइन है।

आप जानते हैं कि "RAG क्या है," पर जब आप एक बनाते हैं तो जवाब गलत आता है — क्योंकि यह अब भी naive RAG है: लापरवाही से काटो और साधारण vector search करो। लेख 030 के implementation फॉलो-अप के रूप में, यह 2026 के व्यावहारिक RAG pipeline (smart chunking, embedding, vector DB, hybrid search, reranking) को चरण-दर-चरण समझाता है: chunking रणनीतियां (recursive 512 डिफ़ॉल्ट, semantic/structural/parent-child, Contextual Retrieval जो रिपोर्ट के अनुसार retrieval विफलताओं को 67% तक घटाता है), embedding model चुनना (text-embedding-3-large, आदि), छह vector DBs की तुलना (prototyping के लिए Chroma, Postgres के साथ pgvector, कम latency वाला Qdrant, पूरी तरह managed Pinecone, hybrid चैंपियन Weaviate, बड़े पैमाने का Milvus), BM25 + dense vectors को RRF से मिलाने वाला hybrid search, bi-encoder फिर cross-encoder से retrieve-then-rerank (Cohere/Voyage/BGE/Jina), LlamaIndex (retrieval) बनाम LangChain/LangGraph (नियंत्रण) विभाजन, क्यों 1M-token window RAG को प्रतिस्थापित नहीं करता (lost in the middle, distraction), और पहले eval सेट बनाने जैसी production सावधानियां।

आप जानते हैं कि "AI एजेंट क्या है" — तो आप एक कैसे बनाएँ? 2026 में, no-code आपको ड्रैग-एंड-ड्रॉप करके एक दोपहर में काम करता एजेंट चालू करने देता है, और आधुनिक SDK 100 से कम लाइनों में एक व्यावहारिक एजेंट जोड़ने देते हैं। "AI एजेंट क्या है" के व्यावहारिक साथी के रूप में, यह बताता है: संरचना (दिमाग LLM + निर्देश + टूल + मेमोरी + स्वायत्त लूप), दो रास्ते (no-code बनाम code), सार्वभौमिक 5-स्टेप बिल्ड फ्रेमवर्क (समस्या सीमित करें, बेस चुनें, निर्देश लिखें, टूल जोड़ें, छोटे पैमाने पर टेस्ट करें), no-code टूल तुलना (संपूर्ण प्लेटफ़ॉर्म के लिए Dify, बिज़नेस इंटीग्रेशन के लिए n8n, प्रोटोटाइपिंग के लिए Flowise, और सबसे आसान Custom GPT/Gemini Gems/Claude Projects), code फ्रेमवर्क तुलना (ठोस Claude Agent SDK/OpenAI Agents SDK, जटिल-नियंत्रण LangGraph, भूमिका-समन्वय CrewAI), एक ठोस व्यावहारिक उदाहरण (सपोर्ट ईमेल का सारांश बनाकर Slack सूचना), लागत (~$10-$50/महीना प्लेटफ़ॉर्म साथ में मॉडल उपयोग) और समय-सीमा दिशानिर्देश, और गलतियाँ (दायरा बहुत बड़ा न करें, अनुमतियाँ और नियंत्रण, केवल-PoC से सावधान)। ज़्यादातर लोगों के लिए, पहले no-code से एक बनाना ही सही कदम है।

Claude Code अचानक रुक जाता है — "फिर से लॉगिन करें," "रेट लिमिट," "prompt बहुत लंबा है," "MCP कनेक्ट नहीं होगा" — और हर एक को गूगल करना थका देता है। यह एक व्यावहारिक रेफरेंस है जो आम तौर पर मिलने वाले एरर को सूचीबद्ध करता है, हर एक के कारण और चलाने लायक कमांड के साथ। यह पहले चलाने लायक तीन डायग्नोस्टिक कमांड से शुरू होता है (पूरे डायग्नोस्टिक्स के लिए claude doctor, सक्रिय ऑथ के लिए /status, कॉन्टेक्स्ट ब्रेकडाउन के लिए /context), फिर चार आम परिवारों (उपयोग/रेट लिमिट, कॉन्टेक्स्ट ओवरफ़्लो, एक्सपायर हुई ऑथ, MCP कनेक्शन फेल्योर) पर लक्षण→कारण→फिक्स-कमांड टेबल के साथ केंद्रित होता है — ऑथ और लॉगिन, उपयोग/रेट लिमिट (Claude Code चैट की तुलना में 10-100 गुना टोकन खपत करता है), कॉन्टेक्स्ट और टोकन (prompt बहुत लंबा, कॉम्पैक्शन थ्रैशिंग), सर्वर और मॉडल (500/529/timeout/model not found), इंस्टॉल/PATH/अपडेट, नेटवर्क और प्रॉक्सी (ECONNREFUSED, TLS), MCP, परमिशन (deny, bypass को हराता है), और अन्य (thinking blocks 400, image/PDF, IDE) में। यह एक एरर→फिक्स चीट शीट और FAQ के साथ समाप्त होता है। आधिकारिक Claude Code डॉक्स (2026 तक) पर आधारित: फँसने पर तीन डायग्नोस्टिक कमांड चलाएँ, और अगर ठीक न हो, तो claude update चलाएँ।