Tác động của Gen AI đối với công việc kỹ năng cao: Thí nghiệm với các lập trình viên phần mềm
(papers.ssrn.com)Tóm tắt
- Tổng quan nghiên cứu
- Nghiên cứu này đánh giá tác động của AI tạo sinh lên năng suất của lập trình viên phần mềm thông qua ba thí nghiệm đối chứng ngẫu nhiên được thực hiện tại Microsoft, Accenture và một công ty sản xuất điện tử thuộc Fortune 100 giấu tên.
- Các thí nghiệm được tiến hành như một phần trong công việc hằng ngày tại mỗi công ty, và các lập trình viên được chọn ngẫu nhiên đã được cung cấp GitHub Copilot, một trợ lý lập trình dựa trên AI.
- Nghiên cứu với tổng cộng 4.867 lập trình viên phần mềm cho thấy số lượng công việc hoàn thành của các lập trình viên sử dụng công cụ AI đã tăng 26,08% (sai số chuẩn: 10,3%).
- Đặc biệt, các lập trình viên ít kinh nghiệm hơn cho thấy tỷ lệ chấp nhận và mức cải thiện năng suất cao hơn.
Tóm lược của GN⁺
- Nghiên cứu này cho thấy AI tạo sinh có thể cải thiện đáng kể năng suất của lập trình viên phần mềm.
- Đặc biệt hữu ích với các lập trình viên ít kinh nghiệm hơn, điều này cho thấy các công cụ AI có thể giúp làm nhẹ đường cong học tập.
- Các công cụ AI như GitHub Copilot có thể đóng vai trò quan trọng trong việc nâng cao hiệu quả phát triển phần mềm.
- Những dự án khác có chức năng tương tự bao gồm TabNine và Kite.
1 bình luận
Các ý kiến trên Hacker News
Đôi khi tôi tự hỏi liệu lý do chất lượng nhân lực IT đi xuống có phải là vì các công ty, để cắt giảm nhân sự, đang nhồi ngày càng nhiều vai trò hơn vào một người hay không.
Trước đây phát triển, vận hành, bảo mật là các vai trò chuyên trách riêng; nhưng khi DevOps ra đời, một số công ty hiểu đó không phải là tích hợp đội nhóm mà là chỉ cần 2/3 số người, và khi DevSecOps ra đời thì họ cho rằng chỉ cần 1/3 các vai trò ban đầu là đủ, miễn là lập trình viên làm luôn vận hành và bảo mật ứng dụng.
Tôi không phê phán shift-left hay bản thân mô hình vận hành tích hợp; ý tôi là đây là hệ quả logic của những mô hình đó khi các lãnh đạo nghĩ rằng nếu giảm nhân sự để cắt chi phí thì họ có thể nhận thưởng nhiều hơn.
Giờ đây lập trình viên mới vào phải bước vào một môi trường n microservice phức tạp đến phi lý, vừa học codebase hiện có, 5 pipeline CI/CD, cả vai trò DBA, trong khi vẫn phải đáp ứng nhịp phát hành đều đặn.
Việc họ dùng ChatGPT để cố bắt kịp có thật sự đáng ngạc nhiên không? Điều này sẽ còn tiếp diễn cho đến khi các công ty IT ngừng cắt người để “làm đẹp chỉ số” thay vì theo đuổi chiến lược kinh doanh tốt.
Điều tôi nghĩ các MBA bỏ lỡ là hiện tượng ràng buộc quá mức. Khi vai trò chung là “lập trình viên” bị tách thành “phát triển, vận hành, bảo mật”, sẽ xuất hiện đủ loại chi tiết về cách thực hiện từng vai trò. Dù sau đó gộp lại thành DevSecOps, các chi tiết ấy vẫn còn nguyên, nên không phải một người làm việc hiệu quả gấp 3 lần, mà là gánh khối lượng công việc gấp 3.
Muốn đảo ngược cho đúng thì phải nới lỏng các ràng buộc và để người đó tự phán đoán cách thực hiện công việc.
Kết luận kéo theo là quy mô tổ chức không thể nhỏ đi, mà chỉ có thể lớn lên. Càng nhiều nhân viên thì công việc càng chuyên môn hóa; nếu loại bỏ họ, chức năng đó đơn giản là không được thực hiện nữa. Ở mức chuyên môn hóa đó, những nhân viên còn lại khó có thể chỉ sửa mô tả công việc một chút là gánh thêm trách nhiệm mới.
Cuối cùng phải bỏ tổ chức cũ và bắt đầu lại bằng một tổ chức mới, nhỏ hơn; đây cũng là lý do hệ sinh thái quỹ đầu tư tư nhân/vốn mạo hiểm/startup tồn tại. Định luật Gall cũng cùng mạch này: https://en.wikipedia.org/wiki/John_Gall_(author)#Gall's_law
Ngược lại, nhìn vào các startup mới xuất hiện gần đây, ngày càng có nhiều người thật sự tài năng. Tôi nghĩ vì trong môi trường vốn chặt chẽ hơn, muốn khởi nghiệp cần những người thực sự giỏi hơn, và những người như vậy lại tuyển thêm người xuất sắc.
Ngành công nghệ hiện nay có cảm giác giống giai đoạn 2004~2008 hơn nhiều, khi gần như ai quan tâm đến startup cũng lao vào vì thích hack các vấn đề kỹ thuật.
Theo trải nghiệm của tôi khi dùng Cursor, nó rất tốt cho những việc mà kỹ sư bình thường có thể làm, nhưng rất tệ với các công việc cao cấp hơn; đồng thời vẫn cần khả năng hiểu code của người khác thật nhanh.
Có lẽ các kỹ sư kỹ thuật cao cấp không tập trung vào frontend hay phát triển web app sẽ không còn cần tuyển nhiều lập trình viên web junior như trước. Điều này giống như việc webmaster biến mất khi các framework và công cụ giúp tạo nhanh HTML/CSS cơ bản cho trang web xuất hiện.
Giả sử nhân sự “DevSecOps” đang làm khối lượng gấp 3 lần phần việc họ phải làm, ta cũng cần nhìn xem họ còn đang làm gì nữa. Họ có thể phải đặt chuyến công tác, quyết toán và báo cáo chi phí, chia và báo cáo thời gian làm việc theo từng hạng mục kinh doanh, quản lý nghỉ phép, quản lý cuộc họp, làm slide thuyết trình bằng đồ họa tự tạo, thậm chí chuẩn bị 80% việc mua hàng từ nhà cung cấp bên ngoài.
Những việc này không có trong mô tả công việc, cản trở công việc thực sự và bào mòn một cách mất cân đối khả năng thực hiện nghề chính. Trước đây mỗi việc như vậy đều có chuyên gia chuyên trách, và họ có thể xử lý rẻ hơn nhiều với hiệu suất gấp 10 lần.
Các chuyên gia như thư ký, bộ phận đồ họa nội bộ, nhân sự tài chính từng hiện diện trên báo cáo tài chính. Loại bỏ các vai trò đó không làm công việc biến mất; nó chỉ bị phân tán thành từng mảnh cho mọi người dưới danh nghĩa phần mềm văn phòng tự phục vụ giúp cải thiện “năng suất”.
Kết quả là ai cũng chậm đi một cách mất cân đối, nhưng những người chỉ nhìn vào con số chỉ thấy khoản tiền lương tiết kiệm được từ các vai trò đã loại bỏ. Sự chậm lại chỉ hiện ra như một cảm giác mơ hồ, chung chung về năng suất suy giảm, như một căn bệnh chi phí bí ẩn mà ai cũng gặp.
Tôi nghĩ chẳng có gì bí ẩn cả: không có tăng năng suất, mà còn phát sinh tổn thất. Chỉ là vì nó biến chi phí rõ ràng, dễ thấy thành chi phí phân tán và khó tính toán, nên rất dễ ảo tưởng rằng mình đang tiết kiệm tiền.
Năng lực cốt lõi bị bỏ sót là khả năng hiểu lĩnh vực kinh doanh mà công ty đang hoạt động. Ngay cả năng lực lập trình vừa phải, nếu kết hợp với hiểu biết tốt về mục tiêu kinh doanh, vẫn có thể tiếp tục có giá trị trong khi một phần lập trình viên thuần túy bị AI thay thế.
Trong 13 năm ở một công ty thuộc ngành ngân hàng, tôi đã thấy độ phức tạp tăng mạnh, cùng với mức quan liêu vô lý. Đến giờ vẫn có thể làm những việc cần thiết, nhưng lại không có quyền truy cập. Cũng không thể có được.
Một tác vụ đơn giản giờ đã trở thành việc phải thương lượng 10 bước với một đội Pune không rõ là ai, rồi phải đuổi theo và escalte 10 lần cho đến khi họ nhận ra rằng thực sự có việc cần làm.
Quy trình trở nên lố bịch đến mức khi bắt đầu một việc gì đó, không biết sẽ mất 2 ngày hay 3 tháng. Mọi ứng dụng, nếu không được bảo trì liên tục, sẽ hỏng khá nhanh vì một tác vụ mạng mới, một bản cập nhật Unix chưa được kiểm chứng, hoặc một trong vô số chuyện chắc chắn sẽ xảy ra.
Cuối cùng, những người xử lý giấy tờ và những người mà công việc chính cũng chỉ ở mức trung bình đã cắm rễ sâu trong quy trình và giành phần thắng; các đơn vị kinh doanh nhận được dịch vụ IT kém chất lượng, dự án bị trì hoãn và vượt ngân sách. Điều này càng củng cố hình ảnh IT là “cái ác tệ hại nhưng phải chịu”.
Giờ tôi đã thôi bận tâm; công việc chỉ cần là phương tiện để sống là đủ. Sự tập trung và thành tựu của tôi nằm ở phần “sống” đó.
Việc đo lường cái gì mới là quan trọng. Nghiên cứu này chỉ xem mức sử dụng Copilot
Tôi là một kỹ sư giàu kinh nghiệm, và với tôi Copilot không chỉ vô dụng mà còn gây cản trở. Phần lớn thời gian tôi dùng để hiểu miền vấn đề, nắm bắt các ràng buộc và khả năng trong môi trường mình đang ở, rồi suy nghĩ về đoạn code sẽ viết
Khi thực sự bắt đầu gõ code, tôi đã biết mình sẽ viết gì, nên tính năng tự động hoàn thành “hỗ trợ” của Copilot chỉ làm tôi mất tập trung. Nó khiến quy trình làm việc của tôi tệ hơn nhiều
Ngược lại, AI cực kỳ hữu ích ở các bước trước khi thực sự code. Đôi khi chỉ cần một prompt được viết tốt dựa trên phần suy nghĩ đã chuẩn bị trước là có thể có bản nháp, và sau đó việc ghép cặp với LLM để nhanh chóng nhận câu trả lời cho những vấn đề nhỏ phát sinh ngoài dự kiến là rất hữu ích
Vì vậy, trái với báo cáo này, tôi nghĩ nếu lập trình viên lành nghề dùng AI tốt thì thậm chí có thể thu được lợi ích lớn hơn so với lập trình viên chưa thành thạo
Nhưng dùng Claude Sonnet 3.5 cùng Cursor hoặc Continue.dev thì cải thiện rất mạnh. Có thể kiểm soát ngữ cảnh một cách tường minh, chẳng hạn chọn và đưa vào 6–7 file, cộng thêm năng lực vượt trội của Claude thì cục diện thay đổi hoàn toàn
Tùy công việc, dễ dàng nhanh hơn 2–5 lần. Việc vốn có thể mất nửa ngày có thể được tạo thành 100 dòng code sẵn sàng cho production, có cả test, trong chưa đầy một giờ
Tôi nói điều này từ góc nhìn người có 26 năm kinh nghiệm và đã giữ các vai trò principal/staff/lead từ năm 2012. Tuy nhiên, với kinh nghiệm dưới mức senior thì tôi không kỳ vọng mức cải thiện tương tự. Vì thực tế phải mô tả khá chi tiết điều mình muốn, rồi thường nhận một giải pháp ban đầu chạy được và tinh chỉnh khoảng sáu lần để biến nó thành dạng lý tưởng, được phân tách tốt
Ví dụ khi viết IaC cho AWS thì có rất nhiều thứ phải tra. Hỏi AI sẽ nhận được câu trả lời và ví dụ rất nhanh. Nếu đang học IaC cho một dịch vụ mới thì tôi sẽ xem tài liệu AWS, nhưng khi chỉ cần câu trả lời nhanh hoặc ôn lại thì AI nhanh hơn nhiều
Càng dựa nhiều vào các pattern hàm, thiết kế monad, chỉ thực hiện nhập/xuất ở ranh giới và dùng fluent programming thì hiệu quả càng lớn
Nhân tiện, đây là trải nghiệm của tôi với Java. Tôi đã dùng Java 3,5 năm và phụ thuộc nhiều vào các tính năng Java 8+. Nếu dùng nhiều generic trong code thư viện, LLM có nhiều cơ hội hơn để nhất quán chọn đúng
Với thiết kế nhanh hơn và làm qua loa hơn thì không thấy được lợi ích như vậy. Tôi muốn nghe thêm từ những người dùng lập trình hàm thực thụ như Haskell, OCaml, F#, Scala
Nó có ích khi viết boilerplate cho unit test, đặc biệt là table-driven test, nhưng không đủ để duy trì gói đăng ký trả phí
Nó rất có giá trị khi làm việc với ngôn ngữ chưa quen, hoặc trong các công việc lặp lại mà tôi có thể dễ dàng đánh giá code được sinh ra có ổn hay không
Ngược lại, nó yếu khi điều tôi muốn làm rất rõ ràng và khá giống implementation chuẩn nhưng có chút mới hơn. Điều này thường xảy ra với “reduce” hoặc các quy trình mơ hồ hơn
Là kỹ sư nền tảng, tôi phải chuyển qua lại giữa nhiều không gian như Bash, Python, trình duyệt, JS thuần, TS, Node, GitHub Actions, workflow Jenkins Java, Docker, v.v.; khi chuyển miền, nó giúp não được nghỉ và khởi động nhẹ
Tôi thắc mắc liệu nghiên cứu có tính đến nợ kỹ thuật mà các lập trình viên ít kinh nghiệm tạo ra bằng AI rồi sau đó các lập trình viên nhiều kinh nghiệm hơn phải xử lý hay không. Vì cá nhân tôi đã gặp rất nhiều chuyện như vậy tại một trong các công ty được nhắc trong nghiên cứu
Tôi cũng trực tiếp thấy những lập trình viên ít quan tâm đến bản thân công nghệ nhưng rất quan tâm đến việc giao hàng lại hứng thú với AI hơn. Các PM thì thích những người như vậy, nhưng
Việc chúng tôi yêu cầu chỉ là một thay đổi nhỏ khoảng 5 dòng và test. Nhưng giờ chúng tôi không chỉ gánh thêm nợ mới, mà còn cả đoạn code không ai giải thích được vì sao bị thay đổi hoàn toàn, một phần trong đó chỉ là thay đổi để mà thay đổi, và cả code trông hoàn toàn xa lạ đối với những người đang bảo trì nó
Tôi liên tục thấy điều này ở những người dùng các công cụ như vậy nhưng không phải kỹ sư cấp cao. Cuối cùng những PR như thế bị từ chối và chúng tôi bảo họ làm lại, thế là lợi ích thời gian tưởng như có được lúc đầu biến mất
Điều này không có nghĩa các công cụ như vậy vô dụng, nhưng người ta đang dùng chúng mà không hiểu output là gì, cũng không hiểu tác động dài hạn lên codebase
Ngày tôi cảm thấy mất đi một phần linh hồn là khi tôi hỏi một lập trình viên liệu tôi có thể góp ý về schema DB không, anh ta nói được, rồi vài phút sau ngắt lời bằng câu “Vâng, tôi không mấy quan tâm đến X”
Không quan tâm ư? Tôi đang nói với tư cách chuyên gia trong lĩnh vực đó rằng có thể cải thiện điều gì, làm thế nào và vì sao nên làm, vậy mà lại không quan tâm
Cloud là một sai lầm. Nó gieo vào đầu mọi người ý nghĩ rằng vì lúc nào cũng có thể scale up/out nên không cần theo đuổi hiệu quả và tối ưu hóa. Tôi còn không nói đến microbenchmark, mà chỉ là những chuyện rất đơn giản như “có lẽ dùng cấu trúc dữ liệu kia thay vì cấu trúc dữ liệu này sẽ tốt hơn”
Chúng tôi cũng dùng nội bộ, và tôi cho rằng nợ kỹ thuật là một mối đe dọa khổng lồ chưa được đánh giá đúng mức
Nó rất hữu ích để rải hàng loạt API và pattern lạ lẫm vào code, nhưng nếu không cẩn thận sẽ tạo ra trùng lặp code khổng lồ và boilerplate khó xử lý
Lý do là vì hai thiên lệch lớn. Thứ nhất, dữ liệu huấn luyện của mô hình là kiểu ví dụ StackOverflow nên không xét đến ngữ cảnh và ràng buộc. Thứ hai, thay vì nhìn codebase hiện có rồi đề xuất refactor, nó có xu hướng sao chép và lặp lại
Vấn đề thứ nhất rốt cuộc có thể giảm nhẹ nếu bạn làm đúng phần việc của mình: review và chỉnh sửa những gì LLM nhả ra
Vấn đề thứ hai chỉ có thể giảm nhẹ nếu diff và lịch sử commit được đưa vào dữ liệu huấn luyện, nhưng bộ dữ liệu này khó xử lý và gắn nhãn hơn nhiều. Có thay đổi tốt như refactor, nhưng có thay đổi có thể là bug được sửa ở commit sau, còn commit message thì về cơ bản là nói dối nên cũng không có cách phân biệt rõ ràng. Không ai viết “đưa bug vào” cả
Hơn nữa, merge, rebase, squash còn làm thay đổi hoặc xóa bỏ ý nghĩa của lịch sử, hoặc thêm nhiễu, khiến mọi thứ càng mờ nhạt hơn
Tôi thích kỹ thuật và cũng viết phần mềm để giải trí, nhưng làm cùng AI khách quan mà nói vui hơn. Năng suất tăng hơn rất nhiều, và quan trọng nhất là không còn trì hoãn
Khi bị kẹt hoặc không muốn bắt đầu việc, tôi bắt chuyện với Aider, rồi trước khi nhận ra thì một việc mà nếu không có AI hôm đó tôi đã không làm đã xong
Nhờ vậy, những dự án công khai/riêng tư trước đây mất vài tháng đến vài năm, giờ tôi tung ra mỗi 2 tuần. Chi phí để có một đội lập trình viên nhanh và nhiều kinh nghiệm ngồi cạnh mình tối đa chỉ vài đô mỗi ngày
Trước khi kết luận, cần xem bài báo sâu hơn một chút. Bản thân nghiên cứu có lẽ cũng đã có thể tóm tắt kết quả tốt hơn
Phần tóm tắt và kết luận chỉ đưa ra một tỷ lệ duy nhất là tăng năng suất 26,08% như kết quả, nhưng có vẻ quá nhiều chữ số thập phân. Đi sâu hơn một chút thì thấy con số là 27~39% với junior và 8~13% với senior
Nhìn kỹ hơn nữa, không chỉ theo kinh nghiệm mà chênh lệch giữa các công ty cũng lớn. Ở Microsoft, ngoài pull request, các chỉ số kết quả khác như commit, build, tỷ lệ build thành công dường như không có ý nghĩa thống kê. Mức tăng PR có vẻ có ý nghĩa ở Microsoft nhưng ở Accenture thì dường như không, và thậm chí điều đó có thể chỉ đúng với junior
Phần tóm tắt và kết luận cần phải tóm lược, nhưng kết quả thay đổi quá nhiều theo biến số nên tôi không biết việc đưa một con số tổng thể duy nhất làm tóm tắt có hợp lý không. Đặc biệt là vì ý nghĩa thống kê trông khá thất thường
Accenture là công ty hợp tác và cùng làm marketing với các tổ chức lớn như Microsoft. Nhóm khoảng 300 lập trình viên gần như không thể làm dịch chuyển toàn bộ mẫu, và họ đang xây dựng các bộ phận marketing/tư vấn quanh workflow AI, nên cũng khó giả định là khách quan
Công ty ẩn danh thứ ba thực ra không phải là thử nghiệm đối chứng ngẫu nhiên, nên khó nói nên gộp kết quả đó với các RCT như thế nào. Ngoài ra, hẳn còn có những công ty công nghệ lớn khác đã làm thí nghiệm tương tự và muốn biết hiệu quả, nên có thể giả định rằng ngoài dữ liệu được đưa vào kết quả còn có dữ liệu khác
Vì sao họ lại chọn các công ty này trong một tập mẫu lớn hơn? Có lẽ vì Microsoft và Accenture có động cơ thúc đẩy việc áp dụng, còn công ty thứ ba được chọn do p-hacking
Đặc biệt, câu trong phần tóm tắt “mỗi thí nghiệm riêng lẻ đều có nhiễu, nhưng khi gộp ba thí nghiệm lại” là một tín hiệu rất xấu. Về thực chất đó là thừa nhận rằng nếu nhìn từng công ty thì không có kết quả có ý nghĩa thống kê, nhưng khi gộp ba nhóm này lại thì trở nên có ý nghĩa. Đây không phải là khoa học
Lập trình viên junior có thể đang làm những tác vụ mà LLM dễ đoán đúng, hoặc mắc sai lầm là chấp nhận bản nháp đầu tiên chỉ vì trông có vẻ LGTM, khiến throughput có vẻ cao hơn
Việc dùng mô hình sinh code cũng cần kỹ năng, và kỹ năng đó giống với kỹ năng cần có khi giao việc cho người khác và tích hợp lời giải của nhiều tác giả thành một hệ thống gắn kết
Đây chỉ là trực giác của tôi, nhưng tôi cho rằng lập trình có LLM hỗ trợ có hại cho quá trình trưởng thành thành lập trình viên. Nó có vẻ chỉ có thể kéo năng suất lên đến một mức nhất định, và mức đó có thể là những việc lặp lại nhàm chán với senior, nhưng lại là giai đoạn hình thành đối với junior
Theo kinh nghiệm của tôi, LLM không chỉ được dùng cho code boilerplate đơn giản, mà còn được gọi đến khi lập trình viên junior gặp những tác vụ khá phổ biến mà họ chưa hiểu đủ. Quá trình thử nghiệm, học hỏi và thấu hiểu phần lớn bị thay bằng LLM, còn kỹ năng thật sự trở thành việc chỉnh prompt cho đến khi thứ đó trông có vẻ chạy được
Tối qua tôi lần đầu thiết lập Linux RAID. Việc đó không quá khó, nhưng cần nhiều công cụ như mount, umount, fstab, blkid, mdadm, fdisk, lsblk, mkfs, v.v., và trong quá trình làm có thể lệch khỏi các bước chính xác trong hướng dẫn, nên chỉ xem tutorial hay tài liệu không đặc biệt hữu ích
Tôi đã hỏi hàng chục câu về từng công cụ và từng bước; nếu là trước đây thì có lẽ tôi chỉ copy-paste rồi cầu nguyện
Hai ngày trước, tôi cũng đã học qua ChatGPT và khôi phục toàn bộ dữ liệu từ một ổ SSD bị hỏng. Dù có thể sai 20%, việc xử lý một kỹ năng hoàn toàn mới với một “hướng dẫn” tốt hơn rất nhiều so với mức trung bình của Internet mở thật sự rất tuyệt
Với những người thích học, nó có cảm giác như đôi hia bảy dặm so với việc lục lọi vô tận trong rác trên Internet. Tất nhiên cũng như mọi thứ khác trên Internet, phải nghi ngờ những gì AI nói, nhưng nó giảm phiền toái một cách khổng lồ
Tôi cũng có trực giác tương tự, và còn muốn gọi đó là một quan điểm mạnh có cơ sở. Tôi nghĩ vài năm nữa ngành này sẽ phải trả giá
Đường ống cung ứng “lập trình viên phần mềm junior có cảm giác nghề” sẽ khô cạn đáng kể, và được thay thế bằng một làn sóng “lập trình viên phần mềm junior phụ thuộc vào AI”. Giữa hai nhóm đó có một vực sâu
Đương nhiên điều này cũng sẽ gây hiệu ứng dây chuyền lên số lượng lập trình viên mid-level có cảm giác nghề và senior có cảm giác nghề
Ngược lại, người muốn hiểu toàn bộ code mình dùng có khả năng sẽ tra cứu những phần họ không biết trong thứ LLM nhả ra
Ít nhất thì tôi dùng như vậy. Và để nêu phản ví dụ cho giả thuyết đó, LLM đôi khi dùng những hàm hoặc thành phần thư viện mà tôi chưa biết, nên khi học một ngôn ngữ hoặc bộ công cụ mới, nó giúp tiết kiệm rất nhiều thời gian. Với tôi, nó tăng tốc việc học hơn là làm chậm lại
Nhưng với những người dù sao cũng sẽ thành công, nó giống như đặt câu hỏi trên StackOverflow và nhận được câu trả lời tức thì, không bị phán xét, nên thật sự là một món quà lớn
Nó không phải lúc nào cũng đúng, nhưng StackOverflow cũng vậy. Cuối cùng, như mọi khi, vẫn phụ thuộc vào từng cá nhân
50 năm trước, có bao nhiêu lập trình viên ngày nay biết dùng hợp ngữ, thứ gần như là bắt buộc nếu muốn tạo ra thứ gì đó
Có thể LLM đang chuyển từ một cái nạng trừu tượng hóa nữa thành một trụ cột trừu tượng hóa vững chắc
Điều thú vị nhất trong nghiên cứu này là khi chia theo mức độ kinh nghiệm, các nhà phát triển có thời gian làm việc ở công ty cao hơn mức trung vị không có mức tăng có ý nghĩa thống kê nào ở chỉ số đại diện không mấy hay ho gọi là “năng suất”. Khoảng tin cậy 95% thậm chí còn đi sâu về phía âm ở mọi chỉ số, chỉ hơi nghiêng về phía dương mà thôi
Điều này cũng khớp với trải nghiệm của tôi. Copilot tốt ở chỗ giảm bớt một số việc nhàm chán và để não dùng cho các câu hỏi sâu hơn, nhưng không đến mức thay đổi thế giới như các lập trình viên junior nói
Nó cũng thường sai một cách tinh vi, theo kiểu mà lập trình viên ít kinh nghiệm có thể bỏ sót. Tôi phải dừng lại để chỉnh hầu hết những gì nó sinh ra, và rất có thể lập trình viên kém kinh nghiệm hơn không biết phải chỉnh như thế nào
Sau vài năm dùng, giờ tôi đã khá có cảm giác về khi nào nên dùng Copilot và khi nào không, nên có lẽ hiệu ứng ròng là dương, nhưng không phải lúc nào cũng vậy
Ngoài ra tôi cũng tò mò liệu một phần lý do “năng suất” của senior developer trông như giảm có phải là do năng suất của các junior trong công ty tăng lên không. Nếu junior tạo nhiều PR hơn và trong đó có nhiều lỗi hơn khiến thời gian review tăng, thì mức cải thiện năng suất của senior có thể giảm tương ứng
Tăng năng suất 26% nhìn chung cũng khớp với trải nghiệm của tôi. Một chiều khác nên xem xét là đang làm với công nghệ mới hay công nghệ đã quen thuộc. AI hữu ích hơn nhiều với ngôn ngữ hoặc framework mà tôi đang muốn học
Tôi không nhớ rõ các điểm kỳ quặc và cạm bẫy của những ngôn ngữ phụ trợ, chẳng hạn chính xác phải dùng loại dấu nháy thần chú nào khi viết câu điều kiện trong Bash. Vì vậy trước đây tôi hầu như không viết script Bash để tự động hóa, chỉ cố làm khi đó là việc đủ thường xuyên. Xử lý JSON bằng jq hay parse bằng AWK cũng tương tự
Giờ nhờ LLM, tôi tạo nhiều script Bash hơn hẳn, và vì quá dễ nên cũng dùng chúng thường xuyên hơn cho tài liệu hóa quy trình. Những thứ trước đây là README tĩnh theo từng bước giờ đi kèm với script Bash tương tác nhận input từ người dùng
Nói chung tôi thấy nhiều lập trình viên senior bàn về lý do vì sao công cụ AI không hiệu quả. Junior thì cứ dùng mà không có định kiến
Có bốn chỗ nó hữu ích. Thứ nhất là hỏi về framework/ngôn ngữ tôi không dùng thường xuyên nhưng có nhiều nội dung ví dụ, như Qt hay CSS
Thứ hai là các câu hỏi rất cụ thể mà trước đây tôi sẽ tìm trên Google Search hoặc StackOverflow. Ví dụ với câu hỏi như “cách hiệu quả nhất để lấy mức sử dụng CPU và RAM của Windows bằng Python”, nó chỉ ra thư viện hoặc ví dụ thay vì lập tức tạo đoạn mã để copy-paste
Thứ ba là mã boilerplate mà tôi vốn đã biết viết nhưng giúp tiết kiệm chút thời gian và giảm lỗi gõ phím. Khi dùng plugin CoPilot cho PyCharm, nếu viết ý định bằng comment trong file, nó hoàn thành vài dòng tiếp theo. Kết quả vẫn tốt nhất khi rất ngắn và cụ thể. Nếu dài hơn, phải lặp lại quá nhiều với CoPilot nên không còn giá trị nữa
Thứ tư là một cách để tìm nhanh trong tài liệu
Có người nói nó tốt cho việc viết unit test, nhưng với tôi thì không. Ít nhất không phải loại unit test mà tôi muốn
Nếu định lượng, tôi cho rằng năng suất tăng khoảng 5~10%. Nhỏ hơn nhiều so với việc dùng một IDE đầy đủ như PyCharm thay vì Notepad, hoặc dùng một git client tốt thay vì gõ trực tiếp lệnh git trên CLI. Nói cách khác, nó chỉ là một trong nhiều công cụ năng suất, tôi sẽ không gọi là “mang tính cách mạng”
Tôi đã dùng Cursor khoảng 10 ngày trong một dự án Ruby on Rails khổng lồ, và đã dùng stack này hơn 13 năm
Tôi không thu được gì vượt quá mức cải thiện năng suất mà GitHub Copilot đã mang lại. Tôi ước tính mức cải thiện của Copilot vào khoảng 25%
Nhưng khi bắt đầu một dự án mới như Node.js từ một thư mục trống thì nó mạnh đến kỳ lạ. Chỉ bằng prompt, có thể tạo trong khoảng 5 phút một API xử lý request từ schema OpenAPI và cung cấp schema OpenAPI qua swagger
Tuy nhiên việc bắt đầu dự án mới từ đầu là hiếm với tôi, nên có lẽ tôi sẽ quay lại Copilot và VSCode cơ bản
Nó giúp mọi người tạo nhiều PR hơn. Ồ, ghê thật. Ai quan tâm chứ
Số hạng mục vượt qua QA có tăng không? Những thứ được tạo với hỗ trợ AI có ít bug được phát hiện sau QA hơn không? Sau này có dễ mở rộng hoặc sửa đổi không, hay là thiết kế cứng nhắc, thiếu linh hoạt?
Một công cụ biến lập trình viên thành khỉ viết code mà chất lượng không rõ ràng không phải thứ tôi tìm kiếm. Tôi muốn công cụ giúp lập trình viên tìm bug hoặc lỗi thiết kế trong việc họ làm, hoặc giúp họ viết các bài test được thiết kế tốt
Chỉ đếm số PR chẳng nói lên điều gì hữu ích. Ngược lại, nó chạm đúng trực giác của tôi rằng khi lượng code trên mỗi đơn vị thời gian tăng lên thì chất lượng trung bình sẽ giảm
Copilot: “Được, tôi sẽ làm! Đây là các commit mới!”
Senior developer: “Tại sao? Thay đổi này là nguyên tử. Nếu ban quản lý lại lôi mấy chỉ số ngu ngốc kiểu số thay đổi hằng tháng ra, tôi sẽ lịch sự bảo họ biến đi”
Đây rất có thể là Copilot dựa trên GPT-3.5
Microsoft: tháng 9/2022~3/5/2023
Accenture: tháng 7/2023~tháng 12/2023
Công ty ẩn danh: tháng 10/2023~?
Bản cập nhật GPT-4 của Copilot Chat là ngày 30/11/2023: https://github.blog/changelog/label/copilot/
Với tôi, AI đã hồi sinh tài liệu hóa. Các framework mới có quá ít tài liệu. Tài liệu tốt cuối cùng mà tôi nhớ là sách DOS. Tôi nghĩ các lập trình viên ngày nay có khi còn chẳng hình dung được tài liệu tốt là như thế nào
Dù vậy, AI mỗi lần có thể đưa ra những đề xuất khác nhau, nên việc phán đoán vẫn phải do lập trình viên giàu kinh nghiệm đảm nhiệm. Rốt cuộc, AI thay thế tài liệu và việc gõ phím
Nếu là dự án công khai, tài liệu đã trở thành một phần dữ liệu huấn luyện của LLM, nên việc tài liệu kỹ lưỡng và chính xác càng quan trọng hơn nhiều. Vì nhiều lập trình viên sẽ lấy câu trả lời từ hệ thống đó
Nếu là dự án nội bộ, có thể đưa tài liệu vào tập dữ liệu fine-tuning hoặc hệ thống RAG để đạt hiệu quả tương tự
Điều đó cũng có thể giải thích vì sao chẳng có gì được tài liệu hóa
Vì thế trên thực tế nó cũng có tác dụng buộc lập trình viên tài liệu hóa mã tốt hơn
Không nhất thiết phải là tài liệu live hiện đại, bất cứ thứ gì cũng được. Tôi muốn xem trong quá khứ điều gì đã từng tuyệt vời đến thế mà chúng ta đã đánh mất, rồi thử đưa một phần vào tài liệu của mình