एआई डिज़ाइन अथॉरिटी

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

सॉफ्टवेयर का त्रय सिद्धांत

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

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

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

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

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