Đừng "thuê ngoài" quá trình học hỏi: Cạm bẫy của việc phụ thuộc quá mức vào AI khi viết code

Đừng "thuê ngoài" quá trình học hỏi: Cạm bẫy của việc phụ thuộc quá mức vào AI khi viết code

Hiện nay, việc để AI viết code thay vì tự mình mày mò học hỏi trở nên quá dễ dàng. Lỗi được sửa, nhưng mô hình tư duy của bạn thì dậm chân tại chỗ. Chúng ta đang âm thầm đánh đổi năng lực trong tương lai lấy tốc độ ở hiện tại, và các công cụ này sẽ không ép chúng ta phải thay đổi điều đó. Sự thay đổi phải xuất phát từ chính bạn.

Hầu hết chúng ta đều rơi vào một vòng lặp mặc định: bạn dán thông số kỹ thuật hoặc thông báo lỗi vào, mô hình đưa ra bản sửa lỗi, triệu chứng biến mất và bạn gửi code (ship). Ở đâu đó trong vòng lặp đó, sự đấu tranh tư duy hỗn loạn giữa vấn đề và giải pháp đã hoàn toàn ngừng lại.

Các nghiên cứu đều đi đến một kết luận tương đồng

Trong năm qua, nhiều nghiên cứu đã đưa ra những kết quả đáng báo động về việc sử dụng AI trong lập trình.

Anthropic đã thực hiện một thử nghiệm ngẫu nhiên vào đầu năm 2026, trong đó các kỹ sư học một thư viện Python mới, một nửa dùng hỗ trợ của AI và một nửa không. Cả hai nhóm hoàn thành nhiệm vụ với tốc độ như nhau. Tuy nhiên, nhóm dùng AI đã "trượt" bài kiểm tra hiểu bài theo sau: 50% so với 67% của nhóm thủ công. Kết quả thú vị nhất nằm ở chính nhóm dùng AI: những kỹ sư dùng AI để đặt câu hỏi mang tính khái niệm đạt điểm trên 65%, trong khi những người chỉ copy-paste code do AI tạo ra đạt điểm dưới 40%. Công cụ không quyết định kết quả, thái độ sử dụng mới là yếu tố then chốt.

Nghiên cứu "Não bộ bạn trên ChatGPT" của MIT so sánh việc viết bài luận giữa các nhóm dùng LLM, công cụ tìm kiếm và chỉ dùng não bộ. Các phép đo EEG cho thấy kết nối não bộ giảm đi theo từng lớp hỗ trợ từ bên ngoài. Nhóm dùng LLM cho thấy sự liên kết yếu nhất. Sau khi viết xong, 83% người dùng LLM không thể trích dẫn lại một dòng nào trong những gì họ vừa viết. Các nhà nghiên cứu gọi đây là "nợ nhận thức" (cognitive debt): tiết kiệm sức lực tinh thần hôm nay, nhưng phải trả bằng tư duy phản biện vào ngày mai.

Một nghiên cứu khác tại CHI 2026 cũng đưa ra phát hiện liên quan. Khi mọi người có quyền truy cập LLM ngay từ đầu một nhiệm vụ, LLM sẽ định hình toàn bộ vấn đề. Ngay cả khi con người tự làm phần còn lại, sự neo giữ (anchoring) ban đầu đó dẫn đến các quyết định tồi tệ hơn về mặt đo lường. Thứ tự thực hiện các thao tác quan trọng hơn tổng lượng AI được sử dụng.

Các phương pháp luận khác nhau nhưng cùng một kết luận: Sử dụng AI mà không có ý định học hỏi chủ động sẽ âm thầm làm giảm kỹ năng mà bạn đang được trả tiền để thực hiện.

Công cụ được thiết kế để "giao hàng", không phải để dạy học

Nếu bạn bật một tác nhân code (coding agent) và giữ nguyên các cài đặt mặc định, mọi thứ đều được tinh chỉnh cho một chỉ số: hoàn thành nhiệm vụ. Mô hình viết code, bạn chấp nhận, vòng lặp lặp lại. Không có điểm nào công cụ dừng lại và hỏi "bạn nghĩ vấn đề là gì?" hay "hãy thử viết năm dòng đầu tiên xem sao".

Đó không phải là một âm mưu, mà là "trọng lực UX" (UX gravity). Các đội ngũ sản phẩm được thưởng cho các thay đổi được hợp nhất (merged) và thời gian chu kỳ ngắn hơn, chứ không phải vì biến bạn thành một kỹ sư sắc bén hơn. Chúng ta đều muốn ít gõ phím hơn, nên các công cụ đã mài mòn sự ma sát đi. Rắc rối là sự ma sát đó chính là nơi sinh ra việc học.

Một số công ty đã bắt đầu phản ứng lại. Anthropic ra mắt Chế độ Học tập (Learning Mode) cho Claude, sử dụng phương pháp hỏi Sokrates và yêu cầu bạn viết code trước khi tiếp tục. OpenAI và Google cũng có các tính năng tương tự. Nhưng gần như không ai sử dụng chúng cho công việc thực tế. Chúng ta âm thầm xếp chúng vào mục "dành cho học sinh", và đó là một sai lầm. Tính năng giúp sinh viên năm hai học React cũng hoạt động tốt cho kỹ sư cao cấp học Rust. Bạn chỉ cần sẵn sàng cảm thấy mình như một người mới bắt đầu lại.

Tại sao cần hiểu khi AI đã làm được?

Một câu hỏi công bằng. Đối với một số công việc, câu trả lời là: bạn không cần. Nếu đó là code mẫu (boilerplate), code kết dính (glue code), hay một script CI bỏ đi mà bạn sẽ không bao giờ nhìn lại nữa, hãy ủy quyền nó. Chi phí cơ hội của việc ghi nhớ cú pháp YAML là quá cao.

Tuy nhiên, đối với phần mềm thực sự, việc ủy quyền hoàn toàn sẽ gặp sự cố ở một số điểm cụ thể:

• Khi mọi thứ bị hỏng: Code do AI tạo ra cũng bị sập giống như code của con người. Câu nói "tác nhân AI đã viết nó" không giúp bạn debug. Ai đó trong nhóm phải hiểu kiến trúc.
• Khi AI tự tin nhưng sai lầm: Các mô hình ngôn ngữ lớn (LLM) có thể ảo tưởng (hallucinate). Lời phòng thủ duy nhất trước một câu trả lời sai trông có vẻ hợp lý là đủ chuyên môn để nhận ra nó.
• Khi nền tảng thay đổi: Code là tạm thời, hệ thống là vĩnh viễn. Khi các framework cập nhật hoặc một bài đánh giá bảo mật gắn cờ một vấn đề cấu trúc, bạn không thể chỉ cần "re-prompt" để giải quyết. Bạn cần các kỹ sư hiểu hệ thống đủ tốt để di chuyển nó.
• Khi bạn rời khỏi mức trung bình: AI rất xuất sắc với các vấn đề đã được giải quyết hàng triệu lần trên GitHub. Càng đi xa khỏi mức trung bình, nó càng hoạt động kém tệ. Những vấn đề khó, ít tài liệu, những thứ biện minh cho mức lương của một kỹ sư cao cấp, vẫn đòi hỏi sự hiểu biết sâu sắc.
• Khi thị trường điều chỉnh: Sự giảm 20% việc làm của các lập trình viên junior kể từ năm 2022 không phải là ngẫu nhiên. Những kỹ sư chỉ có thể ship code với AI và không thể làm được mà không có nó đang bước vào một lực lượng lao động đang định giá lại giá trị của chuyên môn thực sự.

Nếu bạn sử dụng AI để bỏ qua việc học hỏi, bạn đang đánh đổi sự phù hợp trong tương lai để lấy một ngày thứ Ba dễ thở hơn một chút.

Giải pháp nằm ở cách bạn "prompt", không phải là việc bạn có dùng hay không

Tin tốt là cùng một công cụ tạo ra nợ nhận thức cũng có thể tạo ra những kỹ sư sắc bén hơn. Sự khác biệt nằm ở những gì bạn yêu cầu chúng.

• Đặt giả thuyết trước khi hỏi: Trước khi yêu cầu sửa lỗi, hãy viết xuống hai hoặc ba câu về những gì bạn nghĩ là vấn đề. Sử dụng câu trả lời của mô hình để kiểm tra lý thuyết của bạn, không phải để thay thế nó.
• Yêu cầu giải thích trước khi xem code: Trong lãnh thổ lạ, lời nhắc đầu tiên của bạn nên là "giải thích cách hoạt động này, các lựa chọn thay thế là gì và sự đánh đổi là gì". Chỉ yêu cầu code sau khi bạn đã nắm bắt được các khái niệm.
• Bật Chế độ Học tập khi bạn bị sa lầy: Claude có nó, ChatGPT có Study Mode, Gemini có Guided Learning. Vâng, nó cảm thấy chậm hơn. Đó là mục đích.
• Coi output của AI như một PR từ kỹ sư junior: Đọc nó. Phê bình nó. Đẩy lùi nó. Bạn có hợp nhất nó chỉ vì các bài kiểm tra通过了 không? Nếu không, đừng hợp nhất ở đây.
• Tự suy diễn lại bằng tay đôi khi: Lấy một đoạn code mô hình đã viết cho bạn và thử tạo lại nó từ đầu. Đó là phép kiểm tra hiệu chuẩn cho biết bạn đã âm thầm mất bao nhiêu.
• Yêu cầu mô hình dạy bạn những gì nó vừa làm: Sau khi nó viết một hàm thông minh, hãy hỏi nó đã dùng những khái niệm nào và bạn cần đọc gì để hiểu lựa chọn thiết kế đó. Một lời nhắc thêm sẽ thay đổi những gì bạn thu được từ buổi làm việc.

Không cái nào trong số này là kịch tính. Chúng là những thay đổi nhỏ về thái độ bên trong cùng một công cụ mà bạn đang sử dụng.

Hai chỉ số, không phải một

Tôi đã bắt đầu kết thúc các buổi viết code với một câu hỏi đơn giản: Hôm nay tôi đã học được gì, hay tôi chỉ đóng các vé (tickets)?

Đôi khi câu trả lời trung thực là "Tôi chỉ đóng vấn đề" và điều đó ổn. Nếu nó trở thành câu trả lời trong nhiều tháng liên tiếp, nợ nhận thức đang tích lũy trong nền.

Ship (giao hàng) và Learn (học hỏi) là hai chỉ số riêng biệt. Quản lý và khách hàng của bạn sẽ chỉ bao giờ hỏi về cái đầu tiên. Cái thứ hai là trách nhiệm của bạn.

Tôi thà giao 80% những gì tôi có thể làm và học 100% những gì tôi cần, hơn là làm ngược lại. Trải qua nhiều năm, hai chiến lược này tạo ra những kỹ sư hoàn toàn khác nhau.

Bạn không phải chọn giữa việc sử dụng AI và việc học hỏi. Bạn phải chọn một quy trình làm việc thực hiện cả hai, vì các cài đặt mặc định sẽ không chọn nó giúp bạn. Các công cụ đã sẵn sàng bất cứ khi nào bạn muốn. Nhiệm vụ nhàm chán tiếp theo mà bạn định ủy quyền là một nơi tốt để bắt đầu.