AI एजेंट के लिए फ़ीडबैक बोर्ड: प्रॉम्प्ट आपके यूज़र लिखें

रात 11 बजे एक यूज़र आपको लिखता है। "Safari पर एक्सपोर्ट बटन कुछ नहीं करता।"

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

एक ही माँग, तीन बार लिखी हुई। पहली बार मुफ़्त में लिखी गई थी, उस आदमी के हाथों जिसे बग सचमुच झेलना पड़ा। बाक़ी दो आपके ज़िम्मे हैं।

यही दूसरी और तीसरी लिखाई काम का वह हिस्सा है जिसे एजेंट ने बेतुका बना दिया।

आख़िरी चीज़ जो आप अब भी हाथ से टाइप करते हैं

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

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

इसके बजाय हम उस टेक्स्ट को कच्चे माल की तरह बरतते हैं जिसे दोबारा पकाना है, क्योंकि जिस टूल ने उसे इकट्ठा किया और जिस टूल पर काम होता है, वे कभी एक टूल थे ही नहीं। फ़ीडबैक एक प्रोडक्ट में रहता है, टिकट दूसरे में, और एजेंट उस टर्मिनल में चलता है जो दोनों में से किसी को नहीं जानता।

इस खाई को मिटा दीजिए, फिर दोबारा लिखने वाले क़दम के लिए जगह ही नहीं बचती।

जब बोर्ड ख़ुद अमल कर सके, तो फ़ीडबैक बोर्ड क्या बन जाता है

पब्लिक बैकलॉग एक ऐसा पेज है जहाँ तक आपके यूज़र पहुँच सकते हैं। वे बग बताते हैं, फीचर माँगते हैं, किसी और की माँग को अपवोट करते हैं, बातचीत का धागा पकड़ते हैं और स्थिति बदलते हुए देखते हैं। यहाँ तक यह एक फ़ीडबैक बोर्ड है, और अच्छे फ़ीडबैक बोर्ड पहले से मौजूद हैं।

फ़र्क़ इस बात में है कि टिकट गिरता कहाँ है। वह किसी फ़ीडबैक प्रोडक्ट में एक्सपोर्ट होने के इंतज़ार में नहीं गिरता। वह उसी टास्क बोर्ड पर गिरता है जिससे आपके एजेंट पहले से चलते हैं, पूरे दर्जे के टिकट की तरह, आपके अपने लिखे टिकटों के ठीक बगल में।

वहाँ से उसे In Progress में खिसकाते ही एक एजेंट खड़ा हो जाता है जिसका ब्रीफ़ वही टिकट है: शीर्षक, रिपोर्ट करने वाले के अपने शब्दों में लिखा विवरण, वह पेज जिस पर वह था, वह ब्राउज़र जो उसने इस्तेमाल किया, और उसके बाद से उससे हुई पूरी बातचीत। किसी ने कुछ दोबारा नहीं लिखा। रिपोर्ट ही प्रॉम्प्ट है।

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

तीन दरवाज़े, क्योंकि लोग वहीं बताते हैं जहाँ वे होते हैं

फ़ीडबैक बोर्ड तभी चलता है जब रिपोर्ट करना कहीं और जाकर भड़ास निकालने से सस्ता पड़े। इसका मतलब है लोगों से वहीं मिलना जहाँ समस्या हुई थी।

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

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

तीसरा दरवाज़ा Chrome एक्सटेंशन है, और आदत यही सबसे ज़्यादा बदलता है। आपका यूज़र किसी भी पेज पर गड़बड़ टेक्स्ट चुनता है, एक्सटेंशन पर क्लिक करता है, और टिकट URL तथा चुने हुए हिस्से के साथ दर्ज हो जाता है। आपके पास "काम नहीं कर रहा" नहीं आता, आपके पास पते-ठिकाने वाली रिपोर्ट आती है।

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

रूटिंग, क्योंकि "सही एजेंट" कोई एक एजेंट नहीं होता

बाहर से आया टिकट किसी के नाम नहीं होता। हर इनबॉक्स की असली दिक़्क़त यही है: किसी को तय करना पड़ता है कि इसे उठाएगा कौन।

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

आप चाहें तो टिकट किसी एक एजेंट के बजाय पूरी एजेंट टीम के हवाले कर सकते हैं, ताकि क्लाइंट की माँग आप तक पहुँचने से पहले एक डेव चरण और फिर एक QA चरण से गुज़र जाए।

वह हिस्सा जिसे सब भूल जाते हैं: रिपोर्ट करने वाले को वापस क्या दिखता है

फ़ीडबैक इकट्ठा करना आसान है। चक्र को बंद करने वाली जगह पर ही प्रोडक्ट लोगों को खोते हैं।

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

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

अगर कोई माँग धुँधली आती है, तो रिपोर्ट और काम के बीच टिकट का दायरा तय करना खड़ा रहता है: एक Product Manager एजेंट उस धुँधली माँग को आपके असली प्रोडक्ट के ऐसे मॉकअप में बदल देता है जिसमें बदलाव लागू दिखता है, ताकि कोड की एक पंक्ति लिखे जाने से पहले आप उसी टिकट पर विचार को परख लें।

पारंपरिक टूल कहाँ जाकर रुक जाते हैं

यह मौजूदा खिलाड़ियों पर तंज़ नहीं है। Canny, Featurebase, Fider और UserVoice इकट्ठा करना, दोहराव हटाना और क्रम लगाना अच्छे से करते हैं, और प्रोडक्ट टीम के लिए जो हिस्से मायने रखते हैं, उन पर उनकी सालों की मेहनत चढ़ी है। वे सब एक ही जगह जाकर रुकते हैं, और वजह भी एक ही है, ढाँचे वाली: वे ऐसे संगठनों के लिए बने थे जहाँ इंजीनियरिंग एक अलग विभाग है, जिस तक सिर्फ़ एक्सपोर्ट के रास्ते पहुँचा जा सकता है।

जो पंक्ति फ़ैसला करती है वह आख़िरी है। बड़ी टीम में किसी माँग को स्पेक में बदलना एक असली काम है जिसकी असली क़ीमत है, और वहाँ एक्सपोर्ट अड़चन नहीं है। लेकिन कोडिंग एजेंट के साथ शिप करने वाली एक से पाँच लोगों की टीम में वही दोबारा लिखना ही अड़चन है, और वह शुद्ध नुक़सान है।

यह जिन चीज़ों का हल नहीं है

एजेंट से जुड़ा फ़ीडबैक बोर्ड ऑटोपायलट नहीं है, और उसे ऑटोपायलट मान लेने का नतीजा ठीक वही निकलता है जिसका अंदेशा है।

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

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

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

इसे शुरू कैसे करें

किसी प्रोजेक्ट का बैकलॉग खोलिए, Public backlog पर क्लिक कीजिए, एक URL और दृश्यता का एक मोड चुनिए। पूरा सेटअप इतना ही है, और उसी पल पेज लाइव हो जाता है।

इसके बाद आप क्या करते हैं, यह सेटअप से ज़्यादा मायने रखता है। लिंक वहाँ लगाइए जहाँ आपके यूज़र पहले से हैं: ऐप के भीतर, सपोर्ट के जवाबों में, रिलीज़ नोट्स के नीचे। जिस फ़ीडबैक बोर्ड के बारे में किसी को पता ही नहीं, वह कुछ भी इकट्ठा नहीं करता, और इस फ़ीचर के नाकाम होने की वजह तकनीकी नहीं होती, वजह यह होती है कि लिंक कभी साझा ही नहीं किया गया।

AgentsRoom वह कमांड सेंटर है जिस पर यह सब चलता है: एक टास्क बोर्ड जहाँ कार्ड चलता हुआ एजेंट बन जाता है, उससे जुड़ा एक पब्लिक या निजी फ़ीडबैक पेज, एम्बेड होने वाला विजेट, एक Chrome एक्सटेंशन, और क्लाइंट को जाने वाली वे सूचनाएँ जो काम सचमुच शिप होने पर छूटती हैं। यह Claude Code, Codex, OpenCode, Antigravity CLI, Aider, Grok Build, Mistral Vibe और Kimi Code के साथ चलता है।

AgentsRoom डाउनलोड कीजिए और अपना पहला बोर्ड प्रकाशित कर दीजिए।

अक्सर पूछे जाने वाले प्रश्न

AI एजेंट के लिए फ़ीडबैक बोर्ड क्या है?

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

क्या कोई यूज़र टिकट सचमुच अपने आप एक AI एजेंट चला सकता है?

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

यह Canny, Featurebase, Fider या UserVoice से अलग कैसे है?

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

क्या इसे इस्तेमाल करने के लिए अपना रोडमैप सार्वजनिक करना पड़ता है?

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

पब्लिक बोर्ड को शोर से भर जाने से कौन रोकता है?

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