- Giải pháp cho rằng chỉ cần con người rà soát toàn bộ các lỗi thường gặp của công cụ lập trình LLM khó có thể đồng thời bảo đảm chất lượng và năng suất vì giới hạn xử lý của code review
- Theo các nghiên cứu thực nghiệm, một buổi review hiệu quả có trần khoảng 1 giờ·400 LOC; vượt ngưỡng này, mệt mỏi và suy giảm tập trung khiến hiệu quả phát hiện lỗi giảm rất nhanh
- Áp dụng tiêu chuẩn này, cứ mỗi 400 LOC do LLM tạo ra sẽ cần 1 giờ rà soát tập trung của một lập trình viên dày dạn kinh nghiệm, nên năng lực xử lý thực tế mỗi ngày có thể dưới 1.000 LOC
- Có bằng chứng ban đầu cho thấy con người tìm ra ít lỗi hơn trong mã do LLM tạo nhưng lại tự tin hơn, nên khó cho rằng chỉ dựa vào review là có thể lọc đủ lỗi
- Cần có nghiên cứu thực nghiệm đo lường và tái lập trực tiếp tỷ lệ phát hiện lỗi, tốc độ review và khối lượng bền vững hằng ngày của mã LLM để đánh giá hiệu quả thực sự của công cụ bằng chứng cứ thay vì giai thoại
Vì sao nhìn công cụ lập trình LLM với sự hoài nghi
- Trọng tâm vấn đề không nằm ở quyền sở hữu trí tuệ, chi phí sinh thái, tiêu thụ tài nguyên hay đánh giá rằng mọi đầu ra của LLM đều tệ hại
- Chỉ với bằng chứng khoa học hiện tại, rất khó xác nhận cách mà công cụ lập trình LLM giúp lập trình viên viết mã tốt hơn hoặc nhanh hơn
- Lập luận ủng hộ thường không trực tiếp xử lý các vấn đề và chứng cứ liên quan, thậm chí phản bác chủ nghĩa hoài nghi đôi khi còn làm vấn đề thêm rõ
- Dù bài viết được viết cách đây khoảng 1 năm nên dùng cụm Coding Assistants hiện gần như đã bị thay thế, tác giả vẫn giữ nguyên vì chưa tìm được thuật ngữ khác bao quát mọi cách dùng mã hóa của AI tạo sinh
Phép so sánh với “thực tập sinh” và giải pháp rà soát toàn diện
- Công cụ lập trình LLM có rủi ro lỗi tương đối cao do cấu trúc vận hành và giao diện tương tác
- Có thể tạo ra ảo giác hoặc lỗi gõ
- Có thể trả về kết quả không liên quan đến yêu cầu hoặc thực hiện công việc theo hướng khác
- Người dùng thường ví những công cụ này như thực tập sinh
- Cần dự liệu rằng kết quả sẽ sai ở mức nào đó
- Cần xem như nó làm việc mà không thật sự hiểu đúng mình đang làm gì
- Cách ứng phó phổ biến là để người có kinh nghiệm review toàn bộ kết quả như với mã của thực tập sinh hay lập trình viên junior
- Dựa trên giả định rằng con người hiểu rõ hơn và cũng là người chịu trách nhiệm cuối cùng
- Kéo theo lập luận rằng mọi mã đi vào codebase vốn dĩ đều phải được review
Mức độ review cần có để giám sát LLM
- Trong ngành và trong tài liệu nghiên cứu, review bao hàm nhiều thực hành khác nhau
- Review nhẹ, phân tán cho nhiều người hữu ích để chia sẻ hiểu biết về thay đổi và áp dụng các quy tắc bề mặt, nhưng không đủ làm chuẩn giám sát mã LLM
- Không nhất thiết phải kiểm tra đau đớn từng dòng trong nhiều giờ như kiểu hội đồng ngày xưa, nhưng vẫn cần code review khá sâu và đầy đủ
- Vì LLM có thể viết mã phức tạp và lỗi có thể ẩn trong chi tiết của phần mềm, chỉ kiểm tra sơ bộ là không đủ
Những giới hạn thực nghiệm mà code review phải đối mặt
- Các giới hạn chính của review hiệu quả được xác nhận trong nghiên cứu thực nghiệm như sau
- Một phiên review 1 giờ đã là quá dài
- Khối lượng có thể review hiệu quả trong khoảng thời gian đó tối đa chỉ khoảng 400 LOC
- Khi review vượt quá 1 giờ, hiệu quả giảm rất nhanh bất kể kích thước mã
- Không chỉ vì phần lớn mã đã được xem qua
- Mà còn vì giữ mức tập trung cao suốt 1 giờ sẽ gây mệt mỏi và nhàm chán, cần phải nghỉ
- Tác giả không tìm thấy nghiên cứu khảo sát thời gian hồi phục cần thiết giữa các phiên 1 giờ
- Có thể giả định cực hạn là vài lần mỗi ngày
- Khoảng 2 lần/ngày được nêu như mức khả dĩ trung bình nhưng không phải con số chắc chắn
- Số dòng mã có thể review mỗi giờ thay đổi mạnh theo ngữ cảnh và loại mã, cũng như kinh nghiệm và hiểu biết của người review
- Dù không phải chuẩn tuyệt đối, dữ liệu thực nghiệm gần như không có trường hợp review nhanh hơn 400 LOC/H mà vẫn phát hiện và đánh dấu lỗi hiệu quả, nên có thể xem đây là tốc độ tối đa còn hữu dụng
Tính toán thông lượng khi áp dụng cho mã LLM
- Nếu muốn xử lý vấn đề của mã LLM bằng review, thì ngay cả trong trường hợp tốt nhất cũng cần 1 giờ của lập trình viên dày dạn cho mỗi 400 LOC được tạo ra
- Số phiên review có thể chấp nhận cho một lập trình viên vào khoảng 10~40 phiên mỗi tuần, và giữa các phiên cần thời gian hồi phục chưa rõ độ dài
- Thời gian hồi phục có thể ít nhất 1~2 giờ, nhưng không có nghiên cứu trực tiếp xác nhận
- Quỹ thời gian tập trung này còn phải dùng cho họp, thiết kế, ứng phó sự cố và suy nghĩ về phần mã cần tự viết
- Trong trường hợp tốt nhất, lượng mã mà một lập trình viên dùng LLM có thể viết, review và commit mỗi ngày là vài nghìn LOC
- Trong kịch bản thực tế, thông lượng hằng ngày có thể dưới 1.000 LOC
- Bao gồm cả boilerplate, test, migration và file cấu hình
- Chỉ một file test cũng có thể vượt 400 LOC
- Ngay cả trong điều kiện lý tưởng khi phần lớn mã đều đơn giản và dễ review, review vẫn đóng vai trò trần trên của mức tăng năng suất
Khác biệt giữa review mã của người và mã của LLM
- Chứng cứ hiện có đến từ bối cảnh người review phát hiện lỗi trong mã do con người viết, và không có bằng chứng cho thấy hiệu quả tương tự áp dụng được cho mã LLM
- Bằng chứng ban đầu cho thấy người review mã do LLM tạo ra có xu hướng phát hiện ít lỗi hơn nhưng lại tin chắc hơn rằng mình đã tìm được hết lỗi
- So với tổ hợp tác giả con người và reviewer con người, tổ hợp công cụ lập trình LLM và reviewer con người có thể tạo ra kết quả chất lượng thấp hơn, trong khi reviewer ở vế sau lại đánh giá hiệu suất của chính mình cao hơn
- Review toàn diện không chỉ giới hạn lợi ích năng suất của LLM mà còn thiếu căn cứ chắc chắn rằng nó thật sự giải quyết được lỗi thường xuyên phát sinh
Chi phí phát sinh từ trước cả khi sửa lỗi
- Cách tính này chưa bao gồm chi phí sửa những lỗi được phát hiện
- Nó chỉ bàn đến năng lực và chi phí để lập trình viên chuyên nghiệp review mã trong môi trường làm việc và đánh dấu vấn đề
- Bất kể số lượng hay mức độ nghiêm trọng của lỗi mà LLM tạo ra là bao nhiêu, chi phí review mã sinh ra vẫn tồn tại
- Ngay cả khi công cụ lập trình LLM tạo ra mã chất lượng rất cao, nếu mọi đầu ra đều phải được review thì chi phí và giới hạn năng suất như cũ vẫn còn
Mâu thuẫn khi giao phần mã khó review nhất
- Người ủng hộ LLM nêu lợi điểm rằng công cụ có thể thay con người tạo ra loại mã mà người viết cảm thấy đau đớn khi phải tự làm
- Một ví dụ là đề xuất để LLM viết 100% mã Bash cần dùng về sau
- Shell script có cách parse lỏng lẻo và ngữ nghĩa chồng chéo quá mức, nên chỉ một lỗi gõ ở dấu câu có thể vô hại hoặc cũng có thể dẫn tới việc xóa sạch cả máy tính
- Đây là loại mã dễ sinh lỗi, khó hiểu, khó review và cũng khó nhận ra sai lầm chí mạng
- Việc giao cho một công cụ tạo lỗi ngẫu nhiên viết phần mã khó review nhất rồi nói rằng con người chỉ cần kiểm tra lại, trước hết vẫn chưa chứng minh được đầu ra LLM thực sự là đối tượng có thể review hiệu quả
- Vấn đề nằm ở chỗ lấy loại mã khó review nhất làm ví dụ tiêu biểu mà chưa trả lời liệu review có giải quyết được lỗi hay không, và còn lại đủ mức tăng năng suất hay không
Những bài toán thực chứng cần được kiểm tra
- Bài toán thứ nhất là đo xem người review phát hiện lỗi trong mã do LLM tạo ra tốt đến mức nào
- Năng lực phát hiện lỗi
- Tốc độ review
- Khối lượng review có thể duy trì trong một ngày
- Cần có dữ liệu về việc con người review mã LLM giống như các nghiên cứu đã có với mã do con người viết
- Các thí nghiệm và dữ liệu thực nghiệm hiện tại còn hạn chế về quy mô và bối cảnh, nên cần thêm nhiều nghiên cứu tái lập
- Dữ liệu khoa học hiện tại nghiêng về khả năng con người không review tốt đầu ra LLM hoặc khó phát hiện vấn đề của nó
- Điều này có thể phù hợp với đặc tính LLM được huấn luyện để né tránh việc bị phát hiện
- Cũng cần kiểm chứng khả năng kết quả hiện có chỉ là ngẫu nhiên
- Bài toán thứ hai là xác nhận việc review đầu ra LLM có phải là một vấn đề khác về chất so với review đầu ra do con người viết hay không
- Nếu khác biệt đủ lớn đến mức nghiên cứu code review hiện có không còn áp dụng được thì logic phê phán hiện tại có thể sụp đổ
- Tuy vậy, bằng chứng ban đầu cho thấy review mã do LLM tạo có khả năng khó hơn chứ không dễ hơn, và trong trường hợp đó phê phán còn được củng cố
Đánh giá thực chứng về công cụ chuyên nghiệp, thay vì giai thoại
- Xét những gì đã biết về code review, rất khó xác nhận các công cụ LLM với giao diện và quy trình hiện tại mang lại lợi ích gì cho lập trình viên chuyên nghiệp
- Điều gây khó chịu lớn hơn là việc nhà cung cấp liên tục đưa ra công cụ và quy trình mâu thuẫn với bằng chứng, đồng thời xem những người hoài nghi như điều bất thường thay vì trực tiếp giải quyết vấn đề
- Mô thức giai thoại lấn át bằng chứng thực nghiệm cũng từng lặp lại với TDD, hệ thống kiểu, tách biệt tổ chức test·phát triển, CI/CD và DevOps
- Thay vì dựa vào những câu chuyện kiểu “lần này nó hiệu quả với tôi”, cần tiến hành nghiên cứu thực sự theo đúng cách mà nền tảng thực nghiệm của code review đã được xây dựng
- Nếu muốn xem công cụ lập trình LLM là công cụ phát triển chuyên nghiệp, cần kiểm chứng hiệu quả và giới hạn của nó dựa trên ergonomics và bằng chứng thực nghiệm
1 bình luận
Các ý kiến trên Lobste.rs
Tốc độ không nhất thiết phải là mục tiêu duy nhất. Có thể tách việc sửa lỗi thành các commit chuẩn bị riêng để review độc lập, chỉnh lại cấu trúc kiểu dữ liệu có thể biểu diễn trạng thái sai, và nếu độ tin cậy của kiểm thử chưa đủ thì thử nghiệm kiểm thử dựa trên thuộc tính, fuzzing, các phương pháp hình thức
Trước đây, những việc này thường bị nhồi vào một commit hoặc để lại thành TODO nợ kỹ thuật, nhưng nay chi phí biên để làm cho đúng đã thấp đến mức đáng kinh ngạc. LLM là công cụ có tính mở, nên nó trả lại giá trị tương ứng với những gì người dùng coi trọng
Dù vậy, cũng có rủi ro là số nguyên mẫu không hoàn thiện và không bao giờ tới production sẽ tăng lên; nhưng nhìn chung, nó giúp ích rất nhiều cho kiểu kỹ thuật coi trọng tính nghiêm ngặt
Có thể đó là vấn đề văn hóa công ty, nhưng thật đáng thất vọng; mong ngành này tỉnh táo lại và tạo ra phần mềm chất lượng cao hơn
Nếu đưa agent vào các dự án cũ bằng một prompt duy nhất, nó vẫn liên tục tìm ra lỗi thật mà không cần nhiều công sức. Con người cũng cẩu thả và bản thân tôi cũng mắc lỗi, nhưng LLM vừa nhanh vừa ngu ngơ hơn ở nhiều khía cạnh, nên vấn đề lộ ra sớm hơn mà thôi
Lỗi sẽ tích tụ, nên nếu để agent tự ý sửa code thì mọi thứ sẽ hỏng rất nhanh; nhưng kết luận rằng bản thân công cụ vô dụng chỉ vì cách dùng ngây thơ không ổn định cũng là một phán đoán lười biếng
Hiện tôi tự động chạy 5 lượt review chuyên sâu cho mỗi thay đổi, bao gồm kiến trúc, khả năng bảo trì, độ tin cậy, bảo mật, v.v., đồng thời sắp xếp bằng hệ thống tài liệu thiết kế để cải thiện đáng kể quyết định của agent. Chưa hoàn hảo, nhưng tốt hơn cách làm ngây thơ; và việc vẫn còn nhiều chỗ để cải thiện cũng là điểm thú vị khi làm việc với một công cụ mới
Dù tạo nhanh hơn bằng prompt, việc kiểm chứng và hiểu lại tốn thêm thời gian, khiến tôi tự hỏi liệu viết trực tiếp từ đầu có nhanh hơn không. Bản thân việc quyết định bên nào tốt hơn cũng tốn thời gian và năng lượng, và tôi muốn dùng nguồn lực đó vào việc khác
Tuy nhiên, nếu người gửi PR chịu quyền sở hữu và trách nhiệm, thì việc có dùng LLM hay không không quan trọng. Nếu đáp ứng các tiêu chuẩn về chất lượng, độ chính xác và tính nhất quán, cứ chọn cách nhanh hơn; trách nhiệm vẫn nằm ở tác giả là con người
Cá nhân tôi thấy AI tốt cho việc học và mở rộng, đào sâu hiểu biết, nhưng nếu tính cả toàn bộ quy trình chứ không chỉ thời gian nhập liệu, hiện viết code trực tiếp vẫn năng suất hơn
Vấn đề bắt đầu từ chỗ bài viết đã được viết gần 1 năm trước. Trong 6 tháng gần đây, đặc biệt là 3 tháng gần đây, mức hữu dụng của các model cloud trả phí mới nhất đã tăng lên đáng kể
Cần kiểm tra xem có các cơ chế kiểm soát chặn được cả một nhóm lỗi hay không, giống như nguyên tắc MFIC được phát triển trong công việc audit: https://gist.github.com/pmarreck/b30aa3ca69cb70a5526f8a63ab8c8d7e
Cũng cần các công cụ như https://github.com/pmarreck/dirtree và https://github.com/pmarreck/codescan để giữ code hiện có và cấu trúc dự án trong ngữ cảnh; chúng cũng hữu ích cho lập trình viên con người đã quên codebase hoặc chưa quen với nó
Rốt cuộc, hoặc là tận dụng đúng cách để hưởng lợi, hoặc tự viết code tùy chỉnh trong khi cũng tạo ra bug và lỗ hổng bảo mật rồi bị đối thủ nhanh hơn vượt qua. Từ trải nghiệm từng bỏ 2 năm-người vào codebase Ruby on Rails cỡ một triệu dòng đã bị khai tử của Desk.com, code doanh nghiệp có tính tạm thời, nên khá hợp với code do LLM sinh ra
Nếu là phần triển khai nội bộ của Erlang thì khó tin tưởng, nhưng vẫn có thể để nó viết theo đơn vị hàm rồi review; đôi khi kết quả còn tốt hơn mong đợi. Lý tưởng là dùng cả kim đan lẫn máy dệt tùy tình huống, thay vì chỉ chọn một
Dựa trên trải nghiệm cá nhân và các lập trình viên dày dạn đáng tin quanh tôi, LLM đã nhiều lần giúp code tốt hơn và nhanh hơn, nên tôi khó nghiêm túc tiếp nhận một bài viết nói rằng bằng chứng khoa học cho thấy nó không thể hữu ích
Dù không có bài báo bình duyệt, tôi đã thấy đủ rồi; và chỉ một nghiên cứu của METR phản bác ước tính tăng năng suất của các lập trình viên thì cũng không khiến tôi thay đổi đánh giá hiện tại
Tôi sẵn sàng đổi ý nếu được chỉ ra một cách nghiêm ngặt và hợp lệ về mặt phương pháp rằng điều này khác với các nghiên cứu thực nghiệm vững chắc hiện có ở đâu. Nhưng trải nghiệm cá nhân hay một tá giai thoại không có giải thích thì chưa đủ
Khoa học và kỹ thuật đã cải thiện cuộc sống của hàng tỷ người, và không thể vứt bỏ chúng chỉ vì ai đó tin rằng mình giỏi hơn
Tôi không có ý gọi cá nhân nào là tín đồ tà giáo, nhưng thái độ xem thách thức đối với niềm tin như chuyện cá nhân trong khi lại không biết cách thuyết phục người khác thì giống cách giao tiếp của một nhóm tà giáo
Ngay cả PR phần lớn do LLM tạo, người gửi vẫn phải chịu trách nhiệm và phải chia nhỏ theo ngữ cảnh và kích thước để người khác dễ hiểu. Code vẫn là đặc tả cuối cùng của phần mềm, và sự thật rằng lập trình viên phải sở hữu và hiểu nó không hề thay đổi
Lập luận rằng agent AI một năm trước mắc nhiều lỗi là đúng, nhưng không rõ hiện nay còn vậy không; vào khoảng tháng 11 năm ngoái, tôi cảm nhận được điểm ngoặt của các model tuyến đầu
Đúng là LLM làm tăng lượng code và tạo áp lực mới lên năng lực review, nhưng kỹ sư phải hãm lại và bảo đảm khối lượng review phù hợp với năng lực xử lý thực tế
Tệ hơn là code mới thường chạy được, nên có khả năng cao bị merge mà không được dọn dẹp
Tôi thấy lạ là dù các model tuyến đầu viết ra lượng code khổng lồ, người ta lại không nghiêm túc khám phá đóng góp âm dưới dạng đề xuất xóa code. Như “The Best Code is No Code At All” - Jeff Atwood, nếu chúng có thể gỡ rối độ phức tạp của codebase phình to bởi các tầng trừu tượng và đề xuất xóa dòng thì sẽ rất mới mẻ
Có thể điều đó đã làm được rồi, nhưng tôi chưa tận mắt thấy
Đính chính: mục “The Limits Of Reviews” đưa ra tốc độ tối đa hiệu quả là 400 dòng mỗi giờ, chứ không phải 400 dòng mỗi lần review như tôi nghĩ ban đầu
Tuy vậy, tôi vẫn tò mò con số 1 giờ và 400 dòng chính xác đến từ bài báo nào về code review. Nếu bạn không lưu riêng tên bài thì không cần tốn nhiều thời gian tìm lại
Hiện tôi đang đi du lịch, nên vài ngày nữa hãy nhắc lại
Nếu review chiếm 25% trong tuần làm việc 40 giờ thì khoảng 540 dòng/giờ; nếu 15% thì 900 dòng/giờ; nếu 5% thì 2.700 dòng/giờ. Lưu lượng thực tế ước khoảng 500–1.000 dòng mỗi giờ, cũng khá gần với con số chưa có nguồn được nêu
Tôi khó hiểu logic rằng code do AI tạo ra cần được review nhiều hơn hoặc ít hơn code do con người viết. Vì tiêu chuẩn phê duyệt là như nhau, nên review ở cùng một mức độ