Test-Oriented Programming: rethinking coding for the GenAI era
यह शोध पत्र "टेस्ट-ओरिएंटेड प्रोग्रामिंग" (TOP) का प्रस्ताव करता है, जो एक नया प्रतिमान (पैराडाइम) है जहाँ डेवलपर्स उत्पादन कोड जनरेशन को AI को सौंपते हुए प्राकृतिक भाषा विनिर्देशों के आधार पर LLM-जनित टेस्ट कोड को सत्यापित करने पर ध्यान केंद्रित करते हैं, और एक प्रूफ-ऑफ-कॉन्सेप्ट टूल के माध्यम से इस दृष्टिकोण को मान्य करता है जो पहचाने गए चुनौतियों के साथ उत्साहजनक परिणाम प्रदर्शित करता है।
मूल पेपर CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/) के तहत लाइसेंस किया गया है। नीचे दिए गए पेपर की यह व्याख्या AI से तैयार की गई है। इसे लेखकों ने न तो लिखा है, न इसका समर्थन किया है। तकनीकी सटीकता के लिए मूल पेपर देखें। पूरा डिस्क्लेमर पढ़ें
कल्पना कीजिए कि आप एक विशाल ऑर्केस्ट्रा के कंडक्टर हैं। पुराने दिनों में, आपको हर वायलिन, ट्रम्पेट और ड्रम के लिए हर एक नोट खुद लिखना पड़ता था। आधुनिक "ऑटो-कम्प्लीट" टूल्स (जैसे GitHub Copilot) के बावजूद, आप अभी भी शीट म्यूजिक ही लिख रहे थे, बस थोड़ा तेज़ी से। आप अभी भी संगीतकार (कंपोजर) ही थे।
यह पेपर ऑर्केस्ट्रा चलाने के एक क्रांतिकारी नए तरीके का प्रस्ताव देता है, जिसे टेस्ट-ओरिएंटेड प्रोग्रामिंग (TOP) कहा जाता है।
यहाँ इसका सरल विवरण दिया गया है जो लेखक, जॉर्ज मेलेगाटी (Jorge Melegati) सुझा रहे हैं:
1. बड़ा विचार: निर्देशक बनें, संगीतकार नहीं
जेनरेटिव एआई (GenAI) के इस नए युग में, लेखक का तर्क है कि हमें स्वयं कोड (संगीत के नोट्स) लिखना बंद कर देना चाहिए। इसके बजाय, हमें केवल उन नियमों को लिखना चाहिए कि संगीत कैसा सुनाई देना चाहिए।
- पुराना तरीका: आप एआई को कहते हैं, "दो संख्याओं को जोड़ने के लिए एक फंक्शन लिखें।" एआई कोड लिखता है, और आप उसकी जांच करते हैं।
- नया तरीका (TOP): आप एआई को कहते हैं, "मुझे दो संख्याओं को जोड़ने वाला एक फंक्शन चाहिए। यहाँ एक टेस्ट है: यदि मैं 2 और 2 टाइप करता हूँ, तो परिणाम 4 होना चाहिए। यदि मैं 5 और 5 टाइप करता हूँ, तो परिणाम 10 होना चाहिए।"
- जादू: इसके बाद एआई स्वचालित रूप से वह वास्तविक कोड लिखता है ताकि यह सुनिश्चित हो सके कि वे टेस्ट पास हो जाएं। यदि कोड टेस्ट में फेल हो जाता है, तो एआई तब तक दोबारा प्रयास करता है जब तक कि वह काम न करने लगे।
उपमा: इसे एक कस्टम केक ऑर्डर करने की तरह समझें।
- पुराना तरीका: आप बेकर को एक रेसिपी देते हैं और देखते हैं कि वे आटा और चीनी कैसे मिला रहे हैं, और अगर वे अंडा गिरा दें तो उन्हें सुधारते हैं।
- TOP तरीका: आप बेकर को उस केक की एक फोटो देते हैं जैसा आप चाहते हैं और स्वाद के परीक्षणों (टेस्ट) की एक सूची देते हैं ("यह मीठा होना चाहिए," "यह चॉकलेट वाला होना चाहिए")। बेकर (एआई) केक बनाता है। आप मिक्सिंग बाउल को नहीं छूते; आप बस केक चखते हैं यह देखने के लिए कि क्या यह आपकी फोटो से मेल खाता है। यदि नहीं, तो आप बेकर को बताते हैं, "बहुत सूखा है," और वे इसे ठीक करते हैं।
2. "नेचुरल लैंग्वेज" (प्राकृतिक भाषा) के साथ समस्या
आप पूछ सकते हैं, "क्यों न हम एआई को साधारण अंग्रेजी में ठीक-ठीक बता दें कि क्या करना है?"
समस्या यह है कि मानवीय भाषा अस्पष्ट होती है। यदि आप कहते हैं, "एक तेज़ कार बनाओ," तो एआई एक फेरारी बना सकता है या एक रेस कार, या शायद सिर्फ एक खिलौना कार। यह संदिग्ध है।
पारंपरिक प्रोग्रामिंग में, हम इसे टेस्ट्स (Tests) के माध्यम से हल करते हैं। टेस्ट एक सख्त चेकलिस्ट की तरह होते हैं। वे अस्पष्टता को दूर करते हैं।
- बदलाव: लेखक का सुझाव है कि भविष्य में जो "कोड" हम लिखेंगे, वह स्वयं सॉफ्टवेयर नहीं होगा, बल्कि वे टेस्ट्स होंगे जो यह साबित करते हैं कि सॉफ्टवेयर काम कर रहा है। एआई वह फैक्ट्री बन जाता है जो आपके टेस्ट पास करने के लिए सॉफ्टवेयर बनाता है।
3. प्रयोग: "अनियन" (Onion)
यह साबित करने के लिए कि यह काम करता है, लेखक ने Onion नामक एक टूल बनाया।
- इसने क्या किया: उन्होंने अनियन को एक टूल (किताब के संदर्भों को प्रबंधित करने के लिए एक कमांड-लाइन ऐप) का सरल विवरण और टेस्ट की एक सूची दी (जैसे, "जब मैं 'Harry' खोजूँ, तो इसे 'Harry Potter' दिखाना चाहिए")।
- परिणाम: एआई ने वास्तविक प्रोग्राम का एक भी लाइन लिखे बिना पूरा प्रोग्राम सफलतापूर्वक बना लिया। इंसान ने केवल टेस्ट्स की जांच की।
4. रुकावटें (चुनौतियां)
भले ही यह काम कर गया, लेकिन लेखक को तीन मुख्य बाधाएं मिलीं:
- "बहुत अधिक कागजी कार्रवाई" की समस्या: एआई ने बहुत सारा टेस्ट कोड जेनरेट किया। यह ऐसा है जैसे बेकर आपको एक 50 पन्नों की रिपोर्ट दे रहा हो कि उन्होंने केक का स्वाद कैसे लिया। एक इंसान के लिए उस सभी टेस्ट कोड को पढ़ना और सत्यापित करना थका देने वाला है। हमें एआई के "स्वाद परीक्षणों" को पढ़ने में मदद करने के लिए बेहतर टूल्स की आवश्यकता है।
- "रैंडमनेस" (अनिश्चितता) की समस्या: एआई मॉडल पूरी तरह से अनुमानित नहीं होते हैं। यदि आप एक ही एआई को दो बार एक ही चीज़ बनाने के लिए कहते हैं, तो वह इसे थोड़ा अलग बना सकता है (जैसे एक शेफ दूसरी बार थोड़ा अधिक नमक डाल देता है)। यह गारंटी देना कठिन बनाता है कि परिणाम हमेशा एक जैसा ही रहेगा।
- "स्टाइल" (शैली) की समस्या: अलग-अलग एआई मॉडल अलग-अलग तरह से कोड लिखते हैं। एक मॉडल (GPT-4o) छोटा और सटीक कोड लिखता है। दूसरा मॉडल (Gemini) बहुत सारे कमेंट्स के साथ लंबा और विस्तृत कोड लिखता है। यह एक वास्तुकार द्वारा एक सरल स्केच बनाने और दूसरे द्वारा इमारत के बारे में उपन्यास लिखने जैसा है। यह विसंगति भ्रमित करने वाली हो सकती है।
निष्कर्ष
यह पेपर सुझाव देता है कि हम उस युग से जा रहे हैं जहाँ इंसान कोड लिखते थे, उस युग में जहाँ इंसान आवश्यकताओं को परिभाषित करते हैं और टेस्ट्स को सत्यापित करते हैं, जबकि एआई सॉफ्टवेयर बनाने का भारी काम करता है।
यह एक ईंट जोड़ने वाले (हर ईंट को बिछाने वाले) से एक वास्तुकार (ब्लूप्रिंट बनाना और यह जांचना कि इमारत खड़ी रहती है या नहीं) बनने की ओर बदलाव है। यह सॉफ्टवेयर विकास को तेज़ और अधिक अमूर्त (abstract) बनाने का वादा करता है, लेकिन हमें अभी भी एआई की विचित्रताओं और उसके द्वारा उत्पादित टेस्ट डेटा की विशाल मात्रा को प्रबंधित करने के तरीके खोजने की आवश्यकता है।
अपने क्षेत्र के पेपरों की भीड़ में उलझे हुए हैं?
आपके रिसर्च कीवर्ड से मेल खाने वाले सबसे नए और अलग सोच वाले पेपरों का रोज़ाना Digest पाएँ—तकनीकी सारांश के साथ, आपकी भाषा में।