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

हम सॉफ्टवेयर विकास में एक मोड़ पर हैं। चर्चा अक्सर होती है कौन सा एआई सबसे अच्छा कोड लिखता है (Claude बनाम ChatGPT) या कहाँ एआई को कहां रहना चाहिए (IDE या CLI)। पर यह सही प्रश्न नहीं है।

समस्या कोड नहीं है। उत्पन्न करना यह उस के बारे में है मान्यकरण का।

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

समाधान यह नहीं है अधिक लोगों को। समाधान एक है एआई डिज़ाइन अथॉरिटी.

कुशल कारीगर से कारखाना निदेशक तक

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

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

लेकिन कौन सुनिश्चित करता है कि वे दीवारें सीधी हों?

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

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

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

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

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

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

विजेता प्रोडक्शन में जाता है।

सॉफ्टवेयर का त्रिराजनी तंत्र

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

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

निष्कर्ष: वास्तुकार की नई भूमिका

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

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

मुझे बताइए