AI copilotu artık yeterli, AI HUD’lara ihtiyacımız var

• Mark Weiser’ın 1992’de dile getirdiği AI "copilot" metaforu eleştirisi bugün de geçerliliğini koruyor
• Weiser, "yardımcı"dan ziyade kullanıcı deneyimine doğal biçimde karışan bir arayüzü savunuyordu
• Modern uçaklardaki HUD (Head-Up Display) kavramı bu felsefeyi iyi gösteriyor
• Otomasyon ya da ajan UI’ları yerine, kullanıcının duyularını genişleten HUD tarzı UI’ların değeri çeşitli örneklerle ortaya çıkıyor
• Gündelik işlerde copilot etkili olsa da, yaratıcı / yapılandırılmamış durumlarda HUD insanın yeteneklerini daha fazla güçlendiriyor

---

1992’de Mark Weiser’ın copilot eleştirisi

• 1992’de Mark Weiser, MIT Media Lab’deki 'interface agents' etkinliğinde AI’yi "copilot" olarak görme yaklaşımına eleştiri getirdi
• Bağlam farkındalığı ve otomasyon gibi bugün de geçerli olan sorunlar o dönemde de tartışılıyordu
• Weiser, "copilot"un (pilotun yanında sanal bir insan gibi yardımcı olan AI) yerine, kullanıcının bilgiyi doğal biçimde algılayabildiği sistemleri savundu
• Onun ideali, "göze çarpmayan bilgisayar" idi; bu, kullanıcının bedeninin doğal bir uzantısı gibi çalışan bir ortam anlamına geliyordu

HUD (Head-Up Display) ve Weiser’ın felsefesi

• Modern uçaklardaki HUD (Head-Up Display), ufuk çizgisi / irtifa gibi temel bilgileri şeffaf bir ekrana bindirerek pilotun görüş alanında doğal biçimde sunar
• HUD, copilot’tan farklı olarak diyaloğa ihtiyaç duymaz ve algısal yetenekleri doğal biçimde genişletir
• Bu HUD kavramı, Weiser’ın ortaya koyduğu kullanılabilirlik anlayışıyla uyumludur

Yazılımda HUD’un hayata geçirilmesi

• Yazım denetimi, bir "AI işbirlikçisi" gibi konuşmak yerine, yazım hatalarının altını otomatik olarak kırmızıyla çizer
• Bu tür anlık ve görsel bilgi sunumu, kullanıcıda yeni bir duyusal katman oluşturan HUD’a bir örnektir
• AI kullanan özel debugger UI’ları da programın davranışını sezgisel biçimde görselleştirerek, kullanıcının sorunu doğrudan fark edip anlamasını sağlar
• Bu yaklaşım, geleneksel otomasyon ya da "sanal yardımcı" UI’larından ayrılır ve insanın duyularını doğrudan genişletir

HUD ile copilot arasındaki ödünleşimler

• Yazar, HUD’un her zaman copilot’tan daha iyi olduğunu söylemiyor; her yaklaşımın kendi artıları ve eksileri olduğunu açıklıyor
• Rutin ve öngörülebilir işlerde (ör. düz uçuş) copilot yaklaşımı verimlidir
• Yapılandırılmamış ve yaratıcı problemlerde (ör. acil inişte durumsal farkındalık), HUD gibi insan bilişini destekleyen araçlar büyük güç sağlar
• AI tasarımcıları, "assistant" yaklaşımının ötesine geçip HUD gibi insan duyularını genişleten UI’ları da mutlaka değerlendirmelidir

Sonuç

• Geleceğin AI tasarımında, hem copilot yaklaşımının hem de HUD yaklaşımının değeri ve ödünleşimleri kabul edilmelidir
• Sıradan otomasyonu sanal yardımcıya bırakıp, daha üstün sonuçlar istendiğinde HUD gibi insan uzmana "yeni süper güçler" kazandıran yöntemler en güçlü yaklaşım olabilir

[GN⁺]

Hacker News görüşü

• Kaynak dosyadaki her token'ın model için ne kadar şaşırtıcı olduğunu gösteren bir ısı haritasını açıp kapatma özelliğinin faydalı olup olmayacağını gerçekten merak ediyorum. Kırmızı token'ların hata, kötü isimlendirme ya da yanlış yorum olma olasılığı daha yüksek olurdu.
  • Öngörülemez kod bazen yeni bir algoritmadan kaynaklanır, ama böyle durumlarda daha iyi dokümantasyon kesinlikle gerekir. Koda düzgün açıklamalar eklerseniz, o da kendi başına daha az şaşırtıcı hale gelir. Yani kaynağın belirli bölümlerini şaşırtıcı olmayacak şekilde yapılandırmak mümkündür ve bu iyi bir mühendislik pratiği olabilir. LLM'ler sayesinde herkes iyi dokümantasyonun önemine dikkat etmeye başladı. Sadece başka insanlar için değil, yapay zekanın da sistemi okuyup anlayabilmesi için bu daha da gerekli.
  • Bence fikir gerçekten harika. Tersine, AI'ın önerileri için de güven düzeyine göre bir ısı haritası olsa gerçekten çok faydalı olurdu.
  • Ben bu özelliğin editörün içine girmesini isterdim. Yazının fazla öngörülebilir ya da klişe olup olmadığını kontrol etmek için de iyi olurdu. Perplexity hesaplamak da zor değil, sadece editör arayüzüne entegre edilmesi gerekiyor.
  • İlginç. LLM'lerin ilk dönem heyecanından beri ortaya çıkan “alçakta asılı meyveleri” yeterince değerlendiremediğimizi sık sık düşünüyorum. Bu da tam öyle bir fikir.
  • Bence gerçekten müthiş bir fikir.
• Yaklaşık 10 yıl önce Bret Victor, geri bildirim gecikmesini en aza indirmenin bir yaşam ilkesi olduğunu söylemişti. Hızlı yineleme döngülerinin sadece kod yazmayı değil, yaratıcı içgörüleri de geliştirdiğini savunuyordu. Alternatifleri göstermek için çeşitli örnek programlar yapmıştı ve OP'de bahsedilen HUD örneği de onun “zamanda geri giderek kodu anlama” demosuna çok benziyor. İlgili video
• Bu fikri sevdiğim için, bunun kodlamaya genel olarak nasıl uygulanabileceğini düşündüm. Hayal edin: Kod yazarken LLM testler üretiyor ve IDE bu testleri gerçek zamanlı çalıştırıyor. Her tuş vuruşunda 10 ila 100 test <1ms içinde çalışıyor ve sonuçlar göze batmayacak şekilde gösteriliyor. Testler kodun yanında ayrı bir panelde duruyor, son çalıştırmada geçip geçmedikleri kırmızı/yeşil noktalarla belirtiliyor. Hangi testlerin olduğu, hangilerinin olmadığı ve durumları sadece buna bakarak bile yazmakta olduğunuz kodun “dışarıdan” ne yaptığını anlatıyor. Eğer LLM'nin üretmediği bir teste ihtiyaç duyduğunuzu düşünüyorsanız, bu prompt'un yanlış olduğu ya da kodun niyetten saptığı anlamına gelebilir. Gerçek zamanlı olma özelliği kodu rafine etmede büyük yardım sağlar. Bunu geleneksel TDD ile yapmak isterseniz, kullanıcı testleri yazar ve LLM de testleri geçecek kodu üretir.
  • Testleri önce insanın yazıp LLM'nin kodu üretmesi çok daha iyi. Çünkü testler kodun “gerçeği” ve “niyeti”dir. Girdi ve çıktıyı belirleme inisiyatifini bırakırsanız, geliştirici artık sürücü koltuğunda değildir.
  • Ciddi C++ kod tabanlarında bu yaklaşım uygulanabilir değil. Sadece derleme süreleri bile bunu imkansız kılar ve LLM'nin testleri tahmin etmesi de tüm kodu yazmadan zordur. Örneğin yeni bir veri yapısı oluşturuyorsanız, LLM bunu nasıl bilecek?
  • Kod yazarken LLM'nin test üretip IDE'nin bunları her seferinde çalıştırması iyi bir yaklaşım değil. Testler değişmezlikleri garanti eden kodlardır; LLM'nin onları rastgele kurcalaması sorun yaratır. Testler sadece kullanıcı açıkça değiştirdiğinde değişmeli ve sadece kendileri değişmelidir. Bu kısıtlar altında bu zaten günlük iş akışının bir parçası olmuş durumda. JavaScript test çerçevelerindeki watch modu gibi. Geliştiriciler böyle iş akışlarını zaten 10 yıldır kullanıyor.
  • Testlerin doğru yazıldığını doğrulayan testlere de ihtiyaç olmaz mı? Yoksa LLM testlerin kendisi yanlış olsa bile sadece onları geçirmeye çalışacaktır. Hatta sistemi kandıran kod da yazabilir. Sonuçta iyi çalışan bir kurulum için LLM ile insanın kendi sınırlarını serbestçe aşabildiği bir ortam gerekir. Sadece net gereksinimleri yazıp iki tarafın çoğunu AI'a bırakmak çok daha üretken ve akıcı olur.
  • Her girdi için tüm test paketini çalıştırmanın ROI'si çok düşük. Tuş vuruşlarının çoğu “tamamlanmamış” bir programa aittir; bu yüzden testleri ne zaman çalıştıracağınızı daha akıllıca belirlemek, mantıklı bir denge kurmak için şart.
• Sonuçta her şey şu soruya çıkıyor: "İnsanların dijital bilgiyle etkileşime girmesi için ideal arayüz nedir?" Her gün daha fazla bilgi alıyoruz ve yapay zeka nedeniyle bu miktar azalmıyor, artıyor. Karmaşık ve uzmanlık gerektiren bilgileri de (örneğin hata loglarını) özetleyebilirseniz, daha önce bunları göremeyen insanlar için bilgiye erişimde yeni yollar açılır. Öyleyse bu kadar bilgiyi nasıl verimli şekilde işleyeceğiz? Şu anda türlü türlü arayüzler, siteler, panolar, e-postalar ve sohbetler var; ama 10 yıl sonra bunların hepsine hâlâ ihtiyaç olup olmayacağını sorguluyorum. Tüm bilgiyi tek bir sohbet arayüzünden alabiliyorsam, sırf bunun için bir siteye girmem gerekir mi? AI'ın bizim yerimize web siteleri, uygulamalar ve web arayüzleri üretmesi artık biraz... gereksiz tekrarmış gibi geliyor.
  • Web sitesi dediğiniz şey, bir şirket ya da Wikipedia gibi güvenilir bir yerden “resmî” bilgi almanın yoluydu. Bu güven o kadar güçlüydü ki “line of death”, kilit simgesi, phishing önlemleri ve homograf saldırılarına karşı önlemler üzerinde çok çalıştık. Her şey bu sitenin güvenilir, resmî bilgi verdiği varsayımıyla yapıldı. Herkesin LLM'lere eleştirel olmadan dayandığı bir dünyada “güven”in ne anlama geldiği gerçekten kafa karıştırıcı. LLM genelde doğru olsa bile, çok kritik anlarda ona güvenebilir miyiz?
  • 6. nesil savaş uçağı tasarımcıları da tam aynı sorunla karşı karşıya. Kokpit, uçak ile pilot arasındaki arayüz ama rolü giderek küçülüyor. 7. nesilde insanın değerli bir rolü kalıp kalmayacağı bile belirsiz. (Yine de uluslararası hukuk ya da Skynet riski yönetimi gibi nedenlerle insan müdahalesi gerekirse varlığını sürdürebilir.) Muhtemelen tüm alanlardaki arayüzler de bu yönde evrilecek. Karmaşıklık giderek azalacak ve insan sadece sisteme ne istediğini yüksek seviyeli kavramlarla anlatacak. Bunun mutlaka doğal dil olması gerekmez; hassas bir spesifikasyon gerekiyorsa ona uygun bir arayüz de olabilir.
  • Her insan farklı olduğuna göre, arayüzleri genellemek yerine anında dinamik biçimde özelleştirmek gerekir.
  • Akıllı telefonların gerçekten mükemmel ve fiilen yeterince kullanılmış olduğunu söylemek zor. Yine de benim en sevdiğim cihaz onlar.
• AI'ın gerçek zamanlı karmaşık görselleştirmeler üretme yeteneğinin gerçekten faydalı olacağını düşünüyorum. Örneğin belirli bir kod yolunda bellek sızıntısı ayıklarken, AI o yol üzerindeki bellek ayırma/serbest bırakma işlemlerini görselleştirerek sorunu anlamaya yardımcı olabilir. Her bir probleme uygun görselleştirme araçlarını AI'ın bizzat ürettiği bir çağ geliyor gibi. Jonathan Blow'un LambdaConf'taki son konuşması bu fikirle birebir örtüşüyor. Programları farklı şekillerde görselleştirerek potansiyel sorunları bulan araçlar gösterdi. AI'ın bu tür araçları iyi yapabileceğini düşünüyorum. Videonun tamamı
• Claude Code'un TODO öğeleriyle bağlantılı değişiklikleri doğrudan bir HUD'da görmek isterdim. Satır içi yorumlar sonra birikiyor ve LLM bunları düzgün toparlayamıyor, o yüzden bunu istemiyorum.
• HUD'ların henüz yaygınlaşmamış olmasının en büyük nedenlerinden biri, bugün kullanılan ekran ortamlarının sınırlamaları. Monitörler ve mobil cihazlar çevresel ve müdahaleci olmayan bilgi sunmakta zayıf. AI ajanı hataları düzeltirken ya da karmaşık görevleri işlerken, sonuçları bekleme süresi tuhaf oluyor. Başka bir şeye geçmek için fazla kısa, ama ekrana boş boş bakmak için de fazla uzun. HUD olsaydı çok daha kısa geri bildirim döngülerine sahip olabilirdik. AI'ın ne yaptığını göz ucuyla takip edip anında müdahale edebilir ya da hiçbir şey kaçırmadan başka işinize devam edebilirdiniz. Tüm dikkati vermek ya da tamamen uzak durmak gibi iki uç arasında kalmak yerine, ortam farkındalığı içinde müdahale düzeyini anlık seçebilmek önemli. Bu yüzden VR/AR'ın AI HUD için temel killer app olabileceğini düşünüyorum. Mekânsal bilişim sayesinde, 2D ekrandan gözünüzü ayırmadan AI yardımını alabilirsiniz. Bu yaklaşım yemek yapmak ya da bisiklet tamiri gibi fiziksel işlerde de özellikle çok faydalı olur.
  • Ben ultrawide monitör ile dizüstü ekranını birleştirip zaten benzer şekilde kullanıyorum. Oyuna dalmışken ya da başka bir işle meşgulken, köşede bir tmux penceresinde Claude açık duruyor; bir sonraki adım ya da önemli bir değişiklik olduğunda hemen bakıyorum.
• HUD tarzı kodlama arayüzünün aslında fiilen AREPL olduğunu düşünüyorum. Hata ayıklama için uygun, ama sohbet penceresi ya da satır içi Soru-Cevap bana çok daha çeşitli kullanım alanları sunuyor gibi geliyor. Genel olarak sohbet dışı alternatif arayüz mantığına katılıyorum, ama pratikte sohbet zaten akıllı telefonlarda baskın arayüz. HUD ise muhtemelen AR gözlükleri gibi gerçek HUD'lara daha çok yakışır.
• Arka planda uzun süre otonom biçimde çalışabilen ve gerektiğinde bilgiyi “push” eden AI modellerinin de mümkün olduğunu düşünüyorum. Bağlamı akıllıca algılayıp filtreleyen, özetleyen ve gerektiğinde öneriler sunan bir yapı. Özellikle birçok müşteriyi 100 farklı durumda izlemek zorunda olan iş ortamlarında bu çok daha doğal olur.
  • Aslında en zor kısım bağlamı tanımlamak ve ilgili veriyi toplamak. Otonom bir sistemin bunu yapması problemi ise teknik olarak zaten uzun zaman önce çözülmüştü.
• "AI için tasarımı ciddiye alacaksak, yalnızca bir copilot'tan fazlasını, insanın iç dünyasını genişleten biçimleri düşünmemiz gerekir" görüşüne katılıyorum. Aslında auto-complete bile zaten böyle bir işlev görüyor. Elbette LLM ile konuşabilirsiniz ama sadece komut verebilir ya da otomatik tamamlama da kullanabilirsiniz. Sanırım yazarın kabaca vurgulamaya çalıştığı şey, AI'ın bizimle yan yana, aynı yöne bakarak çalışması gerektiği. Masanın karşı tarafında bizimle tartışan bir 'sanal insan' gibi copilot değil; söylediğimizi hemen yapan gerçek bir iş birliği ortağı gerekiyor.
  • Yazar burada. Evet, GitHub Copilot'un otomatik tamamlama arayüzü gerçekten de (ironik biçimde) iyi bir HUD örneği. Tab ile tamamlama, sanki beynin bir parçasıymış gibi akıyor. Ama son dönemde kodlama ortamı sohbet ajanlarına kayıyor. Daha yüksek bir soyutlama seviyesinde “tab ile tamamlama” arayüzünün nasıl görüneceğini hayal etmemiz gerekiyor. Ayrıntılara takılmadan, gerçekten doğrudan hissettiren bir kod tasarımı biçimi olabilir.