एआई टीम की असंगति ठीक नहीं करता, बस उसे ढक देता है।

जिन्न की समस्या

एआई के बारे में सोचते समय मैं बार-बार एक ही बात पर लौटता हूँ। एआई किसी जिन्न की तरह है। आप जो कहते हैं, वह वही करता है; जो आप कहना चाहते थे, वह नहीं। और इन दोनों के बीच की दूरी में ही बहुत सारा उत्पाद-कार्य बिखर जाता है।

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

इंजीनियरिंग टीम उसे उठाती है, लिखे हुए शब्दों के आधार पर कुछ समझदार बनाती है, और दो हफ्ते बाद समीक्षा में हर कोई किसी न किसी रूप में यही कह रहा होता है: मेरा मतलब यह नहीं था।

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

सबसे कमजोर आधार

ज़रा सोचिए, किसी उत्पाद की असली समझ आखिर रहती कहाँ है। आपका कोडबेस आपकी संरचना, नामकरण, निर्भरताएँ और अमल की सीमाएँ जानता है। आपके डिजाइन फ़ाइलें आपकी दृश्य भाषा, परस्पर क्रिया के ढर्रे और उन फैसलों को जानती हैं जिन्हें आपने इतना दोहराया है कि वे व्यवस्था बन चुके हैं। पुराने टिकट और दस्तावेज़ टीम की शब्दावली और समझौतों को रखने का तरीका जानते हैं।

Jira टिकट को इनमें से लगभग कुछ भी नहीं पता होता। अक्सर वही पूरे कामकाजी ढाँचे में संदर्भ के लिहाज़ से सबसे गरीब चीज़ होता है। इसलिए जब कोई टीम किसी टिकट को एआई उपकरण में चिपकाकर बेहतर गुणवत्ता वाली आउटपुट की उम्मीद करती है, तो असल में वह सबसे कमजोर जानकारी से सबसे अच्छा जवाब माँग रही होती है।

इसी वजह से परिणाम अक्सर भरोसेमंद-सा सुनाई देता है, पर ठीक से बैठता नहीं। स्वीकृति मानदंड गलत उपयोगकर्ता को मान लेते हैं। डिजाइन सुझाव ऐसे रूप में भटक जाते हैं जिन्हें आप कभी जारी नहीं करेंगे। तकनीकी सिफारिशें आपके तकनीकी ढाँचे, तैनाती के तरीके या उन शॉर्टकट्स को नज़रअंदाज़ कर देती हैं जिन्हें आपकी टीम जानबूझकर नहीं अपनाती। एआई “गलत” नहीं कर रहा होता। वह बस बहुत कमजोर ब्रीफ़ से जितना हो सकता है, उतना कर रहा होता है।

आत्मविश्वास भरी बेतुकी बात

ज़्यादातर Jira एआई उपकरण एक ही तरह चलते हैं। issue खोलिए। बटन दबाइए। विवरण, स्वीकृति मानदंड और शायद कुछ उप-कार्य मिल जाते हैं। अनुभव इसलिए उत्पादक लगता है क्योंकि परिणाम तेज़, व्यवस्थित और साफ-सुथरा दिखता है।

आम तौर पर यह कुछ यूँ होता है:

• issue खोलिए;
• बटन दबाइए;
• एक साफ पाठ, मानदंड और शायद उप-कार्य पा लीजिए।

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

यहीं असली खतरा है: कचरा अंदर, कचरा बाहर, बस अब उस कचरे के साथ शीर्षक, बुलेट और पक्के यक़ीन का लहजा जुड़ गया है। टीम एक ही समय में ज़्यादा भरोसे और कम स्पष्टता के साथ अमल की तरफ बढ़ सकती है।

एआई को सचमुच क्या चाहिए

Jira issue के लिए एआई से सचमुच उपयोगी कुछ निकलवाना है, तो उसे उस दुनिया की चार बातें समझनी होंगी जिसमें वह काम कर रहा है:

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

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

अगर आप इस संदर्भ-स्तर का व्यावहारिक रूप देखना चाहते हैं, तो आपका एआई आपके उत्पाद का अंदाज़ा लगा रहा है में मैंने बताया है कि क्या सँभालकर रखना चाहिए और उसे बार-बार कैसे इस्तेमाल करना चाहिए।

आपका कोड ज़्यादा जानता है

आज के कोडिंग एजेंटों की सचमुच मजबूत बात यह है कि वे भंडार को पढ़कर उसे साधारण भाषा वाले संदर्भ में बदलने में अच्छे हैं। आप Claude Code, Codex या किसी और सक्षम कोडिंग एजेंट को अपने भंडार की ओर भेजकर उससे यह कह सकते हैं कि वह markdown में उत्पाद का उद्देश्य, तकनीकी ढाँचा, अमल की सीमाएँ, ज्ञात खाली जगहें और व्यावसायिक संकेतों का सार लिख दे। इसमें कुछ मिनट लगते हैं, हफ्तों की दस्तावेज़ी मेहनत नहीं।

यहीं समीकरण बदलता है। दो वाक्यों वाले टिकट के सहारे एआई से अँधेरे में कुछ बनवाने के बजाय, आप उसे उत्पाद, डिजाइन व्यवस्था, उपयोगकर्ता समूह और तकनीकी ढाँचे का ठोस सार दे सकते हैं। तब मॉडल अँधेरे में अंदाज़ा नहीं लगाता; वह ऐसी दुनिया के भीतर तर्क करता है जो सचमुच आपकी परियोजना जैसी लगती है।

ये जवाब पूरे समय आपके कोडबेस में मौजूद थे। घटकों के नाम डिजाइन-भाषा दिखाते हैं। डोमेन मॉडल बताते हैं कि उत्पाद कैसे सोचता है। एकीकरण और पुस्तकालय तकनीकी सीमाओं को उजागर करते हैं। संदर्भ आपको शून्य से गढ़ना नहीं है। आपको बस उसे ऐसे रूप में निकालना है जिसे दूसरी एआई भरोसे के साथ इस्तेमाल कर सके।

छिपे हुए फैसले

परियोजना-संदर्भ अच्छा हो, तब भी एक दूसरी समस्या बची रहती है जिसे एआई अंदाज़े से हल नहीं कर सकता: वे फैसले जो अभी किसी ने किए ही नहीं। हर Jira issue अपने भीतर अनुमति-नियम, चरणबद्ध रिलीज़, किनारी स्थितियाँ, पिछली संगतता, परस्पर क्रिया के ब्योरे और यहाँ तक कि “वास्तविक उपयोगकर्ता तक पहुँचने पर सफलता दिखेगी कैसी” जैसी धारणाएँ छिपाए रहती है।

ये फैसले काम शुरू होते ही गायब नहीं हो जाते। वे बस sprint के बीच में फिर सामने आते हैं, और वही उन्हें देखने का सबसे महँगा समय होता है। डिजाइनर पूछता है कि किस मौजूदा स्क्रीन को आधार माना जाए। इंजीनियर जानना चाहता है कि क्या इस प्रवाह के लिए पहले से कोई API मौजूद है। किसी को पता चलता है कि स्वीकृति मानदंड ने तो लॉग-इन उपयोगकर्ता मान लिए थे, जबकि अनुभव का आधा हिस्सा अनाम है। बाद में यह सब चौंकाने वाला नहीं लगता। यह सब शुरू से वहीं था।

इसीलिए सिर्फ संदर्भ काफ़ी नहीं है। सवाल भी चाहिए, और वे सवाल ठोस होने चाहिए, जो टिकट और वास्तविक उत्पाद-संदर्भ दोनों से जुड़े हों। क्या यह मौजूदा उपयोगकर्ताओं पर भी लागू होगा या सिर्फ नए लोगों पर? अगर ब्राउज़र बीच में बंद हो जाए तो क्या होगा? क्या यह सुविधा सिर्फ प्रशासकों के लिए है? क्या यह एक बार की क्रिया है या दोहराया जाने वाला व्यवहार? कुछ ईमानदार जवाब अक्सर एक और चमकदार विशिष्टता-पत्र से ज्यादा समझ पैदा करते हैं।

Just में यह कैसे चलता है

ठीक यही प्रक्रिया मैंने Just: AI Assistant for Jira में बनाई है:

1. पहले परियोजना-संदर्भ एक बार चार संरचित खानों में तय कीजिए: उत्पाद-सार, डिजाइन व्यवस्था, उपयोगकर्ता समूह और तकनीकी ढाँचा। Just आपको ऐसे संकेत भी देता है जिन्हें आप Claude Code या किसी भी कोडिंग एजेंट से गुजारकर सीधे भंडार से ये सार निकलवा सकते हैं। एक बार परिणाम चिपकाइए, फिर वही संदर्भ आगे आने वाले टिकटों में बार-बार काम आता है।
2. फिर Jira issue खोलिए। हर काम के लिए अलग से prompt-साधना या अतिरिक्त सेटअप की ज़रूरत नहीं। Just उस issue को आपके सहेजे हुए संदर्भ के साथ पढ़ता है और ऐसे संकेत निकालता है जो सचमुच आपकी परियोजना के अनुसार ढले हों। उसके बाद वह स्पष्टीकरण वाले सवाल पूछता है जो सामान्य नहीं होते, बल्कि आपके उत्पाद, आपकी तकनीकी हकीकत और आपकी डिजाइन-भाषा पर टिके होते हैं।
3. फिर योजना बनती है। Just उन जवाबों को आवश्यकताओं, डिजाइन-दिशा, किनारी स्थितियों, अपेक्षित परिणामों और ऐसी संरचित कार्य-योजना में बदल देता है जिस पर टीम सच में काम कर सके। ज़रूरत पड़ने पर वह ताज़ा वेब-संदर्भ भी जोड़ सकता है, और यह पाँचों बड़े एआई प्रदाताओं के साथ काम करता है ताकि हर चरण पर सबसे उपयुक्त मॉडल चुना जा सके। लक्ष्य जादुई लगना नहीं है। लक्ष्य यह है कि टीम सही चीज़ बनाए, सिर्फ तेज़ी से कुछ बना न दे। पूरा प्रवाह आप aiapps.me पर देख सकते हैं।

इससे क्या बदलता है

तो फिर ज़्यादातर Jira एआई उपकरण समझ की समस्या को कम करने के बजाय बढ़ाते क्यों हैं? क्योंकि वे आम तौर पर तब आते हैं जब अस्पष्टता पहले ही टिकट के भीतर घुस चुकी होती है, और फिर बस उसे चमकदार, पूरा और भरोसेमंद दिखा देते हैं।

असली ताकत इससे पहले है। टीम को पहले साफ समझना होगा कि वह वास्तव में चाहती क्या है, अमल शुरू होने से पहले छिपे फैसलों को सामने लाना होगा, और एआई को इतना संदर्भ देना होगा कि वह उत्पाद के वास्तविक ढाँचे के भीतर काम करे, न कि कमजोर विवरण से अंदाज़ा लगाए।

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