Việc tạo mã bằng LLM có thể dẫn đến suy giảm độ tin cậy
(jaysthoughts.com)- 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
1 bình luận
Các ý kiến trên Hacker News
https://archive.is/5I9sB
Hoạt động cả trên các trình duyệt cũ, và không cần JavaScript trừ khi đi qua CloudSnare
Một người bạn của tôi luôn nói rằng “đổi mới diễn ra theo tốc độ của niềm tin”, và từ sau GPT-3 câu này cứ hiện lên trong đầu tôi
Việc xác minh rất tốn kém, và phương tiện cốt lõi để giảm chi phí đó là niềm tin. Tôi không biết làm sao để khiến chúng ta tin tưởng LLM. Chúng rất lưu loát trong cả mã nguồn lẫn ngôn ngữ tự nhiên, nhưng đồng thời cũng sẵn sàng chui vào những hố thỏ đào mãi không hết như fractal, và có cả những hành vi mà nếu là con người thì có thể xem là ác ý
Thế giới mới nơi ta luôn phải xác minh mọi thứ này khá mệt mỏi, và nói thật là rất chậm
Nó quá hữu ích để có thể bỏ qua, và niềm tin luôn được xây từng viên gạch một. Cũng đừng quên rằng con người vốn cũng không đáng tin đến thế. Như việc lái ô tô, khả năng tạo ra mã ít lỗi hơn trên những con đường đã được định nghĩa trước có vẻ sẽ sớm vượt qua con người, rồi sau đó chỉ còn là cuộc đấu về các nguyên lý cơ bản để cải thiện độ phức tạp
Trong khoa học, ta xây dựng niềm tin khi tiến lên
Ở nơi làm việc, tôi đã trải qua chuyện này theo một cách khác với dự đoán. Một đồng nghiệp và tôi chịu áp lực phải cho thấy tiến độ, và chúng tôi quyết định vội vàng merge một đợt refactoring khá lớn mà tôi đang làm. Đó là một PR nháp, nhưng chúng tôi merge để giữ đà, và tuần sau xuất hiện vài bug ở những vùng mã chưa được kiểm thử
Trong lúc debug, đồng nghiệp để lộ rằng anh ấy đã cho rằng tôi viết nó bằng AI, và nói rằng thật bực bội khi phải cố hiểu sản phẩm do AI tạo ra sau đó. Nhưng đoạn mã này không dùng AI. Dĩ nhiên tôi có dùng AI khi viết mã, nhưng đoạn này là tôi viết tay sau khi suy nghĩ cẩn thận về toàn bộ thiết kế. Các bug không phải là lỗi nền tảng của việc refactor, mà là những thiếu sót nhỏ phát sinh khi điều chỉnh mã hiện có cho phù hợp với API đã thay đổi
Kết quả là chúng tôi có thể nói rõ với nhau về sự căng thẳng, nên đó đã trở thành một trải nghiệm xây dựng niềm tin. Có thể nói chúng tôi đã đối diện khá nhẹ nhàng với sức nặng của những gì đang diễn ra. Nhìn lại thì thật may vì mọi chuyện được giải quyết như vậy, và tôi có thể tưởng tượng ở một môi trường làm việc khác nó đã có thể trở nên rối rắm hơn nhiều. Cần phải cẩn trọng
Khoảng 4 năm trước tôi từng tự biến mình thành kẻ ngốc nặng nề. Một tờ báo địa phương đăng bài đưa ra một cáo buộc vô lý về một người, lấy ảnh làm bằng chứng chính, và tôi đã gửi email trực tiếp cho biên tập viên để giải thích vì sao tôi tin chắc bức ảnh đã bị chỉnh sửa. Lập luận của tôi dựa trên một hiểu lầm của chính tôi: tôi đã diễn giải sai việc nhân vật trong ảnh gần như không thay đổi vị trí và tư thế khi chụp ảnh tạo dáng với nhiều người tại một buổi meet-and-greet. Biên tập viên bị xúc phạm và trả lời kiểu chế giễu tôi; khi tôi không chịu lùi, ông ấy nhận ra tôi không phải kẻ kích động mà chỉ là một kẻ ngốc, rồi chia sẻ cho tôi toàn bộ video chưa công bố nơi bức ảnh được lấy ra. Khi đó tôi đã xin lỗi sâu sắc và cả quyên góp nữa, và trong suốt 1 năm sau đó cái tôi của tôi đã được thu nhỏ lại đúng mức
Ngay cả trước khi gửi email, vì không muốn đưa ra cáo buộc sai, tôi đã chia sẻ bức ảnh với những người bạn điềm tĩnh và hỏi ý kiến họ; họ cũng kết luận rằng khả năng cao bức ảnh đã bị chỉnh sửa, nên tôi đã khá tự tin. Bây giờ tôi ngầm tin tưởng tờ báo đó và những người liên quan, nhưng chỉ để thuyết phục một người thôi cũng đã tốn thật sự rất nhiều công sức
Khó hiểu tiền đề. Nếu tin rằng ai đó viết code tốt, thì niềm tin đó được học từ việc code của người đó chạy tốt, chứ không phải vì trong đầu người đó có một mô hình tinh thần tiên nghiệm nào đó “tạo ra code tốt”
Nếu ai đó dùng LLM để tạo ra code không có lỗi, tôi sẽ tin họ. Nếu ai đó dùng LLM để tạo ra code nhiều lỗi, tôi sẽ không tin họ. Điều đó khác gì so với thời người đó chỉ dùng đầu óc của chính mình để tạo ra code?
Vì LLM, việc chỉ nhìn vào code được gửi lên để đánh giá ngay chất lượng của developer đưa ra patch trở nên rất khó. Nếu không thể đoán được đối phương thuộc kiểu người nào, ta phải quay về trạng thái “không tin cậy” và rà soát mọi thứ cực kỳ kỹ. Nói cách khác, không còn “lối tắt review” an toàn nữa, và những nơi vận hành dựa vào các tín hiệu như vậy có thể sẽ rất khổ sở. Nếu là một đội vốn đã có năng lực và độ tin cậy cao, vấn đề này không áp dụng, và có khả năng bản thân khái niệm này sẽ cảm thấy xa lạ
Nếu contributor giải thích tốt nội dung thay đổi, tôi tin tưởng hơn. Nếu trước đây họ từng làm việc xuất sắc, tôi tin tưởng hơn. Nếu họ quản lý đơn vị thay đổi tốt, như các commit hợp lý, tôi tin tưởng hơn. Nếu họ chọn đúng vấn đề, chẳng hạn sửa bug trước khi thêm tính năng mới, tôi tin tưởng hơn. Nếu họ cho thấy có thể bảo trì code hiện có, thay vì chỉ đắp thêm lên trên, tôi tin tưởng hơn. Nếu họ đóng góp đều đặn, tôi tin tưởng hơn
Vấn đề thường là lỗi giao tiếp. Với người thực hiện, nhiệm vụ có thể rất rõ ràng, nhưng do LLM thường xuyên bị khởi tạo lại ngữ cảnh, khó đảm bảo nó cũng nắm được toàn cảnh; khi có điểm mơ hồ, nó dễ đưa ra các giả định ngu ngốc. Cách deep research của 4o hỏi thêm thông tin trước khi làm gì đó, theo tôi, cũng nên trở thành tiêu chuẩn trong sinh code. Như vậy có thể ngăn được cả núi vấn đề
Có trường hợp đơn giản: routine này có trả về giá trị mong muốn hay không. Nhưng những tình huống khác phức tạp hơn nhiều vì phải dự đoán nó sẽ tương tác với các phần khác của hệ thống ra sao, và các edge case khó thấy là gì. Trong những tình huống đó, để viết code “không lỗi”, tác giả phải hiểu hàm ý của code; nếu developer không hiểu chính xác code do LLM viết đang làm gì, thì cũng không thể hiểu các hàm ý đó. Khi đó gánh nặng chuyển sang reviewer, và khối lượng công việc của reviewer tăng lên. Đó chính là tiền đề
Quy tắc kinh nghiệm tốt là cứ từ chối các công việc có LLM tham gia, và cũng bỏ qua cả các trao đổi do LLM viết. Ngay cả với người dùng tiếng Anh như ngoại ngữ, tôi cho rằng tiếng Anh “vụng về” của chính họ vẫn tốt hơn nhiều so với việc để ChatGPT nói thay. Khi các vấn đề nghiêm trọng của LLM ngày càng rõ ràng hơn, tôi nghĩ chính sách như vậy sẽ trở thành chuẩn chung, và tôi hy vọng điều đó xảy ra
LLM khiến bất kỳ loại công việc tệ nào cũng trông như một công việc tốt một cách có vẻ hợp lý. Vì vậy, việc tự động hạ thấp giá trị sản phẩm của người đã dùng AI là hợp lý.
Trước đây, một người họ hàng của tôi từng bị phát hiện là kẻ lừa đảo. Sau khi bị phát hiện, tôi cắt liên lạc và nói rằng tôi không biết người đó; anh ta nói: “Tôi vẫn là chính người mà cậu đã biết suốt 10 năm qua.” Tôi đáp: “Có thể. Nhưng giờ tôi mới nhận ra rằng tôi hoàn toàn không biết anh là ai, và sau này cũng không thể biết được.”
Tất cả chúng ta đều giả định rằng những người trong đời mình không chủ động muốn làm hại mình. Khi niềm tin đó vỡ, nó vỡ rất nặng. Người dùng AI không ai có thể khẳng định “đây là công việc của tôi”. Vì không thể biết liệu đó có phải là công việc của bạn hay không. Người đã dùng AI cũng không thể khẳng định đó là công việc tốt nếu không hiểu nó đến tận gốc, và có lẽ họ sẽ không hiểu đến tận gốc. Nhiều sinh viên của tôi từng khẳng định rằng họ đã đọc và hiểu bài viết của tôi, nhưng tôi phát hiện thực tế không phải vậy. Nếu tôi là AI, còn họ nhận công việc của tôi rồi ghi tên mình làm tác giả thì sao? Họ sẽ không thể giải thích, bảo vệ hay làm tiếp bất cứ thứ gì. Vấn đề này đã tồn tại trước AI, nhưng giờ nó tệ hơn gấp mười lần.
Tôi là người đã đổ “hơn 10.000 giờ” vào lập trình ứng dụng phức tạp trước khi các LLM hữu dụng xuất hiện. Trong nhiều năm, đêm nào tôi cũng đào sâu vào tài liệu và mã nguồn của người khác, hoàn toàn đắm mình vào việc thành thạo full-stack. Cuối cùng, sự đắm chìm đó dẫn đến burnout nghiêm trọng, sức khỏe sa sút và hôn nhân cũng lung lay. Ngay sau khi phát hành ứng dụng, tôi phải buông hẳn trong 3 năm để hồi phục, và từng chắc rằng mình sẽ không bao giờ cầm lại nó nữa.
Sau khi nghe rất nhiều câu chuyện rằng LLM đã khá giỏi về code, tôi thận trọng quay lại trước máy tính, và từ điểm đó trải nghiệm của tôi khác rất xa với mối lo ngại nói trên. Tôi không thể đồng ý với câu “người dùng AI không thể khẳng định ‘đây là công việc của tôi’”. Khi dùng LLM, tôi là người thiết kế và người kiểm duyệt cuối cùng. Tôi chỉ đạo tầm nhìn, thiết kế hệ thống, và dùng công cụ diff để xem xét từng dòng do LLM tạo ra. Gần đây, tôi đã cùng LLM xây dựng một mô hình tối ưu hóa phức tạp cho engine báo giá của doanh nghiệp. Dùng một mô hình tối ưu hóa thực sự vốn luôn là cách “đúng”, nhưng nếu là trước đây thì có lẽ cần nhiều tháng lao động vất vả để học mọi chi tiết của thư viện và đọc code của người khác. Lần này tôi hoàn thành trong một tuần. Việc này có cảm giác như công việc của tôi không? Hoàn toàn có. Chỉ là tôi có một trợ lý không biết mệt, xuất sắc nhưng đôi khi có lỗi.
Trải nghiệm của tôi cũng ngược lại với nhận định rằng người dùng “sẽ không hiểu đến tận gốc”. Để dùng LLM hiệu quả cho những việc không tầm thường, cần hiểu nền tảng sâu hơn nhằm dẫn dắt LLM và bắt những lỗi tinh vi thường xảy ra. Nếu không có nhiều năm kinh nghiệm, tôi đã không thể dẫn dắt việc phát triển phức tạp nhiều module, debug đầu ra, hay nhận ra rằng một công việc trông có vẻ tốt thực ra lại sai theo kiểu như vấn đề N+1.
Tôi đồng cảm với trải nghiệm của bạn với tư cách giáo viên. Việc sinh viên dùng những công cụ này để giả vờ đã hiểu là vấn đề có thật và khó. Trong học thuật, mục tiêu là quá trình học tập, tức là đạt được một phần thực chất nào đó của 10.000 giờ. Nhưng trong thế giới chuyên nghiệp, mục tiêu là kết quả, và đây là một công cụ mới mạnh mẽ để đạt kết quả tốt hơn. Tôi không biết giáo viên nên dạy sinh viên thế nào trong thực tế mới này, nhưng quỷ hóa việc sử dụng LLM có lẽ không phải cách tốt nhất.
Với tôi, điều này không làm công việc tệ trông có vẻ tốt. Nó đã khiến công việc xuất sắc trở nên khả thi trở lại, đồng thời giúp tôi lấy lại cuộc sống của mình. Nó trả lại cho tôi niềm vui với craft phát triển phần mềm mà không phá hỏng tôi và gia đình, và giờ cuộc sống của tôi cân bằng hơn rất nhiều, nên tôi biết ơn điều đó.
Với tôi thì đã đúng là như vậy rồi. Tôi đã đọc câu “Xin lỗi vì đã bỏ sót, bạn hoàn toàn đúng” nhiều không đếm xuể. Khoảng 8–9 lần trên 10.
Mặt khác, tôi liên tục thấy người ta vô tư copy code do LLM trả phí tạo ra, rồi nổi giận khi nó không hoạt động như mong đợi. Nhân tiện, đó còn là lựa chọn tốt hơn. Vì hỏng một cách rõ ràng vẫn còn tốt hơn là nhìn bề ngoài có vẻ đang hoạt động.
Dù vậy, engine dự đoán vẫn chưa thể làm kỹ thuật thực sự. Nếu không chỉ rõ rằng hãy dùng những thứ như Python generator, rất có khả năng nó sẽ tạo ra code ngốn bộ nhớ khủng khiếp. Tiếc là điều này cũng không khác nhiều với nhiều lập trình viên Python mà tôi biết, nhưng nó cũng là một ví dụ cho thấy LLM tệ đúng như lời bạn nói. Mặt tích cực là nó khiến mọi người thực sự viết đặc tả chi tiết hơn một dòng “thêm tính năng”.
Nơi AI agent hữu ích nhất với chúng tôi là legacy code mà không ai ưu tiên. Chúng tôi có một bộ trích xuất dữ liệu được viết từ thiên niên kỷ trước, dùng khoảng 200 tọa độ hard-code để trích xuất dữ liệu từ một loại tài liệu cụ thể gửi qua fax. Tài liệu đó không đổi trong khoảng 30 năm nên vẫn hoạt động tốt, nhưng gần đây đã thay đổi, và Copilot mất khoảng 30 giây để sửa các tọa độ. Với con người, rất có thể đó là công việc cực kỳ nhàm chán kéo dài cả ngày. Tuy nhiên, tôi hoàn toàn không biết ngành của chúng ta định đào tạo chuyên gia như thế nào trong thời đại vibe coding.
Chống lại LLM chẳng khác nào tiểu ngược chiều gió
LLM theo cách hiện nay có vẻ giúp lập trình viên làm việc năng suất hơn. Với các lập trình viên ít kinh nghiệm, nó thậm chí có thể mang lại lợi ích lớn hơn so với lập trình viên lành nghề. Mức tăng năng suất, có lẽ là tăng theo bội số rất lớn, sẽ không bị từ bỏ chỉ vì những rào cản do những người phản đối công nghệ vì lý do nào đó dựng lên
Ngay cả khi xuất hiện những ví dụ về việc một công cụ năng suất mới gây thiệt hại nghiêm trọng, chẳng hạn một lỗi làm gián đoạn một dịch vụ lớn trong thời gian đáng kể, nếu công nghệ đó mang lại năng suất đáng kể thì nó cũng sẽ không dừng lại. Con đường hợp lý duy nhất là làm việc cùng công nghệ và giảm thiểu điểm yếu của nó. Và các biện pháp giảm thiểu đó không nên là một tập hợp quy tắc xóa sạch hoàn toàn lợi ích năng suất của công nghệ mới. Các biện pháp giảm thiểu phải vận hành cùng công nghệ theo hướng làm tăng việc áp dụng công nghệ; nếu không, chúng sẽ bị đi đường vòng
Theo kinh nghiệm của tôi, những người khẳng định mạnh mẽ rằng LLM giúp họ tăng năng suất gấp 10 lần thường là các lập trình viên front-end tương đối junior, hoặc các lập trình viên startup nối tiếp luôn xây ứng dụng mới từ đầu. Dĩ nhiên đó là các trường hợp sử dụng hoàn toàn hợp lệ, nhưng vì vậy mà một lập trình viên front-end junior và một lập trình viên embedded C senior rất dễ nói lệch nhau khi bàn về tăng năng suất nhờ AI
Thay vì nói rằng chỉ có làm việc cùng công nghệ và giảm thiểu điểm yếu của nó mới là hợp lý, chỉ cần dùng nó một cách sáng suốt hơn. Ví dụ, bản thân ý tưởng AI “agent” có tốt không? Sự cố Copilot gần đây[0] đã khiến MS và AI trông như trò cười. Có khả năng bản thân nỗ lực để AI tự chủ thực hiện công việc không phải là điều khôn ngoan lắm
Một phép so sánh gần đây là blockchain và tiền mã hóa. Dù thích hay ghét, nhìn vào thành công của Coinbase và các công ty tương tự thì rõ ràng blockchain đã tìm được một trường hợp sử dụng có thật nhưng hẹp. Nhưng trong thời kỳ tiền mã hóa quá nóng, có những người nói những câu như “sẽ theo dõi chuỗi cung ứng hạt cà phê bằng blockchain”. Năm 2025 nghe như một trò đùa phóng đại trên Twitter, nhưng năm 2020 IBM thực sự đã cố bán thứ như vậy[1]. Một ngày nào đó nhìn lại, có thể ta sẽ thấy AI agent hoặc một số ứng dụng AI tạo sinh hiện nay chính là blockchain cà phê của bong bóng này
[0] https://www.reddit.com/r/ExperiencedDevs/comments/1krttqo/my...
[1] https://www.forbes.com/sites/robertanzalone/2020/07/15/big-c...
Nhưng điều này không có nghĩa là tổ hợp mô hình/con người đáp ứng nhu cầu của người dùng hiệu quả hơn. Nó có nghĩa là tạo ra “nhiều code hơn”. Không có LLM nào đưa ra một tập thay đổi xóa 2000 dòng code. Vì vậy có thể thấy câu “làm cho kỹ sư năng suất hơn” là nói về lượng code được tạo ra
Bạn nói như thể đây là lập luận nhị phân dùng LLM hay không dùng LLM, nhưng tác giả chủ yếu đang nói về giảm thiểu rủi ro. Ví von thì giống như tác giả chỉ ra rằng vài chiếc ô tô đã phát nổ, rồi nói rằng ngựa ngày xưa không phát nổ nên trước khi cho nhà máy keo hoạt động, ta nên làm cho ô tô ít phát nổ hơn; còn bạn lại dường như cho rằng tác giả phản đối về căn bản việc phát triển ô tô
Bây giờ tôi vẫn có cảm giác không muốn dùng GPT, trong khi gần đây đồng nghiệp của tôi hay nói “ChatGPT nói rằng” hoặc “đoạn code này do ChatGPT tạo”. Tôi tự hào vì tự viết code và không dùng GPT, nhưng đồng thời tôi vẫn dùng Google và Stack Overflow. Có thể nói đó cũng chỉ là phiên bản chậm hơn của GPT
Có vẻ tác giả đã bỏ lỡ điểm rằng ngay cả một tác nhân không hoàn hảo và mang tính xác suất cũng có thể tạo ra một hệ thống tất định đáng tin cậy
Ta sẽ không tin một công cụ garbage collection dựa trên độ tin cậy của tác giả, mà sẽ tin sau khi thấy nó được chứng minh qua kiểm thử rộng rãi rằng nó làm đúng việc được kỳ vọng. Hoàn toàn có thể hình dung việc niềm tin sẽ suy yếu trong tương lai, và kết quả là phát triển theo hướng kiểm thử sẽ có thêm động lực. Đừng tin, hãy kiểm chứng
Câu hỏi quan trọng hơn là ai kiểm thử chính các bài test. Trong phát triển truyền thống, mọi logic được triển khai hai lần: một lần trong code, một lần trong test. Test kiểm tra code, và ngược lại code ngầm kiểm tra test. Việc bug nằm trong test chứ không phải trong code ứng dụng là khá phổ biến. Không thể mù quáng tin vào test rồi chờ đến khi agent tìm ra cách sao chép bug của test vào code
Lấy ví dụ garbage collection: tất nhiên, một ngày nào đó một hệ thống dạng agent có thể dựng thứ gì đó lên rồi dùng test harness, sửa bug, v.v. để đập cho nó khớp. Nhưng hãy tưởng tượng dùng model như chính garbage collector/công cụ đó. Ví dụ, mỗi lần sweep lại ném bộ nhớ chương trình vào model và yêu cầu nó giải phóng các block không cần thiết. Ta tuyệt đối không thể tin rằng model sẽ xác định chính xác các block bộ nhớ đúng, và sẽ không có “patch” hay “fine-tuning” nào đưa ta tới được đó
Với các lớp trừu tượng trước đây như JVM, nếu đầu ra tất định — trong trường hợp này là assembly do JIT xuất ra — bị sai, bug đó sẽ được vá và lớp trừu tượng ấy sẽ không bao giờ mắc lại cùng lỗi đó nữa. LLM thì không như vậy. Khi nói về các công cụ phát triển trong quá khứ đã thay đổi toàn bộ bản chất của ngành, với tôi khác biệt này rất quan trọng. Tôi không nói rằng LLM sẽ không tác động sâu sắc đến cách vận hành trong tương lai. Chỉ là tôi thấy chúng ta đang bước vào một vùng hoàn toàn chưa biết, gần như không có tiền lệ lịch sử
Còn chuyện phát triển theo hướng kiểm thử sẽ có thêm động lực, tôi cũng không hiểu vì sao TDD luôn được đưa ra như viên đạn bạc sửa mọi vấn đề trong xây dựng phần mềm. Số lần tôi thấy TDD bắt đầu từ test sai và tạo ra phần mềm sai thật ra nhiều đến mức đáng xấu hổ
Nên chỉ định đầu ra, không nên chỉ định quy trình. Kỳ vọng người đóng góp hiểu patch là một ý hay
Nhưng khuyến khích hoặc yêu cầu junior tránh dùng công cụ hỗ trợ LLM trong một thời gian khi onboarding là một ý tưởng tệ hại. Onboarding có rất nhiều vấn đề thiết lập môi trường ngẫu nhiên, và LLM thường khá mạnh ở những việc như vậy. Nó cũng là việc bắt kịp code và tài liệu, và còn có những công cụ tìm kiếm/tóm tắt văn bản tuyệt vời đáng chia sẻ
Có vẻ quá rõ ràng rằng nếu ta làm trơn tru mọi khó khăn và phức tạp trong đời, thì chẳng bao lâu nữa khi gặp khó khăn hay phức tạp, ta sẽ hoàn toàn không biết phải làm gì. Chỉ mình tôi nghĩ vậy sao?
Hiện tượng LLM “xấp xỉ thứ gần đúng trong một khoảng thời gian rồi sau đó độ chính xác rơi mạnh theo thời gian”, mà tác giả gọi là vách đá AI, là lần đầu tôi nghe thấy. Những người khác có gặp chưa?
Các trình sinh hiện tại có xu hướng làm mọi thứ phức tạp hơn theo thời gian, thay vì đơn giản hơn. Người luôn phải prompt LLM refactor cho đơn giản hơn, hoặc tự tay refactor khi mọi thứ đã trở nên quá phức tạp để LLM xử lý, luôn là tôi. Vì vậy, ít nhất với thế hệ LLM hiện nay, nếu cứ “thả dây cương cho LLM” và để nó muốn làm gì thì làm, cuối cùng nó sẽ tạo ra một mớ rối rắm kiểu Rube Goldberg khổng lồ, rồi bạn sẽ phải dọn dẹp; điều đó có vẻ khá tất yếu
Liên hệ với ý chính của bài viết, một người dày dạn kinh nghiệm có thể sớm nhận ra khi LLM bắt đầu kéo bạn ra biển xa, và dù có đi hơi xa vẫn tìm được đường quay lại vùng nước nông. Người mới thì trước khi kịp hiểu chuyện gì đã xảy ra, đã vượt quá khả năng của mình và lạc ngoài biển
Hãy tưởng tượng có 10.000 token đúng 99% làm đầu vào ngữ cảnh. Mỗi lần LLM trả lời, nó thêm 1.000 token đúng 90%. Sau vài lượt trao đổi để chỉnh LLM, cửa sổ ngữ cảnh phần lớn bị lấp đầy bởi đầu ra cặn bã của chính LLM. Tệ hơn nữa là lỗi tích lũy. Ngay cả 90% đúng kia cũng chỉ là việc ngoại suy đúng từ cuộc thảo luận về code sai, và LLM lại đánh giá các token gần đây là quan trọng hơn. Vấn đề tương tự cũng xuất hiện trong văn xuôi
Với các model suy luận, vấn đề này có thể còn trầm trọng hơn. Vì toàn bộ quá trình suy nghĩ nằm trong ngữ cảnh, và nếu suy nghĩ thực sự rẽ sang đường vòng, nó sẽ gieo những hạt độc nuôi sự thối rữa. Giá mà có thể triển khai một dạng tỉa ngữ cảnh nào đó để cắt bỏ khi xuất hiện ngữ cảnh không liên quan. Hiện tại, khi cảm thấy sự thối rữa xuất hiện, tôi tạo bản tóm tắt rồi chuyển sang một instance mới
Với các công cụ dạng agent như claude code, codex, gemini cli thì đây là vấn đề ít hơn nhiều. Vì chúng tự quản lý cửa sổ ngữ cảnh của mình và có thể tự sanity check bằng cách chạy các công cụ phát triển
Quá trình này rèn cho ta thói quen ghi lại trạng thái công việc hiện tại để agent mới có thể bắt kịp