आफैँ निर्माण हुने प्रणालीको डिजाइन
अधिकांश सफ्टवेयर डेभलपर, टेक लिड र डेभअप्स इन्जिनियरहरू आफ्नो करिअर निर्माणकर्ता (builder) का रूपमा सुरु गर्छन्।
तिनले प्रणाली, एप, कम्पोनेन्ट, थिम, प्याटर्न, मोड्युल र पाइपलाइन बनाउँछन्। लेआउट सुधार्छन्, अप्ठ्यारा अवस्था (edge case) समाधान गर्छन्, अनुकूलता कायम राख्छन्, र एक-एक कमिट गर्दै प्रणालीलाई अगाडि बढाउँछन्। काम सटीक, व्यावहारिक र गहिरो प्राविधिक हुन्छ।
तर कुनै बिन्दुमा केही बदलिन्छ।
उत्कृष्ट अभ्यासकर्ताहरू निर्माण गर्न छाड्दैनन्, तर तिनले प्रणालीका रूपमा सोच्न थाल्छन्।
निर्माणकर्ताबाट प्रणाली-चिन्तकतर्फ
बदलाव: उत्पादनबाट नियमतर्फ
निर्माणकर्ताको ध्यान उत्पादन (output) मा हुन्छ: कम्पोनेन्ट, टेम्प्लेट, पेज, फिचर, लाइब्रेरी, एप्लिकेसन।
प्रणाली-चिन्तकको ध्यान नियमतर्फ सर्छ: सीमा-बन्देज, अन्तरक्रिया, फिडब्याक लुप।
"यो कम्पोनेन्ट कस्तो देखिन्छ?" भनेर सोध्नुको सट्टा प्रणाली-चिन्तकहरू फरक प्रश्न गर्छन्: यो कम्पोनेन्टलाई कुन नियमले शासित गर्छ? यससँग के-कस्ता अन्तरक्रिया गर्न दिइन्छ? परिवर्तनमा यसले कस्तो व्यवहार गर्छ? समयसँगै मूल मनसाय (intent) कसरी जोगिन्छ?
यो बदलावले स्वाभाविक रूपमा एजेन्टिक प्रणाली (agentic systems) तर्फ डोर्याउँछ।
![Man looking at flowchart titled "Collective of AI Agents."](/sites/default/files/styles/d08/public/2026-01/shifting-focus-from-output-to-rules.png?itok=9kTUezLo "Man looking at flowchart titled "Collective of AI Agents."")
जब डिजाइन स्थिर रहँदैन
आधुनिक डिजाइन प्रणालीले पहिल्यै तर्कलाई कोडमा उतारेका हुन्छन्: टोकनले सीमा तोक्छन्, कम्पोनेन्टले संरचना तोक्छन्, प्याटर्नले व्यवहार तोक्छन्।
तर अधिकांश प्रणाली अझै पनि मानिसद्वारा गरिने भारी समन्वयमा निर्भर छन्।
एआई एजेन्टहरूले फरक मोडेल ल्याउँछन्, जहाँ प्रणालीले आफ्नै नियम आफैँ लागू गर्न, निर्णयहरूको निरन्तर प्रमाणीकरण गर्न, सन्दर्भअनुसार प्रतिक्रिया दिन र भित्रभित्रै समन्वय गर्न सक्छ।
यहीँबाट डिजाइन कागजी कागजातबाट कार्यान्वयनयोग्य तर्क (executable logic) मा विकसित हुन्छ।
यो कतातिर जाँदैछ
अहिले ध्यान यी विचारहरूलाई वास्तविक, चल्ने प्रणालीमा लागू गर्नेतर्फ छ, प्रयोगका रूपमा होइन, आधारशिलाका रूपमा।
१. डिजाइन टुल (Figma) सँग एआई एजेन्टहरूको गहिरो एकीकरण
एजेन्टिक डिजाइन प्रणालीतर्फ
डिजाइन टुलहरू निष्क्रिय क्यानभास मात्र हुनु हुँदैन।
लक्ष्य Figma सँग यस्ता एआई एजेन्टहरू जोड्नु हो जसले डिजाइन टोकन र कम्पोनेन्टका सीमा बुझून्, निर्णयहरू वास्तविक समयमै प्रमाणित गरून्, डिजाइनको मनसायलाई प्रणाली-स्तरका नियममा रूपान्तरण गरून्, र निर्यातकर्ता होइन, सहकर्मीका रूपमा काम गरून्।
यसले डिजाइनलाई सुरुवाती चरणमै पुर्याउँछ, जहाँ मनसाय जोगिन्छ, पछि अनुमान लगाइँदैन।
२. स्केलेबल एआई एजेन्ट व्यवस्थापन
लक्ष्य: १५० एजेन्ट, प्रत्येक कम्पोनेन्टका लागि एक
एउटै सामान्य-उद्देश्यीय एआईको सट्टा टोलीहरू धेरै विशेषज्ञ एजेन्टतर्फ सर्दै छन्।
प्रत्येक कम्पोनेन्टले आफ्नै एजेन्ट पाउँछ, जसका स्पष्ट जिम्मेवारी, स्पष्ट सीमा र सम्बन्धित कम्पोनेन्टबारे जानकारी हुन्छ।
स्वस्थ प्रणाली यसरी नै बढ्छन्: विशेषज्ञता, समन्वय र स्पष्ट सम्झौताद्वारा।
![Three color-coded grids labeled "Actions," "Resources," and "Strategies."](/sites/default/files/styles/d08/public/2026-01/designing-systems-that-build-themselves-components-150-v2.png?itok=RJGz7XWW "Three color-coded grids labeled "Actions," "Resources," and "Strategies."")
३. वास्तविक सीप, टुल र प्लगइनसहितका एजेन्ट
एजेन्टहरू काम गर्न सक्षम हुनुपर्छ।
यसको अर्थ तिनलाई सीप (एक्सेसिबिलिटी सम्बन्धी तर्क, डिजाइन प्रमाणीकरण, performance को चेतना), टुल (लिन्टर, टेस्ट रनर, डिजाइन API) र प्लगइन (Storybook, Drupal, CI पाइपलाइन, Figma इन्टिग्रेसन) ले सुसज्जित गर्नु हो।
टुलबिनाको एजेन्ट सैद्धान्तिक मात्र हो। टुलसहितको एजेन्ट प्रणालीकै अंश बन्छ।
४. अझ स्मार्ट स्वचालित फंक्सनल एक्सेप्टेन्स टेस्टिङ
एआई-सञ्चालित र मनसाय-सचेत
परम्परागत टेस्टिङले आउटपुट जाँच्छ। एजेन्ट-सञ्चालित टेस्टिङले व्यवहार बुझ्छ।
ध्यान यस्ता एआई एजेन्टहरूमा छ जसले प्रयोगकर्ताको यात्रा (user journey) बारे तर्क गर्छन्, selector मात्र होइन मनसाय बुझ्ने फंक्सनल टेस्टहरूमा, कम्पोनेन्टसँगै टेस्ट पनि विकसित गर्ने प्रणालीहरूमा, र अर्थगत विश्वास बढाउँदै कमजोर (brittle) टेस्ट घटाउनमा।
टेस्टिङ प्रणालीको बुद्धिमत्ताको अर्को तह बन्छ।
एआईको युगमा TDD र BDD: एआई एजेन्टहरूलाई किन १००% बढी टेस्ट-फर्स्ट डेभलपमेन्ट चाहिन्छ
यो किन महत्त्वपूर्ण छ
टोलीहरूले यस्ता प्रणाली बनाउँदैछन् जो आफ्ना सिर्जनाकर्ताभन्दा लामो समय टिक्छन्, निरन्तर अनुकूलित हुन्छन्, र दीर्घकालीन डिजाइन निर्णयहरू अगाडि बोक्छन्।
यस्तो संसारमा हातले गरिने नियन्त्रण सँगसँगै बढ्न सक्दैन। तर राम्ररी परिभाषित नियमले सक्छ।
डिजाइनर, डेभलपर र एआई एजेन्टहरूले एउटै तार्किक ढाँचाभित्र काम गर्नुपर्छ, सीमा र मनसायको एउटै साझा प्रणाली।
निर्माणकर्ताबाट प्रणाली-चिन्तकतर्फको यात्रा कार्यान्वयन त्याग्नु होइन। यो प्रणालीलाई पुर्जाहरूको थुप्रोभन्दा बढी देख्ने कुरा हो।
अर्को कदम भनेको प्रणालीले तर्क गर्न, अनुकूलित हुन र विकसित हुन सक्ने नियमहरू डिजाइन गर्नु हो।
यो बदलाव अपनाउने सफ्टवेयर डेभलपर, टेक लिड र डेभअप्स इन्जिनियरहरू केवल निर्माण गरिरहेका हुँदैनन्, तिनले प्रणालीहरू आफैँ निर्माण हुन सक्ने परिस्थिति रचिरहेका हुन्छन्।
