वर्षों से, आर्टिफिशियल इंटेलिजेंस आपके एडिटर में आपके साथ बैठा रहता था और अनुमान लगाता था कि आगे क्या आएगा। आपने एक लाइन लिखी; इसने अगली लाइन का सुझाव दिया। आर्किटेक्चर, डिबगिंग और सिंटैक्स पर अभी भी आपका नियंत्रण था। वह व्यवस्था अब समाप्त हो चुकी है।
हम Intent-Driven Development की ओर बढ़ रहे हैं। आप लूप्स (loops) और कंडीशन्स (conditionals) टाइप करना बंद कर देते हैं। इसके बजाय, आप उस परिणाम का वर्णन करते हैं जिसकी आपको आवश्यकता है। एक एजेंट उस लक्ष्य को समझता है, चरणों की योजना बनाता है, कोड लिखता है, टेस्ट चलाता है, और आपके परिणाम देखने से पहले ही अपनी गलतियों को सुधार लेता है। कीबोर्ड अब प्राथमिक उपकरण नहीं रह गया है। स्पष्ट सोच (Clear thinking) अब मुख्य उपकरण है।
लाइन-दर-लाइन कोडिंग का अंत
पुराने वर्कफ़्लो में आपको अपनी हर मंशा को एक विशिष्ट भाषा में अनुवाद करने के लिए मजबूर होना पड़ता था जिसे कंपाइलर समझ सके। आप बिजनेस रिक्वायरमेंट को अपने दिमाग में रखते थे, और फिर उसे मैन्युअल रूप से फंक्शन्स, इम्पोर्ट्स, एरर हैंडलिंग और टेस्ट केसेस में विभाजित करते थे। Intent-Driven Development उस ट्रांसलेशन लेयर को खत्म कर देता है।
मान लीजिए आपको एक पेमेंट वेबहुक (payment webhook) को इंटीग्रेट करने की आवश्यकता है। पहले, आप रूट हैंडलर लिखते, पेलोड को पार्स करते, सिग्नेचर को वैलिडेट करते, ट्रांजेक्शन के भीतर डेटाबेस को अपडेट करते और रसीद ईमेल को कतार (queue) में डालते। अब आप आवश्यकता का वर्णन करते हैं: “आने वाले Stripe webhook को वैलिडेट करें, इवेंट को idempotently रिकॉर्ड करें, और रसीद फ्लो को ट्रिगर करें। यदि डेटाबेस राइट विफल हो जाता है, तो रोल बैक करें।” एजेंट हैंडलर लिखता है, पार्सिंग स्ट्रैटेजी चुनता है, रिट्राय लॉजिक (retry logic) तैयार करता है और टेस्ट जेनरेट करता है। आपकी भूमिका लेखक से बदलकर निर्देशक (director) की हो जाती है।
यह केवल इसलिए काम करता है क्योंकि एजेंट केवल कोड जेनरेट करने पर नहीं रुकता। यह एक लूप में प्रवेश करता है।
एजेंट लूप के भीतर
मुख्य काम अब इंसानी टाइपिंग या मैन्युअल डिबगिंग नहीं रह गया है। यह जनरेशन और वैलिडेशन के बीच का एक निरंतर चक्र है। एजेंट कोड बनाता है, उसे आपके टेस्ट सूट के खिलाफ चलाता है, आउटपुट पढ़ता है, और अपनी गलतियों को खुद ठीक करता है। एक मिसिंग इम्पोर्ट, टाइप मिसमैच, या फेल होता हुआ एसर्शन (assertion) — एजेंट स्टैक ट्रेस (stack trace) देखता है, फ़ाइल को एडिट करता है, और सूट को फिर से चलाता है। आप उस लूप में नहीं होते। यह चक्र मशीन की गति से चलता है।
आप तब हस्तक्षेप करते हैं जब लूप खुद टूट जाता है। शायद एजेंट दो डिपेंडेंसीज़ के बीच संघर्ष (conflict) को हल नहीं कर पाता, या वह ऐसा कोड जेनरेट करता रहता है जो यूनिट टेस्ट तो पास कर लेता है लेकिन उच्च-स्तरीय बिजनेस नियम का उल्लंघन करता है। वे सीमाएँ ही हैं जहाँ मानवीय निर्णय (human judgment) अभी भी मायने रखता है।
आपका असली काम: कंस्ट्रेंट डिज़ाइनर और एज-केस हंटर
यदि मशीन फंक्शन्स लिखती है, तो आपके लिए क्या बचता है? दो चीजें, और वे सिंटैक्स टाइप करने से कहीं अधिक कठिन हैं।
पहला, आप वे कंस्ट्रेंट्स (constraints) लिखते हैं जो एजेंट को सही रास्ते पर रखते हैं। एजेंट के पास व्यापक ज्ञान होता है लेकिन आपके विशिष्ट वातावरण (environment) की समझ नहीं होती। आपको उसे बताना होगा: “केवल इंटरनल बिलिंग API का उपयोग करें, कभी भी रॉ कार्ड टोकन लॉग न करें, और रिस्पॉन्स लेटेंसी को दो सौ मिलीसेकंड से कम रखें।” वे सीमाएँ केवल साधारण प्रॉम्प्ट्स नहीं हैं। वे वे स्पेसिफिकेशन हैं जो सफलता या विफलता निर्धारित करते हैं।
दूसरा, आप उन दस प्रतिशत मामलों को पकड़ते हैं जहाँ एजेंट विफल हो जाता है। एजेंट सामान्य रास्तों को अच्छी तरह से संभाल लेते हैं। वे सूक्ष्म रेस कंडीशंस (race conditions), अस्पष्ट बिजनेस लॉजिक एज-केस और अपने ट्रेनिंग डेटा में निहित सुरक्षा मान्यताओं (security assumptions) पर लड़खड़ा जाते हैं। आपकी विशेषज्ञता वेबहुक हैंडलर और रिफंड क्रॉन जॉब (refund cron job) के बीच की रेस को पहचानने, या यह समझने से आती है कि जेनरेट किया गया रिट्राय लॉजिक चार्जेस को डुप्लिकेट कर सकता है। मशीन मानक समस्या को हल करती है। आप खतरनाक अपवाद (exception) को पकड़ते हैं।
कोड रिव्यू को वेरिफिकेशन हार्नेस से बदलें
जब एक एजेंट रातों-रात पचास फाइलें तैयार कर सकता है, तो आप केवल यह देखने के लिए कि वे “सही दिख रही हैं,” डिफ्स (diffs) को सरसरी तौर पर देखकर उनकी समीक्षा नहीं कर सकते। फाइलों की भारी संख्या मानवीय निरीक्षण को असंभव बना देती है। आपको एक ऐसे हार्नेस की आवश्यकता है जो कोड आपके पास पहुँचने से पहले ही गलतियों को पकड़ ले।
यह हार्नेस तीन स्तंभों पर टिका है।
ड्यूरेबल एक्जीक्यूशन (Durable execution)। एजेंट टास्क अक्सर सिंगल रिक्वेस्ट टाइमआउट से अधिक समय तक चलते हैं। यदि किसी अस्थायी नेटवर्क समस्या के कारण कोई चरण विफल हो जाता है, तो हार्नेस रुक जाता है, पुन: प्रयास करता है, और स्टेट (state) को खराब किए बिना फिर से शुरू हो जाता है। काम बीच में रुकने के बावजूद सुरक्षित रहता है।
स्ट्रक्चर्ड आउटपुट (Structured outputs)। इस उम्मीद में रहने के बजाय कि एजेंट एक अच्छी तरह से बनी कॉन्फ़िगरेशन फ़ाइल लौटाएगा, आप पहले से ही कॉन्ट्रैक्ट लागू करते हैं। JSON Schema जैसे टूल तुरंत आउटपुट को वैलिडेट करते हैं। यदि एजेंट किसी आवश्यक फ़ील्ड को छोड़ देता है या गलत डेटा टाइप का उपयोग करता है, तो हार्नेस कोड के आपके रिपॉजिटरी तक पहुँचने से पहले ही उसे अस्वीकार कर देता है।
डायनेमिक गार्डरेल्स (Dynamic guardrails)। एजेंट को सीक्रेट्स पढ़ने या प्रोडक्शन डेटाबेस में लिखने की पूरी छूट नहीं होनी चाहिए। हार्नेस गतिशील रूप से अनुमतियों (permissions) को नियंत्रित करता है, एजेंट को सैंडबॉक्स (sandboxing) करता है ताकि वह केवल निर्दिष्ट टेस्ट डेटाबेस और इंटरनल एंडपॉइंट्स को ही छू सके। आप हर लाइन की समीक्षा नहीं कर रहे हैं। आप एजेंट के चारों ओर बनी बाड़ (fence) का ऑडिट कर रहे हैं।
जब कोड काम करता है लेकिन उत्पाद विफल हो जाता है
यहाँ एक विरोधाभास है। हार्नेस खराब कोड को पकड़ लेता है, लेकिन खराब इरादे (intent) को नहीं।
यदि आपका स्पेसिफिकेशन कहता है, “प्रत्येक नए उपयोगकर्ता को एक स्वागत ईमेल भेजें,” तो एजेंट एक साफ, टेस्ट किया हुआ कोड लिखेगा जो वह ईमेल भेज देगा। उसे यह पता नहीं चलेगा कि आपका मतलब था, “स्वागत ईमेल केवल तभी भेजें जब उपयोगकर्ता ने अपना पता सत्यापित कर लिया हो, मार्केटिंग के लिए सहमति दी हो, और अपने स्थानीय टाइमज़ोन में व्यावसायिक घंटों के दौरान साइन अप किया हो।” कोड तकनीकी रूप से त्रुटिहीन है लेकिन व्यावसायिक रूप से खतरनाक है।
Intent-Driven Development में वास्तविक जोखिम अस्पष्ट स्पेसिफिकेशन है। अस्पष्ट इरादा ऐसा सॉफ्टवेयर तैयार करता है जो किताबी सटीकता के साथ गलत समस्या का समाधान करता है। यही कारण है कि आपको अपने स्पेसिफिकेशन को वास्तविक संपत्ति (assets) के रूप में मानना चाहिए। उनका वर्जन बनाएँ। हितधारकों (stakeholders) के साथ उनकी समीक्षा करें। एजेंट द्वारा निर्माण शुरू करने से पहले वास्तविक वर्कफ़्लो के आधार पर उन्हें सत्यापित करें। चैट बॉक्स में लिखा गया एक प्रॉम्प्ट स्पेसिफिकेशन नहीं है। यह एक देनदारी (liability) है।
इंजीनियरिंग जजमेंट अब अपस्ट्रीम की ओर बढ़ रहा है
इंजीनियरिंग जजमेंट गायब नहीं हो रहा है। यह एक उच्च स्तर पर स्थानांतरित हो रहा है।
अब आप इस बात पर मानसिक ऊर्जा खर्च नहीं करते कि मैप को कैसे इटरेट किया जाए या क्लास पदानुक्रम (class hierarchy) को कैसे स्ट्रक्चर किया जाए। आप इसे इस बात पर खर्च करते हैं कि विफलता (failure) की स्थिति में सिस्टम को क्या करना चाहिए, उसे कौन सा डेटा कभी उजागर नहीं करना चाहिए, और डिस्ट्रीब्यूटेड सर्विसेज में कौन से इनवेरिएंट्स (invariants) बने रहने चाहिए। कोडिंग की कला अब आवश्यकताओं (requirements) की कला बनती जा रही है।
इसका मतलब है कि आपके स्पेसिफिकेशन को उसी सटीकता की आवश्यकता है जो आप कभी अपने कोड पर लागू करते थे। अपने कन्स्ट्रेंट्स (constraints) को सटीक रूप से नाम दें। फेलियर मोड (failure modes) को स्पष्ट रूप से परिभाषित करें। बिजनेस रूल्स को उतनी ही स्पष्टता से बताएं जितनी स्पष्टता से आप कभी अपने टाइप्स (types) घोषित करते थे। एजेंट इम्प्लीमेंटेशन को संभालेगा। आपको यह गारंटी देनी होगी कि वह इम्प्लीमेंटेशन बनाने लायक है।
अपनी क्वालिटी बार को पुल रिक्वेस्ट से हटाकर प्रॉम्प्ट पर ले आएं। पहले हार्नेस बनाएं। दूसरा, स्पेसिफिकेशन लिखें। फिर मशीन को सिंटैक्स संभालने दें, जबकि आप इस बात पर ध्यान केंद्रित करें कि क्या समस्या को सही ढंग से परिभाषित किया गया है और क्या सीमाएं सुरक्षित रूप से खींची गई हैं।
यदि आप इस बदलाव के पीछे के विचारों को और गहराई से समझना चाहते हैं, तो Intent-Driven Development पर मूल चर्चा यहाँ उपलब्ध है। AI-native इंजीनियरिंग के बारे में चल रही बातचीत के लिए, आप GyaanSetu community में भी शामिल हो सकते हैं।