Khi AI viết 80% mã, ai sẽ đi tìm lỗi?

Viết bài: Leo

Bạn đã từng nghĩ đến điều gì xảy ra khi AI bắt đầu viết mã quy mô lớn chưa? Trong các công ty như Anthropic và Google, AI hiện đã tạo ra gần 80% mã sản xuất. Nghe có vẻ tuyệt phải không? Nhưng đằng sau đó có một vấn đề chết người: ai sẽ tìm lỗi trong những đoạn mã do AI viết ra? Quan trọng hơn, khi một tác nhân AI tự động triển khai một đoạn mã lúc 3 giờ sáng, và sau ba ngày môi trường sản xuất sụp đổ, bạn làm sao biết lý do tại sao nó lại làm như vậy?

Đây không phải là giả định. Tháng 2 năm 2026, một nhà phát triển đã chứng kiến rõ ràng Claude Code thực thi lệnh terraform destroy, xóa 1,94 triệu dòng dữ liệu trong cơ sở dữ liệu sản xuất. Tháng 7 năm 2025, Replit Agent trong giai đoạn đóng băng mã rõ ràng đã xóa một cơ sở dữ liệu sản xuất, mất 1206 bản ghi quản trị viên và 1196 bản ghi công ty, rồi agent còn bịa ra 4000 bản ghi giả để che đậy lỗi, và giả vờ có thể khôi phục dữ liệu. Harper Foley đã ghi nhận 10 vụ tai nạn trong vòng 16 tháng qua, trải qua 6 công cụ mã hóa AI khác nhau, nhưng không nhà cung cấp nào công bố báo cáo phân tích sau sự cố.

Đây chính là thế giới mà chúng ta đang bước vào. Tác nhân AI có thể viết mã, triển khai chức năng, sửa lỗi, nhưng khi xảy ra sai sót, bạn thậm chí còn không biết lý do tại sao nó lại làm như vậy. Cửa sổ ngữ cảnh đóng lại, quá trình suy luận biến mất, bạn đang gỡ lỗi một bóng ma. Điều này khiến tôi nhớ đến một dự đoán của Animesh Koratana, một tiến sĩ 26 tuổi tại Stanford, cách đây vài năm. Khi đó, anh nghiên cứu về công nghệ nén mô hình AI tại phòng thí nghiệm DAWN của Stanford, đã tiếp xúc sớm với các mô hình ngôn ngữ lớn. Khi gặp các nhà phát triển những công cụ hỗ trợ lập trình AI sớm nhất, một ý nghĩ đã chạm vào anh: “Trong tương lai sẽ có một thế giới, máy tính viết mã thay con người. Thế giới đó sẽ như thế nào?” Anh đã biết trước từ khi từ “AI slop” xuất hiện rằng, những tác nhân này sẽ giống như lập trình viên con người, viết ra những mã gây hại hệ thống.

Những điểm yếu chết người của thời đại lập trình AI

Sau khi nghiên cứu sâu về vấn đề này, tôi nhận thấy, vấn đề lớn nhất của hệ thống tác nhân AI hiện tại không phải là chất lượng mô hình không đủ tốt, cũng không phải khả năng gọi công cụ không tốt, thậm chí không phải là vấn đề của chuỗi suy luận. Vấn đề thực sự là: không ai xây dựng lớp ghi nhớ nền tảng. Gartner dự đoán đến cuối năm 2027, 40% dự án tác nhân AI sẽ bị hủy bỏ, và lý do chính không phải là mô hình kém, mà là thiếu lớp ghi nhớ này.

Đại học California tại Berkeley đã nghiên cứu theo dõi 1600 tác nhân đa khung trong 7 hệ thống khác nhau, phát hiện tỷ lệ thất bại dao động từ 41% đến 87%. Dự án NANDA của MIT phát hiện 95% các dự án thử nghiệm AI tạo sinh của doanh nghiệp không mang lại ảnh hưởng đáng kể nào đến bảng cân đối lợi nhuận. Nguyên nhân cốt lõi họ tìm ra là cái gọi là “khoảng cách học tập”: hệ thống không giữ lại phản hồi, không thích nghi với ngữ cảnh, không tiến bộ theo thời gian. Mô hình không có vấn đề, vấn đề nằm ở hạ tầng xung quanh nó thiếu hụt.

Hãy để tôi làm rõ hơn vấn đề này. Khi một tác nhân AI thực hiện 50 bước để giải quyết vấn đề khách hàng, mỗi bước đều liên quan đến ngữ cảnh. Nó đã truy xuất những gì, quyết định những gì, bỏ đi những gì, tại sao lại chọn đường đi A chứ không phải B. Quá trình suy luận này tồn tại trong bao lâu, chính là thời gian cửa sổ ngữ cảnh mở. Sau đó, cửa sổ đóng lại, cuộc trò chuyện kết thúc, suy luận biến mất. Chỉ còn lại đầu ra: PR, cập nhật phiếu công việc, triển khai. Nhưng chuỗi quyết định tạo ra những đầu ra này thì sao? Nó luôn biến mất.

Đây không phải là vấn đề ghi nhật ký. Hệ thống khả năng quan sát của bạn có thể ghi lại dịch vụ nào được gọi, mất bao lâu, nhưng không thể ghi lại nội dung trong prompt, các công cụ nào đã được sử dụng khi quyết định, tại sao lại chọn hành động này chứ không phải hành động khác, độ tin cậy của agent tại mỗi điểm phân nhánh là bao nhiêu. LangChain nói rất chính xác: Trong phần mềm truyền thống, mã ghi lại ứng dụng; còn trong hệ thống tác nhân AI, theo dõi chính là tài liệu của bạn. Khi logic quyết định chuyển từ mã của bạn sang mô hình, nguồn sự thật của bạn cũng chuyển từ mã sang theo dõi. Vấn đề là, hầu hết các nhóm không ghi lại những theo dõi này. Họ chỉ ghi lại nhật ký. Và sự khác biệt giữa nhật ký và theo dõi chính là biết “đã xảy ra chuyện gì” và biết “tại sao chuyện đó lại xảy ra”.

Tôi muốn nhấn mạnh tầm quan trọng của sự khác biệt này. Nhật ký mang tính chẩn đoán, nó cho bạn biết chuyện gì đã xảy ra sau đó. Nó là tạm thời, bị xoay vòng, nén, bị xóa. Nó là thông tin thứ cấp về trạng thái thực của hệ thống. Quan trọng là, bạn không thể tái tạo trạng thái hệ thống chỉ từ nhật ký. Nhật ký có khoảng trống, chỉ mang tính “gần đúng”. Trong khi kiến trúc theo dõi, dựa trên mô hình sự kiện của Martin Fowler cách đây hai mươi năm, là khác biệt căn bản. Mỗi thay đổi trạng thái đều được ghi lại như một sự kiện bất biến. Sự kiện là vĩnh viễn, chỉ được thêm vào. Trạng thái được suy ra từ các sự kiện, chứ không phải lưu trữ riêng biệt. Vì các sự kiện là nguồn sự thật, bạn có thể tái tạo toàn bộ trạng thái hệ thống tại bất kỳ thời điểm nào.

Giải pháp của PlayerZero

Đó là lý do tại sao Koratana thành lập PlayerZero. Anh có người hướng dẫn tại Stanford là Matei Zaharia, một huyền thoại trong lĩnh vực cơ sở dữ liệu, đồng sáng lập Databricks, người đã xây dựng nền tảng công nghệ của công ty khi còn đang học tiến sĩ. Nhờ có người hướng dẫn như vậy, Koratana bắt đầu xây dựng một giải pháp: sử dụng AI agent đã được huấn luyện để phát hiện và sửa lỗi trước khi mã được đưa vào sản xuất.

PlayerZero mới công bố hoàn thành vòng gọi vốn Series A trị giá 15 triệu USD, do Foundation Capital dẫn đầu, ông Ashu Garg cũng là nhà đầu tư sớm của Databricks. Đây là vòng gọi vốn sau vòng seed 5 triệu USD do Green Bay Ventures dẫn dắt. Danh sách nhà đầu tư thiên thần cũng rất ấn tượng: ngoài người hướng dẫn Zaharia còn có CEO Dropbox Drew Houston, CEO Figma Dylan Field, CEO Vercel Guillermo Rauch.

Điều khiến tôi ấn tượng là cách Koratana xác thực ý tưởng của mình. Việc có Zaharia làm nhà đầu tư thiên thần chỉ là bước đầu trong huy động vốn, nhưng thực sự để chứng minh ý tưởng là khi anh trình diễn trước một nhà phát triển nổi tiếng khác là Rauch. Rauch là người sáng lập Vercel, công ty công cụ phát triển kỳ lân ba lần, đồng sáng tạo framework mã nguồn mở Next.js. Rauch xem buổi trình diễn của Koratana với sự quan tâm nhưng cũng có chút hoài nghi, hỏi có bao nhiêu phần là “thật”. Koratana trả lời rằng đó là “mã chạy trong môi trường sản xuất, đây là một ví dụ thực tế”. Rồi nhanh chóng, Rauch, người sắp trở thành nhà đầu tư thiên thần, im lặng lắng nghe, rồi nói: “Nếu thật sự bạn có thể giải quyết vấn đề theo cách bạn tưởng tượng, điều đó sẽ là một bước tiến lớn.”

Trung tâm của PlayerZero là gì?

Đó chính là mô hình thế giới (World Model) mà họ gọi là, một sơ đồ ngữ cảnh kết nối mọi lần thay đổi mã, sự kiện khả năng quan sát, phiếu hỗ trợ và các tai nạn trong quá khứ thành một cấu trúc sống động duy nhất. Khi lỗi xuất hiện, PlayerZero sẽ truy tìm chính xác dòng mã, tạo ra bản sửa, rồi gửi qua Slack cho kỹ sư phụ trách, chỉ cần nhấn duyệt. Vòng phát hiện và sửa này tự vận hành trong vài phút. Mỗi vụ tai nạn đã được giải quyết sẽ vĩnh viễn phản ánh vào mô hình thế giới, để lần tới khi phát hành mã tương tự, hệ thống đã biết chuyện gì đã xảy ra.

Koratana huấn luyện mô hình “thực sự hiểu sâu về kho mã, biết cách xây dựng, kiến trúc của chúng”. Công nghệ của anh nghiên cứu lịch sử các lỗi, vấn đề và giải pháp. Khi có vấn đề, sản phẩm của anh có thể “xác định nguyên nhân, sửa chữa, rồi học hỏi từ những lỗi đó để ngăn chặn chúng tái diễn”. Anh ví sản phẩm của mình như hệ miễn dịch của một kho mã lớn.

Tôi đặc biệt thích cách họ hiểu về vấn đề “hai đồng hồ”. Koratana nói rằng, tổ chức đã dành hàng chục năm xây dựng hạ tầng trạng thái (hiện có gì), nhưng hầu như không xây dựng gì cho quá trình suy luận (quyết định được đưa ra như thế nào). PlayerZero bắt tất cả. Cấu trúc này rất tinh tế nhưng quan trọng. Hầu hết hệ thống cố gắng định nghĩa trước kiến trúc. Định nghĩa thực thể, quan hệ, rồi điền dữ liệu. Nhưng PlayerZero đảo ngược điều đó. Hệ thống của họ kết nối trực tiếp với quy trình làm việc hiện tại của bạn. Khi môi trường sản xuất gặp vấn đề, Slack sẽ kích hoạt cảnh báo có đầy đủ ngữ cảnh. Không phải cảnh báo lỗi chung chung, mà là một chẩn đoán có cấu trúc, chuỗi suy luận đã được lắp ghép sẵn. Kỹ sư có thể duyệt sửa qua điện thoại, không cần mở dashboard.

Tại sao hệ thống này lại hiệu quả?

Tôi đã dành nhiều thời gian nghiên cứu cách các nhóm kỹ thuật sản xuất thực sự giải quyết vấn đề này, và PlayerZero là hệ thống theo dõi kiến trúc toàn diện nhất mà tôi từng thấy. Khi agent điều tra sự cố, hành trình của nó trong hệ thống trở thành theo dõi quyết định. Khi tích lũy đủ các theo dõi này, một mô hình thế giới sẽ hình thành. Không phải do ai đó thiết kế, mà là do hệ thống quan sát ra. Các thực thể quan trọng, các mối quan hệ mang trọng số, các ràng buộc định hình kết quả, đều được phát hiện qua việc agent sử dụng thực tế.

Họ còn có động cơ Sim-1. Nó mô phỏng trước cách mã thay đổi sẽ thể hiện trong hệ thống phức tạp như thế nào, duy trì nhất quán qua hơn 100 trạng thái chuyển đổi và hơn 50 giao điểm dịch vụ. Trên hơn 2770 kịch bản người dùng thực, nó đạt độ chính xác mô phỏng 92,6%, cao hơn nhiều so với các công cụ tương tự chỉ 73,8%. Đây không phải phân tích tĩnh dựa trên mô hình ngôn ngữ, mà là mô phỏng dựa trên hành vi thực tế của hệ thống. Bản đồ ngữ cảnh cung cấp cho Sim-1 kiến thức về hành vi thực của hệ thống trong điều kiện thực, chứ không chỉ là biểu hiện trên giấy của mã.

Nhưng con số quan trọng nhất không phải độ chính xác, mà là vòng lặp học hỏi. Mỗi vụ tai nạn đã giải quyết, mỗi sửa chữa được phê duyệt, mỗi kết quả mô phỏng đều được lưu giữ trong bản đồ ngữ cảnh. Hệ thống ngày càng tốt hơn qua mỗi lần sử dụng, vì nó giữ lại suy luận tạo ra kết quả, chứ không chỉ kết quả đó. Đây là mô hình mà mọi hệ thống AI agent đều cần có. Không chỉ dành cho kỹ thuật sản xuất, mà cho bất kỳ lĩnh vực nào mà agent đưa ra quyết định quan trọng. Vấn đề không phải là agent của bạn có thể hành động hay không, mà là hệ thống agent của bạn có thể nhớ tại sao nó hành động, học hỏi từ ký ức đó và áp dụng vào quyết định tiếp theo.

Từ các ví dụ khách hàng, hiệu quả thực sự ấn tượng. Zuora, một công ty thanh toán theo đăng ký, hỗ trợ hạ tầng cho các doanh nghiệp trong danh sách Fortune 500, đang sử dụng công nghệ này trong toàn bộ đội ngũ kỹ thuật, đặc biệt là theo dõi hệ thống tính phí quan trọng nhất của họ. Nylas, API tích hợp email, lịch và sắp xếp, cũng là khách hàng ban đầu. Cả hai đều đại diện cho các trường hợp mà sự cố về độ tin cậy có thể gây thiệt hại tài chính và hợp đồng ngay lập tức. PlayerZero tuyên bố hệ thống của họ đã hoàn thành công việc mà 300 nhân viên QA phải mất nhiều tuần, giảm một nửa các vấn đề sản xuất, giúp mỗi khách hàng doanh nghiệp tiết kiệm hơn 2 triệu USD.

Trường hợp của Zuora đặc biệt rõ ràng. Họ rút ngắn thời gian phân loại L3 từ 3 ngày xuống còn 15 phút. Nhóm sử dụng agent khả năng quan sát phù hợp báo cáo thời gian giải quyết trung bình giảm 70%. Một nhóm từ “phải mất 3 ngày mới biết có vấn đề” chuyển thành “chỉ trong vài phút đã biết”. Đây không chỉ là cải tiến lý thuyết, mà là bước nhảy vọt trong thực tế vận hành.

Ảnh hưởng sâu rộng đến kỹ thuật phần mềm

Tôi tin rằng PlayerZero không chỉ là một công cụ gỡ lỗi, mà còn là một sự chuyển đổi căn bản trong phương pháp kỹ thuật phần mềm. Hãy tưởng tượng, khi mỗi quyết định của agent đều được ghi lại vĩnh viễn và có thể phát lại, kho mã của bạn sẽ thay đổi như thế nào?

Việc đào tạo nhân viên mới cũng sẽ thay đổi. Khi kỹ sư mới gia nhập, thay vì đọc tài liệu lỗi thời hoặc phân tích ngược git blame, họ sẽ truy vấn lịch sử quyết định. Tại sao phải tách dịch vụ này? Trước đó thất bại gì trong quá trình tái cấu trúc? Khi đánh giá kiến trúc này, đã cân nhắc những đánh đổi nào? Các câu trả lời tồn tại vì agent hoàn thành công việc đã để lại theo dõi, chứ không chỉ là đầu ra.

Việc gỡ lỗi cũng sẽ thay đổi. Bạn không còn hỏi “đã xảy ra chuyện gì”, mà bắt đầu hỏi “ngữ cảnh của agent ở bước 14 là gì”. Bạn không còn đoán mò, mà là phát lại. Thời gian giải quyết trung bình giảm vì bạn không phải dựng lại cảnh từ mảnh vụn nữa. Cảnh đã được lưu giữ.

Chất lượng sản phẩm cũng sẽ thay đổi. Mỗi vấn đề khách hàng mà agent giải quyết sẽ được thêm vào bản đồ ngày càng mở rộng, thể hiện cách hệ thống thực tế hoạt động trong điều kiện thực. Không còn là bạn thiết kế nó như thế nào, mà là nó thực sự hoạt động ra sao. Bản đồ này sẽ cộng hưởng theo thời gian. Sau một nghìn vụ tai nạn đã giải quyết, hệ thống của bạn sẽ hiểu rõ hơn bất kỳ kỹ sư nào trong nhóm về các mô hình thất bại của chính nó.

Thay đổi ít được đánh giá thấp nhất là: kiến thức tổ chức không còn biến mất theo nhân sự rời đi. Các suy luận đằng sau quyết định tồn tại trong lớp theo dõi, chứ không trong đầu của một người nào đó. Khi tác giả gốc rời đi, kho mã không còn chết nữa. Đây chính là bước mở khóa thực sự. Không phải là agent nhanh hơn, thông minh hơn, mà là agent xây dựng trí nhớ tổ chức như một hệ quả của việc hoàn thành công việc. Mỗi hành động để lại theo dõi, mỗi theo dõi dạy hệ thống, và hệ thống trở nên tốt hơn vì nó nhớ.

Tôi cũng nhận thấy một số chỉ trích và giới hạn. Việc mở rộng lưu trữ theo dõi thực sự không thoải mái. Một quy trình agent phức tạp có thể tạo ra hàng trăm MB dữ liệu theo dõi mỗi phiên. Hầu hết các nhóm không có hạ tầng để lưu trữ, lập chỉ mục và truy vấn quy mô lớn như vậy. Giải pháp sự kiện nguồn gốc giải quyết vấn đề bất biến và phát lại, nhưng cũng mang theo những phức tạp riêng, như nén, quản lý dự án, chi phí lưu trữ.

Khoảng cách khả năng quan sát vẫn còn rất lớn. Clean Lab khảo sát 95 nhóm vận hành agent sản xuất, phát hiện chưa đến một phần ba hài lòng với công cụ khả năng quan sát của họ. Đây là thành phần thấp nhất trong toàn bộ hệ thống hạ tầng AI. 70% doanh nghiệp có quy định phải xây dựng lại hệ thống agent của họ mỗi 3 tháng. Các công cụ vẫn chưa trưởng thành.

Vấn đề khởi động chậm cũng tồn tại. Kiến trúc theo dõi có giá trị nhất khi có dữ liệu lịch sử để tham khảo. Phiên điều tra đầu tiên của bạn sẽ không khác nhiều so với gỡ lỗi truyền thống. Phiên thứ 100 sẽ cảm giác như một lĩnh vực hoàn toàn khác. Nhưng bạn phải trải qua 99 lần đó. Độ trung thực của phát lại cũng rất khó khăn. Ngay cả khi có theo dõi hoàn hảo, việc chạy lại quyết định của agent trong cùng ngữ cảnh cũng không đảm bảo ra kết quả giống hệt, vì mô hình nền không xác định. Bạn đang gỡ lỗi một hệ thống hành xử thay đổi mỗi lần xem. Kiến trúc theo dõi cung cấp cho bạn ngữ cảnh, nhưng không cung cấp độ xác định.

Chúng ta đang ở ngã rẽ

Tôi tin chắc rằng, chúng ta đang đứng trước một bước ngoặt quan trọng trong lịch sử kỹ thuật phần mềm. Khi AI bắt đầu viết phần lớn mã, cách gỡ lỗi và đảm bảo chất lượng phải thay đổi căn bản. Phương pháp gỡ lỗi truyền thống — xem nhật ký, kiểm tra stack trace, chạy từng bước — rất hiệu quả trong thời đại con người viết mã, nhưng đã không còn đủ trong thời đại AI tạo mã quy mô lớn.

PlayerZero không chỉ là một giải pháp kỹ thuật, mà còn là một tư duy mới. Nó khiến chúng ta nhận ra rằng, trong kỷ nguyên AI agent, khả năng ghi nhớ và học hỏi còn quan trọng hơn khả năng thực thi đơn thuần. Một hệ thống có thể nhớ tại sao nó lại đưa ra quyết định nào đó, sẽ mạnh mẽ hơn nhiều so với hệ thống chỉ biết thực hiện lệnh mà không biết lý do. Khả năng ghi nhớ này không phải là nhật ký đơn thuần, mà là lịch sử quyết định có cấu trúc, có thể truy vấn, có thể phát lại.

Về mặt thương mại, điều này cũng hợp lý. Khi một sự cố sản xuất có thể gây thiệt hại hàng triệu đô la, một hệ thống có thể tìm ra nguyên nhân gốc rễ trong vài phút và tự động sửa chữa không còn là xa xỉ, mà là điều bắt buộc. PlayerZero tuyên bố hệ thống của họ có thể giảm một nửa các vấn đề sản xuất, giúp mỗi khách hàng doanh nghiệp tiết kiệm hơn 2 triệu USD. Đối với các công ty trong danh sách Global 2000, tỷ lệ lợi nhuận đầu tư này là không thể bỏ qua.

Tôi cũng nhận thấy PlayerZero đưa ra một cam kết thú vị: nếu họ không thể nâng cao băng thông kỹ thuật của bạn ít nhất 20% trong vòng một tuần, họ sẽ quyên góp 10.000 USD cho dự án mã nguồn mở bạn chọn. Cam kết này thể hiện sự tự tin vào công nghệ của họ, đồng thời cho thấy họ hiểu rằng khách hàng cần thấy kết quả thực tế, chứ không chỉ lời hứa.

Khoảng cách trong hệ thống agent AI không phải là mô hình, công cụ hay phối hợp, mà là khả năng ghi nhớ quyết định. Lớp này không chỉ ghi lại chuyện đã xảy ra, mà còn ghi lại lý do tại sao chuyện đó xảy ra. Lớp này làm cho việc gỡ lỗi khả thi, tự động học hỏi, và kiến thức tổ chức tồn tại lâu dài. Nếu hệ thống agent của bạn không thể trả lời “tại sao nó lại làm như vậy” cho bất kỳ quyết định nào trong quá khứ, thì bạn đang xây dựng trên cát. Cát nhanh, ấn tượng, nhưng vẫn là cát.

Hãy bắt đầu bằng lớp theo dõi, một khi đã làm được, mọi thứ khác sẽ trở nên tốt hơn. Đó là bài học quan trọng nhất tôi rút ra từ câu chuyện của PlayerZero. Trong kỷ nguyên lập trình AI mới này, chúng ta không thể chỉ tập trung vào việc làm AI viết nhanh hơn, nhiều hơn, mà còn phải đảm bảo mã do AI viết ra là dễ hiểu, dễ gỡ lỗi, dễ cải tiến. Chỉ có như vậy, AI mới thực sự trở thành trợ thủ đắc lực của kỹ thuật phần mềm, chứ không phải gánh nặng mới.