Các User Interfaces đơn giản hơn trong tương lai AI

Các bài viết gần đây của tôi đã điểm lại những cách mà chúng ta nên lạc quan về tiềm năng viết các formal specifications tốt cho các phần mềm quan trọng của tương lai, cho phép thực hiện formal verification và các cách khác để tăng cường sự tin cậy vào các hệ thống đó. Bằng cách thực hiện loại formal verification nghiêm ngặt bao gồm cả suy luận về các giao diện giữa các thành phần hệ thống, chúng ta thường nhận được các lợi ích cybersecurity bổ sung hoàn toàn miễn phí. Mang tính suy đoán hơn, chúng ta có lẽ đang ở điểm khởi đầu của một lộ trình tăng tốc để tái cấu trúc nền kinh tế của chúng ta sao cho có nhiều phần hơn liên quan đến việc các AIs tương tác trực tiếp với nhau, giúp giải phóng các phần mềm liên quan khỏi việc phải đối mặt với các phức tạp của việc mô phỏng con người.

Kết quả của xu hướng cuối cùng đó có khả năng là sự sụt giảm đáng kể về độ phức tạp trong phần viết specification vốn xử lý các user interfaces. Tôi sẽ trình bày ba cách giúp việc đưa ra các lập luận chặt chẽ rằng các thành phần phần mềm mới này làm cho “người dùng” của chúng “hài lòng” trở nên dễ dàng hơn.

Xu hướng Signaling và Interface

Các giao diện máy tính đã thay đổi đáng kể theo thời gian. Một mặt, một phần quan trọng của sự thay đổi liên quan đến những đột phá thực sự về khái niệm trong cách thiết kế giao diện để thúc đẩy sự hài lòng của người dùng. Một số ý tưởng giao diện phụ thuộc vào sức mạnh tính toán thô, nơi mà các nhà thiết kế trước đây có thể đã biết rõ những gì họ ước có thể hiển thị cho người dùng, nhưng việc đưa những ý tưởng đó vào cuộc sống phải chờ đợi năng lực tính toán mở rộng. Có lẽ hầu hết các nhà quan sát sẽ nghĩ đến những yếu tố đó khi nhìn lại lịch sử của các user interfaces.

Bức hình hoạt họa này hiển thị những người dùng máy tính mặc các loại trang phục gắn liền với thời kỳ của họ, vì tôi muốn tạo mối liên kết giữa các computer user interfaces và thời trang quần áo. Tôi nghĩ phép tương đồng này chỉ giải thích một phần khiêm tốn chi phí tạo và bảo trì các user interfaces ngày nay, nhưng đó là một nguồn chi phí thực sự mà tôi kỳ vọng giờ đây sẽ giảm bớt tầm quan trọng.

Thời trang được công nhận rộng rãi là một ví dụ tuyệt vời về signaling và cạnh tranh địa vị. Chắc chắn, một số thay đổi trong trang phục bắt nguồn từ những cải tiến công nghệ giúp mở rộng không gian của những gì có thể sản xuất với chi phí hợp lý. Tuy nhiên, chúng ta chấp nhận rằng sự thay đổi trong lĩnh vực này phần lớn được thúc đẩy bởi tính thẩm mỹ.

Ở một mức độ nào đó, các xu hướng thời trang với những khác biệt tinh tế nhất so với các xu hướng trước đó là có giá trị nhất cho việc signaling. Thiết kế một thời trang mới mà ưu điểm của nó chỉ rõ ràng với những người trong cuộc có thể là công việc khó khăn nhất. Sau đó, những người trong cuộc đó có cơ hội thể hiện sự hiểu biết của mình bằng cách chỉ chọn ra những thời trang mới thành công trong cuộc chơi. Ở một mức độ nào đó, những người tham gia vào cuộc cạnh tranh địa vị này đang thể hiện các working memories của họ, bằng cách duy trì các sơ đồ tư duy từ các xu hướng thời trang đến dòng thời gian của chúng, để họ có thể phân biệt giữa các phong cách ít quen thuộc hơn vì chúng thuộc về thập kỷ trước so với việc đại diện cho một trường phái tiên phong đáng để tham gia sớm. Tải nhận thức chung của quy trình này làm cho nó hữu ích để đo lường trí thông minh của những bạn đời tiềm năng và các đối tác liên minh, cho dù chúng ta đang nói về trí thông minh kiểu học thuật hay trí thông minh xã hội để dẫn đầu trong các động lực nhóm.

Tôi muốn lập luận rằng các computer user interfaces cũng bao gồm một động lực tương tự, không mang tính trung tâm như thời trang quần áo, nhưng vẫn đủ quan trọng để ảnh hưởng đến các xu hướng áp dụng. Bây giờ, tôi có một lý do ích kỷ để đưa ra trường hợp này, với tư cách là một chuyên gia trong các phần mang tính “backend” hơn của hệ thống máy tính. Khi tôi thiết kế các user interfaces, chúng hầu như luôn bị chê là cổ hủ. Tôi hiểu cho những người phản đối rằng họ đang ghi nhận một số đổi mới thực tế chân chính bị bỏ qua trong cách tăng năng suất của người dùng. Tuy nhiên, tôi thực sự cảm thấy như có một yếu tố ghi nhớ các giao diện của các thời kỳ khác nhau và chỉ muốn được gợi nhắc về thẩm mỹ mới nhất, độc lập với các nguyên lý cơ bản đằng sau mỗi phong cách. Lời giải thích chắc chắn không thể là tôi vẫn nhớ cảm giác hào hứng hồi trung học khi các HTML tables và frames đầu tiên ra đời, đúng không?

Bất kể vai trò của signaling trong các user interfaces là gì, chúng ta có thể hy vọng rằng các AI agents sẽ có những việc tốt hơn để làm thay vì lo lắng về thời trang. Các phân tích chính quy mà chúng ta thực hiện có thể tập trung vào các yêu cầu thực dụng.

Sự trỗi dậy của các Giao diện Tối giản, Có cấu trúc

Chúng ta không cần phải dựa vào chế độ viễn tưởng khoa học để thấy những thay đổi giao diện quan trọng. Một bài viết năm 2025 của Salesforce lập luận rằng các GUIs sẽ giảm bớt tầm quan trọng khi các AI agents sinh sôi. Một bài viết khác cách đây vài ngày chứng minh cho tầm quan trọng ngày càng tăng của loại giao diện mang tính kỹ thuật cao như các REST APIs, vốn rất thuận tiện để sử dụng từ các chương trình – phần mềm sử dụng phần mềm. Nếu các “nhân công” của tương lai ngày càng là phần mềm, thì tự nhiên họ sẽ ưa chuộng loại giao diện này.

Hãy đi vào chi tiết hơn một chút. Tôi sẽ lập luận rằng các UIs hướng tới con người bị ảnh hưởng lớn bởi các giới hạn trong working memory của con người, tức những gì chúng ta có thể tập trung chú ý cùng một lúc. Hãy lấy ví dụ về các bộ điều khiển cho một chiếc máy bay.

Máy bay là một distributed system phức tạp, có cả các phần kỹ thuật số và tương tự, với các chi tiết đầy đủ và gây bối rối của chúng được trực quan hóa ở bảng điều khiển ngoài cùng bên trái. Về lý thuyết, một phi công có thể nhận đầu vào từ bất kỳ cảm biến nào trong hệ thống hoặc gửi yêu cầu đến bất kỳ bộ truyền động nào. Rắc rối là con người, ngay cả những người tinh hoa được đào tạo làm phi công, cũng không thể nhớ toàn bộ giao diện ở cấp độ đó. Chúng ta đang cứu người dùng khỏi một search process dò tìm trên mô tả toàn bộ hệ thống và mang lại các phần có liên quan, như buồng lái thực tế được hiển thị trong bảng điều khiển ở giữa. Với thiết kế phần mềm mà chúng ta quen thuộc, nhà phát triển thực hiện tìm kiếm tốn kém đó ngay từ đầu, trang bị cho mỗi “màn hình” của một chương trình chính xác các tùy chọn đầu vào và đầu ra được coi là có liên quan đến giai đoạn thực thi đó. This framing fits with the theory of distributed cognition, vốn cho rằng các biểu diễn được phân chia giữa các bên tham gia trong một hệ thống.

Tuy nhiên, chúng ta không nhận được bức tranh toàn cảnh nếu chỉ nghĩ về những gì có liên quan đến người dùng ở mỗi bước. Người dùng thường có một số nhiệm vụ trải dài qua nhiều bước, và working memory cũng khiến việc theo dõi trạng thái nhiệm vụ và những gì ở phía trước trở nên khó khăn. Vì vậy, mục tiêu của một GUI tại một thời điểm đơn lẻ không chỉ đơn thuần là hiển thị các tính năng khả dụng của hệ thống liên quan đến thời điểm đó: nó cũng cần tóm tắt kết quả của các quyết định trong quá khứ (cách chúng ta đến đây) và các tùy chọn cho các bước tiếp theo (nơi chúng ta có thể đi). Ở một mức độ nào đó, tất cả các bits trạng thái trong toàn bộ hệ thống là đủ để theo dõi cả hai khía cạnh, nhưng working memory của chúng ta không thể lưu trữ tất cả các bits đó, vì vậy chúng ta nhận được dự đoán của nhà thiết kế giao diện về việc hiển thị thông tin lớn vừa phải nào sẽ nhắc nhở chúng ta đang ở đâu trong một search process.

Các AI agents, được thể hiện ở bảng điều khiển ngoài cùng bên phải, đơn giản là có vị thế tốt hơn nhiều trong việc lưu giữ tất cả trạng thái liên quan trong bộ nhớ có thể truy cập với chi phí hợp lý. Vẫn có sự khác biệt trong việc truy cập các phần thông tin được lưu trữ khác nhau, được minh họa bằng các memory hierarchies và các context windows, nhưng ngay cả phương pháp lưu trữ chậm nhất cũng đại diện cho một thắng lợi lớn so với những gì con người có thể tập hợp được. Kết quả là, AI agent điển hình của bạn đã sẵn sàng đối mặt với một mô tả cơ bản về các phần và khả năng của hệ thống, vốn trông giống như một data schema hoặc một đặc tả API hơn là một GUI. Quan điểm cá nhân của tôi là việc thiết kế các abstractions tốt hơn vẫn sẽ quan trọng để tăng hiệu quả của các hệ thống này, nhưng rất nhiều thứ có thể được hoàn thành bằng sức mạnh thô tương đối (brute force).

Do đó, khi chỉ rõ điều gì làm cho một chương trình có thể chấp nhận được, chúng ta không cần lo lắng về các chi tiết giao diện cụ thể theo tình huống và khả năng hiểu chúng của người dùng. Thay vào đó, chúng ta có thể trình bày các mô tả tương đối trực nghĩa về những gì hệ thống có thể làm, một công việc thường dễ thực hiện chính xác hơn nhiều. Con người vẫn là đối tượng tiêu dùng quan trọng của các APIs ngày nay, đòi hỏi một lượng công việc trừu tượng nhất định của các nhà thiết kế API, điều này có thể ngày càng trở nên không cần thiết khi việc sử dụng AI chiếm ưu thế. (Và đừng lo lắng: trong các bài đăng sau, tôi sẽ tiếp tục lập luận về tầm quan trọng của abstraction trong việc giúp các hệ thống tương lai hoạt động nhanh hơn và đáng tin cậy hơn. Chỉ là lập luận ở đây có vẻ đủ mạnh ngay cả khi tiếp tục phụ thuộc nhiều vào brute force, như xu hướng ngày nay.)

Giá trị của một Open-Source User

Có một sự chuyển dịch thú vị khác trong động lực của phần mềm được sử dụng bởi phần mềm. Nó trở nên tương đối khả thi để có một mô hình có thể đọc được bằng máy về người dùng! Kết quả là quy trình tương đương với usability testing (kiểm thử khả năng sử dụng) trở nên rẻ hơn và có thể tự động hóa.

Điểm xuất phát chỉ là tạo ra một bộ test suite cho một dịch vụ, bao gồm việc chạy một loạt các chương trình client phổ biến chống lại nó. Loại bài tập này đã là tiêu chuẩn ngày nay.

Tuy nhiên, chúng ta có thể làm theo một chiến lược liên quan đến chiến lược tôi đã viết trước đây, đối với các AI agents dần tin tưởng vào code được cung cấp bởi các đối thủ cạnh tranh của chúng. Hãy xem xét bất kỳ người dùng nào của dịch vụ có source code được biết đến bởi tác giả dịch vụ. Người dùng đó có thể được xây dựng bởi cùng một tổ chức, hoặc nó có thể được phát hành ra thế giới dưới dạng open source. Giờ đây, bài tập đảm bảo chất lượng là thực hiện formal verification cho hệ thống kết hợp, có thể bao gồm dịch vụ và tất cả người dùng đã biết của nó. Các thuộc tính thậm chí có thể được kiểm tra đối với hành vi mới nổi (emergent behavior) phát sinh từ việc những người dùng khác nhau tương tác với nhau. Miễn là chúng ta có thể chính thức hóa, chẳng hạn, một số thước đo năng suất cho tập thể người dùng, giờ đây chúng ta có thể (với đủ nỗ lực chứng minh) đảm bảo thước đo đó trên vô vàn các tình huống khác nhau, mỗi tình huống kéo dài vô tận. Đó là một khoảng cách rất xa so với những gì có thể thực hiện được trong ngân sách usability-testing cho một chương trình phần mềm ngày nay!

Sự thay đổi trong góc nhìn thực sự có thể là một động lực mạnh mẽ cho sự phát triển phần mềm. Không chỉ là chúng ta muốn tiến hành kiểm tra cuối cùng đối với một dịch vụ mới trước khi phát hành nó ra thị trường. Chúng ta có thể đánh giá khả năng sử dụng lặp đi lặp lại trong suốt quá trình phát triển để định hình tất cả các lựa chọn mà chúng ta đưa ra. Các kiểm tra như vậy có thể hoạt động giống như các tool calls trong các AI coding assistants ngày nay. Một AI tìm kiếm trong không gian của các chương trình đáng xem xét, liên tục kiểm tra khả năng sử dụng để định hướng các quyết định của nó.

Tương lai lấy AI làm trung tâm của chúng ta, tất nhiên, vẫn có thể bao gồm một vai trò cho các dịch vụ được sử dụng bởi nhiều loại người dùng khác nhau, những người giờ đây tương ứng với các chương trình khác nhau, với các mục tiêu khác nhau, được viết vào các thời điểm khác nhau. Chúng ta không thể kiểm tra khả năng sử dụng của dịch vụ trước bằng cách tham chiếu đến source code cụ thể của những người dùng chưa được xây dựng. Tuy nhiên, ở đây, chúng ta đi đến điều có thể làm hài lòng sâu sắc các software engineers vốn quen thương lượng với những người dùng con người kỹ tính: chúng ta có thể áp đặt một formal specification lên người dùng, tuyên bố rằng bảo hành của dịch vụ sẽ bị vô hiệu nếu đối mặt với hành vi sai lệch. Người dùng có thể chọn đầu tư vào việc tự xác thực chính thức (formal verification) chính mình, trái ngược với con người, những người có lẽ thậm chí sẽ không buồn đọc các điều khoản dịch vụ này, chưa nói đến việc tự kiểm toán bản thân xem có tuân thủ hay không. (Ý tưởng này liên quan đến design by contract trong các phương pháp chính quy, vốn buộc tất cả các phần của một hệ thống phần mềm phải tuân theo một hệ thống đặc tả chung và đôi khi là chứng minh.)

Kết luận

Khi chuyển giao nhiều phần của nền kinh tế hơn cho AI, việc có thể viết ra chính xác các quy tắc chúng ta muốn các tác nhân đó tuân theo trở nên quan trọng. Nếu quá khó để chính thức hóa các yêu cầu của chúng ta, thì chứng minh chính quy (formal proof) rằng các tác nhân đáp ứng chúng là điều không tưởng. Các user interfaces là một phần phức tạp của phần mềm như chúng ta biết, điều này có thể gợi ý một nhiệm vụ khó khăn phía trước trong việc chính thức hóa phần đó cho các hệ thống AI. Tuy nhiên, nếu như tôi lập luận ngày càng nhiều hoạt động của các AI agents sẽ là tương tác với các tác nhân khác, thì có một vài lý do để kỳ vọng rằng việc chính thức hóa các giao diện của chúng sẽ dễ dàng hơn dự kiến (ít nhất là đối với các tác nhân hoạt động hoàn toàn bên trong các vùng khả đọc).

1. Các user interfaces đã thay đổi để tuân theo các xu hướng thời trang, điều này không phải là mối bận tâm của các AI agents.

2. Các user interfaces đã được thiết kế xung quanh các giới hạn trong working memory của con người, trong khi giao diện cho các AIs có thể chỉ cần trình bày “các sự thật” theo cách trực tiếp nhất.

3. Khi người dùng của một hệ thống chính là các chương trình, việc kiểm thử hoặc thậm chí chứng minh chính quy hệ thống chống lại người dùng của nó trở nên rất rẻ, mà không tốn bất kỳ chi phí và sự chậm trễ nào của việc tuyển dụng mọi người cho usability testing. Thật vậy, một bài tập chứng minh đơn lẻ có thể bao trùm tất cả người dùng trong một danh mục được xác định chính thức nào đó (ngay cả một danh mục vô hạn).

Dựa trên những tiến bộ này, có thể chuyển đổi quy trình tương đương với usability testing thành các chứng minh chính quy (formal proof) mạnh mẽ.

Sự phản đối còn lại mà tôi mong đợi ở thời điểm này, từ tất cả các software engineers ngoài kia, là phần thực sự khó khăn của một dự án vẫn là tìm hiểu xem người dùng thực sự muốn gì, điều này hầu như độc lập với các chi tiết giao diện. Tôi đồng ý: yếu tố đó là những gì làm cho việc tự động hóa hoàn toàn software engineering trong thế giới ngày nay trở thành một vấn đề thực sự “AI-hard”! Nhưng trong một thế giới mà AI thậm chí còn mang tính trung tâm hơn, khía cạnh này có còn khó khăn như vậy không? Bài viết tiếp theo của tôi lập luận tại sao lại không.