Việc tạo mã bằng LLM có thể dẫn đến suy giảm độ tin cậy

• Gần đây, hiện tượng tạo mã dựa trên LLM đang ngày càng được sử dụng nhiều hơn trong giới phát triển
• Việc dùng mã được tạo tự động làm gia tăng lo ngại về chất lượng mã và độ tin cậy
• Các nhà phát triển đang trải nghiệm độ khó bảo trì dự án tăng lên do thiếu hiểu biết về mã và kiểm chứng chưa đầy đủ
• Sự lan rộng của việc sử dụng mã không đáng tin cậy đang ảnh hưởng đến toàn bộ hệ sinh thái phần mềm
• Cùng với tiến bộ công nghệ, nhu cầu xây dựng các biện pháp bảo đảm độ tin cậy được nhấn mạnh

---

Tổng quan

Trong blog của mình, Jay đề cập đến tác động của công nghệ tạo mã dựa trên LLM (mô hình ngôn ngữ lớn) mới xuất hiện gần đây đối với thực tiễn phát triển phần mềm. Dù sự phát triển của các công cụ này giúp nâng cao hiệu quả phát triển, các vấn đề về độ tin cậy và chất lượng của mã cũng đồng thời nổi lên.

Sự trỗi dậy của công nghệ tạo mã bằng LLM

• Các công cụ tự động tạo mã sử dụng LLM đang lan rộng nhanh chóng trong môi trường phát triển
• Chúng mang lại năng suất cao trong việc triển khai các tính năng phức tạp hoặc các tác vụ lập trình lặp đi lặp lại
• Có ưu điểm là hỗ trợ tạo nguyên mẫu nhanh và giảm gánh nặng khi học ngôn ngữ mới

Vấn đề về độ tin cậy

• Xuất hiện tình trạng mã do LLM tạo ra không phải lúc nào cũng hoạt động đúng như mong muốn
• Ý đồ và logic thiết kế bên trong mã không rõ ràng, khiến quá trình hiểu và kiểm chứng trở nên khó khăn
• Nếu quy trình review và kiểm thử không đầy đủ, có thể phát sinh lỗi hoặc lỗ hổng ngoài dự kiến

Bảo trì dự án và tác động đến hệ sinh thái

• Phát sinh vấn đề thiếu tài liệu hóa và giải thích chưa đầy đủ đối với mã được tạo tự động
• Các nhà phát triển gặp khó khăn trong việc nắm bắt nguyên lý hoạt động của mã, làm tăng độ phức tạp của bảo trì
• Có nguy cơ làm suy yếu văn hóa phát triển phần mềm đáng tin cậy

Kết luận và đề xuất

• Công nghệ tạo mã dựa trên LLM mang tính đổi mới, nhưng việc bảo đảm độ tin cậy là nhiệm vụ thiết yếu
• Khi áp dụng mã được tạo tự động, cần nhấn mạnh việc tăng cường kiểm chứng và review mã có hệ thống
• Về lâu dài, việc xây dựng các tiêu chuẩn để bảo vệ niềm tin trong hệ sinh thái điện toán là rất quan trọng

[GN⁺]

Ý kiến Hacker News

• Chia sẻ liên kết archive.is, chạy được cả trên trình duyệt cũ và chỉ cần JavaScript để vượt CloudSnare

• Một người bạn của tôi hay nói rằng "đổi mới diễn ra với tốc độ của niềm tin". Từ sau khi GPT3 xuất hiện, câu này cứ lởn vởn trong đầu tôi. Việc xác minh rất tốn kém, và niềm tin là phương tiện chủ yếu để giảm chi phí đó. Nhưng tôi không biết phải xây dựng niềm tin với LLM như thế nào. Nó vừa code vừa dùng ngôn ngữ tự nhiên rất trôi chảy, nhưng đồng thời cũng lạc hướng theo cách mà nếu là con người thì có thể bị xem là ác ý

  • Tôi là tác giả đây: Tôi thật sự rất thích câu trích dẫn đó. Nó tóm gọn cực kỳ súc tích điều tôi đã cố giải thích bằng vài đoạn văn. Thành thật mà nói, một thế giới nơi giờ đây phải kiểm chứng mọi thứ từng chút một thật sự rất mệt và chậm
  • Không thể đặt niềm tin tuyệt đối vào đầu ra của LLM. Nhưng có thể tinh lọc và giới hạn mức độ phá hoại. Lọc đầu vào người dùng, pentest, giấu bí mật trong file dot, rồi cuối cùng mọi thứ sẽ hội tụ về các tiêu chuẩn như "best practice" và "tuân thủ quy định SOC-AI". LLM quá hữu ích nên dù muốn cũng không thể phớt lờ. Niềm tin cũng được xây từng nấc một. Con người vốn dĩ cũng chẳng đáng tin đến thế, và nếu so với xe tự lái thì có vẻ nó sẽ có thể tạo ra mã ít lỗi hơn con người trong các quy tắc xác định sẵn. Sau đó chỉ còn cải thiện dần độ phức tạp
  • Câu "đổi mới diễn ra với tốc độ của niềm tin" cần được giải thích thêm. Khi điện, hàng không hay phóng xạ mới được phát hiện thì đã có mức độ niềm tin đó chưa? Trong khoa học, niềm tin được tích lũy trong quá trình tiến triển

• Tôi từng trải nghiệm chủ đề này ở công ty theo một cách không ngờ. Vì áp lực phải ra kết quả nhanh, một đồng nghiệp đã merge bản refactor lớn tôi làm dù nó mới ở trạng thái PR tạm thời. Sau đó bug xuất hiện trong đoạn mã chưa được test. Trong lúc debug, đồng nghiệp thú nhận rằng anh ấy tưởng tôi đã code bằng AI, và thấy bực khi phải cố hiểu đoạn mã do AI tạo ra sau khi sự việc đã rồi. Nhưng thực ra đó là mã tôi tự viết rất cẩn thận, và bug chỉ đến từ những sai sót nhỏ trong quá trình thay đổi API đơn giản. Trái lại, trải nghiệm này lại giúp tôi và đồng nghiệp tự nhiên bộc lộ được sự căng thẳng liên quan đến niềm tin và có một cuộc trao đổi mang tính xây dựng. Nhìn lại, đây là một trải nghiệm xây dựng niềm tin khá có ý nghĩa, và nếu bối cảnh khác đi thì có lẽ mọi thứ đã rối rắm hơn nhiều. Cảm giác như lúc nào cũng phải cẩn thận

• Tôi không thật sự hiểu tiền đề ở đây. Niềm tin rằng ai đó viết code tốt đến từ kinh nghiệm thực tế rằng người đó tự code và cho ra kết quả tốt. Dùng LLM mà vẫn luôn tạo ra code không lỗi thì tôi tin, dùng LLM mà có lỗi thì tôi không tin. Tôi không thấy nó khác gì so với khi họ chỉ tự dùng đầu óc để viết

  • Tôi là tác giả đây: Ý tôi là trong những môi trường niềm tin thấp như đội ngũ lớn có độ tin cậy trung bình hoặc mã nguồn mở, LLM ngày càng khiến việc đánh giá năng lực lập trình viên chỉ qua mã được gửi lên trở nên khó khăn. Không đoán được khuynh hướng của đối phương, nên cuối cùng phải xem mọi đoạn mã với trạng thái "hoàn toàn không tin cậy". Những lối tắt từng giúp review nhanh trước đây không còn hiệu quả nữa, và với các tổ chức đã quen với văn hóa đó thì đây có thể là điều khá đau đớn. Nếu là một đội đã có mức tin cậy cao thì có thể hoàn toàn không cảm được vấn đề này
  • Trước đây nếu A=B thì B cao cũng có nghĩa A tốt. Giờ thì thành A+Ai=B, nên dù B cao thì A chưa chắc đã cao. Mà AI hiện tại lại mang tính xác suất, nên nhiều lúc còn tệ hơn là không làm gì cả
  • Bạn nói là chỉ tin "code chạy tốt", nhưng cơ sở của niềm tin là việc lập trình viên biết trước rằng code thực sự không có lỗi. Với hệ thống phức tạp, để hiểu code sẽ tương tác với các phần khác thế nào và edge case nào có thể xảy ra thì người viết phải hiểu toàn bộ bối cảnh. Nếu LLM viết thay mà lập trình viên không hiểu trọn vẹn nội dung đó, thì gánh nặng xác minh rốt cuộc sẽ đổ sang reviewer và dẫn tới quá tải. Đó là luận điểm ở đây
  • Khi code bằng LLM, vài lần đầu thấy ổn thì sẽ dễ tự tin quá mức và lơ là test. Trên thực tế, rất nhiều vấn đề đến từ lỗi giao tiếp. Người làm có thể hiểu rõ toàn bộ nhiệm vụ, nhưng LLM khó duy trì trạng thái và nếu bối cảnh mơ hồ thì nó có xu hướng tự đưa ra những giả định vô lý. Tôi ước gì cách tiếp cận như 4o, tức là chủ động hỏi thêm thông tin trước, sẽ trở thành tiêu chuẩn cho mọi mô hình sinh mã, vì có thể ngăn được rất nhiều vấn đề
  • Niềm tin còn được xây từ rất nhiều yếu tố ngoài việc có chạy hay không. Giải thích thay đổi rõ ràng, lịch sử đóng góp tốt trước đó, đơn vị thay đổi phù hợp (ví dụ commit có kích thước vừa phải), chọn đúng ưu tiên vấn đề (sửa bug trước rồi mới thêm tính năng), khả năng bảo trì mã hiện có, mức độ hoạt động ổn định, v.v. đều được cân nhắc

• Thời đại đó đã đến rồi. Tôi thấy quá nhiều câu như "xin lỗi vì đã bỏ sót điểm này, bạn nói đúng". Chắc phải 8 hoặc 9 trên 10 lần tôi đều thấy kiểu đó. Mặt khác, tôi cũng thường thấy người ta copy-paste vô nghĩa đoạn code LLM tạo ra rồi nổi giận vì nó không như kỳ vọng. Thật ra như thế còn tốt hơn. Tôi nghĩ một thứ hỏng rõ ràng còn tốt hơn thứ nhìn bề ngoài có vẻ đúng

  • Theo kinh nghiệm của tôi, LLM thường có xu hướng sửa code sao cho chỉ cần pass test chứ không thực sự đáp ứng yêu cầu
  • Bạn đang dùng LLM qua chatbot trên trình duyệt à? Bọn tôi dùng AI agent có quyền truy cập mã trực tiếp, ít nói hơn hẳn và nhiều việc còn làm tốt hơn junior quanh tôi. Nó xử lý tốt các tác vụ ngắn, cụ thể nên chỉ cần code review là gần như dùng được ngay. Tất nhiên, prediction engine thì thật sự không biết làm engineering. Ví dụ, nếu không yêu cầu rõ Python generator thì nó thường đưa ra code ngốn bộ nhớ khủng khiếp. Nhưng các lập trình viên Python quanh tôi cũng hay mắc lỗi tương tự. Thậm chí chính điểm này lại giúp thúc đẩy việc viết spec rõ ràng thay vì chỉ nói "add feature". Nơi AI agent hữu ích nhất là code legacy mà chẳng ai muốn động vào. Trước đây có một hệ thống trích dữ liệu từ tài liệu gửi qua fax bằng 200 tọa độ, hơn 30 năm dùng không đổi, gần đây tài liệu mới bị thay đổi. copilot sửa các tọa độ đó mất 30 giây. Nếu là người làm chắc phải mất cả ngày. Nhưng tôi không biết trong bầu không khí lập trình như thế này thì sẽ trở thành chuyên gia bằng cách nào
  • 8 hay 9 trên 10 là nói quá rồi. Đó là thống kê bịa 100%

• Các công cụ trừu tượng hóa trước đây vừa giảm độ phức tạp vừa mặc định lấy "tính đúng đắn" của lớp trừu tượng làm tiền đề. Tất nhiên không hoàn hảo, cũng có bug, nhưng đó là lỗi của implementation chứ không phải sai sót mang tính bản chất. Một khi đã vá thì nó có xu hướng vững hơn. Ngược lại, LLM là cỗ máy dự đoán xác suất nên chỉ cho độ chính xác gần đúng trong một khoảng thời gian nhất định. Điểm mà tác giả dường như bỏ qua là ta vẫn có thể xây dựng hệ thống quyết định đáng tin cậy từ các agent xác suất không hoàn hảo. Ví dụ, ta tin công cụ garbage collection không phải vì tin tác giả của nó, mà vì công cụ đã được test đủ để chứng minh nó hoạt động đúng như mong muốn. Trong tương lai có lẽ phát triển hướng kiểm thử sẽ mạnh hơn. Không phải niềm tin, mà là xác minh

  • Nghĩ rằng test tự động có thể bắt mọi vấn đề là quá ngây thơ. Đồng thời tính, quản lý tài nguyên, lỗ hổng bảo mật và nhiều thứ khác rất khó tự động hóa. Và ai sẽ kiểm chứng chính các bài test? Code và test đều triển khai logic, và đôi khi nguyên nhân bug lộ ra lại nằm ở phía test chứ không phải code. Test cũng không thể được tin vô điều kiện
  • Tôi là tác giả đây: Ở đây tôi đang nói về bản thân công cụ hơn là hiệu quả của công cụ. Ví dụ, nếu chính mô hình đóng vai trò như garbage collector, nhận memory dump của chương trình rồi tự quyết định khối nào là rác để giải phóng, thì tôi sẽ không bao giờ có thể tin phán đoán đó mãi mãi được. Dù có bù bằng "patch" hay "fine-tuning" thì cũng có giới hạn. Với đầu ra mang tính quyết định như JVM, nếu có lỗi thì vá một lần là lỗi đó biến mất vĩnh viễn. LLM thì không như vậy. Tôi nghĩ khác biệt này là điểm rẽ bản chất giữa các lớp trừu tượng trước đây và thế giới LLM. Tôi tin LLM sẽ có ảnh hưởng lớn đến ngành, nhưng do tiền lệ lịch sử còn ít nên đây đúng là vùng đất chưa biết
  • Đoạn "một hệ thống quyết định đáng tin cậy sinh ra từ nhân tố xác suất (cỗ máy entropy)" nghe với tôi khá táo bạo. Với lại TDD lúc nào cũng được giới thiệu như công cụ vạn năng giải quyết mọi thứ. Nhưng chuyện xây ra phần mềm sai vì test sai thì tôi đã thấy nhiều đến mức phải ngại thay

• Sự phản cảm với LLM chẳng có ích gì. Hiện tại LLM làm tăng năng suất của lập trình viên. Ít nhất thì càng hữu ích hơn với người ít kinh nghiệm. Một công cụ làm tăng năng suất mạnh như vậy sẽ không bị từ bỏ chỉ vì người khác phản đối. Dĩ nhiên, kể cả khi có thiệt hại như bug lớn khiến dịch vụ lớn sập lâu dài, nếu năng suất vẫn quan trọng thì công nghệ cũng không dừng lại. Cách thực tế duy nhất là đi cùng công nghệ và giải quyết (giảm nhẹ) điểm yếu của nó. Trong quá trình đó, nếu biện pháp giảm nhẹ làm hại mức tăng năng suất thì người ta sẽ tìm cách lách, và những biện pháp bổ sung hài hòa với công nghệ sẽ dần ổn định

  • Câu "LLM làm tăng năng suất lập trình viên" khác nhau rất lớn tùy người và hoàn cảnh. Theo kinh nghiệm của tôi, phía nói về "năng suất gấp 10 lần" chủ yếu là junior frontend hoặc người ở startup thường xuyên làm app giai đoạn đầu. Đó đúng là những ví dụ tốt, nhưng kiểu lập trình viên đó và một senior embedded C gần như đang nói hai ngôn ngữ khác nhau. Vì vậy tranh luận về năng suất AI thực chất là những cuộc trò chuyện trong các bối cảnh khác nhau. Và về mặt "ứng dụng hợp lý", tôi còn nghi ngờ chính khái niệm AI agent có thật sự tốt không. Nhìn vụ Copilot thì cả MS lẫn AI đều thành trò cười. Cách tiếp cận giao việc tự chủ cho AI có thể không hẳn là thông minh. Tương tự, blockchain cũng từng có vô số ví dụ bị thổi phồng trong thời kỳ tiền mã hóa cuồng nhiệt, nhưng cũng có những trường hợp thực sự bám được vào một niche có ý nghĩa như Coinbase. Năm 2020, IBM từng nói họ quản lý chuỗi cung ứng hạt cà phê bằng blockchain (nhìn từ hôm nay năm 2025 thì nghe như trò đùa trên Twitter, nhưng khi đó là nói thật). Cuối cùng thì AI agent hiện nay, và cả các ứng dụng AI tạo sinh khác, sau này cũng có thể trở thành ví dụ về hype quá đà vụ Copilot bài báo Forbes
  • Cụm "năng suất hơn" cứ lặp đi lặp lại, nhưng nó không nói rằng tổ hợp người/AI có thực sự phù hợp hơn với yêu cầu người dùng hay không, mà chỉ có nghĩa là "nhiều code hơn được tạo ra". Tôi chưa từng nghe chuyện LLM tạo một PR xóa 2.000 dòng code. "Nâng cao năng suất kỹ sư" thực chất gần như là nói tới việc viết nhiều code hơn
  • Hiểu rằng ý của tác giả là chỉ trích gay gắt thì hơi nhầm. Đây không phải lựa chọn nhị phân giữa dùng hay không dùng LLM, mà là tập trung vào quản lý và giảm thiểu rủi ro. Ví như không phải phản đối phát triển ô tô, mà là nói rằng ô tô có nguy cơ phát nổ nên hãy tập trung hơn vào việc giảm nguy cơ đó
  • Tôi thấy bài gốc không phải là "lời than vô nghĩa", mà giống một sự trăn trở thực tế về các cái bẫy dễ lơ là khi cộng tác với LLM và về những biện pháp bổ sung trong nhóm
  • Tôi từng hối hận vì ngày xưa lúc React mới ra đã không chịu học. Tôi vẫn có cảm giác phản kháng với GPT, xung quanh thì ai cũng nói "chatGPT bảo vậy" hay "đây là code chatGPT", còn tôi lại có lòng tự hào vì tự mình vật lộn để code. Tôi không dùng GPT, nhưng thật ra cũng có thể xem Google hay stackoverflow như một GPT chậm hơn

• Thay vì các chính sách như "cam kết rằng mã đóng góp không phải sản phẩm của LLM, là nguyên bản và đã được hiểu hoàn toàn" hay "yêu cầu chủ yếu làm thủ công", ta nên chỉ tập trung vào kết quả. Yêu cầu người đóng góp phải hiểu kỹ thay đổi của mình là điều tốt. Nhưng các chính sách kiểu "junior phải hạn chế hoặc cấm dùng công cụ LLM trong một thời gian" thì không ổn lắm. LLM rất hữu ích cho vấn đề setup môi trường onboarding vốn lộn xộn. Ngoài ra còn tốt để nắm bắt code/tài liệu, và là công cụ tìm kiếm văn bản, tóm tắt khá hữu dụng

  • Onboarding thực ra cũng là quá trình học cách giải quyết các vấn đề môi trường ngẫu nhiên. Nếu ta tự động hóa hết mọi khó khăn và phức tạp đi, thì sau này có thể sẽ chẳng còn ai biết phải làm gì trong những tình huống như thế. Không biết có chỉ mình tôi nghĩ vậy không

• Đây là lần đầu tôi nghe khái niệm "AI Cliff" (hiện tượng độ chính xác của LLM đột ngột sụt mạnh). Không biết người khác có từng gặp chưa

  • Tôi gặp thường xuyên. Khi độ phức tạp của code vượt qua một ngưỡng nào đó, LLM không thể giữ toàn bộ bối cảnh trong đầu nên bắt đầu hành xử linh tinh. Vai trò của tôi là quản lý mức độ phức tạp mà LLM phải nhìn vào. LLM hiện nay có xu hướng làm cấu trúc ngày càng phức tạp theo thời gian. Về cơ bản tôi phải yêu cầu nó refactor để đơn giản hóa, hoặc nếu quá phức tạp thì tự mình dọn dẹp. LLM bây giờ nếu cứ để tiếp tục thì cuối cùng sẽ tạo ra một mớ hỗn độn kiểu Rube Goldberg khổng lồ, và rốt cuộc con người phải đi dọn. Lập trình viên có kinh nghiệm sẽ nhanh chóng nhận ra LLM đang đưa mình đi xa đến mức nào và kịp quay lại sớm, nhưng người mới thì có thể lạc hoàn toàn trước cả khi nhận ra chuyện gì đang xảy ra
  • Người ta còn gọi là context drunk. Nếu đầu vào ngữ cảnh là 10.000 token và đúng 99%, thì LLM trả lời 1.000 token mà chỉ đúng 90%. Cứ qua lại nhiều lần, phần lớn context window sẽ bị lấp bằng những đầu ra kém chính xác do chính LLM tạo ra. Lỗi tích lũy, mà thông tin gần đây lại có trọng số cao hơn nên dần dần mọi thứ càng sai. Vấn đề này không chỉ xảy ra với code mà cả văn xuôi cũng vậy
  • Tôi gọi nó là context rot. Ngữ cảnh càng chồng chất thì chất lượng đầu ra càng giảm. Càng nhiều tán gẫu hay nội dung lạc đề thì chất lượng xuống càng nhanh. Đặc biệt khi chain of thought (COT) còn nằm trong ngữ cảnh, nếu quá trình suy nghĩ bị lạc thì dấu vết đó càng làm tình hình tệ hơn. Cá nhân tôi muốn có chức năng pruning để cắt bỏ có chọn lọc một phần ngữ cảnh. Hiện tôi tự tóm tắt rồi chuyển sang phiên mới để đối phó với context rot
  • Tôi chỉ gặp điều đó ở giao diện chat kiểu vibe coding; còn các công cụ dạng agent thì tự quản lý context window của code và trực tiếp chạy dev tooling để sanity check nên tần suất thấp hơn nhiều
  • Tôi thường reset phiên AI làm việc khá thường xuyên nên ít cảm nhận được 'AI cliff'. Nhưng khi viết tiểu thuyết sáng tác thì độ dài và tính nhất quán của ngữ cảnh rất quan trọng, nên đã có lúc AI bỗng không giữ được tính cách nhân vật và phản ứng kỳ quặc. Không thể kéo nó quay lại được, đó là một trải nghiệm rất lạ

• Bài gốc nói sẽ không tóm tắt ý kiến của nhiều người, nhưng có vẻ thực tế lại đang làm như vậy. Dù sao thì tôi cũng muốn trong PR có đánh dấu file nào chứa code do AI tạo. Kiểu lỗi của code LLM và code con người khác nhau, nên nếu review theo cách phân biệt được thì có thể tiết kiệm thời gian. Không biết ai từng trải nghiệm chính sách như vậy trong tổ chức lớn chưa, hoặc đã có công cụ tự động nào làm chuyện này chưa. Nếu các công ty đang đo tỷ lệ mã do LLM tạo thì có lẽ để lấy metric chi tiết họ đã có công cụ như thế rồi

  • Tôi là tác giả đây: Thực tế trong nhóm tôi không thấy có nhiều thảo luận được chính thức hóa về niềm tin trong đội và LLM, nên chưa thấy ví dụ nào được thành văn. Tôi cũng không rõ là vì mình đang làm ở môi trường không phù hợp nên mới có vấn đề đó, hay đơn giản là ngoài luồng chính nên khó tìm thấy trong thực tế