Mười hai cách đánh giá sai về lập trình có trợ lý AI

 (third-bit.com)
9 điểm bởi GN⁺ 2 giờ trước | 1 bình luận | Chia sẻ qua WhatsApp
  • Giá trị của lập trình có trợ lý AI khó có thể quy về những con số dễ đo như số dòng mã, số ticket hay mức độ hài lòng, và kết luận có thể bị méo mó tùy theo cách đánh giá
  • Số dòng mã cùng số commit, Pull Request và ticket chỉ là thước đo mức độ hoạt động; một khi trở thành mục tiêu thì chúng rất dễ bị thao túng và không phản ánh được chất lượng
  • Tỷ lệ chấp nhận và tỷ lệ áp dụng chỉ là tín hiệu cho thấy đề xuất có vẻ hợp lý hoặc công cụ đã được triển khai, chứ không đảm bảo tính chính xác, bảo mật hay khả năng bảo trì
  • Bài tập đồ chơi, so sánh trước-sau không có nhóm đối chứng, so sánh người dùng tự nguyện và đường cơ sở yếu khiến rất khó tách riêng hiệu ứng của LLM với thiên lệch chọn mẫu
  • Để đánh giá năng suất cần có chỉ số ở cấp độ hệ thống bao gồm review, gỡ lỗi, bảo mật, nợ kỹ thuật, điểm nghẽn của nhóm và thay đổi dài hạn

Đối tượng đánh giá và tiền đề

  • Khi cố chứng minh giá trị so với chi phí thuê bao của công cụ lập trình có trợ lý AI, các chỉ số như số dòng mã được sinh ra, số ticket hoàn thành và khảo sát mức độ hài lòng của lập trình viên đều có thể dẫn đến kết luận sai theo những cách khác nhau
  • Điểm mấu chốt không phải là giá trị tự thân của lập trình có trợ lý LLM, mà là cách đánh giá hiệu quả của nó có thể dễ dàng đi chệch hướng đến mức nào
  • Cùng một kiểu phê bình này cũng có thể áp dụng, chỉ cần thay đổi đôi chút, cho các tuyên bố về phát triển agile, phát triển hướng kiểm thử và các thực hành phát triển phần mềm khác
  • Điều này dẫn đến kết luận rằng nếu kỹ nghệ phần mềm tiếp thu nghiêm túc hơn các phương pháp nghiên cứu từ khoa học con người, thì lĩnh vực này đã có thể đi xa hơn nhiều trong việc nghiên cứu những hiện tượng như vậy

Những chỉ số năng suất sai lầm

  • Đếm số dòng mã được tạo ra

    • Số dòng mã từ lâu đã được dùng như một chỉ số thay thế cho năng suất, vốn rất khó đo trực tiếp
    • LLM có thể tạo ra nhiều mã hơn, nhưng không đảm bảo kết quả tốt hơn
    • Một nhóm có số dòng mã trên mỗi lập trình viên tăng 40% sau khi áp dụng LLM có thể đang đo sự dài dòng, chứ không phải năng suất
    • Việc thay 2000 dòng logic rối rắm bằng 200 dòng sạch sẽ lại có thể trông như một sự thua lỗ nếu nhìn bằng chỉ số số dòng mã
    • Nhiều mã hơn đồng nghĩa với nhiều thứ hơn phải đọc, bảo trì và gỡ lỗi, và gánh nặng trong tương lai mà AI để lại không hiện ra trong phép đếm số dòng

  • Đếm commit, Pull Request và ticket

    • Năm 2023, McKinsey đề xuất cách đo năng suất lập trình viên cá nhân bằng số lượng hoạt động như commit, Pull Request và code review
    • Theo định luật Goodhart, khi một thước đo trở thành mục tiêu thì nó không còn là thước đo tốt nữa
    • Nếu số commit bị theo dõi, lập trình viên sẽ tạo ra nhiều commit nhỏ hơn; nếu số ticket bị theo dõi, ticket sẽ bị chia nhỏ
    • Các con số có thể đẹp hơn nhưng công việc nền tảng có thể không hề được cải thiện
    • Hoạt động không phải là đầu ra, và đầu ra cũng không tự động trở thành giá trị

  • Xem tỷ lệ chấp nhận đề xuất như tín hiệu chất lượng

    • Tỷ lệ chấp nhận đề xuất cao của các trợ lý lập trình LLM thường được đưa ra làm bằng chứng rằng công cụ hữu ích
    • Tỷ lệ chấp nhận chỉ đo việc mã được sinh ra có trông đủ hợp lý để lập trình viên nhấn Tab hay không, chứ không đo tính chính xác, bảo mật hay khả năng bảo trì
    • Lập trình viên chịu áp lực thời gian sẽ chấp nhận nhiều đề xuất hơn, trong đó có cả những đề xuất không an toàn
    • Một nghiên cứu doanh nghiệp với 400 lập trình viên ghi nhận tỷ lệ chấp nhận trung bình 33% và mức hài lòng cao của lập trình viên, nhưng không theo dõi độ chính xác hay độ an toàn của đoạn mã được chấp nhận
    • Một chỉ số thưởng cho thứ trông có vẻ hợp lý không phải là chỉ số thưởng cho thứ thực sự tốt

  • Xem tỷ lệ áp dụng như chỉ số thành công

    • Câu kiểu “đạt tỷ lệ áp dụng công cụ AI 90% trên toàn bộ tổ chức kỹ thuật” là thành tích mua sắm và triển khai, không phải thành tích về năng suất
    • Tỷ lệ áp dụng chỉ đo việc công cụ đã được cài đặt và mở lên hay chưa; nó không cho biết đề xuất có hữu ích không, lập trình viên có chấp nhận vô điều kiện hay không, hoặc các đề xuất được chấp nhận có đúng không
    • Khi tỷ lệ áp dụng cao đi kèm chất lượng đề xuất thấp, lập trình viên có thể phải dành thời gian quản lý công cụ thay vì nhận được lợi ích
    • Trong nghiên cứu về trợ lý lập trình AI doanh nghiệp của IBM, công cụ này thường tạo ra mức tăng năng suất ròng, nhưng lợi ích đó không đồng đều trên toàn bộ người dùng
    • Tỷ lệ áp dụng dễ đo hơn lợi ích, và chính vì thế mà nó dễ được báo cáo hơn

Sai sót trong thiết kế thí nghiệm

  • Bấm giờ các bài tập nhân tạo

    • Nghiên cứu GitHub Copilot được trích dẫn rộng rãi cho thấy người dùng hoàn thành bài tập nhanh hơn 55% so với người không dùng
    • Bài tập là triển khai một máy chủ HTTP bằng JavaScript từ đầu, thời gian giới hạn là 90 phút và các lập trình viên không có nghĩa vụ nào khác trong ngày hôm đó
    • Việc phát triển phần mềm thực tế bao gồm điều hướng trong một codebase lớn mà mình không viết, hiểu các yêu cầu ticket còn mơ hồ, phối hợp với đồng nghiệp và tham gia họp
    • Tốc độ trong bài tập đồ chơi kiểu greenfield không dự đoán được tốc độ trong những công việc thực tế này
    • Trong một thử nghiệm đối chứng ngẫu nhiên với các lập trình viên mã nguồn mở có kinh nghiệm, trái với kỳ vọng của người tham gia, việc cấp quyền truy cập công cụ AI lại làm thời gian hoàn thành nhiệm vụ tăng 19%

  • So sánh trước-sau không có nhóm đối chứng

    • Nếu bắt đầu dùng LLM vào tháng 1 và đến tháng 6 Pull Request được triển khai nhanh hơn, có thể trông như công cụ đã tạo ra hiệu quả
    • Nhưng nếu trong cùng khoảng thời gian đó công ty tuyển thêm 12 kỹ sư, tái cấu trúc pipeline CI và đổi nhà cung cấp cloud, thì không thể tách riêng nguyên nhân
    • Nếu không có một nhóm không áp dụng công cụ, rất khó phân biệt tác động của LLM với tác động của các thay đổi khác diễn ra cùng lúc
    • Tính hợp lệ nội tại đòi hỏi một phản thực đáng tin cậy cho biết điều gì sẽ xảy ra nếu không có công cụ

  • So sánh người dùng và người không dùng

    • Nếu so sánh các lập trình viên chọn dùng LLM với những người không chọn dùng, ta đang so sánh hai nhóm người khác nhau chứ không phải hai điều kiện
    • Những người áp dụng sớm thường sẵn sàng thử nghiệm hơn, quen với công cụ mới hơn và có khả năng đã là người có hiệu suất cao hơn so với người áp dụng muộn hoặc không áp dụng
    • Vì thiên lệch chọn mẫu, khác biệt quan sát được có thể là thuộc tính của con người chứ không phải thuộc tính của công cụ
    • Đây là cách làm có chi phí triển khai thấp nhất nên trở thành lỗi thiết kế phổ biến trong các báo cáo năng suất AI của ngành
    • Một nghiên cứu dọc theo dõi việc dùng Copilot trong 2 năm tại một tổ chức CNTT lớn cho thấy người dùng vốn đã hoạt động tích cực hơn người không dùng ngay từ trước khi áp dụng công cụ

  • So sánh AI với ‘không có gì cả’

    • Nếu đem lập trình viên có trợ lý AI so với nhóm đối chứng không dùng bất kỳ công cụ nào, ta đã chọn một đường cơ sở vốn không tồn tại trong công việc thực tế
    • Ngay cả lập trình viên không có trợ lý LLM vẫn dùng tài liệu, đồng nghiệp và thời gian tự suy nghĩ để giải quyết vấn đề
    • Câu hỏi quan trọng là công cụ LLM có tốt hơn các lựa chọn mà lập trình viên đã có hay không, nhưng kiểu so sánh này hiếm khi được thực hiện
    • Khi chọn đường cơ sở yếu, công cụ nào cũng có vẻ tốt, nhưng điều đó không đồng nghĩa với tính hữu ích thực sự

Những phần bị bỏ sót trong phạm vi đo lường

  • Chỉ đo một nửa dễ đo

    • LLM giúp việc sinh mã nhanh hơn, và phần này thì dễ đo
    • Nửa khó hơn là thời gian review mã do LLM sinh ra, thời gian gỡ lỗi bị mất vì các đề xuất sai nhưng đầy tự tin, các lỗ hổng bảo mật do mã có vẻ hợp lý nhưng không an toàn tạo ra, và nợ kỹ thuật do các cách giải quyết chắp vá phớt lờ thiết kế xung quanh
    • Trong nghiên cứu về mã của GitHub Copilot, một phần đáng kể mã được sinh ra có chứa lỗ hổng bảo mật, và các lập trình viên chịu áp lực thời gian chấp nhận đề xuất không an toàn với tỷ lệ cao hơn
    • Trong đánh giá năm 2025 với 5 LLM lớn, không mô hình nào tạo được mã ứng dụng web đáp ứng các tiêu chuẩn bảo mật công nghiệp
    • Một phân tích quy mô lớn trên hơn 300.000 commit do AI viết cho thấy hơn 15% đã đưa vào ít nhất một vấn đề chất lượng, và gần một phần tư trong số đó tồn tại lâu dài trong codebase
    • Nếu chỉ đo phần đầu vào tăng thêm mà bỏ qua chi phí tăng theo, đó không phải là đo lường mà là marketing

  • Cần đo hệ thống chứ không chỉ cá nhân

    • Tốc độ viết mã của cá nhân là thứ dễ đo nhất nên thường được đem ra đo
    • Dù công cụ AI có thể giúp lập trình viên viết mã nhanh hơn 30%, nếu lead time từ ticket đến production của cả nhóm không đổi thì điểm nghẽn không nằm ở việc viết mã
    • Khi mã được sinh ra nhiều hơn thì lượng mã cần review cũng tăng; nếu AI chỉ làm tăng lượng mã mà không tăng năng lực review, cycle time có thể xấu đi
    • Nghiên cứu thực nghiệm với các lập trình viên chuyên nghiệp cho thấy công cụ AI giúp tăng đầu ra của những người đóng góp ít kinh nghiệm hơn, nhưng với các lập trình viên senior, gánh nặng review do mã AI sinh ra tăng 6,5% đã làm năng suất của họ giảm 19%
    • Tối ưu hóa chỉ một công đoạn của pipeline và phớt lờ phần còn lại là một thất bại trong tư duy hệ thống, dù bề ngoài có thể trông như nghiên cứu năng suất

Hiệu ứng bị bóp méo theo thời gian

  • Hỏi lập trình viên xem năng suất có tăng không

    • Những kết quả khảo sát như “87% lập trình viên cảm thấy mình năng suất hơn với công cụ AI” thường được trích dẫn như bằng chứng rằng công cụ hoạt động hiệu quả
    • Tự báo cáo có thể tạo ra hiểu lầm mang tính hệ thống vì ba lý do
    • Do hiệu ứng Hawthorne, con người sẽ làm việc khác đi khi biết rằng mình đang bị quan sát hoặc đánh giá
    • Công cụ mới tạo ra hiệu ứng mới lạ, khiến người ta cảm thấy nhanh hơn chỉ vì nó mới, và cảm giác này thường biến mất sau vài tuần
    • Do thiên lệch mong muốn xã hội, người trả lời có xu hướng đưa ra câu trả lời mà họ tin rằng khảo sát muốn nghe, đặc biệt khi ban lãnh đạo là người chọn công cụ

  • Chỉ đo trong giai đoạn hiệu ứng mới lạ

    • Nếu một nghiên cứu kéo dài 4 tuần tìm thấy mức tăng năng suất, thì điều nó tìm thấy chỉ là mức tăng năng suất trong 4 tuần
    • Trong giai đoạn đầu, lập trình viên tập trung hơn vào công cụ mới nên kết quả quan sát được có thể bị thổi phồng so với đường cơ sở dài hạn
    • Những hiệu ứng thực sự quan trọng xuất hiện trong nhiều tháng chứ không phải vài tuần
    • Sự mai một kỹ năng trong các công việc giao cho AI, nợ kỹ thuật tích lũy từ các đề xuất sai và thay đổi trong cách cộng tác của cả nhóm đều cần quan sát dài hạn
    • Những nghiên cứu được thiết kế để phát hiện lợi ích ngắn hạn sẽ không cho biết điều gì xảy ra sau khi nghiên cứu kết thúc
    • Phân tích 807 kho mã nguồn mở áp dụng Cursor cho thấy tốc độ phát triển tăng mạnh nhưng tạm thời sau khi áp dụng, trong khi độ phức tạp mã và các cảnh báo phân tích tĩnh tăng đáng kể và kéo dài

Kết luận để diễn giải tốt hơn

  • Đo lường năng suất rất khó quy về một con số đơn lẻ hay một chỉ số thay thế dễ lấy
  • Để đánh giá tác động của lập trình có trợ lý LLM, cần xem không chỉ tốc độ viết mã mà còn cả review, gỡ lỗi, bảo mật, bảo trì, nợ kỹ thuật, điểm nghẽn của nhóm và các thay đổi dài hạn
  • Nếu không có nhóm đối chứng, đường cơ sở thực tế, kiểm soát thiên lệch chọn mẫu, quan sát dài hạn và chỉ số ở cấp độ hệ thống, sẽ rất khó phân biệt tác động của công cụ AI với tác động của các thay đổi khác
  • Những giá trị dễ đo thì dễ được báo cáo, nhưng giá trị dễ đo không thể thay thế cho giá trị quan trọng
  • Để đánh giá các thực hành phát triển phần mềm, cần nghiêm túc tiếp nhận hơn các phương pháp nghiên cứu từ khoa học con người

Tài liệu chính được trích dẫn

Bài viết liên quan

1 bình luận

 
GN⁺ 2 giờ trước
Ý kiến trên Lobste.rs

  • Tác giả là một trong những người sáng lập Software Carpentry, nên là người đã suy nghĩ về cách đo lường năng suất phần mềm tốt hơn từ rất lâu trước khi LLM xuất hiện
    Nghiên cứu METR được trích dẫn thú vị hơn những lý do thường thấy. Với nhiều người, dòng tít là “AI khiến con người làm chậm hơn”, và điều này có thể bị phản bác bằng lập luận kiểu LLM năm 2025 vẫn đang tiếp tục cải thiện
    Nhưng kết quả còn thú vị hơn là, các ước lượng họ tự đưa ra sau đó thậm chí còn không đúng cả về chiều hướng so với thực tế. Có vẻ ở đây tồn tại một yếu tố mà hầu hết các công ty đều phớt lờ, thứ tạo ra khó khăn mang tính nền tảng cho mọi phép đo
    Ngay cả cảm giác mơ hồ rằng công cụ làm con người năng suất hơn cũng không đáng tin. Con người tự họ không biết
    Nghiên cứu tiếp theo về cơ bản đã thất bại vì thiên lệch chọn mẫu

    The primary reason is that we have observed a significant increase in developers choosing not to participate in the study because they do not wish to work without AI
    Việc các lập trình viên từ chối làm việc nếu không có AI có thể có nghĩa là công cụ hoạt động tốt, hoặc cũng có thể có nghĩa là họ ngày càng phụ thuộc vào công cụ đến mức khả năng làm các tác vụ khó hơn đã thoái hóa hoàn toàn

    • Giả thuyết của tôi là mọi người có xu hướng dựa vào LLM nhiều hơn cho những phần họ thực sự không muốn làm, và khi làm việc mình không thích thì thời gian lúc nào cũng có cảm giác trôi chậm hơn rất nhiều

  • Câu “công cụ mới cho cảm giác nhanh hơn chỉ vì nó mới, và cảm giác đó thường biến mất trong vài tuần” có vẻ là ngược lại
    Công cụ mới luôn làm tôi chậm đi vì tôi chưa quen với nó. Tất nhiên vẫn nhìn thấy tiềm năng để nhanh hơn, nhưng là vì tôi chưa biết dùng nó hiệu quả

    • Còn có một hiệu ứng liên quan khác. Đặc biệt là những người tự nguyện thử công cụ mới thường rất nhiệt tình, nên họ còn làm thêm ngoài giờ để bù vào những thiếu sót của nó
      Trong một thời gian thì trông rất ấn tượng, nhưng cuối cùng nó tự nhiên biến mất khi họ quay lại cách làm việc bình thường

  • Đo lường là việc khó. Ở một góc độ nào đó, bản thân việc cố đo lường lập trình có hỗ trợ AI có thể đã là một sai lầm
    Có những tác vụ rõ ràng sẽ được làm nhanh hơn, và gần như chắc chắn cũng có những cách dùng giúp nó nhanh hơn
    Câu hỏi quan trọng hơn là những cách đó là gì, và ta đánh mất điều gì trong quá trình ấy

    • Năng suất và việc tăng tốc độ làm việc không phải là một. Dù một tác vụ được làm nhanh hơn, nếu đó không phải nút thắt cổ chai hoặc việc tăng tốc đi kèm chi phí, thì có thể nó chẳng mang lại tác động tích cực nào cho năng suất
      Bài gốc cũng gọi đây là “chỉ đo nửa dễ đo”

  • Với câu hỏi “nếu tuần sau quản lý yêu cầu bạn chứng minh công cụ AI coding mà công ty đã mua đáng giá bằng đúng phí thuê bao, bạn sẽ đo số dòng mã được tạo ra hay số ticket đã đóng?”, thì Claude đã đo số dòng mã, tỷ lệ chấp nhận và lượng token sử dụng ngay trong lịch sử thanh toán
    Số ticket đã đóng sẽ là tốc độ của cả nhóm, trong đó đầu ra từ AI chỉ là một yếu tố, còn Jira thì đo velocity của sprint
    Dù sao thì câu hỏi này rất dễ bị thao túng tùy theo việc bạn nghĩ đầu ra mà quản lý muốn là gì, và có lẽ điều đó đã và đang xảy ra rồi

  • Có vẻ tác giả đã bỏ sót một câu hỏi cực kỳ quan trọng: “Việc dùng AI gây ra những thiệt hại gì?”
    Tôi cho rằng đây là câu hỏi nền tảng hơn bất kỳ câu hỏi nào khác. Vì thiệt hại dễ đo hơn nhiều. Chỉ cần dựng một Git forge rồi nhìn các crawler lao vào như cá mập ngửi thấy máu là đủ
    Việc scraper DDoS toàn bộ Internet là một vấn đề có thể đo được, và với những ai tự host thì đó là thực tế ai cũng tự cảm nhận được
    Liệu những lợi ích được cho là của AI, vốn ta còn khó mà đo cho ra hồn, có đáng để chấp nhận những thiệt hại rất thực mà crawler gây ra hay không?
    Nếu cộng thêm năng lượng tiêu tốn để vận hành crawler và xử lý các request đó, chi phí huấn luyện, chi phí suy luận, và nhu cầu về các trung tâm dữ liệu ngày càng lớn thì sao?
    Tôi nghĩ câu hỏi quan trọng hơn nhiều là liệu những lợi ích được cho là đó của AI có đáng để đánh đổi tất cả những điều này hay không

    • Điều luôn khiến tôi bực mình ở kiểu vấn đề “chúng ta nên nói về X” này là, trong các bài viết về tác hại sinh thái, tôi lại thấy đúng luận điểm ngược lại
      Kiểu như “kể cả nếu mấy thứ này không tiêu tốn năng lượng thì chúng vẫn tạo ra mã tệ, nên nói về điều đó còn quan trọng hơn nhiều”, hoặc “sao lại nói về coding, tác hại thật sự là việc nó được dùng để giám sát”, rồi câu chuyện cứ tiếp tục bị chuyển hướng