एआई डिज़ाइन प्राधिकरण

हम सॉफ्टवेयर विकास में एक महत्वपूर्ण मोड़ पर खड़े हैं। चर्चा अक्सर इस बारे में होती है कि कौन सा एआई सबसे अच्छा कोड लिखता है (क्लॉड बनाम चैटजीपीटी) या कहाँ उस एआई को कहाँ रहना चाहिए (आईडीई या सीएलआई)। लेकिन यह गलत चर्चा है।

असली समस्या यह नहीं है कि उत्पादन कोड की। असली समस्या यह है सत्यापन इसका।

जब हम एआई को "वाइब कोडर्स" के रूप में अपनाते हैं - जहाँ हम इरादा बताते हैं और एआई निष्पादन करता है - तो हम नए सॉफ्टवेयर की एक विशाल धारा बनाते हैं। एआई एजेंटों का एक झुंड एक मिनट में उससे अधिक कोड उत्पन्न कर सकता है जिसे एक वरिष्ठ डेवलपर एक सप्ताह में समीक्षा कर सकता है। इंसान बाधा बन गया है।

समाधान नहीं है अधिक इंसान। समाधान है एक एआई डिज़ाइन प्राधिकरण.

कारीगर से फैक्ट्री निदेशक तक

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

यदि हम "डिस्पोजेबल कोड" पर स्विच करते हैं - ऐसा सॉफ़्टवेयर जिसे हम अनिश्चित काल तक रिफैक्टर नहीं करते हैं, बल्कि आवश्यकताओं के बदलने पर फेंक देते हैं और फिर से उत्पन्न करते हैं - तो हमारी भूमिका मौलिक रूप से बदल जाती है। हम अब ईंट-दर-ईंट लगाने वाले राजमिस्त्री नहीं हैं। हम उस फ़ैक्टरी के वास्तुकार हैं जो दीवारें प्रिंट करती है।

लेकिन कौन नियंत्रित करता है कि वे दीवारें सीधी हैं?

द "गॉन्टलेट": एक स्वचालित अग्नि परीक्षा

एक एआई डिज़ाइन अथॉरिटी कोई व्यक्ति नहीं है, बल्कि एक पाइपलाइन है। एक "गॉन्टलेट" जिससे उत्पादन में जाने के लिए उत्पन्न कोड की हर पंक्ति को लड़ना पड़ता है। यह प्रक्रिया मानव कोड समीक्षा को प्रतिस्थापित नहीं करती है कुछ नहीं, बल्कि कुछ बेहतर.

यह तीन स्तरों में काम करता है:

1. कार्यकारी शक्ति (उत्पादन)
हम एक समाधान के लिए एक एआई से नहीं पूछते, हम तीन से पूछते हैं। हम जेमिनी 3, जीपीटी-5 और एक ओपन-सोर्स मॉडल (जैसे लामा) को एक ही समस्या पर समानांतर रूप से काम करने देते हैं। यह सुरंग दृष्टि को रोकता है और उस "आलस्य" को तोड़ता है जिससे कभी-कभी एलएलएम पीड़ित होते हैं। यह दृष्टिकोण भी वैज्ञानिक रूप से शोधित है और दिखाता है कि आप एआई मतिभ्रम को रोक सकते हैं और बिना किसी त्रुटि के बहुत लंबी श्रृंखलाएं बना सकते हैं

2. कठोर फ़िल्टर (कानून)
यहां कोई बहस संभव नहीं है। कोड को संकलित करना होगा। लिंटर्स को शिकायत नहीं करनी चाहिए। और महत्वपूर्ण बात: यह ब्लैक बॉक्स टेस्ट सफल होना चाहिए। हम यह परीक्षण नहीं करते हैं कि फ़ंक्शन आंतरिक रूप से काम करता है या नहीं (यह एआई में हेरफेर कर सकता है), हम परीक्षण करते हैं कि सिस्टम बाहर से वही करता है जो उसे करना चाहिए। परीक्षण विफल होता है? सीधे कूड़ेदान में।

3. नरम फ़िल्टर (एआई जूरी)
यह वास्तविक नवाचार है। शेष समाधान एक विशेष "वोटिंग एआई" के सामने प्रस्तुत किए जाते हैं। यह एजेंट कोड नहीं लिखता है, बल्कि पढ़ता है कोड। इसे हमारे आर्किटेक्चर सिद्धांतों, सुरक्षा आवश्यकताओं (OWASP, ISO) और अनुपालन नियमों (ईयू एआई एक्ट) पर प्रशिक्षित किया जाता है।
वह सहमत है: “समाधान ए तेज़ है, लेकिन समाधान बी अधिक सुरक्षित है और हमारी माइक्रो सर्विसेज वास्तुकला का बेहतर ढंग से पालन करता है।”

विजेता उत्पादन में जाता है।

सॉफ्टवेयर का त्रय राजनीति (ट्रायस पॉलिटिका)

यह मॉडल शक्तियों के पृथक्करण को लागू करता है जो कई टीमों में अनुपस्थित है।

• विधायी शक्ति (आर्किटेक्ट): आर्किटेक्ट "संविधान" लिखता है। प्रॉम्प्ट्स, आर्किटेक्चर दस्तावेज़ (project-description.md, rules.md en principles.md), कठोर आवश्यकताएँ। आर्किटेक्ट तय करता है क्या हम क्या बनाते हैं और क्यों.
• कार्यकारी शक्ति (कोडिंग एजेंट): वे निष्पादित करते हैं। तेज़ी से, सस्ते में और मानव डेवलपर्स के तत्वावधान में।
• न्यायिक शक्ति (डिज़ाइन प्राधिकरण): एक स्वतंत्र एआई परत जो कानून का परीक्षण करती है।

निष्कर्ष: आर्किटेक्ट की नई भूमिका

यह हमें सिंटैक्स त्रुटियों की तानाशाही से मुक्त करता है और हमें उस पर ध्यान केंद्रित करने देता है जिसमें हम अच्छे हैं: सिस्टम थिंकिंग। सत्य की खोज। संरचना और निर्णय लेना।

सवाल यह नहीं है कि क्या एआई हमारा कोड लिख सकता है। यह पहले ही तय हो चुका है। कोड काफी हद तक डिस्पोजेबल हो जाएगा।
सवाल यह है: क्या आप नियंत्रण छोड़ने की हिम्मत करते हैं निष्पादन नियंत्रण छोड़ने की, ताकि आप नियंत्रण प्राप्त कर सकें गुणवत्ता वापस जीतने के लिए?