David Chan

Posted on Apr 10

Khi AI Khiến Bạn Quên Cách Code

AI đang giúp lập trình viên đi nhanh hơn. Điều đó gần như không còn tranh cãi. Từ việc sinh boilerplate, viết unit test, gợi ý refactor cho đến giải thích stack trace, các công cụ như ChatGPT, GitHub Copilot, Cursor hay Claude đã trở thành một phần quen thuộc trong workflow hàng ngày.

Nhưng có một câu hỏi khó chịu mà nhiều người né tránh:

Bạn đang dùng AI để tăng năng suất — hay đang dần đánh mất năng lực kỹ thuật cốt lõi vì quá lệ thuộc vào nó?

Đây không phải kiểu lo ngại "AI sẽ cướp việc lập trình viên". Vấn đề thực tế hơn nhiều: nếu mọi lần bí là bạn hỏi AI, thì theo thời gian, bộ não sẽ bớt phải tự giải bài toán. Hệ quả không đến ngay lập tức, nhưng nó tích lũy âm thầm: khả năng debug kém đi, phản xạ thiết kế suy yếu, và cảm giác "mình từng biết cái này mà giờ không viết nổi nếu không có AI".

Bài viết này không chống AI. Ngược lại, tôi cho rằng AI là một đòn bẩy cực mạnh nếu dùng đúng. Nhưng giống như mọi công cụ tăng lực khác, nó có mặt trái: nếu bạn offload quá nhiều tư duy, bạn sẽ trả giá bằng chính kỹ năng của mình.

Bạn Có Đang Lập Trình — Hay Chỉ Đang Nhắc Lệnh?

Ngày nay, một workflow rất phổ biến là:

Mở IDE
Viết một comment mô tả ý định
Chờ AI generate phần còn lại
Chỉnh vài dòng
Submit

Nhìn bề ngoài, quy trình này trông cực kỳ hiệu quả. Nhưng vấn đề nằm ở chỗ: bạn có thật sự hiểu thứ vừa được tạo ra không?

Kịch bản quen thuộc: Mở IDE, gõ comment, đợi AI hoàn thành

Hãy thành thật với chính mình. Bạn có từng:

Nhờ AI viết một hàm đơn giản mà trước đây bạn có thể tự làm trong vài phút?
Copy code do AI sinh ra và chỉ test xem "chạy được chưa"?
Đọc output của AI mà hiểu lơ mơ, nhưng vẫn giữ lại vì "có vẻ đúng"?
Cảm thấy khó chịu rõ rệt khi mất mạng hoặc không có AI assistant?

Đó là lúc AI không còn chỉ là công cụ hỗ trợ nữa. Nó bắt đầu trở thành chiếc nạng kỹ thuật số.

Ranh giới mong manh giữa công cụ hỗ trợ và chiếc nạng kỹ thuật số

Không phải mọi việc dùng AI đều xấu. Thực tế, AI rất mạnh trong các tình huống như:

Sinh boilerplate lặp lại
Gợi ý cách dùng API mới
Tóm tắt tài liệu dài
Hỗ trợ viết test
Refactor những đoạn code rõ mục tiêu

Nhưng AI trở thành vấn đề khi bạn dùng nó để thay thế các năng lực nền tảng như:

Phân tích bài toán
Tự thiết kế lời giải
Suy luận nguyên nhân bug
Đánh giá trade-off kiến trúc
Kiểm chứng tính đúng đắn của code

Khác biệt không nằm ở việc bạn dùng AI bao nhiêu, mà ở chỗ bạn còn giữ vai trò người điều khiển hay không.

Tự kiểm tra: 5 câu hỏi để biết bạn đang ở đâu trên thang phụ thuộc AI

Hãy thử tự chấm điểm cho mình:

Bạn có thể viết một hàm CRUD hoặc xử lý mảng cơ bản mà không mở AI không?
Bạn có thể giải thích từng bước logic của đoạn code AI vừa tạo không?
Khi AI sinh ra code sai, bạn có đủ khả năng sửa mà không phải prompt lại liên tục không?
Bạn có còn thói quen viết pseudo-code hoặc phác logic trước khi hỏi AI không?
Trong một buổi làm việc 1–2 giờ, bạn có thể dành ít nhất 20–30 phút code hoàn toàn không cần AI không?

Nếu phần lớn câu trả lời là "không", thì vấn đề không còn là năng suất nữa. Đó là dấu hiệu của sự phụ thuộc.

Khoa Học Phía Sau Sự Thoái Hóa Kỹ Năng

Điều này không chỉ là cảm giác chủ quan của lập trình viên lâu năm. Nó có thể giải thích bằng khoa học nhận thức.

Cognitive Offloading — khi não bộ "sa thải" kỹ năng không còn được dùng

Cognitive offloading là hiện tượng con người chuyển gánh nặng tư duy sang công cụ bên ngoài. Ví dụ rất quen thuộc:

Không nhớ số điện thoại vì đã có danh bạ
Không nhớ đường vì có Google Maps
Không cần tính nhẩm vì có máy tính

Trong lập trình, AI tạo ra một phiên bản offloading mạnh hơn nhiều:

Không cần nhớ syntax vì AI viết
Không cần tự nghĩ thuật toán vì AI đề xuất
Không cần phân tích bug từ đầu vì AI giải thích hộ
Không cần viết lại từ đầu vì AI sinh luôn implementation

Bản thân việc offload không xấu. Vấn đề là khi bạn offload cả những phần lẽ ra nên là năng lực lõi của nghề.

Neuroplasticity và nguyên tắc "use it or lose it" trong lập trình

Não bộ hoạt động theo nguyên tắc rất thực dụng: thứ gì dùng thường xuyên sẽ được củng cố, thứ gì bỏ lâu sẽ suy yếu.

Trong kỹ thuật, điều này biểu hiện rất rõ:

Không tự debug nữa → khả năng đọc stack trace giảm
Không tự thiết kế logic → tư duy decomposition kém dần
Không tự viết thuật toán đơn giản → phản xạ coding chậm đi
Không đọc kỹ code AI sinh → khả năng code comprehension giảm

Đây chính là skill atrophy — thoái hóa kỹ năng do không sử dụng.

Lập trình viên thường không nhận ra nó ngay, bởi AI luôn bù đắp khoảng trống đó rất nhanh. Nhưng đến lúc AI trả lời sai, mơ hồ hoặc không phù hợp với context hệ thống, bạn sẽ thấy khoảng trống ấy ngay lập tức.

Tại sao tốc độ code nhanh hơn không đồng nghĩa với năng lực cao hơn

Một trong những ảo giác phổ biến nhất của thời AI là:

"Tôi đang làm xong nhiều việc hơn, nghĩa là tôi đang giỏi hơn."

Không hẳn.

Tăng tốc output và tăng năng lực là hai chuyện khác nhau.

Năng suất ngắn hạn: số dòng code, số task hoàn thành, tốc độ tạo prototype
Năng lực dài hạn: khả năng hiểu, kiểm chứng, tối ưu, debug, thiết kế và ra quyết định

AI thường cải thiện rất mạnh vế đầu. Nhưng nếu dùng sai, nó làm xói mòn vế sau.

Đó là nghịch lý năng suất của AI trong lập trình: bạn giao hàng nhanh hơn, nhưng có thể đang trở nên yếu hơn ở những tầng quan trọng nhất của nghề.

Giải Phẫu Một Vòng Lặp Phụ Thuộc Điển Hình

Phụ thuộc AI thường không đến như một cú sốc. Nó đến như một quá trình âm thầm, hợp lý, và rất dễ tự biện minh.

Giai đoạn 1 — Honeymoon: AI làm mọi thứ trơn tru

Ban đầu, trải nghiệm rất tuyệt:

Gõ ít hơn
Viết nhanh hơn
Ít phải nhớ syntax
Tạo được những thứ trước đây mất cả giờ chỉ trong vài phút

Ở giai đoạn này, AI giống như một "senior pair programmer" luôn sẵn sàng hỗ trợ.

Nhưng đây cũng là giai đoạn nguy hiểm nhất, vì thành quả đến quá nhanh khiến bạn ít đặt câu hỏi về cái giá dài hạn.

Giai đoạn 2 — Erosion: Kỹ năng nền bắt đầu mờ dần

Sau một thời gian, những biểu hiện nhỏ bắt đầu xuất hiện:

Bạn lười tự nghĩ lời giải ban đầu
Bạn mất kiên nhẫn với việc đọc docs
Bạn ít tự viết từ đầu hơn
Bạn có xu hướng prompt trước rồi mới hiểu sau

Nếu kéo dài, bạn sẽ thấy một điều đáng lo: những việc từng là "basic" giờ cũng có xu hướng hỏi AI trước.

Ví dụ đơn giản:

// ❌ Vấn đề: Lập trình viên copy từ AI mà không hiểu
const result = array.reduce((acc, curr) => {
  return { ...acc, [curr.id]: curr };
}, {});
// Câu hỏi: Bạn có thể giải thích tại sao dùng reduce ở đây không?
// Bạn có thể viết lại bằng for loop không?

Đoạn code trên không hề phức tạp. Nhưng nếu bạn dùng nó mà không thể giải thích:

vì sao reduce phù hợp,
vì sao acc được khởi tạo bằng object rỗng,
vì sao dùng spread có thể tốn chi phí tạo object mới ở mỗi vòng lặp,

thì bạn không thực sự "sở hữu" đoạn code đó.

Giai đoạn 3 — Crisis: AI sai và bạn không biết tại sao

Mọi chuyện trở nên nghiêm trọng khi AI:

Bịa API không tồn tại
Sinh code đúng syntax nhưng sai logic
Đề xuất pattern không phù hợp với hệ thống hiện tại
Tạo query chậm hoặc có bug edge case
Viết code có security hole hoặc technical debt

Người dùng có nền tảng tốt sẽ:

nhận ra vấn đề,
khoanh vùng lỗi,
sửa hoặc prompt lại có chủ đích.

Người phụ thuộc sẽ:

prompt lại liên tục,
thay đổi câu hỏi theo kiểu mò mẫm,
sửa chỗ này hỏng chỗ khác,
cuối cùng vẫn không hiểu nguyên nhân gốc.

Đó là lúc AI không còn tăng tốc nữa. Nó khiến bạn mắc kẹt trong một vòng lặp không hiểu nhưng vẫn tiếp tục generate.

Giai đoạn 4 — Reckoning: Nhận ra mình không thể code nếu không có AI

Khoảnh khắc này thường đến trong các tình huống rất thật:

Đi phỏng vấn live coding không có AI
Làm bài test offline
Debug production issue lúc gấp, nơi AI trả lời chung chung
Phải maintain một hệ thống cũ với business rule phức tạp
Code review một đoạn AI-generated nhưng không tự tin phản biện

Lúc đó, sự thật lộ ra: bạn vẫn đang làm công việc lập trình, nhưng phần tư duy cốt lõi đang ngày càng bị thuê ngoài cho máy.

Tái Lập Trình Chính Mình — Chiến Lược Phục Hồi Có Cấu Trúc

Tin tốt là kỹ năng có thể phục hồi. Nhưng sẽ không phục hồi chỉ bằng cách "cố gắng dùng AI ít hơn". Bạn cần một quy trình có chủ đích.

Phương pháp "Deliberate Struggle" — cố tình không dùng AI trong 30 phút đầu

Một trong những cách hiệu quả nhất là tạo ra sự vật lộn có kiểm soát.

Quy tắc rất đơn giản:

Trong 30 phút đầu của một task, không dùng AI
Tự đọc đề
Tự chia bài toán
Tự viết pseudo-code
Tự thử implementation đầu tiên

Mục tiêu không phải để viết code hoàn hảo. Mục tiêu là kích hoạt lại mạch tư duy giải quyết vấn đề.

Sau 30 phút, bạn có thể dùng AI để:

so sánh cách tiếp cận,
tối ưu,
tìm edge case,
review code,
đề xuất test.

Như vậy, AI hỗ trợ cho tư duy của bạn thay vì thay thế nó.

Xây dựng "AI-free zones" trong workflow hàng ngày

Bạn không cần cực đoan kiểu "cấm AI hoàn toàn". Cách bền vững hơn là tạo các vùng không AI trong workflow.

Ví dụ:

AI-free debugging: 15 phút đầu tiên tự đọc log, stack trace, reproduce bug
AI-free algorithm drill: mỗi tuần 2–3 bài nhỏ tự làm
AI-free code reading: tự đọc codebase trước khi hỏi AI giải thích
AI-free review: tự review PR của mình trước khi đưa cho AI nhận xét

Một bài tập rất hữu ích:

# Ví dụ về "AI-free drill" — bài tập không dùng AI
# Thách thức: Implement binary search từ đầu, không Google, không AI
# Thời gian: 20 phút
# Mục tiêu: Không phải perfect code, mà là kích hoạt lại tư duy

Những bài tập như vậy nghe có vẻ "cũ", nhưng nó phục hồi thứ mà AI đang vô tình làm yếu đi: khả năng tự triển khai logic từ trí nhớ và hiểu biết nền.

Kỹ thuật Rubber Duck + Feynman: Giải thích code trước khi generate

Nếu chỉ chọn một thói quen để giảm phụ thuộc AI, tôi sẽ chọn thói quen này:

Trước khi nhờ AI viết code, hãy tự giải thích bài toán bằng ngôn ngữ đơn giản.

Bạn có thể làm theo trình tự:

Mô tả bài toán bằng lời
Chia nó thành từng bước
Viết pseudo-code
Chỉ sau đó mới nhờ AI hỗ trợ

Ví dụ:

# ✅ Quy trình lành mạnh khi dùng AI
# Bước 1: Tự viết pseudo-code trước
# for each item in list:
#     if item meets condition:
#         add to result

# Bước 2: Implement thủ công
result = [item for item in data if item['active']]

# Bước 3: Nhờ AI optimize — không phải thay thế tư duy

Điểm mấu chốt ở đây là: AI chỉ nên đến sau khi bạn đã có một mental model tối thiểu về lời giải.

Khi đó:

prompt của bạn tốt hơn,
output của AI sát hơn,
khả năng đánh giá đúng/sai cũng cao hơn.

Code review với tiêu chí: "Tôi có thể viết lại cái này không?"

Một nguyên tắc rất thực dụng:

Không merge một đoạn code do AI sinh ra nếu bạn không thể tự viết lại nó từ đầu ở mức tương đương.

Điều này nghe có vẻ khắt khe, nhưng nó cực kỳ đáng giá. Nó buộc bạn phải kiểm tra:

Tôi có hiểu logic không?
Tôi có biết tại sao chọn cách này không?
Tôi có nhìn thấy edge case không?
Nếu production lỗi, tôi có sửa nổi không?

Nếu câu trả lời là "không", thì đoạn code ấy chưa thật sự là của bạn.

Dùng AI Như Một Kỹ Sư Thực Thụ, Không Phải Người Vận Hành Máy

Muốn dùng AI lâu dài mà không bị "mất nghề", bạn cần đổi mental model.

Mental model đúng: AI là junior dev, bạn là senior reviewer

Nhiều người dùng AI như một "oracle" — hỏi gì cũng tin. Đó là cách dùng nguy hiểm nhất.

Mental model tốt hơn là:

AI giống một junior dev rất nhanh
Nó biết nhiều mẫu phổ biến
Nó tạo nháp rất tốt
Nhưng nó thiếu context thật
Nó không chịu trách nhiệm cho production
Nó có thể tự tin nói sai

Khi nhìn AI theo cách này, bạn sẽ tự nhiên thay đổi hành vi:

hỏi rõ hơn,
kiểm chứng kỹ hơn,
không copy mù quáng,
ưu tiên review thay vì thần phục output.

Giữa các công cụ AI hiện nay, khác biệt chủ yếu không nằm ở "cái nào thông minh tuyệt đối hơn", mà ở workflow phù hợp:

Copilot mạnh ở gợi ý ngay trong IDE, hợp cho luồng coding liên tục
ChatGPT / Claude tốt cho giải thích, phân tích, brainstorming, so sánh giải pháp
Cursor mạnh ở chỉnh sửa theo ngữ cảnh codebase, nhưng càng tiện thì càng dễ khiến người dùng lười tự suy nghĩ

Nói ngắn gọn: tool càng mượt, rủi ro phụ thuộc càng cao nếu bạn không có kỷ luật sử dụng.

Quy trình 3 bước: Hiểu → Thiết kế → Delegate

Một workflow lành mạnh với AI thường có dạng:

Hiểu
- Bài toán là gì?
- Input/output ra sao?
- Constraint nào quan trọng?
- Tiêu chí đúng là gì?
Thiết kế
- Chia nhỏ thành bước
- Chọn data structure / approach
- Nghĩ trước edge case
- Viết pseudo-code
Delegate
- Nhờ AI generate phần implementation
- So sánh với cách của mình
- Yêu cầu AI nêu trade-off
- Tự review trước khi dùng

Điều cần tránh là quy trình ngược lại:

Delegate → Copy → Submit

Đó không phải AI-assisted engineering. Đó là outsourcing tư duy.

Đo lường năng lực thực sự: Bạn có thể debug AI output không?

Một thước đo rất thực tế cho trình độ thật trong thời AI không còn là "bạn generate được nhanh đến đâu", mà là:

Bạn có phát hiện được code AI sai không?
Bạn có kiểm tra được complexity không?
Bạn có hiểu được side effect không?
Bạn có sửa được output khi requirements thay đổi không?
Bạn có thể bảo vệ quyết định kỹ thuật đó trước team không?

Nếu không làm được những điều này, thì AI chưa làm bạn mạnh hơn. Nó chỉ làm bạn nhanh hơn trong phạm vi mình còn kiểm soát được.

Tương Lai Của Lập Trình Viên Trong Kỷ Nguyên AI

AI sẽ không biến mất. Ngược lại, nó sẽ ngày càng tích hợp sâu vào môi trường phát triển phần mềm. Vì thế, câu hỏi đúng không phải là "có nên dùng AI hay không", mà là:

dùng AI thế nào để giá trị của bạn tăng lên thay vì bị bào mòn?

Kỹ năng nào sẽ trở nên khan hiếm và có giá trị hơn

Khi AI ngày càng giỏi ở việc tạo code phổ thông, những kỹ năng sau sẽ càng đáng giá:

Problem framing — định nghĩa đúng bài toán
System design — nhìn được kiến trúc và trade-off
Debugging literacy — tìm và sửa lỗi trong hệ thống thật
Code comprehension — đọc hiểu codebase lớn, cũ, rối
Judgment — biết khi nào AI đúng, khi nào AI nguy hiểm
Metacognition — tự nhận ra mình đang hiểu thật hay chỉ đang "có cảm giác hiểu"

Đây là những thứ khó prompt thay cho bạn.

Sự phân hóa giữa "AI-augmented engineer" và "AI-dependent operator"

Trong vài năm tới, thị trường sẽ phân hóa ngày càng rõ giữa hai kiểu người:

1. AI-augmented engineer

Dùng AI để tăng tốc phần cơ học
Giữ quyền kiểm soát tư duy và quyết định
Hiểu sâu hơn nhờ AI, không phải nông hơn
Dùng AI như đòn bẩy cho năng lực sẵn có

2. AI-dependent operator

Phụ thuộc vào AI cho cả việc cơ bản
Tốc độ nhanh nhưng khả năng tự lực thấp
Khó debug khi rời khỏi "happy path"
Dễ tạo technical debt mà không nhận ra

Nhìn bề ngoài, hai nhóm này có thể đều giao code nhanh. Nhưng khi gặp hệ thống thật, yêu cầu mơ hồ, bug production, hoặc bài toán không chuẩn mẫu, sự khác biệt sẽ lộ ra rất nhanh.

Lời kêu gọi hành động: Chủ động xây dựng kỹ năng nền trong khi dùng AI

Nếu bạn đang dùng AI mỗi ngày, hãy tự đặt cho mình vài nguyên tắc đơn giản:

Không hỏi AI ngay trong 5–15 phút đầu
Luôn viết hoặc nghĩ pseudo-code trước
Không merge code mình không giải thích được
Mỗi tuần có một số phiên AI-free
Dùng AI để review và mở rộng tư duy, không chỉ để generate
Tự hỏi thường xuyên: nếu bỏ AI đi, mình còn làm được đến đâu?

AI không làm bạn quên cách code chỉ vì nó tồn tại. Nó chỉ làm điều đó khi bạn trao luôn phần suy nghĩ cho nó.

Dùng đúng, AI là công cụ giúp bạn tiến xa hơn.
Dùng sai, nó khiến bạn trở thành người vận hành output do máy sinh ra.

Và trong dài hạn, giá trị của một kỹ sư phần mềm chưa bao giờ nằm ở việc gõ code nhanh nhất.

Nó nằm ở khả năng hiểu vấn đề, đưa ra quyết định đúng, và xử lý được những lúc mọi thứ không còn chạy đúng như kỳ vọng.

Kết luận

AI là một lợi thế cạnh tranh thực sự cho lập trình viên hiện đại. Nhưng chỉ những ai giữ được năng lực nền tảng mới biến lợi thế đó thành sức mạnh dài hạn.

Hãy nhớ:

AI nên giảm tải phần lặp lại, không thay thế tư duy
Nhanh hơn không đồng nghĩa với giỏi hơn
Nếu bạn không hiểu code, bạn không thật sự sở hữu nó
Kỹ năng không được dùng sẽ thoái hóa
Người thắng trong kỷ nguyên AI là người biết kết hợp đòn bẩy máy móc với chiều sâu kỹ thuật của con người

Nếu cần một nguyên tắc duy nhất để bắt đầu ngay hôm nay, hãy dùng nguyên tắc này:

Hiểu trước, rồi mới nhờ AI tăng tốc. Đừng để AI trở thành nơi bạn gửi cả quá trình suy nghĩ của mình.

DEV Community

Khi AI Khiến Bạn Quên Cách Code