संक्षेप में

प्राकृतिक भाषा, स्यूडोकोड और कोड एक-दूसरे से प्रतिस्पर्धा करने वाले साधन नहीं हैं। वे सटीकता के अलग-अलग स्तरों के लिए अलग भाषाएँ हैं।

एआई की सहायता से प्रोग्रामिंग के दौर में प्रोग्राम करना सीखने का मतलब केवल कोड की हर पंक्ति हाथ से लिखना नहीं है। इसका मतलब है यह जानना कि किसी विचार को कब अधिक सटीक बनाना है, उस रूपांतरण को कैसे नियंत्रित करना है और मनुष्य द्वारा लिए गए निर्णयों तथा एआई प्रणाली द्वारा पूरे किए गए निर्णयों में अंतर कैसे करना है।

Richard Feynman का एक कथन

यह समझने के लिए कि एआई आने से प्रोग्रामिंग समाप्त क्यों नहीं हो जाती, एक अधिक सामान्य अंतर से शुरुआत करना उपयोगी है: स्पष्टता और सटीकता के बीच का अंतर।

Richard Feynman ने गणित के बारे में बात करते हुए यह विचार समझाया था:

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

वास्तव में किसी भी बात को पूरी तरह सटीक कहना लगभग असंभव है, जब तक वह बात वास्तविक दुनिया से इतनी अलग न कर दी गई हो कि वह किसी वास्तविक चीज़ का प्रतिनिधित्व ही न करे। शुद्ध गणित वास्तविक दुनिया से ऐसा ही अमूर्तन है और उसके विशेष तकनीकी विषयों के लिए उसकी अपनी विशेष सटीक भाषा है।

लेकिन जब आप दुनिया की वास्तविक वस्तुओं की बात करते हैं, तो यह सटीक भाषा किसी अर्थ में सटीक नहीं रहती। जब तक कुछ विशेष बारीकियों को सावधानी से अलग करना ज़रूरी न हो, इसका उपयोग केवल दिखावटी विद्वत्ता और काफी भ्रम पैदा करता है।

दिलचस्प बात यह है कि Feynman गणित की आलोचना नहीं कर रहे हैं। वे इस विचार की आलोचना कर रहे हैं कि अधिक औपचारिकता का अर्थ हमेशा अधिक समझ होता है।

उनकी बात सरल है:

  • स्पष्टता सटीकता से अधिक महत्वपूर्ण है;
  • सटीकता केवल वहीं जोड़नी चाहिए जहाँ वास्तव में अस्पष्टता हो;
  • शुद्ध गणित पूरी तरह सटीक हो सकता है, क्योंकि वह गणित द्वारा परिभाषित अमूर्त अवधारणाओं से संबंधित है;
  • वास्तविक दुनिया की बात करते समय अनुमान, मान्यताएँ और अधूरी परिभाषाएँ हमेशा होती हैं।

हालाँकि Feynman गणित की बात कर रहे थे, यह अंतर प्रोग्रामिंग के बारे में सोचने के लिए भी उपयोगी है। इसलिए नहीं कि प्रोग्रामिंग शुद्ध गणित जैसी है, बल्कि इसलिए कि जहाँ प्राकृतिक भाषा बहुत अस्पष्ट होती है, वहाँ प्रोग्रामिंग भी औपचारिक सटीकता लाती है।

इस लेख का मुख्य विचार यह है:

प्रोग्राम करना सीखना अब भी महत्वपूर्ण है, क्योंकि कठिन समस्या केवल कोड बनाना नहीं है। कठिन समस्या एक अस्पष्ट मानवीय उद्देश्य और ऐसे औपचारिक सिस्टम के बीच रूपांतरण को नियंत्रित करना है जो सामान्य समझ के बिना निर्देशों को क्रियान्वित करता है।

लोगों की भाषा और कंप्यूटर की भाषा

प्रोग्रामिंग किसी प्रक्रिया को बताने का तरीका है। यह मशीन को बताने का तरीका है कि हम उससे क्या करवाना चाहते हैं।

CPU, यानी सेंट्रल प्रोसेसिंग यूनिट, अंग्रेज़ी, स्पैनिश, Python या C++ को मनुष्य की तरह नहीं समझता। सबसे निचले स्तर पर वह बहुत सरल निर्देश चलाता है: संख्याएँ पढ़ना, उनकी तुलना करना, उन्हें जोड़ना, मेमोरी में डेटा एक जगह से दूसरी जगह कॉपी करना और एक निर्देश से दूसरे निर्देश पर जाना।

प्रोग्रामिंग भाषाएँ प्रक्रियाओं का वर्णन करने के लिए मनुष्यों के अनुकूल परत हैं। बाद में उन प्रक्रियाओं को समझा या कम्पाइल करके ऐसे निर्देश बनाया जाता है जिन्हें मशीन चला सकती है।

प्राकृतिक भाषा में ऐसा वाक्य:

ताश की इस गड्डी को क्रम में लगाओ।

कई बातें समझने वाले की व्याख्या पर छोड़ देता है।

इसमें माना जाता है कि निर्देश पाने वाला जानता है कि ताश का पत्ता क्या है, क्रम में लगाने का अर्थ क्या है, कौन सा क्रम अपनाना है, कौन से पत्ते दूसरों से बड़े हैं, पत्तों के रंग और चिह्न मायने रखते हैं या नहीं और कितना समय या प्रयास स्वीकार्य है।

प्रोग्रामिंग में इन निर्णयों को सिस्टम में कहीं परिभाषित करना आवश्यक है।

हम हमेशा हर विवरण हाथ से नहीं लिखते, क्योंकि हम ऐसी प्रोग्रामिंग भाषाएँ, लाइब्रेरी, फ़्रेमवर्क और अमूर्त संरचनाएँ इस्तेमाल करते हैं जिनमें बहुत से निर्णय पहले से शामिल होते हैं। लेकिन किसी स्तर पर किसी ने उन निर्णयों को सटीक रूप से परिभाषित किया है।

प्राकृतिक भाषा और प्रोग्रामिंग भाषाएँ एक ही चीज़ के बेहतर या बदतर रूप नहीं हैं। वे अलग साधन हैं। यह पूछना कि क्या एआई के कारण अब हमें प्रोग्रामिंग सीखने की ज़रूरत नहीं है, कुछ वैसा है जैसे पूछना कि आवर्धक काँच इस्तेमाल करना आने पर क्या हमें सूक्ष्मदर्शी का उपयोग समझने की ज़रूरत नहीं रहती।

सॉफ़्टवेयर कंपनी में सॉफ़्टवेयर कैसे बनाया जाता है

सॉफ़्टवेयर कंपनी में लगभग सब कुछ प्राकृतिक भाषा से शुरू होता है।

ग्राहक बताता है कि उसे क्या चाहिए:

मुझे ऑर्डर सँभालने के लिए एक ऐप चाहिए।

या:

मुझे उत्पाद बेचने के लिए एक वेबसाइट चाहिए।

या:

मुझे अपॉइंटमेंट सँभालने के लिए एक सिस्टम चाहिए।

वह पहला विवरण शायद ही कभी सटीक होता है। इसलिए नहीं कि ग्राहक ठीक से बता नहीं पा रहा, बल्कि इसलिए कि वह अपने क्षेत्र का बहुत सा ज्ञान कुछ वाक्यों में समेटने की कोशिश कर रहा है।

उस ज्ञान में आदतें, अपवाद, व्यवसाय के नियम, पसंद, असामान्य स्थितियाँ, पहले की समस्याएँ और अनकहे निर्णय शामिल हो सकते हैं।

इसीलिए बीच की परतें होती हैं।

उत्पाद प्रबंधक, व्यवसाय विश्लेषक या कार्यात्मक विश्लेषक ग्राहक से बात करता है, सवाल पूछता है, अस्पष्टताएँ पहचानता है और शुरुआती माँग को अधिक स्पष्ट आवश्यकताओं में बदलता है।

फिर तकनीकी प्रमुख, आर्किटेक्ट या प्रोग्रामर उन आवश्यकताओं को क्रमशः अधिक विशिष्ट तकनीकी निर्णयों में बदलता है, जब तक आखिर में कोड तैयार नहीं हो जाता।

हर परत समस्याएँ खोज सकती है या बदलाव सुझा सकती है। लेकिन किसी परत को ऊपर के स्तर पर लिया गया निर्णय चुपचाप बदलना नहीं चाहिए।

अगर प्रोग्रामर को विरोधाभास मिले, तो उसे सामने लाना चाहिए। अगर उत्पाद प्रबंधक किसी आवश्यकता को नए शब्दों में लिखे, तो उसका संबंध ग्राहक की मूल माँग से पता चलना चाहिए।

किसी विचार को कोड में बदलने के तीन तरीके

अगला चित्र तीन कार्यप्रवाहों की तुलना करता है: पारंपरिक सॉफ़्टवेयर विकास, LLM से सीधे कोड बनाना और बीच में एक स्पष्ट परत वाला प्रस्तावित कार्यप्रवाह।

पारंपरिक प्रक्रिया

ग्राहक
↓
विश्लेषक / उत्पाद प्रबंधक
↓
तकनीकी प्रमुख
↓
प्रोग्रामर
↓
कोड

पद्धति के बिना LLM

उपयोगकर्ता
↓
प्रॉम्प्ट
↓
LLM
↓
कोड

Black Box Approach

उपयोगकर्ता
↓
प्राकृतिक भाषा
↓
स्यूडोकोड + बॉक्स
↓
कौशल द्वारा निर्देशित LLM
↓
स्रोत स्पष्ट रखने वाला कोड

जब कोई व्यक्ति कोड बनाने के लिए LLM इस्तेमाल करता है, तो क्या होता है?

जब कोई व्यक्ति कोड बनाने के लिए सीधे LLM से संवाद करता है, तो बीच की परत पूरी तरह गायब नहीं होती। वह अप्रत्यक्ष हो जाती है।

मॉडल प्रॉम्प्ट की व्याख्या करता है, छूटे हुए विवरण भरता है, निर्देशों की प्राथमिकता तय करता है और कार्यान्वयन के निर्णय लेता है। लेकिन इनमें से बहुत से निर्णय किसी स्थायी जगह दर्ज नहीं होते।

इसीलिए एआई के कई कोडिंग साधनों में योजना मोड जैसी सुविधा होती है। विचार यह है कि मॉडल से लागू करने से पहले सोचने को कहा जाए।

समस्या यह है कि योजना अक्सर अस्थायी होती है। वह बातचीत में ही रह सकती है, अंतिम कोड से अलग हो सकती है या उपयोगकर्ता उसे अनदेखा कर सकता है।

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

सावधानी से विनिर्देश लिखे जाने पर भी समस्या समाप्त नहीं होती।

LLM को विरोधाभास मिल सकते हैं, वह खाली जगहें भर सकता है या ऐसे निर्णय ले सकता है जो आवश्यकताओं से ठीक मेल न खाते हों। कभी इसका कारण प्राकृतिक भाषा की अस्पष्टता होती है। कभी फ़ाइलें पढ़ने का क्रम कारण होता है। कभी निर्देशों में टकराव होता है। और कभी कारण यह है कि LLM संभाव्यता पर आधारित प्रणालियाँ हैं।

समस्या यह नहीं है कि LLM निर्णय लेता है।

समस्या यह न जानना है कि उसने कौन से निर्णय लिए, क्यों लिए और क्या वे मनुष्य द्वारा पहले लिए गए किसी निर्णय से टकराते हैं।

बीच की परत के रूप में स्यूडोकोड

स्यूडोकोड वह भूमिका निभा सकता है जो पारंपरिक सॉफ़्टवेयर विकास में अक्सर ग्राहकों, प्रबंधकों, आर्किटेक्ट और प्रोग्रामर के बीच बातचीत में बँटी होती है।

यह पूरी तरह प्राकृतिक भाषा नहीं है, क्योंकि इसकी संरचना होती है।

लेकिन यह चलने वाला कोड भी नहीं है, क्योंकि इसमें हम उद्देश्य, मॉड्यूल और ज़िम्मेदारियों के रूप में बात कर सकते हैं।

यह बीच की परत LLM के साथ खास तौर पर उपयोगी है, क्योंकि यह दो चरणों को अलग करती है जिन्हें अक्सर बहुत जल्दी मिला दिया जाता है:

  1. तय करना कि सिस्टम को क्या करना चाहिए;
  2. तय करना कि उसे कैसे लागू किया जाए।

उदाहरण के लिए:

IF user selects a subscription plan
  CALL create_checkout_session

IF payment succeeds
  CALL activate_subscription
  CALL send_confirmation_email
ELSE
  CALL show_payment_error

यह स्यूडोकोड अभी तय नहीं करता कि हम Stripe, Paddle, Mercado Pago, अपनी एपीआई या किसी खास लाइब्रेरी का उपयोग करेंगे।

लेकिन यह एक संरचना परिभाषित करता है:

  • एक योजना है;
  • भुगतान की प्रक्रिया का एक सत्र है;
  • सदस्यता सक्रिय करने का एक चरण है;
  • सफल भुगतान का एक रास्ता है;
  • त्रुटि का एक रास्ता है।

यह ऐसी अस्पष्ट माँग से पहले ही अधिक सटीक है:

ऐप में भुगतान जोड़ दो।

लेकिन यह अभी अंतिम कार्यान्वयन के कोड जितना कठोर नहीं है।

प्रस्ताव: Black Box Approach

प्रस्तावित पद्धति सरल है:

सिस्टम के हर हिस्से को ऐसे ब्लैक बॉक्स के रूप में देखें जिसे छोटे हिस्सों में बाँटकर बेहतर किया जा सके, जिसकी सीमाएँ स्पष्ट हों, जिसमें बीच का स्यूडोकोड हो और निर्णयों का स्रोत स्पष्ट हो।

हर ऐप प्रोजेक्ट को एक blackboxes/ फ़ोल्डर मिलता है जिसमें होते हैं:

  • YAML बॉक्स;
  • साझा डेटा संरचनाएँ;
  • स्पष्ट रूप से बुलाए जाने पर LLM को पालन करने के लिए एक कौशल फ़ाइल;
  • निर्णयों के स्रोत का रिकॉर्ड;
  • वैकल्पिक रूप से, बॉक्स का वृक्ष दिखाने वाला विज़ुअलाइज़र।

लक्ष्य कोड को हटाना नहीं है।

लक्ष्य है मानवीय उद्देश्य से कोड तक के रूपांतरण को दिखाई देने वाला, संपादन योग्य और जाँचने योग्य बनाना।

यह क्या हल करने की कोशिश करता है

1. मानवीय निर्णय और एआई के निर्णय

हर बॉक्स और डेटा फ़ील्ड अपने निर्णयों का स्रोत दर्ज करता है:

  • human_defined
  • ai_defined
  • mixed

मनुष्य द्वारा किसी बात की पुष्टि करने के बाद एआई उसे चुपचाप फिर से अनुमान नहीं बना सकता।

उदाहरण के लिए, अगर LLM Stripe इस्तेमाल करने का निर्णय ले, तो शुरुआत में उसे ai_defined के रूप में दर्ज किया जा सकता है।

अगर कोई मनुष्य उस निर्णय की पुष्टि करे, तो वह मनुष्य द्वारा अनुमोदित हो जाता है। उसके बाद मॉडल को Stripe की जगह दूसरा प्रदाता नहीं चुनना चाहिए, जब तक वह बदलाव स्पष्ट रूप से सामने न रखे।

2. बीच की परत के रूप में स्यूडोकोड

बॉक्स मिश्रित स्यूडोकोड इस्तेमाल करते हैं:

CALL create_checkout_session
IF payment succeeds
WHILE there are pending invoices

इससे सिस्टम को हिस्सों में बाँटने लायक संरचना मिलती है, लेकिन तैयार होने से पहले कार्यान्वयन के विवरण में डूब जाने जितनी संरचना नहीं होती।

3. मॉड्यूल की सीमाएँ

एक समय में एक ब्लैक बॉक्स को बेहतर बनाया जाता है।

ऊपर के बॉक्स केवल पढ़े जाने वाले संदर्भ हैं। केवल चुना गया उपवृक्ष बदल सकता है।

यह इसलिए महत्वपूर्ण है कि ऐसी माँग:

भुगतान का प्रवाह ठीक करो।

LLM को प्रमाणीकरण की परत, डेटाबेस का स्कीमा और सूचनाओं की प्रणाली दोबारा लिखने की अनुमति नहीं देनी चाहिए, जब तक उन बदलावों का संबंध स्पष्ट न हो और उन्हें स्वीकृति न मिली हो।

4. मनुष्यों के लिए समझने योग्य दृश्य

विज़ुअलाइज़र बॉक्स का वृक्ष दर्जनों बिखरी हुई विनिर्देश फ़ाइलों से कहीं सरल तरीके से दिखा सकता है।

उद्देश्य केवल दस्तावेज़ बनाना नहीं है। उद्देश्य निर्णयों की सीमाएँ बनाए रखना है।

एक छोटा उदाहरण

भुगतान के प्रवाह के ब्लैक बॉक्स का एक सरल उदाहरण यह है:

box: payment_flow
goal: allow the user to pay for a subscription
provenance: human_defined

inputs:
  - selected_plan
  - user_id

pseudocode:
  - IF user selects plan
  - CALL create_checkout_session
  - IF payment succeeds
  - CALL activate_subscription
  - ELSE show_error_message

decisions:
  payment_provider:
    value: Stripe
    provenance: ai_defined
    status: needs_human_confirmation

constraints:
  - Do not modify auth_flow without human approval
  - Do not store sensitive card data

दिलचस्प बात YAML खुद नहीं है।

दिलचस्प बात यह है कि हर निर्णय की जगह है। सिस्टम जानता है कि मनुष्य ने क्या तय किया है, एआई ने क्या अनुमान लगाया है और किस बात की पुष्टि अभी बाकी है।

बीच की परत नौकरशाही नहीं है। यह एआई को अस्पष्टता से ऐसे निर्णय बनाने से रोकने का तरीका है जो दिखाई न दें।

अब प्रोग्रामिंग सीखने का अर्थ क्या है?

शायद प्रोग्रामिंग सीखने का अर्थ अब सिंटैक्स याद करना या हर फ़ंक्शन शुरू से लिखना नहीं रह गया है।

शायद इसका अर्थ सटीकता के अलग-अलग स्तरों पर सोचना सीखना है।

इसका अर्थ है जानना कि प्राकृतिक भाषा कब पर्याप्त है, स्यूडोकोड कब चाहिए, चलने वाला कोड कब चाहिए और कब किसी निर्णय को दर्ज करना ज़रूरी है क्योंकि उसका प्रभाव पूरे सिस्टम पर पड़ेगा।

प्रोग्रामिंग सीखने से यह भी सीखा जाता है:

  • समस्याओं को हिस्सों में कैसे बाँटें;
  • असामान्य स्थितियों को कैसे पहचानें;
  • डेटा का मॉडल कैसे बनाएँ;
  • बनाए गए कोड को आलोचनात्मक ढंग से कैसे पढ़ें;
  • त्रुटियाँ कैसे खोजें और ठीक करें;
  • अलग विकल्पों के लाभ और नुकसान कैसे आँकें;
  • मेमोरी, विलंब, सुरक्षा, समवर्ती कार्य, अनुमतियों और लागत जैसी सीमाओं पर कैसे विचार करें।

एआई कोड बनाने की गति बहुत बढ़ा सकता है।

लेकिन एआई जितना अधिक कोड बनाता है, उसे पढ़ना, उस पर सवाल करना और जिन मानवीय निर्णयों को उसे लागू करना है, उनसे दोबारा जोड़ना उतना ही महत्वपूर्ण हो जाता है।

निष्कर्ष

“क्या हमें अब भी प्रोग्रामिंग सीखने की ज़रूरत है?” सवाल शायद सही ढंग से नहीं पूछा गया है।

अगर प्रोग्रामिंग का अर्थ सिंटैक्स याद करना और कोड की हर पंक्ति हाथ से लिखना है, तो समय के साथ हमें शायद ऐसा कम करना पड़ेगा।

लेकिन अगर प्रोग्रामिंग का अर्थ यह समझना है कि एक अस्पष्ट उद्देश्य निर्णय लेने और कार्य करने वाली औपचारिक प्रणाली में कैसे बदलता है, तो जवाब स्पष्ट रूप से हाँ है।

एआई कोड लिख सकता है।

लेकिन किसी को अब भी रूपांतरण नियंत्रित करना होगा।

और किसी रूपांतरण को नियंत्रित करने के लिए दोनों भाषाओं का कम से कम कुछ हिस्सा समझना ज़रूरी है।

इस लेख में बताया गया Black Box Approach एक अवधारणा-प्रमाण का प्रयोग है। github.com/amiune/theblackboxapproach