Khi mọi người đều có AI nhưng công ty vẫn chẳng học được gì

Ethan Mollick đã viết về việc áp dụng AI trong các tổ chức một thời gian rồi. Trong tác phẩm Making AI Work: Leadership, Lab, and Crowd, ông đã chỉ ra rằng: sự gia tăng năng suất cá nhân nhờ AI không tự động chuyển hóa thành lợi ích cho tổ chức. Con người có thể làm việc nhanh hơn, viết tốt hơn, phân tích sâu hơn, tự động hóa nhiều hơn, hoặc âm thầm trở thành những phiên bản "người máy" của chính họ. Tuy nhiên, công ty có thể vẫn chẳng học được điều gì cả.

Minh họa giai đoạn áp dụng AI

Hiện nay, rất nhiều công ty đang bước vào giai đoạn mà ở đó giấy phép GitHub Copilot đã được cấp phát, ChatGPT Enterprise xuất hiện ở đâu đó trong hệ thống, Claude hay Gemini hay Cursor ló diện lên từng nhóm nhỏ, và mỗi team đều có ít nhất một người đi xa hơn nhiều so với những gì tài liệu hướng dẫn chính thức dự đoán. Một phần việc này là hữu hình, nhưng phần lớn lại không.

Ban quản lý nhìn thấy việc sử dụng giấy phép ("ROI của 2 triệu € chúng ta trả cho Anthropic năm ngoái ở đâu?"), có thể là số lượng prompt, một cuộc khảo sát, hoặc một vài PoC (bản chứng minh khái niệm) nội bộ trông đủ hứa hẹn để đưa vào slide trình bày của ủy ban điều hành. Ở những công ty khác, AI được đưa thẳng cho bộ phận IT và rồi "chết yểu" ở đó.

Tôi nghĩ mọi người đều biết đây là giai đoạn mọi thứ trở nên phức tạp, thực sự là rất phức tạp. "Giai đoạn hỗn loạn ở giữa" (messy middle) của việc áp dụng AI bắt đầu khi việc sử dụng AI ở khắp mọi nơi, không đồng đều, một phần bị che giấu, khó so sánh và chưa được kết nối với việc học hỏi của tổ chức.

Giờ thì ai cũng có Copilot

Giai đoạn đầu của việc áp dụng AI (phần lớn) khá thoải mái vì nó trông giống như các đợt triển khai phần mềm doanh nghiệp khác. Bạn mua chỗ ngồi (seats). Bạn định nghĩa quy tắc sử dụng chấp nhận được. Bạn tổ chức đào tạo. Bạn tạo ra mạng lưới những người tiên phong. Bạn yêu cầu mọi người chia sẻ trường hợp sử dụng trong một kênh Teams, kênh đó sẽ trông có vẻ sôi động một lúc rồi trở thành một "kho chứa đồ" doanh nghiệp nữa đầy những ý định tốt đẹp.

Giai đoạn thứ hai thì kỳ lạ hơn nhiều: một nhóm dùng Copilot như tính năng tự động điền mã (autocomplete) và coi đó là hết việc. Một nhóm khác chạy Claude Code trong các vòng lặp chặt chẽ, với kiểm thử, đánh giá (review) và điều hướng liên tục. Một chủ sở hữu sản phẩm (product owner) đột nhiên tạo mẫu phần mềm thực thay vì chỉ vẽ màn hình giả trong Figma. Một kỹ sư cao cấp ủy thác phân tích nguyên nhân gốc rễ cho một tác nhân AI và quay lại với giải pháp hợp lệ trong chưa đầy một giờ; việc này từng mất hai tuần nếu không có AI. Một người mới tạo ra mã nguồn bóng bẩy nhưng không có chút nào nào về các giả định kiến trúc đã bị lén lút đưa vào hệ thống. Một nhóm hỗ trợ âm thầm chuyển đổi các vé thường xuyên thành quy trình tự động hóa, vì họ biết chính xác nỗi đau nằm ở đâu và không ai trong Trung tâm Năng suất xuất sắc (Center of Excellence) từng đặt đúng câu hỏi.

Tất cả những điều này có thể xảy ra trong cùng một công ty tại cùng một thời điểm. Đó là lý do khiến giai đoạn hỗn loạn này trở nên lộn xộn: đơn vị áp dụng không còn là tổ chức, và có thể cũng không phải là nhóm. Nó là vòng lặp bên trong công việc!

Khung Leadership, Lab, và Crowd của Mollick rất hữu ích ở đây. Leadership thiết lập phương hướng và quyền hạn. The Crowd (Đám đông) khám phá các trường hợp sử dụng vì Đám đông mới là người thực hiện công việc thực tế. The Lab (Phòng thí nghiệm) biến những khám phá đó thành các thực hành chung, công cụ, điểm chuẩn và hệ thống mới. Nhưng phần tôi cứ bị mắc kẹt chính là phần lặp đi lặp lại trong kỹ thuật tác nhân (agentic engineering): việc học hỏi thực sự di chuyển như thế nào?

Cỗ máy thay đổi cũ quá chậm cho việc này

Hầu hết các công ty sẽ cố gắng xử lý việc áp dụng AI thông qua các bộ máy họ đã có. Các cộng đồng thực hành, các buổi thảo luận ăn trưa (brown-bag sessions), mạng lưới người tiên phong, slide đào tạo, giờ tư vấn, demo hàng tháng, khảo sát, có thể là một bảng điều khiển (dashboard). Công bằng thôi, tôi đã làm, bạn cũng đã làm. Một số việc trong số đó giúp ích, đặc biệt là ở các tổ chức vẫn cần sự cho phép để thử nghiệm.

Nhưng công việc AI thú vị không đợi cuộc họp cộng đồng tiếp theo. Nó xuất hiện bên trong một bài đánh giá mã (code review), một đề xuất bán hàng, một nhiệm vụ nghiên cứu, một mẫu sản phẩm, một sự cố sản xuất, một chiến lược kiểm thử, một câu hỏi tuân thủ. Hoặc khi ai đó nhận ra rằng đối với một lớp nhất định các thành phần sản phẩm, họ có thể thiết lập thứ gì đó gần giống một "nhà máy tối" (dark factory): viết ý định, để tác nhân chạy một vòng lặp rất lỏng, áp dụng đủ áp lực ngược (backpressure) để giữ nó trên đúng quỹ đạo, đánh giá kết quả dựa trên các kịch bản mạnh, tinh chỉnh ý định và liên tục nhận được kết quả chất lượng cao. Đến lúc câu chuyện được dọn dẹp đủ sạch để trở thành một slide thực hành tốt nhất, bài học quan trọng thường đã mất đi "sự sắc bén" của nó. Điều khiến nó hữu ích là ma sát: bối cảnh bị thiếu, bài kiểm tra thất bại, hành vi API kỳ lạ, khoảnh khắc tác nhân lan man thành vô nghĩa và ai đó phải kéo nó lại.

Tôi đã suy nghĩ về điều này thông qua cùng một lăng kính với "vòng lặp đàn hồi" (elastic loop). Hợp tác với AI không phải là một chế độ! Nó kéo dài từ việc lái xe chung đồng bộ chặt chẽ đến việc ủy thác không đồng bộ lỏng lẻo hơn. Câu hỏi áp dụng không đơn giản là "mọi người có đang dùng AI không?". Đó là liệu các nhóm có biết kích thước vòng lặp nào nên dùng, ở đâu họ cần sức cản, hiện vật nào nên tồn tại qua vòng lặp, và làm thế nào những hiện vật đó trở thành thứ mà tổ chức có thể học hỏi từ đó.

Đó là một câu hỏi khó hơn nhiều so với việc sử dụng công cụ hay đếm đậu (token).

Scrum được xây dựng cho sự lặp lại tốn kém

Tôi đã lập luận rằng phần lớn quy trình phần mềm hiện đại tồn tại vì sự lặp lại của con người từng tốn kém. Lập kế hoạch Sprint, ước lượng, họp đứng (standups), user stories, chải thẻ (ticket grooming), bàn giao, tất cả các nghi thức xung quanh sự phối hợp và giảm thiểu rủi ro. Hợp lý, cho các ràng buộc đó. Nếu một lần lặp duy nhất mất vài ngày hoặc vài tuần, bạn cần các cấu trúc ngăn mọi người lãng phí quá nhiều trong số đó.

Nhưng kỹ thuật tác nhân thay đổi kinh tế học: Nó làm vật chất hóa nhiều tùy chọn hơn! Nó cho phép các nhóm chuyển từ ý định sang mẫu thử sang đánh giá nhanh hơn nhiều. Nó cho phép người làm sản phẩm thấy phần mềm hoạt động sớm hơn. Nó cho phép kỹ sư kiểm tra nhiều giả thuyết hơn trước khi cam kết. Nó không làm cho việc giao hàng trở nên dễ dàng một cách kỳ diệu, nhưng nó chuyển ràng buộc từ việc triển khai sang ý định, xác minh, phán xét và phản hồi.

Điều ngượng ngùng là nhiều tổ chức đã dành hai mươi năm tự gọi mình là linh hoạt (agile) trong khi vẫn giữ các phản xạ tổ chức mà agile lẽ ra phải loại bỏ. Giờ AI làm sự linh hoạt thực sự khả thi hơn, nhưng hệ thống vẫn yêu cầu cam kết sprint hai tuần, tài liệu bàn giao, và tất cả những thứ giả định sự lặp lại là khan hiếm.

Đó lại là "nghĩa trang nghi thức" nữa, nhưng giờ ở mức độ áp dụng. Vòng lặp có thể di chuyển nhanh hơn tốc độ tổ chức có thể chuyển hóa những gì vòng lặp học được.

Quầy bar mở sẽ không mãi mãi mở cửa

Có một áp lực khác đang tích tụ dưới tất cả những điều này. Việc sử dụng AI sẽ trở nên rõ ràng hơn về việc đo đếm. Cảm giác doanh nghiệp hiện tại của "ai cũng có quyền truy cập, đừng lo lắng quá nhiều về hóa đơn" sẽ không kéo dài mãi mãi, ít nhất không dưới dạng mọi người đang quen. Định tuyến mô hình, ngân sách token, giá cả tùy thuộc vào việc sử dụng, chi phí suy luận (inference costs), quản trị xung quanh việc mô hình nào được phép cho nhiệm vụ nào: tất cả những điều đó sẽ trở nên rõ ràng hơn khi các công ty chuyển từ hỗ trợ thân thiện sang công việc tác nhân nghiêm túc.

Tôi không muốn biến đây thành một câu chuyện hoảng loạn chi phí, đó sẽ là cách thú vị nhất để nghĩ về "trí tuệ thuê". Câu hỏi không phải là cách giảm thiểu chi tiêu token một cách trừu tượng, cũng giống như câu hỏi về giao hàng phần mềm chưa bao giờ là cách giảm thiểu số lần nhấn phím.

Nhưng hóa đơn sẽ ép buộc một câu hỏi tốt hơn: điều gì đã thay đổi vì chúng ta đã tiêu những token đó?

Làm ơn, tôi cầu xin các bạn, đừng đếm pull requests. Tốt hơn là: Vòng lặp nào đóng nhanh hơn? Quyết định nào được cải thiện? Phân tích nguyên nhân gốc rễ nào trở nên sắc bén hơn? Bài đánh giá nào bắt được lỗi nhiều hơn? Nhóm nào học được các mẫu có thể tái sử dụng? Ý tưởng sản phẩm nào bị loại bỏ sớm hơn vì mẫu thử đã làm lộ ra điểm yếu? AI tạo ra việc học ở đâu, và nơi nào nó chỉ tạo ra nhiều đầu ra hơn?

Token-đến-đầu ra là phản xạ đo lường cũ trong bộ trang phục mới. Token-đến-học-hỏi mới gần hơn với điều thực sự quan trọng.

Loop Intelligence là đường dẫn phản hồi còn thiếu

Tôi cứ quay lại với ba khả năng mà các công ty sẽ cần trong giai đoạn hỗn loạn ở giữa.

Agent Operations (Vận hành Tác nhân): Các tác nhân và công cụ AI nào đang chạy, chúng có thể chạm vào hệ thống nào, chúng có thể thấy dữ liệu nào, hành động nào cần sự phê duyệt, nơi danh tính, kiểm toán, quyền hạn và khả năng nhìn thấy thời gian chạy (runtime visibility) sinh sống. Đây là phía kiểm soát, và nó quan trọng vì công việc tác nhân cuối cùng sẽ chạm vào các hệ thống thực.

Loop Intelligence (Trí tuệ Vòng lặp): Các vòng lặp được hỗ trợ bởi AI (hoặc hoàn toàn tự chủ) nào thực sự tạo ra việc học, vòng lặp nào vẫn mở, vòng lặp nào suy giảm, nơi tác nhân tạo ra đòn bẩy, nơi chúng lan man vào các nhiệm vụ phụ, nhóm nào đang bị kẹt trong sự giám sát chặt chẽ vì thiếu kiểm thử, bối cảnh hoặc trực giác. Nhóm nào đã sẵn sàng cho việc ủy thác lỏng lẻo hơn.

Agent Capabilities (Khả năng Tác nhân): Cách các khả năng hữu ích được phân phối trên khắp tổ chức mà không giả vờ rằng ba tác nhân đơn khối có thể làm công việc của tất cả mọi người. AI bắt đầu hành xử giống như một công nghệ cơ bản lỏng hơn là một danh mục ứng dụng đơn lẻ. Nó không vừa kh neatly vào một "tác nhân HR", một "tác nhân kỹ thuật", một "tác nhân bán hàng", mỗi cái ngồi đâu đó trong vườn thú doanh nghiệp. Câu hỏi tốt hơn là cách các khả năng chảy vào nơi công việc diễn ra: dây đai nhân viên, tác nhân nền, nhóm sản phẩm, dịch vụ nền tảng, kỹ năng địa phương, máy chủ MCP, bộ đánh giá, sổ chạy (runbooks), ví dụ và quy trình cụ thể theo lĩnh vực.

Đây là nơi câu hỏi nền tảng trở nên thú vị. Ai sở hữu các khả năng này? Làm thế nào một kỹ năng tác nhân hữu ích được phát hiện trong một nhóm có thể sẵn có cho những người khác mà không biến thành một mẫu chết? Làm thế nào bạn làm giàu dây đai của một nhà phát triển khác với dây đai của một người làm sản phẩm, một tác nhân nền của nhóm hỗ trợ, hoặc một quy trình tuân thủ? Khả năng nào thuộc về gần nhóm, khả năng nào thuộc về lớp nền tảng, và khả năng nào không bao giờ nên được tổng quát hóa vì bối cảnh địa phương mới là cả điểm?

Có cái này mà không có cái kia nhanh chóng trở nên kỳ lạ. Agent Operations mà không có Loop Intelligence trở thành quan liêu kiểm soát. Loop Intelligence mà không có Agent Capabilities trở thành một lớp phân tích khám phá các mẫu hữu ích nhưng không có cách nào đưa chúng trở lại công việc. Agent Capabilities mà không có Operations và Loop Intelligence trở thành sự lan tràn công cụ với thương hiệu tốt hơn. Chúng ta đều có thể có những biểu đồ đẹp đẹp những ngày này, không cần hỏi bộ phận IT xây dựng bảng điều khiển nữa, đúng không?

Đường dẫn kiểm soát, đường dẫn học hỏi và đường dẫn khả năng phải gặp nhau ở đâu đó.

Nơi đó là thứ tôi đã gọi nội bộ là "dây đai phản hồi" (feedback harness). Tôi không chắc tôi thích thuật ngữ này cho khách hàng. Nó nghe quá giống thứ gì đó từ sơ đồ kiến trúc, và khách hàng không mua dây đai vì cơ chế thì thanh lịch, ngay cả khi đó là thứ của năm. Họ mua sự tự tin, quyết định tốt hơn, học hỏi nhanh hơn, lãng phí ít hơn, ủy thác an toàn hơn.

Vì vậy, khái niệm hướng tới khách hàng hữu ích hơn có thể là một Trung tâm Trí tuệ Vòng lặp (Loop Intelligence Hub).

Một dây đai phản hồi lắng nghe các vòng lặp công việc thực: nhiệm vụ, prompt, thông số kỹ thuật, đánh giá, kịch bản, các giả thuyết được chấp nhận và bị từ chối, tín hiệu sản xuất, làm lại, quyết định của con người và sự can thiệp. Không phải để theo dõi mọi người, mà để hiểu vòng lặp. Phiên bản đầu tiên không nhất thiết phải là một nền tảng khổng lồ. Chọn một vài quy trình công việc thực, lắp đặt các công cụ tại các điểm mà ý định, công việc tác nhân, xác minh và quyết định của con người đã để lại dấu vết, thu thập đủ phản hồi định tính để hiểu tại sao một vòng lặp hoạt động hoặc thất bại, và biến nó thành một hiện vật học hỏi định kỳ.

Một Loop Intelligence Hub biến các tín hiệu đó thành thứ mà tổ chức có thể hành động: một danh sách việc cần làm (backlog) để hỗ trợ, radar khả năng, bản tóm tắt đầu tư, các khoảng trống quản trị, quy trình công việc có thể tái sử dụng, nhu cầu đào tạo, ưu tiên đánh giá. Không có bảng điều khiển một kích cỡ phù hợp với tất cả, tùy chỉnh vào những gì liên quan. Đầu ra thú vị không phải là bảng điều khiển anyway. Đó là quyết định đi theo sau: nhóm này cần áp lực ngược tốt hơn trước khi có thể ủy thác thêm (mở rộng vòng lặp), nhóm sản phẩm này có một mẫu nhà máy tối có thể lặp lại cho một lớp hẹp các thành phần, quy trình tuân thủ này cần ranh giới công cụ được quản trị, kỹ năng này nên chuyển sang nền tảng vì năm nhóm đã phát minh lại nó một cách tồi tệ.

Dây đai thu thập và trung tâm giúp tổ chức quyết định. Lớp khả năng đưa việc học trở lại công việc.

Điều này không thể trở thành sự giám sát nhân viên

Cả thứ này sẽ chết nếu nó biến thành chấm điểm nhân viên.

Nếu mọi người tin rằng tổ chức đang đo lường xem họ có dùng đủ AI hay không, họ sẽ lách luật các tín hiệu. Nếu họ tin rằng mọi thử nghiệm trở thành kỳ vọng năng suất, họ sẽ giấu các thử nghiệm. Nếu họ tin rằng quy trình làm việc tốt nhất của họ đơn giản sẽ trở thành khối lượng công việc cơ sở mới của họ, họ sẽ giữ nó riêng tư. Công ty sẽ nhận được phiên bản áp dụng tồi tệ nhất có thể: sự tuân thủ hữu hình và việc học vô hình.

Đó là lý do ý định trung thực (không chỉ là cách định khung) thực sự quan trọng ở đây. Câu hỏi hữu ích không thể là "ai dùng AI đủ chưa?" mà là: AI đã thay đổi công việc theo cách nào mà tổ chức có thể học hỏi từ đó? Vòng lặp nào trở nên khỏe mạnh hơn? Nhóm nào cần áp lực ngược tốt hơn trước khi có thể ủy thác thêm? Nhóm sản phẩm nào cần môi trường khác vì các mẫu thử đang trở thành phần mềm thực?

Bạn có thể viết chính sách về điều này, và bạn có lẽ nên làm. Nhưng quản trị, giống như việc học, chỉ trở nên thực tế thông qua việc sử dụng. Một khi tác nhân chạm vào công việc gần sản xuất, một khi người làm sản phẩm tạo mẫu thay vì chỉ định thông số, một khi nhà phát triển ủy thác phân tích nguyên nhân gốc rễ, một khi chi tiêu token trở nên đủ lớn để ban quản lý muốn câu trả lời, tổ chức sẽ khám phá xem liệu họ đã xây dựng một hệ thống học hỏi hay chỉ mua nhiều chỗ ngồi.

Giai đoạn hỗn loạn ở giữa không phải là giai đoạn để tồn tại

Giai đoạn đầu của việc áp dụng AI là về quyền truy cập. Ai nhận được công cụ, ai có quyền phép, ai đàm phán hợp đồng, ai có thể thử mô hình mới nhất mà không cần điền phiếu mua sắm. Giai đoạn đó vẫn quan trọng, nhưng nó sẽ không tạo ra sự khác biệt trong dài hạn. Quyền truy cập vào trí tuệ tiên phong có thể được thuê. Kiểm soát vận hành và việc học hỏi tổ chức không thể được thuê theo cùng cách đó.

Lợi thế tiếp theo là tốc độ học hỏi.

Ai tìm thấy các mẫu thực sự nhanh hơn? Ai chuyển các khám phá từ cá nhân sang nhóm sang khả năng tổ chức? Ai xây dựng áp lực ngược vào các vòng lặp tác nhân, để các tác nhân không thể lan man? Ai phân phối các khả năng tác nhân hữu ích mà không biến chúng thành các tác nhân doanh nghiệp đơn khối không vừa vặn với ai? Ai cuối cùng sử dụng kỹ thuật tác nhân để làm cho agile trở nên thực tế, thay vì chỉ đè AI lên các nghi thức cũ?

Không ai hiểu điều này hết, tôi chắc chắn là chưa. Tôi đã lặp lại trên vòng lặp đàn hồi trong nhiều tháng, và mỗi cuộc trò chuyện với khách hàng, mỗi cuộc thảo luận nội bộ, mỗi ví dụ lạ lùng từ công việc thực lại định hình lại nó. Đó là điểm mấu chốt! Chúng ta sẽ không hiểu sự chuyển dịch này bằng cách chờ đợi một sách chơi áp dụng dứt khoát từ một nhà cung cấp, một tư vấn, hoặc một phòng thí nghiệm AI. Chúng ta sẽ hiểu nó bằng cách lắp đặt công cụ vào công việc, chia sẻ những bài học lộn xộn, để người khác chọc thủng, và lặp lại một cách công khai.