मैं एक मैक-विशेष मीटिंग रिकॉर्डिंग और ट्रांसक्रिप्शन ऐप बना रहा हूँ जिसका नाम Kanary है, जिसमें मैं Claude Code (Opus 4.8) / Codex (GPT-5.5) का उपयोग कर रहा हूँ। कुछ लोगों को यह कल्पना करना मुश्किल लग सकता है कि डेवलपमेंट में "vibe coding" वास्तव में कैसे काम करता है।
इस बार, मैं Opus की महानता के बारे में लिखना चाहता हूँ, जो विशेष रूप से एक डिज़ाइनर और उच्च-स्तरीय विनिर्देश सलाहकार के रूप में काम करता है।
इस बार की चुनौती रिकॉर्डिंग को रोकना भूल जाने की समस्या है। यह वर्तमान में उपयोगकर्ताओं से सबसे अधिक रिपोर्ट की जाने वाली समस्या है।
नीचे संवाद है: Me > Claude > Codex > Claude।
Me
रिकॉर्डिंग रोकने के संबंध में: चूँकि Kanary विंडो बंद होने पर मेनू बार में केवल एक लाल बिंदु दिखाता है, और यह किसी विशिष्ट ऐप से बंधे बिना सभी वैश्विक माइक/स्पीकर ऑडियो को संश्लेषित करता है, इसलिए सैद्धांतिक रूप से मीटिंग के अंत का पता लगाना असंभव है। परिणामस्वरूप, कई उपयोगकर्ता मीटिंग के बाद घंटों की चुप्पी रिकॉर्ड कर लेते हैं। मैंने अभी-अभी समस्या को रोकने के लिए शुरुआत और अंत को ट्रिम करने की सुविधा जोड़ी है, लेकिन मुझे लगता है कि असली लक्ष्य उपयोगकर्ता को यह एहसास कराना है कि मीटिंग समाप्त हो गई है।
मेरे पास अभी तक दो विचार हैं:
- यदि माइक/स्पीकर से आवाज़ 5 मिनट तक लगभग शांत रहती है तो एक सूचना जारी करें।
- रिकॉर्डिंग शुरू होने पर एक मिनी प्लेयर प्रदर्शित करें ताकि इसे बिना ध्यान दिए चलने देने की स्थिति को रोका जा सके।
दोनों के अपने फायदे और नुकसान हैं। आप क्या सोचते हैं?
Claude
सीधे मुद्दे पर आते हैं, ये दोनों समस्या की अलग-अलग परतों को संबोधित करते हैं, और जो मूल (= उन्हें अंत का एहसास दिलाना) पर प्रहार करता है, वह टाइप 1 दृष्टिकोण है। हालाँकि, 1 और 2 दोनों में अपनी-अपनी कमजोरियाँ हैं; जीतने वाली चाल इस बात में निहित है कि आप उन्हें कैसे जोड़ते हैं। आइए इसे तोड़कर देखें।
पहले, आइए विफलता मोड की परिभाषा पर सहमत हों
"घंटों की खाली रिकॉर्डिंग" की स्थिति, परिभाषा के अनुसार, इसलिए होती है क्योंकि उपयोगकर्ता स्क्रीन के सामने नहीं है या उसे देख नहीं रहा है। यह मूल्यांकन अक्ष का मूल है।
- 2 (मिनी प्लेयर) एक दृश्य सुविधा है → यह केवल स्क्रीन देखने वाले लोगों तक पहुँचता है। यह उन मामलों में काम करता है जहाँ कोई "अपनी डेस्क पर है लेकिन अन्य काम में डूबा हुआ है," लेकिन यह सैद्धांतिक रूप से मुख्य समस्या तक पहुँचने में विफल रहता है: "डेस्क छोड़ दिया / पीसी से दूर चला गया।" यह उस स्थिति में काम नहीं करता जहाँ इसकी सबसे अधिक आवश्यकता है।
- 1 (सूचना) स्क्रीन के बाहर तक पहुँचती है → यह नोटिफिकेशन सेंटर, लॉक स्क्रीन, और (यदि मिरर किया गया हो) iPhone तक जाती है। विफलता मोड के साथ अनुकूलता 1 के साथ कहीं बेहतर है।
तो, यदि हम मूल पर निशाना लगा रहे हैं, तो हम 1 पर आधारित हैं।
प्रत्येक प्रस्ताव की कमजोरियाँ
1 की कमजोरी गलत सकारात्मकता है। चुप्पी ≠ मीटिंग का अंत। वास्तविक मीटिंग में चुप्पी सामान्य रूप से होती है (दस्तावेज़ पढ़ना, सोचना, ब्रेक, स्क्रीन शेयर के माध्यम से एक मूक वीडियो दिखाना, आदि)। 5 मिनट की सीमा "छोटा = कष्टप्रद / लंबा = खाली जगह रहती है" के बीच एक समझौता है, जो आसानी से ट्यूनिंग नर्क बन जाता है। यदि कुछ बार गलत ट्रिगर होते हैं, तो सूचना में विश्वास मर जाता है, जो सबसे डरावना हिस्सा है।
2 की कमजोरी आदत और स्क्रीन शेयर लीक है। एक निरंतर प्रदर्शन एक सप्ताह के भीतर वॉलपेपर बन जाता है और अनुभूति से गायब हो जाता है। इसके अलावा, एक मीटिंग टूल की प्रकृति को देखते हुए, साझा स्क्रीन पर एक रिकॉर्डिंग संकेतक दिखाई देना सूचना रिसाव और सौंदर्य दोनों के संदर्भ में एक दुर्घटना है।
जीतने वाली चाल: केवल चुप्पी से मत आंकिए। "चुप्पी और उपयोगकर्ता निष्क्रिय"
1 की गलत सकारात्मकता की समस्या लगभग गायब हो जाती है यदि आप एक और संकेत जोड़ते हैं।
- ऑडियो RMS सीमा से नीचे है (दोनों माइक + स्पीकर) प्लस
- HID निष्क्रिय समय (CGEventSourceSecondsSinceLastEventType / IOKit, कोई कीबोर्ड/माउस संचालन नहीं), और आदर्श रूप से डिस्प्ले स्लीप / स्क्रीन लॉक।
इस AND तर्क को लेने से निर्णय "चुप्पी" से बदलकर "मीटिंग समाप्त हुई और व्यक्ति चला गया" हो जाता है। यह लगभग कभी गलत सकारात्मकता को ट्रिगर नहीं करता है। मीटिंग के दौरान चुप्पी इसे ट्रिगर नहीं करेगी क्योंकि उपयोगकर्ता अपनी डेस्क पर है और कंप्यूटर का संचालन कर रहा है, इसलिए वे "निष्क्रिय" नहीं हैं।
और यदि यह शर्त पूरी होती है, तो तथ्य यह है कि हम सुरक्षित रूप से एक ऑटो-स्टॉप को ट्रिगर कर सकते हैं बहुत बड़ा है:
- उपयोगकर्ता संचालन कर रहा है (मौजूद) → कुछ भी हो, ऑटो-स्टॉप या सूचित न करें। व्यक्ति देख रहा है, और मेनू बार में लाल बिंदु है। उन पर भरोसा करें। (यह वह जगह है जहाँ 2 में मिनी प्लेयर काम करता है)।
- निष्क्रिय लेकिन ऑडियो मौजूद → वेबिनार जैसी वैध रिमोट रिकॉर्डिंग की संभावना। रोकें नहीं।
- निष्क्रिय और चुप → यह "मीटिंग समाप्त + चले गए" की एकमात्र पुष्टि की गई स्थिति है → सूचित करें → यदि कोई प्रतिक्रिया नहीं, तो ऑटो-स्टॉप।
चूँकि वे डेस्क छोड़ चुके हैं, ऑटो-स्टॉप के साथ मीटिंग के बाकी हिस्से को खोने का जोखिम संरचनात्मक रूप से शून्य है। चूँकि ट्रिम सुविधा पीछे की चुप्पी को साफ करती है, रोकने के बिंदु पर सामग्री भी साफ है। सूचना की एक सीढ़ी (लंबी अवधि के काम के लिए एक भागने का मार्ग) → M मिनट के बाद ऑटो-स्टॉप (छोड़ने वाले उपयोगकर्ताओं के लिए स्व-उपचार) बनाकर, यह खुद को ठीक कर लेता है भले ही उपयोगकर्ता सूचना पर ध्यान न दे।
हमें क्यों रोकना चाहिए, न कि केवल "उन्हें एहसास दिलाना"
सिर्फ ट्रिम करने के बजाय मूल पर टिके रहने का कारण गोपनीयता है। मीटिंग के बाद घंटों तक कमरे का ऑडियो उठाना एक दुर्घटना है जिसमें मीटिंग से असंबंधित निजी बातचीत की रिकॉर्डिंग शामिल है। यही कारण है कि मैं केवल "उन्हें एहसास दिलाने (निष्क्रिय)" के बजाय दूर होने पर रोकने की सक्रिय दिशा के लिए जोर देता हूँ।
सारांश
- मुख्य अक्ष = 1 का बेहतर संस्करण: चुप्पी और निष्क्रिय → सूचना → ऑटो-स्टॉप सीढ़ी। विफलता मोड पर सीधा प्रहार करता है, गलत सकारात्मकता को कुचलता है, और गोपनीयता की रक्षा करता है।
- 2 = सहायक: अपनी डेस्क पर उपयोगकर्ताओं के लिए एक एम्बिएंट डिस्प्ले के रूप में मूल्यवान, लेकिन कम प्राथमिकता। यदि शामिल किया जाता है, तो स्क्रीन शेयरिंग के दौरान स्वचालित रूप से छिपाना/छोटा करना अनिवार्य है।
- मेनू बार लाल बिंदु में बीता हुआ समय प्रदर्शन जोड़ना सस्ता है लेकिन जागरूकता बढ़ाता है कि "यह अभी भी रिकॉर्ड कर रहा है," इसलिए इससे कोई फर्क नहीं पड़ता कि आप किस रास्ते पर जाते हैं, इसे तुरंत करना उचित है।
प्रति-तर्क के रूप में, कोई ऑटो-स्टॉप को "मनमाने ढंग से उपयोगकर्ता सामग्री काटने" के रूप में नापसंद कर सकता है। उस स्थिति में, समझौता एक सूचना पर रुकना होगा, निष्क्रिय स्थिति के साथ गलत सकारात्मकता को समाप्त करके सूचना को विश्वसनीय बनाना होगा। एक बार जब आप तय कर लेते हैं कि पूरी तरह से ऑटो-स्टॉप पर जाना है या सूचना पर रुकना है, तो कार्यान्वयन नीति निर्धारित हो जाती है।
Codex
मुझे लगता है कि Claude की राय बहुत सही है। विशेष रूप से यह संगठन कि "1 और 2 अलग-अलग परतें हैं" और "चुप्पी और निष्क्रिय" तर्क मजबूत है।
यहाँ बताया गया है कि मैं कैसे प्राथमिकता दूंगा:
- चुप्पी और निष्क्रिय पर सूचित करें
- दोनों माइक/स्पीकर लगभग शांत
- कोई कीबोर्ड/माउस संचालन नहीं
- आदर्श रूप से स्क्रीन लॉक/डिस्प्ले स्लीप को ध्यान में रखें
- 5 मिनट के बाद, एक सूचना: "रिकॉर्डिंग जारी है। रोकें?"
- सूचना के बाद एक निश्चित समय तक कोई प्रतिक्रिया नहीं होने पर ऑटो-स्टॉप
- यह उत्पाद दर्शन पर निर्भर करता है, लेकिन मुझे लगता है कि इसे शामिल करना ठीक है।
- कारण वही है जो Claude ने कहा: यह भंडारण की समस्या नहीं है, यह गोपनीयता की समस्या है।
- हालाँकि, शुरू में, इसे सेटिंग्स में टॉगल करने योग्य होना चाहिए, या कम से कम "अनुशंसित चालू"।
- मेनू बार लाल बिंदु पर रिकॉर्डिंग समय दिखाएं
- सस्ता और प्रभावी।
- जैसे ● 1:24:03, ताकि उन्हें पता चले कि "यह अभी भी रिकॉर्ड कर रहा है" भले ही विंडो बंद हो।
- यह अभी करने लायक है।
जहाँ तक मिनी प्लेयर का सवाल है, मैं इसे मुख्य समाधान के रूप में प्राथमिकता से हटा दूंगा। कारण यह है कि "भूलकर छोड़ देने" का सबसे बड़ा मामला तब होता है जब वे स्क्रीन नहीं देख रहे होते हैं या अपनी सीट छोड़ चुके होते हैं। मिनी प्लेयर वहाँ उन तक नहीं पहुँचता। साथ ही, स्क्रीन शेयर में दिखने का जोखिम थोड़ा कष्टप्रद है।
ऐसा नहीं है कि मिनी प्लेयर बेकार है, लेकिन इसकी एक अलग भूमिका है। यह "काम के दौरान स्वाभाविक रूप से याद दिलाने के लिए प्रभावी है कि रिकॉर्डिंग चल रही है।" लेकिन "मीटिंग के बाद घंटों तक रिकॉर्डिंग की दुर्घटना को रोकने" के लिए, सूचना/ऑटो-स्टॉप अधिक सीधा निशाना लगाता है।
मेरी अनुशंसित विशिष्टता यह है:
यदि रिकॉर्डिंग के दौरान माइक/स्पीकर लगभग शांत है और उपयोगकर्ता निष्क्रियता 5 मिनट तक जारी रहती है, तो सूचित करें। यदि सूचना के बाद अगले 5 मिनट तक कोई प्रतिक्रिया नहीं होती है, तो ऑटो-स्टॉप। रोकने के बाद, पीछे की चुप्पी को ट्रिम करें और सहेजें।
इस सेटअप के साथ, मीटिंग के दौरान चुप्पी में रुकना मुश्किल है, और यह उन मामलों में नहीं रुकेगा जहाँ ऑडियो चल रहा है, जैसे वेबिनार देखना। इसके अलावा, यह सबसे समस्याग्रस्त स्थिति में स्व-उपचार कर सकता है: "डेस्क से दूर और सूचना पर ध्यान देने में असमर्थ।"
एक बात ध्यान देने योग्य: "लगभग शांत" की सीमा उपयोगकर्ता के वातावरण के अनुसार बहुत भिन्न होती है, इसलिए निश्चित मान गड़बड़ हो सकते हैं। रिकॉर्डिंग शुरू होने के बाद परिवेशी शोर सीखना और अपेक्षाकृत "चुप्पी जैसी" स्थितियों की तलाश करना बेहतर होगा। यह शुरू में मोटा हो सकता है, लेकिन यह भविष्य में अनुभव की गुणवत्ता निर्धारित करेगा।
अंत में, मैं Claude प्रस्ताव से दृढ़ता से सहमत हूँ। हालाँकि, मैं "मूल उन्हें एहसास दिलाना है" से एक कदम आगे बढ़कर वास्तव में उनके जाने पर रुकना चाहूंगा। यह विश्वास की भावना कि Kanary स्वचालित रूप से आपकी रक्षा करेगा, इस समस्या के लिए बेहतर है।
Claude
सहमत हूँ। मैं उनके जाने पर रुकने तक जाने के पक्ष में हूँ। सीढ़ी प्रारूप (चुप्पी + निष्क्रिय 5 मिनट → सूचना → और 5 मिनट → ऑटो-स्टॉप → पीछे की ट्रिम) ठोस है। इसके ऊपर, मैं 4 बिंदु जोड़ूंगा जो कार्यान्वयन में अंतर लाएंगे।
1. सीमा की बात वैसी ही है जैसा Codex ने कहा, और यह अनुभव की गुणवत्ता निर्धारित करता है। आइए डिज़ाइन को और अधिक विशिष्ट बनाएं।
निश्चित dB सीमाएँ पर्यावरणीय अंतरों के कारण निश्चित रूप से गड़बड़ होंगी, इसलिए सही उत्तर रिकॉर्डिंग सत्र के भीतर सापेक्ष मूल्यों को देखना है। रिकॉर्डिंग के पहले कुछ दर्जन सेकंड से मिनटों में "भाषण के दौरान सक्रिय वॉल्यूम रेंज (माध्यिका)" को रोलिंग-सीखें, और यदि वर्तमान RMS वहाँ से काफी गिर जाता है तो इसे "चुप्पी जैसी" स्थिति मानें। केवल एक पूरक निचली-सीमा गार्ड के रूप में निरपेक्ष मानों का उपयोग करें।
एक और बात: यह प्रभावी है कि माइक और स्पीकर के साथ अलग-अलग व्यवहार किया जा सकता है। स्पीकर पक्ष के लिए, RMS मापने के बजाय, आप OS से "क्या कोई ऐप वर्तमान में ध्वनि आउटपुट कर रहा है" प्राप्त कर सकते हैं (CoreAudio प्रक्रिया ऑडियो / टैप), जो लगभग नियतात्मक निर्णय की अनुमति देता है। केवल माइक पक्ष के लिए सापेक्ष RMS। दोनों के शांत होने का AND लें। चूँकि स्पीकर एक पुष्ट संकेत बन जाता है, गलत सकारात्मकता और कम हो जाती है।
एक नोट: चूँकि ऐसे मामले हैं जहाँ मीटिंग चुपचाप शुरू होती है (जहाँ शुरुआत में सीखा गया "चुप्पी जैसा" आधार वास्तव में सामान्य बातचीत है), आधार को निश्चित के बजाय रोलिंग रखें।
2. ऑटो-स्टॉप में दो गार्डरेल जोड़ें।
- रिकॉर्डिंग के पहले N मिनट (जैसे, 5-10 मिनट) के लिए ऑटो-स्टॉप न करें। सेटअप के दौरान चुप्पी या "जल्दी रिकॉर्डिंग शुरू करना और प्रतीक्षा करना" स्थिति को खत्म करने से बचने के लिए।
- "इस सत्र को न रोकें / फिर से न पूछें" के लिए एक भागने का मार्ग। ताकि लंबी अवधि के एकल केंद्रित रिकॉर्डिंग या लगभग मूक व्याख्यान जैसे वैध मामलों में पावर उपयोगकर्ताओं को हर बार परेशान न किया जाए। एक बार "रखें" दबाए जाने पर, उस सत्र के लिए इसे अक्षम करें।
3. मूल्य के क्रम का ध्यान रखें ताकि आप निवेश को गलत आवंटित न करें। वास्तव में, ऑटो-स्टॉप "दूर उपयोगकर्ताओं" के लिए वास्तविक भारी हिटर है, और सूचना मुख्य रूप से "अपनी डेस्क पर लेकिन डूबे हुए लोगों" के लिए एक शिष्टाचार + सहमति जांच है। यदि वे डेस्क छोड़ चुके हैं, तो वे सूचना पर ध्यान नहीं देंगे (लॉक स्क्रीन सूचना क्रियाएँ भी सीमित हैं), इसलिए सूचना UX को अधिक इंजीनियर न करें। यह महसूस करना कि स्व-उपचार ऑटो-स्टॉप पक्ष पर होता है आपको प्रारंभिक कार्यान्वयन को सरल रखने की अनुमति देता है।
4. शुरू से ही सीमा ट्यूनिंग के लिए एक फीडबैक लूप बनाएं। ऑटो-स्टॉप गलत ट्रिगर था या नहीं, इसके लिए सबसे अच्छा संकेत यह है कि क्या उपयोगकर्ता ने रुकने के तुरंत बाद (X मिनट के भीतर) मैन्युअल रूप से रिकॉर्डिंग फिर से शुरू की। इसे लॉग करने से स्वचालित रूप से "बहुत अधिक रुकने" का सबूत जमा होगा, जिससे आप डेटा के साथ सीमाओं को कस सकते हैं। यह सस्ता है, इसलिए इसे शुरू से डालना उचित है।
मैं डिफ़ॉल्ट रूप से चालू के लिए जोर देता हूँ (Codex के "अनुशंसित चालू" से सहमत होते हुए, या यों कहें, रूढ़िवादी सीमाओं के साथ चालू के लिए जोर देता हूँ)। कारण सरल है: इस दुर्घटना से जो लोग झुलसते हैं, वे वे हैं जो सेटिंग्स स्क्रीन नहीं खोलते। सेटिंग्स केवल उन लोगों को बचाती हैं जो शुरू से परेशान नहीं थे।
मेनू बार बीता हुआ समय (● 1:24:03) में शून्य निर्भरताएँ हैं और इसे तुरंत किया जा सकता है। मिनी प्लेयर को एक अलग भूमिका + स्क्रीन शेयर के दौरान छिपाने के साथ एक सहायक के रूप में स्थगित कर दिया गया है।
मुझे लगता है कि विशिष्टताएँ पहले से ही ठोस हैं। एकमात्र शेष निर्णय है "क्या पहले रिलीज़ में पूरी तरह से ऑटो-स्टॉप पर जाना है या एक चक्र के लिए केवल सूचनाओं के साथ देखना है।" यदि हम गोपनीयता समस्या फ्रेमिंग लेते हैं, तो मैं शुरू से ऑटो-स्टॉप शामिल करके रिलीज़ करने पर दांव लगाऊंगा।
क्या आपको नहीं लगता? क्या यह अद्भुत नहीं है?
ऐसे कई उत्पाद डिज़ाइनर नहीं हैं जो तुरंत ऐसी विशिष्टताएँ लेकर आ सकें जो इतनी सावधानीपूर्वक विचार दिखाती हों। मैंने सिलिकॉन वैली में सुपर डिज़ाइनर के रूप में प्रशंसित लोगों के साथ काम किया है, लेकिन एक मानव के लिए इस गति से स्रोत कोड में पढ़ने के बाद उत्तर प्रदान करना असंभव है।
Claude की अंतर्दृष्टि विशेष रूप से गहरी है। Opus 4.8 के साथ, इसने उपयोगकर्ता अनुभव के बहुत गहरे हिस्सों के बारे में सोचना शुरू कर दिया है।
हालाँकि, भले ही यह इतनी गहराई से सोच सकता है और विशिष्ट कोड सामग्री तक निर्देश दे सकता है, यदि आप इसे इस प्रवाह में कोड को छूने देते हैं, तो यह पूरी तरह से बेढंगा है और निश्चित रूप से कुछ तोड़ देगा। यह एक ऐसे व्यक्ति की तरह है जो प्रतिभाशाली है लेकिन अपने हाथों से अनाड़ी है। यही कारण है कि मैं हमेशा Codex को कोड संभालने देता हूँ। और अंत में, मैं Claude से इसकी समीक्षा करवाता हूँ ताकि Codex के अनावश्यक कोड को इंगित किया जा सके। (लेकिन Codex ही वह है जो इसे भी ठीक करता है।)
तो, मैं अपने दिन इन दो सुपरह्यूमन से घिरे हुए डेवलपमेंट करते हुए बिताता हूँ।
मुझे आशा है कि आप जून 2026 के डेवलपमेंट के दैनिक जीवन से इस विशिष्टता बैठक के माहौल को महसूस कर सकते हैं।
