Kỷ nguyên của phần mềm mở rộng: Khi LLM thay đổi cách chúng ta tùy biến ứng dụng

Hầu hết các phần mềm web mà chúng ta tương tác ngày nay đều ở trạng thái tĩnh. Các nhà phát triển có quỹ thời gian và sự tập trung hạn chế, nên họ ưu tiên xây dựng các tính năng phục vụ cho nhóm người dùng lớn nhất. Phần đầu của đường cong nhu cầu được đáp ứng tốt bởi các phần mềm hiện có, nhưng vẫn tồn tại một "đuôi dài" (long-tail) các nhu cầu chưa được thỏa mãn, vốn khác biệt đối với từng người dùng.

Ngay cả khi các nhà phát triển cực kỳ tâm huyết để nhồi nhét mọi tính năng, giao diện người dùng cũng chỉ có thể phức tạp đến một mức độ nhất định trước khi trở nên không thể sử dụng được. Mỗi tính năng bổ sung lại làm cho sản phẩm trở nên phức tạp hơn đối với những người dùng khác. Nếu thị trường cho tính năng đó nhỏ, nó có thể vô tình làm cho sản phẩm trở nên tệ hơn đối với tất cả những người dùng không cần đến nó.

Trong bối cảnh này, sự trỗi dậy của lập trình hỗ trợ bởi LLM thực sự đã trao quyền cho bất kỳ ai cần những thứ nằm trong "đuôi dài" này.

Phần mềm đã trở nên… linh hoạt hơn.

Rõ ràng là các LLM thực sự rất xuất sắc trong việc xây dựng "Phần mềm cho một người" (Software for One). Đó là những ứng dụng cá nhân giúp né tránh mọi sự phức tạp và trách nhiệm giải trình của phần mềm doanh nghiệp, đồng thời được tùy chỉnh hoàn toàn cho quy trình làm việc của một cá nhân duy nhất.

Pete Koomen tại Y Combinator cho rằng đang có một cơ hội cho thứ mà họ gọi là "Phần mềm nhỏ" (Small Software). Tôi nghĩ họ đã tìm ra một hướng đi đúng đắn.

Pi là một ví dụ điển hình cho thứ mà tôi bắt đầu coi là phần mềm thuần LLM (LLM-native software): một lõi phần mềm đã được kiểm chứng qua thực tế, nhưng gần như có khả năng mở rộng vô tận chỉ bằng cách đặt câu hỏi, nơi người dùng có thể chia sẻ các tùy chỉnh của họ với người khác. Trong năm qua, người dùng của bạn đột nhiên có khả năng "nói" để tạo ra mã nguồn. Hầu hết các phần mềm hiện có không thể tận dụng được điều này, nhưng Pi thì có.

Tôi nghi ngờ rằng chúng ta sẽ bắt đầu thấy nhiều phần mềm tuân theo mô hình tự mở rộng này hơn. Tuy nhiên, hầu hết các ví dụ hiện có về phần mềm có thể cắm thêm (pluggable software) đều là phần mềm cục bộ: các AI agent, IDE cho lập trình viên, bản mod cho trò chơi điện tử, các add-on của Blender, hay các tiện ích mở rộng CAD. Đây thường là những công cụ chuyên nghiệp với rào cản gia nhập cao.

Web là hệ thống phân phối phần mềm thành công nhất trên thế giới. Nó không nên bị bỏ lại phía sau.

Giả thuyết của tôi là đang có một cơ hội mới cho "Phần mềm có thể mở rộng" (Extensible Software) trên web. Các LLM làm giảm đáng kể chi phí tạo ra các tiện ích mở rộng, và các nguyên tắc sandbox hiện đại giúp giảm chi phí triển khai đồng thời cung cấp các ranh giới bảo mật tốt. Chúng ta có thể xây dựng ứng dụng của mình như một lõi vững chắc, có trách nhiệm giải trình và cho phép người dùng mở rộng nó một cách an toàn theo nhiều hướng bằng cách để LLM lấp đầy những mảnh ghép còn thiếu. Chúng ta có thể trao cho người dùng của mình những siêu năng lực.

Tiết lộ: Hiện tôi đang làm việc tại Cloudflare, nơi việc tiếp xúc nhiều với các bài viết của Kenton Varda đã định hình phần lớn tư duy của tôi ở đây. Gần cuối bài, tôi sẽ lập luận rằng Dynamic Workers là một lựa chọn đặc biệt phù hợp cho mô hình này, nhưng trước hết tôi sẽ đề cập đến một vài phương án thay thế.

Điều này sẽ trông như thế nào?

Rất nhiều hệ thống web ngày nay dựa vào webhook để cho phép người dùng phản ứng với các thay đổi trong ứng dụng. Cách này ~tạm ổn, nhưng nó đặt ra một rào cản rất cao cho việc mở rộng: phải xây dựng và vận hành một dịch vụ hoàn toàn riêng biệt, cộng với việc giải quyết mọi vấn đề phát sinh trong quá trình truyền tải.

Tôi muốn có thể kết nối vào các bản cập nhật bản ghi và chèn logic của riêng mình vào. "Khi tôi gắn thẻ này vào một bản ghi, hãy chạy hàm của tôi". "Hãy thực hiện hành động này cho tôi theo lịch cron hàng ngày".

Thực ra, tôi không muốn phải suy nghĩ về điều đó chút nào. Tôi muốn nói với ứng dụng "đọc sau" (read-it-later) của mình rằng:

Và sau đó, một con robot sẽ tạo ra các đoạn mã đơn giản, kết nối chúng vào một số điểm mở rộng và biến điều đó thành hiện thực. Tôi cũng nên có khả năng chia sẻ những gì mình đã tạo với bất kỳ ai khác có cùng nhu cầu về tính năng đó.

Dưới đây là một số lĩnh vực khác mà tôi rất muốn thấy cách tiếp cận mở rộng thuần LLM.

AI Agents

Được rồi, đây là ví dụ rõ ràng nhất. Pi, DeepSeek và OpenCode đều đang thử nghiệm trong không gian này.

Thay vì thêm mọi ý tưởng mới vào lõi của mình, Pi cung cấp các điểm kết nối (hooks) ổn định cho các công cụ, lệnh, sự kiện và giao diện người dùng, để nó có thể biến một yêu cầu thành một tiện ích mở rộng TypeScript nhỏ và tải lại ngay tại chỗ. Các tiện ích mở rộng đó sau đó có thể được đóng gói để chia sẻ, cho phép hệ sinh thái hấp thụ "đuôi dài" của các ý tưởng mà không làm cồng kềnh chính phần mềm đó.

Tuy nhiên, đối tượng sử dụng những thứ này, ít nhất là như hiện tại, khá nhỏ. Bạn phải cảm thấy thoải mái khi chạy phần mềm tùy chỉnh trên máy cục bộ của mình. Trong môi trường doanh nghiệp, tổ chức phải cảm thấy thoải mái khi bạn chạy phần mềm mà chưa ai từng, hoặc sẽ không bao giờ, xem xét qua. Trừ khi bạn tự sandbox Pi, các tiện ích mở rộng của Pi sẽ chạy với cùng quyền hạn như chính Pi.

Các kỹ sư phần mềm sẽ tìm ra cách, nhưng kế toán, bác sĩ, luật sư và hàng ngàn ngành nghề khác cũng xứng đáng có được những công cụ tốt hơn. Họ cần những agent có thể được tùy chỉnh một cách an toàn và dễ dàng cho lĩnh vực và quy trình làm việc của riêng họ.

Nếu chúng ta muốn có nhiều người sử dụng agent hơn, điều đó không có nghĩa là biến họ thành lập trình viên phần mềm. Mà là làm cho phần mềm phù hợp với nhu cầu của họ.

Nền tảng doanh nghiệp nội bộ

Tất cả các công ty đều kết thúc với hàng tấn dữ liệu. Nhân viên cần xem, truy vấn, điều tra, đối chiếu dữ liệu đó với dữ liệu khác trong hệ thống khác, tìm khách hàng đang gặp <vấn đề x>, tìm khách hàng sắp rời bỏ, và hàng triệu việc khác.

Rất nhiều công ty đang thử nghiệm việc cho phép các nhân viên đam mê AI tự viết mã cho công cụ của riêng họ, có thể là triển khai nó lên một PaaS. Điều này đúng về mặt định hướng, nhưng lại tạo ra hàng loạt vấn đề kéo theo. Khi bạn có hàng trăm hoặc hàng ngàn ứng dụng như vậy, làm thế nào để duy trì chúng? Làm thế nào để chúng có quyền truy cập vào dữ liệu cần thiết? Làm thế nào để chúng chỉ truy cập vào đúng dữ liệu cần thiết? Làm thế nào để kiểm toán những gì phần mềm này đang làm? Nếu chúng ta dựa vào các token truy cập, phạm vi của chúng là gì? Ai là người xoay vòng chúng? Làm thế nào để đảm bảo chúng ta không ghi nhật ký thông tin khách hàng ra bên thứ ba? Làm thế nào để đảm bảo chúng ta không vi phạm GDPR?

Hoặc hàng triệu vấn đề tuân thủ và bảo mật khác mà các doanh nghiệp thực sự cần phải lo lắng.

Điều gì sẽ xảy ra nếu chúng ta cung cấp cho họ một nơi để triển khai mã nguồn mà không có các token xác thực có thể bị rò rỉ? Nơi mà việc truy cập dữ liệu được xử lý bởi một nhóm nền tảng nội bộ có thể đảm bảo tất cả các tiêu chuẩn tuân thủ đều được đáp ứng? Hãy cho họ không gian để xây dựng các tự động hóa hoặc chế độ xem tùy chỉnh của riêng họ, nhưng một cách an toàn.

Bật mí: Đây về cơ bản chính là Cloudflare OS.

Nền tảng hỗ trợ

Tôi đã dành phần lớn sự nghiệp của mình để xử lý các phiếu hỗ trợ (support tickets) hóc búa. Không thể tránh khỏi việc tôi phải đào bới qua các bảng điều khiển, tìm kiếm nhật ký, lấy dữ liệu từ hàng triệu nơi khác nhau. Hãy cho phép tôi tạo các tiện ích mở rộng hiển thị dữ liệu cho người dùng đã mở phiếu từ hệ thống cụ thể của tôi vào giao diện hỗ trợ. Hãy cung cấp cho tôi các điểm kết nối để tôi có thể khởi chạy các agent thực hiện vòng điều tra đầu tiên cho tôi, trước cả khi tôi nhìn vào nó. Nếu có những tác vụ phổ biến mà tôi cần làm như "đặt lại hạn ngạch X cụ thể", hãy cho phép tôi thêm một nút vào chế độ xem của mình để thực hiện điều đó.

Sau đó, cũng hãy cho phép tôi chia sẻ những thứ này với nhóm của mình để tất cả chúng ta có thể giúp đỡ lẫn nhau.

Nền tảng quan sát (Observability)

Rất nhiều công cụ quan sát đã hội tụ về cùng một bộ tính năng: một cách để tìm kiếm nhật ký của bạn với biểu đồ thanh nhỏ ở trên cùng. Một chế độ xem thác nước (trace waterfall) để xem các dấu vết (traces) riêng lẻ. Các bảng điều khiển chỉ số có thể tùy chỉnh. Có thể là một bản đồ dịch vụ. Một vài công cụ đang thử nghiệm các hình ảnh hóa mới, đặc biệt là với sự trỗi dậy của các agent.

Biểu đồ thác nước dấu vết đáng kính rất hữu ích cho các hệ thống có dạng yêu cầu/phản hồi, nơi bạn chủ yếu quan tâm đến độ trễ và tỷ lệ thành công. Nhiều người trong chúng ta đang thấy mình làm việc với các hệ thống có phần… trạng thái… hoặc năng động hơn. Các ứng dụng hiện đại đang chạy các agent không xác định hoặc các công cụ quy trình làm việc bền bỉ, nơi một hành động duy nhất có thể mất hàng giờ hoặc hàng ngày. Các khoảng dấu vết (trace spans) là nguồn sự thật tuyệt vời để xây dựng dựa trên đó, nhưng hãy để tôi thử nghiệm với các hình ảnh hóa của riêng mình (hoặc cài đặt của người khác).

Ngoài những thứ đẹp đẽ mà tôi có thể nhìn thấy, hãy cho phép tôi chèn logic của riêng mình:

Phần mềm có thể mở rộng trên web thì… khó hơn.

Tôi vừa làm cho tất cả những điều đó nghe có vẻ dễ dàng. Nhưng thực tế thì không hề như vậy.

Tôi là một người hâm mộ lớn của Obsidian, cả với tư cách là một công cụ tôi sử dụng hàng ngày và là một phần mềm.