हमने Codex का उपयोग करके 28 दिनों में Android के लिए Sora कैसे बनाया

26 अप्रैल, 2026 से प्रभावी, Sora प्रोडक्ट अब और उपलब्ध नहीं है.

नवंबर में, हमने Sora Android ऐप को दुनिया भर में लॉन्च किया, जिससे किसी भी Android डिवाइस के उपयोगकर्ता एक छोटे प्रॉम्प्ट को एक जीवंत वीडियो में बदल सकते हैं. लॉन्च के दिन, ऐप प्ले स्टोर में नंबर 1 पर पहुंच गया. Android यूज़र ने पहले 24 घंटों में एक मिलियन से अधिक वीडियो जनरेट किए.

लॉन्च के पीछे एक कहानी है: Sora के प्रोडक्शन Android ऐप का प्रारंभिक संस्करण 28 दिनों में बनाया गया था, उसी एजेंट की बदौलत जो किसी भी Team या डेवलपर के लिए उपलब्ध है: Codex.

8 अक्टूबर से 5 नवंबर, 2025 तक, एक लीन इंजीनियरिंग Team ने Codex के साथ मिलकर काम करते हुए और लगभग 5 बिलियन token का उपयोग करते हुए, Sora को Android के लिए प्रोटोटाइप से वैश्विक लॉन्च तक पहुँचाया. इसके पैमाने के बावजूद, ऐप का क्रैश-फ्री रेट 99.9 प्रतिशत है और इसका आर्किटेक्चर ऐसा है जिस पर हमें गर्व है. अगर तुम सोच रहे हो कि क्या हमने कोई गुप्त मॉडल इस्तेमाल किया, तो हमने GPT‑5.1‑Codex के एक शुरुआती संस्करण का उपयोग किया मॉडल – वही संस्करण जो आज किसी भी डेवलपर या Business द्वारा CLI, IDE एक्सटेंशन, या वेब ऐप के माध्यम से उपयोग किया जा सकता है.

जब Sora को iOS पर लॉन्च किया गया, तो उपयोग तेजी से बढ़ गया. लोग तुरंत वीडियो की एक धारा जनरेट करने लगे. इसके विपरीत, Android पर हमारे पास केवल एक छोटा आंतरिक प्रोटोटाइप था और Google Play पर प्री-रजिस्टर किए गए यूज़र की संख्या बढ़ रही थी.

उच्च दांव और समय के दबाव वाले लॉन्च के लिए एक सामान्य रिस्पांस है संसाधनों को बढ़ाना और प्रक्रियाओं को जोड़ना. इस स्तर और गुणवत्ता के प्रोडक्शन ऐप में आमतौर पर कई इंजीनियर महीनों तक काम करते हैं, जिन्हें समन्वय के कारण धीमा कर दिया जाता है. 

अमेरिकी कंप्यूटर आर्किटेक्ट फ्रेड ब्रूक्स ने प्रसिद्ध रूप से चेतावनी दी थी कि "एक देर से चल रहे सॉफ़्टवेयर प्रोजेक्ट में अधिक लोगों को जोड़ने से यह और भी देर से हो जाता है." दूसरे शब्दों में, जब किसी जटिल प्रोजेक्ट को जल्दी से शिप करने की कोशिश की जाती है, तो अधिक इंजीनियरों को जोड़ने से अक्सर संचार ओवरहेड, टास्क विखंडन, और एकीकरण लागत बढ़ने के कारण दक्षता कम हो सकती है. हमने इस अंतर्दृष्टि को नजरअंदाज करने के बजाय इसे अपनाया; हमने चार इंजीनियरों की एक मजबूत Team बनाई - सभी Codex से लैस थे ताकि प्रत्येक इंजीनियर के प्रभाव को काफी हद तक बढ़ाया जा सके. 

इस तरह काम करते हुए, हमने 18 दिनों में कर्मचारियों के लिए Android के लिए Sora का एक इंटरनल बिल्ड भेजा और 10 दिन बाद सार्वजनिक रूप से लॉन्च किया. हमने एंड्रॉइड इंजीनियरिंग प्रथाओं में उच्च मानक बनाए रखा, रखरखाव में निवेश किया, और ऐप को उसी विश्वसनीयता के स्तर पर रखा जैसा कि हम एक पारंपरिक प्रोजेक्ट से अपेक्षा करते हैं. (हम आज भी Codex का व्यापक रूप से उपयोग करते हुए आगे बढ़ें ताकि ऐप में नए फीचर्स विकसित और जोड़े जा सकें.)

यह समझने के लिए कि हमने Codex के साथ कैसे काम किया, यह जानना फायदेमंद होता है कि यह कहाँ बेहतरीन है और कहाँ इसे मार्गदर्शन की ज़रूरत है. इसे एक नए नियुक्त वरिष्ठ इंजीनियर के रूप में देखना एक अच्छा दृष्टिकोण था. Codex की क्षमता का अर्थ था कि हम कोड को खुद लिखने के बजाय उसे निर्देशित करने और रिव्यु करने में अधिक समय बिता सकते थे.

जहां Codex को मार्गदर्शन की आवश्यकता है

1. Codex अभी तक उन चीज़ों को समझने में उतना अच्छा नहीं है जो उसे नहीं बताई गई हैं (जैसे, आपकी पसंदीदा आर्किटेक्चर पैटर्न, उत्पाद रणनीति, वास्तविक यूज़र व्यवहार, और आंतरिक मानदंड या शॉर्ट कट).
2. इसी तरह, Codex ऐप को वास्तव में चलते हुए नहीं देख सकता था: यह डिवाइस पर Sora को नहीं खोल सकता था, यह नहीं देख सकता था कि स्क्रॉल सही नहीं लग रहा था, या यह महसूस नहीं कर सकता था कि फ्लो भ्रमित कर रहा था. सिर्फ हमारी Team ही इन अनुभवात्मक टास्क को पूरा कर सकती थी.
3. प्रत्येक उदाहरण के लिए ऑनबोर्डिंग की आवश्यकता होती है. स्पष्ट लक्ष्यों, बाधाओं और 'हम चीजें कैसे करते हैं' पर मार्गदर्शन के साथ कॉन्टेक्स्ट साझा करना Codex को अच्छी तरह से निष्पादित करने के लिए आवश्यक था.
4. इसी तरह, Codex गहरे आर्किटेक्चरल निर्णय के साथ संघर्ष करता था: अगर इसे अपने हाल पर छोड़ दिया जाए, तो यह एक अतिरिक्त व्यू मॉडल पेश कर सकता है, जबकि हम वास्तव में मौजूदा एक को विस्तारित करना चाहते थे, या लॉजिक को UI लेयर में धकेल सकता है, जो स्पष्ट रूप से एक रिपॉजिटरी में होना चाहिए था. इसका स्वाभाविक झुकाव कुछ काम करने की ओर होता है, न कि दीर्घकालिक स्वच्छता को प्राथमिकता देने की.

हमने पाया कि कोडबेस में Codex द्वारा पर्याप्त मात्रा में एजेंट.md फ़ाइलें बनाएं और बनाए रखना उपयोगी है. इससे विभिन्न सेशन्स में एक ही मार्गदर्शन और सर्वोत्तम प्रथाओं को लागू करना आसान हो गया. उदाहरण के लिए, यह सुनिश्चित करने के लिए कि Codex ने हमारे स्टाइल दिशानिर्देशों के अनुसार कोड लिखा है, हमने अपने शीर्ष-स्तरीय AGENTS.md में निम्नलिखित जोड़ा:

जहां Codex उत्कृष्टता प्राप्त करता है

1. बड़े कोडबेस को तेजी से पढ़ना और समझना: Codex लगभग सभी प्रमुख प्रोग्रामिंग भाषाओं को जानता है, जिससे कई प्लेटफॉर्म्स पर एक ही अवधारणाओं का उपयोग करना आसान हो जाता है बिना जटिल अमूर्तताओं के.
2. परीक्षण कवरेज: Codex (विशेष रूप से) यूनिट टेस्ट लिखने के लिए उत्साही है ताकि विभिन्न प्रकार के मामलों को कवर किया जा सके. हर परीक्षण गहन नहीं था, लेकिन कवरेज की व्यापकता ने रिग्रेशन को रोकने में मदद की. 
3. फ़ीडबैक लागू करना: इसी तरह, कोडेक्स फ़ीडबैक पर प्रतिक्रिया देने में अच्छा है. जब CI विफल हो जाता, तो हम लॉग आउटपुट को प्रॉम्प्ट में पेस्ट कर सकते थे और Codex से सुधार प्रस्तावित करने के लिए कह सकते थे.
4. विशाल पैमाने पर समानांतर, डिस्पोजेबल निष्पादन: अधिकांश लोग उस सीमा तक नहीं पहुँचेंगे जितने सेशन वे वास्तव में एक समय में चला सकते हैं. यह अत्यधिक संभव है कि कई विचारों का समानांतर परीक्षण किया जाए और कोड को डिस्पोजेबल के रूप में देखा जाए.
5. नए दृष्टिकोण की पेशकश: डिज़ाइन चर्चाओं में, हमने संभावित विफलता बिंदुओं की एक्स्प्लोर करने और समस्या को हल करने के नए तरीकों को खोजने के लिए Codex को एक जनरेटिव टूल के रूप में इस्तेमाल किया. उदाहरण के लिए, जब हमने वीडियो प्लेयर मेमोरी ऑप्टिमाइज़ेशन डिज़ाइन किया, तो Codex ने कई SDKs का छानबीन किया और ऐसे दृष्टिकोण प्रस्तावित किए जिन्हें समझने का हमारे पास समय नहीं था. Codex की रिसर्च से प्राप्त इनसाइट्स ने अंतिम ऐप में मेमोरी फुटप्रिंट को कम करने में अमूल्य साबित हुईं.
6. उच्च-प्रभावी कार्य को सक्षम बनाना: व्यवहार में, हमने कोड लिखने की बजाय इसे रिव्यु करने और निर्देशित करने में अधिक समय बिताया. यह कहा जा सकता है कि Codex कोड रिव्यू में भी बहुत अच्छा है, जो अक्सर बग्स को मिलाएँ होने से पहले ही पकड़ लेता है और इससे विश्वसनीयता में सुधार होता है.

जैसे ही हमने इन विशेषताओं को स्वीकार किया, हमारा कार्य मॉडल और भी सरल हो गया. हमने Codex पर भरोसा किया ताकि वह अच्छी तरह से समझे जाने वाले पैटर्न और सीमित दायरे के अंदर भारी काम कर सके, जबकि हमारी Team आर्किटेक्चर, यूज़र अनुभव, प्रणालीगत बदलाव और अंतिम गुणवत्ता पर ध्यान केंद्रित कर सके.

यहां तक कि सबसे अच्छे नए, वरिष्ठ नियुक्त व्यक्ति के पास तुरंत दीर्घकालिक समझौते करने के लिए सही दृष्टिकोण नहीं होता. Codex का लाभ उठाने और यह सुनिश्चित करने के लिए कि इसका काम मजबूत और बनाए रखने योग्य था, यह महत्वपूर्ण था कि हम स्वयं ऐप की सिस्टम डिज़ाइन और प्रमुख ट्रेड-ऑफ़्स की देखरेख करें. इनमें ऐप की संरचना को आकार देना, मॉड्यूलराइजेशन, डिपेंडेंसी इंजेक्शन, और नेविगेशन शामिल थे; हमने प्रमाणीकरण और बेस नेटवर्किंग प्रवाह भी लागू किए. 

इस आधार पर, हमने कुछ प्रतिनिधि फीचर्स को अंत-से-अंत तक लिखा. हमने उन नियमों का उपयोग किया जिन्हें हम चाहते थे कि पूरा कोडबेस पालन करे और जैसे-जैसे हम आगे बढ़े, परियोजना-व्यापी पैटर्न को दस्तावेज़ किया. प्रतिनिधि विशेषताओं की ओर Codex को इंगित करने से, यह हमारे मानकों के भीतर अधिक स्वतंत्र रूप से काम कर सका. एक प्रोजेक्ट के लिए, जिसे हम अनुमान लगाते हैं कि 85% Codex द्वारा लिखा गया था, एक सावधानीपूर्वक प्लॉनबद्ध नींव ने महंगे बैकट्रैकिंग और रीफ़ैक्टरिंग से बचाया. यह हमारे द्वारा किए गए सबसे महत्वपूर्ण निर्णयों में से एक था. 

विचार यह नहीं था कि "कुछ ऐसा बनाएं जो जल्दी से काम करे", बल्कि यह था कि "कुछ ऐसा बनाएं जो इस बात को समझे कि हम चीजों को कैसे काम करना चाहते हैं." कोड लिखने के कई “सही” तरीके होते हैं. हमें Codex को ठीक-ठीक यह बताने की ज़रूरत नहीं थी कि क्या करना है; हमें Codex को यह दिखाने की ज़रूरत थी कि हमारी Team में क्या "सही" है. एक बार जब हमने अपनी शुरुआत का बिंदु और हमें कैसे निर्माण करना पसंद है, यह तय कर लिया, तो Codex शुरू करने के लिए तैयार था.

यह देखने के लिए कि क्या होगा, हमने यह संकेत देने की कोशिश की: "iOS कोड के आधार पर Sora Android ऐप बनाओ." "Go," लेकिन जल्दी ही उस रास्ते को छोड़ दिया. हालांकि Codex द्वारा बनाया गया तकनीकी रूप से काम कर रहा था, लेकिन उत्पाद का अनुभव मानक से कम था. एंडपॉइंट्स, डेटा, और यूज़र फ्लोज़ की स्पष्ट समझ के बिना, Codex का सिंगल-शॉट कोड अविश्वसनीय था (एजेंट का उपयोग किए बिना भी, हजारों लाइनों के कोड को मिलाएँ जोखिम भरा है.) 

हमने यह परिकल्पना की थी कि Codex अच्छी तरह से लिखे गए उदाहरणों के सैंडबॉक्स में सफल होगा; और हम सही थे. Codex से "यह सेटिंग्स स्क्रीन बनाओ" कहने पर, लगभग बिना किसी कॉन्टेक्स्ट के, यह अविश्वसनीय था. Codex से यह कहना कि "इस सेटिंग्स स्क्रीन को उसी आर्किटेक्चर और पैटर्न का उपयोग करके बनाओ जैसा तुमने अभी-अभी दूसरी स्क्रीन में देखा था" कहीं बेहतर काम किया. मनुष्यों ने संरचनात्मक निर्णय लिए और अपरिवर्तनीयताएँ निर्धारित कीं; फिर Codex ने उस संरचना के भीतर बड़ी मात्रा में कोड भरा.

Codex की क्षमता को अधिकतम करने का अगला कदम यह समझना था कि Codex को बिना निगरानी लंबे समय तक (हाल ही में, 24 घंटे से ज़्यादा⁠) काम करने के लिए कैसे सक्षम किया जाए.

Codex का उपयोग शुरू करते समय, हम जल्दी से इस तरह के प्रॉम्प्ट्स पर पहुँच गए, जैसे कि, "यहाँ फीचर है." यहाँ कुछ फ़ाइलें हैं. कृपया इसे बनाओ. कभी-कभी यह काम करता था, लेकिन ज्यादातर ऐसा कोड उत्पन्न होता था जो तकनीकी रूप से कंपाइल हो जाता था, लेकिन हमारी आर्किटेक्चर और लक्ष्यों से भटक जाता था.

तो हमने वर्कफ़्लो बदल दिया. किसी भी महत्वपूर्ण बदलाव के लिए, हमने पहले Codex से यह समझने में मदद मांगी कि सिस्टम और कोड कैसे कार्य करते हैं. उदाहरण के लिए, हम इसे संबंधित फ़ाइलों के सेट को पढ़ने और यह सारांशित करने के लिए कहेंगे कि वह फीचर कैसे काम करता है; उदाहरण के लिए, डेटा API से रिपॉजिटरी लेयर, व्यू मॉडल, और UI में कैसे प्रवाहित होता है. फिर हम इसकी समझ को सुधारेंगे या परिष्कृत करेंगे. (उदाहरण के लिए, हम यह बताएंगे कि कोई विशेष अमूर्तता वास्तव में किसी अन्य स्तर में होनी चाहिए या कि कोई विशेष क्लास केवल ऑफलाइन मोड के लिए है और इसे विस्तारित नहीं किया जाना चाहिए.)

जिस तरह आप एक नए, अत्यधिक सक्षम टीममेट के साथ जुड़ते हैं, उसी तरह हमने Codex के साथ मिलकर एक ठोस प्लॉन बनाया. वह प्लॉन अक्सर एक लघु डिज़ाइन डॉक्यूमेंट की तरह दिखती थी, जो यह निर्देश देती थी कि कौन-सी फ़ाइलें बदलनी चाहिए, कौन-से नए स्टेट्स पेश किए जाने चाहिए, और लॉजिक कैसे प्रवाहित होना चाहिए. तभी हमने Codex से कहा कि वह प्लॉन को एक समय में एक कदम उठाते हुए लागू करना शुरू करे. एक सहायक सुझाव: बहुत लंबे टास्क के लिए, जहाँ हम अपने कॉन्टेक्स्ट विंडो की सीमा तक पहुँच जाते हैं, हम Codex से उसका प्लॉन एक फ़ाइल में सेव करने के लिए कहेंगे, जिससे हम एक ही दिशा को विभिन्न उदाहरणों में लागू कर सकें.

यह अतिरिक्त योजना चक्र समय के लायक साबित हुआ. इसने हमें Codex को लंबे समय तक बिना निगरानी के चलाने की अनुमति दी, क्योंकि हमें इसकी प्लॉन पता थीं. इससे कोड रिव्यू आसान हो गया, क्योंकि हम बिना कॉन्टेक्स्ट के डिफ पढ़ने के बजाय अपनी प्लॉन के खिलाफ कार्यान्वयन की जांच कर सकते थे. और जब कुछ गलत हो गया, तो हम पहले प्लॉन को डीबग कर सकते थे और फिर कोड को. 

डायनामिक का अनुभव वैसा ही था जैसे एक अच्छा डिज़ाइन डॉक्यूमेंट किसी टेक लीड को प्रोजेक्ट में आत्मविश्वास देता है. हम केवल कोड जनरेट नहीं कर रहे थे: हम ऐसा कोड तैयार कर रहे थे जो एक साझा रोडमैप का समर्थन करता था.

प्रोजेक्ट के चरम पर, हम अक्सर कई Codex सेशन समानांतर में चला रहे थे. कोई प्लेबैक पर काम कर रहा था, कोई सर्च पर, कोई त्रुटि प्रबंधन पर, और कभी-कभी कोई परीक्षणों या पुनःसंरचना पर. यह एक उपकरण का उपयोग करने जैसा कम और एक Team का प्रबंधन करने जैसा अधिक महसूस हुआ.

हर सेशन समय-समय पर हमें प्रगति की जानकारी देगा. कोई कह सकता है, "मैंने इस मॉड्यूल की योजना बनाना समाप्त कर लिया है; यहाँ मेरा प्रस्ताव है," जबकि दूसरा एक नई सुविधा के लिए एक बड़ा अंतर प्रस्तुत करेगा. प्रत्येक को ध्यान, फ़ीडबैक, और रिव्यु की आवश्यकता थी. यह एक टेक लीड होने जैसा था, जिसमें कई नए इंजीनियर थे, सभी प्रगति कर रहे थे और सभी को मार्गदर्शन की जरूरत थी.

परिणाम एक सहयोगात्मक प्रवाह था. Codex की मूल कोडिंग क्षमता ने हमें बहुत से मैनुअल टाइपिंग से मुक्त कर दिया. हमारे पास आर्किटेक्चर के बारे में सोचने, पुल अनुरोधों को ध्यान से पढ़ने और ऐप का परीक्षण करने के लिए अधिक समय था. 

उसी समय, अतिरिक्त गति का मतलब था कि हमारी रिव्यु कतार में हमेशा कुछ न कुछ प्रतीक्षा कर रहा होता था. Codex को कॉन्टेक्स्ट स्विचिंग से कोई बाधा नहीं हुई, लेकिन हमें हुई. हमारे विकास में बाधा कोड लिखने से निर्णय लेने, फ़ीडबैक देने और बदलावों को एकीकृत करने की ओर स्थानांतरित हो गई है.

यह वह जगह है जहाँ ब्रूक्स की अंतर्दृष्टियाँ एक नए तरीके से सामने आती हैं. तुम कोडेक्स सेशन जोड़कर रैखिक गति की उम्मीद नहीं कर सकते, जैसे तुम प्रोजेक्ट में इंजीनियर जोड़ते रहो और उम्मीद करो कि शेड्यूल रैखिक रूप से घट जाएगा. प्रत्येक अतिरिक्त "हाथों की जोड़ी," भले ही वे वर्चुअल हों, समन्वय का अतिरिक्त बोझ बढ़ाती है. हम ऑर्केस्ट्रा के संचालक बन गए थे, न कि केवल तेज़ एकल खिलाड़ी.

हमने अपने प्रोजेक्ट की शुरुआत एक बड़े मील के पत्थर से की: Sora पहले से ही iOS पर उपलब्ध था. हमने अक्सर Codex को iOS और बैकएंड कोडबेस की ओर निर्देशित किया ताकि वह प्रमुख आवश्यकताओं और बाधाओं को समझ सके. प्रोजेक्ट के दौरान हम मजाक में कहते थे कि हमने एक क्रॉस-प्लेटफॉर्म फ्रेमवर्क के विचार को फिर से आविष्कृत कर दिया है. React Native या Flutter को भूल जाओ; क्रॉस-प्लेटफॉर्म का भविष्य केवल Codex है.

मज़ाक के पीछे दो सिद्धांत छिपे हैं:.

1. लॉजिक पोर्टेबल है. चाहे कोड Swift में लिखा गया हो या Kotlin में, अंतर्निहित ऐप्लिकेशन लॉजिक – डेटा मॉडल, नेटवर्क कॉल्स, वैलिडेशन नियम, Business लॉजिक – समान होते हैं. Codex Swift इम्प्लीमेंटेशन को पढ़ने और अर्थ को बनाए रखते हुए Kotlin में समकक्ष उत्पन्न करने में बहुत अच्छा है.
2. ठोस उदाहरण शक्तिशाली कॉन्टेक्स्ट प्रदान करते हैं. एक नया Codex सेशन जो "यहाँ iOS पर यह कैसे काम करता है" और "यहाँ Android आर्किटेक्चर है" देख सकता है, केवल प्राकृतिक भाषा विवरणों से काम करने वाले सत्र की तुलना में कहीं अधिक प्रभावी है.

इन सिद्धांतों को लागू करते हुए, हमने iOS, बैकएंड और Android रिपॉजिटरी को एक ही वातावरण में उपलब्ध कराया. हमने Codex को इस तरह के प्रॉम्प्ट्स दिए:

iOS कोड में इन मॉडल और एंडपॉइंट को पढ़ो और फिर हमारे मौजूदा API क्लाइंट और मॉडल क्लासेस का उपयोग करके Android पर समान व्यवहार को लागू करने के लिए एक योजना प्लॉन प्रस्तावित करो.

एक छोटा लेकिन उपयोगी ट्रिक यह था कि ~/.codex/एजेंट.md में विस्तार से बताया जाए कि स्थानीय रिपॉजिटरी कहाँ स्थित हैं और उनमें क्या शामिल है. इससे Codex के लिए प्रासंगिक कोड को खोजने और नेविगेट करना आसान हो गया.

हम अनुवाद के माध्यम से साझा अमूर्तता के बजाय प्रभावी रूप से क्रॉस-प्लेटफ़ॉर्म विकास कर रहे थे. क्योंकि Codex ने अधिकांश अनुवाद संभाला, हम कार्यान्वयन लागत को दोगुना करने से बच गए.

मुख्य सबक यह है कि Codex के लिए, कॉन्टेक्स्ट ही सब कुछ है. Codex ने अपना सबसे अच्छा काम तब किया जब उसने समझा कि iOS में फीचर पहले से कैसे काम करता है, और साथ ही यह भी समझा कि हमारा Android ऐप कैसे संरचित है. जब Codex के पास वह कॉन्टेक्स्ट नहीं था, तो वह "सहयोग करने से इनकार" नहीं कर रहा था; वह अनुमान लगा रहा था. जितना अधिक हमने इसे एक नए टीममेट की तरह समझा और इसे सही इनपुट देने में निवेश किया, उतना ही बेहतर यह प्रदर्शन करता गया.

हमारे चार-सप्ताह के स्प्रिंट के अंत तक, Codex का उपयोग करना एक प्रयोग जैसा नहीं रहा और यह हमारे डिफ़ॉल्ट विकास चक्र बन गया. हमने मौजूदा कोड को समझने, बदलावों की प्लॉन बनाने और फीचर्स को लागू करने के लिए इसका उपयोग किया. हमने इसके आउटपुट की समीक्षा उसी तरह की जैसे हम एक टीममेट की रिव्यु करते. यह बस हमारा सॉफ़्टवेयर वितरित करने का तरीका था.

यह स्पष्ट हो गया कि AI-सहायता प्राप्त विकास कठोरता की आवश्यकता को कम नहीं करता; बल्कि इसे बढ़ाता है. Codex जितना सक्षम है, उसका उद्देश्य अभी A से B तक पहुंचना है. यही कारण है कि AI-सहायता प्राप्त कोडिंग इंसानों के बिना काम नहीं करती. सॉफ्टवेयर इंजीनियर सिस्टम की असल दुनिया की सीमाओं को समझ सकते हैं और उन्हें लागू कर सकते हैं, सॉफ्टवेयर को आर्किटेक्ट करने के सबसे अच्छे तरीके जान सकते हैं, और भविष्य के डेवलपमेंट और प्रोडक्ट प्लान को ध्यान में रखकर कैसे बनाना है, यह भी सीख सकते हैं. भविष्य के सॉफ़्टवेयर इंजीनियर की असली ताकत गहरी प्रणालीगत समझ और लंबे समय तक AI के साथ मिलकर काम करने की क्षमता होगी. 

सॉफ़्टवेयर इंजीनियरिंग के सबसे दिलचस्प हिस्से हैं आकर्षक उत्पाद बनाना, स्केलेबल सिस्टम डिज़ाइन करना, जटिल एल्गोरिदम लिखना, और डेटा, पैटर्न और कोड के साथ प्रयोग करना. हालांकि, सॉफ्टवेयर इंजीनियरिंग के अतीत और वर्तमान की असलियतें अक्सर ज़्यादा सामान्य होती हैं: बटन को सेंटर करना, एंडपॉइंट्स को वायर करना, और बॉयलरप्लेट लिखना. अब, Codex सॉफ़्टवेयर इंजीनियरिंग के सबसे महत्वपूर्ण हिस्सों पर ध्यान केंद्रित करना और हमारे शिल्प के प्रति हमारे प्रेम के रीज़न को संभव बनाता है.

एक बार Codex को एक कॉन्टेक्स्ट-समृद्ध वातावरण में सेट कर दिया जाता है जहाँ यह आपके लक्ष्यों और आपकी निर्माण शैली को समझता है, तो कोई भी Team अपनी क्षमताओं को कई गुना बढ़ा सकती है. हमारा लॉन्च रेट्रो कोई ऐसा नुस्खा नहीं है जो सभी के लिए उपयुक्त हो, और हम यह दावा नहीं कर रहे हैं कि हमने AI-सहायता प्राप्त विकास को पूरी तरह से हल कर लिया है. लेकिन हमें उम्मीद है कि हमारा अनुभव कोडेक्स को आपको सशक्त बनाने के सर्वोत्तम तरीकों को खोजने में मदद करेगा. 

जब Codex ने सात महीने पहले एक शोध प्रीव्यू करें में लॉन्च किया था, तब सॉफ़्टवेयर इंजीनियरिंग बहुत अलग दिखती थी. Sora के माध्यम से, हमने इंजीनियरिंग के आगे के अध्याय का एक्स्प्लोर किया. जैसे-जैसे हमारे मॉडल और हार्नेस में सुधार होता जाएगा, AI निर्माण का एक अनिवार्य हिस्सा बनता जाएगा. 

तुम अपनी खुद की Codex Team के साथ क्या बनाओगे?