a16z Quan điểm mới nhất: Khi AI Agent trở thành người dùng chính của phần mềm

Viết bài: Vòng tròn suy ngẫm

Bạn đã từng nghĩ rằng toàn bộ logic xây dựng phần mềm của chúng ta có thể bị lật đổ hoàn toàn chưa? Trong vài thập kỷ qua, tất cả phần mềm đều được thiết kế cho con người. Chúng ta đã tốn vô số công sức để tối ưu giao diện người dùng: để các nút bấm dễ tìm hơn, để menu rõ ràng hơn, để quy trình thao tác mượt mà hơn. Nhưng nếu trong tương lai, người dùng chính của phần mềm không còn là con người nữa, mà là các agent AI thì sao? Nếu một công ty có 100 người nhưng lại có tới 1.000 agent AI đang làm việc, thì chúng ta còn nên đặt trọng tâm vào việc tối ưu giao diện cho con người nữa không?

Gần đây, trong một tập podcast của a16z, Erik Torenberg, Steven Sinofsky và Martin Casado đã có một cuộc trò chuyện cực kỳ sâu sắc với CEO của Box là Aaron Levie. Vấn đề cốt lõi mà họ bàn đến là: khi các agent AI trở thành người dùng chính của phần mềm doanh nghiệp, toàn ngành phần mềm sẽ được tái cấu trúc như thế nào. Cuộc đối thoại này khiến tôi nhận ra rằng chúng ta đang đứng ở rìa của một sự chuyển đổi mô hình còn dữ dội hơn nhiều so với tưởng tượng của phần lớn mọi người. Đây không phải là chỉ cần gắn thêm một tính năng AI vào phần mềm hiện có, mà là phải suy nghĩ lại từ gốc rễ: phần mềm nên được xây dựng ra sao, nên tương tác thế nào và nên được sử dụng ra sao.

Phần mềm phải được xây dựng cho AI Agent

Trong cuộc trò chuyện, Aaron Levie đưa ra một quan điểm khiến tôi phải suy ngẫm: nếu bạn có nhiều agent AI gấp một trăm lần, thậm chí một nghìn lần so với số lượng nhân viên, thì phần mềm của bạn bắt buộc phải được xây dựng cho agent. Đây không phải là bài toán “chọn hay không”, mà là xu hướng tất yếu. Hiện nay, Box dành thời gian suy nghĩ về giao diện dành cho agent, và thời gian đó đã ngang bằng với thời gian suy nghĩ về giao diện dành cho con người. Tốc độ của sự chuyển đổi này nhanh đến mức vượt xa dự đoán của tôi.

Logic đằng sau thực ra rất đơn giản. Khi các agent AI trở thành người dùng chính của phần mềm, chúng sẽ tương tác với hệ thống thông qua những giao thức như API, CLI (giao diện dòng lệnh) hoặc MCP (Model Context Protocol, mô hình ngữ cảnh giao thức). Và theo góc nhìn hiện tại, mô hình mang lại hiệu quả nhất là gì? Hãy cung cấp quyền truy cập vào các công cụ SaaS cho một agent có thể viết mã, để nó có thể truy cập vào quy trình làm việc và thông tin ngữ cảnh của bạn. Một agent như vậy không chỉ có thể đọc và hiểu thông tin, mà quan trọng hơn, nó có thể hoàn thành nhiệm vụ bằng cách viết mã hoặc sử dụng API.

Claude Code của Anthropic, “siêu ứng dụng” mà OpenAI đang phát triển và khả năng tính toán của Perplexity đều đang đi theo hướng này. Tôi cho rằng sự tăng trưởng theo cấp số nhân của các năng lực này mới chỉ vừa bắt đầu. Hãy tưởng tượng một agent không chỉ hiểu câu nói của bạn: “Giúp tôi phân tích dữ liệu bán hàng quý trước”, mà còn tự viết mã để trích xuất dữ liệu, phân tích, tạo biểu đồ trực quan—thậm chí chủ động phát hiện những xu hướng mà bạn chưa để ý. Ranh giới của năng lực này nằm ở đâu? Hiện tại tôi vẫn chưa nhìn rõ được.

Nhưng ở đây có một vấn đề then chốt khiến tôi luôn trăn trở: mọi người thường nói phải “xây dựng thứ gì đó cho agent”, “tiếp thị cho agent”, “có API tốt và ngôn ngữ mô tả giao diện tốt”. Martin Casado trong cuộc trò chuyện đưa ra một quan điểm phản biện mà tôi hoàn toàn đồng tình: cách nói đó gần như hoàn toàn sai. Tại sao? Vì agent chính xác là thứ giỏi nhất trong việc tìm ra đúng công cụ và hệ thống backend. Chúng sẽ không chọn bạn chỉ vì tài liệu API của bạn được viết đẹp đẽ, mà sẽ dựa trên các yếu tố mang tính thực chất như thông số chi phí, độ tin cậy của hệ thống, tính bền vững của dữ liệu. Agent sở hữu trí tuệ “tập thể” mà con người dùng các nền tảng đó.

Quan điểm này khiến tôi bừng tỉnh. Với tư cách là một ngành, chúng ta quá chú trọng vào giao diện và API, nhưng lại bỏ quên bản chất: chúng ta cần xây dựng chính bản thân hệ thống tốt hơn. Agent sẽ thúc đẩy chúng ta quay trở lại nền tảng kỹ thuật, thay vì chỉ là “bọc ngoài marketing”. Trước đây, quyết định mua phần mềm doanh nghiệp thường bị ảnh hưởng bởi năng lực bán hàng, sức ảnh hưởng của thương hiệu, thậm chí là các buổi chiêu đãi/tiệc chiêu đãi công việc. Nhưng trong một thế giới do agent dẫn dắt, các yếu tố đó sẽ giảm đáng kể trọng số. Agent sẽ đưa ra lựa chọn lý trí hơn dựa trên ưu nhược điểm kỹ thuật. Đây là cơ hội rất lớn dành cho những công ty thực sự tập trung vào bản thân kỹ thuật.

Ngưỡng tư duy thuật toán: không phải ai cũng có thể ra lệnh cho AI Agent

Trong cuộc trò chuyện có một đoạn thảo luận khiến tôi ấn tượng sâu sắc: những thách thức thực tế khi người không rành kỹ thuật sử dụng AI agent. Steven Sinofsky đưa ra một quan điểm sắc bén: tư duy thuật toán đối với đa số người đang đi làm thật sự—rất rất—khó. Nếu bạn bắt bất kỳ ai vẽ một sơ đồ quy trình cho nhiệm vụ mà họ cần hoàn thành, thì họ có khả năng sẽ thất bại.

Nhận định này trúng đích. Hãy hình dung trong một đội marketing có 50 người, phụ trách việc marketing cho một “dòng sản phẩm” lớn—có lẽ chỉ có 1 người thực sự hiểu và có thể tài liệu hóa toàn bộ quy trình làm việc. Nếu bạn đặt những công cụ hợp tác hoặc AI agent này trước nhân viên bình thường, thì năng lực để họ giải thích rõ ràng “phải làm gì” thực ra rất hạn chế.

Aaron Levie phản hồi rằng: việc này chỉ là công việc “dịch” lên một bậc nữa; bạn cần học một bộ kỹ năng mới. Điều này không khác gì bất kỳ lần thay đổi công nghệ nào trong lịch sử. Ông đưa ra một ví dụ rất thú vị: một nhân viên marketing tăng trưởng của Anthropic—chỉ một người—đã dùng Claude Code để làm công việc vốn cần từ 5 đến 10 người. Ví dụ này có ý nghĩa vì bản thân người đó là người có tư duy hệ thống; cô ấy đã hiểu đủ về kỹ thuật để làm được điều đó.

Nhưng điểm mấu chốt nằm ở đây: nếu bạn tưởng tượng rằng bên cạnh mỗi vị trí đều có một “vũng” tài nguyên kỹ sư vô hạn, có thể tự động hóa mọi việc mà người đó muốn làm, thì trong tương lai vị trí đó sẽ trở thành gì? Tôi nghĩ đây là một câu hỏi đáng suy ngẫm. Có lẽ agent sẽ ngày càng giỏi hơn trong việc hướng dẫn người dùng theo hướng tư duy hệ thống, nhưng ít nhất ở giai đoạn hiện tại, vẫn chỉ có một số ít người có thể sử dụng hiệu quả những công cụ này.

Steven Sinofsky chia sẻ một phép so sánh rất hay. Chị họ của ông, sau khi tốt nghiệp một trường thương mại danh tiếng, bắt đầu công việc đầu tiên đúng vào thời điểm mở đầu của kỷ nguyên máy tính. Trong thời gian học cao học, cô ấy chưa từng dùng bảng tính; đến năm đầu đi làm, cô ấy được biết rằng có thể thuê bất kỳ số lượng thực tập sinh nào, thế là cô ấy quản lý cả một phòng “agent”—những sinh viên đại học làm tất cả các công việc liên quan đến bảng tính. Nhưng thật kỳ diệu, trong vài năm tiếp theo, cô và các đồng nghiệp đều trở thành chuyên gia bảng tính. Lớp trừu tượng được nâng lên. Trước đây, các thực tập sinh dùng máy tính cầm tay và máy tính tài chính HP để làm—giờ cô tự làm bằng bảng tính, và có thể thực hiện 30 lần lặp thay vì chỉ 2 lần.

Câu chuyện này khiến tôi nhận ra rằng chúng ta đang ở một giai đoạn phát triển tương tự của AI agent. Bạn sẽ nghĩ cần 50 agent nhỏ, do một người cực kỳ thông minh điều phối chúng. Nhưng rất nhanh, những thứ đó sẽ “gấp lại” vào nhau, cuối cùng trở thành một tập hợp kỹ năng—một đoạn mã mà chúng ta gọi là agent—nó hiểu marketing. Bạn có thể hỏi nó các câu hỏi liên quan đến marketing, và bước tiếp theo, để nó thực hiện nhiệm vụ.

Tôi cho rằng điểm ngoặt quan trọng là: hiện tại, bạn cần phải là kiểu “nhà khoa học tên lửa” thì mới có thể tạo ra 42 agent và khiến tất cả vận hành được. Nhưng “độ khó tên lửa” đó sẽ sớm biến mất, và một mảng lớn kiến thức chuyên môn sẽ quay trở lại tay các chuyên gia trong lĩnh vực. Điều này gần như y hệt lộ trình tiến hóa của bảng tính.

Nỗi sợ của doanh nghiệp: mất kiểm soát tích hợp và cơn ác mộng về quyền hạn

Trong cuộc trò chuyện có một cảnh khiến tôi bị đánh động rất mạnh. Aaron Levie nói rằng gần đây ông đã chia sẻ quan điểm lạc quan tương tự trước một phòng toàn CFO và CIO. Kết quả là 6 người chạy tới nói: “Anh điên rồi, ở đây anh đã mất hết uy tín với tôi.” Tại sao? Vì ông nói rằng vấn đề tích hợp sẽ trở nên dễ hơn rất nhiều.

Những lo ngại của các lãnh đạo CNTT doanh nghiệp này hoàn toàn có cơ sở. Họ sợ không chỉ bản thân agent, mà còn sợ con người được trao quyền thực hiện tích hợp. Khi bạn cho phép nhân viên tạo ra các tích hợp mới, về cơ bản là bạn đang nói: “Hãy đến phá hủy hệ thống cốt lõi của tôi.” Hãy tưởng tượng có ai đó tạo một kết nối API mới giữa hệ thống 27 và hệ thống 38. Nếu chỉ dùng để tạo báo cáo thì người đó làm sai là chuyện của họ. Nhưng nếu liên quan đến thao tác ghi dữ liệu thì sao?

Aaron Levie cho rằng, trong một khoảng thời gian rất dài (N là một con số rất lớn), chúng ta sẽ có một phiên bản tích hợp agent chỉ đọc. Rất nhiều ứng dụng AI hiện nay thuộc tầng tiêu dùng—con người là người dùng cuối. Nhưng ngay cả ở tầng này, doanh nghiệp vẫn đối mặt với các thách thức mới.

Box vừa ra mắt CLI chính thức, Aaron mô tả một kịch bản: bạn cấp cho Claude Code Box CLI, và lúc đó bạn có thể dùng ngôn ngữ tự nhiên để tương tác với toàn bộ hệ thống Box. Bạn có thể dùng một mô hình mạnh như Opus 4.6 để orchestrate (biên phối/điều phối) một loạt thao tác. Nghe có vẻ rất tuyệt—bạn có thể nói “tải toàn bộ thư mục này trên máy tính của tôi lên Box”, hoặc “xử lý toàn bộ tài liệu trong thư mục này”, và nó làm được.

Nhưng các vấn đề phát sinh sau đó lại khiến người ta đau đầu. Hãy tưởng tượng một công ty có 5.000 nhân viên, mỗi người đều có quyền truy cập vào kho lưu trữ tài liệu kỹ thuật và tài liệu marketing dùng chung, và mỗi người đều dùng CLI. Lúc này, chúng ta đối mặt với một số thách thức mới rất thú vị: làm thế nào để điều phối các yêu cầu có thể gửi tới hệ thống tới 10000 lần mỗi giờ? Không phải vì hiệu năng, mà là làm sao để đảm bảo khi agent của một người đang di chuyển file, thì agent của người khác sẽ không đồng thời cố gắng thực hiện thao tác ghi vào một thư mục khác; và trong khi đó, agent của người thứ ba lại đang cố gắng xóa thứ gì đó. Khi các agent này chạy “điên cuồng”, đó sẽ là vấn đề mới mà mỗi CFO và CIO đều cần phải giải quyết với mức độ căng thẳng cực cao.

Trong quá trình tự kiểm tra, Aaron Levie cũng gặp vấn đề này. Khi ông thử tạo một ví dụ cấu trúc thư mục cho một kế hoạch marketing, ông bị mắc vào một vòng lặp, liên tục tạo các thư mục lồng nhau. Ông đùa rằng: “Tôi muốn biết giới hạn độ sâu của thư mục lồng nhau của Box là bao nhiêu, vì tôi sắp chạm tới rồi.”

Câu chuyện nhỏ này phản ánh một vấn đề lớn hơn: khi agent được trao năng lực thực thi, chúng có thể làm những điều ngoài dự đoán của chúng ta. Và chính sự khó lường này là điều mà doanh nghiệp sợ nhất.

Có coi AI Agent như nhân viên không? Không đơn giản vậy đâu

Trong cuộc trò chuyện có một đoạn bàn về cách quản lý AI agent khiến tôi thấy đặc biệt thú vị. Khi mọi người bắt đầu dùng các agent cá nhân, họ sẽ cấp cho chúng các API key riêng, địa chỉ email riêng. Vậy làm thế nào để ngăn chúng làm những việc không nên làm?

Martin Casado chia sẻ một cách làm thực tế: đưa cho agent của bạn số điện thoại riêng của nó, thẻ tín dụng riêng của nó (hy vọng là thẻ Visa trả trước mua từ CVS), và tài khoản Gmail riêng của nó. Gmail thực tế có nhiều cơ chế RBAC (kiểm soát truy cập dựa trên vai trò). Bạn có thể tranh luận rằng chúng ta đã xây dựng rất nhiều hệ thống quyền như vậy rồi, và nên đối xử với agent như một con người độc lập.

Nhưng Aaron Levie ngay lập tức chỉ ra vấn đề của mô hình đó. Trong một đội 50 người, liệu sẽ có 100 “người” cùng cộng tác—50 người là con người và 50 agent—tất cả cùng ở trong một không gian dùng chung chứ? Tôi chắc chắn có quyền giám sát hoàn toàn đối với agent của mình. Nhưng nếu agent của tôi cộng tác với người khác, và lỡ truy cập vào những tài nguyên mà lẽ ra tôi không được phép truy cập thì sao? Hiện giờ, các agent tự chủ và có trạng thái đang xử lý thông tin của người khác.

Ở đây có một mâu thuẫn căn bản. Đối với nhân viên thực sự, bạn không thể xem các kênh Slack của họ, không thể đăng nhập bằng danh tính của họ, và không thể giám sát mọi hành động của họ. Họ phải chịu trách nhiệm cho việc thực thi của chính mình; trong thế giới thực, bạn sẽ không bị phạt vì họ làm hỏng gì đó. Nhưng với agent, bạn phải chịu trách nhiệm cho mọi thứ mà nó làm. Bạn cần có quyền giám sát hoàn toàn, trong khi chúng không có quyền riêng tư.

Vì vậy, sẽ nảy sinh một số mâu thuẫn. Tôi cần có thể cấp quyền truy cập cho agent, nhưng cũng cần có thể đăng nhập vào bất cứ lúc nào bằng danh tính của nó, ví dụ: “Không được, mọi thứ bạn làm đã hỏng—tôi cần thu hồi tất cả các thao tác.” Nhưng nếu tôi có thể đăng nhập bằng danh tính của nó, thì làm sao nó có thể cộng tác với người khác trong thế giới thực, đồng thời vẫn giữ được tính bảo mật hoặc an toàn cho mọi thông tin? Do đó, về thực tế, agent gần như không thể không trở thành phần mở rộng của bạn.

Aaron Levie cũng đưa ra một vấn đề bảo mật sâu hơn nữa: chúng ta vẫn chưa biết cách khiến agent giữ kín bí mật. Nếu bạn nói với agent “đừng tiết lộ thông tin X trong cửa sổ ngữ cảnh”, thì việc này rất khó. Nếu mọi thứ đều có thể đi vào cửa sổ ngữ cảnh của agent vì chúng có quyền truy cập tài nguyên, thì về mặt lý thuyết bạn phải giả định rằng những thông tin đó có thể bị rò rỉ thông qua prompt injection (chèn prompt).

Điều đó có nghĩa là gì? Nghĩa là nếu tôi biết địa chỉ email của agent mới của bạn, tôi có thể gửi email cho nó; tôi có thể social engineering (tấn công kỹ thuật xã hội) nó—dễ hơn gấp mười lần so với social engineering một con người. Rất khó để khiến agent này đồng thời được quyền truy cập các thông tin nhạy cảm như tài liệu M&A của bạn.

Tôi nghĩ đây là một trong những rào cản kỹ thuật lớn nhất mà AI agent đang đối mặt hiện nay. Cho đến khi vấn đề này được giải quyết triệt để, agent rất khó có thể thực sự được trao quyền quyết định độc lập và quyền truy cập tài nguyên. Chúng sẽ luôn tồn tại như phần mở rộng của con người, chứ không phải như một thực thể độc lập.

Lợi thế của startup: mạnh dạn đón nhận AI Agent mà không do dự

Trong cuộc trò chuyện có một quan điểm khiến tôi đặc biệt đồng cảm: tốc độ lan tỏa của năng lực AI sẽ chậm hơn rất nhiều so với những gì người ở Thung lũng Silicon tưởng tượng. Lý do nằm ở chỗ các ràng buộc mà startup và các doanh nghiệp lớn phải đối mặt hoàn toàn khác nhau.

Aaron Levie nói rằng, chúng ta thấy startup có thể bắt đầu từ số 0 và xây dựng mà không gặp những rủi ro mà chúng ta vừa thảo luận, vì chúng không có gì để làm hỏng. Vì vậy, chúng ta xem đó như quỹ đạo phát triển mà mình đang đi. Nhưng khi bạn đến hỏi JPMorgan rằng họ sẽ thiết lập NanoClaw (một agent AI giả định) như thế nào để tự động hóa hoạt động kinh doanh, bạn sẽ thấy có một khoảng cách rất lớn.

Khoảng cách đó thể hiện ở đâu? Các doanh nghiệp lớn có 75 hệ thống kế thừa cần tích hợp, có các yêu cầu tuân thủ nghiêm ngặt, có các tiêu chuẩn an ninh dữ liệu được tích lũy trong hàng chục năm, và có cơ chế quản lý quyền hạn phức tạp. Và quan trọng hơn cả, họ có quá nhiều thứ không thể để mất. Nếu agent của một ngân hàng lớn rò rỉ dữ liệu khách hàng, đó có thể là một thảm họa khiến công ty có nguy cơ sụp đổ.

Steven Sinofsky đưa ra một dự đoán rất hay: startup sẽ đốt sạch nguồn vốn khả dụng và giả vờ rằng chi phí tính toán không phải là vấn đề. Nhiều công ty lớn sẽ đóng băng vì quá sợ hãi và không làm gì cả. Sau đó, nhân viên bình thường sẽ bắt đầu tự mua và tự sử dụng các công cụ này—làm những việc mà các công ty lớn có tiền nhưng lại không muốn chi.

Trong giai đoạn đó, sẽ có một số công ty sẵn sàng đặt cược vì nhiều lý do khác nhau, miễn là tình hình tài chính của họ cho phép. Những công ty này sẽ trở thành các nhà lãnh đạo trong lĩnh vực của mình, miễn là họ duy trì được sức khỏe tài chính. Sẽ không có tình huống kiểu như CFO sợ bị sa thải nên không ai dám tham gia. Sẽ có trường hợp CFO mắc sai lầm, nhưng điều đó cũng là bình thường.

Tôi cho rằng điều này sẽ tạo ra một sự phân hóa thị trường rất thú vị. Các công ty tầm trung dám đầu tư sớm và sẵn sàng chịu rủi ro có thể giành được lợi thế cạnh tranh trước các doanh nghiệp lớn. Họ có đủ nguồn lực để đầu tư vào AI, và không giống như các “ông lớn” khổng lồ, họ không bị trói buộc bởi hệ thống kế thừa và tâm lý né rủi ro.

Đồng thời, sẽ xuất hiện một nhóm các công ty dịch vụ hoàn toàn mới. Hãy tưởng tượng nếu bạn bắt đầu từ số 0 để tạo một công ty agency marketing, một công ty tư vấn kỹ thuật, hoặc một công ty thiết kế kiến trúc—bạn xây dựng hoàn toàn dựa trên các nguyên lý “first principles” của AI agent, không có rào cản thông tin và không có ranh giới cứng nhắc; bạn có thể cung cấp toàn bộ ngữ cảnh mà agent cần để làm việc, và có thể lập trình phần mềm cho các nhu cầu cụ thể bất cứ lúc nào. Trong một khoảng thời gian, các công ty như vậy sẽ có mức độ “lật đổ” khá lớn, cho đến khi các doanh nghiệp lớn hơn hiện tại thoát khỏi được các ràng buộc.

Ngân sách token: chiến trường mới của quản lý kỹ thuật

Trong cuộc trò chuyện có một đoạn về ngân sách token khiến tôi vừa thấy thực tế vừa thấy kỳ quặc. Aaron Levie nói: “Cuộc đối thoại về ngân sách tính toán kỹ thuật sẽ là một trong những cuộc tranh luận điên rồ nhất trong vài năm tới.”

Tại sao lại nói vậy? Vì chi phí kỹ thuật chiếm từ 14% đến 30% doanh thu của bất kỳ công ty công nghệ niêm yết nào. Nếu chi phí tính toán gấp đôi, hay chỉ cao thêm 3%, thì sự chênh lệch đó có thể quyết định toàn bộ EPS (thu nhập trên mỗi cổ phiếu) của công ty.

Nhưng Steven Sinofsky lại cho rằng chúng ta vẫn chưa có câu trả lời, và các CFO luôn muốn biết câu trả lời cho những câu hỏi mà họ chưa biết. Phố Wall sẽ ép họ đưa ra một con số và chịu trách nhiệm cho con số đó, rồi họ sẽ bị sa thải, và vòng lặp đó lại tiếp diễn. Đây không phải chuyện mới; chúng ta đã trải qua điều tương tự với mọi công nghệ mới như băng thông internet, ống chân không, transistor, số lượng lập trình viên, v.v.

Tuy nhiên, Aaron Levie khăng khăng rằng lần này có phần khác. Ông đưa ra một quan điểm rất hay: chưa bao giờ có khoảnh khắc mà mọi người dùng cuối trong tổ chức có khả năng linh hoạt hoàn toàn để kích hoạt nguồn lực thay mặt họ. Và trong nhiều trường hợp, việc họ kích hoạt các nguồn lực đó là hoàn toàn hợp lý.

Điều này đúng là tương tự với quá trình chuyển đổi sang điện toán đám mây đầu những năm 2000: khi đó chúng ta chuyển từ CapEx (chi tiêu vốn) sang OpEx (chi tiêu vận hành), rồi thành chi tiêu vô hạn. Aaron nhớ lại thời gian ở trung tâm briefing của Box hồi đó, khi các CFO nói: “Anh không hiểu đâu, chúng tôi là công ty nông nghiệp, chúng tôi chỉ quen với CapEx” hoặc ngược lại: “Chúng tôi là công ty OpEx, chúng tôi thích đám mây.” Sự khác biệt trong quy tắc kế toán thực sự ảnh hưởng đến việc ứng dụng công nghệ.

Nhưng vấn đề ngân sách token lại chi tiết hơn nữa. Với tư cách là một trưởng nhóm kỹ thuật, giờ đây bạn cần quyết định: có nên để các kỹ sư cân nhắc ngân sách tính toán cho từng prompt hay không? Bạn muốn các prompt chạy dài hay ngắn? Bạn có muốn song song hóa không? Mức độ bạn chấp nhận lãng phí token là bao nhiêu?

Aaron nói rằng thái độ của ông hiện tại là nên lãng phí rất nhiều token—vì điều đó có nghĩa là chúng ta đang thử nghiệm. Vậy liệu trưởng nhóm kỹ thuật có nên vui khi đội của mình chạy song song 10 thí nghiệm trước không? Dù hiển nhiên là sẽ lãng phí 90% token, nhưng bạn vẫn chọn một lộ trình dẫn tới thành công. Hay là nên yêu cầu đội thiết kế một hệ thống hoàn hảo trước khi chạy?

Trong lúc cuộc đối thoại này được ghi hình, mọi người đang hoảng vì kế hoạch Max mới của Claude Code, vì họ bị giới hạn sau ba prompt. Đây sẽ là một chủ đề rất thực tế, cho đến khi chúng ta thực sự có thể xây dựng được năng lực trung tâm dữ liệu.

Nhưng tôi đồng tình với quan điểm dài hạn của Steven Sinofsky: vấn đề này rốt cuộc sẽ biến mất. Lý do lớn nhất là bạn phải làm phép tính kiểu Benioff. Nếu bạn trả cho một nhân viên bán hàng 1 triệu USD mỗi năm, bạn phải hỏi công cụ của họ trị giá bao nhiêu. Nếu bạn trả cho một kỹ sư X USD mỗi năm, thì tại một thời điểm nào đó, công cụ của họ chắc chắn xứng đáng với khoản đầu tư đó.

Và định luật số lớn sẽ giải quyết vấn đề này. Cuối cùng, bạn sẽ có đủ nhiều kỹ sư: họ sẽ dùng một lượng lớn tài nguyên tính toán, và mọi thứ sẽ cân bằng lại. Hiện tại, chúng ta đang ở giai đoạn chuyển tiếp. Phần lớn mọi người hai năm trước tưởng rằng mức chi cho AI chỉ là chi phí cho một chatbot. Nhưng họ đã sai—vì họ coi nó như một trường hợp sử dụng cụ thể. Thực tế, đó là một sự chuyển đổi mang cấp độ nền tảng.

Tương lai của hệ thống SaaS: giá trị quay trở về ở lớp dữ liệu

Trong cuộc trò chuyện có một đoạn thảo luận về tương lai của hệ thống doanh nghiệp khiến tôi ấn tượng. Martin Casado đề xuất rằng các nhà cung cấp SaaS hiện tại đang gặp một vấn đề thú vị: họ thực ra không bán dữ liệu của các mảng kinh doanh; họ bán “tính thông minh”, kiến thức chuyên ngành và toàn bộ hệ thống. Nhưng bên agent chỉ muốn mua dữ liệu—chỉ muốn được cấp quyền đối với dữ liệu và có quyền truy cập vô hạn. Điều đó chưa bao giờ là mô hình kinh doanh của họ.

Đây vẫn luôn là một điểm căng thẳng lâu dài với các hệ thống như Workday và SAP—được phép truy cập bao nhiêu API? Salesforce đã trải qua ba lần thiết kế lại nền tảng lớn vì vấn đề này. Đây là một bài toán kỹ thuật đặc biệt thú vị: khi người ta muốn truy cập dữ liệu, thì “system of record” (hệ thống ghi nhận) nghĩa là gì?

Steven Sinofsky nói rất thẳng: “Muốn tạo ra một hệ thống kiểu SAP theo cách vibe coding thì thật là điên rồ.” Tất cả kiến thức theo miền trong SAP không chỉ nằm trong một lớp dữ liệu được sắp xếp cẩn thận. Nó tồn tại trong UI, tồn tại ở lớp trung gian, và tồn tại trong cách bạn sử dụng nó.

Nhưng Aaron Levie lại có quan điểm khác. Ông cho rằng nếu bạn lặp đủ nhiều vòng, cuối cùng agent sẽ chịu phần lớn trách nhiệm trong việc lựa chọn và sử dụng các công cụ mà nó muốn triển khai. Dù agent không thể thay thế các hệ thống doanh nghiệp, nhưng sau nhiều thế hệ phát triển, agent có thể gặp quá nhiều rào cản từ phần mềm của bạn đến mức nó sẽ nói: “Bạn cần cuối cùng loại bỏ hệ thống HR kế thừa của mình, nếu không tôi không thể tự động hóa quy trình công việc này cho bạn.”

Đây là một quan điểm mang tính đảo lộn. Hãy tưởng tượng khi số lượng agent gấp 100 lần hoặc 1.000 lần so với con người. Nếu cứ lặp lại tình huống này nhiều lần, cuối cùng sẽ phải xây dựng một “ngăn xếp” phần mềm cho agent. Có lẽ sẽ có vài hệ thống cố thủ, chẳng hạn một vài hệ thống ERP là nơi cuối cùng để cố thủ, nhưng mọi thứ khác trong doanh nghiệp của bạn sẽ gắn với việc agent có thể truy cập tốt đến đâu các thông tin cần thiết để làm việc. Vì vậy, toàn bộ ngăn xếp CNTT doanh nghiệp của bạn phải được thiết lập theo cách hỗ trợ các agent làm việc hiệu quả.

Martin Casado đưa ra một khác biệt tinh tế mà tôi rất đồng tình. Mọi người thường nói một cách trừu tượng rằng: “bây giờ bạn đang tiếp thị cho agent”, “bạn cần trở thành một API”, “bạn cần có ngôn ngữ mô tả giao diện tốt”. Ông cho rằng điều đó gần như hoàn toàn sai. Thứ agent thực sự giỏi chính là tìm ra backend phù hợp. Chúng sẽ không nói “cái giao diện này tốt, tài liệu tốt”, mà sẽ nói “cái này có tham số chi phí như vậy, cái kia có tính bền vững như thế nào.” Chúng thực chất sở hữu trí tuệ tập thể của chúng ta trong cách sử dụng các nền tảng này.

Ông nêu một ví dụ: mỗi lần ông để agent chọn một nền tảng điện toán đám mây, agent dùng những thứ mang ý nghĩa, chứ không phải những thứ liên quan tới giao diện. Vì vậy, với tư cách là một ngành, chúng ta quá tập trung vào các giao diện và tin rằng chủ đề như “bạn cần tiếp thị cho agent” là đúng. Trong thực tế, chúng ta sẽ bị thúc đẩy xây dựng các hệ thống tốt hơn—và đó mới là thứ sẽ được lựa chọn.

Tôi cho rằng quan điểm này cực kỳ sâu sắc. Trong thời đại agent, sự quan trọng của việc hơn kém về mặt kỹ thuật sẽ tăng lên, còn tầm quan trọng của marketing và “đóng gói” sẽ giảm đi. Những sản phẩm thực sự có năng lực cạnh tranh về kỹ thuật sẽ nổi bật, còn những sản phẩm chủ yếu dựa vào bán hàng sẽ gặp thách thức.

Những suy nghĩ của tôi: Chúng ta đã đánh giá thấp quy mô của cuộc biến đổi này

Sau khi nghe trọn vẹn toàn bộ cuộc trò chuyện, cảm nhận lớn nhất của tôi là: Phố Wall và cả ngành đang dùng một khung tư duy sai để hiểu tác động kinh tế của cuộc biến đổi này. Aaron Levie nói đúng: vấn đề lớn nhất là ai cũng đang cố tìm hiểu lợi ích kinh tế của tất cả những thứ này, nhưng họ lại đánh giá sai ít nhất một bậc độ lớn về quy mô của cơ hội.

Steven Sinofsky minh họa điều đó bằng các ví dụ lịch sử. Khi nhìn vào PC, người ta cho rằng việc “tiêu thụ MIPS” (triệu lệnh mỗi giây) là giới hạn của thị trường. Nhưng họ lại không nghĩ nếu đem tất cả MIPS đó đặt lên mỗi chiếc máy tính để bàn thì chuyện gì sẽ xảy ra. Ngoài ra, họ còn tưởng rằng phần mềm đi cùng với MIPS, và chỉ có một người (tức Bill Gates và Paul Allen) từng nghĩ đến việc có thể bán phần mềm riêng rẽ.

Chuyện tương tự cũng xảy ra với điện toán đám mây. Khi nhìn vào đám mây, người ta cho rằng chúng ta chỉ chuyển hoạt động của máy chủ (khoảng 60.000 máy mỗi năm) sang trung tâm dữ liệu của người khác. Không ai nghĩ rằng mức sử dụng sẽ tăng gấp 1.000 lần.

Với AI, điều tương tự cũng đang diễn ra. Mô hình của Phố Wall có một “miếng bánh doanh thu” cố định—tư duy kiểu zero-sum. Họ cho rằng mỗi công ty sẽ chi một khoản cố định hàng năm cho một thứ gì đó. Nhưng khi điện toán đám mây xuất hiện, vấn đề mà Salesforce gặp phải là CRM hàng năm trị giá 2 tỷ USD, liên quan đến việc mua tất cả các máy chủ đó, giấy phép Oracle và nỗi đau triển khai kéo dài nhiều năm cùng với các đơn vị tư vấn. Nhưng nếu bạn cho phép nhân viên bán hàng tự đăng ký cá nhân, họ sẽ đăng ký trơn tru, không hề có ma sát—đúng là điều đang xảy ra.

Tôi cho rằng AI agent sẽ mang đến một sự mở rộng thị trường tương tự, thậm chí còn lớn hơn. Khi mỗi người làm công việc tri thức đều có một hoặc nhiều agent làm việc bên cạnh, thì lượng sử dụng phần mềm, lượng xử lý dữ liệu và mức tiêu thụ tính toán sẽ tăng theo cấp số nhân. Đây không phải một trò chơi zero-sum, không chỉ đơn giản là chuyển công việc hiện tại từ con người sang agent, mà còn tạo ra các khả năng và giá trị mới hoàn toàn.

Aaron Levie nhắc rằng, với tư cách là một nhà đầu tư, ông tiếp xúc với khoảng 240 công ty hạ tầng. Trong 6 tháng qua, họ đều cho thấy mức tăng kiểu tiệm cận (ệm dần tăng lên theo tiệm cận). Tại sao? Vì hiện nay có nhiều phần mềm được viết ra hơn bất kỳ thời điểm nào trước đây. Khi có nhiều phần mềm hơn, nhiều agent hơn, thì sẽ có nhiều tài nguyên tính toán bị tiêu hao hơn. Khi AI được tiêu thụ rộng rãi trên điện thoại của mọi người, và AI trên thiết bị đầu cuối trở thành hiện thực, mức sử dụng sẽ tăng gấp một tỷ lần.

Tôi tin rằng chúng ta đang trải qua một “thời khắc transistor”. Steven Sinofsky minh họa bằng ví dụ về ống chân không. Ngày trước, có giai đoạn người ta cho rằng toàn bộ Dakodahta sẽ phải được phủ bởi các kho chứa ống chân không; mọi người đi giày trượt trong các hành lang để thay ống chân không, chỉ để phục vụ Chiến tranh Thế giới thứ hai. Rồi có người nói: “Hay dùng transistor thì sao.”

Token có thể giống như MIPS của IBM ngày xưa. Mỗi năm IBM bán nhiều MIPS hơn với giá thấp hơn, nhưng vẫn định giá mainframe theo MIPS, cho đến khi có người chỉ ra rằng đường cong của họ đang đi xuống vì tốc độ sản xuất MIPS nhanh hơn tốc độ họ thu phí. Tương tự, chuyện đó sẽ xảy ra với token.

Nhưng trong ngắn hạn, chúng ta sẽ chứng kiến sự hỗn loạn và bất định rất lớn. Doanh nghiệp sẽ giằng co giữa việc đầu tư bao nhiêu, kiểm soát chi phí như thế nào và quản lý rủi ro ra sao. Startup sẽ dám cược và di chuyển nhanh. Sẽ có thất bại, sẽ có thành công. Nhưng về dài hạn, hướng đi là rõ ràng: phần mềm phải được xây dựng cho agent, API sẽ trở nên quan trọng hơn UI, chất lượng hệ thống sẽ quan trọng hơn marketing, và chi phí tính toán sẽ tiếp tục giảm trong khi mức sử dụng sẽ tăng theo cấp số nhân.

Chúng ta không chỉ đang trải qua một lần nâng cấp công cụ đơn giản. Chúng ta đang trải qua một sự chuyển đổi nền tảng về mô hình tính toán. Những công ty và cá nhân hiểu điều này và hành động sẽ định hình bức tranh công nghệ của thập kỷ tới. Những ai vẫn còn tư duy bằng khung cũ có thể sẽ thấy mình bị bỏ lại phía sau rất xa.

Cuộc biến đổi này vừa mới bắt đầu.