- Đã khoảng 2 năm kể từ khi các công cụ hỗ trợ lập trình dựa trên LLM được ra mắt
- Một số nhà phát triển báo cáo rằng năng suất đã tăng tới 5 đến 10 lần
- Tuy nhiên, không có bằng chứng rõ ràng cho thấy năng suất của toàn bộ ngành phần mềm đã tăng 5–10 lần
- Trên thực tế, ngoài việc thêm các tính năng dạng boilerplate đơn giản vào codebase, công cụ LLM thường hoạt động khá khó khăn
- Phần lớn lập trình viên либо không biết cách sử dụng hiệu quả công cụ LLM, либо không quan tâm đến chúng
Vì sao mức tăng năng suất chỉ tập trung ở một số người dùng nhất định
- Nếu năng suất thực sự tăng 5 đến 10 lần, rất có thể điều này chỉ giới hạn ở một số ít power user hoặc nhà phát triển lành nghề biết cách khai thác LLM
- Không có dấu hiệu nào cho thấy toàn ngành phần mềm đang cung cấp nhiều tính năng hữu ích hơn một cách đột biến hoặc chất lượng đã cải thiện rõ rệt
- Tác giả gần như không cảm nhận được ảnh hưởng của LLM trong 1–2 năm qua
Thực sự thì LLM đã giúp những dự án nào trở nên khả thi?
- Chưa xác định rõ những dự án nào được kích hoạt nhờ hiệu năng của LLM
- Ngay cả trong các kết quả nghiên cứu cũng hầu như không tìm thấy ví dụ cụ thể nào (refactor COBOL gần như là ví dụ duy nhất)
- Ngay cả các sản phẩm dựa trên LLM từ những viện nghiên cứu AGI cũng không cho thấy thành quả đặc biệt ấn tượng
- Chủ yếu chỉ cung cấp các tính năng cơ bản như tải PDF lên trong hộp thoại chat
- Còn thiếu khả năng để LLM giao tiếp trơn tru với nhiều loại phần mềm và dữ liệu khác nhau
Câu hỏi: Có lĩnh vực nào thực sự tăng năng suất không?
- Không có bằng chứng rõ ràng về việc dự án nào đã được phát hành nhanh hơn nhờ LLM
- Cũng không thấy dấu hiệu cho thấy một lĩnh vực cụ thể nào trong hệ sinh thái phần mềm đã tăng trưởng gấp 10 lần
Điều mong muốn là bằng chứng thực tế, rõ ràng
- Không cần những loại thông tin như sau
- Những tuyên bố mơ hồ về việc năng suất tăng 10 lần
- Các chỉ số kinh tế trừu tượng hay nhắc đến việc tăng sản lượng mã nguồn
- Các ví dụ đơn thuần về việc tạo công cụ hay tính năng dựa trên LLM
- Những ví dụ nhỏ nhặt kiểu “tạo bản clone Snake bằng ChatGPT”
Giả thuyết: Có thể LLM thực ra không làm tăng năng suất thực tế
- Thời gian lại bị tiêu tốn vào việc chỉnh sửa mã do LLM tạo ra và xử lý vấn đề phát sinh
- Khi codebase lớn do LLM tạo ra vượt qua một mức độ phức tạp nhất định, nó có thể trở nên không thể chỉnh sửa và cuối cùng phải viết lại từ đầu
- Ngay cả khi LLM tạo ra phần mềm mới, phần lớn cũng có thể chỉ là công cụ dùng một lần hoặc mã minh chứng không được sử dụng
- Ngay cả trong phần mềm thực sự hữu ích, việc tăng lượng mã cũng có nguy cơ kéo theo các tính năng không cần thiết hoặc bloatware
- Có khả năng các lập trình viên đang bị đánh lừa bởi trải nghiệm “ma thuật” khi nhận được kết quả tức thì từ LLM
Phạm vi tăng năng suất thực tế
- Theo trải nghiệm của tác giả, LLM chỉ hữu ích trong một số trường hợp cụ thể sau
- Viết các tính năng nhỏ nhặt
- Hỗ trợ học một thư viện hoặc codebase cụ thể
- Thực hiện các tác vụ refactor đơn giản
- Mức tăng năng suất nhiều khả năng chỉ vào khoảng 10–30%
- Rất khó để tối đa hóa năng suất trước khi AGI (trí tuệ nhân tạo tổng quát) xuất hiện
[Bình luận của Richard Horvath]
Những trường hợp LLM có thể mang lại tốc độ nhanh hơn 10 lần trong tình huống cụ thể
- Viết các script nhỏ, độc lập
- Khi viết các tác vụ đơn giản (ví dụ: script bash để thao tác tệp, mã Excel VBA), LLM cho kết quả rất tốt
- Có thể tạo dễ dàng chỉ với mô tả ngắn gọn và cũng dễ xác minh
- Có thể viết được ngay cả khi không có hiểu biết sâu về ngôn ngữ
- Không cần cân nhắc đến bảo trì, mô-đun hóa hay unit test
- Đặc biệt hiệu quả với các tác vụ liên quan đến biểu thức chính quy (regex)
- Tăng tốc độ học khi làm việc với stack xa lạ
- Có thể nhanh chóng nắm được class và method của thư viện mới
- Dù mã tạo ra không hoạt động hoàn toàn, nó vẫn cung cấp hướng tiếp cận để giải quyết vấn đề
- Giảm mạnh thời gian vốn phải bỏ ra để tìm tài liệu hoặc khóa học
- Tuy nhiên, mã được tạo ra vẫn cần tự chỉnh sửa và refactor
Những người báo cáo mức tăng năng suất 10 lần có thể thuộc các nhóm sau
- Thiếu kiến thức phát triển phần mềm
- Nếu kỹ năng lập trình cơ bản còn yếu, mã do LLM hỗ trợ tạo ra có thể trông vượt trội hơn hẳn so với trước đây
- Tuy nhiên, trong trường hợp này mã từ LLM có nhiều khả năng gây ảnh hưởng tiêu cực về lâu dài
- Phải viết nhiều giải pháp nhỏ, độc lập
- Các công việc như tự động hóa Excel hay viết shell script trong DevOps là những nơi LLM đặc biệt hữu ích
- Thường xuyên phải thử nghiệm nhiều stack và thư viện khác nhau
- Đây là các trường hợp công việc thiên về thử nghiệm hơn là làm lâu dài trên một stack cố định
- Xảy ra hiệu ứng neo (Anchoring Effect)
- Khi LLM tạo ra kết quả tức thì ở một số tác vụ, người dùng có thể dễ dàng đánh giá quá cao điều đó thành mức tăng năng suất dài hạn
[Bình luận của Davidmanheim]
- Từ góc nhìn của những người viết mã trong các công ty thông thường và cả giới quản lý, mức tăng năng suất do LLM mang lại trên thực tế có thể chỉ ở mức hạn chế
- Điều này có thể được giải thích bằng góc nhìn của Theory of Constraints:
- Giả sử trước đây công việc được hoàn thành qua quy trình như sau:
- Business Analyst → mất 1 ngày
- QA tester → mất 1 ngày
- Lập trình viên → mất 1 ngày
- Ngay cả khi năng suất của lập trình viên tăng 2 lần hoặc 5 lần, tổng thời gian công việc vẫn không rút ngắn
- Vì các giai đoạn khác (phân tích nghiệp vụ và QA) trở thành nút thắt cổ chai nên tốc độ của toàn quy trình vẫn giữ nguyên
- Cần tái cấu trúc quy trình doanh nghiệp
- Để tận dụng tối đa mức tăng năng suất từ LLM, cần tái cấu trúc toàn bộ quy trình của doanh nghiệp
- Nhưng hiện tại mới chỉ có một số công ty bắt đầu tiến hành kiểu tái cấu trúc này
[Bình luận của faul_sname]
- Với LLM, người viết đặc biệt trải nghiệm hiệu quả trong việc tạo UI mockup như sau:
- Trước đây, việc tạo UI mockup chiếm khoảng 10% tổng thời gian làm việc
- Nhờ LLM, tốc độ tạo UI mockup nhanh hơn khoảng 5 lần
- Tuy nhiên, tổng thời gian công việc tự nó không giảm
- Thay vào đó, mức độ chi tiết và tính tương tác của UI mockup được cải thiện mạnh
- Có thể lặp lại nhiều hơn, nhờ đó chất lượng sản phẩm cuối cùng được nâng lên
- “Mã sẽ bị vứt bỏ” không nhất thiết có nghĩa là vô dụng
- Ngay cả prototype hay mã minh chứng cũng có thể đóng góp vào việc phát triển sản phẩm cuối cùng tốt hơn
- Ngoài ra, LLM còn đưa ra câu trả lời cho những lỗi cụ thể khó tìm bằng công cụ tìm kiếm
- Ví dụ: “cách giải quyết lỗi phát sinh từ tác vụ đang chạy trên stack xyz”
- Có thể hỗ trợ debug trong các bối cảnh stack và cấu hình Kubernetes cụ thể
- Mức tăng năng suất tổng thể được đánh giá vào khoảng 10–30%
- Tuy nhiên, năng suất không tăng đồng đều ở mọi công việc
- Một số tác vụ có tốc độ cải thiện đột phá (ví dụ: UI mockup, debug)
- Hầu như không có kết quả đáng kể với công việc phức tạp hoặc code legacy
- Mức tăng năng suất nổi bật ở giai đoạn đầu dự án, nhưng giảm đi ở giai đoạn bảo trì phức tạp
- Vì vậy, giới hạn ở đây theo người viết không phải là thiếu agency mà là vấn đề quản lý ngữ cảnh (context management)
[Bình luận của Noosphere89]
- Trích dẫn quan điểm của Ajeya Cotra, người viết nêu ra các điểm sau về tác động của LLM đối với năng suất của lập trình viên:
- Năng suất của AI trong công việc lập trình cao hơn dự đoán
- AI đang đạt thành quả đáng kể trong các tác vụ lập trình
- Tuy nhiên, với các tác vụ ngoài lập trình thì hiệu năng giảm đi rất nhiều
- Vì vậy, tác động công nghiệp tổng thể của AI hiện vẫn còn hạn chế
- Các liên kết đến phát biểu liên quan của Ajeya Cotra
- Về lập luận rằng “cần AGI để tạo ra thành quả dài hạn”
- Trên lộ trình phát triển AI hiện nay, tính năng lực tổng quát (Generality) có vẻ ít hơn dự đoán
- Hiệu năng AI thường tăng vọt ở một số tác vụ cụ thể hoặc bộc lộ điểm yếu ở một số lĩnh vực nhất định
- Chính sự mất cân bằng về hiệu năng này có thể khiến khái niệm AGI (trí tuệ nhân tạo tổng quát) trở nên kém hữu ích hơn dự kiến
[Bình luận của yo-cuddles]
- Ví dụ về một người làm robotic process automation (RPA) trong văn phòng của tôi
- Anh ta khẳng định rất mạnh rằng mình làm việc hiệu quả hơn nhiều
- Nhưng trên thực tế, công việc của anh ta kém hiệu quả và thiếu tin cậy, khiến người khác phải tốn thời gian sửa lại
- Đồng nghiệp đang cố loại anh ta khỏi workflow
- Con người không đo lường chính xác năng suất của bản thân mà thường chỉ nhận thức rõ một số thành quả hoặc tổn thất nhất định:
- Tập trung vào thành quả dễ thấy
- Khi hoàn thành nhanh công việc bằng phương pháp tự động hóa, cảm giác thành tựu đến ngay lập tức
- Vì kết quả nhanh hiện ra tức thì nên nó được cảm nhận như tác động tích cực
- Chi phí dài hạn khó được nhận ra
- Chi phí thời gian phát sinh sau đó rất khó bị theo dõi
- Đặc biệt khi vấn đề do người khác sửa, cái giá đó lại càng khó nhìn thấy
- Ngay cả khi lỗi phát sinh từ công việc tự động hóa đã được sửa, việc lãng phí thời gian do nó gây ra cũng khó cảm nhận
- Các vấn đề do mã LLM tạo ra càng khó được nhận biết vì những lý do sau:
- Khó truy vết chính xác nguyên nhân bug là do mã LLM
- Trong quá trình sửa lỗi, người khác có thể phải tốn thêm thời gian
- Người dùng không nhận ra nguyên nhân gốc rễ của vấn đề và không hiểu rằng đó là hậu quả của việc dùng công cụ tự động hóa
- Cảm giác “nhờ tự động hóa mà xong nhanh hơn” rất rõ rệt, nhưng “thời gian bị lãng phí vì tự động hóa” thì khó cảm nhận
- Dù việc dùng LLM đã trở nên phổ biến, mức tăng năng suất trên toàn ngành vẫn chưa thể hiện rõ ràng
- Mọi người nói rằng mình “năng suất gấp 2 lần”, nhưng thực tế rất có thể năng suất còn giảm do các vấn đề ẩn
- Nói cách khác, vì thời gian và tài nguyên tiêu tốn cho việc xử lý sự cố không hiện rõ nên nhận thức về thành quả bị phóng đại
6 bình luận
Cảm giác này khá giống với trải nghiệm của tôi.
Trong những trường hợp như trên, tôi đã tiết kiệm được khá nhiều thời gian. Nhiều lúc với tổ hợp Google + Stack Overflow cũng không dễ tìm ra, mà đặc biệt trên Stack Overflow thì hễ có câu trả lời nào là trong phần bình luận cũng luôn có rất nhiều ý kiến phản đối, rồi còn chuyện đó là cách triển khai của phiên bản cũ nên không nên dùng nữa, kiểu vậy, nên nhiều khi thấy khá bực mình...
Có vẻ mức năng suất tăng 10x chỉ xuất hiện khi làm prototype.
Tôi thấy khá ngọt ngào.
> Phần lớn lập trình viên không biết cách sử dụng hiệu quả các công cụ LLM hoặc không quan tâm
Điều khá bất ngờ là nhiều lập trình viên xung quanh lại không mấy quan tâm đến công nghệ. Họ dành phần lớn thời gian để máy móc chìm đắm trong những video YouTube Shorts mới hoặc lặp đi lặp lại.
Ý kiến trên Hacker News
Đang làm việc tại một công ty công nghệ nổi tiếng ở Seattle và bị ép buộc phải dùng AI. Ban lãnh đạo đang theo dõi mức độ sử dụng AI của các lập trình viên, thậm chí còn trực tiếp hỏi vì sao cá nhân tôi không dùng AI nhiều hơn. Tôi tin rằng điều quan trọng là dùng đúng công cụ cho đúng việc, và AI không phải lúc nào cũng phù hợp
Có một câu châm ngôn cũ trong các dự án phần mềm rằng 10% cuối cùng của dự án chiếm tới 90% thời gian. AI hữu ích ở 90% đầu tiên, nhưng không giúp được ở 10% cuối cùng
Đang dùng LLM được tích hợp vào IDE tại FAANG, và có một số hiệu quả tích cực nhẹ
Một ví dụ về lập trình viên thực sự trải nghiệm mức cải thiện gấp 10 lần là Pieter Levels, người đã code một trình mô phỏng bay 3D nhiều người chơi chỉ trong vài ngày
Đã thử dùng LLM để sinh code nhưng lúc đầu năng suất còn giảm
Là thành viên của nhóm phát triển Copilot Autofix trên GitHub, công cụ đưa ra đề xuất sửa lỗi dựa trên các cảnh báo CodeQL
Chất lượng câu trả lời từ các trợ lý code dùng LLM bị ảnh hưởng rất lớn bởi khả năng giao tiếp của lập trình viên
Giả định rằng năng suất phần mềm chưa tăng 5-10 lần có thể là sai
Có vẻ mục cuối cùng trong bản dịch tóm tắt ý kiến Hacker News, "Có thể giả định rằng năng suất phần mềm đã không tăng 5-10 lần là sai", là một bản dịch sai. Nếu xem nguyên văn, có lẽ nên tóm tắt theo hướng an toàn hơn như: "Việc nói rằng năng suất phần mềm đã tăng 5-10 lần dựa trên một giả định sai về mức cải thiện năng suất".