Vì sao tôi quyết định giảm sử dụng LLM
(zed.dev)- Alberto Fortin, kỹ sư phần mềm với 15 năm kinh nghiệm, từng đặt rất nhiều kỳ vọng vào việc áp dụng LLM (mô hình ngôn ngữ lớn), nhưng trong môi trường production thực tế anh đã trải qua nhiều giới hạn
- Trong quá trình xây dựng lại hạ tầng dựa trên Go và ClickHouse, anh cảm nhận rõ mặt được và chưa được của AI, và thấy rằng ngay cả khi mô hình đã cải thiện thì những vấn đề cốt lõi vẫn chưa được giải quyết đầy đủ
- Anh chỉ ra rằng có một ảo tưởng về việc tăng năng suất, trong khi thực tế lỗi và các vấn đề ngoài dự kiến lại tăng lên nhiều hơn
- Anh nhấn mạnh bài học rằng nên xem LLM là trợ lý (assistant), và việc thiết kế, ra quyết định cốt lõi phải do chính lập trình viên đảm nhiệm
- "AI mang tính cách mạng nhưng vẫn chưa hoàn thiện, vì vậy cần sử dụng cân bằng và nhìn nhận thực tế một cách tỉnh táo"
Trải nghiệm và nhìn lại của Alberto Fortin với LLM
- Kỹ sư phần mềm Alberto Fortin với 15 năm kinh nghiệm đã tích cực đưa LLM vào công việc phát triển và từng có kỳ vọng rất lớn
- Trong quá trình xây dựng lại hạ tầng bằng Go và ClickHouse, khi vấp phải nhiều thách thức và giới hạn, anh đã viết một bài blog về khoảng cách giữa AI và phát triển phần mềm thực tế
- Sau đó, qua phân tích bổ sung gần đây, anh tiếp tục kiểm chứng xem các mô hình mới nhất như Claude Opus 4 có giải quyết được những vấn đề này hay không
- Trải nghiệm của Alberto mang đến cho các kỹ sư đang cân nhắc áp dụng LLM trong môi trường thực tế những bài học thiết thực, đồng thời đưa ra góc nhìn thực tế về việc công cụ này tạo ra giá trị ở đâu và giới hạn của nó nằm ở đâu
Những trích dẫn chính của Alberto về trải nghiệm với LLM
"Điều thực sự khiến tôi ngạc nhiên là vấn đề không chỉ nằm ở việc chạy sai hay chức năng không hoạt động. Với tư cách là người sẽ phải bảo trì đoạn mã này trong vài năm tới, mã nguồn phải đủ sạch sẽ."
"Có cảm giác như vấn đề sắp được giải quyết, nhưng rồi lần sau lại xuất hiện một lỗi mới, và việc xử lý nó lại tiếp tục mất thêm khoảng 2 tuần nữa — trải nghiệm đó cứ lặp đi lặp lại."
"Khi đưa đầu ra lỗi cho LLM, nó có đưa ra câu trả lời mới, nhưng lại thường xuyên làm mọi thứ rối hơn hoặc làm hỏng những phần khác."
Nhận thức về kỳ vọng quá mức đối với LLM
"Khi lần đầu dùng những tính năng nhỏ như autocomplete ban đầu, lập trình viên nào cũng thấy kinh ngạc. Nó giống như đang đọc được suy nghĩ của mình, nên kỳ vọng rất dễ bị đẩy lên quá cao."
"Ta bắt đầu nghĩ rằng năng suất phát triển có thể tăng lên gấp 10 lần, nhưng trên thực tế lại có xu hướng đặt kỳ vọng đó quá sớm."
Định nghĩa lại vai trò và kỳ vọng
"Khác biệt lớn nhất là sự thay đổi trong cách nhìn nhận vai trò. Tôi là kiến trúc sư và lập trình viên senior, còn LLM chỉ là trợ lý của tôi. Tôi lập kế hoạch, còn LLM đảm nhận vai trò hỗ trợ."
"Sau khi đánh mất niềm tin vào nó, tôi không còn giao những chức năng quan trọng nữa. Tôi chỉ dùng nó ở những đơn vị nhỏ như refactoring."
"Tôi bắt đầu tự sửa bug. Khi đã hiểu hoàn toàn codebase thì việc tự mình giải quyết vấn đề nhanh và hiệu quả hơn rất nhiều."
Sự thay đổi trong góc nhìn về LLM và lời khuyên
"Với tư cách là một lập trình viên senior, tôi đã tự thừa nhận rằng việc áp dụng LLM không thực sự phù hợp không phải vì năng lực của tôi còn thiếu. Điều cốt lõi là vẫn giữ cách làm việc vốn có, còn AI thì chỉ nên được dùng như công cụ hỗ trợ."
"Đúng là công nghệ đã tiến thêm một bước, nhưng vẫn chưa đạt tới bước tiếp theo. Ra quyết định và kiến trúc vẫn phải do con người đảm nhiệm."
"Cuộc cách mạng AI thật đáng kinh ngạc, nhưng ở thời điểm hiện tại, điều cần thiết là một mức kỳ vọng cân bằng và thực tế."
2 bình luận
> https://vi.news.hada.io/topic?id=20955
Ý kiến trên Hacker News
Lý do tôi cảm thấy mình đang dành quá nhiều thời gian trên HN là vì gần như bài viết và bình luận nào cũng lặp lại cùng một câu chuyện. LLM đúng là thú vị, nhưng code được tạo ra thì phức tạp, không có cảm giác sở hữu, và vì không nắm được toàn bộ cấu trúc trong đầu như khi tự viết nên rất khó bảo trì. Có thể dùng được cho các script ngắn không định duy trì, nhưng với các dự án lớn thì thành vấn đề. Mặt khác, cũng có những người nói rằng workflow huy động nhiều tác nhân LLM để phân tán và hợp nhất nhiều tác vụ khác nhau rất hay ho, nhưng lại không cho xem code thực tế mà chỉ có cảm giác đang khoe khoang
Tôi nghĩ phần tóm tắt này thực sự nắm rất đúng trọng tâm. LLM tăng tốc độ phát triển lên rất nhiều, nhưng vì tôi không thực sự hiểu toàn bộ code nên rất khó xác định khi nào và chỗ nào phát sinh vấn đề. Cuối cùng có cảm giác như một lập trình viên mới vào đang cố làm quen với chính dự án của mình. Vì vậy tôi commit code thường xuyên, và định kỳ lại yêu cầu LLM giải thích code thêm một lần nữa. Trong quá trình đó, cũng có nhiều lúc LLM tự tìm ra bug của chính nó. Với các tác vụ có phạm vi hẹp như phân tích dữ liệu thì hoàn toàn có thể kiểm soát tốt và làm nhanh. Ngược lại, nếu không có năng lực và thói quen để tận dụng LLM đúng cách trong codebase lớn thì rất dễ thành mớ hỗn độn. Viết prompt, quản lý context, điều tiết tốc độ, tổ chức công việc, và review chính xác đầu ra của LLM đều là những năng lực bắt buộc phải học để dùng LLM hiệu quả. Hiện chưa ai chính thức dạy những thứ này nên mọi người đều đang tự học bằng thử-sai. Dù vậy, một khi đã nếm thử thì rất khó quay lại như trước. Vì có thể giao những việc phiền phức hoặc lặp đi lặp lại cho LLM. Tôi đã làm phát triển phần mềm hơn 20 năm nên cũng không còn kiên nhẫn như trước, và với những ý tưởng mà tôi chưa rõ cách triển khai thì giao cho LLM giúp làm việc hiệu quả hơn nhiều
Tôi thích cách xem lập trình là một quá trình "xây dựng lý thuyết". Tham khảo Programming as Theory Building. Tôi không phản cảm với việc dùng AI. Nhưng tôi không đồng tình với thái độ từ bỏ trách nhiệm đối với kết quả của code được tạo ra. Cũng như khi dùng công cụ như grep, chỉ khi chịu trách nhiệm xử lý kết quả từ công cụ thì mới có ý nghĩa. Với code sinh ra lại càng như vậy, không phải chuyện có thể kết thúc chỉ bằng một lời miễn trừ trách nhiệm
Tôi cũng đồng cảm với sự mệt mỏi trước các bài viết về AI. Đúng là ý kiến đang bị chia rẽ. Tuy vậy, cũng có những ví dụ thật sự công khai code của họ. Armin Ronacher, người tạo ra Flask/Jinja2/Sentry, đã đăng video workflow trên YouTube và bài giới thiệu thư viện AI tự làm, còn tôi thì đang làm khoảng 50%~80% dự án mã nguồn mở của mình bằng AI. Xem cijene-api
Tôi có cảm giác nhóm người dùng đang phân bố như một đường cong hình chuông. Ở một đầu là những người bị LLM nhả ra quá nhiều code theo kiểu của nó, khiến không thể nạp được ngữ cảnh vào đầu và bị choáng ngợp. Ngược lại, với những người vốn dĩ một mình không thể hiện thực được gì thì LLM mở ra con đường để họ thử làm đủ mọi thứ. Và ở đầu còn lại là những người vốn có thể tự mình triển khai chậm rãi, nhưng khi có LLM thì dùng nó như cả một đội lập trình viên junior, chỉ cần tập trung nhớ ở mức thuật toán tổng thể rồi nhanh chóng dựng nên các dự án lớn hơn nhiều
Tôi nghĩ điều này cũng không khác lắm so với làm việc trong một codebase lớn có hơn 25 lập trình viên cùng tham gia. Tổ chức của tôi có 160 kỹ sư phụ trách frontend và middle-tier, và lúc nào cũng phải đào bới những đoạn code không có cảm giác sở hữu, git blame thì thường hiện tên một lập trình viên outsource từ 3 năm trước. LLM có vẻ ổn ở quy mô nhỏ, không hợp ở quy mô trung bình, rồi lại ổn khi dùng như một mô-đun nhỏ trong dự án lớn
LLM giúp tôi rất nhiều trong việc đạt mục tiêu, nhưng lại có cảm giác làm giảm năng lực lập trình trực tiếp của bản thân. Nó giống như steroid: cơ bắp có thể to lên nhanh nhưng tác dụng phụ rất nhiều, và đến lúc ngừng thì có thể sụp đổ trong chớp mắt. Công ty thì chỉ quan tâm đến kết quả nhanh chứ không quan tâm sức khỏe, nên hiện tượng này càng nghiêm trọng hơn. Tôi bắt đầu dùng theo cách có kiểm soát và giữ mức độ vừa phải
Có cảm giác nhờ LLM mà nhiều lập trình viên đã quên mất bài học được nhấn mạnh trong "Simple Made Easy". Loại code mà LLM tạo ra rất giỏi trong việc sản xuất ra "Ball of Mud" (một mớ code hỗn độn, phức tạp, khó refactor và khó bảo trì). Sức mạnh thực sự là chia nhỏ vấn đề phức tạp thành những thành phần nhỏ, mỗi thành phần hoạt động đơn giản, rồi để sự tương tác giữa chúng tạo ra độ phức tạp cần thiết. Khi từng thành phần đơn giản thì việc hiểu, debug và dự đoán hiệu năng sẽ dễ hơn. Nếu đến lúc LLM thật sự tuân theo nguyên lý này thật tốt thì khi đó có lẽ lập trình viên mới thực sự không còn cần thiết nữa
Thực ra có thể trực tiếp chỉ cho LLM hướng mình muốn. Sự khác biệt giữa người thấy LLM hữu ích và người không thấy hữu ích nằm ở việc họ có hiểu LLM mạnh ở đâu, yếu ở đâu, và có thể dự đoán chất lượng kết quả sẽ thay đổi theo đầu vào (prompt) hay không. Ví dụ, tôi thích hỏi LLM cách chia nhỏ một vấn đề phức tạp để kiểm tra xem có điểm nào tôi bỏ sót không, rồi sau đó mới giao phần triển khai cụ thể. Tôi không bảo nó tạo toàn bộ một dự án lớn mà không có bất kỳ chỉ dẫn nào
Vấn đề "Ball of Mud" không chỉ xảy ra với code. Ở chỗ làm của tôi cũng có những lãnh đạo kêu gọi "hãy tích cực đón nhận AI", và tôi đã thấy ý tưởng đưa cả hệ thống triển khai lẫn vận hành phức tạp cho AI xử lý. Cuối cùng là chồng thêm một hộp đen phức tạp lên trên một hệ thống vốn đã phức tạp, theo logic rằng "muốn hiểu hộp đen thì cần một hộp đen mới", và với tôi thì điều đó vô lý. Bầu không khí ép buộc trong tổ chức đôi khi còn khiến tôi cảm thấy như mình mới là người nghĩ kỳ quặc
Tôi cũng tự hỏi nếu LLM thật sự trở nên hoàn hảo thì lập trình viên có thực sự không còn cần thiết nữa không. Có lẽ chẳng ai muốn một cỗ máy chạy 24/7 chỉ để liên tục "sản xuất" phần mềm. Cuối cùng vẫn sẽ cần những người biết chia nhỏ vấn đề và tìm ra, rồi xây nên, phần mềm thực sự cần thiết. Cũng như ngày nay chúng ta gọi họ là lập trình viên phần mềm
Cuối cùng tôi cũng đi đến kết luận tương tự. LLM không giỏi khi được dùng để điền cả codebase theo kiểu autocomplete. Vấn đề là mô hình tinh thần về cái gì đang làm gì ở đâu biến mất khỏi đầu. Dùng LLM như một StackOverflow được cá nhân hóa — để giải thích từ khóa, tóm tắt khái niệm chưa rõ, gợi ý hướng đi — còn việc triển khai thực tế và ra quyết định thì tự mình làm sẽ hiệu quả hơn nhiều
Tôi cũng dùng theo cách đó, nhưng cursor cứ liên tục dai dẳng đề xuất sửa code. Tôi muốn biết bí quyết để chỉ cho nó introspect mà không động vào nội dung codebase
Trường hợp của tôi thì khác. Nếu lúc nào cũng review kỹ code mà LLM đề xuất, thì có thể hiểu khá rõ cái gì ở đâu và chúng tương tác với nhau như thế nào
Tôi cũng đang giảm mạnh tần suất sử dụng. Có khá nhiều trường hợp câu trả lời của LLM là sai. Vì vậy dạo này tôi chỉ hỏi nó nên tìm trong "manual hay tài liệu nào" thôi, còn nội dung thực tế thì tôi tự kiểm tra. Cách này giúp rèn khả năng xác định vị trí thông tin, đồng thời giảm sự phụ thuộc vào công cụ tìm kiếm và LLM. LLM chỉ là một công cụ, mà độ chính xác cũng không cao lắm
Có một điểm chưa thấy ai nhắc tới, đó là LLM đôi khi còn làm giảm năng suất. Nếu nó dùng những câu trả lời nghe có vẻ hợp lý để kéo mình đi sai hướng thì thời gian lãng phí có thể rất nghiêm trọng. Nhìn tổng thể thì đúng là có nhiều lúc nó hữu ích, nhưng việc "kiểm chứng căn cứ" là rất quan trọng, và thực tế cũng không hiếm khi tự tay làm còn nhanh hơn
Giới hạn của LLM là rất rõ. Nó cực kỳ mạnh, nhưng khó có được những bước nhảy sáng tạo như con người. Ví dụ, với câu hỏi: "Trên Android không bind được cổng dưới 1000, vậy phải làm sao để chạy web server?" thì cả Claude lẫn Gemini đều chỉ đưa ra ba cách giải quyết thông thường sau: 1) reverse proxy 2) root máy 3) nâng số cổng lên. Nhưng lời giải thực sự tôi muốn là HTTPS RR record (tham khảo liên quan). Cả hai đều biết bản thân spec này, nhưng không áp dụng được vào tình huống. Chỉ khi tôi tự bổ sung ngữ cảnh thì mới tìm ra câu trả lời
Thực ra tôi không thấy lạ khi LLM không gợi ý được điều đó. Cũng khó mà kỳ vọng nó đề xuất một spec mới còn chưa được Chrome hỗ trợ chính thức, và có lẽ bản thân tôi cũng sẽ không nghĩ tới mức đó
Thông tin này tôi cũng đã ghi chú lại. Gần đây khi thật sự trò chuyện với LLM, tôi thấy nếu đối xử với nó bằng một chút khoan dung như với con người thì sẽ bớt căng thẳng hơn. Ví dụ khi viết code bằng cursor, nếu tôi chỉ ra rằng "chỗ này bị thiếu", đôi lúc tôi cũng nghĩ rằng chính mình cũng có thể mắc lỗi tương tự. Tôi từng dùng LLM như bạn đồng hành cho "book club" và "movie club", cho nó thảo luận về hai bộ phim, và dù có lỗi như nói sai hoàn cảnh của nhân vật, nhưng không nhất thiết phải chính xác 100%; nếu dành cho nó sự khoan dung giống như với con người thì cuộc trò chuyện sẽ linh hoạt hơn nhiều. Khi trò chuyện với AI, đối xử theo hướng tích cực cũng tốt
Tôi từng nghe về SRV record nhưng thấy hình như hiếm khi được dùng, còn HTTPS RR thì đây là lần đầu tôi biết. Tình trạng hỗ trợ thực tế có vẻ cũng tốt hơn SRV
Đây là vấn đề kinh điển của LLM: "chỉ khi chính bạn nhắc đến đáp án thì nó mới thêm đáp án đó vào danh sách giải pháp"
Nếu chỉ định mục tiêu và các ràng buộc đủ rõ ràng thì ChatGPT o3 vẫn có thể đưa ra giải pháp này. Tuy nhiên nó cũng chỉ rõ một cách chính xác rằng cách này chỉ hoạt động trên các trình duyệt mới. Ví dụ tham khảo
Tôi dùng bản ChatGPT Enterprise khá thường xuyên, và theo thời gian đã rút ra vài điều. Đừng nhét vào một lượng code quá lớn; xử lý ở mức hàm độc lập hoặc class nhỏ sẽ hiệu quả hơn nhiều. Với các yêu cầu sinh hoặc hoàn thiện code, khoảng 10% trường hợp có thể sửa bằng chỉ dẫn bổ sung nhưng chất lượng vẫn giảm, còn khoảng 25% thì giải thích thế nào chất lượng cũng không lên. Gặp những lúc như vậy thì cứ mạnh dạn bỏ qua và tự giải quyết. Ngược lại, nó khá hữu ích cho việc review đoạn code mới viết. Một nửa bình luận là vô dụng, một phần thì mơ hồ, nhưng đôi khi nó thật sự chỉ ra bug hay vấn đề quan trọng. Đừng đưa nhiều trang vào cùng lúc; nên chia nhỏ rồi dùng. Các lĩnh vực ngách như HLSL shader hay SIMD thì gần như không thể mong đợi câu trả lời tốt vì thiếu dữ liệu huấn luyện. Nhìn chung nó giúp cải thiện chất lượng code. Vì phải chia nhỏ code ra theo từng đơn vị để kiểm chứng nên cấu trúc kiến trúc cũng được tách thành hàm/class/module rõ ràng hơn, nhờ đó chất lượng tổng thể tốt hơn
Về phát triển phần mềm dài hạn, điểm hấp dẫn nhất là dùng LLM như một "trình tạo boilerplate cao cấp". Với các việc một lần không cần quan tâm bảo trì thì nó đã rất tốt, nhưng ngay cả trong phát triển dài hạn, nó cũng cực kỳ hữu ích cho những đoạn code lặp lại mà khó trừu tượng hóa, chẳng hạn như code test. Ban đầu tôi khá phản cảm, nhưng giờ thì rất hài lòng. Những phần nhàm chán và lặp lại đã biến thành một trò chơi mới khá thú vị là "tối ưu prompt", và năng suất cũng tăng mạnh. Viết prompt và review code kết thúc nhanh hơn nhiều so với làm thủ công các việc đơn giản. Nhờ vậy chỉ còn lại những phần thú vị thật sự cần dùng não
Cuối cùng tôi nhận ra LLM, không chỉ trong lập trình mà cả trong nhiều công việc khác, là hiện tượng giống như "chế độ ăn kiêng thời thượng". Ai cũng muốn một lời giải nhanh và dễ, nhưng rốt cuộc không có con đường tắt nào. Sự tiện lợi luôn đi kèm đánh đổi, và sớm muộn gì mọi người cũng sẽ chấp nhận thực tế đó