मैं अस्पष्ट इंजीनियरिंग समस्याओं को हल करने के लिए AI Councils का उपयोग कैसे करता हूँ

एक AI असिस्टेंट उपयोगी है। लेकिन यह हमेशा पर्याप्त नहीं होता।

यदि आप कोडिंग के लिए AI का उपयोग करते हैं, तो आप इस पैटर्न को जानते होंगे। आप एक समस्या का वर्णन करते हैं। मॉडल एक समाधान प्रस्तावित करता है। यह अच्छा दिखता है। आप इसे लागू करते हैं। फिर तीन दिन बाद आपको एक बड़ी खामी मिलती है। आर्किटेक्चर एक बाउंड्री कंडीशन (boundary condition) में विफल हो गया। इसने दो ऐसी चीजों को आपस में जोड़ दिया जिन्हें अलग होना चाहिए था।

यह मॉडल की विफलता नहीं है। यह प्रक्रिया की विफलता है। एक अकेला मॉडल अपनी ही धारणाओं (assumptions) को चुनौती देने की क्षमता नहीं रखता है।

जटिल इंजीनियरिंग कार्यों के लिए, आपको एक AI Council की आवश्यकता होती है। यह कोई नया प्लेटफॉर्म नहीं है। यह एक संरचित वर्कफ़्लो (structured workflow) है जहाँ कई AI भूमिकाएँ एक ही प्रस्ताव की विभिन्न दृष्टिकोणों से समीक्षा करती हैं।

इसका लक्ष्य AI के उपयोग को एक नियंत्रित इंजीनियरिंग वर्कफ़्लो में बदलना है।

वर्कफ़्लो इस प्रकार काम करता है:

• Problem Statement: आप समस्या को परिभाषित करते हैं। • Architect Agent: एक सोर्स-ग्राउंडेड (source-grounded) एजेंट एक प्रारंभिक प्रस्ताव तैयार करता है। • AI Council: विभिन्न AI भूमिकाएँ प्रस्ताव की समीक्षा करती हैं। • Feedback Synthesis: एक एजेंट सभी फीडबैक को मिलाता है और संघर्षों (conflicts) की पहचान करता है। • Objection Ledger: आप प्रत्येक आपत्ति, उसकी गंभीरता और उसके समाधान को ट्रैक करते हैं। • Human Governance: आप तय करते हैं कि कब रुकना है या आगे बढ़ना है। • Executor Agent: एक अलग एजेंट योजना को लागू करता है। • Auditor Agent: एक अंतिम एजेंट मूल स्पेसिफिकेशन (spec) के विरुद्ध कोड की जाँच करता है।

आपके काउंसिल में निम्नलिखित भूमिकाएँ शामिल होनी चाहिए:

• System Thinker: जोखिमों और सिस्टम की सीमाओं का मूल्यांकन करता है।
• Critical Reviewer: धारणाओं को चुनौती देता है और कमियों को ढूँढता है।
• Simplifier: अनावश्यक जटिलता को पहचानता है।
• Alternatives Reviewer: अलग-अलग दृष्टिकोणों का सुझाव देता है।

जादू अधिक मॉडल उपयोग करने में नहीं है। जादू भूमिकाओं के अलगाव (role separation) में है। जब आप AI से "इसकी समीक्षा करें" कहते हैं, तो आपको अस्पष्ट उत्तर मिलते हैं। जब आप AI से "तीन सबसे बड़े आर्किटेक्चरल जोखिमों को खोजें" कहते हैं, तो आपको कार्रवाई योग्य डेटा (actionable data) मिलता है।

आपको संदर्भों (contexts) को भी अलग करना चाहिए। जो एजेंट कोड लिखता है, वह वही एजेंट नहीं होना चाहिए जो कोड का ऑडिट करता है। यह AI को एक ही तरह की कमियों (blind spots) को दोहराने से रोकता है।

इंसान मैन्युअल काम नहीं करता है। इंसान नियंत्रण (gates) रखता है। आप तय करते हैं कि फीडबैक कब पर्याप्त है। आप तय करते हैं कि किन जोखिमों को स्वीकार करना है। आप इंजीनियरिंग मैनेजर हैं, मैन्युअल वर्कर नहीं।

इसका उपयोग उच्च-जोखिम वाले रिफैक्टरिंग (refactors) और अस्पष्ट आर्किटेक्चर के लिए करें। इसका उपयोग मामूली बग फिक्स के लिए न करें। यह अतिरिक्त प्रयास (overhead) तभी सार्थक है जब गलती की कीमत अधिक हो।

Source: https://dev.to/j3nnning/how-i-use-ai-councils-to-solve-ambiguous-engineering-problems-4dii

Optional learning community: https://t.me/GyaanSetuAi