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