Nghịch lý “người mới phải hành xử như chuyên gia”
Những developer hưởng lợi nhiều nhất từ coding assistant hiện nay thường đã có nhiều năm kinh nghiệm. Họ biết cách viết spec, chọn kiến trúc, nhận ra design pattern tệ và review output trước khi merge. Trong khi đó, người mới vào nghề lại được khuyến khích, thậm chí bị yêu cầu, dùng cùng công cụ để tăng tốc.
Nghịch lý nằm ở đây: AI coding đòi hỏi năng lực cấp chuyên gia để điều hướng và kiểm tra, nhưng nó cũng có thể bỏ qua chính quá trình thử sai giúp một người hình thành năng lực đó. Nếu model làm luôn phần lập kế hoạch, triển khai và sửa lỗi, người học có thể giao hàng mà chưa xây được mental model về hệ thống.
Tự tin nhưng chưa hiểu
Bài viết dẫn nghiên cứu “The Widening Gap: The Benefits and Harms of Generative AI for Novice Programmers”, trong đó hành vi của người học được quan sát trong các buổi coding. Những người dựa nhiều vào GenAI thường bỏ qua bước lập kế hoạch quan trọng và kết thúc với “ảo giác năng lực” thay vì hiểu vấn đề.
Ngược lại, nhóm biết bỏ qua gợi ý sai hoặc không hữu ích có “negative expertise”: họ đã định hình lời giải trước, rồi dùng AI để tăng tốc phần thực thi. Điểm khác biệt không phải có hay không có Copilot; đó là ai đang giữ quyền quyết định về hướng giải.
LLM cũng tạo ra một kiểu học đảo ngược. Người học phải đặt đúng câu hỏi, đánh giá câu trả lời và sửa hướng cho “người hướng dẫn”. Trong một lĩnh vực mới, họ chưa biết mình đang thiếu gì, nên rất dễ nhận một câu trả lời trôi chảy như bằng chứng rằng mình đã hiểu.
Ma sát là một phần của việc học
Chuyên môn không chỉ đến từ việc quan sát lời giải. Nó hình thành qua lặp lại, thất bại, debug và phải thay một hướng tiếp cận khi nó không scale. Những lần mắc kẹt đó tạo ra trực giác giúp developer nhìn một thay đổi và nhận ra nó có khả năng gây lỗi trước khi test báo đỏ.
Một nghiên cứu UPenn năm 2025 với 1.000 học sinh cho thấy nhóm dùng LLM không có guardrail đạt kết quả kiểm tra thấp hơn 17% so với nhóm chỉ dùng sách giáo khoa. Trong cùng nghiên cứu, biến thể GPT Tutor giúp kết quả luyện tập tăng mạnh vì người học vẫn phải tự giải bài; đến bài kiểm tra, họ đạt mức gần tương đương nhóm dùng sách.
Điều này không có nghĩa mọi sự trợ giúp đều làm giảm kỹ năng. Khi dùng AI như một đối tác hỏi đáp kiểu Socrates, người học vẫn phải phản tư và tự đưa ra lời giải. Một nghiên cứu của Anthropic năm 2026 về coding skills cũng xem nỗ lực nhận thức, kể cả việc bị mắc kẹt, là thành phần quan trọng để hình thành mastery.
Expertise pipeline có thể đổi, không nhất thiết biến mất
Rủi ro dài hạn không chỉ là một developer quên syntax. Nếu công ty tối ưu cho số dòng code và tốc độ tạo patch, người mới có ít cơ hội học cách hiểu hệ thống mà họ sẽ phải bảo trì sau này. Code tiếp tục tích lũy, trong khi số người đủ khả năng phân biệt một bản sửa nghe hợp lý với một bản sửa đúng có thể không tăng cùng tốc độ.
Đây là phiên bản mới của “law of leaky abstractions”: abstraction tiết kiệm thời gian làm việc nhưng không xóa nhu cầu học lớp bên dưới. Khi abstraction rò rỉ ở production, developer vẫn cần biết log nào đáng tin, invariant nào bị phá và thay đổi nào có thể sửa mà không tạo sự cố khác.
Cách dùng AI mà vẫn xây kỹ năng
Tác giả đề xuất ưu tiên “friction first”: dùng model cho tài liệu tương tác, bài tập động và câu hỏi gợi mở, thay vì để nó tạo toàn bộ code. Với một khái niệm mới, output vẫn phải được đối chiếu với tài liệu chính thức, đồng nghiệp và thử nghiệm thực tế.
Một checklist thực dụng gồm:
- Nếu không có AI, mình có thể hoàn thành task này không?
- Model đang giúp hiểu sâu hơn hay chỉ đưa đáp án nhanh hơn?
- Mình có thể giải thích và kiểm tra toàn bộ output được tạo không?
- Mình đã biết đủ để đặt câu hỏi đúng và phát hiện giả định sai chưa?
- Task này có thực sự lặp lại, hay vẫn chứa quyết định kỹ thuật quan trọng?
Điểm cần phân biệt là cognitive offloading và cognitive debt. Offloading giao phần máy móc, lặp lại cho công cụ nhưng giữ phán đoán ở con người. Cognitive debt xuất hiện khi developer giao luôn việc hiểu vấn đề và chọn giải pháp, rồi nhận về code mà họ không đủ khả năng kiểm chứng.
Dev nên quan tâm vì tốc độ ngắn hạn và năng lực dài hạn không tự cân bằng. Một quy trình tốt phải dành chỗ cho người mới tự thiết kế, dự đoán lỗi, review và giải thích trước khi agent hoàn tất phần còn lại.