LLM Fallacy

Có một điều khá lạ mà mình bắt đầu cảm nhận rõ hơn trong vài tháng gần đây, đặc biệt khi team dùng AI nhiều hơn trong công việc hằng ngày.

Mọi người làm nhanh hơn thật.

Code ra nhanh hơn. Tài liệu ra nhanh hơn. Research nhanh hơn. Những task trước đây có thể mất vài tiếng, thậm chí vài ngày, bây giờ đôi khi được xử lý trong vài chục phút. Nhìn từ bên ngoài, mọi thứ có vẻ rất tích cực. Velocity tăng. Output nhiều hơn. PR nhiều hơn. Document cũng đầy đủ hơn.

Nhưng đi cùng với đó, mình bắt đầu thấy một vấn đề khác âm thầm xuất hiện.

Có những lúc output rất tốt, nhưng khi hỏi sâu hơn thì người làm lại không thật sự explain được vì sao họ chọn cách đó. Có những đoạn code nhìn rất sạch, comment đầy đủ, structure khá ổn, nhưng khi hỏi “nếu case này fail thì debug ở đâu?”, hoặc “tại sao dùng approach này thay vì cách đơn giản hơn?”, thì câu trả lời bắt đầu mơ hồ.

Lúc đầu mình nghĩ có thể do task hơi phức tạp, hoặc do bạn đó chưa chuẩn bị kỹ khi review. Nhưng sau vài lần như vậy, mình nhận ra đây không còn là chuyện của một cá nhân hay một task cụ thể nữa. Nó là một pattern mới khi chúng ta làm việc với AI.

AI đang làm chúng ta tạo ra output tốt hơn rất nhiều. Nhưng đồng thời, nó cũng có thể khiến chúng ta dễ nhầm rằng năng lực thật của mình cũng đã tốt hơn tương ứng.

Gần đây mình đọc một paper có tên The LLM Fallacy: Misattribution in AI-Assisted Cognitive Workflows, và thấy nó gọi khá đúng vấn đề này: LLM Fallacy.

Hiểu đơn giản, LLM Fallacy là một dạng lỗi phân bổ nhận thức.

Khi bạn dùng AI để tạo ra một output tốt, não bạn nhìn thấy kết quả đó và rất dễ quy nó về năng lực của chính mình. Output tốt nên mình cảm thấy mình giỏi hơn. Task khó mà vẫn xử lý được nên mình cảm thấy mình đã lên level. Code chạy, test pass, PR được merge, nên mình cảm thấy mình hiểu vấn đề.

Nhưng thực tế có thể không phải vậy.

Một ví dụ rất đơn giản: bạn cần viết một module authentication. Trước đây, nếu tự làm, bạn phải ngồi nghĩ flow login, JWT token, refresh token, expiry, middleware, error handling, edge cases, test cases. Quá trình đó mệt hơn, chậm hơn, nhưng chính nó tạo ra năng lực.

Bạn phải vật lộn với vấn đề. Phải sai. Phải sửa. Phải debug. Và sau cùng, bạn hiểu mình đang làm gì.

Còn bây giờ, bạn mở Cursor hoặc Claude, gõ một prompt bằng tiếng Việt. Trong vài chục giây, AI generate cho bạn một module khá hoàn chỉnh. Có token logic, có refresh flow, có validate input, có error handling, có test. Bạn đọc qua, thấy hợp lý, chạy thử thấy pass, chỉnh thêm vài chỗ rồi merge.

Không có gì sai ở đây cả.

Mình cũng dùng AI như vậy mỗi ngày. Team mình cũng dùng. Và mình nghĩ trong thời điểm này, không dùng AI gần như là tự làm mình chậm hơn.

Nhưng vấn đề nằm ở một chỗ rất tinh tế: bạn không thật sự viết toàn bộ đoạn code đó. AI viết phần lớn. Bạn là người điều phối, review, chỉnh sửa và quyết định merge.

Nếu bạn hiểu rõ toàn bộ logic phía sau thì rất tốt. Nhưng nếu bạn chỉ nhìn output thấy ổn rồi tin rằng mình đã “làm được”, thì đó là lúc LLM Fallacy bắt đầu xảy ra.

Điểm nguy hiểm của LLM Fallacy là nó không tạo ra cảm giác bất an ngay lập tức.

Ngược lại, nó tạo ra cảm giác tự tin.

Bạn không cảm thấy mình đang bị phụ thuộc. Bạn cảm thấy mình đang mạnh hơn. Bạn thấy mình làm được nhiều hơn, đụng được vào nhiều phần phức tạp hơn, xử lý được nhiều task hơn. Những thứ trước đây mình hơi ngại đụng vào, giờ với AI bên cạnh, mình thấy có vẻ cũng không quá khó.

Đây là phần làm nó rất khó nhận ra.

Vì trong ngắn hạn, mọi tín hiệu đều có vẻ tích cực. Bạn ship nhanh hơn. Bạn trả lời nhanh hơn. Bạn xử lý nhiều việc hơn. Bạn ít bị kẹt hơn. Bạn có cảm giác mình đang trở thành một phiên bản tốt hơn của chính mình.

Nhưng cần tách hai thứ ra.

Một bên là perceived capability — năng lực bạn cảm nhận về bản thân.

Một bên là actual capability — năng lực thực sự của bạn khi phải tự hiểu, tự giải thích, tự debug, tự chịu trách nhiệm.

Khi dùng AI nhiều, perceived capability thường tăng rất nhanh. Nhưng actual capability không chắc tăng cùng tốc độ.

Actual capability chỉ tăng khi bạn thật sự hiểu. Khi bạn có thể giải thích lại bằng ngôn ngữ của mình. Khi bạn biết trade-off. Khi bạn biết edge case. Khi bạn có thể debug nếu AI không còn ở đó. Khi bạn biết phần nào trong output là đúng, phần nào có risk, phần nào chỉ nhìn có vẻ hợp lý nhưng thực ra chưa chắc phù hợp với context của hệ thống.

Khoảng cách giữa hai thứ này mới là phần nguy hiểm.

Mình nghĩ đây sẽ là một loại “debt” mới trong các team sử dụng AI nhiều: understanding debt.

Trước đây chúng ta hay nói về technical debt. Code viết nhanh quá, design chưa tốt, sau này phải trả nợ. Nhưng bây giờ còn có một dạng nợ khác: hệ thống có code, có document, có automation, có test, nhưng không ai thật sự hiểu đầy đủ nó đang vận hành như thế nào.

Một PR 3000 dòng có thể được tạo ra rất nhanh. Nhưng nếu người submit không explain được design decision, không biết impact đến module cũ, không biết rollback thế nào nếu lỗi, thì vấn đề không chỉ nằm ở size của PR.

Vấn đề là ownership đã bị mờ đi.

Và khi ownership bị mờ, trách nhiệm cũng mờ theo.

Trước đây, khi một developer viết code, dù code có thể chưa đẹp, nhưng thường họ vẫn có một mức ownership nhất định. Họ biết mình đã nghĩ gì, đã thử gì, đã sửa gì, và tại sao cuối cùng chọn cách đó. Nhưng với AI, quá trình tạo ra output bị rút ngắn và bị ẩn đi rất nhiều.

Người review chỉ nhìn thấy PR cuối cùng. Họ không biết phần nào là người viết thật sự nghĩ ra, phần nào AI generate, phần nào được verify kỹ, phần nào chỉ được đọc lướt qua vì “trông cũng hợp lý”.

Đây là một thứ mình tạm gọi là pipeline opacity.

Pipeline tạo ra output trở nên mờ hơn. Và khi pipeline mờ hơn, việc đánh giá năng lực thật cũng khó hơn.

Ở cấp độ cá nhân, LLM Fallacy có thể khiến bạn ảo tưởng nhẹ về năng lực của mình.

Nhưng ở cấp độ team, nó có thể trở thành rủi ro vận hành.

Một team có thể ship nhanh hơn, nhưng lại hiểu hệ thống ít hơn. Một team có thể merge nhiều PR hơn, nhưng lại có ít người thật sự nắm được logic lõi hơn. Một team có thể tạo ra nhiều document hơn, nhưng khi cần ra quyết định thì vẫn không ai chắc assumption nào là quan trọng.

Điều đáng sợ nhất không phải là AI tạo ra code sai. Code sai thì trước giờ vẫn có.

Điều đáng sợ hơn là code sai nhưng không ai biết tại sao sai. Hoặc hệ thống lỗi nhưng người từng merge phần đó cũng không biết bắt đầu debug từ đâu.

Đây là lúc AI không còn chỉ là productivity tool nữa. Nó bắt đầu ảnh hưởng đến cách team tích lũy năng lực.

Nếu mỗi task đều được AI làm phần khó nhất, còn con người chỉ làm phần prompt, skim, approve, thì team vẫn có output. Nhưng team có thể đang mất dần những vòng luyện tập quan trọng nhất: suy nghĩ từ đầu, thiết kế giải pháp, phân tích trade-off, debug, và chịu trách nhiệm với lựa chọn của mình.

Năng lực không chỉ đến từ việc nhìn thấy kết quả đúng.

Năng lực đến từ quá trình vật lộn để hiểu vì sao nó đúng.

Đây là lý do mình nghĩ cách review trong team cũng cần thay đổi.

Trước đây, khi review code, chúng ta thường hỏi: code này đúng không, có bug không, có clean không, có theo convention không, có test không. Những câu hỏi này vẫn cần.

Nhưng trong thời đại AI, mình nghĩ cần thêm một lớp nữa:

Người submit có thật sự hiểu không?

Không cần biến review thành một buổi kiểm tra căng thẳng. Không cần hỏi kiểu phán xét. Chỉ cần thêm một vài câu rất đơn giản:

• “Tại sao mình chọn approach này?”

• “Nếu case này fail thì debug ở đâu?”

• “Alternative đơn giản hơn là gì?”

• “Phần này có ảnh hưởng gì đến module cũ không?”

• “Nếu input là null thì flow sẽ đi như thế nào?”

• “Nếu production issue xảy ra, log nào mình sẽ check đầu tiên?”

Những câu hỏi này không nhằm làm khó developer.

Nó tạo ra một chút friction cần thiết.

Trong một môi trường mà AI làm mọi thứ quá trơn tru, một chút friction đôi khi lại là thứ giúp team không trượt vào trạng thái copy-output-and-merge.

Friction ở đây không phải để làm chậm team một cách vô nghĩa. Nó là điểm dừng để đảm bảo người ship thật sự hiểu thứ mình đang ship.

Một cơ chế đơn giản mình nghĩ các team có thể áp dụng là thêm một phần nhỏ vào PR template:

Ví dụ:

Mục tiêu của phần này không phải để kiểm soát ai dùng AI nhiều hay ít.

Mình cũng không nghĩ team nên tạo cảm giác “dùng AI là có lỗi”. Nếu làm vậy, mọi người sẽ chỉ giấu đi cách họ dùng AI, và vấn đề còn tệ hơn.

Mục tiêu đúng hơn là làm rõ quá trình tạo ra output.

Khi phải viết ra phần nào AI generate, phần nào mình đã review, phần nào mình thật sự hiểu, người submit sẽ tự có một khoảnh khắc nhìn lại. Rất nhiều khi, chỉ cần phải articulate ra, mình mới nhận ra có phần mình chưa thật sự hiểu.

Đây là một cách rất nhẹ để giảm pipeline opacity.

Một nguyên tắc khác mình thấy cần thiết là xác định một số vùng quan trọng trong hệ thống là human-first zones.

Không phải module nào cũng có cùng mức rủi ro.

Với những phần như authentication, billing, permission, payment, data migration, security-critical paths, infrastructure changes, hoặc production incident fixes, mình nghĩ con người nên viết skeleton và flow chính trước.

AI vẫn có thể hỗ trợ. Nhưng vai trò nên là review, suggest, refactor, hoặc fill boilerplate sau khi con người đã có conceptual ownership.

Nói đơn giản: với những phần quan trọng, người phải nghĩ trước, AI nghĩ sau.

Điều này có thể làm task chậm hơn một chút ở thời điểm đầu. Nhưng đổi lại, team giữ được năng lực hiểu hệ thống ở những khu vực quan trọng nhất.

Vì khi production có vấn đề, AI không phải người chịu trách nhiệm.

Team mới là người chịu trách nhiệm.

Mình nghĩ có một câu hỏi rất mạnh để kiểm tra một team có đang bị LLM Fallacy hay không:

Nếu tất cả AI tools bị tắt ngay bây giờ và hệ thống bị lỗi production, ai trong team có thể debug được?

Nếu câu trả lời là “không ai chắc lắm”, hoặc “chắc chỉ một người”, hoặc “phải hỏi lại AI”, thì đó là một signal đáng chú ý.

Không phải vì team không được dùng AI.

Mà vì team đang thiếu actual understanding.

Một team dùng AI tốt không phải là team generate được nhiều output nhất. Một team dùng AI tốt là team vẫn có thể defend mọi thứ họ ship.

• Họ có thể giải thích.

• Họ có thể debug.

• Họ có thể rollback.

• Họ có thể đánh giá risk.

• Họ có thể nói “không” với output sai.

• Họ có thể dùng AI như leverage, chứ không biến AI thành cây nạng.

Mình dùng ví dụ coding vì nó dễ thấy nhất, nhưng LLM Fallacy không chỉ xảy ra trong software development.

Một PM có thể dùng AI để viết roadmap rất đẹp, nhưng không thật sự hiểu trade-off. Một BA có thể generate user stories rất đầy đủ, nhưng không thật sự hiểu business flow. Một marketer có thể tạo campaign plan rất nhanh, nhưng không hiểu customer insight. Một writer có thể viết bài rất mượt, nhưng không có thesis riêng. Một researcher có thể tổng hợp paper rất nhanh, nhưng không phân biệt được đâu là insight thật và đâu là hallucination.

AI giúp chúng ta tạo ra sản phẩm của tư duy.

Nhưng nếu không cẩn thận, nó cũng có thể làm chúng ta bỏ qua chính quá trình tư duy.

Và trong dài hạn, quá trình đó mới là thứ tạo ra năng lực.

Một phản ứng khá dễ gặp khi nói về chủ đề này là: vậy có nên hạn chế dùng AI không?

Mình nghĩ câu trả lời không đơn giản như vậy.

Vấn đề không phải là dùng AI nhiều hay ít. Vấn đề là dùng AI theo cách nào.

Có người dùng AI rất nhiều nhưng năng lực vẫn tăng rất nhanh, vì họ dùng AI để học, phản biện, kiểm tra, mở rộng suy nghĩ. Họ hỏi AI để hiểu sâu hơn, chứ không chỉ để lấy output. Họ dùng AI như một người reviewer, một sparring partner, một công cụ để tăng tốc quá trình học.

Nhưng cũng có người dùng AI rất nhiều mà năng lực ngày càng rỗng, vì họ dùng AI để né suy nghĩ. Gặp việc khó thì prompt. Gặp phần chưa hiểu thì paste vào hỏi. Gặp bug thì nhờ AI đoán. Gặp document thì bảo AI viết. Sau một thời gian, họ có rất nhiều output nhưng rất ít ownership.

Cùng một công cụ, nhưng tạo ra hai kết quả rất khác nhau.

Khác biệt nằm ở việc bạn có giữ lại ownership hay không.

Nếu AI giúp bạn đi nhanh hơn nhưng bạn vẫn hiểu đường đi, đó là tốt.

Nếu AI kéo bạn đi còn bạn không biết mình đang ở đâu, đó mới là vấn đề.

LLM Fallacy không phải là vấn đề của việc dùng AI.

Nó là vấn đề của việc dùng AI mà không có cơ chế để verify actual understanding.

Điều nguy hiểm nhất không phải là AI viết sai một đoạn code. Điều nguy hiểm hơn là code sai nhưng không ai biết vì sao sai. Hệ thống lỗi nhưng không ai biết debug từ đâu. PR được merge nhưng author không thật sự hiểu logic. Team ship nhanh hơn nhưng năng lực thật không tăng. Mọi người đều cảm thấy mình hiểu codebase, cho đến khi production incident xảy ra.

AI đang làm output trở nên rẻ hơn rất nhiều.

Nhưng understanding thì không tự động rẻ đi theo.

Muốn hiểu, vẫn phải đọc.
Vẫn phải hỏi.
Vẫn phải debug.
Vẫn phải explain.
Vẫn phải chịu trách nhiệm.
Vẫn phải có những khoảnh khắc vật lộn thật sự với vấn đề.

Một team dùng AI tốt không phải là team generate được nhiều output nhất.

Mà là team có thể nói:

“Dù AI có available hay không, chúng tôi vẫn hiểu thứ mình đang ship.”

Đó mới là năng lực thật.

Và có lẽ trong thời đại AI, năng lực quan trọng nhất không còn là tạo ra output nhanh hơn người khác.

Mà là biết chính xác phần nào trong output đó mình thật sự hiểu, phần nào mình chỉ đang mượn từ AI, và phần nào mình cần học lại trước khi dám ship.

Paper gốc cho bạn nào muốn đọc chi tiết: https://arxiv.org/pdf/2604.14807

Leave a comment