Codex ने सामान्य भाषा को काम करने वाले कोड में बदलकर डेवलपर्स के सॉफ़्टवेयर लिखने का तरीका बदल दिया। यह लेख बताता है कि यह कैसे काम करता है, क्या-क्या कर सकता है, कहाँ कमज़ोर पड़ता है, और आज के ज़्यादा सक्षम कोड मॉडल कैसे वहीं से आगे बढ़े हैं जहाँ Codex ने छोड़ा था।
OpenAI का Codex 2021 में आया और उसने तुरंत बदल दिया कि डेवलपर्स क्या संभव मानते हैं। उससे पहले ऑटोकम्प्लीट का मतलब था किसी वेरिएबल का नाम पूरा करना। उसके बाद आप सीधी अंग्रेज़ी में एक वाक्य लिख सकते थे और एक काम करता हुआ फ़ंक्शन बनते देख सकते थे। सिंटैक्स में मदद से इरादे का अनुवाद तक का यही बदलाव इस लेख में समझाया गया है।
Codex एक लार्ज लैंग्वेज मॉडल है, जिसे प्राकृतिक भाषा के टेक्स्ट और सार्वजनिक रिपॉज़िटरी से इकट्ठा किए गए सोर्स कोड के एक विशाल कॉर्पस पर प्रशिक्षित किया गया था, जिनमें सबसे प्रमुख GitHub है। अपने मूल में यह GPT-3 का वंशज है, जिसे गद्य के बजाय कोड टोकन की भविष्यवाणी के लिए ख़ास तौर पर फाइन-ट्यून किया गया था।
प्रशिक्षण डेटा ने इसे एक उल्लेखनीय चीज़ दी: इंसान सॉफ़्टवेयर कैसे लिखते हैं, इसका सांख्यिकीय ज्ञान। सिर्फ़ सिंटैक्स के नियम नहीं, बल्कि आम मुहावरे, लाइब्रेरी की परंपराएँ, फ़ंक्शन आम तौर पर कैसे नामित होते हैं, और कमेंट नीचे के कोड से कैसे जुड़ते हैं, यह सब भी। इसने प्रोग्रामिंग औपचारिक विनिर्देशों से नहीं सीखी, बल्कि लाखों ऐसे उदाहरणों से सीखी जिनमें प्रोग्रामर वास्तव में अपना काम कर रहे थे।
इसका आर्किटेक्चर एक ट्रांसफ़ॉर्मर है, वही न्यूरल नेटवर्क परिवार जो आज हर बड़े लैंग्वेज मॉडल के पीछे है। ट्रांसफ़ॉर्मर सेल्फ़-अटेंशन नाम की व्यवस्था से इनपुट कॉन्टेक्स्ट के हर टोकन का दूसरे हर टोकन से प्रासंगिकता-भार तय करते हैं। कोड के लिए यह बेहद ताकतवर है: 200 लाइन पहले परिभाषित कोई वेरिएबल भी मॉडल के लिए तब तक "दिखता" रहता है, जब वह अगला हिस्सा भविष्यवाणी कर रहा होता है।
Codex दो मुख्य कॉन्फ़िगरेशन में आया: एक छोटा cushman वर्ज़न (लगभग 12B पैरामीटर), जो स्पीड के लिए ऑप्टिमाइज़ था, और एक बड़ा davinci वर्ज़न, जो सटीकता पर केंद्रित था। मूल GitHub Copilot को davinci वर्ज़न ने ही शक्ति दी थी, और लॉन्च के समय यही कॉन्फ़िगरेशन लोगों को सचमुच प्रभावित कर पाया।
सामान्य-उद्देश्य वाले LLM हर चीज़ संभालने के लिए प्रशिक्षित होते हैं: निबंध, सवाल, सारांश, बातचीत। Codex ने चौड़ाई के बदले गहराई चुनी। कोड पर इसकी फाइन-ट्यूनिंग का मतलब है कि यह दर्जनों प्रोग्रामिंग भाषाओं में सिंटैक्स के हिसाब से सही आउटपुट भरोसे से देता है, गद्य-केंद्रित मॉडलों से बेहतर तरीके से कोड-विशेष कॉन्टेक्स्ट संभालता है, और रिकर्शन, async एक्ज़िक्यूशन और API कॉन्ट्रैक्ट जैसी अमूर्त प्रोग्रामिंग अवधारणाओं को व्यावहारिक स्तर पर समझता है।
💡 एक सामान्य LLM किसी सॉर्टिंग एल्गोरिदम का वर्णन करेगा। Codex उसे लिखेगा, और एज केस भी संभालेगा।
यांत्रिक स्तर पर, कोड जनरेशन नेक्स्ट-टोकन प्रेडिक्शन है। आप मॉडल को एक प्रॉम्प्ट देते हैं, जो कमेंट, फ़ंक्शन सिग्नेचर या कोई मौजूदा फ़ाइल हो सकती है, और मॉडल हर संभव अगले टोकन पर एक प्रायिकता वितरण की गणना करता है, फिर उस वितरण से सैंपल लेता है।
कोड के लिए जो चीज़ इसे ताकतवर बनाती है, वह यह है कि वैध प्रोग्राम सभी संभावित टोकन अनुक्रमों का बहुत छोटा हिस्सा घेरते हैं। असली कोड पर प्रशिक्षण मॉडल को उस वैध क्षेत्र का आकार सिखाता है, इसलिए उसकी भविष्यवाणियाँ ज़्यादातर समय उसी के भीतर पड़ती हैं।
कोड मॉडल एक कॉन्टेक्स्ट विंडो के भीतर काम करते हैं, यानी वह अधिकतम टोकन संख्या जिसे वे एक बार में प्रोसेस कर सकते हैं। Codex के लिए यह वर्ज़न के आधार पर 4,096 या 8,192 टोकन थी। इससे सीमित होता है कि भविष्यवाणी करते समय मॉडल आसपास के कितने कोड को "देख" सकता है।
आधुनिक कोड मॉडलों ने इसे काफ़ी आगे बढ़ाया है। GPT 4.1 10 लाख टोकन तक के कॉन्टेक्स्ट संभालता है, यानी पूरे कोडबेस एक ही प्रॉम्प्ट में समा सकते हैं। IBM का Granite 8B Code Instruct 128K ख़ास तौर पर कोड कार्यों के लिए ऑप्टिमाइज़ 1,28,000 टोकन देता है, जो Codex की मूल सीमाओं से एक बड़ा सुधार है।
Codex का स्पष्ट "जादू" यह है कि इसे ऐसे कोड रिपॉज़िटरी पर प्रशिक्षित किया गया था जिनमें कमेंट और इम्प्लीमेंटेशन दोनों साथ-साथ थे। इसने सीखा कि # parse a JSON file and return a dict जैसा कमेंट आम तौर पर एक ख़ास तरह के Python फ़ंक्शन से पहले आता है। वह कमेंट देने पर वह संबंध सक्रिय हो जाता है और मॉडल उसके अनुरूप इम्प्लीमेंटेशन की भविष्यवाणी करता है।
यह किसी दार्शनिक अर्थ में रीज़निंग नहीं है। यह असाधारण रूप से ताकतवर पैटर्न मैचिंग है, जो इतने बड़े पैमाने पर चलती है कि उसके आउटपुट समझ से अलग नहीं दिखते।
💡 ध्यान देने योग्य बात: Codex कोड एक्ज़िक्यूट नहीं करता और न ही उसे किसी रनटाइम पर जाँचता है। हर सुझाव एक सांख्यिकीय भविष्यवाणी है। इसी वजह से AI से बने कोड को अब भी इंसानी समीक्षा की ज़रूरत पड़ती है।
असली क्षमताओं की रूपरेखा समझने से आप किसी भी AI कोड मॉडल से न बहुत ज़्यादा उम्मीद करेंगे, न बहुत कम।
OpenAI ने मार्च 2023 में Codex को बंद कर दिया था। उसके बाद से कोड जनरेशन का परिदृश्य काफ़ी आगे बढ़ चुका है, और हर सार्थक सुधार दो अक्षों तक जाता है: बड़ी कॉन्टेक्स्ट विंडो और इंटीग्रेटेड रीज़निंग।
| मॉडल | कॉन्टेक्स्ट विंडो | विशेषता | उपलब्धता |
|---|---|---|---|
| Codex (davinci) | 8K टोकन | कोड-केंद्रित | बंद हो चुका |
| GPT 4.1 | 10 लाख टोकन | सामान्य + कोड | PicassoIA |
| Granite 8B Code 128K | 128K टोकन | केवल कोड | PicassoIA |
| Granite 20B Code 8K | 8K टोकन | केवल कोड | PicassoIA |
| DeepSeek R1 | 128K टोकन | कोड + रीज़निंग | PicassoIA |
| Claude 4 Sonnet | 200K टोकन | कोड + लेखन | PicassoIA |
| Kimi K2 Instruct | 128K टोकन | एजेंटिक कोडिंग | PicassoIA |
Codex को एक ही काम के लिए ऑप्टिमाइज़ किया गया था: अगला कोड क्या आएगा, इसकी भविष्यवाणी करना। नए मॉडल कोड जनरेशन को चेन-ऑफ़-थॉट रीज़निंग के साथ जोड़ते हैं, जिसमें कोड देने से पहले समस्या पर चरण-दर-चरण सोचा जाता है। इससे उन मल्टी-स्टेप प्रोग्रामिंग कार्यों में फ़ासला भरता है, जहाँ सिर्फ़ पैटर्न मैचिंग काफ़ी नहीं होती।
DeepSeek R1 यहाँ अलग दिखता है: यह दिखने वाले रीज़निंग ट्रेस देता है, इसलिए आप ठीक-ठीक देख सकते हैं कि उसने कोड को किसी ख़ास तरीके से क्यों ढाला। Claude 4 Sonnet भी बिना पूछे अपने लिखे कोड को प्राकृतिक भाषा में समझाता है, जिससे AI से बने आउटपुट की समीक्षा काफ़ी तेज़ हो जाती है।
Codex से आगे निकले सभी मॉडल PicassoIA के लार्ज लैंग्वेज मॉडल संग्रह में उपलब्ध हैं। न API key संभालने की ज़रूरत है, न लोकल एनवायरनमेंट का सेटअप। असली कोड जनरेशन कार्यों पर इन्हें कैसे लगाएँ, यह यहाँ है।
Granite 8B Code Instruct 128K IBM का समर्पित कोड मॉडल है, जिसे जनरेशन, डीबगिंग, व्याख्या और रीफ़ैक्टरिंग सहित प्रोग्रामिंग कार्यों पर ख़ास तौर पर प्रशिक्षित किया गया है।
💡 टिप: रीफ़ैक्टरिंग कार्यों के लिए, पहले मौजूदा फ़ंक्शन चिपकाएँ, फिर जोड़ें: "इसे [एज केस] संभालने के लिए फिर से लिखें, पर वही इंटरफ़ेस रखें।"
GPT 4.1 तब बेहतरीन है जब कार्य कई फ़ाइलों में फैला हो। इसकी 10 लाख टोकन की विंडो का मतलब है कि आप पूरे मॉड्यूल या कई संबंधित फ़ाइलें एक साथ चिपका सकते हैं और उसे एक बार में सभी पर तर्क करने को कह सकते हैं। यह वही कार्य है जिसमें Codex सबसे साफ़ तौर पर कमज़ोर पड़ता था, और यहीं GPT 4.1 एक सचमुच अलग अनुभव देता है।
इसे इन कामों के लिए इस्तेमाल करें:
जो डेवलपर्स AI कोड जनरेशन से सबसे ज़्यादा फ़ायदा उठाते हैं, वे उसे एक तेज़ पहला ड्राफ़्ट मानते हैं, तैयार उत्पाद नहीं। व्यवहार में यह ऐसा दिखता है।
टेस्ट जनरेशन वह जगह है जहाँ कोड LLM रोज़मर्रा के काम में सबसे ज़्यादा व्यावहारिक मूल्य जोड़ते हैं। ज़्यादातर डेवलपर इम्प्लीमेंटेशन लिखने के बाद टेस्ट लिखते हैं, और यह थकाऊ होता है। आप पहले से जानते हैं कि फ़ंक्शन क्या करता है, बस केस गिनने बाकी हैं।
एक उपयोगी प्रॉम्प्ट पैटर्न:
Given this function:
[paste function]
Write pytest unit tests covering:
- The happy path
- Empty input
- Edge case: [specific case you are worried about]
- Error conditions
Kimi K2 Instruct इस पैटर्न को ख़ास तौर पर अच्छी तरह संभालता है। इसे एजेंटिक कोडिंग वर्कफ़्लो को ध्यान में रखकर प्रशिक्षित किया गया था, यानी यह आपस में मेल खाते टेस्ट सूट बनाता है, न कि ऐसे अलग-अलग टेस्ट फ़ंक्शन जो फ़िक्स्चर या सेटअप साझा नहीं करते।
रीफ़ैक्टरिंग जनरेशन से अलग चुनौती है। सुधारने से पहले मॉडल को मौजूदा कोड समझना पड़ता है, इसलिए कॉन्टेक्स्ट विंडो का आकार निर्णायक कारक बन जाता है।
पुराना मॉड्यूल चिपकाएँ, समस्या बताएँ, और वही बाहरी इंटरफ़ेस रखते हुए रीफ़ैक्टर्ड वर्ज़न माँगें। Claude 4.5 Sonnet और GPT 4.1 दोनों इसे अच्छी तरह करते हैं, क्योंकि वे नया फ़ंक्शन बनाते समय मूल फ़ंक्शन पूरा अपने ध्यान में रख सकते हैं, न कि पहले वहाँ क्या था इसका अंदाज़ा लगाएँ।
खराब प्रॉम्प्ट से खराब कोड बनता है। अच्छे प्रॉम्प्ट से ऐसा कोड बनता है जिसे आप शिप कर सकें। फ़र्क लगभग पूरी तरह इस बात में है कि आप शुरू में मॉडल को कितना कॉन्टेक्स्ट देते हैं।
कॉन्टेक्स्ट के बिना कोड बनाने वाला मॉडल आपकी सीमाओं का अंदाज़ा लगा रहा होता है। उसे अपनी भाषा और फ़्रेमवर्क बताने से गलत तरीका चुनने की संभावना आधी हो जाती है। मौजूदा इंटरफ़ेस बताने से इंटीग्रेशन की पूरी श्रेणी की गलतियाँ सामने आने से पहले ही ख़त्म हो जाती हैं।
न्यूनतम कॉन्टेक्स्ट वाला प्रॉम्प्ट:
Write a function to parse CSV files
प्रभावी कॉन्टेक्स्ट वाला प्रॉम्प्ट:
Python 3.11, using the csv module (not pandas).
Write a function parse_csv(filepath: str) -> list[dict]
that reads a CSV with a header row and returns a list of dicts.
Handle FileNotFoundError and return an empty list if the file is empty.
दूसरा प्रॉम्प्ट काम आने लायक कोड देता है। पहला कुछ ऐसा देता है जो सही लगता है, पर आपके कोडबेस में फ़िट हो भी सकता है और नहीं भी।
💡 अगर पहला जवाब गलत है, तो वही प्रॉम्प्ट दोबारा न चलाएँ। एक वाक्य जोड़कर बताएँ कि क्या गलत था। मॉडल सुधारात्मक फ़ॉलो-अप पर दोहराए गए एक जैसे प्रॉम्प्ट से कहीं बेहतर प्रतिक्रिया देते हैं।
Codex और आज के मॉडलों के बीच सबसे अहम व्यावहारिक फ़ासलों में से एक प्रति टोकन क्षमता नहीं है। यह है कि वे एक बार में कितने टोकन पर ध्यान दे सकते हैं।
8K टोकन पर Codex लगभग 400 से 600 लाइन कोड प्रोसेस कर सकता था। यह अलग-अलग फ़ंक्शनों के लिए ठीक था, पर उन कामों में तुरंत लड़खड़ा जाता था जिनमें साझा टाइप वाली कई फ़ाइलें हों, डेटाबेस मॉडल का हवाला देने वाले API हैंडलर हों, या कई मॉड्यूल फैले इंटीग्रेशन टेस्ट हों।
Granite 20B Code Instruct 8K की कॉन्टेक्स्ट विंडो Codex के बराबर है, लेकिन इसमें काफ़ी ज़्यादा पैरामीटर और ज़्यादा हाल का ट्रेनिंग कॉर्पस है, जिससे इसका प्रति-टोकन आउटपुट काफ़ी ज़्यादा सटीक बनता है। Granite 8B Code Instruct 128K कच्चे पैरामीटर की संख्या की जगह पहुँच को चुनता है: शुरुआत से ही खास तौर पर कोड कामों के लिए बने मॉडल में 128K टोकन।
पूरे कोडबेस पर होने वाले कार्यों के लिए, GPT 5 मौजूदा सबसे आगे की तकनीक है, जो लगभग असीमित कॉन्टेक्स्ट को हर बड़ी भाषा और फ़्रेमवर्क में व्यापक सॉफ़्टवेयर इंजीनियरिंग क्षमता के साथ जोड़ता है।
Codex ने जो जनरेशन प्रतिमान स्थापित किया था, वह था: कॉन्टेक्स्ट दो, टोकन की भविष्यवाणी करो। उसके बाद आए रीज़निंग प्रतिमान में आउटपुट से पहले एक कदम जुड़ता है: पहले समस्या पर सोचो।
DeepSeek R1 और GPT 5 जैसे मॉडल कोड देने से पहले मध्यवर्ती विचारों की एक श्रृंखला पर काम करते हैं। इससे इन कामों में वास्तविक फ़र्क पड़ता है:
कोड समीक्षा के लिए रीज़निंग ट्रेस अपने आप में भी मूल्यवान है। अगर मॉडल समझाता है कि उसने किसी ख़ास बग-वर्ग से बचने के लिए कोई पैटर्न चुना, तो आप उस तर्क को सीधे जाँच सकते हैं, न कि एक ब्लैक बॉक्स आउटपुट का ऑडिट करते रहें।
💡 व्यावहारिक नोट: रीज़निंग मॉडल धीमे होते हैं और प्रति टोकन ज़्यादा महँगे पड़ते हैं। उन्हें सही होना ज़रूरी हो ऐसे कोड के लिए इस्तेमाल करें। बॉयलरप्लेट और टेस्ट के लिए Claude 4.5 Haiku जैसा तेज़ मॉडल कहीं ज़्यादा कुशल है।
कोड जनरेशन के लिए Codex एक प्रूफ़ ऑफ़ कॉन्सेप्ट था, जिसे पूरे उद्योग ने सही साबित किया और फिर बहुत पीछे छोड़ दिया। अब उपलब्ध मॉडल वह सब करते हैं जो Codex करता था, साथ में बड़ी कॉन्टेक्स्ट विंडो, बेहतर रीज़निंग और भाषाओं व फ़्रेमवर्क की ज़्यादा विस्तृत रेंज में अधिक सटीक आउटपुट के साथ।
अगर आपने AI कोड मॉडल को गंभीरता से इस्तेमाल नहीं किया है, तो सबसे आसान शुरुआत उस काम से करें जो आप हर हफ़्ते करते हैं पर थकाऊ लगता है। टेस्ट जनरेशन, docstring लिखना और बॉयलरप्लेट स्कैफ़ोल्डिंग, इन सबका फ़ीडबैक लूप छोटा है: आप तुरंत देख लेते हैं कि आउटपुट काम का है या नहीं। वहीं से शुरू करें, समझ बनाएँ कि क्या काम करता है, और अपने प्रॉम्प्ट लिखने के तरीके को परखते हुए कठिन कामों की ओर बढ़ें।
ऊपर की तुलना तालिका का हर मॉडल अभी PicassoIA पर उपलब्ध है। कोई सेटअप नहीं। कोई API key नहीं। कोई एक चुनें, एक फ़ंक्शन चिपकाएँ, और एक मिनट से कम में देखें कि वह क्या करता है। जटिल क्रॉस-फ़ाइल काम के लिए GPT 5 आज़माएँ, जब आपको रीज़निंग देखनी हो तो DeepSeek R1, या केंद्रित, तेज़ केवल-कोड अनुभव के लिए Granite 8B Code Instruct 128K। "मैंने AI कोडिंग टूल्स के बारे में सुना है" और "मैं इन्हें रोज़ इस्तेमाल करता हूँ" के बीच का फ़ासला बस एक दोपहर के प्रयोग भर का है।
अपनी भाषा चुनें
