- Khi lượng và quy mô mã do AI tạo ra tăng theo cấp số nhân, cách code review thủ công truyền thống không còn hiệu quả nữa
- Ở các nhóm có tỷ lệ áp dụng AI cao, sản lượng công việc hoàn thành tăng 21% và số PR được hợp nhất tăng 98%, nhưng lại xuất hiện nghịch lý là thời gian review PR tăng 91%
- Thay vì trực tiếp kiểm tra mã, vai trò của con người cần chuyển sang xác minh ở thượng nguồn bằng cách review đặc tả và tiêu chí chấp nhận (Acceptance Criteria)
- Thay vì một cổng xác minh đơn lẻ, cần một cấu trúc tin cậy nhiều lớp dựa trên mô hình phô mai Thụy Sĩ như cạnh tranh đa tác tử, guardrail mang tính quyết định, BDD, hệ thống quyền hạn và xác minh đối kháng
- Cách làm "triển khai nhanh, quan sát mọi thứ và hoàn tác còn nhanh hơn" đang trở thành mô hình mới thay thế cho review chậm rồi debug trên production
Con người vốn đã không gánh nổi code review
- Thực tế là PR bị bỏ đó nhiều ngày, có những phê duyệt mang tính hình thức, và reviewer chỉ lướt qua các diff dài 500 dòng
- Code review được xem là cổng chất lượng, nhưng vẫn có những đội đã phát hành phần mềm suốt hàng chục năm mà không cần review từng dòng, và code review chỉ thực sự trở nên phổ biến vào khoảng 2012~2014
- Dù có review thì sự cố vẫn xảy ra, nên các đội đã xây dựng những hệ thống như feature flag, rollout dần dần, rollback ngay lập tức để ứng phó
Phải từ bỏ việc đọc mọi dòng code
- Ở các nhóm có tỷ lệ áp dụng AI cao, cả số lượng thay đổi lẫn kích thước thay đổi đều đang tăng theo cấp số nhân
- Dựa trên dữ liệu từ hơn 10.000 nhà phát triển và 1.255 đội ngũ (phân tích của Faros)
- Các nhà phát triển cảm nhận rằng review mã do AI tạo ra tốn nhiều công sức hơn so với review mã của đồng nghiệp
- Với review thủ công, không thể thắng được cuộc chiến này; code review là một cổng phê duyệt của quá khứ không còn phù hợp với hình thức công việc hiện nay
AI code review thì vẫn chỉ là 'review'
- Nếu AI viết code và AI review code, thì không có lý do gì phải dựng lên một UI review hào nhoáng
- Các công cụ AI code review chỉ giúp tiết kiệm thời gian, và kiểu review này rồi cũng sẽ dịch chuyển sang bên trái của chu kỳ phát triển (shift left)
- Không có lý do gì để lãng phí tài nguyên CI và quản lý phiên bản giữa các vòng review
- Trong môi trường nơi các tác tử viết code, "một cặp mắt mới" cũng chỉ là một tác tử khác với cùng điểm mù; giá trị nằm ở vòng lặp lặp lại, không phải ở cổng phê duyệt
- Bản năng kiểu "đã từng thấy AI làm chuyện ngớ ngẩn nên lúc nào cũng phải kiểm tra" từng hợp lý khi còn có thể xác minh thủ công, nhưng ở quy mô hiện tại thì không còn khả thi nữa
Chuyển từ review code sang review ý định (Intent)
- Cần dịch chuyển checkpoint của con người lên thượng nguồn (upstream)
- Trong phát triển phần mềm đã từng có tiền lệ cho việc checkpoint dịch chuyển: từ ký duyệt waterfall → tích hợp liên tục (CI)
- Phát triển dựa trên đặc tả (Spec-driven development) đang nổi lên như phương thức hợp tác chủ đạo với AI
- Con người cần review đặc tả, kế hoạch, ràng buộc và tiêu chí chấp nhận, chứ không cần review diff 500 dòng
- Trong mô hình mới, đặc tả trở thành nguồn chân lý duy nhất (source of truth), còn code là đầu ra của đặc tả
- Thứ được review không còn là code mà là các bước (steps), quy tắc xác minh (verification rules) và hợp đồng (contract) mà code phải thực hiện
- Việc phê duyệt có human-in-the-loop chuyển từ "cái này có được viết đúng không?" sang "nó có đang giải đúng bài toán với đúng ràng buộc không?"
- Phán đoán giá trị nhất của con người không nằm sau khi code được sinh ra, mà ở trước khi dòng đầu tiên được tạo ra
Xây dựng lòng tin nhiều lớp — mô hình phô mai Thụy Sĩ
- LLM không giỏi tuân thủ chỉ thị, thường xuyên chệch hướng và ngay cả tự xác minh cũng không đáng tin (dù code đang cháy vẫn tự tin trả lời là "chạy được")
- Giải pháp không phải là yêu cầu LLM tự xác minh, mà là bắt nó viết ra các script xác minh — chuyển từ phán đoán sang tạo ra đầu ra kiểm chứng được
- Lòng tin phải được xây theo từng lớp, và theo mô hình phô mai Thụy Sĩ, cần chồng nhiều bộ lọc không hoàn hảo để các lỗ hổng không thẳng hàng
Layer 1: So sánh nhiều phương án
- Thay vì yêu cầu một tác tử đưa ra đáp án đúng, hãy để ba tác tử thử theo những cách khác nhau rồi chọn kết quả tốt nhất
- Việc lựa chọn không nhất thiết phải làm thủ công; có thể xếp hạng theo tiêu chí như phương án vượt qua nhiều bước xác minh nhất, diff nhỏ nhất, hoặc không thêm dependency mới
- Chi phí của việc tạo ra nhiều phương án hiện đang ở mức thấp nhất trong lịch sử kỹ nghệ phần mềm
Layer 2: Guardrail mang tính quyết định
- Cần có những cách mang tính quyết định để xác minh công việc — như test, type check, xác minh contract — tức là chỉ xử lý sự thật chứ không phải ý kiến
- Thay vì hỏi LLM "cái này xong chưa?", hãy định nghĩa các bước xác minh tạo ra một chuỗi đầu ra pass/fail
- Phân tầng guardrail gồm:
- Hướng dẫn coding — có thể triển khai bằng custom linter
- Các quy tắc bất biến toàn tổ chức — những điều không thể thương lượng như cấm hardcode credential, API key, token
- Domain contract — quy tắc theo framework, service hoặc khu vực codebase (ví dụ: trong domain thanh toán, mọi số tiền phải dùng kiểu Money)
- Tiêu chí chấp nhận (Acceptance Criteria) — tiêu chí riêng cho từng công việc
- Các bước xác minh phải được định nghĩa trước khi viết code, không phải tạo ra sau đó chỉ để xác nhận thứ đã tồn tại
- Nếu tác tử vừa viết code vừa viết test thì chỉ là dời vấn đề sang chỗ khác; tiêu chí xác minh phải đến từ đặc tả, không phải từ phần triển khai
Layer 3: Con người định nghĩa tiêu chí chấp nhận
- Nơi con người tạo giá trị là định nghĩa thành công từ thượng nguồn
- BDD (Behavior-Driven Development) trở nên phù hợp trở lại
- Đây là cách mô tả hành vi kỳ vọng bằng ngôn ngữ tự nhiên rồi tự động hóa nó thành test
- Trước đây vì còn phải tự viết code nên viết đặc tả trông như công việc phát sinh thêm, nhưng trong môi trường tác tử thì đặc tả là đầu ra sơ cấp
- Khi con người viết đặc tả, tác tử sẽ triển khai, và framework BDD sẽ xác minh — miễn là không thất bại thì không cần đọc phần triển khai
- Những việc con người làm tốt: định nghĩa "tính đúng đắn", mã hóa business logic và edge case, suy nghĩ về những gì có thể đi sai
- Tiêu chí chấp nhận do con người viết và máy xác minh mới là cổng kiểm soát thực sự quan trọng
Layer 4: Biến hệ thống quyền hạn thành kiến trúc
- Việc tác tử được phép động vào cái gì và cái gì cần escalation phải trở thành một quyết định kiến trúc
- Phần lớn framework tác tử xử lý quyền hạn theo kiểu all-or-nothing, nhưng sự chi tiết hóa mới quan trọng
- Một tác tử sửa bug ở utility function không cần quyền truy cập cấu hình hạ tầng
- Một tác tử viết test không cần quyền sửa pipeline CI
- Phạm vi nên hẹp nhất có thể miễn là tác tử vẫn làm được việc hữu ích
- Ví dụ: nếu nhiệm vụ là "sửa lỗi parse ngày trong
utils/dates.py" thì chỉ nên cho phép truy cập file đó và file test liên quan
- Trigger escalation cũng quan trọng: sửa logic xác thực, thay đổi schema database, thêm dependency mới... những mẫu như vậy phải tự động kích hoạt review của con người bất kể mức độ tự tin của tác tử
Layer 5: Xác minh đối kháng
- Tách biệt trách nhiệm: một tác tử làm việc, một tác tử khác xác minh — điểm cốt lõi là không để chúng tin tưởng lẫn nhau
- Đây là một mẫu lâu đời tương tự như việc đội QA không nên báo cáo cho engineering manager, và người viết code không nên là người duy nhất review nó
- Có thể ép buộc điều này ở mức kiến trúc: tác tử viết code không biết tác tử xác minh sẽ kiểm tra điều gì, còn tác tử xác minh thì không thể sửa code — đối kháng theo thiết kế
- Đi xa hơn nữa, có thể để tác tử thứ ba cố gắng phá hủy những gì tác tử thứ nhất tạo ra bằng cách nhắm vào edge case và failure mode — tức là áp dụng tự động hóa red team/blue team cho mọi thay đổi
Ý nghĩa của "code tốt" đang thay đổi
- Incentive của hệ thống tác tử rất đơn giản: hoàn thành nhiệm vụ được giao và làm hài lòng người ra lệnh — độ chính xác dài hạn hay yêu cầu kinh doanh không phải động lực nội tại
- Vai trò của con người là mã hóa những điều đó thành ràng buộc
- Trong thế giới nơi tác tử tạo code và tác tử đọc code, hình thái của "code tốt" sẽ chuẩn hóa hơn, và lượng định hướng cần cung cấp cho một codebase mới sẽ giảm đi
- Hướng đi của tương lai là: "triển khai nhanh, quan sát mọi thứ, và hoàn tác còn nhanh hơn"
- Trái ngược với: "review chậm, vẫn để lọt bug, rồi debug trên production"
- Không thể thắng bằng cách đọc nhiều hơn những gì máy tạo ra; cần tư duy vượt máy ở thượng nguồn nơi các quyết định thực sự quan trọng
- Nếu tác tử xử lý code tốt, thì việc con người có đọc được code đó hay không không còn quan trọng nữa
23 bình luận
Tôi khá tò mò liệu trước thời AI, code review có thực sự vận hành tốt ở mọi nơi hay không.
Thực ra, những tổ chức làm code review nhanh chóng và nghiêm túc là cực kỳ hiếm.
Ngay cả trước thời AI, nhiều lập trình viên cũng đã làm code review một cách hời hợt, chậm trễ và thiếu chỉn chu.
Theo trải nghiệm của tôi, các công ty công nghệ Mỹ thì làm đúng bài bản, còn ở nước ngoài bao gồm cả trong nước thì rất lộn xộn.
Nói ngược lại thì review càng chặt chẽ, áp lực công việc càng lớn; còn review lộn xộn thì tương đối thoải mái hơn
Tôi nghĩ việc review biến mất là kết quả của cơ chế thưởng cho hành vi.
Nếu điều công ty yêu cầu là
tỷ lệ lỗi thấp thì họ sẽ yêu cầu review gắt gao hơn,
còn nếu là phát hành tính năng nhanh thì review sẽ dần bị lược bỏ.
Câu chuyện review biến mất khiến tôi cảm thấy điều doanh nghiệp ưu tiên là phát hành tính năng nhanh.
Nhưng nếu là nhà đầu tư thì có lẽ tôi cũng sẽ đòi hỏi như vậy thôi, haha
Tôi cũng không rõ lắm. Nếu vì việc review đã trở thành nút thắt cổ chai mà lại bảo đừng review nữa, thì tôi cảm thấy như vậy là quên mất bổn phận chính. Thay vào đó, tôi nghĩ một cách tốt hơn là bắt buộc phân bổ thời gian review tương ứng với phần thời gian triển khai đã được rút ngắn.
Đây là một ý tưởng đáng để thử, nhưng có vẻ quan điểm chủ đạo hiện giờ vẫn là còn quá sớm.
Cứ tiếp tục chồng thêm các hộp đen sao?
Kiểu như cứ tạo mã như một hộp đen rồi chỉ nhìn kết quả thôi... đại khái là vậy... nhưng liệu đây có thực sự là hướng đi mong muốn không.. Tôi cho rằng đến một lúc nào đó chắc chắn sẽ có thời điểm toàn bộ lượng mã hiện tại do AI viết ra bị lật lại và làm lại từ đầu.
Đây là một vấn đề có thể nghĩ theo kiểu tương tự với câu nói: "FSD đã thông minh hơn rồi nên tài xế có thể ngủ."
Về mặt công nghệ, có vẻ thời đại như vậy sẽ dần đến, nhưng điều quan trọng có lẽ là làm sao vượt qua rào cản mang tên trách nhiệm.
Tôi nghĩ code review chẳng phải là thiết bị an toàn tối thiểu sao.
Tại sao việc kiểm chứng ý định ở cấp độ khái niệm cao hơn lại do con người làm..?
Thực ra cũng đâu nhất thiết phải bắt viết mã bằng ngôn ngữ lập trình.
Khi cùng truyền một prompt cho AI, tôi có cảm giác rằng việc review kết quả tạo ra của nó chẳng phải khá giống với việc kiểm tra hiệu năng của mô hình sao?
Có vẻ như đã chốt sẵn kết luận rồi mới nhờ LLM viết ra. Ngụy biện.
Có vẻ hoàn toàn không có kinh nghiệm production
Chỉ là câu chuyện như mơ thôi.
Càng về sau thì tài liệu hóa cũng không còn nhiều ý nghĩa, và người ta lại càng review nghiêm ngặt hơn phải không?
Ừ thì~ chỉ riêng việc viết ra để tạo nên cuộc tranh luận như thế này thôi cũng đã đủ thể hiện ý đồ rồi mà
Đây vốn là vấn đề có thể được loại ngay từ giai đoạn lập kế hoạch.
Trong quá trình viết code thủ công, lập trình viên một cách tự nhiên sẽ đồng thời ngầm thực hiện việc lên kế hoạch, thiết kế, khám phá, hiểu, kiểm thử, tự review, và cả quy trình ứng phó sau sự cố khi vấn đề phát sinh, nên các khía cạnh đó vốn dĩ sẽ được điều chỉnh một cách tự nhiên. Vì vậy, tôi nghĩ rằng ngay cả khi việc kiểm thử hay review còn thiếu, mọi thứ vẫn có thể vận hành ở một mức độ nào đó.
Nhưng nếu loại bỏ quá trình viết tay đó, thì những quy trình vốn tồn tại ngầm phải được phân định ranh giới một cách tường minh. Vì chủ thể viết code và chủ thể kiểm tra ngày càng tách biệt hơn, sự kém hiệu quả trong giao tiếp cũng tăng lên. Do độ tin cậy dành cho chủ thể viết code thấp hơn, chi phí kiểm tra cũng vì thế mà tăng lên.
Tôi nghĩ điều này có lẽ khá giống với khái niệm gọi là doorman's fallacy.
Đây cũng là chủ đề mà tôi thường suy nghĩ ở công ty, hay đấy, cá nhân tôi cũng nên thử áp dụng vào Hanis mà mình đang tự làm.
Có lẽ dần dần sẽ chuyển theo hướng tinh gọn việc review hơn và siết chặt phần test hơn nữa.
Có vẻ như ý ở đây không chỉ đơn giản là bỏ code review, mà là review bằng các đầu ra ở cấp độ cao hơn, nơi có thể xác nhận một cách tường minh ý đồ và việc ý đồ đó có vận hành đúng hay không.
Ở thời điểm hiện tại, tôi cho rằng việc giữ các chi tiết triển khai mã ở dạng hộp đen, thay vì đi vào cấp độ thiết kế hay kiến trúc, là điều đáng mong muốn.
Tôi nghĩ cái hộp đen đó cứ chồng chất lên, đến mức ngay cả AI cũng không thể xử lý cho ra hồn. Có vẻ mọi người đang quá say sưa với sự tiện lợi. Tôi nghĩ rồi một ngày nào đó sẽ xảy ra một sự cố lớn.
Tôi cũng đồng ý với ý kiến của bạn ở trên. Nếu vào một ngày nào đó đột nhiên phát hiện ra mô hình đã học sai một phần nào đó trong mã do con người viết, và nhận ra điều này bấy lâu nay đã được phản ánh vào code thì sao? Ngày đó có khi sẽ là ngày mọi thứ bị đảo lộn hết..
Dù mô hình mới nhất có giỏi đến đâu đi nữa, nếu không thể
luônđạt điểm tuyệt đối ở SWE benchmark (6 nine, 0.999999) thì tôi nghĩ khả năng đó vẫn luôn để ngỏ.Đánh giá theo ý định. Cách nói hay đấy.
Mình đã suy nghĩ về cách cần thích ứng trong thời đại được AI tăng tốc,
đây là một bài viết hay mang đến góc nhìn mới về code review!