Bạn đang dùng AI như một cái nạng, hay như một huấn luyện viên?

Hai kiểu nhờ AI giúp đỡ

Khi gặp bug, bạn có hai lựa chọn.

Cách thứ nhất: paste thông báo lỗi vào, lấy giải pháp, copy vào code, chạy được, chuyển tiếp. Nhanh. Gọn. Vấn đề biến mất.

Cách thứ hai: mô tả vấn đề, nhờ AI giải thích xem thật ra điều gì đang sai, làm việc cùng nhau để tìm ra nguyên nhân, rồi đọc thêm tài liệu liên quan để đóng vòng lặp. Chậm hơn. Ma sát nhiều hơn. Nhưng đến cuối, bạn thật sự học được thứ gì đó.

Cả hai đều có cảm giác năng suất trong thời điểm đó. Chỉ có một cái tích lũy theo thời gian.

Tại Codepet, chúng tôi dành nhiều thời gian quan sát cách người học tương tác với AI - những mẫu hành vi nào cho thấy ai sẽ tiến bộ, ai giậm chân tại chỗ, và ai cuối cùng ra được sản phẩm thật. Điều tạo ra sự khác biệt lớn nhất không phải tài năng hay số giờ đầu tư - mà là liệu bạn đang dùng AI như một "cái nạng", hay như một "huấn luyện viên".

Khi AI trở thành cái nạng

Cái bẫy này rất dễ sa vào - và hoàn toàn hợp lý. Khi mới học code, thông báo lỗi đọc như mật mã, mô hình tư duy chưa hình thành, và AI có thể xóa tan sự bối rối ngay tức khắc. Tất nhiên bạn cứ với tay ra mà thôi.

Vấn đề chỉ lộ ra dần dần. Người học theo kiểu "nạng" thường có những biểu hiện này:

• Thu thập được giải pháp nhưng không xây dựng được hiểu biết. Code chạy, nhưng hỏi tại sao nó chạy được - họ lúng túng. Họ có một đống bài giải, nhưng không có nền tảng.
• Mất khả năng chịu đựng sự mơ hồ. Ngồi với một vấn đề năm phút trước khi nhờ AI bắt đầu cảm thấy khó chịu - thậm chí bất an. Khả năng tự suy luận qua sự không chắc chắn - vốn là phần cốt lõi của lập trình - dần dần teo lại.
• Tiến theo vòng tròn. Dự án mới mang đến đúng những bối rối cũ, bởi vì các khái niệm nền tảng chưa bao giờ thật sự được xây dựng. Cái giàn giáo không bao giờ được tháo ra.

Đây không phải lỗi lầm về tính cách. Đây là thất bại của feedback - không ai nói với họ rằng tốc độ không phải là mục tiêu.

Khi AI trở thành huấn luyện viên

Người học dùng AI theo kiểu "huấn luyện viên" đang làm điều khác ở tầng mục đích. Họ không cố xóa bỏ vấn đề. Họ đang cố trở thành người có thể tự giải quyết nó.

Biểu hiện cụ thể:

• Hỏi "tại sao" trước "cái gì". Thay vì "sửa lỗi này đi", họ hỏi: "Lỗi này nghĩa là gì - mình đang hiểu sai khái niệm nào ở đây?" Họ dùng AI để soi sáng, không chỉ để lấy output.
• Cố ý vật lộn một chút trước. Họ dành vài phút thật sự cố suy luận trước khi hỏi. Khi hỏi, họ đã có đủ bối cảnh để câu trả lời thật sự đi vào đầu.
• Giải thích lại bằng lời mình. Sau khi nhận giải thích, họ nói lại bằng ngôn ngữ của mình - đôi khi ngay trong cuộc chat: "Ý bạn là hàm này trả về undefined vì mình gọi nó trước khi async operation hoàn thành, đúng không?" Việc giải thích buộc phải có sự hiểu biết thật sự.

Thói quen cuối cùng đó mạnh hơn bề ngoài rất nhiều. Nếu bạn không giải thích được, tức là bạn chưa hiểu - và AI chính là công cụ hoàn hảo để kiểm tra xem lời giải thích của bạn có đúng không.

Tại sao sự khác biệt lại vô hình trong lúc đó

Đây là điều khiến kiểu "nạng" khó nhận ra: hai loại session trông giống hệt nhau từ bên ngoài. Cả hai đều đặt câu hỏi. Cả hai đều nhận câu trả lời. Cả hai đều có code chạy được.

Sự khác biệt hoàn toàn ở bên trong. Và chỉ hiện ra vài tháng sau - khi người học kiểu "nạng" gặp loại vấn đề mới và vẫn không có công cụ, trong khi người học kiểu "huấn luyện viên" đã lặng lẽ xây dựng được một thư viện tư duy thật sự.

Câu hỏi không phải là AI có giải quyết được vấn đề không. Câu hỏi là: bạn có thể giải quyết nó không - nếu AI không có ở đó?

Thay đổi góc nhìn như vậy biến đổi hoàn toàn cảm giác của mỗi buổi học. Mỗi buổi trở thành một lựa chọn nhỏ: nhường hết việc suy nghĩ, hay dùng AI để mài sắc tư duy của chính mình.

Bốn thay đổi thực tế

Nếu bạn nhận ra mình đang trong mẫu "nạng", câu trả lời không phải là dùng AI ít hơn - mà là dùng có chủ đích hơn.

1. Thử trước khi hỏi. Trước khi đặt bất kỳ câu hỏi nào, viết ra bạn nghĩ vấn đề là gì - dù chỉ là một comment, dù bạn sai. Điều này đặt mô hình tư duy hiện tại của bạn lên bàn, giúp câu trả lời của AI hữu ích hơn nhiều.

2. Hỏi về giải thích, không chỉ giải pháp. "Sửa cái này" ra code. "Giải thích tại sao cái này bị lỗi, rồi giúp mình sửa" ra hiểu biết. AI sẽ làm cả hai - nhưng bạn phải tự hỏi đúng.

3. Tóm tắt những gì bạn học được sau mỗi buổi. Hai câu thôi, chỉ cho bạn. Việc tổng hợp lại củng cố kiến thức theo cách mà đọc lướt không làm được.

4. Xây dựng thứ gì đó buộc bạn phải ra quyết định. Làm theo tutorial ít rủi ro; dự án thật nơi bạn thiết kế hệ thống buộc bạn vào chế độ "huấn luyện viên". Khi bạn là kiến trúc sư, bạn không thể thuê ngoài những lựa chọn quan trọng.

Nếu muốn đào sâu hơn về góc độ dự án, bài viết về vì sao người học mới thường va vào tường phân tích kỹ những mẫu hành vi tách biệt người cuối cùng ra được sản phẩm khỏi người bỏ cuộc.

Codepet nhìn nhận điều này thế nào

Sự phân biệt "nạng" và "huấn luyện viên" thật ra là ý tưởng cốt lõi đằng sau cách Codepet được thiết kế. Các vòng phản hồi của chúng tôi được xây dựng có chủ đích để đẩy về phía chế độ "huấn luyện viên" - nhắc người học thử trước khi AI vào cuộc, yêu cầu họ giải thích lại khái niệm, thiết kế bài tập dự án chỉ có nghĩa khi bạn thật sự hiểu mình đang xây dựng gì.

Không phải vì sự hỗ trợ của AI là điều xấu. Mà vì một công cụ học tốt nên được đo bằng năng lực nó xây dựng - không phải tốc độ nó loại bỏ khó khăn. Bạn có thể đọc thêm cách chúng tôi suy nghĩ về điều này tại mục Thấu hiểu người dùng của Build Log.

Người đồng hành bạn cần là người khiến bạn thông minh hơn - không phải người suy nghĩ thay bạn.

Một điều để mang theo

Lần tới khi bị kẹt: trước khi mở AI, viết một câu về những gì bạn nghĩ đang sai.

Dù câu đó hoàn toàn lạc đề. Dù bạn không có chút manh mối nào. Ba mươi giây nỗ lực đó đặt bạn vào một mối quan hệ căn bản khác với câu trả lời bạn sắp nhận được.

Đó là thói quen. Nhỏ, dễ bỏ qua, và - khi làm nhất quán - thứ thật sự tích lũy thành sự tiến bộ.