एआई डिज़ाइन प्राधिकरण
हम सॉफ़्टवेयर विकास में एक निर्णायक मोड़ पर खड़े हैं। चर्चा अक्सर इस बात पर होती है कि कौन-सा सबसे अच्छा कोड एआई लिखता है (क्लॉड बनाम चैटजीपीटी) या कहाँ वह एआई कहाँ होना चाहिए (आईडीई या सीएलआई)। लेकिन यही सही सवाल नहीं है।
यदि हम एआई को “वाइब कोडर्स” के रूप में अपनाते हैं—जहाँ हम केवल अपनी मंशा बताते हैं और क्रियान्वयन एआई करता है—तो हम बड़ी मात्रा में नया सॉफ़्टवेयर तैयार करते हैं। एआई एजेंटों का एक समूह एक मिनट में उससे अधिक कोड तैयार कर सकता है, जितने की समीक्षा एक वरिष्ठ डेवलपर एक सप्ताह में कर पाए। मनुष्य अब बाधा बन गया है।
समाधान लोगों को और अधिक हटाना नहीं है। समाधान एक एआई डिज़ाइन अथॉरिटी.
कारीगर से कारखाना निदेशक तक
परंपरागत रूप से, “डिज़ाइन अथॉरिटी” वास्तुकारों का एक छोटा समूह होता है, जो किसी डिज़ाइन को मंज़ूरी देने या अस्वीकार करने के लिए सप्ताह या महीने में एक बार बैठक करता है। तेज़ गति वाले एआई विकास के संसार में यह मॉडल बुरी तरह पुराना हो चुका है। यह बहुत धीमा और प्रतिक्रियात्मक है।
यदि हम “डिस्पोज़ेबल कोड” की ओर बढ़ते हैं—ऐसा सॉफ़्टवेयर जिसे हम अंतहीन रूप से रिफैक्टर करने के बजाय आवश्यकताएँ बदलने पर हटा कर फिर से तैयार करते हैं—तो हमारी भूमिका मूल रूप से बदल जाती है। अब हम ऐसे राजमिस्त्री नहीं हैं जो एक-एक पत्थर रखकर निर्माण करते हैं। हम उस कारखाने के वास्तुकार हैं, जो दीवारों को प्रिंट करता है।
लेकिन यह कौन जाँचता है कि वे दीवारें सीधी खड़ी हैं?
‘गॉंटलेट’: एक स्वचालित अग्निपरीक्षा
एआई डिज़ाइन अथॉरिटी कोई व्यक्ति नहीं, बल्कि एक पाइपलाइन है। एक “गॉंटलेट”, जिससे होकर जनरेट किया गया हर कोड उत्पादन में पहुँचने से पहले संघर्ष करता है। यह प्रक्रिया मानवीय कोड समीक्षा का स्थान किसी चीज़ से नहीं लेती, बल्कि कुछ नहींबल्कि किसी ऐसी चीज़ से बेहतर.
यह तीन स्तरों पर काम करती है:
1. कार्यकारी शक्ति (जनरेशन)
हम किसी एक एआई से समाधान नहीं माँगते, बल्कि तीन से माँगते हैं। हम जेमिनी 3, जीपीटी-5 और एक ओपन-सोर्स मॉडल (जैसे लामा) को एक ही समस्या पर समानांतर रूप से काम करने देते हैं। इससे संकीर्ण दृष्टिकोण से बचाव होता है और उस “आलस्य” को तोड़ा जाता है, जिससे बड़े भाषा मॉडल कभी-कभी ग्रस्त हो जाते हैं। यह दृष्टिकोण वैज्ञानिक रूप से शोधित और यह दर्शाता है कि एआई के भ्रमों को रोका जा सकता है तथा बिना त्रुटियों के बहुत लंबी शृंखलाएँ बनाई जा सकती हैं
2. कठोर फ़िल्टर (कानून)
यहाँ किसी बहस की गुंजाइश नहीं है। कोड का संकलित होना अनिवार्य है। लिंटर को कोई शिकायत नहीं होनी चाहिए। और सबसे महत्वपूर्ण: ब्लैक बॉक्स परीक्षण को सफल होना होगा। हम यह जाँच नहीं करते कि फ़ंक्शन अंदरूनी रूप से काम करता है या नहीं (एआई इसमें हेरफेर कर सकता है); हम यह जाँचते हैं कि सिस्टम बाहरी स्तर पर वही करता है या नहीं, जो उसे करना चाहिए। परीक्षण विफल हुआ? तो सीधे कूड़ेदान में।
3. नरम फ़िल्टर (AI निर्णायक मंडल)
यही वास्तविक नवाचार है। बची हुई समाधानों को एक विशेष “वोटिंग एआई” के सामने प्रस्तुत किया जाता है। यह एजेंट कोड नहीं लिखता, बल्कि पढ़ता है कोड। इसे हमारे आर्किटेक्चर सिद्धांतों, सुरक्षा आवश्यकताओं (OWASP, ISO) और अनुपालन नियमों (EU AI Act) के आधार पर प्रशिक्षित किया गया है।
यह निर्णय देता है: “समाधान A तेज़ है, लेकिन समाधान B अधिक सुरक्षित है और हमारे माइक्रोसर्विसेज़ आर्किटेक्चर का बेहतर पालन करता है।”
विजेता को प्रोडक्शन में भेज दिया जाता है।
सॉफ़्टवेयर में शक्तियों का त्रिभाजन
यह मॉडल शक्तियों के उस पृथक्करण को लागू करता है, जिसका कई टीमों में अभाव है।
- विधायी शक्ति (आर्किटेक्ट): आर्किटेक्ट ‘संविधान’ लिखता है। प्रॉम्प्ट, आर्किटेक्चर दस्तावेज़ (
project-description.md, rules.md, skills.md en principles.md), कठोर आवश्यकताएँ। आर्किटेक्ट यह निर्धारित करता है क्या हम क्या बनाएँगे, इसे कौन बनाएगा, कैसे और क्यों. - कार्यकारी शक्ति (कोडिंग एजेंट): वे इसे लागू करते हैं—तेज़ी से, कम लागत में और मानव डेवलपरों के पर्यवेक्षण में।
- न्यायिक शक्ति (डिज़ाइन प्राधिकरण): एक स्वतंत्र एआई परत, जो कानून के अनुरूपता की जाँच करती है।
निष्कर्ष: आर्किटेक्ट की नई भूमिका
यह हमें सिंटैक्स त्रुटियों के अत्याचार से मुक्त करता है और उन चीज़ों पर ध्यान केंद्रित करने देता है, जिनमें हम अच्छे हैं: सिस्टम के स्तर पर सोचना। सत्य की खोज। संरचना और निर्णय-निर्माण।
सवाल यह नहीं है कि AI हमारा कोड लिख सकता है या नहीं। यह विषय अब समाप्त हो चुका है। कोड काफी हद तक इस्तेमाल के बाद त्याग दी जाने वाली वस्तु बन जाएगा।
सवाल है: क्या आप कोड का नियंत्रण छोड़ने का साहस करेंगे, ताकि गुणवत्ता पर नियंत्रण फिर से हासिल कर सकें?
मुझे ज़रूर बताइए
