- Đã tiến hành một thử nghiệm đối chứng ngẫu nhiên về tác động của các công cụ AI đầu năm 2025 đối với năng suất thực tế của các lập trình viên mã nguồn mở
- Kết quả nghiên cứu cho thấy, khi dùng công cụ AI, thời gian hoàn thành công việc trung bình lâu hơn 19%
- Các lập trình viên kỳ vọng AI sẽ giúp họ nhanh hơn 24%, nhưng trái với cảm nhận thực tế, hiện tượng chậm đi đã xảy ra
- Khoảng cách giữa năng lực AI thể hiện trong benchmark và trải nghiệm hằng ngày với hiệu quả thực tế là rất rõ rệt
- Nghiên cứu nhấn mạnh tầm quan trọng của việc hiểu chính xác tác động năng suất của AI và các phương pháp đánh giá đa dạng
Tổng quan
- Nghiên cứu này thực hiện thử nghiệm đối chứng ngẫu nhiên (RCT) để xác định tác động của các công cụ AI đầu năm 2025 (Early-2025) lên năng suất của các lập trình viên mã nguồn mở giàu kinh nghiệm
- Trái với kỳ vọng, kết quả xác nhận rằng khi dùng công cụ AI, các lập trình viên mất nhiều thời gian hơn 19%
- Kết quả này có thể được hiểu như một ví dụ về việc đo lường tác động thực tế của tự động hóa nghiên cứu bằng AI đối với phát triển phần mềm
- Dựa trên phương pháp luận này, nhóm nghiên cứu cho biết họ có kế hoạch tiếp tục ước lượng tác động thực tế của việc tăng tốc R&D bằng AI
Động cơ nghiên cứu
- Các benchmark coding/agent hiện có có giới hạn là không phản ánh đầy đủ tình huống công việc thực tế
- Do cấu trúc như bài kiểm tra khép kín, tác vụ đơn lẻ thiếu ngữ cảnh, và chấm điểm tự động, chúng có thể đánh giá quá cao năng lực của AI
- Ngược lại, khi không có sự can thiệp thích ứng của con người, cũng có khả năng đánh giá thấp hiệu năng thực tế của mô hình AI
- Để bù đắp những hạn chế này, nghiên cứu đã đo tác động thực tế của AI bằng cách thử nghiệm ảnh hưởng của nó đến năng suất của các lập trình viên mã nguồn mở trong thực tế
Phương pháp thí nghiệm
- Tuyển chọn 16 lập trình viên kỳ cựu trong mã nguồn mở, rồi chọn 246 issue thực tế trong các kho mã lớn mà mỗi người đã hoạt động nhiều năm (trung bình hơn 22 nghìn sao, hơn 1 triệu dòng mã)
- Với mỗi issue, họ được phân ngẫu nhiên vào nhóm được phép hoặc bị cấm dùng AI
- Khi được phép dùng AI, lập trình viên có thể tự do sử dụng Cursor Pro và các mô hình mới nhất như Claude 3.5/3.7 Sonnet; khi bị cấm, họ làm việc mà không có hỗ trợ từ AI tạo sinh
- Người tham gia ghi lại quá trình giải quyết từng issue (trung bình mất 2 giờ) và tự báo cáo thời gian đã sử dụng
- Người tham gia thí nghiệm được trả 150 USD mỗi giờ
Kết quả chính
- Khi dùng công cụ AI, thời gian giải quyết issue trung bình dài hơn 19%
- Các lập trình viên kỳ vọng AI thực sự sẽ nâng năng suất lên 24%, và ngay cả sau thí nghiệm họ vẫn trả lời rằng mình cảm nhận được mức tăng tốc 20%
- Như vậy, đã xuất hiện khoảng cách lớn giữa nhận thức và hiệu quả thực tế
- Để tránh những hiểu lầm cụ thể, nghiên cứu này không cung cấp bằng chứng cho các kết luận sau:
- Khái quát rằng AI làm chậm mọi lập trình viên hoặc toàn bộ hoạt động phát triển phần mềm
- Quy định hiệu quả của AI trong các lĩnh vực hay thiết lập khác
- Khẳng định rằng kết quả tương tự sẽ tiếp diễn trong tương lai gần
- Cho rằng không thể tối ưu các kỹ thuật LLM và prompt hiện có
Phân tích các yếu tố ảnh hưởng
- Nghiên cứu phân tích 20 yếu tố có thể giải thích sự chậm trễ trong công việc, và cho rằng 5 trong số đó thực sự có tác động
- Xác nhận rằng các biến số chính như điều kiện thí nghiệm, mô hình, độ khó của issue, chất lượng PR, v.v. không tạo ra ảnh hưởng có ý nghĩa lên kết quả thí nghiệm
- Hiện tượng chậm lại được quan sát nhất quán trên nhiều tập con dữ liệu và phương pháp ước lượng khác nhau
- Có thể xem nội dung phân tích chi tiết trong bài báo gốc
Diễn giải kết quả và thảo luận
Xung đột giữa các nguồn bằng chứng và nguyên nhân
- Sự khác biệt giữa điểm benchmark AI / báo cáo tình huống / thí nghiệm thực tế là rất rõ
- Benchmark đo năng lực AI chủ yếu trên các bài toán hẹp có thể chấm tự động
- SWE-Bench: PR mã nguồn mở dựa trên kiểm thử, RE-Bench: các bài toán có thể đánh giá bằng thuật toán
- Trong RCT thực tế, với các tác vụ phức tạp và sát thực tế mất từ 20 phút đến 4 giờ, con người ngược lại còn chậm hơn
- Trong khi đó, ở môi trường công nghiệp hay cộng đồng, có nhiều báo cáo định tính cho rằng AI rất hữu ích cho công việc kéo dài nhiều giờ
Khung diễn giải
- Mỗi cách tiếp cận đều có đặc tính đo lường “năng lực thực tế” theo cách khác nhau
- Cách tiếp cận theo từng trường hợp:
- Vấn đề đánh giá thấp trong RCT: có thể tồn tại tính đặc thù chỉ áp dụng cho thiết lập thí nghiệm của nghiên cứu này
- Khả năng benchmark/trường hợp điển hình đánh giá quá cao: độ lệch so với cách giải thực tế, độ tin cậy chưa cao của cơ sở tự báo cáo
- Cả ba cách đều có thể chỉ phù hợp với một số bài toán con nhất định của thực tế
- Khoảng cách giữa các nguồn khác nhau và năng lực thực tế có thể được diễn giải là lỗi đo lường/thiên lệch (màu đỏ), khác biệt về phạm vi đo lường (màu xanh dương)
Hàm ý bổ sung của thí nghiệm
- Kết quả RCT có thể không áp dụng cho môi trường lấy mẫu kết quả AI hàng trăm hoặc hàng nghìn lần
- Có khả năng chỉ sau khi dùng các công cụ AI như Cursor trong vài chục đến vài trăm giờ thì hiệu suất mới được cải thiện
- Trong môi trường đòi hỏi mã chất lượng cao và nhiều yêu cầu ngầm (tài liệu hóa, kiểm thử, định dạng, v.v.), năng lực của AI có thể bị giới hạn
- Do phạm vi bài toán hẹp, benchmark không phản ánh đúng độ khó của công việc thực tế
- Các báo cáo cảm nhận định tính có thể giảm độ tin cậy do hiệu ứng đánh giá quá cao và tự ảo tưởng
- Không có một phương pháp đánh giá đơn lẻ nào là hoàn hảo, nên cần sử dụng chúng theo hướng bổ sung lẫn nhau
Triển vọng sắp tới
- Nhóm nghiên cứu dự định tiếp tục cải thiện phương pháp này để theo dõi định lượng mức độ các công cụ AI thực sự thay đổi năng suất của lập trình viên
- Nếu các công cụ AI thực sự nâng mạnh hiệu suất của lập trình viên ngoài thực địa, thì nguy cơ tăng tốc đột ngột toàn bộ R&D AI / thất bại trong giám sát / tập trung quyền lực cũng có thể đồng thời xuất hiện
- Việc phát triển các khung đánh giá phù hợp với môi trường thực tế sẽ rất quan trọng đối với sự phát triển tương lai của AI và toàn bộ ngành công nghiệp
2 bình luận
150 đô một giờ à? Ngay từ đó thì việc kiểm soát biến đã buồn cười rồi ha ha ha ha
Ý kiến trên Hacker News
Bình luận của Simon Willison:
Toàn bộ bài báo có rất nhiều chi tiết bị lược khỏi phần tóm tắt liên kết bài báo
Theo cảm nhận cá nhân của tôi, để thực sự đạt được mức tăng năng suất từ các công cụ AI dựa trên LLM thì tồn tại một đường cong học tập dốc hơn rất nhiều so với điều mọi người tưởng
Nghiên cứu này có 16 người tham gia với mức độ kinh nghiệm khác nhau trong việc dùng các công cụ AI, và 56% là lần đầu dùng Cursor, nên về cơ bản đây chủ yếu là một nghiên cứu về Cursor
Mỗi người tham gia xử lý tổng cộng khoảng 15 issue, và với từng issue thì việc được phép hay không được phép dùng AI được gán ngẫu nhiên
Tức là cùng một lập trình viên sẽ làm xen kẽ các tác vụ có cho phép AI và không cho phép AI
Chỉ 1/4 số người tham gia cải thiện hiệu suất, còn 3/4 thì giảm hiệu suất
Nhóm dùng AI hiệu quả nhất là những người đã dùng Cursor hơn 50 giờ
Ngay cả nhóm nghiên cứu cũng thừa nhận rằng các lập trình viên có đủ kinh nghiệm với Cursor đã có cải thiện hiệu suất
Trực giác của tôi là bài báo này cho thấy vì đường cong học tập của phát triển cộng tác với AI rất cao, nên nếu trộn ngay vào quy trình làm việc hiện tại trong thực tế thì ngược lại còn làm giảm hiệu suất
Với LLM thường có phản ứng kiểu “là do bạn không biết dùng cho đúng”, nhưng điều đó nghe như một cái cớ đổ quá nhiều trách nhiệm cho người dùng
Với hầu hết sản phẩm công nghệ, nếu người dùng không cảm nhận được giá trị thì tôi nghĩ vấn đề nằm ở chính thiết kế của sản phẩm. Tôi thắc mắc vì sao logic này lại không được áp dụng cho AI
Cảm ơn Simon, và cảm ơn vì đã đọc bài báo rất kỹ - tôi là fan của các dự án OS nên muốn chỉ ra vài điểm quan trọng
1) Một số nghiên cứu trước đây cho thấy vẫn có cải thiện hiệu suất ngay cả khi ít kinh nghiệm với công cụ, nên chỉ riêng giả thuyết “đường cong học tập dốc” không thể giải thích hết kết quả lần này
2) Trước nghiên cứu, hơn 90% người tham gia đã có kinh nghiệm viết prompt cho LLM, và prompting được xem là kỹ năng chính. Quan điểm phổ biến là nếu đã quen dùng VSCode thì Cursor cũng dễ dùng
3) Nếu mọi người đều đã quen với AI thì khi không có AI họ có thể làm còn kém hơn bình thường (ít nhất tôi thấy điều này hợp lý), và như vậy lại tạo ra ảo giác rằng AI tốt hơn, tức là hiệu ứng này thực ra làm giảm điểm của AI
4) Thông tin về kinh nghiệm đã được chia sẻ trước với các chuyên gia dự đoán, vậy mà những người dự đoán vẫn đặt kỳ vọng tăng năng suất quá cao
5) Có thể thực sự tồn tại các kỹ năng thuộc “đuôi dài” hình thành sau hàng trăm giờ sử dụng, và nghiên cứu này khó có thể nói được tới mức đó
Vì bài báo đưa ra kết quả gây bất ngờ nên người đọc rất dễ chọn ra một yếu tố rồi kết luận “chính cái này là nguyên nhân!”
Trên thực tế có thể là do nhiều nguyên nhân kết hợp (ít nhất 5 và tối đa 9 nguyên nhân vẫn chưa thể loại trừ, xem bảng ở trang 11)
Một hàm ý cực kỳ quan trọng: mức độ hài lòng tự báo cáo của lập trình viên lệch rất xa thực tế, và điều này không phụ thuộc vào loại công cụ được dùng
Để đo năng suất thì dữ liệu thực tế tại hiện trường là bắt buộc (xem C.2.7 của bài báo: phần “Mức sử dụng công cụ AI dưới trung bình” nói khá chi tiết)
Có thể diễn giải kết quả này là dù 75% người tham gia đã có kinh nghiệm với LLM, họ vẫn làm chậm hơn khi dùng AI. Một cách hiểu là đường cong học LLM rất dốc, cách hiểu khác là hiệu quả hỗ trợ lập trình thực tế của LLM hiện nay đang bị đánh giá quá cao. Mọi người liên tục dự đoán sai về hiệu suất
Dù có trở nên giỏi dùng LLM hơn thì mức độ hiểu đoạn mã do chính mình viết ra cũng có thể giảm xuống
Lập trình viên sẽ ngày càng thông thạo code theo thời gian, còn LLM thì có thể ngược lại ngày càng kém hiệu quả hơn
Có thể tạo code rất nhanh bằng LLM, nhưng nếu không chú ý đủ thì bạn sẽ không tích lũy được độ thành thạo với chính code đó
Ban đầu việc phát triển có thể rất nhanh và nhẹ nhàng, nhưng phía sau lại là sự thiếu hiểu biết, còn LLM thì lúc đầu dùng được nhưng dần dần không cải thiện thêm, để rồi đến một lúc nào đó cả LLM lẫn người dùng đều không thể kiểm soát nổi mớ code hỗn loạn đó
Tôi nghĩ cần kiên trì quản lý để LLM sinh ra code gọn gàng hơn, đồng thời bản thân cũng phải thực sự học code. Cần có nỗ lực tự mình hiểu nó
Có thể thấy có người tăng năng suất nhờ công cụ AI, và cũng có người không
Tôi đoán rằng những người có thể đọc rất nhanh văn bản dài hoặc code dài sẽ có lợi thế đáng kể
Khả năng nhanh chóng nhận ra đề xuất vô dụng và lặp lại cho tới khi có được câu trả lời tốt là cực kỳ quan trọng
Khả năng quét đọc nhanh có tương quan với người có kinh nghiệm, nhưng điều bất ngờ là đôi khi cả người mới cũng có kỹ năng này rất tốt
Những người có kỹ năng tìm kiếm tốt có thể cũng thuận lợi hơn khi dùng LLM, theo nghĩa khá giống với kỹ năng Google
Điều này lại làm tôi nhớ đến quy luật 80/20 - AI giúp giải quyết 80% công việc trong 20% thời gian, rồi 20% còn lại lại ngốn 80% thời gian
Luôn có cảm giác “sắp xong rồi”, nên rất dễ rơi vào ngụy biện chi phí chìm
Cách tôi thử gần đây là dùng AI không phải như một “người giải quyết vấn đề” mà như một “công cụ giảm ma sát”
Tôi vẫn tự lập trình, chỉ hỏi AI những thứ nhỏ như cú pháp lặt vặt mình tạm quên để tăng tốc công việc
Tôi gần như không xem các đề xuất code toàn phần trực tiếp. Tôi luôn tự mình suy nghĩ khi viết code để tránh giảm mức độ hiểu và kỹ năng
Trước đây thì kiểu ngược Pareto: 80% công việc tốn 80% công sức, rồi 20% còn lại cũng lại ngốn thêm 80% công sức
Tôi đồng ý với cách dùng AI chỉ để giải quyết “các vật cản nhỏ”
Hôm qua tôi cũng vật lộn với
ConcurrentOperationsExceptionkhi xử lýListbằng Java stream APITôi tự viết method mà không xong, nên giao cho AI một “method chuyển đổi list an toàn luồng”, và nó chỉ ra rằng API đó đã có sẵn method tích hợp rồi
Với những vấn đề lặt vặt kiểu này thì AI là số một - khi vấn đề phức tạp nhưng được xác định rõ
Nó đặc biệt hữu ích khi dùng như một phiên bản mạnh hơn của Stack Overflow: khi tôi đại khái biết mình cần làm gì nhưng không rõ cụ thể phải làm sao cho hợp với môi trường của mình, và nó cũng giúp cho việc debug hay rubber ducking
“Dành 80% thời gian cho 20% cuối cùng” vốn đã là trải nghiệm của tôi từ trước cả khi có AI. Chỉ cần rút ngắn phần thời gian ban đầu là đã tốt rồi. Câu đánh giá hay nhất tôi từng nghe từ một người có kinh nghiệm về AI là: “90% kỹ năng của tôi trở nên vô giá trị, còn 10% còn lại thì trở nên quan trọng gấp nghìn lần.” Hơi cường điệu, nhưng tôi thích ý chính của nó
Chính ảo giác “lúc nào cũng gần xong rồi” lại gây lãng phí thời gian. AI rất giỏi trong việc khiến thứ gì đó trông có vẻ hữu ích, nên để phân biệt đó có phải là tăng năng suất thật hay không thì cần năng lực tư duy phản biện ở mức cao
Nó đặc biệt hữu ích khi thêm tính năng vào codebase hiện có, như kiểu “thêm
foongoài các tham số tìm kiếm hiện tại” hoặc “hãy bỏ phần code liên quan đếnx”Gửi tới người dùng HN, tôi là tác giả bài báo - tôi dùng HN đã lâu, và hôm nay nếu có câu hỏi/phản hồi trong phần bình luận thì tôi đang cố trả lời nhiều nhất có thể. Nếu không có thời gian đọc cả bài báo, tôi khuyên đọc bài blog giới thiệu hoặc chuỗi bài công bố trên x.com
Phương pháp luận của bài báo và cách tác giả trao đổi đều rất chuyên nghiệp và ấn tượng, đây là một nghiên cứu tốt
Tôi nghĩ đây là một trong những nghiên cứu tốt nhất vì nó trình bày kết quả một cách thẳng thắn, không giật tít câu kéo, và được tổ chức rất dễ đọc
Các bạn có cân nhắc xem những ticket đem xử lý bằng AI có thực sự là loại phù hợp với AI hay không? Kiểu “thử xử lý ticket này bằng AI đi” thì đúng là thực tế, nhưng cũng có thể kém hiệu quả. Nếu dùng đúng kiểu phù hợp cho AI thì nó thật sự rất có ích, nhưng trong nhiều trường hợp lại phản tác dụng. Nếu người tham gia có đủ kinh nghiệm với AI thì hẳn họ sẽ phân biệt được điều này, nhưng khi đọc bài báo tôi chưa thấy rõ điểm đó
Tôi muốn hỏi liệu có thể công bố bộ dữ liệu thô đã được ẩn danh, hoặc ít nhất bổ sung vào bài báo thời gian tuyệt đối cho từng lập trình viên theo từng tác vụ hay không. Tôi tò mò liệu người tham gia có nhiều kinh nghiệm với Cursor thực sự nhanh hơn người khác, hay vốn dĩ họ là người chậm hơn nên AI tạo hiệu ứng tăng lớn hơn cho họ. Rất vui khi được thấy một đánh giá thực nghiệm thực sự tốt, có tính đến cả Hawthorne effect (hiệu ứng bị quan sát)
(Tôi chưa đọc bài báo, chỉ xem bài đăng) Tôi tò mò liệu các bạn có đo chỉ số mệt mỏi chủ quan (subjective fatigue) như một yếu tố giải thích vì sao AI bị hiểu nhầm là nhanh hơn hay không. Sau khi chuyển từ lập trình viên sang quản lý, những lúc não mệt thì AI đem lại cảm giác dễ chịu hơn nên thích dùng
Kết quả nghiên cứu này, đặc biệt là chỗ “các lập trình viên kỳ vọng AI sẽ giúp tăng tốc 24%, nhưng trên thực tế lại chậm đi, dù sau khi trải nghiệm họ vẫn tin là mình đã nhanh hơn 20%”, thật sự rất thú vị. Vì sao khoảng cách giữa thực tế và nhận thức lại lớn đến mức kịch tính như vậy? Tôi tự hỏi liệu có phải não bộ đang nhầm “nỗ lực tinh thần” với trải nghiệm về thời gian hay không
Tôi không có bằng chứng, nhưng có một suy nghĩ đáng sợ: liệu khi code, tương tác với AI có kích thích não bộ theo kiểu giống vòng lặp dopamine của mạng xã hội không (dù mức độ có khác)? AI liên tục đưa ra câu trả lời khiến bộ não có cảm giác như đang được ghi nhận tích cực, và vì thế lập trình viên đánh giá AI tích cực hơn thực tế? Nếu điều này còn gây ra cả tính gây nghiện, thì chẳng phải nó sẽ khiến người ta phóng đại hiệu quả năng suất thực tế hay sao?
Hiện tượng này cũng có thể là kết quả của một chiến dịch quy mô lớn khiến rất nhiều người trên thị trường tin rằng các công cụ AI giỏi hơn thực tế. Nhóm chuyên gia kinh tế, chuyên gia ML lại chồng lấn với các bên có lợi ích gắn với công ty AI, và đội ngũ điều hành thì tin điều đó nguyên xi rồi hứa hẹn những thành quả lớn. Kết quả là mức kỳ vọng nền bị đẩy lên trên diện rộng, và điều đó ảnh hưởng cả tới các lập trình viên giàu kinh nghiệm. Rất khó chứng minh bằng thực nghiệm, nhưng đây có thể là lý do ảo giác tập thể về năng suất AI lan rộng như vậy
Tôi cũng tự hỏi liệu nhiều người nhiệt tình với AI trong phần bình luận HN có đang rơi vào hiện tượng này hay không. Thực sự nếu không tự đo hiệu suất của mình thì rất khó chắc rằng AI có thật sự đang nâng năng suất cá nhân hay không
Thỉnh thoảng tôi lại có trải nghiệm hoàn toàn ngược lại. Hôm nay tôi thử dùng Claude code để tạo code cho một ứng dụng demo mẫu, lúc ngồi xem thì trông rất ngầu và đậm chất khoa học viễn tưởng, nhưng chỉ sau 15 phút tôi đã thấy đầu óc mụ mị và chán ngấy
Khi nhìn vào câu “các lập trình viên kỳ vọng AI nhanh hơn 24%, và dù thực tế chậm hơn họ vẫn tin là nhanh hơn 20%”, tôi cảm thấy ở đây có hai vấn đề
Một là rất khó để cùng một người trong cùng một bối cảnh tự so sánh chính xác thời gian khi làm với AI và khi làm không có AI
Vấn đề còn lại là người ta rất dễ đo hiệu quả AI bằng các chỉ số bề mặt như thời gian mở/merge PR, nhưng trên thực tế khi đưa AI vào thì lại tốn thêm nhiều thời gian cho refactoring, testing, xử lý issue và các phần hậu kỳ khác
Chỉ nhìn vào việc “PR được mở nhanh hơn” thì rất dễ lầm tưởng AI nhanh hơn, nhưng lại dễ bỏ qua việc khối lượng công việc về sau tăng lên
Việc đo ảnh hưởng của một công nghệ hay thực hành nào đó tới năng suất thực sự rất khó. Tôi cho rằng chỉ dựa vào tự thuật (anecdote) để kết luận là nguy hiểm, vì ai cũng dễ rơi vào tự huyễn hoặc. Chính nghiên cứu cũng thừa nhận có giới hạn, nên khi bàn về năng suất cần luôn ý thức rằng sai số có thể rất lớn. AI là công nghệ kỳ lạ nhất tôi từng thấy trong đời, và việc cố đọc ra quan hệ nhân quả từ các mẩu chuyện lẻ tẻ hay benchmark đáng ngờ gần như giống bói toán
Trong bài báo, không quan sát thấy sự suy giảm chất lượng PR giữa điều kiện cho phép AI và không cho phép AI. Phần lớn người tham gia đều quen với tiêu chuẩn của repository và không phải kiểu “quăng tạm cho có PR”. Thời gian review trung vị của các PR trong nghiên cứu là khoảng 1 phút. Đúng như bạn nói, cách họ phân bổ thời gian đã thay đổi hoàn toàn. Ở trang 10 của bài báo có phân bố thời gian theo trường hợp dùng/không dùng AI: khi dùng AI thì thời gian code giảm, còn thời gian tương tác với AI tăng lên
Về ý “không thể biết chính xác chênh lệch thời gian khi cùng một người, trong cùng bối cảnh, làm với AI hoặc không có AI”, thì thiết kế thí nghiệm đã tách hiệu ứng của nhóm AI và nhóm không AI bằng random assignment. Khác biệt về cá nhân, tình huống, môi trường... được xử lý bù trừ nhờ ngẫu nhiên hóa. Nếu mẫu đủ lớn và hiệu ứng đủ mạnh thì vẫn có thể rút ra khác biệt có ý nghĩa thống kê
Xem Figure 21 thì ngay cả phần triển khai ban đầu (thời gian tới lúc tạo PR) cũng tăng lên, và dù sau khi review PR thời gian còn tăng thêm, tổng thể có vẻ không phải là yếu tố ảnh hưởng lớn. Như Figure 18 cho thấy, thời gian code thực tế có giảm, nhưng lợi ích đó bị bù trừ bởi thời gian viết prompt, chờ kết quả và rà soát đầu ra. Với các tác vụ đơn giản dưới 5 phút, có khi không dùng LLM lại còn tốt hơn
Tôi muốn so sánh nội dung PR theo từng workflow. Copilot đề xuất nhiều code hơn so với khi tôi tự làm, nhưng rất hay dẫn tới code dài hơn do thêm các kiểm tra không cần thiết, lặp lại, và không có trừu tượng hóa. Giả thuyết cá nhân của tôi là khi nhìn LLM viết ra quá nhiều code, cảm nhận của con người về việc sẽ mất bao lâu để giải quyết vấn đề bị méo đi
Khó khăn thực sự khi dùng LLM để làm việc trong codebase lớn là phải mô tả thật chính xác công việc cần làm. Chỉ riêng việc giải thích một issue giữa vô số tương tác trong code thôi nhiều khi còn tốn thời gian hơn là tự xử lý bằng tay, trong khi với dự án mới và việc tạo boilerplate thì LLM có lẽ lại phù hợp nhất
Chỉ riêng tiền tuyển lập trình viên tham gia đã là 300 x 246 = khoảng 73K, vậy mà bài báo lại không đăng tạp chí học thuật, cũng không qua phản biện đồng cấp. Bài báo trông được trình bày gọn gàng và không có vẻ do AI tạo, nhưng tôi tò mò làm sao có được khoản kinh phí như vậy
Nguồn tài trợ lớn nhất là The Audacious Project, có thể xác nhận qua thông báo chính thức. Ngoài ra cũng có ghi trong chú thích trên website rằng tới tháng 4/2025 họ chưa nhận thù lao đánh giá nào từ các công ty AI
Các công ty thường phát hành kiểu “whitepaper” như thế này. Nó là dạng pha trộn giữa báo cáo kỹ thuật, đề xuất chính sách và tài liệu quảng bá
Tôi không nghĩ việc chỉ chăm chăm xem có đăng tạp chí hay có phản biện đồng cấp hay không là có nhiều ý nghĩa. Trong khoa học, điều quan trọng không phải ai xuất bản mà là khả năng tái lập và kết quả lặp lại được. Như khủng hoảng tái lập trong tâm lý học cho thấy, việc được đăng journal không tự động đảm bảo độ tin cậy
Ở phần lớn các nước đều có tài trợ công cho nghiên cứu; Mỹ trước đây hỗ trợ nhiều hơn, nhưng gần đây đã cắt giảm mạnh
Xem trang giới thiệu về quỹ thì có vẻ họ nhận tài trợ từ nhiều nơi khác nhau như công ty AI, chính phủ, v.v.
Với các dự án OSS làm vì sở thích, AI ngược lại chỉ gây vướng víu. Việc sinh code/scaffold không phải thứ khiến tôi lo lắng; code review và quản lý cộng đồng mới quan trọng hơn. Những việc AI làm được có giới hạn rất rõ. Thế mà có người đưa công cụ review code bằng AI vào PR mở của tôi, và ngay cả với một PR chỉ 30 dòng nó cũng nhả ra bản tóm tắt dài 2 trang với emoji và bullet được sắp xếp chỉnh tề. Toàn tiếng ồn vô ích, đến mức giờ tôi còn phải tốn thêm thời gian bảo trì thực sự chỉ để xóa hoặc ẩn mấy bình luận kiểu đó
Một khi vượt qua đường cong học tập thì đúng là có thể nhanh hơn (hoặc như ai đó nói, “cho tới khi bạn quên mất cách làm việc mà không có AI”), nhưng thứ thật sự cần đo là… lúc 3 giờ sáng PagerDuty báo động, thì mất bao lâu để debug chính đoạn code đó? Và chất lượng dài hạn của code đó sẽ ra sao? Tôi đã dành thời gian dài cải thiện cấu trúc code: kéo business logic lên shared folder, gom call chain lên trên để API bên dưới gọn hơn, tách logic/API/display, đóng gói, v.v. (giảm độ kết dính bằng dependency injection, chẳng hạn). Liệu code do AI tạo ra về lâu dài có thực sự tốt hơn về chất lượng/khả năng di chuyển/khả năng mở rộng không? Hay rồi cuối cùng code chất lượng thấp sẽ chồng chất thành một bãi rác rối tung, để rồi ta phải dành nửa thời gian chỉ để sửa bug?