AI Copilot Kini Sudah Cukup, Kita Membutuhkan AI HUD

• Kritik Mark Weiser terhadap metafora AI 'copilot' yang dipublikasikan pada 1992 masih relevan hingga sekarang
• Weiser menekankan antarmuka yang menyatu secara alami ke dalam pengalaman pengguna, bukan 'asisten'
• Konsep HUD (head-up display) pada pesawat modern menunjukkan filosofi ini dengan baik
• Nilai dari UI bergaya HUD yang memperluas indera pengguna, alih-alih otomasi atau agent UI, terlihat melalui berbagai contoh
• Copilot efektif untuk pekerjaan sehari-hari, tetapi dalam situasi kreatif/tidak terstruktur, HUD lebih mampu memperkuat kemampuan manusia

---

Kritik Mark Weiser terhadap Copilot pada 1992

• Pada 1992, Mark Weiser mengkritik cara pandang yang mengibaratkan AI sebagai 'copilot' dalam sebuah acara tentang 'interface agents' di MIT Media Lab
• Isu seperti kesadaran konteks dan otomasi, yang masih relevan hari ini, juga sudah dibahas saat itu
• Weiser mendukung sistem yang memungkinkan pengguna merasakan informasi secara alami, alih-alih 'copilot' (AI yang berperan membantu pilot seperti manusia virtual)
• Idealnya adalah 'komputer yang tidak mencolok', yakni lingkungan yang menjadi perpanjangan alami dari tubuh pengguna

HUD (Head-Up Display) dan filosofi Weiser

• HUD (Head-Up Display) pada pesawat modern menampilkan informasi inti seperti horizon/ketinggian sebagai overlay pada display transparan, sehingga tersaji secara alami dalam bidang pandang pilot
• Tidak seperti copilot, HUD tidak membutuhkan percakapan, dan secara alami memperluas kemampuan persepsi
• Konsep HUD seperti ini selaras dengan kegunaan yang diajukan Weiser

Perwujudan HUD dalam software

• Pemeriksa ejaan bekerja bukan dengan berdialog seperti 'kolaborator AI', melainkan dengan otomatis memberi garis bawah merah pada typo
• Seperti ini, penyajian informasi yang langsung dan visual menjadi salah satu contoh HUD yang menciptakan indera baru bagi pengguna
• UI debugger kustom yang memanfaatkan AI juga memvisualisasikan perilaku program secara intuitif, sehingga pengguna bisa langsung mengidentifikasi dan memahami masalah
• Pendekatan ini berbeda dari otomasi tradisional atau UI 'asisten virtual', dan secara langsung memperluas indera manusia

Trade-off antara HUD dan copilot

• Penulis menjelaskan bahwa HUD tidak selalu lebih baik daripada copilot, dan masing-masing memiliki kelebihan serta kekurangan
• Untuk tugas yang rutin dan dapat diprediksi (misalnya terbang lurus), pendekatan copilot efisien
• Untuk masalah yang tidak terstruktur dan kreatif (misalnya memahami situasi saat pendaratan darurat), alat yang membantu kognisi manusia seperti HUD sangat berdaya guna
• Perancang AI perlu mempertimbangkan bukan hanya 'assistant', tetapi juga UI perluasan indera manusia seperti HUD

Kesimpulan

• Dalam desain AI masa depan, perlu ada pengakuan terhadap nilai dan trade-off baik dari pendekatan copilot maupun HUD
• Serahkan otomasi biasa kepada asisten virtual, dan jika menginginkan hasil yang lebih unggul, cara paling kuat mungkin adalah memberi 'superpower baru' kepada pakar manusia seperti yang dilakukan HUD

[GN⁺]

Komentar Hacker News

• Saya sangat penasaran apakah akan berguna jika ada fitur untuk menyalakan heatmap yang menunjukkan seberapa “mengejutkan” setiap token dalam file sumber bagi model. Token berwarna merah kemungkinan besar menandakan error, penamaan yang buruk, atau komentar yang keliru
  • Kadang kode sulit diprediksi karena algoritmenya memang baru, tetapi dalam kasus seperti itu dokumentasi yang lebih baik justru sangat dibutuhkan. Jika kode diberi penjelasan yang layak, kode itu sendiri menjadi tidak terlalu mengejutkan. Artinya, bagian tertentu dari source bisa disusun agar tidak mengejutkan, dan itu mungkin merupakan praktik engineering yang baik. Berkat LLM, semua orang jadi lebih peduli pada pentingnya dokumentasi yang baik. Ini makin diperlukan jika bukan hanya manusia, tetapi juga AI harus bisa membaca dan memahami sistem
  • Menurut saya idenya sangat keren. Sebaliknya, akan sangat berguna juga jika saran dari AI diberi heatmap berdasarkan tingkat kepercayaannya
  • Saya ingin fitur seperti ini ada di editor. Ini juga bagus untuk memeriksa apakah tulisan terlalu mudah ditebak atau klise. Menghitung perplexity juga tidak sulit, jadi tinggal diintegrasikan saja ke UI editor
  • Menarik. Saya sering merasa bahwa kita belum cukup memanfaatkan “buah yang menggantung rendah” yang sudah muncul sejak hype awal LLM. Ini salah satu ide seperti itu
  • Menurut saya ini benar-benar ide yang fantastis
• Sekitar 10 tahun lalu Bret Victor pernah berkata bahwa meminimalkan latensi umpan balik adalah prinsip hidup. Ia mengatakan bahwa siklus iterasi yang cepat bukan hanya membuat kita lebih baik dalam coding, tetapi juga mendorong insight kreatif. Ia membuat berbagai program contoh untuk menunjukkan alternatif, dan contoh HUD yang disebut OP juga sangat mirip dengan demonya tentang “memahami kode dengan menelusuri waktu ke belakang”. Video terkait
• Saya suka ide ini, jadi saya sempat memikirkan bagaimana ini bisa diterapkan ke coding secara umum. Bayangkan: saat menulis kode, LLM membuatkan test, lalu IDE menjalankan test itu secara real-time. Di setiap penekanan tombol, 10~100 test dijalankan dalam <1ms, dan hasilnya ditampilkan dengan cara yang tidak mengganggu. Test muncul di panel terpisah di samping kode, dan lulus/gagal pada run terakhir dibedakan dengan titik merah/hijau. Hanya dengan melihat test apa yang ada atau tidak ada, dan statusnya, kita bisa tahu dari “luar” apa yang sedang dilakukan kode yang sedang ditulis. Jika kita merasa ada test yang seharusnya ada tetapi tidak dibuat oleh LLM, itu bisa menjadi sinyal bahwa prompt-nya salah atau kode tidak sesuai niat. Sifat real-time seperti ini sangat membantu dalam menyempurnakan kode. Kalau ingin melakukannya dengan TDD tradisional, pengguna bisa menulis test dulu lalu LLM menulis kodenya agar test lolos
  • Jauh lebih baik jika manusialah yang menulis test lebih dulu dan LLM yang membuat kode. Sebab test adalah “kebenaran” dan “niat” dari kode. Jika kita melepaskan kendali atas input dan output, maka developer tidak lagi duduk di kursi pengemudi
  • Di codebase C++ yang serius, cara seperti ini tidak realistis. Waktu kompilasi saja sudah membuatnya mustahil, dan LLM juga akan kesulitan menebak test jika belum menulis seluruh kode. Misalnya saat membuat struktur data baru, bagaimana LLM bisa tahu itu
  • Bukan ide bagus jika LLM membuat test saat menulis kode lalu IDE menjalankannya setiap saat. Test adalah kode yang menjamin invariant, jadi berbahaya jika LLM mengutak-atiknya sembarangan. Test seharusnya hanya berubah ketika pengguna mengubahnya secara eksplisit, dan hanya test itu sendiri yang berubah. Dalam batasan seperti ini, alur kerjanya sebenarnya sudah jadi hal biasa. Mirip watch mode pada framework test JavaScript. Workflow seperti itu sudah dilakukan developer sejak 10 tahun lalu
  • Bukankah kita juga perlu test untuk memastikan test-nya sendiri ditulis dengan benar? Kalau tidak, LLM hanya akan membuatnya lolos meskipun test-nya salah. Atau malah bisa menulis kode yang sekadar mengakali sistem. Pada akhirnya, setup yang berhasil kemungkinan adalah lingkungan di mana LLM dan manusia bisa bebas melintasi batas masing-masing. Menulis requirement yang jelas lalu membiarkan AI menangani sebagian besar kedua sisi akan jauh lebih produktif dan streamlined
  • Menjalankan seluruh test suite pada setiap input memberi ROI yang terlalu rendah. Sebagian besar penekanan tombol menghasilkan program yang “belum selesai”, jadi waktu eksekusi test perlu ditentukan dengan lebih cerdas agar ada keseimbangan yang masuk akal
• Pada akhirnya semua ini bermuara pada pertanyaan, "apa antarmuka ideal bagi manusia untuk menangani informasi digital?" Kita menerima semakin banyak informasi setiap hari, dan karena AI jumlah itu tidak berkurang, justru bertambah. Jika informasi yang kompleks dan spesifik, seperti error log, juga bisa diringkas, maka terbuka jalan baru agar orang yang sebelumnya tidak bisa melihatnya kini dapat mengakses informasi tersebut. Lalu bagaimana kita harus menangani sebanyak ini secara efisien? Saat ini ada berbagai antarmuka, situs, dashboard, email, dan chat, tetapi saya ragu apakah 10 tahun lagi semua itu masih perlu. Jika saya bisa menerima semua informasi dari satu antarmuka chat, apakah saya masih perlu membuka situs? Sekarang rasanya AI yang membuat website, app, dan web UI untuk kita itu agak... redundan
  • Website pada dasarnya adalah sarana untuk menerima informasi “resmi” dari tempat tepercaya seperti perusahaan atau Wikipedia. Kepercayaan ini sangat kuat, sehingga kita sampai memberi perhatian besar pada "line of death", ikon gembok, pencegahan phishing, dan penanganan serangan homograf. Semua itu berangkat dari asumsi bahwa situs ini adalah sumber informasi resmi yang dapat dipercaya. Di dunia di mana semua orang bergantung pada LLM tanpa kritik, saya benar-benar bingung apa arti “percaya”. Walaupun LLM biasanya benar, apakah kita bisa mempercayainya pada momen yang sangat penting?
  • Para desainer pesawat tempur generasi ke-6 juga menghadapi masalah yang sama. Kokpit adalah antarmuka antara pesawat dan pilot, tetapi perannya terus berkurang. Saat masuk generasi ke-7, saya ragu manusia masih bisa punya peran yang bernilai. (Meski begitu, manusia mungkin tetap diperlukan karena hukum internasional atau pengelolaan risiko Skynet.) Mungkin antarmuka di semua bidang juga akan berevolusi seperti ini. Kompleksitas akan terus berkurang, dan manusia hanya perlu menjelaskan ke sistem apa yang diinginkan dalam konsep tingkat tinggi. Tidak harus bahasa alami; kalau dibutuhkan spesifikasi yang presisi, bisa saja dalam bentuk antarmuka yang sesuai untuk itu
  • Karena setiap orang berbeda, antarmuka seharusnya tidak digeneralisasi, tetapi dikustomisasi secara dinamis saat itu juga
  • Sulit mengatakan bahwa smartphone sudah benar-benar sempurna dan dimanfaatkan sepenuhnya. Bagi saya, itu yang paling saya sukai
• Saya rasa kemampuan AI membuat visualisasi kompleks secara real-time akan sangat berguna. Misalnya saat men-debug memory leak pada jalur kode tertentu, AI dapat memvisualisasikan alokasi/dealokasi memori di jalur tersebut untuk membantu menemukan masalah. Sepertinya kita akan memasuki era ketika AI membuat sendiri tool visualisasi yang cocok untuk masalah spesifik. Talk terbaru Jonathan Blow di LambdaConf sangat sejalan dengan ide ini. Ia menunjukkan tool yang memvisualisasikan program dengan berbagai cara untuk menemukan potensi masalah. Sepertinya AI bisa sangat bagus dalam membuat tool seperti itu. Tonton videonya
• Saya ingin bisa langsung melihat perubahan yang terhubung ke item TODO di Claude Code dalam bentuk HUD. Saya tidak suka komentar inline karena nanti menumpuk dan LLM tidak merapikannya dengan baik
• Salah satu alasan terbesar HUD belum menyebar luas adalah keterbatasan medium display yang dipakai saat ini. Monitor atau perangkat mobile kurang bagus dalam menyampaikan informasi yang periferal dan tidak intrusif. Saat agen AI memperbaiki bug atau menangani task kompleks, waktu tunggunya terasa canggung. Terlalu singkat untuk benar-benar mengerjakan hal lain, tapi juga aneh jika hanya menatap layar terus. Dengan HUD, kita bisa punya feedback loop yang jauh lebih pendek. Kita bisa melirik apa yang sedang dikerjakan AI lalu langsung ikut campur bila perlu, atau tetap bebas melanjutkan pekerjaan lain. Yang penting adalah kita bisa memilih tingkat intervensi saat itu juga dalam kesadaran ambient, alih-alih dipaksa memilih antara fokus penuh atau benar-benar lepas tangan. Karena itu saya pikir VR/AR bisa menjadi killer app utama untuk AI HUD. Berkat spatial computing, kita bisa menerima bantuan AI tanpa harus melepaskan pandangan dari layar 2D. Pendekatan seperti ini juga akan sangat membantu dalam pekerjaan fisik seperti memasak atau memperbaiki sepeda
  • Saya sudah memanfaatkan hal serupa dengan menghubungkan monitor ultrawide dan layar laptop. Sambil tenggelam dalam game atau pekerjaan lain, saya membuka Claude di jendela tmux di salah satu sudut, lalu langsung mengeceknya setiap kali ada langkah berikutnya atau perubahan penting
• Menurut saya antarmuka coding bergaya HUD pada dasarnya adalah AREPL. Cocok untuk debugging, tetapi saya merasa chat window atau inline Q&A jauh lebih serbaguna. Secara umum saya setuju dengan logika antarmuka alternatif selain chat, tetapi secara realistis chat sudah menjadi antarmuka yang dominan di smartphone. HUD tampaknya lebih cocok untuk HUD sungguhan seperti kacamata AR
• Saya juga melihat kemungkinan model AI yang berjalan otonom dalam waktu lama di latar belakang, lalu “mendorong” informasi saat diperlukan. Caranya dengan mendeteksi situasi secara cerdas, memfilter, merangkum, menyampaikan isi, dan bila perlu memberi rekomendasi. Ini terasa jauh lebih natural terutama di lingkungan bisnis yang harus memantau banyak pelanggan dalam 100 jenis situasi
  • Sebenarnya bagian tersulit adalah mendefinisikan situasinya dan mengumpulkan data yang relevan. Soal sistem otonom yang melakukan itu sendiri secara teknis sebenarnya sudah diselesaikan sejak lama
• Saya setuju dengan klaim bahwa “jika kita serius mendesain untuk AI, kita harus memikirkan bentuk yang memperluas batin manusia, bukan sekadar copilot”. Sebenarnya auto-complete pun sudah memainkan peran seperti itu. Kita memang bisa benar-benar bercakap-cakap dengan LLM, tetapi kita juga bisa sekadar memberi perintah sederhana atau memakai auto-complete. Yang tampaknya ingin ditekankan penulis adalah bahwa AI harus bekerja bersama kita, berdampingan, menghadap ke arah yang sama. Bukan copilot seperti ‘manusia virtual’ yang hanya berdebat dari seberang meja, melainkan kolaborator sungguhan yang langsung mengerjakan apa yang kita minta
  • Saya penulisnya. Betul, UI auto-complete GitHub Copilot memang (ironisnya) contoh HUD yang sangat baik. Tab auto-complete terasa menyatu seperti bagian dari otak. Tetapi akhir-akhir ini lingkungan coding bergerak ke arah chat agent. Kita perlu membayangkan seperti apa UI “tab auto-complete” pada level abstraksi yang lebih tinggi. Ini bisa menjadi cara merancang kode yang terasa benar-benar langsung, tanpa tersandung detail-detail sampingan