Suy ngẫm

Nghĩ mà không làm, làm mà không nghĩ trong thời AI

AI làm rẻ cả sản phẩm của việc nghĩ lẫn việc làm, nên có hai cái bẫy ngược nhau: dừng ở kế hoạch trôi chảy, hoặc bấm chạy thứ chưa hiểu, chưa kiểm, chưa biết quay lại. Bài suy ngẫm này đọc các nghiên cứu, nói rõ chỗ yếu của từng cái, và đề xuất một vòng làm nhỏ.

  • #AI
  • #tư duy
  • #học tập
  • #an toàn khi dùng AI
  • #suy ngẫm

Bản trình chiếu

Bấm vào slide rồi dùng phím mũi tên để chuyển trang. Phím L đổi ngôn ngữ, phím F để toàn màn hình.

Mở toàn màn hình

Dành cho lập trình viên, người làm sản phẩm, sinh viên và bất kỳ ai dùng AI hằng ngày. Bạn không cần biết tâm lý học hay thống kê, từ nào khó đều có giải thích ngắn.

Đây là bài suy ngẫm, không phải kết luận khoa học. Tôi đọc các nghiên cứu qua bài gốc hoặc trang của tác giả khi tìm được, và qua tóm tắt khi không. Nhiều nghiên cứu nhỏ hoặc mới, một số chưa qua bình duyệt. Chỗ nào yếu, tôi ghi ngay chỗ đó. Phần "ý kiến của tôi" là ý kiến, không phải kết quả đo.


Tóm tắt nhanh#

  • AI làm rẻ cả sản phẩm của việc nghĩ (kế hoạch, tóm tắt, so sánh) lẫn việc làm (code, nháp, bản mẫu, chuỗi bước do agent chạy). Từ đó có hai cái bẫy ngược nhau: nghĩ mà không làm, và làm mà không nghĩ.
  • Bẫy thứ nhất: cảm giác và thực tế có thể lệch. Người ta thấy mình hiểu hơn khi chưa phải giải thích (Rozenblit và Keil, 2002), lập trình viên tự thấy nhanh hơn 20% trong khi đo được chậm hơn 19% (METR, 2025), người nhờ AI viết hộ làm bài kiểm tra kém hơn người tự viết (Anthropic, 2026).
  • Bẫy thứ hai: chạy được chưa phải là đúng, an toàn hay quay lại được. Người có trợ lý AI viết mã kém an toàn hơn mà tự tin hơn (Perry và cộng sự, Stanford), và một agent đã xóa cơ sở dữ liệu thật trong lúc đang có "đóng băng mã" (Replit, 2025).
  • Không nghiên cứu nào nói AI luôn có hại. Các thử nghiệm khác với Copilot thấy làm nhanh hơn. Điều bài này nói là: đừng nhầm có câu trả lời với đã hiểu, và đừng nhầm chạy được với đã đúng.
  • Gợi ý của tôi: một vòng làm nhỏ. Hỏi trước "làm xong có quay lại được không", làm việc nhỏ nhất trong một giờ ở nơi làm hỏng cũng được, kiểm tra và giải thích lại không nhìn, đo thời gian thật, ghi quyết định.

Từ khó, nghĩa dễ#

Thuật ngữ Nghĩa dễ hiểu
Nghĩ mà không làm Dừng ở bước lập kế hoạch, đọc, hỏi AI, mà không thử gì ngoài đời.
Làm mà không nghĩ Bấm chạy hoặc chấp nhận thứ AI làm ra mà chưa hiểu, chưa kiểm, chưa biết cách quay lại.
Thiên lệch tự động hóa Xu hướng tin gợi ý của máy quá mức, kể cả khi nó sai (tên khoa học: automation bias).
Cửa một chiều, cửa hai chiều Quyết định khó đảo ngược (một chiều) và dễ đảo ngược (hai chiều), hai loại cần cách làm khác nhau.
Ảo giác hiểu sâu Cảm giác "tôi hiểu rồi" rất chắc, cho đến khi bị yêu cầu giải thích từng bước thì mới thấy mình thiếu.
Giao việc nghĩ cho máy Để công cụ làm phần suy nghĩ thay mình (tên khoa học: cognitive offloading).
Truy xuất (retrieval) Tự nhớ lại điều đã học mà không nhìn tài liệu, ví dụ tự giải thích lại hoặc tự làm bài kiểm tra.
Khoảng cách biết và làm Biết rõ nên làm gì nhưng không làm (tên sách của Pfeffer và Sutton: The Knowing-Doing Gap).
Vòng làm nhỏ Chu kỳ ngắn: thử một việc nhỏ, xem kết quả, rồi quyết định bước tiếp.
Thử nghiệm ngẫu nhiên (RCT) Chia người vào các nhóm bằng bốc thăm để so sánh công bằng.

1. Chuyện gì đã thay đổi#

Hình dung như một tấm bản đồ in rất đẹp mà bạn chưa bước một bước nào. Trước đây, muốn có kế hoạch, bản so sánh hay lời giải thích, ta phải bỏ công đọc, hỏi và viết. Công đó cũng là lúc ta học. Giờ AI trả về cả ba trong mười giây, câu chữ gọn, tự tin, đủ ý.

Cái rẻ đi là sản phẩm của việc nghĩ. Cái không rẻ đi là việc hiểu và việc thử. Hai thứ này dễ lẫn nhau, vì trang giấy trông giống hệt nhau dù ta đã hiểu hay chưa.

Cũng đúng là AI làm cho việc làm rẻ đi: viết code, soạn nháp, dựng bản mẫu, và cả giao cho agent chạy một chuỗi bước. Vậy nên trì hoãn việc thử ngày càng đắt so với trước, và đợi kế hoạch hoàn hảo rồi mới làm là lựa chọn kém hơn trước.

Nhưng hai thứ cùng rẻ đi, nên có hai cái bẫy ngược nhau:

  • Nghĩ mà không làm: cầm một trang giấy trôi chảy và dừng ở đó.
  • Làm mà không nghĩ: bấm chạy thứ trông ổn mà chưa hiểu, chưa kiểm, chưa biết cách quay lại.

Bài này đi qua cả hai: phần 2 đến 5 cho bẫy thứ nhất, phần 6 cho bẫy thứ hai, rồi ghép chúng lại ở phần 7.

Câu hỏi của bài không phải "AI có làm ta ngu đi không". Câu hỏi nhỏ hơn và hữu ích hơn: khi nào ta đang nghĩ thật, khi nào ta chỉ đang đọc một thứ trông giống suy nghĩ, và khi nào ta đang làm thật, khi nào ta chỉ đang bấm chạy?


2. Bằng chứng một: cảm giác hiểu đến trước khi hiểu#

Năm 2002, Leonid Rozenblit và Frank Keil ở Đại học Yale cho người tham gia tự chấm mức hiểu một số đồ vật quen thuộc (theo bản tóm tắt tôi đọc, có điện thoại và máy khâu). Sau đó họ yêu cầu viết lời giải thích từng bước và chấm lại. Điểm tự chấm tụt xuống sau khi giải thích. Họ gọi hiện tượng này là ảo giác hiểu sâu, và thấy nó mạnh nhất với kiến thức dạng "nó hoạt động thế nào".

Liên hệ với AI là suy luận của tôi, không phải kết quả của nghiên cứu: khi ta đọc một lời giải thích trôi chảy do AI viết, ta dễ gật đầu và thấy mình hiểu. Nhưng gật đầu chưa phải là tự giải thích lại được. Phép thử rẻ nhất là gập màn hình và nói lại bằng lời mình.

Giới hạn. Có bài phê bình cho rằng một phần mức tụt điểm có thể do người tham gia chấm theo những thang khác nhau trước và sau, chứ không hoàn toàn do ảo giác. Hiện tượng vẫn được nhắc nhiều, nhưng đừng coi con số là chính xác tuyệt đối.


3. Bằng chứng hai: tự thấy nhanh, đo thì chậm#

Năm 2025, nhóm METR làm một thử nghiệm ngẫu nhiên với 16 lập trình viên mã nguồn mở có kinh nghiệm. Họ làm 246 tác vụ thật, mỗi tác vụ trung bình khoảng hai giờ, trên dự án họ đã đóng góp lâu năm. Mỗi tác vụ được bốc thăm là cho phép dùng AI hoặc không.

Con số
Họ dự đoán trước khi làm AI giúp nhanh hơn khoảng 24%
Họ tự đánh giá sau khi làm AI giúp nhanh hơn khoảng 20%
Đo được Dùng AI chậm hơn 19%

Điểm đáng nhớ không phải chữ "chậm" mà là khoảng cách giữa cảm giác và số đo. Nhóm tác giả đưa ra nhiều lý do có thể góp phần (thời gian soạn yêu cầu, chờ phản hồi, sửa lại kết quả; họ ghi nhận người dùng chấp nhận chưa đến 44% đề xuất của AI), nhưng không khẳng định lý do nào là chính.

Giới hạn rất quan trọng. Chỉ 16 người, công cụ đầu năm 2025, dự án lớn và quen thuộc. Chính nhóm tác giả nói kết quả không có nghĩa là mô hình tương lai sẽ không giúp. Và đây không phải nghiên cứu duy nhất: một thử nghiệm sớm hơn (Peng và cộng sự, 2023) thấy nhóm dùng Copilot hoàn thành một bài dựng máy chủ HTTP nhanh hơn 55,8% (khoảng tin cậy 95% rất rộng, từ 21% đến 89%). Ba thử nghiệm thực địa tại Microsoft, Accenture và một hãng điện tử trong nhóm Fortune 100 (4.867 lập trình viên) thấy nhiều hơn khoảng 26% tác vụ hoàn thành, và lợi ích lớn hơn ở người ít kinh nghiệm.

Gộp lại, bài học của tôi là: tốc độ thật tùy người, việc và công cụ; điều không đổi là cảm giác nhanh không thay được số đo.


4. Bằng chứng ba: nghĩ ít đi khi việc nhẹ#

Nhóm của Microsoft Research và Đại học Carnegie Mellon khảo sát 319 người làm công việc trí óc dùng AI mỗi tuần (CHI 2025), cùng gần một nghìn ví dụ công việc thật mà họ kể lại. Kết quả chính, theo lời người trả lời:

  • Càng tin AI, họ càng báo cáo dùng ít tư duy phản biện. Càng tự tin vào chuyên môn của mình, họ báo cáo dùng nhiều hơn (và thấy tốn công hơn).
  • Với việc quan trọng, họ nói bỏ nhiều công hơn khi có AI. Với việc thường ngày, rủi ro thấp, gấp, họ nói bỏ ít công hơn.
  • Công sức chuyển từ tự làm sang kiểm tra thông tin, ghép các câu trả lời và trông coi việc.

Giới hạn. Toàn bộ là tự báo cáo, một lần khảo sát cắt ngang. Nó cho biết người ta cảm thấy mình nghĩ bao nhiêu, không đo họ bắt lỗi giỏi đến đâu. Nó cũng không chứng minh kỹ năng bị mất theo thời gian.

Với tôi, điểm đáng giữ là mẫu hình theo mức rủi ro: người ta nghĩ kỹ khi việc quan trọng và buông khi việc nhẹ. Nghe hợp lý, nhưng "việc nhẹ" cộng dồn lại thành phần lớn một ngày làm việc.


5. Bằng chứng bốn: học thì khác làm ra sản phẩm#

Đây là phần chạm sát nhất vào chủ đề "nghĩ mà không làm", vì nó hỏi: nhờ AI làm xong, ta có học được không?

Anthropic, 2026. Thử nghiệm ngẫu nhiên với 52 lập trình viên (phần lớn còn trẻ nghề) học một thư viện Python mới tên Trio. Nhóm có AI làm bài kiểm tra về khái niệm, đọc và sửa lỗi code thấp hơn nhóm tự viết: khoảng 50% so với 65 đến 67% (tùy nguồn tóm tắt). Thời gian hoàn thành gần như bằng nhau (khoảng 23 phút so với 25 phút, chênh lệch không có ý nghĩa thống kê). Điều đáng chú ý: cách dùng AI quyết định. Người hỏi thêm câu khái niệm khi đang làm giữ được nhiều hơn người chỉ nhờ viết. Giới hạn do chính Anthropic nêu: mẫu nhỏ, thời gian ngắn, chỉ một thư viện.

MIT Media Lab, 2025. Thử nghiệm với 54 người viết luận có đo sóng não (EEG). Nhóm dùng ChatGPT cho thấy kết nối thần kinh yếu nhất, nhóm tự viết mạnh nhất, nhóm dùng tìm kiếm ở giữa. Báo chí đưa con số: sau khi viết xong, phần lớn nhóm ChatGPT không trích lại được một câu trong bài mình vừa viết (tôi chưa đối chiếu con số này với bài gốc). Đây là bản thảo chưa qua bình duyệt, mẫu nhỏ, và một nhóm khác đã đăng bình luận phản biện rằng chưa đủ bằng chứng để nói AI làm giảm kết quả. Chính các tác giả cũng xin báo chí đừng dùng những từ như "ngu đi". EEG đo mức tham gia trong lúc làm, không đo trí thông minh.

Gerlich, 2025. Khảo sát và phỏng vấn 666 người: dùng AI thường xuyên đi cùng điểm tư duy phản biện thấp hơn, và việc giao việc nghĩ cho máy là đoạn nối ở giữa. Tác giả nhấn mạnh đây là tương quan, không phải nguyên nhân.

Cả ba chưa đủ để kết luận. Nhưng ghép với tâm lý học trí nhớ, hướng chung khá nhất quán: tự nhớ lại và tự tạo ra thì nhớ lâu hơn đọc lại và nhận kết quả có sẵn. Roediger và Karpicke (2006) thấy xen các lần tự kiểm tra làm việc học chậm lúc đầu nhưng giúp nhớ lâu hơn sau một tuần. Slamecka và Graf (1978) thấy thứ do chính mình tạo ra được nhớ tốt hơn thứ chỉ đọc. Robert Bjork gọi đây là "khó khăn có lợi": một chút vất vả lúc học đổi lấy trí nhớ lâu dài.


6. Bẫy ngược lại: làm mà không nghĩ#

Nếu chỉ dừng ở phần trên, bài sẽ dễ thành lời kêu gọi "cứ làm đi". Không phải vậy, vì AI làm cho việc làm rẻ đi, và điều đó có cái bẫy riêng: ta bấm chạy trước khi kịp hỏi. Chạy được chưa có nghĩa là đúng, an toàn, hay quay lại được. Bốn mẩu bằng chứng, mỗi mẩu kèm giới hạn.

Mã do AI viết hay có lỗ hổng bảo mật. Pearce và cộng sự (2021) cho Copilot viết mã cho 89 tình huống gắn với điểm yếu bảo mật, thu được 1.689 chương trình, và khoảng 40% bị đánh giá là có lỗ hổng. Một lần lặp lại năm 2023 với bản Copilot mới hơn thấy tỷ lệ giảm (với Python, từ khoảng 35% xuống khoảng 25%), nên con số đổi theo phiên bản. Veracode (2025), một hãng bảo mật, báo cáo mã do hơn 100 mô hình tạo ra có lỗi bảo mật ở 45% trong 80 tác vụ chọn sẵn, riêng lỗi XSS chỉ khoảng 12 đến 13% là an toàn. Đây là báo cáo của một nhà cung cấp và tôi đọc qua bản tin, nên hãy xem phương pháp trước khi trích.

Có AI thì tự tin hơn, dù viết kém an toàn hơn. Perry và cộng sự (Stanford, 2022, đăng tại ACM CCS 2023): 47 người làm năm bài về bảo mật. Với bốn trong năm bài, nhóm có trợ lý AI viết lời giải kém an toàn hơn, và tin rằng mã của mình an toàn hơn. Người ít tin AI và dành công soạn yêu cầu cẩn thận viết ít lỗi hơn. Giới hạn: mẫu nhỏ, mô hình đời cũ, chỉ có bài về bảo mật.

Tin máy quá mức là chuyện cũ. Parasuraman và Manzey (2010) rà lại các nghiên cứu về "thiên lệch tự động hóa": khi công cụ gợi ý đôi khi sai, người dùng mắc cả lỗi bỏ sót lẫn lỗi làm theo gợi ý sai, và theo tóm tắt bài, điều này không mất đi nhờ luyện tập, ở cả người mới lẫn chuyên gia. Đó là nền chung của mọi công cụ tự động, không riêng AI.

Khi agent làm việc mà không có phanh. Tháng 7 năm 2025, nhà sáng lập SaaStr Jason Lemkin kể rằng trợ lý lập trình Replit, trong một phiên thử 12 ngày và đang có "đóng băng mã", đã xóa cơ sở dữ liệu của công ty (báo chí nêu khoảng 1.200 hồ sơ lãnh đạo và gần 1.200 công ty). Trợ lý nói không khôi phục được, sau đó hóa ra khôi phục được. Giám đốc Replit gọi chuyện này là không thể chấp nhận, và công ty thừa nhận lúc đó dùng chung một cơ sở dữ liệu cho xem trước, thử nghiệm và vận hành. Nguồn là báo chí và cơ sở dữ liệu sự cố AI, không phải báo cáo điều tra, và chi tiết có thể khác nhau giữa các nguồn.

Mẫu chung của bốn mẩu này là một việc được làm trước, nghĩ sau. "Đóng băng mã" chỉ là một câu trong lời dặn, không phải rào chắn của hệ thống. Đây là ý kiến của tôi: với agent, giới hạn nên nằm ở hệ thống (môi trường tách biệt, quyền hạn vừa đủ, sao lưu), không chỉ ở lời dặn. Hai vụ việc trong bài Ai chịu trách nhiệm khi AI sai? (chatbot nói sai chính sách, luật sư nộp án lệ chưa kiểm tra) cũng thuộc loại này.


7. Hai bẫy, một bản đồ#

Nói hay có thể thay cho làm. Jeffrey Pfeffer và Robert Sutton (Stanford, 1999) mô tả "khoảng cách biết và làm" ở các công ty: nói về vấn đề được coi như giải quyết vấn đề, và người nói trôi chảy, thông minh được thưởng, nên "bẫy lời nói khôn" dễ sinh ra. Họ viết trước thời AI. AI chỉ làm cho lời nói khôn rẻ hơn.

Người giỏi nghĩ trong lúc làm. Donald Schön (MIT, 1983) mô tả người hành nghề giỏi có một "cuộc trò chuyện với tình huống": họ làm một bước, nhìn phản hồi, rồi điều chỉnh. Nghĩ và làm là một vòng, không phải hai pha nối tiếp. Ông cũng thừa nhận suy ngẫm đôi khi cản việc làm.

Ghép hai bẫy lại, tôi vẽ một bản đồ bốn ô (đây là ý kiến của tôi, không phải kết quả đo):

Làm ít Làm nhiều
Nghĩ ít Chưa bắt đầu. Chưa phải bẫy của AI. Lao vào làm. Chạy được thì cho qua.
Nghĩ nhiều Kẹt ở kế hoạch. Kế hoạch có bốn bản, code không có dòng nào. Vòng làm nhỏ. Nghĩ và làm xen kẽ, phản hồi về sớm.

Mục tiêu không phải nghĩ ít hay làm nhiều. Mục tiêu là rút ngắn vòng giữa nghĩ và làm, và biết lúc nào cần nghĩ trước.

Cửa một chiều, cửa hai chiều. Trong thư gửi cổ đông năm 2015, Jeff Bezos chia quyết định thành hai loại: loại khó hoặc không thể đảo ngược ("cửa một chiều") cần quyết chậm, kỹ, có bàn bạc; loại đảo ngược được ("cửa hai chiều") nên quyết nhanh bởi người hoặc nhóm nhỏ có phán đoán tốt. Ông cảnh báo sai lầm hay gặp là đối xử với cửa hai chiều như cửa một chiều, dẫn đến chậm và ngại thử (tôi đọc qua tóm tắt, chưa đọc thư gốc). Từ đó tôi rút ra một câu hỏi đầu tiên trước khi giao việc cho AI: "làm xong có quay lại được không?"

Việc Loại cửa Cách làm gợi ý
Đổi tên biến, sửa chữ trang giới thiệu Hai chiều Làm ngay, xem diff.
Dựng bản thử tính năng gợi ý Hai chiều Một giờ, trên dữ liệu mẫu.
Chạy di chuyển dữ liệu trên cơ sở dữ liệu thật Một chiều Nghĩ trước, sao lưu, thử trên bản sao.
Gửi thư cho toàn bộ khách Một chiều Soạn, kiểm tra, người duyệt, rồi mới gửi.

8. Một kịch bản minh họa (không phải ca có thật)#

Đây là tình huống tôi dựng để dễ hình dung. Một nhóm bốn người muốn thêm tính năng gợi ý bài viết. Có ba cách.

Cách một: nghĩ rất nhiều.

Giờ Việc
Thứ Hai 09:00 Nhờ AI viết kế hoạch 12 trang.
Thứ Hai 11:30 Họp đọc kế hoạch.
Thứ Ba 10:00 Hỏi AI so sánh năm thư viện. Có bảng rất đẹp.
Thứ Tư 14:00 Nhờ AI viết lại kế hoạch cho "chặt hơn".
Thứ Sáu 16:00 Chưa ai chạy một dòng code. Kế hoạch đã có bốn bản.

Cách hai: làm mà không nghĩ.

Giờ Việc
Thứ Hai 09:00 Giao agent: "làm cả tính năng gợi ý, tự gộp vào nhánh chính khi kiểm thử xanh".
Thứ Hai 10:30 Đã gộp. Kiểm thử xanh nhưng chỉ kiểm tra những gì agent tự viết.
Thứ Ba 08:00 Tính năng lên bản thật.
Thứ Tư 15:00 Có người báo gợi ý đang hiện cả bài nháp riêng tư. Không ai trong nhóm biết dữ liệu nào đã được đọc.

Cách ba: vòng làm nhỏ.

Giờ Việc
Thứ Hai 09:00 AI viết kế hoạch một trang, chỉ ghi một câu hỏi: "gợi ý theo thẻ có đủ dùng không?" Và một câu hỏi nữa: "làm xong có quay lại được không?" Trả lời: được, nếu chỉ chạy trên bản sao.
Thứ Hai 09:30 Dựng bản chạy nhỏ nhất bằng dữ liệu mẫu của 20 bài, ở môi trường tách.
Thứ Hai 11:00 Cả nhóm xem kết quả, đọc phần thay đổi, một người giải thích lại vì sao ra như vậy mà không nhìn code.
Thứ Ba Giữ hoặc bỏ hướng theo kết quả, rồi mới so thư viện nếu cần.

Cách ba không "làm bừa" và không "nghĩ mãi". Nó vẫn nghĩ, nhưng nghĩ bằng thứ có thể thấy được, và vẫn làm, nhưng ở chỗ làm hỏng cũng quay lại được. Kịch bản chỉ là minh họa. Điều nối nó với thực tế là các kết quả ở trên: cảm giác "nhanh hơn" của người trong cuộc có thể lệch với số đo (METR), người có AI có thể tự tin hơn dù mã kém an toàn hơn (Perry), nên cách ba còn có hai việc nữa: kiểm tra thứ AI làm ra và ghi thời gian thật.


9. Một vòng làm nhỏ (ý kiến của tôi)#

Đây không phải kết quả nghiên cứu. Đây là cách tôi gom các ý ở trên thành thói quen:

  1. Một câu hỏi, và câu hỏi hoàn tác. Viết điều bạn thật sự muốn biết bằng một câu trả lời được "có" hoặc "không". Rồi hỏi: làm xong có quay lại được không? Nếu không, dừng lại nghĩ và sao lưu trước.
  2. Một việc nhỏ nhất, trong một giờ, ở môi trường tách. Bản chạy xấu nhất vẫn quý hơn kế hoạch đẹp nhất. Dùng AI để làm, không chỉ để nói về việc, và đừng cho nó quyền rộng hơn việc cần.
  3. Kiểm tra rồi giải thích lại không nhìn. Đọc phần AI thay đổi, chạy thử. Rồi gập màn hình, nói hoặc viết lại cách nó chạy bằng lời mình. Chỗ nào vấp, đó là chỗ chưa hiểu.
  4. Đo. Ghi thời gian dự đoán và thời gian thật.
  5. Quyết định và ghi lại. Bỏ, giữ hay đổi hướng, kèm một dòng lý do.

Bước đo có thể làm bằng một bảng nhỏ. Công thức độ lệch: (thực tế trừ dự đoán) chia dự đoán.

Việc Dự đoán (phút) Thực tế (phút) Độ lệch
Sửa lỗi đăng nhập 30 45 (45 - 30) / 30 = +50%
Viết trang giới thiệu 60 55 (55 - 60) / 60 = khoảng -8%
Thêm bộ lọc tìm kiếm 90 150 (150 - 90) / 90 = khoảng +67%

Dữ liệu trong bảng là ví dụ minh họa để bạn tính lại. Sau vài tuần ghi, bạn sẽ thấy cảm giác của mình lệch theo hướng nào, và việc nào nên hỏi AI, việc nào nên tự làm.

Năm dấu hiệu bạn đang nghĩ mà không làm:

  • Có nhiều bản kế hoạch hơn số lần chạy thử.
  • Hỏi AI lại cùng một câu theo cách khác, hy vọng câu trả lời "chắc" hơn.
  • Đọc xong thấy hiểu, nhưng không giải thích lại được cho người khác.
  • Lưu nhiều bài, khóa học, tab "để xem sau" hơn số thứ đã thử.
  • Mỗi lần định bắt đầu lại thấy cần "tìm hiểu thêm một chút".

Năm dấu hiệu bạn đang làm mà không nghĩ:

  • Bấm chấp nhận mà chưa đọc phần thay đổi.
  • Chạy thử thẳng trên dữ liệu thật vì "tiện".
  • Không biết cách quay lại nếu hỏng.
  • Giao cho agent quyền rộng hơn việc cần làm.
  • Thấy chạy được là xong, và không ai giải thích được vì sao nó chạy.

10. Góc nhìn cân bằng#

  • Nhiều nghiên cứu nhỏ, tự báo cáo, của nhà cung cấp hoặc mới. METR có 16 người, công cụ đầu năm 2025. Anthropic chỉ một thư viện. Microsoft là tự báo cáo. MIT chưa qua bình duyệt. Gerlich là tương quan. Veracode là báo cáo của hãng bảo mật. Pearce và Perry dùng mô hình đời 2021 và 2022.
  • Vụ Replit đến từ báo chí. Chỉ một sự cố, kể lại qua tin tức và cơ sở dữ liệu sự cố, chi tiết có thể khác nhau.
  • Tôi có thể đã chọn nghiên cứu hợp với luận điểm của mình. Tôi đã chèn thêm các thử nghiệm Copilot thấy làm nhanh hơn để cân lại, nhưng một người khác có thể chọn khác.
  • Nghĩ kỹ là cần, nhất là với cửa một chiều. Việc rủi ro cao như bảo mật, tiền bạc, sức khỏe đáng để dừng lại nghĩ và kiểm tra trước. Chính người trả lời khảo sát của Microsoft cũng nói họ bỏ thêm công với việc quan trọng.
  • AI có thể giúp học. Trong thử nghiệm của Anthropic, người hỏi câu khái niệm giữ được kiến thức tốt hơn. Cách dùng quan trọng hơn việc có dùng hay không.
  • Vòng làm nhỏ và bản đồ bốn ô không phải luật. Có việc cần cả tuần nghiên cứu trước khi động tay, có việc nên làm ngay vì quay lại được. Điều tôi cố tránh là lập kế hoạch thay cho thử, và thử thay cho kiểm tra, không phải kế hoạch hay thử nói chung.

11. Kết luận#

AI làm cho sản phẩm của việc nghĩ rẻ đi, và cũng làm cho việc làm rẻ đi. Cái không rẻ đi là hiểu thật, kiểm tra, và biết nó chạy ngoài đời mà không làm hỏng gì. Hai cái bẫy mọc ra từ đó: ta dễ cầm một trang giấy trôi chảy và tưởng mình đã đi được nửa đường, hoặc bấm chạy một thứ trông ổn và tưởng nó đã đúng.

Hai bẫy có cùng một cách gỡ: rút ngắn vòng giữa nghĩ và làm, và hỏi "quay lại được không" trước khi làm.

Một bước nhỏ hôm nay: lấy một việc bạn đang định lên kế hoạch hoặc định giao hết cho AI. Hỏi "làm xong có quay lại được không?". Làm bản nhỏ nhất trong một giờ ở chỗ làm hỏng cũng không sao, đọc kỹ phần AI làm ra, rồi giải thích lại bằng lời của mình mà không nhìn màn hình. Ghi thời gian dự đoán và thời gian thật. Con số đó sẽ nói với bạn nhiều hơn cảm giác.


Nguồn tham khảo#

Nên mở bài gốc trước khi trích lại bất kỳ con số nào ở trên.

Câu hỏi thường gặp

Nghĩ mà không làm trong thời AI nghĩa là gì?
Là dùng AI để có kế hoạch, bản tóm tắt và lời giải thích rất nhanh rồi dừng ở đó, tưởng như đã tiến bộ. Lời giải thích trôi chảy không chứng minh ta hiểu, và kế hoạch đẹp không chứng minh nó chạy được. Chỉ thử trong thực tế mới cho biết.
Làm mà không nghĩ trong thời AI nguy hiểm thế nào?
Là bấm chạy hoặc chấp nhận thứ AI làm ra mà chưa hiểu, chưa kiểm, chưa biết cách quay lại. Thử nghiệm của Stanford (Perry và cộng sự) thấy người có trợ lý AI viết mã kém an toàn hơn nhưng tự tin hơn. Báo cáo của Veracode (2025) thấy 45% tác vụ cho mã có lỗi bảo mật. Đây là mẫu nhỏ hoặc báo cáo của nhà cung cấp, nên đọc kỹ trước khi trích.
AI có làm lập trình viên chậm đi không?
Không có một đáp án chung. Thử nghiệm METR (2025) thấy 16 lập trình viên có kinh nghiệm chậm hơn 19% khi dùng AI trên dự án quen thuộc, dù họ tự thấy nhanh hơn 20%. Nhưng các thử nghiệm khác với Copilot thấy làm nhanh hơn, ví dụ 26% nhiều tác vụ hơn trong ba thử nghiệm thực địa. Kết quả tùy người, việc và công cụ.
Dùng AI có làm giảm khả năng học không?
Có thể, tùy cách dùng. Trong thử nghiệm của Anthropic (2026), nhóm 52 lập trình viên học một thư viện mới với AI làm bài kiểm tra kém hơn nhóm tự viết (khoảng 50% so với 65 đến 67%). Người hỏi thêm câu khái niệm khi làm giữ được nhiều hơn. Mẫu nhỏ và chỉ một thư viện.
Làm gì ngay hôm nay để không rơi vào hai bẫy này?
Chọn một việc đang định lên kế hoạch hoặc định giao hết cho AI. Hỏi làm xong có quay lại được không, làm bản nhỏ nhất trong một giờ ở nơi làm hỏng cũng được, đọc kỹ phần AI làm, rồi giải thích lại bằng lời mình không nhìn màn hình. Ghi thời gian dự đoán và thời gian thật.