Nhà tiên phong DevOps cảnh báo: Việc áp dụng AI Agent đòi hỏi những thay đổi ở cấp độ hệ thống, không chỉ là công cụ

Đừng sửa mã do Agent tạo ra, hãy sửa hệ thống tạo ra mã đó.

Tác giả bài viết, nguồn: InfoQ

Nếu một nhà phát triển không thể sử dụng Agent hiệu quả, vấn đề có thể không nằm ở nhà phát triển, mà ở việc công ty chưa chuẩn bị một hệ thống hoạt động hiệu quả cho Agent.

Nhiều doanh nghiệp gọi đó là chuyển đổi AI, nhưng thực chất vẫn chỉ dừng lại ở việc mua công cụ cho lập trình viên như Cursor, Claude Code, tổ chức vài buổi đào tạo, rồi để mọi người tự mày mò. Nếu cuối cùng hiệu quả của Agent không tốt, trách nhiệm lại đổ cho người sử dụng.

Tuy nhiên, Patrick Debois, người đặt ra thuật ngữ DevOps, cho rằng: “Các nhà phát triển cần thực hiện một sự thay đổi tư duy quan trọng: Khi Agent không hoàn thành nhiệm vụ theo mong đợi của bạn, đừng cố sửa mã mà nó tạo ra, mà hãy cải tiến toàn bộ hệ thống, thay vì chỉ sửa Prompt.”

Theo Debois, đây là sự thay đổi tất yếu khi kỹ thuật phần mềm chuyển từ các hệ thống xác định sang các hệ thống phi xác định, xác suất và quy trình làm việc. Nó không chỉ liên quan đến công nghệ, mà còn tái định hình cách thức làm việc của các nhà phát triển, đội nhóm và toàn bộ tổ chức. Tuy nhiên, sự thay đổi này không thể chỉ dựa vào một kỹ sư đơn lẻ, hay chỉ dừng lại ở cấp độ một đội nhóm. Giống như DevOps, nó chỉ thực sự phát huy hiệu quả khi được triển khai quy mô lớn.

Vấn đề cốt lõi không chỉ là các nhà phát triển có sử dụng Agent hay không, mà là công ty có thể tái tổ chức đội ngũ, nền tảng và cách thức hợp tác xung quanh Agent hay không.

Các điểm chính như sau:

• Đừng sửa mã do Agent tạo ra, hãy sửa hệ thống tạo ra mã đó.
• Nếu trong đội của bạn vẫn còn ai đó dùng cách làm “YOLO (chạy qua đã)” để code theo cảm hứng, bạn nên ngay lập tức ngăn cản. Thực hành kỹ thuật không chỉ cực kỳ quan trọng đối với việc duy trì hệ thống của bạn, mà còn quan trọng đối với việc Agent tự cải thiện liên tục.
• Nhà máy tối có thể không hoàn toàn tối, mà chỉ giữ lại một chút ánh sáng yếu (dim factory), điều này có nghĩa là bạn phải quyết định mức độ rủi ro nào cho từng tính năng, vì không phải tất cả các tính năng đều phù hợp với sự tự trị hoàn toàn.
• Người bạn đang tìm kiếm là người có thể tận dụng AI một cách tối ưu, có nền tảng kỹ thuật vững chắc và sẵn sàng chia sẻ, hợp tác.
• Sự bảo vệ của bạn là việc nắm bắt những kiến thức được tích lũy, những bối cảnh nghiệp vụ mà bạn đang đưa vào skill, Context, thậm chí là các ràng buộc của Harness.

Năm 2009, rất nhiều người nói với tôi rằng ý tưởng về giao tiếp liên tục là điên rồ.

Ghi chú của người dịch: Năm 2009, ngành công nghiệp thường áp dụng mô hình phát hành phiên bản lớn định kỳ vài tháng một lần, mọi người đều cho rằng số lần phát hành càng nhiều thì rủi ro càng cao, đồng thời rào cản giữa phát triển và vận hành rất nghiêm ngặt, các cơ sở hạ tầng tự động hóa như container và đám mây chưa phát triển, thiếu các công cụ pipeline tiêu chuẩn, trong khi các cơ chế kiểm thử và phê duyệt thay đổi truyền thống nhằm loại bỏ tối đa lỗi trước khi triển khai. Trong khi đó, giao tiếp liên tục đưa ra tư tưởng phát hành tần suất cao, tăng dần và có thể triển khai bất kỳ lúc nào, làm đảo lộn nhận thức truyền thống về rủi ro và quản lý quy trình khi triển khai phần mềm, do đó, đối với hầu hết các doanh nghiệp, nó gần như là điều không tưởng và cực kỳ điên rồ.

Và hiện tại, Dark Factory lại gặp phải sự phản đối hoàn toàn giống hệt.

Translator's note: The Dark Factory refers to an AI-driven autonomous software production model where humans only input SPEC, and AI autonomously completes coding, testing, and deployment without requiring human review of code line by line, differing from traditional software factories that still require substantial engineer involvement in the process.

Tôi đã nghe lặp đi lặp lại cùng một câu nói trong nhiều hoàn cảnh: “Thứ này không hoạt động được ở đây.” Nhưng thông điệp thực sự đằng sau câu này không phải là công nghệ không khả thi, mà là “chúng tôi chưa sẵn sàng.” Họ không phải không muốn triển khai thứ này, mà là cấu trúc hiện tại của toàn bộ tổ chức chưa hỗ trợ được mô hình này.

Hiện nay, rất nhiều người đang nói về cách tối ưu Agent bằng vòng lặp, cách xây dựng Harness, những điều này đều rất tuyệt vời. Nhưng tôi muốn nói rằng, cuối cùng chúng ta đều sẽ đạt đến trình độ kỹ thuật đó, và một ngày nào đó, chúng sẽ trở thành những sản phẩm tiêu chuẩn, thậm chí được một phòng thí nghiệm tiên tiến đóng gói thành dịch vụ cung cấp. Đến ngày đó, rào cản kỹ thuật sẽ không còn nữa. Sự khác biệt thực sự nằm ở cách tổ chức của bạn tái cấu trúc cách thức hợp tác xung quanh điều này.

Vì vậy, tôi giả định rằng chúng ta đều đang đi theo hướng của nhà máy tối. Những gì tôi quan sát được tại Tessl và các công ty khác là khi con người bắt đầu áp dụng những công nghệ này, động lực hợp tác sẽ thay đổi hoàn toàn. Nếu bạn quen thuộc với định luật Conway, bạn sẽ biết có một mối quan hệ tương tác hình thành giữa cách tổ chức và công cụ — cách bạn tổ chức con người sẽ tạo ra hệ thống tương ứng. Nhưng hôm nay, tôi không muốn nói về cách làm cho Agent của bạn tốt hơn, mà tôi muốn nói về cách điều này thay đổi động lực nhóm, nền tảng và toàn bộ tổ chức của bạn.

Tôi đoán phần lớn mọi người trong phòng này đều làm việc trong một đội nhóm, chứ không phải làm việc một mình; sự hợp tác trong đội nhóm hoàn toàn khác biệt với việc một người ngồi gõ mã riêng lẻ với Claude Code.

Hiện nay, mọi người đều thích nói một câu: các nhà phát triển cuối cùng sẽ trở thành một nhạc trưởng, một người sắp xếp các Agent. Tôi cho rằng cách nói này không sai, đây đúng là con đường chúng ta đang đi. Chúng ta ngày càng giống những người quản lý Agent, phải xử lý mối quan hệ với các Agent.

Nhưng vấn đề là, tôi nghe nhiều nhà phát triển nói riêng: Chúng tôi không vào ngành này để làm những việc như thế này, chúng tôi chưa bao giờ nghĩ mình sẽ phải dành rất nhiều thời gian để tối ưu Prompt, viết SPEC tốt hơn. Chúng tôi là kỹ sư, chúng tôi làm về công nghệ, điều này tạo ra sự xung đột về danh tính, khiến chúng tôi liên tục tự hỏi: Liệu đây có thực sự là vai trò tôi muốn không?

Sau đó, một khái niệm gọi là “Context engineering” xuất hiện, giúp các nhà phát triển có chút lý do để an ủi bản thân. Nó nói rằng, đây không chỉ đơn thuần là gọi Prompt, mà bạn còn phải kiểm thử, đánh giá, phân phối và tối ưu Prompt, do đó thực sự mang một chút hương vị kỹ thuật. Nhưng nói thật, nhiều nhà phát triển vẫn cảm thấy việc chỉ làm việc với Prompt và SPEC rất trống rỗng, cảm thấy mình đã từ một kỹ sư trở thành “quản lý prompt”.

Nhưng trong thực tế, tôi đã quan sát thấy một bước ngoặt rất thú vị: khi chúng tôi bắt đầu triển khai Harness, vòng lặp, và thậm chí hướng toàn bộ tổ chức đến mức độ tự trị cao hơn, một con đường kỹ thuật hoàn toàn mới đã mở ra. Đột nhiên, các nhà phát triển cần phải xây dựng công cụ cho Agent — điều này lập tức thổi bùng lại niềm đam mê ở một nhóm người. Những nhà phát triển trước đây từng nghĩ “Đây không phải việc của tôi” bỗng nhiên trở nên hăng hái. Họ nói: Đúng vậy, chúng ta có thể làm điều này! Chúng ta nắm giữ kiến thức này! Chúng ta có thể dùng lập trình để giúp hệ thống này trở nên tốt hơn. Vì vậy, thật thú vị khi khi chúng ta liên tục nói về “trừu tượng, trừu tượng, và lại trừu tượng”, thì cảm giác “nghệ thuật thủ công” lại bất ngờ tái xuất hiện ở một vị trí khác, tạo ra không gian mới cho những công việc kỹ thuật sâu sắc hơn.

Nhiều người thường hỏi tôi: Làm thế nào để xử lý những người nghi ngờ? Câu trả lời của tôi luôn là: Những người này thực ra là tài sản của bạn. Vì họ sở hữu rất nhiều kiến thức ẩn và khả năng phán đoán, bạn cần đưa những thứ này vào Agent. Bạn có thể nói với họ: “Hãy đưa ra tất cả kiến thức và sự khắt khe của bạn,” điều này sẽ giúp Agent và Harness trở nên tốt hơn. Nếu bạn gặp những người phản kháng,每天都 than phiền rằng “mã do hệ thống tạo ra chất lượng quá kém,” hãy coi họ như nhiên liệu, biến sự tức giận và nghi ngờ đó thành động lực cải tiến hệ thống.

Bây giờ, tôi muốn đưa ra một đề xuất cho các nhà phát triển của công ty: hãy thực hiện một sự thay đổi lớn trong tư duy—đừng sửa mã do Agent tạo ra, hãy sửa hệ thống tạo ra mã đó. Giống như vài năm trước, có người từng nói: “Đừng tạo ra cái đó, hãy tạo ra cái có thể tạo ra cái đó.” Hiện tại, chúng ta đang ở cấp độ trừu tượng này, thông qua Context, Harness và vòng lặp để xây dựng “cái có thể tạo ra cái gì đó.” Những người vẫn còn dừng lại ở giai đoạn “Human in the Loop,” tự động hoàn thành, hay điều chỉnh Prompt cần suy nghĩ cách nâng mình lên tư duy hệ thống.

Điều chúng ta thực sự cần làm là sử dụng các thực hành kỹ thuật tốt để tối thiểu hóa số lần can thiệp của con người. Ban đầu, mọi người đều cảm thấy “vibe coding” rất đã, chỉ cần đưa một prompt, nhận kết quả, rồi cứ thế tiếp tục chạy. Nhưng giờ đây, chúng ta ngày càng rõ ràng rằng, chúng ta không chỉ đang ra lệnh cho Agent thông qua prompt, mà thực chất đang nói: “Hãy viết code kèm theo bài kiểm tra, hãy cập nhật tài liệu, hãy tuân thủ các quy chuẩn mã nguồn.” Những điều trước đây chúng ta từng nói với các kỹ sư giỏi, giờ đây đều được áp dụng nguyên vẹn cho Agent. Nếu trong đội của bạn vẫn còn ai đó dùng cách “YOLO (chạy đã rồi tính sau)” để làm vibe coding theo kiểu phi truyền thống, bạn nên lập tức ngăn chặn. Các thực hành kỹ thuật không chỉ cực kỳ quan trọng đối với việc duy trì hệ thống của bạn, mà còn quan trọng không kém đối với việc Agent tự cải thiện liên tục.

Tôi bắt đầu thấy một nghi thức mới xuất hiện trong một số nhóm đi đầu, họ vẫn tổ chức các cuộc họp lập kế hoạch và tổng kết, nhưng nội dung thảo luận đã hoàn toàn thay đổi. Thay vì nói “mã nguồn gặp vấn đề gì”, họ hỏi “hệ thống gặp vấn đề gì?”

Trong cuộc họp lập kế hoạch, tôi cũng thấy một sự phân chia thú vị. Những nhiệm vụ được định nghĩa rõ ràng và phạm vi xác định cụ thể có thể trực tiếp giao cho Agent thực hiện, vì Harness ngày càng tốt hơn và có thể xử lý hiệu quả những nhiệm vụ rõ ràng này. Trong khi đó, những việc có ranh giới mơ hồ, cần thảo luận vẫn được giữ lại cho con người. Do đó, trong cuộc họp lập kế hoạch đã hình thành một sự phân công tự nhiên: những thẻ này đi theo luồng Agent, những thẻ kia chúng ta sẽ cùng trao đổi.

Các nhà phát triển thường trải qua một chu kỳ học tập: đầu tiên là học Prompt, sau đó là SPEC tốt hơn, tiếp theo là Context, Harness, vòng lặp, và cả ngành công nghiệp này cũng đang tiến bộ qua chu kỳ này. Nhưng điều mà đội trưởng nhóm có thể làm là thiết lập nhịp độ và giới hạn cho quá trình này, ví dụ như nói với họ: “Đừng còn điều chỉnh Prompt nữa, hãy biến Context thành có thể tái sử dụng.” “Tốt, bước này đã xong, chúng ta chuyển sang bước tiếp theo.” Giá trị của đội trưởng nhóm nằm ở việc thiết lập nhịp độ như vậy; nếu bạn chỉ đơn giản nói “tự tìm hiểu lấy” thì sẽ không hiệu quả.

Còn có một hiệu ứng dây chuyền: một khi năng suất của đội bạn bắt đầu tăng vọt, những người ở phía sau, ví dụ như đội GTM (Go to Market), sẽ không theo kịp, thậm chí cả người dùng cũng không theo kịp. Vì vậy, bạn cần sử dụng tự động hóa để hỗ trợ họ; khung làm việc của bạn không thể dừng lại ở bước mã hóa, mà phải mở rộng đến phía họ. Nguyên lý tương tự cũng áp dụng cho đầu vào yêu cầu ở phía trước: nếu yêu cầu không đến đủ nhanh, đội sẽ bị đình trệ, những khâu này cũng cần được tích hợp vào luồng làm việc mới này.

Hiện nay trên thị trường có rất nhiều chỉ số, như chi phí Token, v.v. Nhưng tôi ngày càng tin tưởng vào hai chỉ số thực sự đo lường năng suất. Thứ nhất: bạn đếm xem để cho Agent thực hiện đúng một việc, bạn cần bao nhiêu lần can thiệp thủ công? Con số này nên liên tục giảm xuống. Hệ thống Harness của bạn càng tốt, ngữ cảnh càng tốt, hướng dẫn càng rõ ràng, con số này càng thấp. Chỉ số thứ hai là khi bạn chuyển từ làm việc đơn lẻ sang hệ thống chia sẻ, sẽ có hiệu ứng nhân lên. Bạn sửa một thứ ở một nơi, mọi người đều được hưởng lợi. Điều này không có nghĩa là một người trở nên hiệu quả gấp mười lần, mà là một lần tối ưu hóa hệ thống Agent sẽ tạo ra hiệu ứng nhân lên cho tất cả mọi người.

Bạn có thể bắt đầu trong một kho lưu trữ hoặc trong một nhóm nhỏ, chia sẻ Context và cùng nhau cải tiến Harness. Nhưng điều bạn thực sự muốn làm là mở rộng hiệu ứng này đến toàn bộ tổ chức. Lúc này, chúng ta buộc phải nói đến đội ngũ nền tảng.

Đội ngũ nền tảng là một tổ chức kiểu chia sẻ điển hình, hiện tại họ có thể đang tập trung vào cơ sở hạ tầng, dịch vụ đám mây, cổng MCP v.v., chưa quá quan tâm đến lĩnh vực Agent. Nhưng đang có rất nhiều thứ mới nổi lên và cần họ tiếp nhận, ví dụ như trung tâm đăng ký kỹ năng (không thể để mỗi người tự phát minh ra một bộ kỹ năng riêng ở góc của mình), hệ thống đánh giá Context (Context này thực sự có hữu ích không? Có thể định lượng được không?), và các cơ chế bảo vệ cũng như quản lý danh tính dành riêng cho agent lập trình (Agent nộp mã dưới danh tính ai? Giới hạn quyền hạn nằm ở đâu?). Do đó, đội ngũ nền tảng cần một người hỗ trợ, giúp họ phát triển lên vai trò trung tâm mới này.

Việc này rất khó, bạn cần có một chủ sở hữu rõ ràng để thúc đẩy. Nhưng người đó nên là ai? Đội ngũ nền tảng hay đội ngũ trải nghiệm nhà phát triển? Đội ngũ trước thường không can thiệp vào các vấn đề cấp phát triển, trong khi đội ngũ sau lại ít khi tiếp cận hạ tầng, do đó cần một sự kết hợp nào đó, nhưng sự kết hợp này sẽ không tự nhiên xảy ra. Bạn cần đảm bảo có một người chịu trách nhiệm thúc đẩy công việc tập trung này, nếu không, đội ngũ của bạn sẽ chỉ dừng lại ở việc tự mình xoay xở trong phạm vi hẹp của mình và sẽ không bao giờ có “Paved Road”.

Tại sao mỗi đội chúng ta lại phải tự phát triển một cách kết nối hệ thống xác thực riêng? Đây là thành phần chia sẻ, nên được đưa vào trung tâm đăng ký. Tại sao mỗi người lại phải tự xây dựng Harness của riêng mình? Nếu tất cả chúng ta đều dùng cùng một linter và cùng bộ công cụ quét bảo mật, thì đó chính là thành phần có thể tái sử dụng. Tôi cho rằng điều này sẽ giống như việc xây dựng hạ tầng điện toán đám mây ngày xưa, dần dần tập trung vào trung tâm nền tảng.

Nhưng vấn đề là, nếu bất kỳ ai cũng có thể tùy tiện đưa thứ gì đó vào kho trung tâm này, nó sẽ nhanh chóng phát triển mất kiểm soát (becomes a sprawl). Ví dụ, một skill được đưa lên, thì ai sẽ duy trì nó? Một người khác lại fork một skill tương tự, vậy thì tôi nên chọn cái nào? Vì vậy, phải có người rõ ràng sở hữu một lĩnh vực cụ thể, người đó phải đảm bảo rằng thứ đó có thể kiểm thử được, mang tính mô-đun, và người khác có thể mở rộng phần quét an toàn trong Context hoặc Harness dựa trên đó. Bạn phải thực hiện theo cách tập trung hóa, chứ không phải truyền tay tùy tiện trong tổ chức.

Việc xây dựng sự đồng thuận rất khó. Nó không nổi tiếng như cuộc tranh cãi giữa tabs và spaces, nhưng đôi khi cảm giác cũng tương tự. Nếu bạn để hai nhóm phát triển đạt được sự đồng thuận về cách thức làm việc, bạn sẽ cần rất nhiều giao tiếp và hòa giải. Cuối cùng, bạn rất có thể sẽ không chỉ có một con đường trải nhựa, mà là ba hoặc bốn con đường, để họ có thể chọn. Nếu họ muốn tự tạo ra một hệ thống riêng, họ cũng có thể làm, nhưng đó sẽ là ngân sách của họ. Con đường được duy trì tập trung mới là “con đường dễ dàng”, được thiết kế để thu hút mọi người đi theo.

Nếu mọi người sử dụng bừa bãi những khả năng chia sẻ này, bạn phải khiến họ nhìn thấy chi phí. Chỉ cần bạn làm cho chi phí trở nên trực quan, họ tự nhiên sẽ muốn tối ưu hóa. Đó là trách nhiệm của đội ngũ nền tảng, đảm bảo chi phí minh bạch: Đã chi bao nhiêu? Đã hỗ trợ được bao nhiêu? Nếu tôi có thể giảm số lần lặp lại của Agent, đó chính là tối ưu hóa. Nhưng nếu tôi không nhìn thấy chỉ số này, mà chỉ thấy kết quả cuối cùng, thì tôi sẽ không thể bắt tay vào cải tiến—sự trực quan hóa là tiền đề cho mọi tối ưu hóa.

Vì vậy, luận điểm cốt lõi của tôi là: chúng ta cần từ những nhà phát triển làm việc đơn lẻ, tiến đến mức độ đội nhóm với ngữ cảnh chung và thành phần chung, cuối cùng đạt đến hệ thống “trò chơi nhiều người” trong toàn bộ tổ chức. Hiệu ứng nhân lên sẽ bùng nổ ở đó, vì bạn có một vòng xoay tăng tốc, nơi các cải tiến có thể lan tỏa đồng thời theo nhiều hướng.

Ở cấp cao hơn nữa, bộ phận VP Kỹ thuật suy nghĩ về vấn đề này như thế nào? Tôi gần như có thể dự đoán được câu chuyện sẽ xảy ra trong tổ chức của bạn: một cuộc hackathon hoặc buổi chia sẻ trong giờ ăn trưa, chia sẻ các trường hợp thành công, tạo một kênh Slack chung, triển khai chương trình champions. Đây đều là những phương pháp chuyển đổi phổ biến. Trước đây, quá trình chuyển đổi Agile đã làm như vậy, DevOps cũng đã làm như vậy, chẳng có gì mới mẻ cả.

Mặt khác, chúng ta cũng biết rằng chiến lược “cấp giấy phép, tổ chức đào tạo, để mọi người tự do phát huy, để ngàn hoa nở rộ” chưa bao giờ thành công. Kết quả của ngàn hoa thường là ngàn cỏ dại, hoa nở rộ nhưng không có bông nào kết trái. Vì vậy, tôi đề xuất rằng ở cấp tổ chức cần trao quyền rõ ràng để các Team Lead và đội ngũ nền tảng thực hiện việc này. Nó không thể được hoàn thành bởi một cá nhân siêu việt duy nhất, mà cần có người được ủy quyền chính thức để thúc đẩy.

Tìm người giúp cũng là một việc khiến đau đầu. Các chức danh hiện nay thật hỗn loạn: kỹ sư sản phẩm AI, kỹ sư triển khai phía trước, kỹ sư agentic, kỹ sư AI… Những từ này thực ra không mang nhiều ý nghĩa thực chất. Bạn không thể dựa vào chức danh để đánh giá mức độ chín chắn của một người, vì toàn bộ ngành này vẫn chưa chín muồi. Tuy nhiên, khi bạn đăng tin tuyển dụng, những từ này thực sự mang lại một số tín hiệu, thu hút những người có ý định ứng tuyển, nhưng bản thân chúng không đảm bảo rằng ứng viên đó thực sự có kỹ năng tương ứng. Tôi còn nghe những câu chuyện còn kỳ lạ hơn: có ứng viên trong buổi phỏng vấn dùng AI để truyền đáp án trực tiếp vào tai, mỗi khi nhà tuyển dụng đặt câu hỏi, lời khuyên từ AI lại vang lên qua AirPods.

Vì vậy, tôi ngày càng nghe thấy nhiều công ty áp dụng cách phỏng vấn này. Bước đầu tiên, đưa ra một bài tập để họ thoải mái sử dụng AI để giải quyết, hãy dùng hết khả năng của AI. Nếu AI có thể giúp họ hoàn thành, điều đó chính là minh chứng cho khả năng tận dụng AI của họ. Bước thứ hai, yêu cầu họ trình bày phương án của mình và giải thích: “Tại sao bạn chọn phương án này? Bạn đã xác minh nó đúng như thế nào?” – lúc này bạn đang đánh giá khả năng kiểm thử và năng lực phán đoán kỹ thuật. Giai đoạn đầu kiểm tra khả năng sử dụng AI, giai đoạn sau kiểm tra nền tảng kỹ thuật. Thứ ba, còn phải quan sát cách họ hợp tác, có sẵn sàng chia sẻ hay không, thuộc kiểu mở hay kiểu làm một mình. Có người kỹ thuật rất giỏi nhưng muốn giữ mọi thứ trong tay, những người như vậy trong thời đại Agent lại trở thành điểm nghẽn.

Người bạn đang tìm kiếm là người có thể tận dụng AI một cách tối ưu, có nền tảng kỹ thuật vững chắc và sẵn sàng chia sẻ, hợp tác. Ba yếu tố này kết hợp mới là điều bạn cần. Không phải là người chỉ từng học ML hoặc AI, cũng không phải là chuyên gia giải mã, mà là một sự pha trộn độc đáo. Bạn có thể không tìm thấy ai đáp ứng đầy đủ cả ba điểm, nhưng điều đó không sao—ví dụ, một ứng viên có thể rất xuất sắc ở một khía cạnh nhưng cần hướng dẫn ở khía cạnh khác. Đồng thời, đừng gộp những kỹ năng này lại và dán nhãn “sơ cấp” hay “nâng cao”, vì chúng là những chiều kỹ năng khác nhau: một người có thể có khả năng tận dụng AI ở mức “nâng cao”, nhưng lại ở mức “sơ cấp” về tinh thần hợp tác.

Bộ phận Kỹ thuật của VP vẫn phải báo cáo kết quả lên trên. Chúng ta đã mua rất nhiều giấy phép, vậy có thể chứng minh được đầu tư và lợi nhuận không? Việc giao hàng có nhanh hơn không? Có thể có cam kết nhưng rất khó chứng minh. Chất lượng có tốt hơn không? Cũng rất khó để khẳng định. Nhưng trở lại hai chỉ số tôi đã nói trước đó, bạn có thể hiển thị số lần can thiệp đã giảm bao nhiêu, cải thiện bao nhiêu, và tỷ lệ tái sử dụng đã tăng bao nhiêu. Điều này dễ dàng và thuyết phục hơn nhiều so với việc so sánh “năng suất mã hóa có và không có Agent”.

Vì vậy, khi có người phàn nàn rằng Agent tiêu quá nhiều tiền và muốn giới hạn hạn mức, phản ứng bản năng của bạn không nên là “chúng ta cắt hết mọi chi phí”, mà nên là “chúng ta làm thế nào để tối ưu chi phí”. Cách đơn giản nhất là chọn đúng mô hình—không phải mọi tác vụ đều cần mô hình mạnh nhất, một số tác vụ chỉ cần mô hình rẻ hơn là đủ. Hãy giáo dục các nhà phát triển về việc sử dụng mô hình nào trong hoàn cảnh nào, và hơn nữa, cung cấp cho họ Context và Harness tốt hơn, điều này sẽ giúp Agent tránh được những con đường sai lầm và giảm chi phí đáng kể.

Còn một chủ đề khác về quy mô đội ngũ. Một người đa năng làm hết mọi việc là giấc mơ tuyệt đối. Nhưng nếu bạn tính kỹ: người này thường cần bổ sung các kỹ năng bổ trợ, chẳng hạn như sản phẩm hoặc thiết kế. Sau đó, bạn còn phải tính đến nhân sự dự phòng (backup), nếu có người đi nghỉ thì sao? Như vậy lại quay về ba người. Rồi có thể còn cần người theo dõi sản xuất và phiếu công việc; nếu bạn cực kỳ hiệu quả, có thể là cùng một nhóm người kiêm nhiệm. Nhưng một khi bạn phải sửa lỗi, tốc độ phát triển tính năng sẽ giảm xuống. Cuối cùng còn có nhân viên mới, bạn cần dẫn dắt họ để họ hiểu được “thế nào là tốt”. Vì vậy, tôi vẫn cho rằng, trong một tổ chức, chúng ta không thể thực sự khiến mỗi đội ngũ chỉ gồm một hoặc hai người.

Cuối cùng, nhà máy tối có thể không hoàn toàn tối, mà vẫn giữ lại một chút ánh sáng mờ (dim factory), điều này có nghĩa là bạn phải quyết định mức độ rủi ro nào cho từng tính năng, vì không phải tất cả các tính năng đều phù hợp với sự tự trị hoàn toàn. Bạn có thể đầu tư nhiều hơn vào việc kiểm toán, chẳng hạn như truy xuất nguồn gốc: ai đã sửa mã? Là con người hay Agent? Thêm bộ kiểm tra để xác minh mã có thực sự hữu ích hay không, và đầu tư vào khả năng nhận thức tình huống khi quy trình tự động thất bại. Từ việc quản lý vi mô hoàn toàn (mỗi dòng mã đều phải được con người xem xét) đến việc phê duyệt hoàn toàn tự chủ (giả định rằng tất cả đầu ra của Agent đều đúng), đây là một dải phổ liên tục. Điều bạn cần làm là lựa chọn mức độ tự động hóa khác nhau cho các loại thay đổi khác nhau dựa trên mức độ rủi ro.

Còn tôi cho rằng lợi thế cạnh tranh của bạn nằm ở việc nắm bắt những kiến thức đã được tích lũy, những ngữ cảnh nghiệp vụ mà bạn đang đưa vào skill, context, thậm chí là các ràng buộc của Harness. Đối với tôi, điều này thực sự đã biến giao tiếp liên tục thành học hỏi liên tục. Hãy tự hỏi mình: Chúng ta có thể nhanh chóng thay thế một thứ mới vào hệ thống và loại bỏ một thứ cũ đi như thế nào? Đó chính là khả năng phản ứng của bạn. Nếu bạn có thể liên tục cải thiện khả năng này, then chốt vấn đề sẽ không còn là “Tôi cần làm cho toàn bộ hệ thống đáng tin cậy hơn”, mà là “Tôi có thể duy trì độ tin cậy của hệ thống trong khi thay đổi ngày càng nhiều bộ phận của nó không?”

Nếu chỉ mang theo một câu, thì đó nên là: Người chiến thắng sẽ không phải là siêu người chơi đơn độc, mà là những người biết cách cải tiến tổ chức trên nhiều cấp độ.