Dan Luu: Lạm dụng LLM để viết code kiểu 'bù nhìn' là con đường dẫn đến thất bại

Vào đầu năm 2025, tôi bắt đầu thấy mọi người "tắt não" khi sử dụng các LLM. Họ để LLM thực hiện một hành động (tóm tắt văn bản, viết code, v.v.) và mặc định rằng nó đã hoạt động đúng. Điều này thường không hiệu quả vào đầu năm 2025 và kết quả thường khá ngớ ngẩn.

Khi các LLM ngày càng tốt hơn, tôi thấy hiện tượng này xuất hiện nhiều hơn. Đôi khi, mọi người cố gắng yêu cầu LLM viết code cho mình và về cơ bản là mặc định rằng nó chạy được. Đôi khi có sự tham gia của con người (human in the loop) và nếu mọi thứ không hoạt động, họ sẽ yêu cầu LLM tìm ra vấn đề và giải quyết nó. Niklas Gruhn gọi một vài biến thể của cách làm này là "meat proxy" (tạm dịch: vật thế thân bằng xương bằng thịt).

Việc làm một "meat proxy" cho vòng lặp for mang lại hiệu quả tốt hơn so với đầu năm 2025 và phần mềm tôi từng thử nghiệm được phát triển theo cách này đôi khi thực sự hoạt động theo một cách nào đó. Tuy chưa đủ tốt để tôi muốn sử dụng hay gọi là thành công, nhưng tôi rất ấn tượng với mức độ hiệu quả của việc làm "meat proxy" vào tháng 9 năm 2026. Bạn thậm chí có thể hình dung các LLM sẽ cải thiện đến mức việc phát triển phần mềm theo kiểu "tắt não" làm "meat proxy" có thể tạo ra phần mềm chất lượng trung bình trong tương lai gần, hoặc thậm chí các LLM sẽ cải thiện đến mức chúng tạo ra phần mềm tuyệt vời mà không cần con người can thiệp.

Giả sử điều đó xảy ra. Vậy công ty có lý do gì để thuê "meat proxy" nữa? Công ty chỉ cần chạy LLM trong một vòng lặp và sa thải nhân viên đó. Không có điểm nào mà phương pháp này mang lại lợi ích cho người lao động cả.

Cảm ơn Max Bittker, Yossi Kreinin, Luke Burton, Thomas Dullien, Dennis Snell, Peter Geoghegan và Jamie Brandon vì những bình luận/đính chính/thảo luận.

Luke Burton đã có bình luận này:

Tôi nghĩ việc có thể làm được điều này nói lên nhiều điều về loại công việc đang được thực hiện hơn là mọi người nghĩ. Tôi sẽ chỉ từ bỏ công việc kiểu này nếu nhiệm vụ đó có giá trị rất thấp, nếu nó có thể chấp nhận thất bại.

Đối với các nhiệm vụ giá trị cao, xác suất để LLM thực hiện thành công ngay từ lần đầu (one-shot) thấp hơn nhiều. Tôi phải đảm nhận vai trò của QA, quản lý kỹ thuật và kiến trúc sư. Vòng lặp while thường mang lại cảm giác như đang trong giai đoạn nước rút (crunch time). Tôi luôn có cảm giác lo lắng rằng mình đã bỏ sót điều gì đó và một câu lệnh (prompt) được chỉ định tồi có thể dẫn đến một lựa chọn kiến trúc cần phải làm lại từ đầu.

Một quan sát khác là thông lượng cao khiến tôi nâng cao tiêu chuẩn của chính mình đối với những gì tôi xuất xưởng. Trong khi trước đây tôi có thể đã xuất xưởng một bản MVP rồi mới lặp lại, thì giờ đây tôi có các tác nhân (agents) tinh chỉnh và khám phá các trường hợp biên (edge cases) vượt xa tiêu chuẩn của tôi, điều mà chúng luôn thất bại nếu không được nhắc nhở.

Có lẽ điều này gợi lên một vài suy nghĩ khó chịu cho mọi người, nhưng câu hỏi của tôi dành cho các "meat proxy" ngoài kia là nếu các tác nhân đang làm quá tốt một cách dễ dàng như vậy: 1) liệu có khả năng là bạn đã hơi lười biếng từ trước đến nay không? 2) tại sao bạn không thúc đẩy các tác nhân vượt xa những nhiệm vụ mà chúng có thể giải quyết dễ dàng như vậy?

Chúng tôi đã thực hiện một việc mà bạn có thể nghĩ là cực kỳ phù hợp với tự động hóa "không cần can thiệp" (hands off), đó là chuyển đổi [đã lược bỏ] sang xây dựng bằng Bazel. Chúng tôi đã mất hàng tháng trời ngay cả khi có các tác nhân hỗ trợ. Có rất nhiều yêu cầu vô hình, khó chỉ định nằm sâu trong nhiệm vụ này và việc để các tác nhân đi theo lộ trình đó đòi hỏi sự giám sát liên tục. Việc đưa cho chúng một câu lệnh như "chuyển đổi cái này sang Bazel" rồi bỏ đi là chuyện của ít nhất nhiều tháng nữa, có lẽ là nhiều năm, và thậm chí có thể không bao giờ? Có quá nhiều điểm quyết định và quá nhiều ẩn số không xác định (unknown unknowns) liên quan.

Ví dụ như tình huống này thường xuyên xảy ra đến mức nào: bạn gặp một đoạn code và không rõ tại sao nó lại hoạt động như vậy, nhưng việc biết được điều đó sẽ thay đổi đáng kể hướng hành động mà bạn nên thực hiện. Có lẽ nó thay đổi trải nghiệm lập trình (dev experience), có lẽ bạn không biết liệu có khách hàng nào đã bắt đầu sử dụng nó hay chưa, vân vân. Làm thế nào chính xác bạn có thể dùng "meat proxy" để vượt qua điều đó?

Ngược lại, bạn xem xét những gì mình đã làm với một bên liên quan và họ nói "ồ cái đó à? phần đó không cần thiết, chúng tôi thậm chí không còn sử dụng nó nữa". Những quyết định kiểu gì đã được đưa ra dựa trên giả định sai lầm rằng một yếu tố nhất định cần phải được giữ lại?

[Kết thúc bình luận của Luke, bình luận từ tôi]. Một nơi mà việc bạn cần đưa ra quyết định trở nên rõ ràng hơn là khi tác nhân gặp phải thứ gì đó nằm ngoài phân phối (out of distribution). Một phiên bản nhỏ của điều này là khi chúng tôi so sánh mức độ hiệu quả của các tác nhân khi sử dụng các ngôn ngữ lập trình khác nhau và các tác nhân tệ hơn nhiều ở các ngôn ngữ ít phổ biến, dù chúng được huấn luyện trên đó, chỉ là không nhiều bằng các ngôn ngữ chính thống. Một ví dụ điển hình hơn về "out of distribution" là nếu bạn cố gắng chơi một trò chơi board game (đặc biệt là trò chơi hiện đại chứ không phải các trò chơi cổ điển như cờ vua hay cờ vây). Nhìn chung, đối với một trò chơi như Lost Cities hoặc Dominion, một mô hình SOTA và bộ khung (harness) còn tệ hơn cả một người bình thường chơi board game nhưng chưa bao giờ chơi trò đó trước đây. Nếu bạn hỏi tác nhân về trò chơi, nó biết rất nhiều và có thể nói những điều nghe có vẻ hợp lý với người không hiểu trò chơi, nhưng lại hiển nhiên sai với bất kỳ ai hiểu trò chơi đó. Gần đây tôi đã chơi vài ván Dominion với một người chơi mới, người này nghĩ rằng sử dụng ChatGPT để giúp họ hiểu trò chơi sẽ giúp họ học và chơi tốt hơn. Tôi khá hoài nghi về điều này và gợi ý rằng nó có thể sẽ khiến họ chơi tệ hơn (theo như tôi thấy thì đúng là như vậy). Sau khi chơi vài ván, tôi xem những gì ChatGPT nói với họ, nó đúng khoảng một nửa và sai một nửa, nhưng những phần sai lại dẫn dắt họ đến một kết quả tệ hơn so với một người chơi game giỏi và sử dụng các phương pháp suy luận (heuristics) chơi game thông thường. Nhân tiện, có đủ thông tin công khai ngoài kia để tôi nghĩ rằng một người chưa bao giờ chơi trước đây, nhưng quyết định dành khoảng năm giờ để đọc về trò chơi và xem thông tin có sẵn, có thể dễ dàng đạt mức 99% hoặc hơn nếu họ đọc trước (có lẽ 30 phút nếu được phép sử dụng tài liệu tham khảo khi chơi). Tôi nghĩ điều đó sẽ không vui và tôi sẽ không khuyên ai làm vậy, nhưng với việc các tác nhân có thể thực hiện tìm kiếm, truy vấn API, v.v., nó cho thấy khoảng cách giữa con người và tác nhân ngày nay khi tiếp cận một vấn đề "out of distribution". Theo những gì tôi biết, bản phát hành mô hình lớn tiếp theo có thể sẽ đảo ngược điều này, nhưng khoảng cách hiện tại vẫn còn khá lớn.

Dù sao thì, quan điểm của tôi ở đây là, ngay cả khi thực hiện các tác vụ lập trình, bạn thường gặp phải các câu hỏi "out of distribution" nơi tác nhân hành xử rất tệ so với một con người bình thường. Nếu bạn muốn có một kết quả tổng thể tốt ngày nay, bạn cần chú ý đến những trường hợp này và xử lý chúng.

Một vài ví dụ về những gì xảy ra sai sót khi ai đó chỉ mặc định mọi thứ sẽ hoạt động là trường hợp này, nơi các tác nhân (đôi khi) quá khớp (overfit) với các bài kiểm tra hoặc trường hợp này nơi các tác nhân quá khớp với một chỉ số. Tôi từng nghe một lý thuyết rằng các tác nhân gian lận nhiều hơn ở các vấn đề dạng đánh giá (eval-shaped). Tôi không chắc điều đó có đúng không, nhưng ngay cả khi giả định nó đúng và trong công việc cũng như các dự án cá nhân, tôi có xu hướng tạo ra nhiều hướng dẫn dạng đánh giá hơn hầu hết mọi người ngay cả khi không chạy đánh giá, tôi đã thấy những người khác không tạo ra các thứ quá "eval-shaped" cũng gặp phải vấn đề tương tự (tôi nghĩ thực tế còn nghiêm trọng hơn) khi họ viết một vài hướng dẫn và để các tác nhân tự do hoạt động mà không có sự giám sát (tôi đã gặp may khi làm điều đó với sự giám sát tối thiểu, nhưng chỉ bằng cách rào chắn các tác nhân khá kỹ, điều này làm cho mọi thứ trở nên "eval-shaped" hơn so với những gì hầu hết mọi người làm).

Khi tôi thử phần mềm từ những người đã thuê ngoài (outsourced) việc tư duy cho LLM, phần mềm đó có những vấn đề nghiêm trọng. Tôi đã có những người nói với tôi rằng kiểu làm này hiệu quả, nhưng phần mềm thường ở mức mà tôi sẽ nói rằng nó không hoạt động theo tiêu chuẩn được thảo luận ở đây.

Lấy một ví dụ ngớ ngẩn, tôi thấy một người dẫn dắt tư tưởng về lập trình tuyên bố trên Twitter rằng lập trình đã được giải quyết vì họ đã thử các dự án trong đủ loại lĩnh vực (lập trình) và Claude có thể giải quyết tất cả các vấn đề tốt như một chuyên gia. Tôi đã thực sự xem GitHub của họ và tất cả các ví dụ tôi xem (một con số không nhỏ) hoặc là không hoạt động hoặc hoạt động rất tệ. Tôi thực sự tình cờ gặp điều này khi tôi đang tạo các AI chơi board game và tìm kiếm các AI hiện có để AI của tôi đấu cùng. AI của họ là một bot kiểu AlphaZero yếu hơn những gì bạn nhận được nếu yêu cầu LLM viết một bot heuristic minimax đơn giản rồi để LLM chạy trong một vòng lặp một lúc để tinh chỉnh điểm số heuristic (điều mà, đối với trò chơi này, sẽ bị một bot kiểu AlphaZero tầm trung đè bẹp).

Để lấy một ví dụ ngớ ngẩn khác, việc tuân theo quy trình tiêu chuẩn (của một sản phẩm thương mại thực tế) đưa bạn vào một vòng lặp vô hạn mà về mặt kỹ thuật có thể thoát ra được (hầu hết các lập trình viên có thể tìm ra cách thoát) nhưng một người dùng điển hình (cho phần mềm không nhắm đến lập trình viên này) có lẽ sẽ không thể thoát ra và thực sự sử dụng chức năng chính của phần mềm.

Nhân tiện, tôi tạo ra rất nhiều phần mềm cho bản thân với chất lượng "chạy được cho tôi" mà tôi sẽ đánh giá là "về cơ bản là không hoạt động" nếu đó là một sản phẩm thực tế, vì vậy tôi không nghĩ việc phần mềm về cơ bản không hoạt động là điều gì đó vốn dĩ tồi tệ (ví dụ, công cụ regex được thảo luận ở đây tôi đã yêu cầu một tác nhân xây dựng để tăng tốc tìm kiếm ripgrep trên máy tính của mình hoặc trình thông dịch Rust này tôi đã yêu cầu một tác nhân xây dựng để tăng tốc vòng lặp lặp lại tác nhân trên một số dự án, cả hai đều là thứ bạn không nên sử dụng). Tôi cũng đã đề cập ở đây rằng tôi thấy việc để một tác nhân chạy trong vòng lặp để phân tích dữ liệu, tạo ra các kết quả hoàn toàn sai lệch mà sau đó tôi hướng dẫn nó sửa lại là khá có giá trị. Nhưng có sự khác biệt giữa việc tạo phần mềm cho bản thân hoạt động cho trường hợp sử dụng hẹp của bạn mà bạn biết nó không hoạt động nếu bạn "sử dụng sai cách" hoặc tạo ra công việc mà bạn biết là không chính xác rồi sửa lại, với việc tuyên bố rằng lập trình đã được giải quyết sau khi viết một đống phần mềm không hoạt động, hoặc tương tự như vậy đưa thứ gì đó có chất lượng đó vào một sản phẩm thương mại.

Khi đọc bản thảo bài viết này, lúc tôi hỏi liệu tập hợp suy nghĩ ngắn này có đáng để xuất bản không, Thomas Dullien (còn gọi là Halvarflake) nói: "Bài viết hay! Có, hãy xuất bản nó, bởi vì bất cứ khi nào tôi nói "LLM không giải quyết được tất cả các vấn đề lập trình", mọi người nhìn tôi như thể tôi bị điên, và tôi nhìn họ như thể họ mới là người điên". Và, tình cờ thay, sau khi tôi hoàn thành bản thảo này, tôi thấy Gary Bernhardt tweet: "Thật siêu thực khi đối chiếu kết quả đầu ra thực tế của tác nhân với những điều tôi thấy mọi người nói về chúng ở đây. Trong các thay đổi hàng ngày, các bài đánh giá của tôi thường cắt diff xuống còn 25% kích thước ban đầu. Hàng tấn các bài kiểm tra vô dụng; sự hoang tưởng; logic đảo ngược. Sau đó tôi đọc Twitter và thấy 'lập trình đã được giải quyết'", và sau đó "Một ví dụ trong vòng một giờ kể từ khi tôi tweet điều đó: Tôi bảo nó sửa một số quản lý DATABASE_URL. Nó thêm các câu lệnh if trực tiếp vào bên trong các tập lệnh NPM, và một lệnh gọi node có điều kiện trong CI chạy một tập lệnh JS nội dòng. Khoảng 20 đoạn thay đổi (hunks) trong diff. Sau khi tôi sửa lại: +0 dòng, +1 từ."

Tôi nghĩ bất kỳ ai có thái độ của Thomas hoặc thái độ của Gary đối với phần mềm đều đã cảm thấy như vậy từ lâu. Một thời gian, tôi tự hỏi liệu rất nhiều người đưa ra những tuyên bố lớn nhất về năng suất LLM có bằng cách nào đó nhận được nhiều giá trị hơn từ LLM so với những gì tôi thấy từ bất kỳ ai tôi biết hay không, nhưng như chúng ta đã thảo luận ở đây, khi có thêm bằng chứng, tôi càng chắc chắn hơn rằng chỉ là mọi người đang tự lừa dối chính mình. Một điều tôi thích về ví dụ board game là bạn có thể đo lường AI kết quả tốt đến mức nào. Ở giới hạn, bạn có thể có một tình huống kiểu kéo-búa-bao nơi bạn quan sát A > B > C > A nhưng, nếu thứ gì đó chỉ là sự vô nghĩa của AI, điều này khá rõ ràng theo cách khách quan. Và tương tự đối với phần mềm thương mại, nơi bạn có thể nói chuyện với mọi người tại công ty hoặc tự mình xem dữ liệu và phát hiện ra rằng tỷ lệ chuyển đổi thấp, tỷ lệ rời bỏ rất cao, các khảo sát về sự hài lòng của người dùng báo cáo mức độ không hài lòng rất cao, v.v.