AI copilot अब काफ़ी हो चुके हैं, हमें AI HUD चाहिए

 (geoffreylitt.com)
1 पॉइंट द्वारा GN⁺ 2025-07-28 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Mark Weiser ने 1992 में प्रस्तुत की गई AI 'copilot' रूपक की आलोचना जो आज भी प्रासंगिक है
  • Weiser ने 'assistant' नहीं, बल्कि यूज़र अनुभव में स्वाभाविक रूप से घुल-मिल जाने वाले इंटरफ़ेस का पक्ष लिया
  • आधुनिक विमान के HUD(Head-Up Display) की अवधारणा इस दर्शन को अच्छी तरह दिखाती है
  • automation या agent UI के बजाय, यूज़र की संवेदनात्मक क्षमता को बढ़ाने वाले HUD-स्टाइल UI का मूल्य कई उदाहरणों से सामने आता है
  • रोज़मर्रा के कामों में copilot प्रभावी है, लेकिन रचनात्मक/अनियमित परिस्थितियों में HUD मानव क्षमता को और अधिक सशक्त बनाता है

1992 में Mark Weiser की copilot आलोचना

  • 1992 में Mark Weiser ने MIT Media Lab के 'interface agents' पर एक कार्यक्रम में AI को 'copilot' से तुलना करने वाले दृष्टिकोण की आलोचना की
  • context awareness और automation जैसे मुद्दों पर, जो आज भी प्रासंगिक हैं, उस समय भी चर्चा हुई थी
  • Weiser ने 'copilot' (एक वर्चुअल इंसान की तरह पायलट की सहायक भूमिका निभाने वाला AI) के बजाय, ऐसे सिस्टम का समर्थन किया जिसमें उपयोगकर्ता जानकारी को स्वाभाविक रूप से महसूस कर सके
  • उनका आदर्श था 'अदृश्य कंप्यूटर', यानी ऐसा वातावरण जो उपयोगकर्ता के शरीर का स्वाभाविक विस्तार बन जाए

HUD(Head-Up Display) और Weiser का दर्शन

  • आधुनिक विमान का HUD(HUD, Head-Up Display) एक पारदर्शी डिस्प्ले पर क्षितिज/ऊंचाई जैसी मुख्य जानकारी overlay करता है, ताकि पायलट की दृष्टि-रेखा में जानकारी स्वाभाविक रूप से उपलब्ध हो
  • HUD, copilot की तरह, संवाद की मांग नहीं करता और स्वाभाविक रूप से संज्ञानात्मक क्षमता का विस्तार करने वाला प्रभाव देता है
  • यह HUD अवधारणा, Weiser द्वारा प्रस्तुत usability दर्शन के अनुकूल है

सॉफ़्टवेयर में HUD का कार्यान्वयन

  • spellcheck 'AI collaborator' की तरह बातचीत नहीं करता, बल्कि टाइपो पर अपने-आप लाल underline खींचने के तरीके से काम करता है
  • इस तरह तुरंत और दृश्यात्मक सूचना देना HUD का एक उदाहरण है, जो उपयोगकर्ता के लिए एक नई संवेदना तैयार करता है
  • AI का उपयोग करने वाला custom debugger UI भी प्रोग्राम के व्यवहार को सहज रूप से दृश्यात्मक बनाता है, ताकि उपयोगकर्ता स्वयं समस्या को पहचान और समझ सके
  • यह दृष्टिकोण पारंपरिक automation या 'virtual assistant' UI से अलग है और सीधे मानव संवेदनाओं का विस्तार करता है

HUD और copilot के बीच trade-off

  • लेखक यह नहीं कहते कि HUD हमेशा copilot से बेहतर है, बल्कि समझाते हैं कि दोनों के अपने फायदे और सीमाएँ हैं
  • रूटीन और पूर्वानुमेय कार्यों (जैसे: सीधी उड़ान) में copilot तरीका अधिक दक्ष होता है
  • अनियमित और रचनात्मक समस्याओं (जैसे: आपातकालीन लैंडिंग के समय स्थिति की समझ) में HUD की तरह मानव संज्ञान को सहारा देने वाले उपकरण बड़ी ताकत दिखाते हैं
  • AI डिज़ाइनरों को 'assistant' से आगे बढ़कर HUD जैसे मानव-संवेदना-विस्तारक UI पर भी ज़रूर विचार करना चाहिए

निष्कर्ष

  • भविष्य के AI डिज़ाइन में copilot शैली और HUD शैली, दोनों के मूल्य और trade-off को पहचानना ज़रूरी है
  • साधारण automation को virtual assistant पर छोड़कर, और बेहतर परिणाम चाहिए हों तो HUD की तरह मानव विशेषज्ञ को 'नई superpower' देने का तरीका सबसे शक्तिशाली हो सकता है

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2025-07-28
Hacker News राय
  • मुझे यह फीचर बहुत उपयोगी लगेगा जो दिखाए कि source file के हर token पर model को कितनी हैरानी होती है, इसके लिए एक heatmap toggle किया जा सके। लाल token का मतलब error, खराब naming, या गलत comments होने की संभावना ज़्यादा है
    • कभी-कभी अप्रत्याशित code किसी नए algorithm की वजह से होता है, लेकिन ऐसे मामलों में बेहतर documentation और भी ज़रूरी होती है। अगर code में ठीक से explanation जोड़ दी जाए, तो वह अपने आप कम surprising हो जाता है। यानी source के कुछ हिस्सों को इस तरह structure करना संभव है कि वे चौंकाने वाले न लगें, और शायद यही अच्छी engineering practice भी है। LLM की वजह से अब सब लोग अच्छी documentation की अहमियत पर ध्यान दे रहे हैं। सिर्फ़ दूसरे लोगों के लिए नहीं, बल्कि AI को system पढ़कर समझने देना हो तब तो इसकी और भी ज़्यादा ज़रूरत है
    • मुझे यह idea सच में बहुत शानदार लगता है। उल्टा, अगर AI के suggestions के लिए भी confidence के हिसाब से heatmap बना दिया जाए, तो वह भी बहुत उपयोगी होगा
    • मैं चाहता हूँ कि editor के अंदर ऐसा feature हो। यह देखने के लिए भी अच्छा होगा कि writing बहुत ज़्यादा predictable या घिसी-पिटी तो नहीं है। perplexity calculate करना भी कठिन नहीं है, बस इसे editor UI में integrate करना होगा
    • दिलचस्प। मुझे अक्सर लगता है कि LLM के शुरुआती hype phase से निकले “low-hanging fruit” का हमने पूरा उपयोग नहीं किया। यह वैसा ही एक idea है
    • मुझे यह सच में शानदार idea लगता है
  • लगभग 10 साल पहले Bret Victor ने कहा था कि feedback delay को कम से कम करना जीवन का एक सिद्धांत होना चाहिए। उनका कहना था कि तेज़ iteration cycle न सिर्फ coding को बेहतर बनाती है, बल्कि creative insight में भी मदद करती है। उन्होंने alternative दिखाने के लिए कई example programs बनाए थे, और OP में बताया गया HUD case भी उनके “समय को पीछे घुमा कर code को समझना” वाले demo से बहुत मिलता-जुलता है। संबंधित वीडियो
  • यह idea मुझे इतना पसंद आया कि मैंने सोचा इसे coding में व्यापक रूप से कैसे लागू किया जा सकता है। कल्पना कीजिए: जैसे ही आप code लिखें, LLM tests generate करे और IDE उन tests को real time में चलाए। हर keypress पर 10~100 tests <1ms में run हों, और results unobtrusive तरीके से दिखें। tests code के बगल में एक अलग panel में हों, और पिछली run pass हुई या fail, यह लाल/हरे dots से दिखे। कौन से tests हैं, कौन से नहीं हैं, और उनकी स्थिति क्या है, सिर्फ़ इतना देखकर भी समझ आ सकता है कि लिखा जा रहा code “बाहर से” क्या कर रहा है। अगर लगे कि LLM कोई ज़रूरी test नहीं लिख रहा, तो यह संकेत हो सकता है कि prompt गलत था या code इरादे के मुताबिक नहीं है। यह real-time गुण code को refine करने में बहुत मददगार है। अगर पारंपरिक TDD करना हो, तो user test लिखे और LLM code लिखकर tests pass करा दे
    • tests इंसान पहले लिखे और LLM बाद में code बनाए, यह तरीका कहीं बेहतर है। क्योंकि test ही code की “सच्चाई” और “इरादा” होते हैं। अगर input और output तय करने का नियंत्रण छोड़ दिया जाए, तो developer फिर driver’s seat में नहीं रहता
    • गंभीर C++ codebase में यह तरीका व्यावहारिक नहीं है। compile time ही इसे असंभव बना देगा, और LLM के लिए tests का अंदाज़ा लगाना भी मुश्किल है जब तक वह पूरा code न लिख दे। उदाहरण के लिए अगर आप कोई नया data structure बना रहे हैं, तो LLM उसे कैसे जानेगा
    • code लिखते समय LLM tests generate करे और IDE हर बार उन्हें चलाए, यह हमेशा अच्छा तरीका नहीं है। tests वह code होते हैं जो invariants को guarantee करते हैं, इसलिए LLM का उन्हें मनमाने ढंग से छूना ठीक नहीं। tests तभी बदलने चाहिए जब user उन्हें स्पष्ट रूप से बदले, और केवल वही बदलें। इन constraints के तहत तो यह पहले से ही रोज़मर्रा का workflow है। जैसे JavaScript test framework का watch mode। ऐसे workflow developers पिछले 10 साल से कर ही रहे हैं
    • क्या यह जाँचने के लिए भी tests नहीं चाहिए होंगे कि tests सही लिखे गए हैं? वरना LLM तो शायद गलत tests को भी बस pass कराने की कोशिश करेगा। या ऐसा code लिख देगा जो system को ही trick कर दे। आख़िर में अच्छा setup वही होगा जिसमें LLM और इंसान दोनों अपनी-अपनी boundaries को लचीले ढंग से पार कर सकें। सिर्फ़ clear requirements लिखकर AI से दोनों तरफ़ का ज़्यादातर काम करवाना कहीं ज़्यादा productive और streamlined होगा
    • हर input पर पूरी test suite चलाना ROI के हिसाब से बहुत कम फ़ायदे का सौदा है। ज़्यादातर keypresses पर program “अधूरा” होता है, इसलिए tests कब चलाने हैं यह ज़्यादा समझदारी से तय करना होगा, तभी सही balance बनेगा
  • आख़िरकार बात आकर इसी सवाल पर टिकती है: "डिजिटल जानकारी संभालने के लिए इंसान का आदर्श interface क्या है?" हम हर दिन लगातार ज़्यादा जानकारी ले रहे हैं, और AI की वजह से यह मात्रा कम नहीं बल्कि और बढ़ रही है। अगर जटिल और विशेषज्ञ स्तर की जानकारी, जैसे error logs, भी summarize की जा सके, तो ऐसे लोगों के लिए जानकारी तक पहुँच का नया रास्ता खुल जाता है जो पहले इसे समझ नहीं पाते थे। तो फिर हम इस भारी मात्रा की जानकारी को कुशलता से कैसे संभालें? अभी हमारे पास तरह-तरह के interfaces, sites, dashboards, email, और chat हैं, लेकिन क्या 10 साल बाद भी यह सब उतना ही ज़रूरी होगा, इस पर संदेह है। अगर मुझे एक single chat interface में सारी जानकारी मिल जाए, तो क्या मुझे अलग-अलग sites पर जाने की ज़रूरत पड़ेगी? AI अगर हमारे लिए websites, apps, और web UI भी बना दे, तो अब वह थोड़ा... दोहराव जैसा लगता है
    • website दरअसल company या Wikipedia जैसी भरोसेमंद जगहों से “official” जानकारी पाने का माध्यम रही है। इसी भरोसे की ताकत की वजह से “line of death”, lock icon, phishing defense, और homograph attack mitigation जैसी चीज़ों पर इतना काम हुआ। यह सब इसी मान्यता पर टिका था कि यह site भरोसेमंद official information देती है। ऐसे संसार में जहाँ हर कोई बिना आलोचनात्मक सोच के LLM पर निर्भर हो, “trust” का मतलब ही उलझ जाता है। भले LLM ज़्यादातर सही हो, पर क्या बेहद महत्वपूर्ण क्षणों में भी उस पर भरोसा किया जा सकता है?
    • 6th-generation fighter designers भी इसी समस्या से जूझ रहे हैं। cockpit विमान और pilot के बीच interface है, लेकिन उसकी भूमिका लगातार घट रही है। 7th generation तक पहुँचते-पहुँचते शायद यह सवाल उठे कि इंसान की कोई मूल्यवान भूमिका बचेगी भी या नहीं। (हालाँकि international law या Skynet-risk management जैसी वजहों से human involvement फिर भी रह सकती है।) शायद हर क्षेत्र के interfaces इसी तरह evolve करेंगे। जटिलता लगातार कम होगी, और इंसान को बस system को high-level concepts में बताना होगा कि वह क्या चाहता है। ज़रूरी नहीं कि वह natural language ही हो; अगर precise specification चाहिए, तो उसके लिए उसी तरह का interface भी हो सकता है
    • हर व्यक्ति अलग है, इसलिए interfaces को generalize नहीं करना चाहिए; उन्हें मौके पर ही dynamically customize होना चाहिए
    • यह मानना मुश्किल है कि smartphone वास्तव में परिपूर्ण हैं और उनका लगभग पूरा उपयोग हो चुका है। फिर भी मुझे वे सबसे ज़्यादा पसंद हैं
  • मुझे लगता है कि AI अगर real time में complex visualizations बना सके, तो वह बेहद उपयोगी होगा। उदाहरण के लिए, किसी खास code path में memory leak debug करते समय AI उस path की memory allocation/deallocation को visualize करके समस्या समझने में मदद कर सकता है। शायद ऐसा दौर आएगा जब AI हर अलग समस्या के लिए उपयुक्त visualization tool खुद बना देगा। Jonathan Blow का LambdaConf में दिया गया हालिया talk इसी idea से सीधा जुड़ता है। उन्होंने program को अलग-अलग तरीकों से visualize करके potential problems ढूँढने वाले tools दिखाए। AI ऐसे tools अच्छी तरह बना सकेगा, ऐसा लगता है। पूरा वीडियो देखें
  • मैं Claude Code के TODO items से जुड़े changes को सीधे HUD में देखना चाहता हूँ। inline comments नहीं चाहिए, क्योंकि वे बाद में जमा होते जाते हैं और LLM उन्हें ठीक से साफ़ नहीं कर पाता
  • HUD अभी तक व्यापक रूप से लोकप्रिय न होने का एक बड़ा कारण वर्तमान display mediums की सीमाएँ हैं। monitor या mobile devices peripheral और non-intrusive जानकारी देने में अच्छे नहीं हैं। जब AI agent bugs ठीक कर रहा हो या कोई complex task संभाल रहा हो, तब result का इंतज़ार करना अजीब-सा होता है। समय इतना कम होता है कि कुछ और करना मुश्किल, लेकिन इतना लंबा भी कि सिर्फ़ screen को देखते रहना असहज लगे। अगर HUD हो, तो feedback loop कहीं छोटा हो सकता है। आप एक नज़र से देख सकते हैं कि AI क्या कर रहा है और तुरंत intervene कर सकते हैं, या फिर बस दूसरा काम जारी रख सकते हैं। पूरा ध्यान या पूरी तरह उपेक्षा, इन दो extremes के बीच ambient awareness में रहकर ज़रूरत के हिसाब से involvement का स्तर चुन पाना महत्वपूर्ण है। इसलिए मुझे लगता है कि VR/AR, AI HUD का एक मुख्य killer app बन सकता है। spatial computing की वजह से 2D screen से नज़र हटाए बिना AI की मदद मिल सकती है। ऐसा approach cooking या bicycle repair जैसे physical tasks में भी खास तौर पर उपयोगी होगा
    • मैं ultrawide monitor और laptop screen को जोड़कर लगभग इसी तरह इस्तेमाल करता हूँ। game में डूबा रहूँ या कोई और काम कर रहा हूँ, एक कोने में tmux window में Claude खुला रहता है, और जैसे ही अगला step या कोई महत्वपूर्ण बदलाव आता है, मैं तुरंत देख लेता हूँ
  • HUD-style coding interface मुझे मूल रूप से AREPL जैसा लगता है। debugging के लिए यह अच्छा हो सकता है, लेकिन मुझे लगता है कि chat window या inline Q&A कहीं ज़्यादा तरह से उपयोगी हो सकते हैं। कुल मिलाकर chat के अलावा alternative interface वाली बात से मैं सहमत हूँ, लेकिन व्यवहारिक रूप से smartphone पर chat पहले से ही एक जबरदस्त interface है। HUD शायद AR glasses जैसे असली HUD के लिए ज़्यादा उपयुक्त होगा
  • मुझे लगता है कि ऐसे AI models भी संभव हैं जो background में लंबे समय तक autonomous तरीके से चलते रहें और ज़रूरत पड़ने पर जानकारी “push” करें। वे context को समझदारी से detect करें, filter करें, summarize करें, और ज़रूरत हो तो recommendation भी दें। खासकर business environments में, जहाँ कई customers को 100 तरह की स्थितियों में monitor करना पड़ता है, यह कहीं ज़्यादा स्वाभाविक लगेगा
    • असल में context को define करना और उससे जुड़ा data इकट्ठा करना ही सबसे कठिन हिस्सा है। यह समस्या कि autonomous system उसे कर दे, तकनीकी रूप से तो बहुत पहले ही हल हो चुकी थी
  • मैं इस दावे से सहमत हूँ कि “अगर हम AI के लिए design को गंभीरता से लेते हैं, तो हमें सिर्फ़ copilot से आगे बढ़कर इंसानी आंतरिक क्षमता को विस्तार देने वाले रूपों पर विचार करना चाहिए।” सच तो यह है कि auto-complete भी पहले से यही भूमिका निभाता है। वास्तव में आप LLM से बातचीत भी कर सकते हैं, लेकिन सिर्फ़ commands दे सकते हैं या auto-complete भी इस्तेमाल कर सकते हैं। लेखक शायद मोटे तौर पर यह ज़ोर देना चाह रहा है कि AI को हमारे साथ कंधे से कंधा मिलाकर, उसी दिशा में देखते हुए काम करना चाहिए। मेज़ के सामने बैठकर बहस करने वाले किसी 'virtual human' copilot की तरह नहीं, बल्कि ऐसे सच्चे collaborator की तरह जो हमारे कहने पर तुरंत काम करे
    • मैं लेखक हूँ। सही कहा, GitHub Copilot का auto-complete UI वास्तव में (विडंबना यह है कि) एक बहुत अच्छा HUD उदाहरण है। tab auto-complete ऐसे घुल जाता है जैसे वह दिमाग़ का कोई हिस्सा हो। लेकिन हाल की coding environments chat agents की ओर जा रही हैं। अब यह कल्पना करने की ज़रूरत है कि abstraction के ऊँचे स्तर पर “tab auto-complete” UI कैसा दिखेगा। शायद यह code design का एक सचमुच प्रत्यक्ष अनुभव देने वाला तरीका बन सके, जो incidental details में फँसे बिना काम करे