Đánh giá mã theo tác tử

• Nhờ hiệu năng của các coding agent tăng vọt, điểm khó trong kỹ thuật đã chuyển từ viết mã sang đánh giá xem có thể tin mã đó hay không, khiến review trở thành công việc có đòn bẩy cao nhất
• AI làm tăng mạnh sản lượng, nhưng lại làm giảm chất lượng và khả năng review, tạo ra khoảng cách nơi lượng mã gấp 4 lần nhưng giá trị thực chỉ tăng khoảng 10%
• Mức độ review cần thiết thay đổi theo blast radius (phạm vi tác động) của thay đổi; một lập trình viên solo và một nhóm bảo trì hệ thống lớn 10 năm tuổi có những ràng buộc hoàn toàn khác nhau
• Agent có suy luận, nhưng suy luận đó không được đính kèm vào PR mà bị bỏ đi, khiến reviewer phải gánh thêm việc tái dựng lại ý đồ (intent) đã biến mất từ đầu
• Việc viết đã rẻ hơn, nhưng việc hiểu vẫn đắt đỏ, nên các đội xây dựng được hệ thống review đáng tin cậy sẽ chiếm ưu thế trong tương lai

---

Dữ liệu năm 2026 thực sự cho thấy điều gì

• Những tuyên bố từng chỉ là giai thoại và tranh cãi trong nhiều năm nay đã được đo lường ở quy mô lớn bởi các tổ chức có lợi ích khác nhau, thậm chí cạnh tranh nhau, và đều đi tới cùng một kết luận: AI làm sản lượng tăng mạnh nhưng làm giảm chất lượng và khả năng review

• Đo lường của Faros AI (dữ liệu tháng 3/2026)

  • Theo dõi quá trình chuyển từ mức áp dụng AI thấp sang mức áp dụng AI cao ở 4.000 team với 22.000 developer
  • Mặt tích cực: developer merge được nhiều PR hơn và hoàn thành nhiều việc hơn, thông lượng trên mỗi kỹ sư tăng lên
  • Các chỉ số tiêu cực
    • Code churn tăng 861%
    • Tỷ lệ incident trên mỗi PR tăng 242.7%
    • Tỷ lệ lỗi trên mỗi developer tăng từ 9% → 54%
    • Thời gian review trung vị tăng 441.5% (cả thời gian đến review đầu tiên và thời gian review trung bình đều gần gấp đôi)
    • PR được merge mà không review tăng 31.3%
  • Merge không review không phải là lựa chọn có chủ đích của ai cả, mà là kết quả của việc reviewer không theo kịp khối lượng, khiến mã chưa được đọc vẫn thường xuyên được merge
  • Ngay cả các team có thực hành kỹ thuật trưởng thành và kỷ luật cũng bị ảnh hưởng như nhau; quy trình tốt không bảo vệ được họ vì khối lượng đến nhanh hơn tốc độ thiết kế quy trình

• Nghiên cứu của CodeRabbit (12/2025)

  • Phân tích 470 PR mã nguồn mở (320 có AI đồng tác giả, 150 chỉ do con người viết), và thấy các thay đổi do AI tạo ra đi kèm khoảng 1.7 lần nhiều issue hơn
    • Vấn đề logic và độ đúng tăng khoảng 75%
    • Issue bảo mật tăng 1.5~2 lần
    • Vấn đề dễ đọc tăng hơn 3 lần
  • Giám đốc AI David Loker nói: "Đây là một điểm yếu có thể dự đoán và đo lường được mà tổ chức phải chủ động giảm thiểu" — vì đó là điểm yếu đã biết và có thể định vị, quy trình review có thể nhắm trúng đích

• Dữ liệu năng suất của GitClear (đến năm 2025)

  • Người dùng AI hằng ngày có sản lượng thô gấp khoảng 4 lần so với người không dùng, nhưng mức cải thiện năng suất thực tế so với chính họ một năm trước chỉ khoảng 12%
  • Cấu trúc ở đây là con người vẫn phải review toàn bộ lượng mã tăng gấp 4 lần đó
  • Bill Harding lưu ý rằng ngay cả con số 12% ấy cũng có thể một phần đến từ thiên lệch lựa chọn, khi các developer mạnh tập trung nhiều hơn vào nhóm dùng AI

• Báo cáo của GitHub

  • Copilot review đã được chạy tích lũy hơn 60 triệu lần, tăng gấp 10 chỉ trong một năm, và hơn 1 trong 5 review trên nền tảng có agent tham gia
  • Đây không còn là một thực hành ngách, mà đã là chính cách mã đang được tạo ra
• Bốn bộ dữ liệu, bốn phương pháp luận khác nhau, nhưng cùng hội tụ về một kết luận: nút thắt không biến mất mà chuyển sang giai đoạn xác minh (verification)

Mọi người đang giải những bài toán khác nhau

• Phần lớn dữ liệu cảnh báo ở trên đến từ telemetry doanh nghiệp và các maintainer mã nguồn mở bị quá tải, nên phần lớn không áp dụng nguyên vẹn cho một solo developer đang làm thứ chỉ vài người dùng

• Ba biến số quyết định vị trí của bạn

  • blast radius: nếu hỏng thì chuyện gì xảy ra — không có gì, hay là người dùng phẫn nộ, mất tiền, lộ PII
  • Tuổi thọ của mã: là prototype dùng một lần rồi bỏ vào tuần sau, hay là codebase sẽ được duy trì nhiều năm
  • Số người cần phải hiểu nó: chỉ mình bạn là người nắm hết trong đầu, hay là một team chia sẻ quyền sở hữu theo thời gian

• Solo, greenfield, không có user

  • Vai trò thứ hai của review là phân phối kiến thức trong team không tồn tại ở đây vì bản thân bạn chính là team
  • Lựa chọn hợp lý là phụ thuộc mạnh vào test và tự động hóa, chỉ review kỹ những phần thực sự quan trọng, phần còn lại chạm nhẹ
  • Tuy vậy, điều này chỉ hiệu quả khi test là thật; bỏ qua review mà không có lưới an toàn không làm công việc biến mất mà chỉ trì hoãn (defer) nó với cái giá đắt hơn
  • "Không có user" là giấy phép để trì hoãn review, chứ không phải giấy phép để bỏ qua xác minh

• Vùng giữa đầy rủi ro

  • Ngay khi dự án có user, vai trò bắt bug của review lập tức trở nên quan trọng vì bug bắt đầu gây hại cho con người, và vai trò chia sẻ tri thức cũng bật lên
  • Nếu team tiếp tục giữ thói quen từ thời solo thêm vài tháng rồi mới gặp postmortem, các con số của Faros sẽ trở thành dashboard của chính họ

• Tổ chức lớn, codebase cũ, nhiều user

  • Tất cả chỉ số cảnh báo đều áp dụng ở cường độ tối đa; những thay đổi mà không ai hiểu sẽ trở thành comprehension debt (nợ hiểu biết) rồi chuyển hóa thành incident on-call của ai đó
  • Điểm cốt lõi không phải là "doanh nghiệp thì thận trọng, solo thì thoải mái", mà là mục đích của review thay đổi theo vị trí nên quy tắc cũng phải thay đổi theo
  • Gắn một pipeline đa agent kiểu enterprise cùng yêu cầu bằng chứng vào một prototype 2 người là tạo ma sát vô nghĩa; còn áp dụng kiểu "test pass thì deploy" cho hệ thống thanh toán thì chỉ là máy tạo incident với dấu check xanh

Review hiện nay thực sự làm gì

• Khi con người viết mã, ý đồ đi kèm gần như miễn phí; các phương án đã cân nhắc rồi loại bỏ vẫn còn trong đầu tác giả, nên review vốn là việc kiểm tra chuỗi suy luận đó
• Agent hiện đại cũng suy luận và đôi khi còn hiển thị rõ thinking trace, nhưng suy luận ấy bị vứt đi ngay khi diff được tạo ra và không được đính kèm vào PR
• Hơn nữa, đó là suy luận của agent về việc "triển khai như thế nào", chứ không phải phán đoán của con người về việc "đây có phải là việc đúng để làm ngay từ đầu hay không"
• Kết quả là review chuyển từ việc kiểm tra suy luận trước mắt sang tái dựng ý đồ không được ghi lại, nên khó hơn và chậm hơn nhiều, đó cũng là lý do mất thêm 441% thời gian

• AI Slop and the Software Commons (bài báo 2026)

  • Phân tích 1.154 bài đăng trong 15 thread trên Reddit và Hacker News
  • Một developer mô tả rằng review PR do agent tạo ra khiến anh ta trở thành "con người đầu tiên nhìn thấy đoạn mã này"
  • Theo cách diễn đạt của bài báo, review "không được thiết kế để khôi phục ý đồ đã biến mất"

• Lời giải là vấn đề công cụ

  • Ý đồ bị mất có thể được khôi phục — suy luận đó từng tồn tại, chỉ là đã bị vứt đi
  • Nếu buộc agent nêu rõ nó định làm gì và loại bỏ những gì, rồi ghi lại thành decision log (nhật ký quyết định) của PR, phần lớn chi phí tái dựng sẽ biến mất
• Chỉ riêng chuyện "AI review AI" không phải là câu trả lời trọn vẹn; một model thứ hai với tri thức nền khác có thể bắt được nhiều bug thật, nhưng không thể cung cấp phán đoán của con người rằng "thay đổi này có đáng để xây hay không"

Công cụ là tốt, nhưng không phải theo đúng lý do chúng được quảng cáo

• Các công cụ AI review chuyên dụng hiện đã đủ tốt, và nên chạy ít nhất coding agent chính của bạn trên mọi thứ, kể cả side project, tốt nhất là thêm cả review agent chuyên dụng nếu có thể

• Đặc điểm của các công cụ chính

  • CodeRabbit: được triển khai rộng rãi nhất, đứng đầu F1 trong benchmark Martian độc lập (1~2/2026), precision khoảng 49% với recall tốt nhất ngành
  • Greptile: hy sinh precision để lấy recall; trong một benchmark có tỷ lệ phát hiện bug khoảng 82% (so với 44% của CodeRabbit) nhưng nhiều false positive hơn
  • Anthropic Code Review: chưa đến 1% kết quả bị kỹ sư nội bộ đánh dấu là sai, và tăng tỷ lệ PR nhận được review thực sự từ 16% lên 54%

• Thử nghiệm chạy song song 4 reviewer (kết quả ngoài vendor)

  • Một kỹ sư đã áp dụng song song CodeRabbit, Sentry Seer, Greptile và Cursor BugBot lên 146 PR thật trong 3 tuần rưỡi, phát hiện 679 mục
  • Trong 617 vị trí cờ cảnh báo duy nhất, 93.4% chỉ được đúng một công cụ phát hiện, 6% bởi hai công cụ, gần như không có trường hợp ba công cụ, và không có trường hợp nào cả bốn cùng phát hiện
  • Không có lần nào bốn công cụ cùng gắn cờ một dòng mã
  • Mỗi công cụ có điểm mạnh khác nhau: Greptile gần như không có false positive ở độ đúng và kiến trúc, CodeRabbit có lưới quét rộng nhất và sửa một cú nhấp, Seer mạnh ở mức độ nghiêm trọng của sự cố vận hành
  • Tính dị thể (heterogeneity) là then chốt — bốn bản sao của cùng một model chỉ là một reviewer duy nhất với hóa đơn lớn hơn; bốn reviewer thực sự khác nhau sẽ lộ ra những bug mà không ai tự mình tìm được

• Hướng dẫn thực hành

  • Đừng cố tìm một công cụ tốt nhất duy nhất vì nó không tồn tại
  • Ở vùng rủi ro cao, hãy chủ đích dùng song song hai công cụ có tính cách khác nhau (thí nghiệm trên dùng Greptile cho độ đúng thường nhật + Seer cho mức độ nghiêm trọng vận hành)
  • Nếu bạn làm solo, một reviewer tốt cộng với test thật là đủ
  • Bất kể marketing nói gì, hãy đo trên chính code của bạn, vì mọi kết quả đều chỉ giới hạn trong một codebase cụ thể

Có nên giao nhiều việc review hơn cho AI không

• Một câu hỏi mà một năm trước còn bị coi là dị giáo giờ đã xuất hiện từ các kỹ sư dày dạn kinh nghiệm — liệu máy móc có nên làm nhiều hơn, thậm chí phần lớn, công việc review hay không

• Sự thật khó chịu rằng AI review có hiệu quả

  • Dưới 1% phát hiện của Anthropic bị đánh dấu là sai; nó bắt được bug mà con người bỏ sót và không mệt ở PR thứ 30 trong ngày, đúng lúc con người ít đáng tin nhất
  • Trong khi đó con người không theo kịp — merge không review tăng 31%, thời gian review tăng ba chữ số
  • Cách đặt vấn đề trung thực không phải là "có nên giao thêm cho AI không" mà là "AI đã làm việc này rồi, vậy ta sẽ để nó làm một cách có chủ đích hay tiếp tục giả vờ là con người đã đọc hết"

• Góc nhìn của loop engineering

  • Tiền đề của loop là rời khỏi việc một con người viết prompt cho agent để chuyển sang xây dựng hệ thống viết prompt cho agent, với agent judge ở trung tâm để quyết định công việc đã hoàn tất hay chưa
  • Reviewer trở thành vai trò tiếp theo bị loại bỏ có chủ đích khỏi vòng lặp nội bộ; sau một năm tự động hóa việc viết, giờ đến tự động hóa việc xác minh, và con người bị đẩy lên tầng trên

• Rủi ro của vòng lặp khép kín

  • Một agent viết, một agent khác review, agent thứ ba phán định — đó là một vòng khép kín của các model có điểm mù tương quan (correlated blind spots), đặc biệt khi chúng cùng họ nên sẽ tự tin đồng ý ở cùng một điểm
  • Một câu "looks good" đầy tự tin mà không có con người nào tham gia chỉ là sự tự tin vay mượn (borrowed confidence) — sự tự tin của hệ thống bị biến thành sự tự tin của chính ta trong khi thực ra không ai hiểu điều gì đang diễn ra

• Con người không biến mất mà dịch lên một tầng

  • Thay vì đọc mọi diff, con người chuyển sang sở hữu những phần không thể chuyển giao cho model, nơi trách nhiệm giải trình là điều quan trọng
  • Những vùng con người phải canh giữ: phán đoán xem đây có phải thay đổi đúng để làm không, các cổng kiểm soát blast radius cao nơi sai lầm rất đắt, và những hành vi mà không ai từng đặc tả (model chỉ review mã đang tồn tại và gần như không thể gắn cờ các yêu cầu chưa từng được viết ra)
  • Từ human in the loop sang human on the loop — thay vì đọc mọi PR, con người lấy mẫu, spot-check, audit hệ thống, và tập trung lượng chú ý hữu hạn vào đúng nơi khi sai thì thật sự đau

• Trường hợp của Kun Chen (cựu kỹ sư Meta L8, solo builder)

  • Xuất xưởng khoảng 40 PR mỗi ngày và gần như dừng code review, chạy song song 20~30 agent
  • Chuyển nỗ lực sang kế hoạch (plan) — viết kế hoạch chi tiết từ trước, rồi để agent chạy hàng giờ; chất lượng kế hoạch quyết định thời gian chạy không cần giám sát
  • Không phải anh ấy ngừng xác minh, mà là viết ý đồ từ sớm để tự giải quyết một nửa vấn đề "con người đầu tiên nhìn thấy mã" (con người hiểu lý do từ trước chứ không phải sau khi mã đã có)
  • Anh ấy cũng không làm việc mà không có lưới an toàn — cổng review tự động gọi là No Mistakes sẽ kiểm tra mã trước khi merge, và agent sẽ chờ escalatation khi bị kẹt
  • Nhưng anh ấy là một solo builder không có team lớn cũng không có hệ thống bãi mìn 10 năm tuổi; điều kiện của anh ấy không phải điều kiện của đa số độc giả — sao chép sang một team phục vụ nhiều user sẽ chỉ tái hiện các con số Faros trên chính dashboard của bạn
• Kết luận trên phổ này: với solo và không có user, giao gần như mọi thứ cho AI là một lập trường có thể tự vệ được trong năm 2026; còn với quy mô lớn và nhiều user, lượt một, lượt hai và 90% phần tẻ nhạt có thể để máy làm, nhưng các đường đi chịu tải (load-bearing paths) vẫn phải có người thật, và nút chỉnh mức độ can dự của con người nên đặt theo blast radius chứ không phải theo cảm giác tội lỗi

Thực tế thì nên làm gì

• Nguyên tắc tổ chức: căn chỉnh nỗ lực review theo chi phí của việc sai, kéo tối đa các tác vụ rẻ và có tính quyết định lên phía trước, và dành sự chú ý của con người cho đúng những việc chỉ con người làm được

• Phân tầng theo rủi ro, không theo tác giả (Tier by risk, not by author)

  • Thay đổi cấu hình thì linter cộng một lượt xem qua là đủ
  • Sửa đường đi của logic nghiệp vụ cốt lõi thì cần full stack: type, test, hai AI reviewer khác nhau, con người sở hữu hệ thống đó, và một security pass
  • Đừng dùng review nặng cho boilerplate, và cũng đừng để một thay đổi lớn đi qua chỉ vì test đang xanh

• Cắt nhanh cái đuôi đắt đỏ (Fast-fail the expensive tail)

  • Early-Stage Prediction of Review Effort (1/2026) nghiên cứu 33.707 PR do agent viết
  • Agent mạnh ở những thay đổi nhỏ và được định nghĩa rõ, nên khoảng 28% được merge gần như ngay lập tức; nhưng ngay khi nhận feedback mang tính chủ quan, chúng có xu hướng "biến mất (ghost)", từ bỏ phần qua lại vốn là cốt lõi của review
  • Trong một bài báo đi kèm năm 2026, reviewer bỏ cuộc chiếm 38% số PR của agent bị từ chối
  • Nhóm nghiên cứu đã xây một circuit breaker dùng các tín hiệu rẻ như loại file và kích thước patch để dự đoán các PR có chi phí bảo trì cao trước khi con người phải nhìn vào, và nó hoạt động tốt

• Nâng cao chính tiêu chuẩn của thứ đáng được review

  • Lời giải không phải là khóa repo, mà là từ chối review các thay đổi đến mà không có bằng chứng
  • Yêu cầu trước khi review: nêu rõ mục đích thay đổi, diff thực sự thay vì 3.500 dòng không chú thích, output của test, và bằng chứng là nó đã thực sự được chạy
  • Thay vì tự hấp thụ chi phí tái dựng ý đồ bằng sự chú ý đắt đỏ của mình, hãy đẩy ngược nó về cho người gửi — nơi nó có thể được xử lý rẻ hơn

• Giữ PR nhỏ một cách có chủ đích

  • PR do agent tạo ra có xu hướng lớn (dữ liệu Faros cho thấy trung bình lớn hơn 51%), trong khi mức độ tham gia của reviewer là một trong những biến dự báo mạnh nhất cho việc PR có được merge hay không
  • PR lớn và không thể review nên bị từ chối ngay lập tức, hoặc tệ hơn là bị đóng dấu cao su cho qua
  • Hãy chỉ thị cho agent tạo commit nhỏ; một diff mà con người thực sự đọc được giờ không còn là phép lịch sự mà là ràng buộc thiết kế

• Đọc thay đổi test kỹ hơn cả thay đổi mã

  • Một failure mode cần cảnh giác của agent là: thay đổi hành vi xong rồi viết lại assertion cho khớp với hành vi mới bị hỏng để "sửa" test
  • Một dấu check xanh trên 200 test đã sửa là vô nghĩa cho tới khi bạn xác nhận việc sửa đó là đúng; những diff viết lại nhiều test nên được coi là cờ đỏ để đọc trước
  • Giá trị của mutation testing: coverage cho biết dòng đó có được chạy hay không, còn mutation test cho biết liệu test có phát hiện được khi dòng đó sai hay không

• Xem CI như một bức tường không được dịch chuyển

  • Hãy để ý các mẫu mà GitHub cảnh báo reviewer: test bị xóa, lint bị bỏ qua, ngưỡng coverage bị hạ, helper bị trùng lặp dù đã có sẵn, và đầu vào không đáng tin chảy vào prompt
  • Mục cuối đặc biệt quan trọng — các tính năng do agent tạo ra là một nguồn phát sinh mới của prompt injection; nếu chuyển nguyên văn văn bản do người dùng kiểm soát vào lời gọi LLM, lỗ hổng sẽ không lộ ra trong diff mà sẽ nằm chờ trong dữ liệu đến sau
  • Agent có thể làm yếu CI mà không có ác ý chỉ để vượt qua, vì gradient descent sẽ tìm con đường rẻ nhất để đi đến màu xanh; cổng quyết định mang tính quyết định là phần duy nhất không thể bị lật ngược bằng một đoạn văn tự tin, nên phải giữ thật nghiêm

• Con người sở hữu việc merge

  • Model không thể bị gọi dậy lúc sự cố và cũng không thể chịu trách nhiệm, nên người bấm nút merge phải là người sở hữu
  • Khi AI review nói "looks good" bằng giọng điềm tĩnh và tự tin, đó luôn là hành động trao cho bạn một mức tự tin chưa từng được kiếm được
  • Hãy coi mọi AI review là sensor, không phải phán quyết — dữ liệu chứ không phải quyết định

Nếu bạn đang vận hành một team thì điều này có nghĩa gì

• Ràng buộc chi phối việc xuất xưởng giờ không còn là viết mã nhanh đến đâu, mà là người được tin cậy có thể nhanh đến đâu để tin chắc vào tính đúng đắn của thay đổi
• Mọi kế hoạch xem việc tạo mã là nút thắt cổ chai và coi review là miễn phí sẽ âm thầm đình trệ trong khi dashboard tốc độ vẫn xanh
• Báo cáo Faros nói thẳng rằng khi sản lượng tăng thì khối lượng QA và review cũng tăng; cắt giảm headcount kỹ thuật vì nghĩ "AI đã làm chúng ta nhanh hơn" trước khi đóng được khoảng trống review là một bước đi nguy hiểm
• Thuế kỹ sư senior dưới dạng thời gian review tăng ba chữ số sẽ đổ nặng nhất lên đúng những người lẽ ra không nên thành nút thắt, và nó không hiện ra trong các chỉ số chỉ đếm PR đã merge
• Maintainer mã nguồn mở là những người đâm đầu vào bức tường này sớm nhất và mạnh nhất — một dòng chảy đều đặn của các đóng góp nghe có vẻ hợp lý nhưng rỗng ruột, dù thiện chí, vẫn tiêu tốn thời gian triage thực tế; đó là chim hoàng yến trong mỏ than, còn doanh nghiệp là lượt tiếp theo
• Những nơi phản ứng tốt sẽ không coi năng lực review là phần dư AI giải phóng ra, mà là một tài nguyên thật cần được đo lường, bảo vệ và tiêu dùng có chủ đích

Viết đã rẻ hơn, nhưng hiểu thì không

• Đừng chấp nhận các câu trả lời đồng loạt ở hai cực — với người solo và không có user, các câu chuyện kinh dị của enterprise về churn và trùng lặp chưa phải đám cháy hôm nay mà là rủi ro tương lai; hãy dựa vào test, chỉ review điều quan trọng, nhưng thành thật thừa nhận rằng phần việc bị trì hoãn vẫn là nợ
• Nếu bạn ở quy mô lớn và có nhiều user, mọi chỉ số cảnh báo ở đây đều đang nói về bạn; thứ duy nhất có hiệu lực là phân tầng, yêu cầu bằng chứng, quy trình review dị thể có chủ đích và một con người sở hữu việc merge
• Điều không đổi trên toàn bộ phổ là quy luật kinh tế nền tảng — việc viết đã trở nên rẻ, còn việc hiểu vẫn đắt đúng như nó luôn từng đắt
• Những team làm tốt trong tương lai sẽ không phải là những team tạo ra nhiều mã nhất, mà là những team xây được hệ thống review thực sự đáng tin cậy, những team không bao giờ nhầm lẫn giữa "test đã pass" và "con người hiểu nó đang làm gì và vì sao"
• Như cách Simon Willison diễn đạt, bản chất của công việc là chuyển giao đoạn mã đã được chứng minh là hoạt động — agent không thay đổi điều đó mà chỉ khiến việc chứng minh trở thành trung tâm của công việc thay vì tác vụ phụ
• Năng lực hiểu hệ thống đủ sâu để có thể đứng sau nó vẫn là kỹ năng bền vững và thú vị nhất trong phần mềm, và đây là thời điểm tuyệt vời để trở nên cực kỳ giỏi ở điều đó