क्यों आउट-ऑफ-द-बॉक्स एआई टीमों को निराश करता है — और इसके बारे में क्या करना है

अधिकांश प्रौद्योगिकियों के साथ, जितना अधिक आप उनका उपयोग करते हैं, उतना ही अधिक शांति से आप उन पर निर्भर करते हैं। एआई टूल्स के साथ, इसके विपरीत सच है: अपने वार्षिक सर्वेक्षण में 49,000 से अधिक डेवलपर्स के साथ, स्टैक ओवरफ्लो ने उपयोग में वृद्धि दर्ज की, जो 84% तक पहुंच गया, जबकि एक ही वर्ष में इन टूल्स की सटीकता में विश्वास 40% से 29% तक गिर गया।

यह प्रभाव मुझे परिचित है। हमारे अपने पहले अनुभव में एआई टूल्स के साथ विकास में बहुत कम समानता थी, जो तकनीकी प्रेस ने तेजी से काम और कम थकान के बारे में लिखा था। हमारे डेवलपर्स को निराशा हुई: एआई ने मध्यम गुणवत्ता वाला कोड उत्पन्न किया जिसकी समीक्षा करने में लंबा समय लगा और अंत में इसे पुनः लिखना पड़ा। टीम ने एआई से समय बचाने की उम्मीद की, लेकिन इसके बजाय अतिरिक्त काम मिला। इसलिए, एआई टूल्स को दैनिक कार्य प्रवाह में शामिल करने के पहले प्रयासों के तुरंत बाद, टीम ने पुराने तरीके से काम करना शुरू कर दिया।

आज उन्हीं टूल्स ने हमारे डेवलपर्स के लिए कोड लिखने और इसकी समीक्षा करने की प्रक्रिया को तेज कर दिया है — न कि कि हमने एक बेहतर मॉडल खोजा है, बल्कि क्योंकि हमने इसके साथ काम करने के तरीके को बदल दिया है। यहाँ क्या मददगार साबित हुआ:

एआई-लिखित कोड डेवलपर्स को क्यों निराश करता है

एआई इंटरनेट भर के सार्वजनिक कोड के एक विशाल द्रव्यमान पर निर्भर करता है, और यह कोड शायद ही कभी उत्कृष्ट होता है: इसकी गुणवत्ता औसत है, और मॉडल उसी औसत को पुन: उत्पन्न करता है।

लेकिन “औसत” संभावनाओं की सीमा नहीं है — यह बस मॉडल द्वारा उत्पादित किया जाता है जब तक यह आपकी परियोजना को नहीं जानता: इसके सम्मेलन, कोड संरचना, वास्तुशिल्प निर्णय। 600 से अधिक डेवलपर्स के एक सर्वेक्षण में, क्वोडो ने पाया कि उन लोगों में से जो एआई कोड की गुणवत्ता से असंतुष्ट थे, 44% ने इसके लिए संदर्भ की कमी को ठहराया। यही बात है जो आउटपुट को मध्यम स्तर पर अटका देती है।

अच्छी खबर यह है कि एआई प्राप्त संदर्भ एकमात्र परिवर्तनीय है जिसे एक टीम पूरी तरह से नियंत्रित करती है। यह कितनी अच्छी तरह से टूल परियोजना को समझता है, यह मॉडल पर निर्भर नहीं करता है, बल्कि आपको क्या खिलाते हैं।

दूसरा कारण मानसिक है — काम का स्वभाव बदल जाता है। जब एआई अधिकांश कोड लिखता है, तो डेवलपर का मुख्य कार्य लिखना नहीं है, बल्कि जेनरेट किए गए कोड की जांच करना है: किसी और के समाधान को पढ़ना, विकल्पों पर विचार करना, तय करना कि क्या शिपिंग के लिए तैयार है। यह एक अलग कौशल है जो स्वयं कोड लिखने से है, और जो लोग लिखने के हिस्से से प्यार करते थे, उन्हें यह आसानी से नहीं मिलता है।

इसके 2025 ऑक्टोवर्स रिपोर्ट में, गिटहब वर्णित करता है कि यह परिवर्तन कैसे होता है: जिन डेवलपर्स ने एआई के साथ सबसे आगे काम किया है, वे अब खुद को “कोड के लेखक” नहीं कहते हैं और इसके “रचनात्मक निदेशक” बन जाते हैं, जहां मुख्य कौशल मार्गदर्शन और सत्यापन है। लेकिन उस भूमिका तक पहुंचने का रास्ता गलतियों और निराशा से होकर गुजरता है, जब तक कि व्यक्ति अपने काम में लाभ नहीं देखता।

एआई को एक कार्यशील टूल में क्या बदलता है

जब हमारी टीम ने पहली बार एआई का उपयोग शुरू किया, तो कुछ डेवलपर्स ने क्लॉड कोड के साथ काम किया, अन्य ने ओपनएआई कोडेक्स, गिटहब कोपायलट, या जेमिनी सीएलआई आजमाया, और प्रत्येक टूल ने अलग परिणाम दिया। इसलिए, जब हमने एआई के साथ टीम के काम करने के तरीके को व्यवस्थित करने का फैसला किया, तो हमने सबसे पहले एक ही टूल पर निर्णय लिया।

यह हमारी एकमात्र प्रथा नहीं है। लीनियर की टीम की कहानी लें: लीनियर तक जनवरी 2026 तक एक “हर कोई जैसे चाहे वैसे काम करे” के सिद्धांत पर चल रहा था, और जनवरी में नेतृत्व ने उस दृष्टिकोण को छोड़ दिया और सभी को एक ही तरीके से काम करने के लिए स्थानांतरित कर दिया — दो एआई टूल्स के लिए विकल्प को सीमित करना और डेवलपर्स से अनुरोध करना कि वे कोड को हाथ से लिखने के बजाय केवल उन टूल्स के साथ लिखें। कंपनी के अनुसार, औसत उत्पादकता अगले महीने ही 30% बढ़ गई, जिसमें मर्ज किए गए पीआर में वृद्धि हुई और प्रति इंजीनियर बंद कार्यों में 33% की वृद्धि हुई।

हालांकि, एक साझा टूल अपने आप कोड में सुधार नहीं करता है — इसे कॉन्फ़िगर किया जाना चाहिए: नियम स्थापित करें, जैसे कि नियम.मडी, जो बताता है कि कोड कैसे लिखना है — किन दृष्टिकोणों का पालन करना है, क्या避 करना है। फिर आपके परियोजना के लिए विशिष्ट कार्यों के लिए कस्टम कौशल आते हैं, ताकि आपको एक ही बात बार-बार समझाने की जरूरत न पड़े। और अंत में, यह टूल को आपके मौजूदा कोडबेस पर इंगित करने के लायक है: यह विश्लेषण करता है कि परियोजना कैसे लिखी गई है और उसी शैली में नया कोड उत्पन्न करता है, न कि एक सामान्य एक में। जितना अधिक संदर्भ टूल प्राप्त करता है, उतना ही कम आपको हाथ से पुनः लिखना पड़ता है।

लेकिन सबसे कठिन हिस्सा तकनीकी नहीं है। कोड के लेखक से इसके मूल्यांकनकर्ता तक का परिवर्तन स्वयं नहीं होता है — उस संक्रमण को मदद की आवश्यकता है। सबसे直接 मार्ग प्रशिक्षण और प्रमाणीकरण है। हमारे मामले में, उदाहरण के लिए, दस डेवलपर्स टूल प्रदाता के साथ एक साझेदार कार्यक्रम के माध्यम से जा रहे हैं, जबकि उनके साथ एक व्यक्ति गोद लेने के लिए काम करता है, जो बताता है कि टूल ने एक निश्चित परिणाम क्यों उत्पन्न किया और इसे कैसे ठीक किया जाए।

एक बार जब टीम समन्वित तरीके से काम करने लगती है, तो एक बोतलनेक रहता है — समीक्षा — और इसके लिए एआई के साथ मजबूती से समर्थन करने की आवश्यकता है। एजेंट प्रत्येक पुल अनुरोध के माध्यम से जाता है और स्पष्ट बातों को संभालता है: दिनचर्या त्रुटियां, शैली, पुनरावृत्ति, सुरक्षा अंतराल। मानव समीक्षक अब बिना किसी भेदभाव के सब कुछ नहीं देखता है, बल्कि केवल वास्तुकला और महत्वपूर्ण निर्णयों पर। यह प्रभाव उन कंपनियों के भीतर भी दिखाई देता है जो इन टूल्स का निर्माण करती हैं: एंथ्रोपिक में, ऐसे एजेंट को पेश करने के बाद, उन पुल अनुरोधों का हिस्सा जिन्हें व्यापक समीक्षा मिली बढ़कर 16% से 54% हो गया, और इंजीनियरों ने इसकी टिप्पणियों से 1% से कम असहमति जताई।

हमारे लिए, यह एक समीक्षा चक्र को छोटा कर दिया जो दो या तीन दिनों में फैला हुआ था, और इसने हमारे वरिष्ठ इंजीनियरों से दिनचर्या को हटा दिया, उन्हें वास्तव में कठिन स्थानों पर छोड़ दिया। एक बार जब टूल ने आखिरकार ऐसे परिणाम देना शुरू किया जिन्हें पुनः काम करने की आवश्यकता नहीं थी, तो इसमें विश्वास भी दिखाई दिया।

एआई टूल्स में विश्वास कहां भुगतान करता है

सबसे पहले और सबसे महत्वपूर्ण — कोड लिखने में: जब टूल परियोजना को जानता है और एजेंट पहली समीक्षा करता है, तो टीम एक ही समय में अधिक और बेहतर लिखती है। हमारे मामले में, एआई टूल्स ने काम को लगभग 30-40% तेज कर दिया।

इसके अलावा, एआई ने ऑनबोर्डिंग को आसान बना दिया है। जब कोई नया व्यक्ति परियोजना में शामिल होता है, तो किसी अनुभवी को आमतौर पर परियोजना के कोड के बारे में कई प्रश्नों का सामना करना पड़ता है। अब एजेंट उस भूमिका को निभाता है: यदि परियोजना अच्छी तरह से प्रलेखित है, तो नए लोग 95% प्रश्नों को साथियों के बजाय इसे निर्देशित करते हैं।

यह दस्तावेजीकरण के साथ भी एक समान कहानी है: एक खुरदरा वास्तुशिल्प मसौदा जो पहले घंटों का उपभोग करता था, अब बड़े हिस्से में एजेंट द्वारा लिखा जाता है — हमारे अनुमानों के अनुसार, लगभग 80% मसौदा, यदि आप इसे पर्याप्त संदर्भ देते हैं। जो मानव के लिए बचा है वह रिपॉजिटरी में नहीं है — निर्णय, व्यापार, विशेषज्ञता।

उतना ही महत्वपूर्ण यह ईमानदारी से स्वीकार करना है कि एआई क्या कर सकता है, क्योंकि यही बढ़े हुए अपेक्षाएं हैं जो पहली जगह में निराशा पैदा करती हैं। एआई अनुपालन नहीं लेता — एक मानव चिकित्सा या वित्तीय डेटा पर हस्ताक्षर करता है, और कंपनी मॉडल के बजाय रिसाव के लिए जिम्मेदार है। यह एकीकरण को तेज नहीं करता है — साझेदारों के साथ, जहां दर्जनों घंटे कॉल और समन्वय में लगते हैं।

आउट-ऑफ-द-बॉक्स एआई वास्तव में परेशान करने वाला है — लेकिन केवल जब इसका उपयोग एक समाप्त समाधान के रूप में किया जाता है। निराशा और भुगतान के बीच सारा अंतर यही है कि आप इसके चारों ओर क्या बनाते हैं: एक साझा मानक, आपकी परियोजना का संदर्भ, और डेवलपर की नई भूमिका।