मेरे कॉमेडी ऐप की सबसे अच्छी समीक्षा चार दोस्तों और ड्रिंक्स के एक राउंड वाली टेबल से आई।
किसी ने कहा, "हमें कोई जोक सुनाओ।" मैंने वही किया जो अब सब करते हैं: फ़ोन उठाया, कुछ खोला, और अंगूठे से स्क्रॉल करने लगा, जबकि पाँच बातचीत मेरे लौटने का इंतज़ार कर रही थीं। यही वह व्यवहार है जिससे बचने के लिए मैंने Knora बनाया था, और मेरा पहला वर्शन उसी तरह उसी टेस्ट में फेल हो गया।
Knora एक मुफ़्त iPhone ऐप है, App Store पर उपलब्ध। आप फ़ोन हिलाते हैं, एक छोटा कॉमेडी बिट एक या दो आवाज़ों में शुरू से आख़िर तक चलता है, और उसके बाद देखने को कुछ नहीं बचता। स्क्रॉल करने के लिए कोई फ़ीड नहीं, ब्राउज़ करने के लिए कोई लाइब्रेरी नहीं, बनाने के लिए कोई अकाउंट नहीं। पूरा इंटरफ़ेस एक इशारा है। इसे भाषा और विषय के कारण 18+ दर्शकों के लिए लिखा गया है — यही इस चीज़ का मक़सद भी है और यही वजह भी कि यह टेबल पर हर किसी के लिए नहीं है।
मैं यहाँ दो चीज़ें हटाकर पहुँचा, और दोनों में से कोई भी हटाव आरामदेह नहीं था। पहले ने एक फॉर्मेट हटाया जिसे यूज़र्स पहले से समझते थे। दूसरे ने ऐप का ज़्यादातर हिस्सा हटा दिया।
पहली चीज़ जो मैंने हटाई वह जोक फॉर्मेट थी
Knora एक knock-knock जोक ऐप के तौर पर शुरू हुआ। यह चला, इस मायने में कि यह माँग पर knock-knock जोक्स बनाता था। दिक्कत यह थी कि फ़ॉर्म ही सीलिंग था। हर knock-knock जोक का ढाँचा एक ही होता है — सेटअप, "who's there", और रिवील — और एक मॉडल उस ढाँचे के अंदर अच्छा जोक लिख सकता है और फिर भी हमेशा सिर्फ़ knock-knock जोक ही बनाएगा। स्ट्रक्चर तय करता था कि ऐप कितना फ़नी हो सकता है, और कितनी भी prompt मेहनत स्ट्रक्चर को हरा नहीं सकती थी।
तो मैंने फॉर्मेट हटा दिया। इसका मतलब था वह चीज़ हटाना जिसे लोग पहचानते थे — जो उस प्रोडक्ट के साथ करने के लिए अजीब चीज़ है जो अभी-अभी काम करने लगा था।
उसकी जगह एक टेम्पलेट की बजाय कॉमिक methods का एक सेट आया। हर बिट ठीक एक method से बना है, कभी कई का मिश्रण नहीं: एक असली बेतुका नियम किसी छोटी-सी चीज़ पर लागू, या एक कहानी जो अपना समय लेती है और फिर पलटती है, या कुछ ऐसा जो तारीफ़ की तरह खुलता है और तारीफ़ नहीं है। चार लाइव हैं। जनरेटर हर बिट के लिए एक चुनता है; ऐप कभी नहीं चुनता।
उस एक बदलाव ने आउटपुट के लिए उससे कहीं ज़्यादा किया जितना इससे पहले के हर prompt रिवीज़न ने किया था। यही पहला असहज सबक़ है: कभी-कभी मॉडल कभी bottleneck ही नहीं था। कंटेनर था।
दूसरी चीज़ जो मैंने हटाई वह इंटरफ़ेस थी
स्क्रीन हटाना ज़्यादा मुश्किल था, क्योंकि स्क्रीन ही वह तरीक़ा है जिससे आप यूज़र्स को दिखाते हैं कि आपने कुछ बनाया है।
टेबल पर खुला ऐप टेबल से मुक़ाबला करता है। मैंने जो भी एलिमेंट जोड़ा — आवाज़ों की ब्राउज़ करने लायक सूची, आपको पसंद आए बिट्स की लाइब्रेरी, एक छोटा-सा प्रोफ़ाइल — उसने फ़ोन को ड्रिंक्स थामे लोगों से ज़्यादा दिलचस्प बना दिया। ब्रीफ़ "एक अच्छा कॉमेडी ऐप बनाओ" से बदलकर "एक इशारा, फिर फ़ोन वापस नीचे" हो गया।
तो न कोई onboarding है और न कोई sign-in। आप चाहें तो एक आवाज़ और भाषा चुन सकते हैं, वरना पहली बार खोलने पर एक रैंडम सुनाने वाला चुन लिया जाता है और आप settings स्क्रीन कभी खोलते ही नहीं। ट्यून करने के लिए कोई personalisation नहीं है, जिसका मतलब है कि ग़लत होने के लिए भी कोई personalisation नहीं है।
बिना माइक वाले सिर्फ़-आवाज़ कॉमेडी ऐप को थोड़ी व्याख्या चाहिए, तो सीधे शब्दों में: यह कभी सुनता नहीं। ज़ोर से कहने के लिए कुछ नहीं और टाइप करने के लिए कुछ नहीं। बिट एक सर्वर पर लिखा जाता है और audio के रूप में फ़ोन पर भेजा जाता है; फ़ोन एक स्पीकर है जिसके साथ एक shake detector लगा है।
"बिना UI" असल में क्या मजबूर करता है
इंटरफ़ेस हटाना सबसे पहले पसंद का फ़ैसला था। ऐसी दुनिया में जहाँ हर ऐप notifications और भरे-भरे screens के साथ आपका attention माँगता है, मुझे एक लगभग काली screen चाहिए थी जिसे आप shake करके चलाते हैं। पर उस फ़ैसले के साथ engineering constraints का एक सेट भी आता है, और वही लिखने लायक है।
हर shake तुरंत होना चाहिए। अगर किसी बिट को दिखने में छह सेकंड लगें, तो टेबल आगे बढ़ चुकी है और फ़ोन फिर से मुँह के बल रखा है। इसलिए बिट्स पहले से लिखे और आवाज़ दिए जाते हैं और एक catalog से सर्व किए जाते हैं। Live generation मौजूद है, पर fallback और refill के तौर पर — वह चीज़ जो catalog को बासी होने से रोकती है, वह रास्ता नहीं जिस पर यूज़र इंतज़ार करता है।
ब्राउज़िंग नहीं तो चुनना नहीं। चुनने के लिए सूची न होने पर ऐप कोई style और कोई model choice नहीं भेजता। Backend एक method निकालता है, कई draft लिखता है, और कोई audio बनने से पहले सबसे अच्छा रख लेता है। फ़ैसला सर्वर पर चला गया क्योंकि स्क्रीन पर उसे रखने की जगह ही नहीं थी।
एक बिट क़रीब पचहत्तर सेकंड तक सीमित है। यह तकनीकी सीमा नहीं है; यह टेबल-लंबाई का बजट है। कहानी सुनाने के लिए काफ़ी लंबा, इतना छोटा कि टेबल पर कोई भी ऐसी चीज़ के तीसरे मिनट तक न रुके जो चल नहीं रही।
Client 2.5 MB का है। ऐप में लगभग कुछ भी नहीं है, क्योंकि ऐप में लगभग कुछ भी होना ही नहीं चाहिए।
लिखने वाला बदला जा सकता है। Production में Gemini 3.8 Flash चलता है, और moderation तथा best-of-N चुनाव एक अलग मॉडल करता है। लिखने वाले को बदलना एक config बदलाव है और कोई ऐप release बिल्कुल नहीं — यह तब मायने रखता है जब आपका इस्तेमाल किया मॉडल हर कुछ महीनों में बदल दिया जाता है।
आप टेस्ट को automate नहीं कर सकते
सबसे काम की चीज़ जो मैंने सीखी वह evaluation के बारे में है, और यह कॉमेडी से कहीं आगे तक लागू होती है।
चार अलग-अलग मौक़ों पर, automated judges ने ऐसे आउटपुट को ऊँचे अंक दिए जिन्हें मेरे अपने कान ने फ़नी नहीं कहा। चार बार। एक मॉडल आपको बता सकता है कि स्ट्रक्चर सही है या नहीं, method पहचानने लायक है या नहीं, पलटाव सही जगह आता है या नहीं। यह नहीं बता सकता कि पलटाव बैठता है या नहीं। मैं इसे बार-बार कराने की कोशिश करता रहा, और यह बार-बार ख़ुद से सहमत होता रहा।
तो मैंने समस्या को दो हिस्सों में बाँटा। Mechanical checks उन चीज़ों की रखवाली करते हैं जो mechanically जाँची जा सकती हैं: गढ़े हुए आंकड़े, रटा हुआ source text, किसी लाइन के बीच से लीक हुई stage direction, किसी समूह, शरीर, बीमारी या शोक पर नीचे वार करने वाली कोई भी चीज़। बाक़ी सब कान तय करता है, और मैंने उसे सौंपने की कोशिश करना छोड़ दिया।
अगर आप AI features ship करते हैं, तो यही बँटवारा काम का बड़ा हिस्सा है। क्वालिटी का वह हिस्सा ढूँढिए जो सचमुच verifiable है और उसे बिना किसी माफ़ी के automate कर दीजिए। फिर ईमानदार रहिए — ख़ुद से और हर उस व्यक्ति से जो पूछे — कि बाक़ी judgment है, और कितने भी rubric इसे judgment होने से नहीं रोक सकते।
इस प्रोजेक्ट का README यह साफ़ कहता है, और मुझे इससे बेहतर शब्द नहीं मिले: कॉमेडी पर कभी किसी automated pass पर भरोसा मत कीजिए।
जो मैंने जान-बूझकर छोड़ा
दो फ़ैसले जो कमियों जैसे लगते हैं, और एक जो सचमुच कमी है।
मैं देख नहीं सकता कि ऐप कैसे इस्तेमाल होता है। कोई analytics SDK नहीं, कोई अकाउंट नहीं, कोई पर्सनल डेटा नहीं। प्राइवेसी का दावा सच्चा है, और क़ीमत भी सच्ची है: मुझे नहीं पता कौन-से बिट्स बैठते हैं, कौन-सी आवाज़ें छोड़ी जाती हैं, या कितने लोग इसे दो बार खोलते हैं। मुझे तब पता चलता है जब कोई मुझे बताता है।
कोई share button नहीं है। यह एक दाँव है, और मैं ग़लत हो सकता हूँ। शेयर करना ही वह तरीक़ा है जिससे एक कॉमेडी ऐप आम तौर पर फैलता है, और मैंने जान-बूझकर वह mechanism नहीं बनाया। दाँव यह है कि फ़ोन टेबल पर एक हाथ से दूसरे हाथ जाता है, न कि link किसी group chat में घूमता है। अगर वह ग़लत निकला, तो सुधार साफ़ है और शायद बहुत देर हो चुकी है।
अभी कोई ratings नहीं हैं। यह नया है। वह design का चुनाव नहीं है, बस लोगों की कमी है।
असहज हिस्सा, अगर आप media में काम करते हैं
मेरा रोज़ का काम media operations है। जिस नंबर को मैंने पूरा करियर optimize किया है वह attention है: site पर समय, session की लंबाई, लौटने की बारंबारता। Knora ऐसे बनाया गया है कि फ़ोन टेबल का ध्यान किसी भी bit से ज़्यादा देर न रोके। एक shake, एक bit, फ़ोन नीचे — और जब टेबल को एक और चाहिए, आप फिर shake कर सकते हैं।
जिस तरह मैं media मापता हूँ, उस हिसाब से यही अजीब हिस्सा है। इसे वापस खींचने वाला कोई feed नहीं, बढ़ाने के लिए कोई session नहीं, और जोक से आगे तक पकड़े रखने के लिए कुछ भी नहीं बनाया गया। इसकी जगह एक वजह है इसे दोबारा उठाने की — एक bit जो अगले shake के लायक मज़ेदार हो। उसके बाद, यह छोड़ देता है।
मुझे नहीं लगता कि यह इसे attention के पीछे भागने वालों से बेहतर प्रोडक्ट बनाता है। पर यह एक काम का याद दिलाने वाला है कि "ज़्यादा engagement" इस बात का चुनाव है कि आप क्या बना रहे हैं, प्रकृति का नियम नहीं। और वह चुनाव एक ऐसे side project में कहीं ज़्यादा आसान है जिसके लिए कोई पैसे नहीं दे रहा।
अगर आपने कुछ ऐसा बनाया है जो attention पकड़ने के बजाय वापस लौटाता है, तो मैं सच में जानना चाहूँगा कि आपने उस पर कैसे सोचा — यह ऐसा design space नहीं है जहाँ मैं दिन में ज़्यादा समय बिताता हूँ।
ऐप App Store पर मुफ़्त है, और design पर मेरे नोट्स यहाँ हैं। अगर आप इसे आज़माएँ और कोई बिट न बैठे, तो मुझे बताइए। पूरा ऐप ही जोक है।
शुभकामनाओं सहित, Chandler