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

एक AI असिस्टेंट उपयोगी है। लेकिन जटिल सॉफ्टवेयर आर्किटेक्चर के लिए यह पर्याप्त नहीं है।

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

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

अस्पष्ट समस्याओं को हल करने के लिए, आपको एक AI Council की आवश्यकता है। यह कोई नया प्लेटफॉर्म नहीं है। यह एक वर्कफ़्लो है जहाँ कई AI कॉन्टेक्स्ट अलग-अलग भूमिकाओं (roles) से एक प्रस्ताव की समीक्षा करते हैं।

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

यहाँ वर्कफ़्लो दिया गया है:

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

इसकी शक्ति भूमिकाओं के अलगाव (role separation) से आती है। केवल "आपको क्या लगता है?" न पूछें। विभिन्न AI सत्रों को विशिष्ट भूमिकाएँ सौंपें:

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

सबसे महत्वपूर्ण हिस्सा Objection Ledger है। इसके बिना, फीडबैक अस्पष्ट राय बन जाता है। एक लेजर आपको हर चिंता को हल करने के लिए मजबूर करता है। आप आपत्तियों को Open, Accepted, Rejected, या Resolved के रूप में चिह्नित करते हैं। यह एक ऑडिट करने योग्य निर्णय रिकॉर्ड बनाता है।

आप कॉपी-पेस्ट बॉटलनेक (bottleneck) नहीं बनते हैं। source-grounded एजेंट सिंथेसिस का कार्य करता है। आप Governor के रूप में कार्य करते हैं। आप मैन्युअल काम नहीं करते हैं। आप गेट्स (gates) के मालिक होते हैं।

आप निर्णयों के स्वामी होते हैं:

  • इटरेशन (iterating) कब बंद करना है।
  • स्पेसिफिकेशन (spec) को कब मंजूरी देनी है।
  • अंतिम जोखिम को कब स्वीकार करना है।

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

छोटी शुरुआत करें। एक क्रिटिक (critic) और एक सिम्प्लीफायर (simplifier) का उपयोग करें। आप तुरंत इसका मूल्य देखेंगे।

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