Nghiên cứu mới về GitHub Copilot phát hiện ‘áp lực đi xuống đối với chất lượng mã’
(visualstudiomagazine.com)- Sách trắng Coding on Copilot của GitClear phân tích dữ liệu thay đổi mã để xem liệu mã có hỗ trợ AI có thể làm tăng năng suất nhưng đồng thời tạo gánh nặng cho chất lượng và khả năng bảo trì hay không
- Code churn — phần mã bị hoàn tác hoặc chỉnh sửa trong vòng 2 tuần sau khi được viết — được dự báo sẽ tăng gấp đôi vào năm 2024 so với mức nền trước AI của năm 2021
- Sau khi Copilot phổ biến, tỷ trọng mã được thêm mới và mã sao chép/dán tăng lên, còn sự sụt giảm của mã được di chuyển cho thấy sự suy yếu của tái cấu trúc và tái sử dụng
- Nghiên cứu năm 2022 của GitHub cho rằng người dùng Copilot hoàn thành công việc nhanh hơn 55%, nhưng GitClear tập trung vào chi phí bảo trì dài hạn hơn là năng suất
- Phân tích 153 triệu dòng mã thay đổi được viết từ tháng 1 năm 2020 đến tháng 12 năm 2023 cho thấy các lãnh đạo kỹ thuật cần đánh giá tác động của việc áp dụng AI bằng các chỉ số chất lượng mã
Góc nhìn của sách trắng GitClear về đặc tính của mã có hỗ trợ AI
- Sách trắng Coding on Copilot khảo sát xem mã có hỗ trợ AI khác gì về chất lượng và khả năng bảo trì so với mã mà con người có thể đã tự viết
- Câu hỏi cốt lõi là liệu mã có hỗ trợ AI gần với đóng góp được trau chuốt cẩn thận của một lập trình viên kỳ cựu hay gần với công việc rời rạc của một nhà thầu ngắn hạn hơn
- GitClear là công ty bán công cụ review code trên nền tảng đám mây, và nghiên cứu lần này tập trung vào việc thành phần của các thay đổi mã đã thay đổi ra sao sau khi sử dụng AI
Những tín hiệu tiêu cực về khả năng bảo trì
- GitClear phát hiện các xu hướng đáng lo ngại về mặt khả năng bảo trì
- Code churn là tỷ lệ các dòng mã bị hoàn tác hoặc cập nhật trong vòng 2 tuần sau khi được viết
- Tỷ lệ này được dự báo sẽ tăng gấp đôi vào năm 2024 so với mức nền trước AI của năm 2021
- Tỷ lệ mã được thêm mới và mã sao chép/dán tăng lên so với mã được sửa, xóa hoặc di chuyển
- Vì những thay đổi này, mã do AI tạo ra bị đánh giá là giống với các cộng tác viên ghé qua kho mã và dễ vi phạm nguyên tắc DRY của repository đó
Ba thay đổi gắn với sự phổ biến của Copilot
- GitClear chỉ ra ba thay đổi quan trọng sau khi Copilot được triển khai: churn, mã được di chuyển, và mã sao chép/dán
-
Churn gia tăng
- Họ cho rằng “việc dùng Copilot” có tương quan mạnh với việc đẩy mã sai sót lên repository
- Điều này gắn với dòng chảy trong đó mã có hỗ trợ AI được thêm vào rất nhanh rồi bị hoàn tác hoặc chỉnh sửa trong thời gian ngắn
-
Mã di chuyển giảm
- Sự sụt giảm của mã được di chuyển cho thấy tái cấu trúc và tái sử dụng đang giảm đi
- Khi đặt cạnh sự gia tăng của mã sao chép/dán, có thể hiểu rằng cách triển khai trợ lý AI hiện nay chưa đủ khuyến khích việc tái sử dụng mã
- Thay vì tạo mã DRY thông qua refactoring, nó tạo ra cám dỗ lặp lại mã hiện có chỉ bằng một lần nhấn phím
-
Mã sao chép/dán gia tăng
- Mã sao chép/dán được xem là yếu tố tạo gánh nặng lớn cho khả năng bảo trì dài hạn
- Khi các dòng mã lặp lại thay vì chỉ là từ khóa, đó được hiểu là tín hiệu cho thấy không có thời gian để đánh giá phần triển khai trước đó
- Nếu mã được thêm lại thay vì tái sử dụng, người bảo trì về sau sẽ phải hợp nhất các nhánh mã song song đang triển khai cùng một chức năng lặp lại
Đối chiếu với các nghiên cứu về năng suất
- Nghiên cứu năm 2022 của GitHub cho rằng các lập trình viên dùng Copilot hoàn thành công việc nhanh hơn 55% so với những người không dùng
- Cũng trong nghiên cứu đó, ngoài năng suất còn ghi nhận tác động tích cực về mức độ hài lòng của lập trình viên và việc bảo toàn năng lượng tinh thần
- Khác với các kết quả về năng suất này, sách trắng của GitClear phân tích chủ yếu các thay đổi trong thành phần thay đổi mã và khía cạnh khả năng bảo trì khi dùng AI
Những đánh giá trái chiều từ các nghiên cứu liên quan
- Exploring the Verifiability of Code Generated by GitHub Copilot: tìm thấy bằng chứng phù hợp với sự đồng thuận trong tài liệu trước đó rằng Copilot là công cụ mạnh, nhưng không nên để nó một mình “điều khiển máy bay”
- Assessing the Quality of GitHub Copilot's Code Generation: phân tích thực nghiệm cho thấy Copilot là công cụ đầy hứa hẹn, nhưng cần các đánh giá toàn diện hơn trong tương lai
- Sea Change in Software Development: Economic and Productivity Analysis of the AI-Powered Developer Lifecycle: khi kỹ năng prompting với AI tạo sinh tăng lên, một mối liên kết độc đáo và khó tách rời giữa con người và AI được hình thành
- The Impact of AI on Developer Productivity: Evidence from GitHub Copilot: các tác động không đồng nhất được quan sát cho thấy AI pair programmer có thể giúp mọi người chuyển sang sự nghiệp phát triển phần mềm
- Study of software developers' experience using the Github Copilot Tool in the software development process: ý kiến của lập trình viên bị chia rẽ; thái độ nhìn chung tích cực, nhưng ý định sử dụng thực tế không cao và các vấn đề bảo mật nổi lên như một mối lo ngại
Phạm vi phân tích và những câu hỏi còn lại
- GitClear đã thu thập và phân tích 153 triệu dòng mã thay đổi được viết từ tháng 1 năm 2020 đến tháng 12 năm 2023
- Cùng với sự bùng nổ mức độ phổ biến của AI, nghiên cứu cũng cho rằng chúng ta đã bước vào thời kỳ các dòng mã được thêm vào nhanh hơn bao giờ hết
- Câu hỏi của năm 2024 không còn chỉ là Copilot sẽ thay đổi ý nghĩa của việc làm lập trình viên như thế nào, mà gần hơn với việc ai sẽ đảm nhận phần dọn dẹp phát sinh sau đó
1 bình luận
Các ý kiến trên Hacker News
Tôi dùng 2 tháng rồi hủy đăng ký. Chi phí tinh thần để sửa lỗi trong đống mã nôn mửa tuôn ra là quá lớn, và với các việc không hề nhỏ hoặc liên quan đến SQL thì gần như vô dụng, kể cả khi tôi đưa toàn bộ schema vào trước
Vì tôi biết mình muốn viết gì nên tự viết đỡ mệt hơn nhiều, và sửa lỗi của tôi còn dễ hơn sửa lỗi của bot. Tôi lo cho các junior sẽ bị đè bẹp dưới đống rác này
Tôi dùng ChatGPT thay cho Copilot, và rất ngạc nhiên vì nó làm được nhiều việc, nhưng vẫn khó gọi đó là “code tốt”. Tôi đọc được JavaScript, nhưng 14 năm qua chuyên về iOS nên không rành các best practice phía trình duyệt, vì vậy tôi dùng nó; nhìn chung có được code chạy được, nhưng vẫn thấy các lựa chọn tệ hoặc những điểm kỳ lạ
Tôi nghĩ thái độ đúng với AI hiện nay là tránh hai cực “mọi chuyện đã an bài rồi” và “chẳng là gì cả”. Với phe sau, cần một ví von kiểu: “một con chó đang tung hứng, khai thuế và nướng bánh; thay vì kinh ngạc vì nó làm được những việc đó, lại phàn nàn rằng nó làm rơi bóng, nhập sai số và công thức không ngon”
Copilot hữu ích nhất như một công cụ tự động hoàn thành giúp giảm gõ phím khi viết code dựa trên ngữ cảnh có thể dự đoán. Nếu viết một enum class ở một cửa sổ, nó có thể tự động hoàn thành phần sử dụng ở cửa sổ khác dựa trên ngữ cảnh; khi viết một loạt unit test, chỉ cần nhấn Tab một lần là có khung cho test case tiếp theo
Đặc biệt trong các ngôn ngữ động, Copilot bổ trợ IntelliSense khá tốt
Vài tháng trước tôi từng viết rằng ngành lồng tiếng chắc chắn sẽ bị các mô hình chuyển văn bản thành giọng nói đẩy lùi, kèm các ví dụ về sắp chữ, đóng sách và khắc bản nhạc: https://news.ycombinator.com/item?id=38491203
Nhưng nếu chính việc phát triển cũng bị rút ruỗng như thế này, tôi không rõ trạng thái cuối cùng sẽ là gì. Vì những người thúc đẩy các cuộc thay thế trước đây cũng chính là lập trình viên. Một dạng suy thoái và sụp đổ xã hội nào đó nghe cũng không hẳn là quá vô lý
“Hãy parse JSON này và đưa các trường tương ứng vào đúng vị trí trong database” là một use case tuyệt vời để viết SQL bằng Copilot. Có thể dùng plugin ORM hoặc middleware, nhưng với MVP hay mockup thì đó là tối ưu hóa quá sớm
Ngược lại, tôi dùng ChatGPT API thường xuyên và thấy khá tiện. Khi viết một SQL update đụng tới hàng triệu dòng, tôi nhờ nó đổi sang chia theo batch và ghi log trạng thái sau mỗi batch; khi gặp lỗi 401 khi truy cập nuget feed của Azure DevOps, nó không chỉ cho nguyên nhân mà còn đưa cả yaml để sửa
Cả hai việc đều là thứ tự mình làm được nếu chịu tìm hiểu một chút, nhưng việc không phải tốn thời gian tìm hiểu đó thật sự rất tuyệt
Nhờ GPT-4, hiệu suất làm việc của tôi tăng đáng kể. Tôi chủ yếu làm các ứng dụng PHP CRUD đơn giản để giải quyết vấn đề công việc hằng ngày, không dùng framework hay cấu trúc MVC, nên code do GPT-4 tạo dựa trên chỉ dẫn rõ ràng rất dễ hiểu và thường chạy ngay
Thường tôi yêu cầu nó sửa một đoạn code khoảng 25 dòng để khớp với một chức năng báo cáo cụ thể; ví dụ bảo trang này nhóm theo X và cộng Y thì nó phản hồi chính xác. Chỉ cần QA nhanh và kiểm thử là xong; với các tác vụ có độ phức tạp thấp và chỉ dẫn rõ ràng, hiệu quả của nó đủ để thay đổi cuộc chơi
Quy trình này giống cách một senior programmer chia nhỏ công việc thành các thành phần cơ bản rồi giao cho junior. Ở đây GPT-4 đóng vai một junior programmer giá 20 đô/tháng, giúp tôi tiết kiệm thời gian nên tôi sẵn sàng tự bỏ tiền túi trả
Tuy nhiên, giống như hồi nhỏ từng hỏi tại sao phải học toán khi đã có máy tính, giờ tôi hiểu vì sao vẫn phải học nền tảng. Không biết cơ bản thì không thể dùng nó hiệu quả. Nếu GPT-4 đã tồn tại khi tôi học PHP, có lẽ tôi đã không hiểu nền tảng đến mức như bây giờ. Tôi đang hưởng lợi từ việc đã học trước khi công cụ này xuất hiện
Tôi cũng không cảm thấy chất lượng code thấp hơn; ngược lại, đôi khi nó còn cho ra kết quả được trau chuốt hơn
Tôi cho rằng phần lớn chỉ trích hiện vẫn còn quá sớm, và đây giống một bước tiến lắc lư cần thêm hỗ trợ hạ tầng. Tích hợp linter để không tạo ra kết quả không biên dịch được ở đâu, rồi tính năng tự động tìm và sửa các lỗi độ khó thấp ở đâu?
Việc test trong môi trường phát triển dùng AI tạo sinh nên trông như thế nào và cần thay đổi ra sao cũng vẫn còn bỏ ngỏ. Có thể tồn tại cách tốt hơn để tối đa hóa lợi ích và giảm chi phí của các phương pháp mang tính quy trình như TDD hay BDD
1–2 năm qua là giai đoạn một thay đổi công nghệ lớn đơn giản bị ném vào các workflow hiện có. Với bất kỳ công cụ nào, kết quả là sự kết hợp giữa năng lực của chính công cụ và kinh nghiệm của người dùng
Ngành cần tích lũy nhiều kinh nghiệm và hiểu biết hơn nữa trong việc tích hợp AI tạo sinh vào phát triển thì mới cảm nhận được giá trị ròng thực sự. Tôi nghĩ cần thêm ít nhất 2–3 năm nữa, không phải vì thích ứng công nghệ mà vì con người cần thời gian để thích ứng
Tôi đã thấy một đội ở độ tuổi 20 tạo ra cả núi spaghetti full-stack trên framework CRUD cơ bản mà tôi làm sẵn. Nếu có thể tạo ra “MMO framework” trong 60 giây, động lực để tự làm một ứng dụng TODO từ đầu sẽ giảm đi
Nó giống việc 12 năm trước tôi dùng Firebase trước khi học các nền tảng quan hệ, rồi mất vài năm mới chạm tới phần cơ bản
Không thể nhìn chính xác tương lai, nhưng tôi tin rằng cách chúng ta nhận thức về chất lượng sẽ thay đổi
Có một bầu không khí như thể công nghệ sẽ trở thành vị cứu tinh cho những vấn đề quan trọng trong mọi lĩnh vực xung quanh chúng ta, từ xe điện, y tế, CNTT đến tài chính. Đồng thời, ngày càng rõ rằng công nghệ chủ yếu được dùng để mở rộng thị trường, chính phủ, quốc gia, v.v., và vận hành bằng cách đặt thêm một lớp nữa lên trên những abstraction vốn đã rò rỉ. Cảm giác giống như không phải giải quyết vấn đề, mà chỉ cố làm tan các triệu chứng
Chất lượng bao hàm sự chậm rãi; điều trị triệu chứng thì có giới hạn, và vì con người không thể đối phó với các thách thức bằng cách liên tục chồng thêm nhiều abstraction hơn, nên tôi nghĩ sự chậm rãi đó sẽ trở nên cần thiết
Tôi cho rằng ý nghĩ rằng chúng ta phải nhanh hơn là sai. Tôi tin rằng với cách cố giải quyết vì lợi ích bề mặt mà không hiểu nền tảng của thách thức với tư cách con người, sẽ không thể tạo ra chất lượng
LLM là một thảm họa đối với lĩnh vực của chúng ta. Vì nó chiều theo sai lầm của con người trung bình: muốn đạt mục tiêu mà không làm công việc thực sự. Công việc thực sự là áp dụng các giả định về tính đúng đắn và hiểu điều mình thật sự đang cố giải quyết là gì
May mắn là không phải ai cũng cố đi nhanh hơn; có những người đang học lại nền tảng, áp dụng các quyết định thận trọng, mài giũa tư duy và công cụ để tạo ra chất lượng có thể tồn tại lâu dài
Trải nghiệm của tôi gần như ngược lại. Thay vì để việc lục lọi các API hay thư viện lộn xộn chặn mất phần khó, LLM phơi bày một cách đau đớn rõ ràng những lúc tư duy của tôi chưa vững trong các công việc có ý nghĩa
Muốn làm gì đó với LLM thì phải viết, mà muốn viết thì phải suy nghĩ. Việc cẩn thận diễn đạt điều tôi muốn làm, bị LLM chất vấn, rồi trong quá trình đó tìm ra và làm rõ những lỗ hổng trong suy nghĩ, sau này còn có thể xem lại lịch sử chat, thường là phần hữu ích nhất
Đặc biệt ở giai đoạn đầu khi định hình một ứng dụng, nó rất hữu ích để theo dõi những việc lúc đó tôi nghĩ là cần làm và sau này xem xét lại liệu có còn đúng như vậy không
Họ nghe một buổi biểu diễn chuyên nghiệp ở câu lạc bộ rồi về nhà cố bắt chước, nhưng cuối cùng chỉ thành một khối hỗn loạn không có nền tảng. Ông nhấn mạnh rằng cần hài lòng với việc làm những điều đơn giản và dần dần xây dựng nền tảng vững hơn
Nhận xét này gần như áp dụng nguyên vẹn cho việc dùng mã do AI tạo ra
Đồ nội thất IKEA là một ví dụ hay. Nếu tự làm đồ nội thất, cảm giác khi ở xung quanh nó tốt hơn nhiều so với những thứ giống bìa carton của IKEA. Nhưng trong đầu mọi người, chi phí, tốc độ và sự tiện lợi dường như mới là quan trọng nhất
Mô hình AI tước đi trải nghiệm bẩm sinh đó và chỉ đưa cho ta phần kem trên cùng của kết quả cuối. Nó giống như xem phim khiêu dâm thay vì xây dựng một mối quan hệ thật để đi đến tình dục
Nếu dùng thông minh, những thứ kiểu Copilot sẽ có ích. Chúng xử lý boilerplate và các phần tẻ nhạt để con người tập trung vào suy nghĩ nặng hơn
Hơn nữa, vẫn còn rất sớm. Còn quá sớm để phán xét, và có vẻ nó cũng sẽ không biến mất
Phương pháp luận có vẻ so sánh hoạt động commit năm 2023 với các năm trước, rồi diễn giải thay đổi như một giả định trong khi không biết trong đó Copilot tham gia bao nhiêu. Đây là một cách tiếp cận khá lung lay
Ngoài ra còn nói “dự báo năm 2024 đã chạy hồi quy bậc hai trên dữ liệu hiện có bằng Assistant gpt-4-1106-preview của OpenAI”, nên tôi thắc mắc liệu họ có thật sự dùng GPT để hồi quy trên 4 điểm dữ liệu thay vì các công cụ hồi quy đơn giản như sklearn, R hay Excel không. Ngay cả nếu làm đúng, với 4 điểm dữ liệu cộng thêm mối lo ngại đầu tiên, sức thuyết phục vẫn yếu
Nói là hồi quy bậc hai nghe có vẻ hợp lý, nhưng với hai điểm dữ liệu thì thực chất chỉ là “kéo dài đường thẳng y như vậy”. Vì thế dự báo năm 2024 về bản chất gần như không có ý nghĩa
Tôi là tác giả của nghiên cứu gốc. Thật vui khi thấy nhiều người quan tâm đến chất lượng mã dài hạn. Việc churned code và mã trùng lặp, tức mã copy-paste, tăng lên trong năm 2023, còn moved code giảm xuống, thậm chí còn lớn hơn chúng tôi dự đoán
Tôi hy vọng các nhóm phát triển và những nhà tạo AI Assistant sẽ áp dụng các thước đo và cơ chế khuyến khích việc tái sử dụng mã hơn là mã mới được thêm vào. Đặc biệt, các nhóm dưới quyền những quản lý tin rằng nên đưa LoC vào đánh giá hiệu suất đang gặp rủi ro. Theo nghiên cứu của GitHub, khoảng một phần ba thuộc trường hợp này, và thế hệ công cụ hỗ trợ lập trình hiện nay khiến việc nhấn Tab rồi commit, gieo nợ kỹ thuật cho tương lai, trở nên quá dễ dàng. Như Adam Tornhill đã nói trên Twitter: “Thách thức cốt lõi của lập trình có hỗ trợ AI là việc tạo ra hàng loạt mã lẽ ra ngay từ đầu không nên viết trở nên quá dễ dàng”
Tuy nhiên, mức ý nghĩa của nghiên cứu hiện tại có hạn chế là không đo trực tiếp mã do AI viết. Nó chỉ vẽ ra tương quan giữa chất lượng mã và sự phổ biến của AI Assistant trong 4 năm qua. Sẽ thật tốt nếu GitHub hoặc các công ty AI Assistant khác hợp tác trong nghiên cứu tiếp theo để có thể đo trực tiếp khác biệt về chất lượng giữa “mã hoàn toàn do AI đề xuất”, “mã AI đề xuất nhưng con người chỉnh sửa”, và “mã được viết từ đầu”
Trong nghiên cứu tiếp theo, tôi cũng muốn đo trực tiếp tần suất lỗi thay đổi thế nào theo việc sử dụng AI. Nếu có ý tưởng khác đáng đo lường, mong mọi người đề xuất. Tôi dự định công bố một bài nghiên cứu mới khoảng 2 tháng một lần
Tái sử dụng mã có thể rất mạnh trong một codebase, nhưng tôi cũng đã thấy nó tạo ra sự hỗn loạn khi vượt qua ranh giới giữa các codebase. Nó có thể hữu ích, cũng có thể không phù hợp và gây rối; kết quả nhìn chung phụ thuộc vào khả năng phán đoán
Tôi nghĩ tốt hơn là đánh giá lập trình viên theo kết quả của phần mềm. Ví dụ như tác động lên tổ chức so với lượng tài nguyên sử dụng, hay lỗi dịch vụ không bắt nguồn từ các dịch vụ phụ thuộc hoặc hạ tầng
Lập trình viên hiện đại không chỉ chịu trách nhiệm về mã, mà là sự pha trộn có chủ ý giữa kỹ sư chất lượng/tester, quản lý sản phẩm kỹ thuật, quản lý dự án, lập trình viên, kỹ sư hiệu năng và kỹ sư hạ tầng. Tôi không có ý hạ thấp nghiên cứu này; tôi vui vì có người quan tâm sâu sắc đến chất lượng mã, và cho rằng chúng ta nên nghĩ khác về cách đánh giá
Tôi cũng tò mò liệu họ có kiểm soát các khả năng giải thích khác, chẳng hạn như nền kinh tế công nghệ đã thay đổi hay không
Bài này benchmark hiệu năng của các LLM phổ biến nhất trên các tác vụ refactoring mã thực tế, và cho biết AI chỉ cung cấp được refactoring đúng về mặt chức năng trong 37% trường hợp
Lập trình có AI hỗ trợ thực sự hữu ích, nhưng cần tiếp tục giữ con người có kinh nghiệm trong vòng lặp và đặt kỳ vọng thực tế, vượt ra ngoài sự phóng đại marketing
Quy trình làm việc của tôi thường là lướt qua tài liệu, tạo prototype, chỉnh mã một chút, thêm test, di chuyển, làm hỏng, làm lại, học tài liệu, refactor thêm, rồi cuối cùng mới hiểu vấn đề đủ để bỏ đi 80% mã và làm lại cho đúng
Nếu Copilot đưa cho tôi đoạn mã đủ chạy ở giai đoạn prototype khiến tôi cứ thế chuyển sang bước tiếp theo, thì tôi sẽ không hiểu đủ sâu để cấu trúc toàn bộ cho đúng. Nó giúp bỏ qua 90% quy trình làm việc, nhưng phải trả giá. Tất nhiên, ở giai đoạn cuối của phát triển, Copilot có thể rất hữu ích
Nếu kết quả nghiên cứu đúng thì không có gì đáng ngạc nhiên. Mã tệ đến từ sự hiểu biết thiếu hụt, và Copilot không thể có nhiều hiểu biết hơn những gì tôi cung cấp. Nó có thể viết mã tốt hơn lập trình viên trung bình, nhưng kết quả không thể tốt hơn đầu vào. Mọi người tập trung vào “prompt engineering” nhiều như vậy, nhưng tôi không hiểu vì sao lại ngạc nhiên khi “prompt” tệ của VSCode tạo ra kết quả tệ
Theo kinh nghiệm của tôi, Copilot rất tuyệt trong việc giúp khởi đầu. Mã có lúc tốt, có lúc bình thường hoặc hỏng hoàn toàn
Dù vậy, nó có giá trị ở chỗ giúp tôi bắt đầu suy nghĩ. Trước khi dùng nó, tôi lãng phí thời gian nhiều hơn hẳn. Có thể là do mạch não của tôi hơi khác thường
Tôi là junior và đã cài Codeium trong VSCode, nhưng trong phần lớn trường hợp nó rất gây xao nhãng. Tôi không hiểu lắm tại sao nhiều người lại dùng các công cụ trợ lý kiểu này đến vậy
Những thứ như Phind thì hữu ích. Khi có chuyện gì đó tôi không hiểu, khoảng 60% thời gian nó giúp tôi nắm được vấn đề. Kiểu như tìm ra những bug nhỏ mà tôi bỏ sót vì mệt hoặc ngớ ngẩn
Ngược lại, Codeium có thể hữu ích khi tạo boilerplate cho framework, nhưng trong trải nghiệm nhỏ của tôi với scraper, pipeline dữ liệu đơn giản, và JS thuần + HTML/CSS, việc phải lướt qua các đề xuất rất khó chịu. Đặc biệt là chúng thường không chạy, và dù chỉ vì những lý do nhỏ như thiếu một tham số, cuối cùng tôi vẫn phải tốn thời gian debug
Ngoài ra trong JavaScript có một phong cách phổ biến là nối phương thức và hàm ẩn danh thành chuỗi dài vô tận như dây xích, và tôi thật sự thấy rất vất vả với nó. Tôi thích tách dòng, đặt tên cho hàm và biến hơn. Các đề xuất code cũng thường theo phong cách đó, có lẽ vì dữ liệu huấn luyện là như vậy. Codeium nói là nó học theo điều này, và thực tế đôi lúc cũng đúng
Điều tôi lo nhất là, nếu một junior như tôi giao code cho các trợ lý kiểu này thì rốt cuộc học bằng cách nào. Việc đưa ngữ cảnh và câu hỏi cho Phind có thể giúp học, hoặc cho tôi hướng để tự tìm trên internet, nhưng chỉ nhấn Tab thì tôi không biết làm sao có thể học được
Vài ngày trước tôi nhận ra rằng rất nhiều người, gồm cả developer, đang dùng LLM không phải như công cụ để trở nên tốt hơn mà như thứ thay thế cho nỗ lực. Tôi nghĩ điều đó đáng sợ không chỉ vì sợ công ty thay thế mình, mà còn ở khía cạnh tự nhìn lại bản thân
Coding không phải đam mê của đời tôi, nhưng tôi thích nó. Vì nó cho phép tôi khiến điều gì đó xảy ra và xử lý độ phức tạp. Nếu không hiểu chuyện gì đang diễn ra, bạn không thể tạo ra thứ gì, cũng không thể nhận ra lúc nào độ phức tạp sẽ nuốt chửng mình
Cứ tiếp tục như vậy là được, nếu không thay đổi thì bạn sẽ đến được nơi tốt đẹp. Bạn chắc chắn đang đi đúng hướng
Điều quan trọng là trong sự nghiệp tôi đã viết API spec thủ công quá nhiều, nên 1) tôi có thể thấy vấn đề ngay lập tức và 2) có thể tự sửa mà không cần thêm trợ giúp. Sửa model bằng tay nhanh hơn tinh chỉnh prompt
Thật đáng kinh ngạc khi thấy nó làm trong 30 giây việc mà ở lĩnh vực tôi rành có thể mất cả buổi sáng. Tuy nhiên tôi không giao cho AI những việc mình không biết làm. Thay vào đó, tôi trò chuyện nhiều với AI về những thứ đang làm, như trade-off, vấn đề bảo mật tiềm ẩn, v.v.
Nó giống một kỹ sư junior có bằng tiến sĩ về ngôn ngữ tôi dùng. Không hiểu nhiều thứ, nhưng những gì nó hiểu thì trông như hiểu rất sâu
Một số developer, đặc biệt là JS developer, thích chaining dù nó chẳng đem lại lợi ích gì ngoài việc giữ mọi thứ trên một dòng. Đó không phải lợi ích. Cứ tiếp tục như hiện tại, đừng để idiom ngu ngốc này lây nhiễm vào đầu bạn
Khoảnh khắc công nghệ này gây ấn tượng là khi nó khớp với phong cách và sở thích của tôi. Nó đặt tên theo cách tôi muốn, và dùng đúng phương thức tôi vừa viết thay vì triển khai lặp lại
Tôi chưa dùng nhiều trong dự án trống hay dự án nhỏ, nhưng nếu nó không nghiêng mạnh theo cách tôi đã dùng dựa trên ngữ cảnh xung quanh, tôi nghĩ cảm giác sẽ kém lý tưởng hơn nhiều
Công dụng lớn nhất của trợ lý AI là viết test và đẩy nhanh các thay đổi lặp kiểu “giống cái này nhưng hơi khác”. Trong IntelliJ + GitHub, với những việc một tham số mới cần được phản ánh qua nhiều method và file, sau khi tự nhập hai ba biến thể đầu tiên thì phần sau thường chỉ cần enter + tab. Ngữ cảnh sẽ điền nốt phần còn lại
Codeium trên VSCode có vẻ bản thân AI cũng chưa đủ tốt, và plugin dường như được viết theo cách khiến phím đề xuất và chấp nhận thường xuyên gây cản trở. Nó vẫn hữu ích cho việc lặp lại, nhưng kém hơn trong việc đề xuất cách đạt mục tiêu
Tôi quyết định thử tạo một clone của Yourls dựa trên Django/Python bằng ChatGPT. Tôi đã chỉ dẫn cụ thể rằng nó phải cho phép URL rút gọn tùy chỉnh và theo dõi traffic, nhưng nó không thật sự tính đến điều đó trong logic hay mô hình dữ liệu. Muốn sửa về sau thì lại phải nạp thêm chỉ dẫn cụ thể
Công cụ AI giống một developer junior làm việc giúp bạn. Chỉ là nhanh hơn nhiều
Nếu không biết mình đang làm gì, nó chỉ tăng tốc độ mắc lỗi
Gần đây tôi cần thêm tiền tố tên bảng vào alias của các cột trong câu SELECT, nhưng không có tính năng như vậy, nên tôi đưa định nghĩa schema và query cho ChatGPT rồi nhờ nó viết ra danh sách chọn khoảng 40 cột thật dài
Tôi không tìm được cách hay để tự động hóa việc này trên nhiều RDBMS, và dù regex hoặc các thao tác văn bản khác cũng có thể làm được, cách giải thích vấn đề rồi nhận output cần thiết đơn giản đến mức dễ chịu
Ngoài ra tôi dùng LLM như autocomplete. Nó cũng có tác dụng khiến tôi đặt tên hàm tốt hơn, vì chỉ với chừng đó thông tin, LLM thường có thể đưa ra một điểm khởi đầu hợp lý. Đặc biệt hữu ích với API hoặc ngôn ngữ tôi chưa dùng nhiều, khi vấn đề tôi gặp đã được giải hàng nghìn lần. Tôi gần như không dùng StackOverflow nữa
Vì vậy tôi đã mua Copilot và cũng dùng ChatGPT rất nhiều. LLM là một trong những thứ tôi thích nhất, cùng với autocomplete tốt kiểu IntelliSense, tạo đặc tả OpenAPI hoặc code EF/JPA, migration DB/tạo bảng dựa trên mô hình ER, container, và các IDE thông minh như JetBrains
Các công ty sẽ muốn nhiều code hơn với tốc độ nhanh hơn, và có vẻ trong vòng xoáy đó sẽ càng ít người thật sự biết mình đang làm gì
Toàn văn bài nghiên cứu ở đây: https://gitclear-public.s3.us-west-2.amazonaws.com/Coding-on...
Ngay cả trước khi các công cụ hỗ trợ “AI” xuất hiện trên thị trường, đã có sự phản đối đối với mã DRY, và đáng tiếc là đó là một xu hướng ngày càng lớn khi tôi dùng Twitter trong giai đoạn 2019–2022
Một số lập trình viên trẻ có thái độ với code rất khác so với những gì tôi được học. Họ cực kỳ khinh miệt Gang of Four và các design pattern, và dường như không biết rằng framework họ yêu thích lại đầy rẫy chính những pattern đó. Họ nói mỉa mai các nguyên tắc như DRY, đặc biệt là SOLID
Ở những nơi như Twitter, lời lẽ càng mỉa mai và càng công kích phe đối lập thì tương tác càng tăng. Đây là một xu hướng khá đáng lo
Tôi cũng cảm thấy cực kỳ khinh miệt những gì diễn ra trong các codebase doanh nghiệp. Dù các guru SOLID nói gì đi nữa, việc chồng chất các lớp gián tiếp bằng class không phải là ổn. Best practices, DRY, SOLID chỉ được dùng như cái cớ
Điều tôi không chịu nổi là việc xem một danh sách nguyên tắc tùy ý xuất phát từ tư duy hướng đối tượng kiểu Java như chân lý của mô hình hóa phần mềm. Tôi cũng phát ngán với cuộc tranh luận lần thứ n về việc nên hiểu SOLID như thế nào
Người ta không cãi nhau như vậy về định lý CAP, vì nó không phải là một nhóm ý tưởng tùy tiện được ghép lại để tạo thành một acronym nghe hay
DRY cũng có thể bị lạm dụng, và người ta chỉ phản ứng với thái độ xem nó như hoàn hảo mà thôi
Ví dụ, nguyên tắc quan trọng của DRY không phải là đừng lặp lại code, mà là đừng lặp lại ý tưởng. Với bất kỳ khái niệm nào trong hệ thống, lý tưởng nhất là nên có một nguồn sự thật duy nhất, và khi xử lý khái niệm đó thì cũng chỉ nên có một nơi cần hiểu hoặc thay đổi
Vì vậy, việc copy-paste một lượng code không nhỏ thay vì tạo ra abstraction có ý nghĩa thường là điều xấu. Đồng thời, đó cũng là lời cảnh báo rằng ngay khi bạn lặp lại một ý tưởng, bạn tạo ra một khoản nợ liên tục: phải giữ cho các biểu diễn khác nhau đồng bộ với nhau. Điều này áp dụng cho DB migration định nghĩa schema và các class ORM riêng biệt, backend API và frontend client, giá trị form và trạng thái nội bộ trong retained mode UI, cũng như các bất biến của data model được biểu diễn cả trong type lẫn unit test
Những người phản đối việc ép gộp các ý tưởng khác nhau chỉ vì chúng tình cờ có implementation giống nhau, bởi điều đó sau này trở thành rủi ro bảo trì, không hề sai. Chỉ là họ đang tấn công một người rơm vốn không phải là ý chính ban đầu của DRY
Giờ vấn đề là các lập trình viên mới sẽ học các nguyên tắc này đúng cách ở đâu và khi nào. Có người có nền tảng chuyên ngành, nhưng không phải ai cũng vậy, và các chương trình CS mang tính học thuật cũng không nhất thiết phải dạy nhiều kỹ năng phát triển phần mềm thực tế
Khi tôi mới bắt đầu, các senior đã đào tạo junior một cách thực tế và khá đáng kể, nhưng với văn hóa nhảy việc thường xuyên hiện nay và bầu không khí ngại tuyển junior như một khoản đầu tư dài hạn, có vẻ chuyện đó đã ít đi rất nhiều. Các khóa học chính thức thì đắt với cá nhân, nhưng gần như không đáng kể theo tiêu chuẩn công ty; dù vậy, số lập trình viên mới thực sự được công ty cử đi học chắc sẽ rất ít
Cũng có những cuốn sách đáng đọc, nhưng tôi không biết những người ở độ tuổi 20 vào năm 2024 có sẵn lòng tiếp cận một định dạng cũ kỹ được in bằng mực trên những mảnh cây bị cắt ra hay không. Các lập trình viên đang trưởng thành ngày nay dường như học nhiều ý tưởng kiểu này từ blog và YouTube; ở đó cũng có tài liệu tuyệt vời, nhưng vấn đề luôn là phải tìm chúng giữa đống rác không hiểu đúng vấn đề hoặc được đóng gói một cách đáng ngờ
Vì vậy, khi một công cụ kỳ diệu xuất hiện, có thể tạo ra 12 dòng code chạy tạm được chỉ trong một nhịp tim, cũng không có gì ngạc nhiên nếu các lập trình viên trẻ nghĩ đoạn code đó thật tuyệt trong khi hầu như không biết các vấn đề sâu hơn của nó. Khó nói đó là lỗi của ai, nhưng rõ ràng đây là một vấn đề, và tôi ước gì biết phải làm gì