अच्छी बाधाओं ने सॉफ्टवेयर के सर्वश्रेष्ठ युगों और मेरे अपने करियर को आकार दिया है। कुछ राय-आधारित दृष्टिकोण, जैसे 12-फ़ैक्टर ऐप सिद्धांत या MVC, ने हमें विश्वसनीय सेवाएँ बनाने और चिंताओं के पृथक्करण को डिज़ाइन करने के लिए एक साझा भाषा दी। ये सरल नियम थे, बताने में आसान, लेकिन पूरी तरह से पालन करने में कठिन। इन्होंने पूरे उद्योगों को जन्म दिया: SaaS, PaaS, क्लाउड इंफ्रास्ट्रक्चर। ये सब सुविचारित बाधाओं की बदौलत बने, जिन्होंने निर्माताओं को बताया: यहाँ सीमा है, इस सीमा के दायरे में रहो, और अच्छे परिणाम मिलेंगे। मैंने व्यक्तिगत रूप से अपने कुछ बेहतरीन कामों में इन बाधाओं को लागू करने से लाभ उठाया है।
मेरा मानना है कि AI-नेटिव सॉफ़्टवेयर को अपनी स्वयं की बाधा की आवश्यकता है। यहाँ वह बाधा है जो मैंने सोची है।
आपके कोडबेस का एक अधिकतम आकार होता है। यह स्वाद का मामला नहीं है। यह सीमा वास्तविक, मापने योग्य, और आपके विचार से छोटी है।
सीमा: आपके एजेंट आपके उत्पाद को बनाने और बनाए रखने के लिए जिस AI मॉडल का उपयोग करते हैं, उसके कॉन्टेक्स्ट विंडो का आधा हिस्सा। इसका मतलब है कि आपके मुख्य व्यावसायिक तर्क और सिस्टम कॉन्टेक्स्ट का आकार, आप जिस भी LLM पर निर्भर हैं, उसकी कॉन्टेक्स्ट विंडो के आधे से अधिक नहीं होना चाहिए।
आधा क्यों? कॉन्टेक्स्ट विंडो दो उद्देश्यों को पूरा करती है। पहला आधा हिस्सा आपके कोड को रखता है। दूसरा आधा हिस्सा वह जगह है जहाँ एजेंट तर्क करता है, योजना बनाता है, और जनरेट करता है। पूरी विंडो को कोड से भर दें और आप सोचने के लिए कोई जगह नहीं छोड़ते। आधा समझने के लिए। आधा सोचने के लिए।
सॉफ़्टवेयर व्यवसायों का सबसे कठिन हिस्सा कभी भी फीचर बनाना नहीं था।
हर अनुभवी टेक फाउंडर यह जानता है। कठिन हिस्सा एक पर्याप्त बड़े ग्राहक वर्ग के लिए उपयोगी सॉफ़्टवेयर का सबसे छोटा टुकड़ा पहचानना था, और फिर ग्राहक अधिग्रहण, ग्राहक सेवा, और प्रतिधारण के कठिन काम के आसपास लोगों को एकजुट करना था।
सॉफ़्टवेयर बनाना पहले महंगा हुआ करता था। इंजीनियरों की लागत बहुत अधिक थी। इसने घर्षण पैदा किया, जिसने पुनरावृत्त विकास प्रक्रियाओं को जन्म दिया, लेकिन इसने अनुशासन भी लागू किया। आपको चुनना था: ग्राहकों को सबसे ज़्यादा क्या चाहिए? बनाने लायक सबसे छोटी चीज़ क्या है? इंजीनियरिंग की मानवीय लागत ने टीमों को केंद्रित रखा। बाधाओं ने स्पष्टता पैदा की। सिलिकॉन वैली की सबसे अच्छी कंपनियाँ इसी तरह बढ़ीं।
अब AI एजेंट आपके द्वारा माँगी गई लगभग हर चीज़ बना देते हैं। बाधा गायब हो गई है। बाधा के साथ अनुशासन भी गायब हो गया।
मुफ्त उत्पादन अतिउत्पादन की ओर ले जाता है। अतिउत्पादन AI-नेटिव कंपनियों की डिफ़ॉल्ट विफलता मोड है।
गैर-तकनीकी फाउंडर और निवेशकों को यह समझने की आवश्यकता है। अधिक फीचर, अधिक कोड, और बनाए रखने के लिए अधिक उत्पाद सतह क्षेत्र अब प्रगति के संकेत नहीं हैं। वे बिना उच्च-गुणवत्ता वाली बाधाओं वाली कंपनी का संकेत देते हैं, और कभी-कभी, मौलिक स्पष्टता की कमी का।
स्केलेबल वितरण और उपभोग के बिना अतिउत्पादन मूल्य कैप्चर में भारी रिसाव पैदा करता है। आप दस फीचर शिप करते हैं। दो प्रतिधारण चलाते हैं। बाकी आठ जटिलता जोड़ते हैं जो उन दो को धीमा कर देती है जो मायने रखते हैं। कोड की हर पंक्ति एक परिसंपत्ति के रूप में प्रच्छन्न देयता बन जाती है।
अनुभवी निर्माता टिपिंग पॉइंट जानते हैं। कोड ग्राहकों की सेवा करने से खुद की सेवा करने की ओर शिफ्ट हो जाता है। जटिलता उत्पाद की दुश्मन बन जाती है। टीमें ग्राहक अनुभव को बेहतर बनाने की तुलना में सॉफ़्टवेयर के प्रबंधन में अधिक समय बिताती हैं। सिस्टम बेकार लगने लगता है, उपयोगकर्ता गिरने लगते हैं, और आपकी ग्राहक-सामना करने वाली टीमें चुपचाप निराश हो जाती हैं।
पुरानी दुनिया में, आप उस टिपिंग पॉइंट तक वर्षों में पहुँचते थे। AI-नेटिव दुनिया में, आप टिपिंग पॉइंट तक हफ्तों में पहुँचते हैं। एजेंट कभी थकते नहीं हैं, कभी पीछे नहीं हटते हैं, और कभी नहीं कहते हैं, "यह बहुत जटिल है, हमें रुक जाना चाहिए।"
आप कैसे जानते हैं कि कब रुकना है? जब AI मुफ्त में असीमित कोड लिखता है, तो वह संकेत क्या है जो आपको बताता है कि बहुत हो गया?
यह है हाफ-विंडो नियम।
आपका मुख्य व्यावसायिक तर्क उस मॉडल की कॉन्टेक्स्ट विंडो के आधे हिस्से में फिट होना चाहिए जो आपके कोडबेस को बनाए रखता है। अपने कोडबेस को टोकन में मापें। इसकी तुलना आधी कॉन्टेक्स्ट विंडो से करें। यदि आप ऊपर हैं, तो आपका AI कार्यबल पहले से ही ख़राब हो रहा है—दिखाई नहीं दे रहा, नाटकीय रूप से नहीं, बल्कि चुपचाप और लगातार।
खतरा: जब आप इस रेखा को पार करते हैं तो स्पष्ट रूप से कुछ भी नहीं टूटता है। एजेंट मना नहीं करता है। कोड सही दिखता है। टेस्ट पास हो जाते हैं। आपके द्वारा रिपोर्ट किया गया बग ठीक हो जाता है।
लेकिन एजेंट अब आपके सिस्टम की पूरी समझ के बिना काम करता है। एजेंट पूरे के बारे में तर्क करने के बजाय टुकड़ों पर पैटर्न-मैच करता है। सूक्ष्म प्रतिगमन दिखाई देते हैं। कोडबेस के उन हिस्सों में तर्क डुप्लिकेट हो जाता है जिन्हें एजेंट नहीं देख सकता है। समस्याएँ कोड जोड़कर "हल" हो जाती हैं जहाँ मौजूदा कोड को बदलना चाहिए था।
आप तुरंत नोटिस नहीं करेंगे। वेलोसिटी अभी भी अधिक लगती है। पुल रिक्वेस्ट अभी भी आती हैं। हर एक अगले को थोड़ा और खराब बनाता है। कम्पाउंड डिग्रेडेशन आपके खिलाफ काम करता है।
जब तक आप पूछते हैं "हमारे एजेंट चक्कर क्यों काटते रहते हैं?" तब तक आप समस्या में गहरे होते हैं।
यह नियम तकनीकी पोशाक में व्यावसायिक अनुशासन है।
जब उत्पादन की लागत कुछ नहीं होती है तो सरलता आपका प्रतिस्पर्धात्मक लाभ बन जाती है। सबसे छोटा कोडबेस बनाएं जो ग्राहकों को वास्तविक मूल्य प्रदान करता है। हर अनावश्यक फीचर, हर अनावश्यक अमूर्तता, और अटकलबाजी कोड की हर पंक्ति आपके AI कार्यबल के संज्ञानात्मक बजट को खा जाती है। अंततः, ये आपकी कंपनी की चलने की क्षमता को खा जाते हैं।
सबसे अच्छे उत्पाद हमेशा सबसे सरल रहे हैं जो किसी वास्तविक समस्या को पूरी तरह से हल करते हैं। इस सिद्धांत के उल्लंघन का दंड अब तेजी से आता है और अधिक मजबूती से बढ़ता है। आपके AI एजेंट उस तरह पीछे नहीं हटेंगे जैसे एक निराश वरिष्ठ इंजीनियर हटता था।
नियम आर्किटेक्चर के साथ स्केल करता है। सिंगल-प्रोडक्ट स्टार्टअप: पूरे कोडबेस पर लागू होता है। मल्टी-सर्विस कंपनी: प्रत्येक सेवा पर स्वतंत्र रूप से लागू होता है। आपके सिस्टम का कोई भी हिस्सा जिसे समग्र रूप से समझा जाना चाहिए, उस सीमा में फिट होना चाहिए जहाँ आपके एजेंट पूरी तस्वीर के बारे में तर्क करते हैं।
आपका उत्पाद आर्किटेक्चर आपके एजेंटों की संज्ञानात्मक सीमाओं को प्रतिबिंबित करेगा, चाहे आप इसके लिए योजना बनाएं या नहीं। जो फाउंडर जानबूझकर इसके लिए डिज़ाइन करते हैं वे उन लोगों से आगे निकल जाएंगे जो दर्द के माध्यम से सीखते हैं।
यह पूर्णता के बारे में नहीं है। आप हमेशा रेखा के नीचे नहीं रहेंगे। कोडबेस बढ़ते हैं। फीचर जुड़ते हैं। जटिलता जमा होती है। बात आकांक्षा की है, कठोर अनुपालन की नहीं। यदि आप इस नियम को ध्यान में रखते हैं और सीमा के करीब रहते हैं, तो आप बेहतर निर्णय लेंगे कि क्या बनाना है, क्या विभाजित करना है, और क्या हटाना है। बाधा आपको एक संदर्भ बिंदु देती है जब बाकी सब कहता है 'और बनाओ'। कभी-कभी इसका मतलब नियम के अनुरूप अपने सब-एजेंट आर्किटेक्चर को फिर से डिज़ाइन करना होता है—बिल्कुल वैसे ही जैसे मानव टीमें बढ़ने पर स्वामित्व को विभाजित करती हैं।
मैं अपने स्वयं के काम में इस नियम का पालन करने की आकांक्षा रखता हूँ। इसलिए नहीं कि नियम तोड़ने का मतलब तत्काल विफलता है, बल्कि इसलिए कि इस बाधा के करीब रहने से मुझे ऐसा सॉफ़्टवेयर बनाने में मदद मिलती है जो समय के साथ उपयोगी, बनाए रखने योग्य और मूल्यवान बना रहता है। जो फाउंडर इसके आसपास उन्मुख होते हैं वे बहुत आगे जाएंगे। जो लोग बाधाओं को पूरी तरह से अनदेखा करते हैं वे दर्द के माध्यम से सीखेंगे।
अच्छी बाधाएँ सफलता की गारंटी नहीं देती हैं। वे विफल होने के सबसे सामान्य तरीकों को हटाकर सफलता को अधिक संभावित बनाती हैं। 12-फ़ैक्टर ऐप सिद्धांतों का एक समूह था जिसने आपके लिए आपकी SaaS कंपनी नहीं बनाई, लेकिन यदि आप उनका पालन करते थे, तो जब आपको स्केल करने की आवश्यकता होती थी तो आपका इंफ्रास्ट्रक्चर काम करता था। हाफ-विंडो नियम बिल्कुल उसी तरह काम करता है। भावना का पालन करें। सीमा के करीब रहें। उपयोगी सॉफ़्टवेयर व्यवसाय बनाएं जो टिके रहें।
सरलता हमेशा जीतती है। अब सरलता तेजी से जीतती है।
लेखक के बारे में: अभिषेक परोलकर https://brain.pe के CEO हैं - जो प्राइवेट इक्विटी फर्मों को उनकी अपनी फर्म या विशिष्ट डील के लिए उनके डिजिटल AI दिमाग बनाने में मदद करता है। हो सकता है कि आपने AI को अपनाया हो, लेकिन क्या AI ने आपको अपनाया है?
