AI code 30 phút, nhưng hệ thống mất 2 tiếng chỉ để… tự kiểm tra nhau

Một thử nghiệm nhỏ trong phát triển phần mềm khiến mình phải xem lại cách phân công công việc, sử dụng AI và cả cách chúng ta xác định thế nào là một kết quả đáng tin cậy.

Một AI viết code. Hai AI khác review. Một hệ thống tiếp tục chạy kiểm thử, phát hiện lỗi, sửa lại rồi kiểm tra thêm lần nữa.

Nghe khá giống một công ty phần mềm thu nhỏ. Khác biệt là tất cả nhân viên đều là AI, không ai cần nghỉ phép, nhưng hóa đơn thì vẫn về đều.

Đó là một phần quy trình mình đang sử dụng khi phát triển phần mềm với AI Coding Agent. Ban đầu, cách tổ chức này có vẻ hợp lý. AI có thể mắc lỗi, nên cần một AI khác kiểm tra độc lập. Với những phần mềm liên quan đến thanh toán, phân quyền và dữ liệu tài chính, việc kiểm tra kỹ càng càng có lý do chính đáng. Nhưng qua vài đợt triển khai, mình nhận thấy một lượng đáng kể thời gian và tài nguyên được dành cho việc đọc lại, đánh giá lại và chạy lại những bài kiểm thử.

Có những giai đoạn code đã hoàn thành, nhưng hệ thống vẫn tiếp tục thực hiện nhiều vòng xác minh để có thể tự tin báo cáo rằng công việc đã đạt yêu cầu.

Mình bắt đầu tự hỏi liệu chúng ta có đang giải quyết đúng vấn đề. Khi chưa hoàn toàn tin tưởng kết quả do AI tạo ra, phản ứng khá tự nhiên là bổ sung thêm người kiểm tra, thêm công cụ, thêm một vòng review. Nhưng cách làm đó có giới hạn về chi phí, và chưa chắc mỗi lớp bổ sung đều đem lại giá trị tương ứng.

Từ một vấn đề rất cụ thể trong phát triển phần mềm, mình muốn tìm hiểu rộng hơn về cách thiết kế việc kiểm chứng khi AI bắt đầu đảm nhận nhiều công việc trước đây do con người trực tiếp thực hiện.

Tốc độ tạo ra kết quả chưa phản ánh toàn bộ năng suất

Khi nói đến hiệu quả của AI, chúng ta thường sử dụng những phép so sánh khá trực quan. Một công việc trước đây mất ba giờ, giờ chỉ cần 30 phút. Một người trước đây viết được hai bài, giờ có thể tạo ra mười bản nháp. Một lập trình viên có thể yêu cầu AI triển khai nhiều chức năng cùng lúc.

Những thay đổi đó có giá trị, nhưng thời gian tạo ra kết quả chưa phải toàn bộ thời gian cần thiết để hoàn thành công việc.

Trong phát triển phần mềm, code còn phải được đọc lại, kiểm thử, tích hợp và đôi khi phải sửa nhiều lần trước khi có thể sử dụng. Một báo cáo kinh doanh cũng cần được đối chiếu dữ liệu, xem xét các giả định và kiểm tra xem kết luận có thực sự trả lời câu hỏi ban đầu hay không. Khi chất lượng đầu ra không ổn định, phần công việc kiểm chứng có thể trở thành một khoản chi phí đáng kể.

Nghiên cứu về năng suất lập trình viên do METR công bố tháng 7/2025 cho thấy một kết quả đáng suy nghĩ. Nhóm nghiên cứu thực hiện thử nghiệm ngẫu nhiên có đối chứng với 16 lập trình viên mã nguồn mở giàu kinh nghiệm, trên tổng cộng 246 nhiệm vụ thuộc những dự án mà họ đã quen thuộc.

Trước khi tham gia, các lập trình viên dự đoán việc sử dụng AI sẽ giúp họ giảm khoảng 24% thời gian hoàn thành. Sau thử nghiệm, họ vẫn ước tính mình đã làm nhanh hơn khoảng 20%. Tuy nhiên, kết quả đo được cho thấy những nhiệm vụ được phép sử dụng AI mất nhiều thời gian hơn khoảng 19% so với khi không sử dụng AI.

Nghiên cứu không kết luận rằng AI làm giảm năng suất lập trình nói chung. Đối tượng khảo sát là những người đã rất quen với codebase, sử dụng các công cụ AI đầu năm 2025 và thực hiện những nhiệm vụ có đặc điểm tương đối cụ thể. Điều mình thấy đáng chú ý là khoảng cách giữa cảm nhận năng suất và thời gian hoàn thành thực tế.

METR · 16 lập trình viên · 246 nhiệm vụ

Cảm nhận năng suất và thời gian đo được

Dự đoán trước thử nghiệm

nhanh hơn 24%

Tự ước tính sau thử nghiệm

nhanh hơn 20%

Thời gian đo thực tế

chậm hơn 19%

Đến tháng 2/2026, METR công bố dữ liệu từ một thử nghiệm tiếp theo với các công cụ AI mới hơn. Kết quả ban đầu gợi ý rằng AI có thể đã cải thiện năng suất trong một số trường hợp, nhưng nhóm nghiên cứu cũng nhận thấy những sai lệch đáng kể về chọn mẫu và cách đo thời gian. Vì vậy, họ chưa thể đưa ra ước lượng đáng tin cậy về mức cải thiện.

Một số lập trình viên đã không còn muốn tham gia những nhiệm vụ bắt buộc làm việc không có AI. Đây là một vấn đề thú vị đối với nghiên cứu thực nghiệm: khi công cụ trở thành một phần trong thói quen làm việc, việc tổ chức một nhóm đối chứng phù hợp cũng trở nên khó khăn hơn.

Mình nghĩ những nghiên cứu như vậy nhắc chúng ta thận trọng với cách đánh giá hiệu quả công việc. Tốc độ tạo đầu ra, cảm giác làm việc nhẹ nhàng hơn và tổng thời gian hoàn thành là những đại lượng khác nhau. Muốn đánh giá một quy trình có thực sự tốt hơn hay không, chúng ta cần tính cả thời gian kiểm chứng, sửa lỗi, phối hợp và những công việc phát sinh.

Đó cũng là điều mình gặp trong hệ thống AI Coding Agent đang xây dựng. Khi tốc độ viết code tăng lên, việc tổ chức kiểm chứng bắt đầu có ảnh hưởng đáng kể đến tổng thời gian triển khai.

Khi một AI kiểm tra một AI khác

Một cách phổ biến để cải thiện chất lượng đầu ra là sử dụng nhiều lượt đánh giá độc lập. AI đầu tiên tạo kết quả, AI thứ hai đọc lại và đưa ra phản hồi, sau đó AI đầu tiên sửa những vấn đề được phát hiện.

Anthropic mô tả cách tổ chức này trong tài liệu Building Effective Agents với tên gọi Evaluator–Optimizer. Theo đó, một model tạo kết quả và một model khác đánh giá, cung cấp phản hồi qua nhiều vòng để cải thiện chất lượng.

Đây là một phương pháp có cơ sở. Trong những công việc như biên tập, dịch thuật hay phát triển phần mềm, một lượt đánh giá độc lập có thể phát hiện những vấn đề mà người thực hiện bỏ sót. Anthropic cũng lưu ý rằng phương pháp này phù hợp khi tiêu chí đánh giá đủ rõ và quá trình cải thiện qua nhiều vòng tạo ra giá trị có thể quan sát được.

Điều kiện thứ hai rất đáng quan tâm.

Nếu mỗi vòng review đều phát hiện vấn đề mới có ý nghĩa, chi phí bổ sung có thể hoàn toàn xứng đáng. Nhưng nếu nhiều reviewer liên tục đọc cùng một phần code, đưa ra những nhận xét tương tự hoặc yêu cầu chạy lại những bài kiểm thử đã có kết quả, chúng ta cần xem xét lợi ích thực tế của từng lượt.

Trong quy trình của mình, có thời điểm model mạnh được sử dụng để triển khai, sau đó hai reviewer cũng thuộc nhóm model mạnh tiếp tục đọc lại code. Hệ thống còn chạy mutation testing, một kỹ thuật cố tình thay đổi code theo hướng sai để xem bộ test có phát hiện được lỗi hay không, và thực hiện thêm những lượt kiểm tra tích hợp.

Các kỹ thuật này đều có giá trị riêng. Tuy nhiên, việc áp dụng chúng đồng loạt ở mọi giai đoạn đã tạo ra khá nhiều công việc lặp lại, nhất là khi một phần kết quả có thể được xác minh trực tiếp bằng công cụ.

Một vấn đề khác nằm ở mối quan hệ giữa người thực hiện và người đánh giá. Trong lập trình, AI implementer thường viết cả code lẫn test. Nếu nó hiểu sai yêu cầu ngay từ đầu, bộ test được viết sau đó có thể phản ánh chính cách hiểu sai ấy. Các bài test đều vượt qua, nhưng hành vi thực tế vẫn không đáp ứng đúng nghiệp vụ.

Đây không phải lỗi riêng của AI. Con người cũng có thể vô tình viết test theo implementation đã xây thay vì theo yêu cầu ban đầu. Khi để AI thực hiện cả hai việc với tốc độ cao, chúng ta cần đặc biệt chú ý đến khả năng sai sót này.

Từ đây, mình muốn thử thay đổi trọng tâm: dành nhiều năng lực hơn cho việc thiết kế tiêu chuẩn kiểm chứng trước khi triển khai, sau đó sử dụng những tiêu chuẩn đó để giảm các vòng đánh giá lặp lại.

Trở lại với một phương pháp đã có từ lâu

Trong phát triển phần mềm, Test-Driven Development (TDD) là một phương pháp khá quen thuộc. Thay vì triển khai chức năng trước rồi mới viết test, lập trình viên xác định hành vi mong muốn thông qua bài kiểm thử, xác nhận bài kiểm thử chưa vượt qua, sau đó viết code để đáp ứng yêu cầu và tiếp tục cải thiện cấu trúc.

Chu trình này thường được gọi là RED – GREEN – REFACTOR.

Martin Fowler có một bài viết giải thích khá rõ về TDD, trong đó ông nhấn mạnh lợi ích thiết kế của việc viết test trước. Người phát triển phải suy nghĩ về cách một chức năng được sử dụng, cách nó giao tiếp với các thành phần khác và những hành vi nào cần được bảo đảm trước khi quyết định cách triển khai bên trong.

Mình thấy đây là một góc nhìn quan trọng. Test không chỉ là công cụ phát hiện lỗi sau khi phần mềm được xây dựng. Việc xác định test còn là một phần của quá trình làm rõ yêu cầu và thiết kế giải pháp.

Tuy vậy, TDD cũng không giải quyết mọi vấn đề. Một bộ test có thể được viết rất cẩn thận nhưng vẫn thiếu những tình huống quan trọng. Khi yêu cầu nghiệp vụ sai hoặc chưa đầy đủ, việc triển khai vượt qua toàn bộ test cũng chưa đủ để chứng minh sản phẩm đáp ứng đúng nhu cầu thực tế.

Chính vì thế, nếu áp dụng tư duy test-first vào hệ thống AI Agent, mình cho rằng phần cần đầu tư năng lực suy luận lớn nhất là xác định hợp đồng: hành vi nào cần được bảo vệ, điều kiện nào không được vi phạm, trường hợp lỗi nào phải được xử lý và làm sao biết bài test có thực sự phát hiện được vấn đề.

Một khi hợp đồng tương đối rõ, phần triển khai có thể được giao cho một model khác với chi phí thấp hơn. Điều này không bảo đảm model đó sẽ làm đúng, nhưng tạo điều kiện để kiểm tra kết quả dựa trên những tiêu chuẩn độc lập đã xác định trước.

Thử nghiệm Test-First Drive

Trong hệ thống tdrive mình đang phát triển, công việc được tổ chức thành các đợt triển khai, mỗi đợt chia thành nhiều giai đoạn có phạm vi và tiêu chuẩn hoàn thành riêng.

Ở một đợt gần đây, thời gian hoàn thành bốn giai đoạn đầu được ghi nhận lần lượt là 31 phút, 31 phút, 61 phút và 154 phút. Giai đoạn cuối có khoảng 80 phút máy ở trạng thái sleep và chờ tài nguyên, vì vậy không thể xem toàn bộ 154 phút là thời gian xử lý thực tế. Tuy nhiên, ngay cả khi loại trừ phần chờ, giai đoạn này vẫn mất gần gấp đôi giai đoạn chậm nhất trước đó.

Một đợt triển khai trong tdrive

Thời gian hoàn thành bốn giai đoạn đầu

Giai đoạn 1

31 phút

Giai đoạn 2

31 phút

Giai đoạn 3

61 phút

Giai đoạn 4

154 phút

Xử lý ~80 phút sleep, chờ tài nguyên

Nhìn vào nhật ký, mình nhận thấy những lớp kiểm chứng sau implementation đang chiếm khá nhiều công sức. Một số bài test được chạy lại để lấy bằng chứng mới, các reviewer đọc cùng một phần thay đổi, và những bài kiểm tra tích hợp sử dụng Docker phải chờ nhau do giới hạn tài nguyên.

Mình bắt đầu điều chỉnh theo hướng giảm những lượt đánh giá trùng lặp, chỉ thực hiện mutation testing ở những phần có rủi ro cao, đồng thời phân biệt công việc thực sự sửa code liên quan đến tiền hoặc bảo mật với công việc chỉ nhắc đến các khái niệm đó trong mô tả.

Sau đó, mình đưa thêm một thử nghiệm gọi là Test-First Drive vào hai giai đoạn liên quan đến sổ cái kế toán và kiến trúc tích hợp thanh toán.

Quy trình bắt đầu bằng việc một model có năng lực suy luận cao đọc đặc tả và thiết kế các bài kiểm thử. Bộ test phải được đánh giá về khả năng kiểm tra hành vi thay vì chi tiết implementation, có các trường hợp lỗi và phải chứng minh được rằng nó thất bại vì đúng nguyên nhân khi hành vi chưa đáp ứng yêu cầu.

Sau khi được chấp nhận, bộ test được lưu lại bằng Git và khóa ở một commit cụ thể. AI implementer nhận nhiệm vụ viết production code, nhưng không được tự ý sửa test hoặc dữ liệu kiểm thử. Nếu phát hiện hợp đồng có vấn đề, nó phải báo cáo để phần test được xem xét và sửa riêng, kèm lý do.

Bước cuối cùng là kiểm chứng bằng script: so sánh những thay đổi của bộ test với mốc đã khóa, chạy build, kiểm tra tĩnh và chạy test trên toàn bộ codebase. Những phần có rủi ro tài chính còn được bổ sung mutation testing để kiểm tra khả năng phát hiện các lỗi đã xác định.

Một AI vẫn được sử dụng để xem nhanh production diff nhằm phát hiện những thay đổi ngoài phạm vi hoặc code được viết riêng để đối phó với dữ liệu test. Mình không muốn loại bỏ hoàn toàn việc review, mà muốn giảm việc sử dụng model mạnh cho những thao tác có thể kiểm chứng bằng công cụ.

Dồn năng lực vào đâu

Review nhiều lớp và Test-First Drive

Trước: kiểm chứng sau implementation

1. model mạnhViết code và test
2. model mạnh ×2Hai reviewer đọc lại cùng phần thay đổi
3. mọi giai đoạnMutation testing
4. DockerKiểm tra tích hợp chờ nhau, chạy lại để lấy bằng chứng mới

Test-First Drive

1. model mạnhĐọc đặc tả, thiết kế bộ test, chứng minh test thất bại đúng nguyên nhân
2. GitKhoá bộ test ở một commit
3. model tiết kiệmViết production code, không được sửa test
4. scriptSo test với mốc đã khoá, build, kiểm tra tĩnh, chạy toàn bộ test
5. AI xem nhanhProduction diff: thay đổi ngoài phạm vi, code đối phó dữ liệu test

Mutation testing chỉ ở phần có rủi ro tài chính.

Có một trường hợp thực tế khá thú vị trong giai đoạn thiết kế test. Hệ thống sổ cái sử dụng thông tin transaction ID để bảo vệ những bút toán đã được ghi nhận. Sau khi database được khôi phục bằng logical restore, transaction ID mới trong một số trường hợp có thể trùng với giá trị cũ đã lưu trên bản ghi, làm suy yếu cơ chế bảo vệ.

Bộ test được thiết kế để tái hiện đúng tình huống này và xác nhận rằng database phải từ chối thao tác bổ sung bút toán không hợp lệ. Khi chạy trên implementation hiện tại, test thất bại vì lỗi thực sự tồn tại. Điều đó cho thấy bài kiểm thử có khả năng nhận diện đúng vấn đề mà giai đoạn triển khai cần giải quyết.

Đây mới là bằng chứng ban đầu về chất lượng của một bài test, chưa phải bằng chứng cho hiệu quả của toàn bộ quy trình mới.

Thử nghiệm đặt mục tiêu giảm ít nhất 40% thời gian so với giai đoạn đối chứng đã điều chỉnh những yếu tố chờ không liên quan, đồng thời giữ được chất lượng kiểm chứng. Những chỉ số khác gồm số lần phải sửa test, số lượt triển khai trước khi đạt yêu cầu, khả năng phát hiện lỗi bằng mutation testing và những lỗi có thể lọt qua bước kiểm chứng.

Tại thời điểm viết bài, mình chưa có đủ dữ liệu để kết luận Test-First Drive đã đạt mục tiêu. Nếu model triển khai liên tục gặp khó khăn hoặc bộ test phải sửa quá nhiều, điều đó cũng có ý nghĩa: có thể phần thiết kế hợp đồng vẫn chưa đủ rõ, hoặc giả định về khả năng phân chia công việc giữa các model chưa phù hợp.

Điều mình muốn kiểm chứng là liệu việc chuyển nguồn lực từ review code nhiều lần sang thiết kế bộ test có chất lượng cao ngay từ đầu có giúp giảm tổng chi phí hoàn thành mà vẫn bảo vệ được những yêu cầu quan trọng hay không.

Khi nào cách tiếp cận này có ích ngoài lập trình?

Nếu tạm bỏ qua phần kỹ thuật, mình nghĩ câu chuyện có liên quan trực tiếp đến cách chúng ta giao việc cho AI trong nhiều lĩnh vực khác.

Trong phân tích dữ liệu, một vấn đề thường gặp là định nghĩa chỉ số không thống nhất. Chẳng hạn, cùng là tỷ lệ chuyển đổi nhưng mẫu số có thể là lượt truy cập, người dùng duy nhất hoặc số khách hàng tiềm năng, tùy mục đích đo lường. Nếu người giao việc và AI sử dụng hai định nghĩa khác nhau, phép tính vẫn có thể đúng về mặt toán học nhưng kết quả không trả lời đúng câu hỏi kinh doanh.

Vấn đề này vốn đã tồn tại trong công việc phân tích dữ liệu, không phải đợi đến AI mới xuất hiện. Điểm khác biệt là AI có thể tạo ra cả phần tính toán lẫn diễn giải rất nhanh, khiến chúng ta dễ bỏ qua bước thống nhất định nghĩa ban đầu. Vì vậy, thay vì chỉ kiểm tra kết quả cuối cùng, mình muốn đưa việc xác định nguồn dữ liệu, quy tắc tính và điều kiện chấp nhận lên trước khi thực hiện.

Với nội dung cũng tương tự. Một bài viết có thể cần đáp ứng đồng thời yêu cầu về đối tượng đọc, độ chính xác của thông tin, nguồn dẫn, giọng văn và mục tiêu truyền đạt. Một phần trong số đó có thể kiểm tra bằng quy tắc tương đối rõ ràng, như sự hiện diện của nguồn, độ dài hay những thông tin không được phép tự suy diễn. Những phần khác như chất lượng lập luận, mức độ hữu ích và cách diễn đạt vẫn cần biên tập viên đánh giá.

Khi phân biệt được hai nhóm, chúng ta có thể giảm những thao tác kiểm tra mang tính cơ học và dành nhiều sự chú ý hơn cho chất lượng nội dung. Điều kiện là bộ tiêu chí phải phản ánh đúng mục tiêu của bài viết, thay vì chỉ đo những thứ dễ đo.

Trong vận hành, một hệ thống AI phân loại yêu cầu khách hàng cũng cần những định nghĩa tương tự: các nhóm yêu cầu, điều kiện chuyển xử lý, tình huống không đủ thông tin và phạm vi được phép tự động trả lời. Những trường hợp phân loại sai có thể được lưu lại để kiểm tra hệ thống sau mỗi lần thay đổi model hoặc quy trình.

Điểm chung của những ví dụ này là khả năng chuyển kinh nghiệm làm việc thành các tiêu chuẩn có thể sử dụng lại. Một khi tiêu chuẩn được lưu giữ độc lập với kết quả của từng lần thực hiện, chúng ta có thể dùng nó để đánh giá các model khác nhau, so sánh những cách tổ chức công việc khác nhau và theo dõi chất lượng qua thời gian.

Đó cũng là tinh thần của phương pháp evaluation-driven development được đề cập trong tài liệu hướng dẫn của OpenAI. Thay vì chỉ dựa vào cảm giác AI đang hoạt động tốt, hệ thống được đánh giá thông qua các tình huống phản ánh công việc thực tế, với tiêu chí rõ ràng và kết quả được đối chiếu với đánh giá của con người khi cần thiết.

Một bộ tiêu chuẩn như vậy không nhất thiết phải phức tạp. Với một công việc thường xuyên lặp lại, chúng ta có thể bắt đầu bằng việc xác định đầu ra, ghi lại những điều kiện bắt buộc và lưu một vài trường hợp đã từng xảy ra lỗi.

Chẳng hạn, khi giao AI tổng hợp báo cáo hàng tuần, mình sẽ muốn làm rõ nguồn dữ liệu được sử dụng, kỳ so sánh, cách xử lý khi thiếu số liệu và những kết luận nào cần bằng chứng. Sau mỗi lần gặp lỗi, trường hợp đó được bổ sung vào bộ kiểm tra. Dần dần, chúng ta có một cơ sở thực tế để cải thiện quy trình thay vì liên tục điều chỉnh prompt theo cảm giác.

Điều này có thể áp dụng ngay mà không cần xây AI Agent hay viết một dòng code nào.

Chất lượng của bộ kiểm chứng cũng cần được kiểm chứng

Đến đây có một câu hỏi cần giải quyết: nếu chúng ta dành nhiều nguồn lực để thiết kế tiêu chuẩn đánh giá, làm sao biết chính bộ tiêu chuẩn đó đủ tốt?

Trong phần mềm, một bộ test có thể vượt qua tất cả các lần chạy nhưng vẫn bỏ sót những trường hợp quan trọng. Mutation testing là một trong những kỹ thuật giúp đánh giá khả năng phát hiện lỗi của bộ test, bằng cách cố tình đưa những thay đổi sai vào code rồi kiểm tra xem test có nhận ra không.

Trong những công việc khó xác định đúng sai tuyệt đối, chẳng hạn biên tập nội dung hoặc đánh giá chất lượng tư vấn, cách tiếp cận sẽ khác. Chúng ta cần những ví dụ tham chiếu, tiêu chí đánh giá được giải thích rõ và sự đối chiếu với nhận định của người có chuyên môn.

OpenAI lưu ý rằng việc sử dụng model để chấm điểm có thể giúp mở rộng quy mô đánh giá, nhưng chất lượng của model chấm điểm phải được kiểm tra dựa trên dữ liệu và đánh giá của con người. Bản thân AI reviewer cũng có thể chịu ảnh hưởng bởi cách trình bày, độ dài câu trả lời hoặc thứ tự các phương án được đưa ra.

Đây là lý do mình không xem test-first như một phương pháp thay thế toàn bộ công việc review. Việc kiểm chứng chỉ hiệu quả khi chúng ta hiểu rõ phạm vi mà tiêu chuẩn đang bảo vệ, những sai sót nó có khả năng phát hiện và những điều vẫn nằm ngoài khả năng đó.

Có những công việc chưa thể xác định tiêu chuẩn ngay từ đầu. Khi khám phá một công nghệ mới hoặc nghiên cứu một vấn đề chưa có đủ dữ kiện, việc thử nghiệm và thay đổi giả thuyết là một phần tự nhiên của quá trình làm việc. Trong trường hợp này, ép toàn bộ công việc vào một hợp đồng cố định từ đầu có thể khiến chúng ta bỏ qua những phát hiện quan trọng.

Mình nghĩ cách hợp lý hơn là phân biệt công việc khám phá với công việc triển khai. Khi chưa hiểu rõ vấn đề, chúng ta cần tìm hiểu, thử nghiệm và làm rõ những điều chưa biết. Khi đã có đủ cơ sở để mô tả hành vi mong muốn, tiêu chuẩn kiểm chứng mới có thể trở thành công cụ hữu ích cho quá trình thực hiện.

Tương tự, không phải tiêu chí nào cũng nên được giao cho AI chấm điểm. Những phép tính, kiểm tra định dạng hoặc quy tắc nghiệp vụ xác định có thể được xử lý bằng công cụ thông thường. Những việc cần đánh giá theo bối cảnh có thể dùng AI hỗ trợ. Còn các quyết định liên quan đến mục tiêu, giá trị, mức độ chấp nhận rủi ro và chất lượng tổng thể vẫn cần người chịu trách nhiệm.

Ai kiểm chứng phần nào

Công cụ thông thường

Phép tính, kiểm tra định dạng, quy tắc nghiệp vụ xác định

AI hỗ trợ

Những việc cần đánh giá theo bối cảnh

Người chịu trách nhiệm

Mục tiêu, giá trị, mức độ chấp nhận rủi ro, chất lượng tổng thể

Việc phân chia này giúp sử dụng năng lực AI có chọn lọc hơn, đồng thời tránh tình trạng tạo ra những lớp kiểm chứng phức tạp hơn cả công việc cần kiểm chứng.

Điều mình muốn nghiên cứu tiếp

Qua thử nghiệm này, mình bắt đầu quan tâm đến ba vấn đề có liên quan với nhau.

Trước hết là chất lượng của hệ thống đánh giá. Trong một công việc cụ thể, làm sao xác định những tiêu chuẩn thực sự phản ánh chất lượng, thay vì chỉ lựa chọn các chỉ số dễ đo? Và làm sao biết một bộ đánh giá đã đủ tốt để sử dụng làm cơ sở cho việc tự động hóa?

Tiếp theo là cách phân bổ năng lực AI. Nếu một phần công việc đã có đầu vào, đầu ra và tiêu chuẩn hoàn thành rõ ràng, liệu chúng ta có thể giao phần đó cho model tiết kiệm hơn mà không làm giảm chất lượng? Ngược lại, những nhiệm vụ có mức độ bất định cao hoặc sai sót gây hậu quả lớn có thể cần năng lực suy luận và kiểm chứng khác. Mình muốn tìm hiểu liệu có thể phân bổ model dựa trên đặc điểm và rủi ro thực tế của nhiệm vụ, thay vì dựa vào tên công việc hoặc cảm nhận rằng nó khó.

Cuối cùng là khả năng tích lũy tri thức từ quá trình kiểm chứng. Khi một hệ thống phát hiện lỗi, liệu chúng ta chỉ sửa kết quả hiện tại hay có thể biến lỗi đó thành một tình huống kiểm tra cho những lần thực hiện tiếp theo? Nếu làm được điều này một cách có hệ thống, chất lượng công việc có thể được cải thiện dựa trên kinh nghiệm tích lũy, kể cả khi thay đổi công cụ hoặc model.

Đây đều là những câu hỏi cần nghiên cứu và thử nghiệm thêm. Mình chưa có đủ bằng chứng để đưa ra một mô hình hoàn chỉnh, nhưng chúng giúp định hướng rõ hơn những gì cần đo và quan sát trong các đợt triển khai tiếp theo.

Hiểu công việc để làm việc tốt hơn với AI

Một trong những thay đổi lớn khi làm việc với AI là chúng ta bắt đầu tách việc xác định yêu cầu khỏi việc trực tiếp tạo ra kết quả.

Trước đây, nhiều quyết định được đưa ra ngay trong quá trình thực hiện. Người làm vừa tiếp nhận yêu cầu, vừa suy nghĩ, điều chỉnh và tự kiểm tra. Khi AI đảm nhận phần thực hiện, những quyết định vốn nằm trong kinh nghiệm của người làm bắt đầu cần được mô tả rõ hơn.

Điều này giải thích vì sao một nhiệm vụ tưởng chừng đơn giản lại có thể trở nên phức tạp khi giao cho AI. Những điều kiện mà chúng ta vẫn ngầm hiểu trong công việc chưa chắc đã xuất hiện trong yêu cầu. Và khi AI tạo ra kết quả rất nhanh, khoảng cách giữa yêu cầu được diễn đạt với yêu cầu thực sự mong muốn cũng có thể được khuếch đại.

Mình cho rằng đây là một hướng đáng nghiên cứu trong câu chuyện chuyển đổi công việc với AI. Thay vì chỉ tập trung vào việc tự động hóa thêm bao nhiêu thao tác, chúng ta cần hiểu cấu trúc công việc, những quyết định đang được đưa ra, cách đánh giá chất lượng và những rủi ro cần kiểm soát.

Thử nghiệm Test-First Drive mới giải quyết một phần nhỏ của bài toán đó. Kết quả vẫn cần được đo đạc để xác định liệu cách tổ chức mới có thực sự cải thiện hiệu quả hay không. Dù vậy, quá trình thiết kế thử nghiệm đã khiến mình thay đổi cách đặt câu hỏi: trước khi quyết định sử dụng model nào và cần bao nhiêu lớp reviewer, nên xác định công việc cần đáp ứng những điều kiện gì, phần nào có thể kiểm chứng bằng công cụ và phần nào thực sự cần đến phán đoán của AI hoặc con người.

Nếu bạn đang sử dụng AI cho một công việc lặp lại, có thể bắt đầu ngay từ lần giao việc tiếp theo. Hãy thử ghi rõ điều kiện hoàn thành, những trường hợp dễ sai và cách bạn sẽ kiểm tra kết quả. Khi phát hiện một lỗi, lưu lại tình huống đó để dùng cho lần sau. Sau vài lần thực hiện, bạn sẽ có cơ sở để đánh giá quy trình tốt hơn việc chỉ dựa vào cảm giác AI trả lời có vẻ ổn.

Bắt đầu từ lần giao việc tiếp theo

1. Ghi rõ điều kiện hoàn thành
2. Ghi những trường hợp dễ sai
3. Ghi cách bạn sẽ kiểm tra kết quả
4. Gặp lỗi thì lưu lại tình huống đó để dùng cho lần sau

Mình nghĩ đây cũng là một thay đổi đáng giá trong cách học và sử dụng AI. Khi buộc phải xác định thế nào là một kết quả đúng, chúng ta phải hiểu rõ hơn yêu cầu, dữ liệu, các quyết định và những điều kiện chi phối công việc của mình.

Công nghệ có thể giúp việc thực hiện nhanh hơn, còn khả năng thiết kế và kiểm chứng công việc quyết định chúng ta có sử dụng được tốc độ đó một cách hiệu quả hay không.

Và nếu chưa biết mình cần kiểm tra điều gì, việc bổ sung thêm vài AI reviewer có lẽ chưa phải nơi nên bắt đầu.

---

Tài liệu tham khảo

1. METR (2025). Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity. Nghiên cứu ngẫu nhiên có đối chứng về năng suất lập trình viên sử dụng công cụ AI đầu năm 2025.

2. METR (2026). We are Changing our Developer Productivity Experiment Design. Cập nhật dữ liệu tháng 2/2026 và giải thích các giới hạn trong phương pháp đo.

3. Martin Fowler (2023). Test Driven Development. Giải thích nguyên tắc TDD và vai trò của test-first trong thiết kế phần mềm.

4. Anthropic (2024). Building Effective Agents. Các cách tổ chức AI Agent, trong đó có Evaluator–Optimizer.

5. Anthropic (2026). Demystifying Evals for AI Agents. Những phương pháp và giới hạn khi đánh giá các hệ thống AI Agent.

6. OpenAI. Evaluation Best Practices. Hướng dẫn xây dựng bộ đánh giá theo nhiệm vụ, sử dụng dữ liệu thực tế và đối chiếu đánh giá tự động với con người.

Ghi chú: Những thông tin về tdrive và Test-First Drive được biên tập từ tài liệu thử nghiệm nội bộ ngày 20/10/2026. Các số liệu thời gian là quan sát vận hành; mục tiêu giảm 40% chưa phải kết quả đã đạt được. Những nhận định mở rộng sang công việc ngoài lập trình là hướng ứng dụng và nghiên cứu, không phải hiệu quả đã được chứng minh bằng thử nghiệm này.

#ai-coding-agent#claude-code#verification#productivity