- Có những lập trình viên gặp khó khăn trong việc tạo ra giá trị rõ ràng khi sử dụng LLM cho lập trình
- Một số người dùng không hài lòng với chất lượng đầu ra của LLM
- Với yêu cầu cụ thể hoặc các vấn đề phức tạp, LLM có xu hướng không đáp ứng được kỳ vọng
- Ngược lại, ở các tác vụ tự động hóa đơn giản hoặc công việc lặp lại, người dùng vẫn cảm nhận được một mức độ tiện lợi nhất định
- Các lập trình viên đang tìm kiếm cách cải thiện prompt engineering hoặc quy trình làm việc
Thảo luận về khó khăn khi dùng LLM cho lập trình và cách cải thiện
Giá trị còn hạn chế của LLM
- Gần đây, nhiều lập trình viên đang thử nghiệm các LLM cho lập trình như ChatGPT, GitHub Copilot, Claude cho nhiều mục đích khác nhau
- Tuy nhiên, không ít người dùng cho biết họ không cảm nhận được mức tăng năng suất thực tế như kỳ vọng
- Đặc biệt, trong việc viết thuật toán phức tạp, cấu trúc hóa mã nguồn quy mô lớn, hay thiết kế kiến trúc dự án, mã do LLM gợi ý thường rời rạc hoặc kém hiệu quả
Bất mãn về chất lượng đầu ra
- Một số lập trình viên cho biết mã do LLM cung cấp có thể chứa bug, hoặc tạo ra kết quả thiếu chính xác do không hiểu đầy đủ ngữ cảnh
- Cũng thường xảy ra trường hợp phần giải thích hoặc phân tích còn thiếu, hoặc mã không phản ánh đúng độ phức tạp và bối cảnh của dự án
Hữu ích trong các lĩnh vực sử dụng đơn giản
- Ở khía cạnh tự động hóa ở mức cơ bản như tạo đoạn mã ngắn, xử lý công việc lặp lại, hay giải quyết các vấn đề cú pháp đơn giản, có thể thấy rõ sự tiện lợi
- Khả năng áp dụng vào các công việc mang tính thường lệ như kiểm thử đơn vị, refactoring, hay chỉnh sửa style code được đánh giá khá cao
Những nỗ lực để cải thiện
- Một số lập trình viên đang tích cực áp dụng các kỹ thuật prompt engineering để có được kết quả tốt hơn
- Họ cũng đang thử nghiệm những cách sử dụng LLM phù hợp với workflow của riêng mình, cũng như kết hợp với nhiều công cụ mã nguồn mở khác
Kết luận và bài học
- Ở thời điểm hiện tại, nhiều người thừa nhận rằng LLM chưa thể là lời giải vạn năng cho mọi nhu cầu phát triển phần mềm
- Cộng đồng và các lập trình viên đang chia sẻ kinh nghiệm để tìm ra chiến lược sử dụng hiệu quả và cách vượt qua các giới hạn hiện có
1 bình luận
Ý kiến trên Hacker News
Tôi có cảm giác có hai kiểu lập trình viên. Một kiểu thì nói LLM là siêu năng lực tuyệt đối cho việc code, năng suất tăng 100 lần; kiểu còn lại thì xem nó là một công cụ khá khó chiều, phải tốn nhiều công sức mới ra được kết quả chỉ ở mức bình thường. Nhưng nếu kiểu thứ nhất thật sự đang được LLM nâng năng suất đột phá đến vậy, chẳng phải họ đã nên thống trị thị trường và quét sạch đối thủ từ lâu rồi sao?
Với công việc greenfield, tôi thực sự có cảm giác năng suất tăng tới 100 lần nhờ LLM. Ví dụ, thêm khung cơ bản cho một ứng dụng React như nhiều trang, Redux store, xác thực... thì nó có thể dựng rất nhanh chỉ trong vài phút. Chỉ cần bảo “giờ thêm X đi” là thường cho ra kết quả khá ổn. Nhưng với bảo trì hệ thống hiện có, thêm tính năng phức tạp, hay những tình huống mà hiểu biết domain là quan trọng thì LLM lại không mấy hữu ích. Nó tốt cho autocomplete code hoặc hoàn thiện các hàm, nhưng đến bước triển khai cả tính năng thì nhanh chóng chạm trần. Trong các trường hợp như vậy, thời gian giao việc cho LLM gần như ngang với việc tự tôi code. Vì thế thường tôi sẽ viết trước stub code theo đúng cấu trúc mình muốn, rồi chỉ để LLM điền vào chỗ trống. Những người nói LLM giúp tăng năng suất 100 lần có lẽ mới chỉ gặp phần dễ, hoặc chưa đụng phải phần khó. Thực tế thường là 90% công việc thì dễ, còn 10% cuối mới là phần thực sự khó, và LLM lại làm không ra ở đúng đoạn đó.
Nói hơi mỉa mai một chút, những người nói năng suất tăng 100 lần thực ra chỉ đang nhân 100 lên từ một con số nhỏ. Ở giai đoạn nghiên cứu, LLM giúp cực kỳ nhiều. Ví dụ gần đây tôi phải viết mã đại số tuyến tính chuyên cho một số domain nhất định, không thể dùng thư viện như LAPACK nên phải tự triển khai. Trong những lúc như vậy, dùng LLM thay cho sách tham khảo để gom thông tin mình cần trong một lượt đúng là có thể rút ngắn thời gian nghiên cứu xuống 100 lần. Nhưng khi giao phần triển khai mã thực tế cho LLM, nó lại chèn vào những lỗi tinh vi mà nếu không phải chuyên gia thì khó nhận ra. Một junior có thể sẽ bỏ qua luôn. Tôi rất coi trọng code review, nên dù LLM có giỏi hơn nữa thì tốc độ viết code của bản thân tôi có lẽ cũng không tăng quá nhiều. Tuy vậy, ở giai đoạn khám phá và tóm tắt để quyết định nên viết loại mã nào thì LLM tăng tốc cực mạnh. Cuối cùng, thứ tạo ra giá trị thật cho thế giới vẫn là đột phá và ý tưởng sáng tạo, và tôi nghĩ phần đó vẫn là việc của con người. LLM sẽ là trợ thủ quan trọng, nhưng mã có giá trị cao thì tôi vẫn tin nên tự tay viết.
Thực ra còn có những người không thuộc hẳn bên nào trong hai nhóm đó. Không phải tăng năng suất 100 lần, nhưng cũng chẳng phải dùng trong khổ sở. Tôi đã code chuyên nghiệp hơn 30 năm, và lúc nào cũng phải tra cứu thứ gì đó, thường xuyên quên ngôn ngữ hay cú pháp cụ thể. Nhiều công việc cũng buộc phải luân phiên dùng nhiều ngôn ngữ. Trước đây phải lục sách tham khảo, manual, thậm chí cả những tài liệu còn khó dùng hơn. Sau này có công cụ tìm kiếm như Google thì đỡ hơn đôi chút, rồi những nền tảng như Stack Overflow còn hiệu quả hơn nữa. Giờ thì LLM đơn giản là một bước tiến tiếp theo. Gợi ý autocomplete đôi khi chính là manh mối tôi đang tìm. Tất nhiên cái nào không cần thì bỏ qua, nhưng giao diện chat cho phép hỏi đáp mang tính đối thoại hơn hẳn Google hay tìm kiếm trên SO nên rất tiện.
Tôi đang học toán bằng Math Academy, ChatGPT và YouTube, đặc biệt là 3Blue1Brown. Nếu không có bộ này thì chắc rất khổ, còn bây giờ lại thấy vui. Trước đây khi học một khóa tương tự ở University of Amsterdam, ChatGPT chưa thông minh như hiện tại nên khó hơn rất nhiều. ChatGPT còn trả lời được cả những câu hỏi mà giáo viên khó lòng giải đáp, điều này rất hợp với tôi vì tôi cần hiểu cả bối cảnh văn hóa của toán học thì mới thấy đồng cảm và nghĩ ra cách giải sáng tạo. Chẳng hạn, khi tôi hỏi vì sao người ta dùng chữ m cho góc, nó giải thích rằng về mặt lịch sử m đến từ measure. Nhờ vậy giờ tôi có thể tập trung trở lại vào phần cốt lõi của toán học. Công thức tính phương sai nhanh cũng được ChatGPT giải thích rất dễ hiểu. Nó không phải công cụ để thống trị thế giới, nhưng nhờ nó tôi đang học được những kiến thức mà lẽ ra mình đã không học được. Tất nhiên vai trò của YouTube và Math Academy cũng rất lớn.
LLM là siêu năng lực cho những người làm nhiều mảng rộng mà không phải chuyên gia ở mọi phần. Nếu bạn chỉ đào rất sâu vào một lĩnh vực cụ thể và lúc nào cũng chỉ làm đúng việc đó thì nó lại không mấy hữu dụng. Ví dụ, khi mỗi dự án chỉ cần viết Dockerfile một lần và không có sẵn chuyên gia triển khai, thì dùng LLM để viết Dockerfile là cực kỳ tuyệt. Những lỗi cú pháp nhỏ hay vấn đề lặt vặt cũng giải quyết nhanh hơn Google. Bạn có thể nhờ LLM phân tích các trade-off kiến trúc, rồi tự mình đưa ra quyết định cuối cùng để cải thiện năng suất. Tuy nhiên, phải giới hạn phạm vi bằng prompt để LLM khỏi làm chuyện ngớ ngẩn, và trên thực tế nó thường xuyên bịa ra API không tồn tại cùng đủ kiểu sai lầm vô lý, nên vẫn cần sửa đi sửa lại. Dù vậy, ngay cả khi phải lặp lại thì vẫn có lợi thế về tốc độ.
Tôi cũng dùng LLM theo nhiều cách khác nhau. Tôi nhờ nó ở những bài toán debug nhỏ, shell script, code, hỏi đáp và nhiều tình huống khác. Trong việc cá nhân, ngoài Claude và OpenAI tôi còn dùng cả Google hay Perplexity và chọn công cụ cho kết quả tốt nhất. Trong công việc, tôi dùng Claude, OpenAI và Google qua VSCode với Copilot hoặc nền tảng nội bộ, cũng thử nghịch Copilot Studio một chút. Tôi đã làm việc kiểu này hơn một năm rưỡi rồi; không phải lúc nào cũng dùng mọi công cụ, nhưng ấn tượng chung là thế này. Rõ ràng LLM có giúp tăng năng suất. Tôi thử nghiệm với nhiều ngôn ngữ lập trình, hiểu rõ hơn về nhiều chủ đề, nên một số việc đúng là dễ hơn hẳn. Nhưng bất kể mô hình hay phiên bản nào, vẫn thấy rất rõ rằng khi công việc trở nên phức tạp hơn, hoặc đi theo hướng riêng thay vì chỉ ghép các mảnh đơn giản, thì tất cả đều có xu hướng thất bại. Thậm chí có lúc thời gian sửa đống kết quả tào lao của LLM còn ăn hết sạch phần thời gian đã tiết kiệm được lúc đầu. Kết luận thành thật lúc này của tôi là LLM hữu ích cho autocomplete mã nhỏ, debug và giải thích, nhưng cũng chỉ đến thế. Nó chưa thể đe dọa công việc của chúng ta ngay bây giờ.
Khi học thư viện, API hay ngôn ngữ mới, LLM giúp tôi rất nhiều. Ví dụ như cách render text trong OpenGL: hỏi LLM trực tiếp vẫn nhanh hơn nhiều so với việc đọc một đống tài liệu chính thức vừa dài vừa lộn xộn. Hoặc khi phải viết những đoạn boilerplate lặp đi lặp lại, nhàm chán mà trong code hiện có lại không có gì để tham khảo, thì LLM rất hữu ích. Nhưng ở phần mà tôi xem là “công việc” thực sự, tức vùng mã đặc thù riêng của dịch vụ mình, thì LLM không quá hữu dụng theo nghĩa “viết code thay mình”. Là một kỹ sư senior, thời gian tôi thực sự tiêu vào việc gõ code gần như không đáng kể; thứ quan trọng là thiết kế cấu trúc, refactor legacy, vấn đề hiệu năng, debug các bug hiếm... LLM chỉ giúp tăng tốc phần viết mã lặp lại, nên trừ khi bạn tuần nào cũng tạo dự án mới từ đầu, còn không thì giá trị của nó không lớn lắm. Nếu bạn vẫn còn viết nhiều boilerplate, có lẽ cũng nên nghĩ đến các giải pháp gốc rễ khác thay vì chỉ dựa vào LLM.
Đọc kỹ tài liệu chính thức lộn xộn và giải thích lại: ở điểm này LLM rõ ràng giỏi hơn một lập trình viên bình thường rất nhiều. Trong mảng đó, nó thực sự tạo thêm giá trị. Cũng có những ngôn ngữ có quá nhiều boilerplate mà.
Không có viên đạn bạc nào cả, và phần khái niệm hóa mới là chỗ thực sự khó. Mythical man-month là một văn bản quan trọng, rất đáng đọc thêm.
Không có viên đạn bạc. Thật kỳ lạ là chúng ta cứ quên mãi lời khuyên ngắn gọn của Fred Brooks. Nếu không kỳ vọng quá mức và hiểu rằng dữ liệu huấn luyện chứa đầy mã có bug nên LLM đương nhiên cũng sẽ có bug, thì LLM sẽ trở nên hữu ích hơn nhiều. Đừng đẩy phần thiết kế cho nó; hãy tự mình làm sẵn các bước như chia hàm, rồi dùng LLM để giảm bớt phiền toái ở những việc tẻ nhạt hoặc ở các vùng mình còn lạ. Nhưng ngay cả với mã do LLM tạo ra, nếu bạn là người phải chịu trách nhiệm thì nó nhất định phải dựa trên hiểu biết và kiểm chứng của chính bạn. Dù mã của LLM có vẻ hoàn hảo đến đâu thì vẫn có thể ẩn lỗi bên trong, nên bạn phải tiếp tục học, tiếp tục nâng kỹ năng và luôn giữ sự nghi ngờ. Tuyệt đối không được mù quáng tin theo.
Khi quy mô vấn đề lớn lên thì rõ ràng LLM trở nên kém hữu dụng. Nó rất xuất sắc ở các tác vụ lặp lại hoặc các thao tác find & replace phức tạp. Với những đoạn mã thường nhật và rõ ràng như điền các phương thức CRUD cho tài nguyên API thì nó cực kỳ hữu ích. Gần đây tôi còn dùng Claude Opus 4 để review patch của mình, và đôi khi nó bắt được lỗi cũng như nhắc tôi những việc cần làm. Nhưng một khi vượt qua ngưỡng phức tạp nào đó, độ hữu dụng của LLM tụt rất mạnh. Ví dụ, nếu phải thay đổi trên nhiều file tương đối lớn, thì bản thân tôi cũng sẽ tự nhiên suy ra được nên sửa file nào. Dù vậy, dùng LLM như một “rubber duck” thì vẫn ổn. Nếu AI làm được thì tốt, còn không thì tôi lập tức tự làm tiếp. Rốt cuộc LLM chỉ giúp ở đoạn đầu, còn phần lớn chỉnh sửa thì kiểu gì tôi cũng phải tự xử lý. Nó dựng cho mình cái khung sơ bộ để rồi mình chỉnh về đúng ý vẫn dễ hơn là viết từ số 0. Nếu thấy LLM rõ ràng đang vật lộn thì tôi không cố ép nữa. Nếu do đặc tả mơ hồ nên nó đoán sai, tôi sẽ chỉ ra; mà nếu vẫn không làm được thì thôi để tôi tự hoàn tất.
Trải nghiệm của tôi cũng tương tự. Tôi thấy LLM có giá trị ở những điểm sau. Nó tạo khá tốt các React component hay page tương đối độc lập, nhất là khi đi cùng các UI library phổ biến. Nó cũng viết được các pure function được định nghĩa rõ ràng với độ tin cậy khá ổn, mà việc kiểm chứng cũng dễ. Boilerplate của các framework nổi tiếng thì nó làm rất nhanh và rất tốt. Nhưng xung quanh tôi có nhiều người khoe trải nghiệm end-to-end cực kỳ mạnh mẽ, còn tôi thì thực tế lại không thấy vậy nên hơi phát điên. Bình thường dù cố gắng rất nhiều, cứ đến đơn vị tính năng hoàn chỉnh là LLM sụp hoàn toàn. Tôi từng thử với các công cụ như aider để làm một tính năng email template đơn giản trong Next.js mà nó cũng không xong; nếu chia nhỏ tính năng ra rồi giao từng phần thì khá hơn chút, nhưng càng làm thì code hiện có càng bị phá. Dù tôi có giải thích vấn đề, prompt càng nhiều thì nó càng kỳ quặc. Cuối cùng tôi phải sửa thủ công, nhưng lúc đó code đã thành một mớ hỗn độn.
Tôi từng bị mấy người bạn vibe coder nói rằng “tiêu chuẩn của mày cao quá”. Tôi nghĩ vibe coder về cơ bản không review code cho tử tế nên chẳng có tiêu chuẩn chất lượng nào cả. Nếu vibe coding thực sự hiệu quả như lời họ nói, thì những nơi như Google AI hẳn đã dùng ngân sách GPU, TPU khổng lồ và các mô hình AI mới nhất để cải thiện sản phẩm nhanh hơn con người một cách áp đảo rồi. Nếu chuyện đó thật sự đang xảy ra, thì công việc của chúng ta sẽ không phải được báo trước bằng việc ngày càng dễ hơn, mà có lẽ ta sẽ biết trước tiên qua tin tức về một sự kiện khổng lồ bất ngờ nào đó, rồi rất lâu sau mới biết nguyên nhân là do AI.
LLM rất hợp với mã dùng một lần. Còn phát triển, bảo trì, debug và sửa chữa thì không hề dễ. Phần lớn code thực ra gần như là code “tiêu hao” chứ không phải sản phẩm, nên ở đó LLM phù hợp. Dù có thể gợi nhớ đến fast food, dây chuyền lắp ráp hay sản xuất tự động, nhưng khác biệt vẫn rất lớn. Đồ vật do máy trong nhà máy làm ra thì chính xác trên 99.99%, nên có thể tin được. Nhưng với LLM, ở mỗi bước tôi đều phải tự xác minh; nếu không xác minh thì đơn giản là nó không chạy. Việc LLM tự động giải quyết thành công bài toán 24 giờ không người giám sát là bất khả thi. Đó là lý do nó chưa cướp việc ngay được.
Tôi tuyệt đối không bao giờ định giao hẳn toàn bộ một bài toán phức tạp cho LLM rồi chờ lấy kết quả. Đó không phải thế mạnh của nó. Giá trị thật của LLM là đưa ra “gợi ý” giúp mình tiến lên và cho phép bỏ qua những phần đơn giản nhưng tốn thời gian. Vài ngày trước tôi phải làm đoạn tạo chuỗi log, và LLM ngay lập tức gợi ý đoạn mã được format đẹp hơn cả thứ tôi đang nghĩ đến, giúp hoàn thành rất tốt trong 30 giây thay vì mất 15 phút. Những thành quả nhỏ như thế tích lũy lại mới tạo ra giá trị.
if err != nil; Rust thêm?, Zig cũng tương tự. Python ngày càng dài và phức tạp hơn với type annotation các thứ. Autoformatter thực sự rất tiện, giúp không phải bận tâm đến việc thụt lề, nhưng Python nhạy cảm với khoảng trắng nên vẫn không hoàn hảo. Công cụ hữu ích cho những ngôn ngữ dài dòng, còn các ngôn ngữ biểu đạt tốt thì hữu ích vì mã ngắn gọn. Thời gian đọc code luôn nhiều hơn rất nhiều so với thời gian viết code. Công cụ tất định mạnh ở cấu trúc của mã; công cụ xác suất như LLM mạnh ở việc tiếp cận ý định. Mô hình ngôn ngữ là dạng tiến hóa của công cụ tự động hóa, và sẽ dần tốt hơn như autocomplete, nhưng không thể “giải quyết hoàn toàn” việc lập trình. Không có đáp án tuyệt đối, cuối cùng chỉ là khác biệt về quan điểm.