AI copilot giờ đã đủ, chúng ta cần AI HUD

• Mark Weiser đã phê phán ẩn dụ AI 'copilot' từ năm 1992, và điều đó đến nay vẫn còn nguyên giá trị
• Weiser lập luận cho một giao diện hòa vào trải nghiệm người dùng một cách tự nhiên, thay vì một 'trợ lý'
• Khái niệm HUD (head-up display) trên máy bay hiện đại thể hiện rất rõ triết lý này
• Nhiều ví dụ cho thấy giá trị của UI kiểu HUD mở rộng giác quan người dùng, thay vì automation hay agent UI
• Copilot hiệu quả với các công việc thường nhật, nhưng trong các tình huống sáng tạo/phi cấu trúc, HUD khuếch đại năng lực con người tốt hơn

---

Phê phán copilot của Mark Weiser năm 1992

• Năm 1992, Mark Weiser đã nêu ra phê phán đối với cách ví AI như một 'copilot' tại một sự kiện của MIT Media Lab về 'interface agents'
• Những vấn đề như nhận biết ngữ cảnh và tự động hóa, vốn vẫn còn phù hợp ngày nay, cũng đã được thảo luận từ thời điểm đó
• Thay vì 'copilot' (AI đóng vai trò hỗ trợ phi công như một con người ảo), Weiser ủng hộ các hệ thống giúp người dùng cảm nhận thông tin một cách tự nhiên
• Lý tưởng của ông là 'máy tính vô hình', một môi trường trở thành phần nối dài tự nhiên như một bộ phận của cơ thể người dùng

HUD (head-up display) và triết lý của Weiser

• HUD (Head-Up Display) trên máy bay hiện đại chồng lớp các thông tin cốt lõi như đường chân trời/độ cao lên màn hình trong suốt, để cung cấp chúng một cách tự nhiên trong tầm nhìn của phi công
• Khác với copilot, HUD không cần đối thoại mà vẫn mở rộng năng lực nhận thức một cách tự nhiên
• Khái niệm HUD này phù hợp với tính khả dụng mà Weiser đề xuất

Hiện thực hóa HUD trong phần mềm

• Trình kiểm tra chính tả hoạt động bằng cách tự động gạch đỏ lỗi chính tả, chứ không trò chuyện như một 'cộng sự AI'
• Kiểu cung cấp thông tin trực quan và tức thời như vậy là một ví dụ của HUD tạo ra giác quan mới cho người dùng
• UI debugger tùy biến dùng AI cũng trực quan hóa hành vi của chương trình, giúp người dùng tự nhận ra và hiểu vấn đề
• Cách tiếp cận này khác với automation truyền thống hay UI 'trợ lý ảo', và trực tiếp mở rộng giác quan của con người

Đánh đổi giữa HUD và copilot

• Tác giả giải thích rằng không phải HUD lúc nào cũng tốt hơn copilot, mà mỗi bên đều có ưu và nhược điểm riêng
• Với các tác vụ lặp lại và có thể dự đoán (ví dụ: bay thẳng), cách tiếp cận kiểu copilot là hiệu quả
• Với các vấn đề phi cấu trúc và mang tính sáng tạo (ví dụ: nhận thức tình huống khi hạ cánh khẩn cấp), các công cụ hỗ trợ nhận thức của con người như HUD phát huy sức mạnh rất lớn
• Các nhà thiết kế AI cần cân nhắc cả UI mở rộng giác quan con người như HUD, thay vì chỉ bó hẹp trong mô hình 'assistant'

Kết luận

• Trong thiết kế AI tương lai, cần nhận thức được giá trị và sự đánh đổi của cả mô hình copilot lẫn HUD
• Hãy giao việc tự động hóa thông thường cho trợ lý ảo; còn nếu muốn kết quả vượt trội hơn, cách mạnh mẽ nhất có thể là trao cho chuyên gia con người 'siêu năng lực mới' theo kiểu HUD

[GN⁺]

Ý kiến trên Hacker News

• Tôi rất tò mò liệu có hữu ích không nếu có thể bật/tắt một bản đồ nhiệt cho biết mỗi token trong file mã nguồn gây “bất ngờ” với mô hình đến mức nào. Các token màu đỏ sẽ có xác suất cao là lỗi, đặt tên tệ hoặc chú thích sai
  • Đôi khi mã khó dự đoán là vì thuật toán mới lạ, nhưng ngay cả trong những trường hợp đó thì tài liệu tốt hơn vẫn rất cần thiết. Nếu giải thích mã cho đúng, bản thân nó sẽ bớt gây bất ngờ hơn. Nói cách khác, có thể cấu trúc những phần nhất định của mã nguồn sao cho chúng không còn “bất ngờ”, và đó có thể cũng là một thực hành kỹ thuật tốt. Nhờ LLM mà mọi người đều bắt đầu quan tâm hơn đến tầm quan trọng của tài liệu tốt. Điều đó càng cần thiết hơn nếu muốn AI, chứ không chỉ người khác, đọc và hiểu được hệ thống
  • Tôi nghĩ ý tưởng này thực sự rất hay. Ngược lại, nếu các đề xuất của AI cũng có bản đồ nhiệt theo mức độ tin cậy thì sẽ cực kỳ hữu ích
  • Tôi muốn có tính năng như thế này ngay trong editor. Nó cũng sẽ hữu ích để kiểm tra xem bài viết có quá dễ đoán hay sáo mòn không. Việc tính perplexity cũng không khó, chỉ cần tích hợp vào UI của editor là được
  • Thú vị thật. Tôi thường cảm thấy từ thời kỳ bùng nổ LLM ban đầu đến nay, chúng ta vẫn chưa khai thác đủ những “quả thấp dễ hái”. Đây đúng là kiểu ý tưởng như vậy
  • Tôi nghĩ đây là một ý tưởng thật sự tuyệt vời
• Khoảng 10 năm trước, Bret Victor từng nói rằng việc giảm thiểu độ trễ phản hồi là một nguyên tắc sống. Ông cho rằng chu kỳ lặp nhanh không chỉ giúp lập trình tốt hơn mà còn đóng góp vào các insight sáng tạo. Ông đã tạo nhiều chương trình ví dụ để chỉ ra các phương án thay thế, và ví dụ HUD được nhắc trong bài gốc cũng rất giống với màn trình diễn của ông về việc “lần ngược thời gian để hiểu mã”. Video liên quan
• Tôi thích ý tưởng này nên đã nghĩ xem có thể áp dụng nó vào lập trình nói chung như thế nào. Hãy tưởng tượng thế này: khi viết mã, LLM tạo test cho bạn, và IDE chạy các test đó theo thời gian thực. Mỗi lần gõ phím, 10~100 test được chạy trong <1ms, và kết quả được hiển thị một cách không gây phân tâm. Test nằm ở một panel riêng cạnh mã, và trạng thái pass/fail của lần chạy gần nhất được phân biệt bằng chấm đỏ/xanh. Chỉ cần nhìn xem có những test nào, không có test nào và trạng thái của chúng, bạn cũng có thể hiểu đoạn mã đang viết đang làm gì từ “bên ngoài”. Nếu bạn nghĩ cần có một test mà LLM không viết ra, đó có thể là dấu hiệu prompt chưa đúng hoặc mã không khớp với ý định. Tính chất thời gian thực này giúp ích rất nhiều khi tinh chỉnh mã. Nếu muốn làm theo TDD truyền thống, người dùng cũng có thể viết test còn LLM sẽ viết mã để làm cho test pass
  • Cách con người viết test trước rồi LLM tạo mã tốt hơn nhiều. Vì test chính là “sự thật” và “ý định” của mã. Nếu từ bỏ quyền quyết định đầu vào và đầu ra, thì nhà phát triển sẽ không còn ngồi ở ghế lái nữa
  • Với codebase C++ nghiêm túc thì cách này là bất khả thi. Chỉ riêng thời gian compile cũng đủ khiến nó không thể thực hiện, và để LLM đoán ra test thì cũng khó trừ khi nó viết cả phần còn lại của mã. Ví dụ nếu đang tạo một cấu trúc dữ liệu mới, sao LLM biết được điều đó
  • Việc LLM tạo test trong lúc viết mã để IDE chạy liên tục không phải là cách hay. Test là mã đảm bảo các bất biến, nên không thể để LLM tùy tiện sửa. Test chỉ nên thay đổi khi người dùng chủ động chỉnh sửa rõ ràng, và chỉ bản thân test được thay đổi. Với các ràng buộc như vậy thì đây thực ra đã là workflow hằng ngày rồi. Giống watch mode của các framework test JavaScript vậy. Các lập trình viên đã làm workflow như thế từ 10 năm trước
  • Chẳng phải chúng ta cũng cần test để kiểm tra xem test có được viết đúng không sao? Nếu không thì LLM sẽ chỉ đơn giản làm cho test pass kể cả khi bản thân test sai. Hoặc nó có thể chỉ viết mã để qua mặt hệ thống. Kết quả là cần một môi trường nơi LLM và con người có thể tự do vượt qua ranh giới của nhau thì mới có được một thiết lập hoạt động tốt. Chỉ cần viết yêu cầu rõ ràng rồi để AI xử lý phần lớn cả hai phía sẽ năng suất hơn nhiều và streamlined hơn
  • Chạy cả bộ test sau mỗi lần nhập có ROI quá thấp. Phần lớn các lần gõ phím đều tạo ra một chương trình còn “chưa hoàn chỉnh”, nên cần quyết định thời điểm chạy test thông minh hơn để có được sự cân bằng hợp lý
• Cuối cùng thì mọi thứ đều quy về câu hỏi: "Giao diện lý tưởng để con người xử lý thông tin số là gì?" Mỗi ngày chúng ta tiếp nhận ngày càng nhiều thông tin, và vì AI mà lượng đó không giảm mà còn tăng thêm. Nếu ngay cả thông tin phức tạp và chuyên môn cao, chẳng hạn log lỗi, cũng được tóm tắt thì sẽ mở ra những con đường mới để những người trước đây không thể đọc được loại thông tin đó có thể tiếp cận. Vậy thì chúng ta phải xử lý khối thông tin khổng lồ này thế nào cho hiệu quả? Hiện nay có đủ loại giao diện, website, dashboard, email và chat, nhưng tôi tự hỏi liệu 10 năm nữa có còn cần tất cả như vậy không. Nếu tôi có thể nhận mọi thông tin trong một giao diện chat duy nhất, liệu còn cần phải vào từng website nữa không? Việc AI tạo website, app, web UI thay chúng ta giờ bắt đầu cảm thấy hơi... trùng lặp
  • Website vốn là phương tiện để nhận thông tin “chính thức” từ những nơi đáng tin như công ty hay Wikipedia. Chính sức mạnh của độ tin cậy đó khiến người ta đầu tư vào "line of death", biểu tượng ổ khóa, các biện pháp chống phishing và đối phó tấn công đồng hình ký tự. Tất cả đều vận hành trên giả định rằng website này là nguồn thông tin chính thức và đáng tin. Trong một thế giới nơi mọi người đều phụ thuộc vào LLM một cách không phê phán, khái niệm “niềm tin” thực sự trở nên rất mơ hồ. Dù LLM thường đúng, liệu ta có thể tin nó trong những thời khắc thật sự quan trọng không?
  • Các nhà thiết kế tiêm kích thế hệ 6 cũng đang đối mặt đúng vấn đề này. Buồng lái là giao diện giữa máy bay và phi công, nhưng vai trò của nó ngày càng giảm. Đến thế hệ 7 thì tôi nghi ngờ liệu con người còn có thể đóng vai trò có giá trị hay không. (Dù vậy, nếu vì luật pháp quốc tế hay quản lý rủi ro kiểu Skynet mà vẫn cần con người can thiệp thì có thể họ vẫn sẽ còn hiện diện.) Có lẽ giao diện trong mọi lĩnh vực cũng sẽ tiến hóa như vậy. Độ phức tạp sẽ ngày càng giảm, và con người chỉ cần mô tả điều mình muốn cho hệ thống bằng những khái niệm ở mức cao. Không nhất thiết phải là ngôn ngữ tự nhiên; nếu cần đặc tả chính xác thì cũng có thể là một giao diện phù hợp với mục tiêu đó
  • Vì mỗi người đều khác nhau, giao diện không nên bị khái quát hóa mà cần được tùy biến động ngay tại chỗ
  • Khó mà nói smartphone thực sự hoàn hảo và đã được khai thác gần như đầy đủ. Nhưng với tôi thì nó vẫn là thứ tôi thích nhất
• Tôi nghĩ khả năng để AI tạo ra các hình ảnh trực quan phức tạp theo thời gian thực sẽ thực sự hữu ích. Ví dụ khi debug memory leak trên một đường đi mã cụ thể, AI có thể trực quan hóa việc cấp phát/giải phóng bộ nhớ trên đường đi đó để giúp xác định vấn đề. Có vẻ chúng ta đang tiến tới thời kỳ mà AI sẽ tự tạo ra các công cụ trực quan hóa phù hợp với từng vấn đề riêng lẻ. Bài talk gần đây của Jonathan Blow tại LambdaConf chạm đúng vào ý tưởng này. Ông đã trình diễn các công cụ dùng nhiều cách khác nhau để trực quan hóa chương trình nhằm tìm ra vấn đề tiềm ẩn. AI có vẻ sẽ rất giỏi trong việc tạo ra những công cụ như thế. Xem toàn bộ video
• Tôi muốn thấy ngay trên HUD những thay đổi gắn với các mục TODO của Claude Code. Tôi không muốn chú thích inline vì về sau chúng sẽ tích tụ lại và LLM cũng không dọn dẹp chúng cho ra hồn
• Một trong những lý do lớn nhất khiến HUD vẫn chưa phổ biến rộng là giới hạn của các phương tiện hiển thị hiện nay. Màn hình monitor hay thiết bị di động đều không giỏi trong việc cung cấp thông tin ngoại vi, không xâm lấn. Khi AI agent sửa bug hoặc xử lý tác vụ phức tạp, quãng thời gian chờ kết quả rất lưng chừng. Nó quá ngắn để làm việc khác, nhưng cũng khá kỳ nếu cứ nhìn chằm chằm vào màn hình. Nếu có HUD thì có thể có vòng phản hồi ngắn hơn nhiều. Bạn có thể liếc xem AI đang làm gì và can thiệp ngay lập tức, hoặc cứ tiếp tục việc khác. Điều quan trọng là thay vì phải chọn cực đoan giữa tập trung toàn phần hoặc bỏ mặc hoàn toàn, bạn có thể linh hoạt chọn mức độ can thiệp trong một trạng thái nhận thức ambient. Vì thế tôi nghĩ VR/AR có thể là killer app cốt lõi cho AI HUD. Nhờ spatial computing, chúng ta có thể nhận hỗ trợ từ AI mà không cần rời mắt khỏi màn hình 2D. Cách tiếp cận này cũng sẽ đặc biệt hữu ích trong các công việc vật lý như nấu ăn hay sửa xe đạp
  • Tôi đang tận dụng kiểu này bằng cách kết hợp màn hình ultrawide với màn hình laptop. Trong khi đắm vào game hoặc làm việc khác, tôi mở Claude trong một cửa sổ tmux ở góc, rồi kiểm tra ngay mỗi khi có bước tiếp theo hoặc thay đổi quan trọng
• Tôi nghĩ giao diện lập trình kiểu HUD về cơ bản là AREPL. Nó hợp cho debug, nhưng tôi cảm thấy cửa sổ chat hay Q&A inline dùng được đa dạng hơn nhiều. Nhìn chung tôi đồng ý với lập luận rằng nên có giao diện thay thế ngoài chat, nhưng thực tế thì chat đã là giao diện áp đảo trên smartphone rồi. HUD có lẽ phù hợp hơn với HUD thực sự như kính AR
• Tôi tin cũng có thể có các mô hình AI hoạt động tự chủ lâu dài ở nền và “đẩy” thông tin khi cần. Chúng sẽ phát hiện ngữ cảnh một cách thông minh, lọc, tóm tắt để truyền đạt nội dung và nếu cần thì đưa ra khuyến nghị. Đặc biệt trong môi trường kinh doanh, nơi phải theo dõi nhiều khách hàng qua 100 tình huống khác nhau, cách này sẽ tự nhiên hơn nhiều
  • Thực ra phần khó nhất là định nghĩa tình huống và thu thập dữ liệu liên quan. Bản thân bài toán để hệ thống tự trị làm việc đó thì về mặt kỹ thuật đã được giải quyết từ lâu rồi
• Tôi đồng ý với nhận định rằng, "nếu thực sự nghiêm túc về thiết kế cho AI, ta phải nghĩ đến những hình thức mở rộng nội tâm con người vượt xa một copilot đơn thuần". Thực ra auto-complete cũng đã làm điều đó rồi. Tất nhiên ta cũng có thể thật sự trò chuyện với LLM, nhưng cũng có thể chỉ ra lệnh đơn giản hoặc dùng tự động hoàn thành. Điều tác giả dường như muốn nhấn mạnh là AI phải làm việc cùng phía với chúng ta, cùng nhìn về một hướng. Không phải một copilot kiểu 'con người ảo' ngồi đối diện bàn chỉ để tranh luận, mà là một cộng sự thực thụ có thể làm ngay điều chúng ta yêu cầu
  • Tôi là tác giả. Đúng vậy, UI tự động hoàn thành của GitHub Copilot thực sự là một ví dụ HUD rất hay, một cách đầy mỉa mai. Tính năng tab auto-complete hòa vào trải nghiệm như thể là một phần của bộ não. Nhưng gần đây môi trường lập trình đang nghiêng về các chat agent. Chúng ta cần tưởng tượng xem một UI “tab auto-complete” ở mức trừu tượng cao hơn sẽ trông như thế nào. Nó có thể trở thành một cách thiết kế mã thật sự trực tiếp, không bị vướng bởi các chi tiết phụ bên lề