Khi AI dạy ta quên cách học
Bạn có thể hoàn thành công việc nhanh hơn với AI. Nhưng nếu tốc độ đó đánh đổi bằng chính năng lực bạn đang cần xây dựng thì sao?
Khi AI dạy ta quên cách học
Bạn có thể hoàn thành công việc nhanh hơn với AI. Nhưng nếu tốc độ đó đánh đổi bằng chính năng lực bạn đang cần xây dựng thì sao?
Đó là câu hỏi mà Judy Hanwen Shen và Alex Tamkin — hai nhà nghiên cứu tại Anthropic — đặt ra trong nghiên cứu “How AI Impacts Skill Formation” (tháng 2/2026). Và câu trả lời không đơn giản như chúng ta mong đợi.
Họ thiết kế một thí nghiệm ngẫu nhiên có đối chứng: cho các lập trình viên học một thư viện Python hoàn toàn mới (Trio) — một nửa được dùng AI hỗ trợ, nửa còn lại tự mình giải quyết. Kết quả? Nhóm dùng AI không nhanh hơn đáng kể, nhưng điểm đánh giá kỹ năng giảm 17%. Quan trọng hơn, khoảng cách lớn nhất nằm ở khả năng debugging — chính kỹ năng mà con người cần nhất để giám sát code do AI tạo ra.
Nhưng câu chuyện không dừng ở đó. Khi phân tích sâu cách mỗi người tương tác với AI, nghiên cứu phát hiện sáu khuôn mẫu hành vi khác biệt — trong đó ba khuôn mẫu giữ được khả năng học. Điều phân biệt không phải là có dùng AI hay không, mà là cách dùng: đầu tư nỗ lực nhận thức hay giao phó hoàn toàn.
Điểm chính
Năng suất không bù đắp được năng lực: AI giúp hoàn thành task nhưng giảm 17% kỹ năng đo lường được — đặc biệt ở debugging và hiểu khái niệm
Lỗi là thầy giáo tốt nhất: Nhóm không dùng AI gặp nhiều lỗi hơn gấp 3 lần — và chính quá trình đối mặt với lỗi giúp họ hiểu sâu hơn
Sáu cách dùng AI, ba cách giữ được kỹ năng: Delegation, Progressive Reliance, Iterative Debugging dẫn đến điểm thấp (24-39%); Conceptual Inquiry, Generation-Then-Comprehension, Hybrid Code-Explanation giữ điểm cao (65-86%)
Cognitive engagement là chìa khóa: Không phải bỏ AI, mà là dùng AI theo cách vẫn buộc não bộ phải làm việc
Khi AI trở thành phím tắt: Năng suất có thực sự miễn phí?
AI giúp lập trình viên viết code nhanh hơn. Điều này gần như không còn ai tranh cãi. Nhưng hãy thử dừng lại một nhịp và đặt câu hỏi khác: nếu một junior developer hoàn thành task nhanh gấp đôi nhờ AI, liệu sáu tháng sau, developer đó có thể debug một hệ thống production khi AI không có mặt?
Nghiên cứu “How AI Impacts Skill Formation” của Judy Hanwen Shen và Alex Tamkin (Anthropic, tháng 2/2026) không chỉ đo lường năng suất — họ đo lường cái giá mà năng suất đó đòi hỏi. Và cái giá đó nằm ở chính quá trình hình thành kỹ năng (skill formation) — thứ mà mọi người ngầm giả định sẽ tự xảy ra trong quá trình làm việc.
Câu hỏi cốt lõi ở đây không phải “AI có giúp ta làm nhanh hơn không?” mà là: khi AI rút ngắn con đường từ bài toán đến lời giải, chúng ta đã bỏ lỡ gì trên đoạn đường bị cắt?
Một vòng lặp cũ với công nghệ mới
Kể từ cuộc cách mạng công nghiệp, kỹ năng trên thị trường lao động liên tục dịch chuyển mỗi khi công nghệ mới xuất hiện. Và mô hình dịch chuyển đó có một nhịp điệu quen thuộc đến đáng ngờ: vai trò của con người chuyển từ thực hiện công việc sang giám sát công việc. Robot tự động hóa nhà máy — công nhân chuyển từ lao động tay chân sang giám sát dây chuyền. Phần mềm kế toán — chuyên viên không còn tính toán thô mà tập trung vào chiến lược thuế và quản lý sổ sách. Nhưng hãy lưu ý điều cốt lõi mà cả hai kịch bản đều giữ nguyên: con người vẫn chịu trách nhiệm cuối cùng về chất lượng sản phẩm, và vẫn phải gánh chịu hậu quả khi có lỗi xảy ra. Dù tự động hóa thay đổi quy trình hoàn thành công việc, kiến thức kỹ thuật để nhận diện và sửa lỗi vẫn cực kỳ quan trọng — có lẽ còn quan trọng hơn trước.
Vậy AI — thứ đang hứa hẹn trở thành chất xúc tác cho tự động hóa và năng suất trong vô số lĩnh vực, từ software engineering (kỹ thuật phần mềm) đến entrepreneurship (khởi nghiệp) — liệu có tuân theo cùng một kịch bản cũ? Câu trả lời thành thật là: chưa ai biết rõ. Ngày càng nhiều người lao động dựa vào AI để cải thiện năng suất, nhưng một câu hỏi lớn vẫn lơ lửng: liệu việc sử dụng AI assistance (hỗ trợ từ AI) tại nơi làm việc có cản trở khả năng hiểu sâu các khái niệm cốt lõi, hoặc ngăn cản việc phát triển kỹ năng cần thiết để giám sát những task đã được tự động hóa? Phần lớn nghiên cứu hiện tại tập trung vào sản phẩm đầu ra của AI — số dòng code viết được, chất lượng ý tưởng đề xuất. Nhưng câu hỏi quan trọng không kém, thậm chí có thể quan trọng hơn, là: quá trình nhận hỗ trợ từ AI tác động đến người lao động như thế nào? Khi con người giao phó cho AI những kỹ năng như brainstorming (động não), viết lách, và tư duy phản biện, sự phát triển của chính những kỹ năng đó có thể bị biến đổi đáng kể — tùy thuộc vào cách AI được sử dụng.
Software engineering là lĩnh vực đặc biệt đáng chú ý trong bối cảnh này. Đây là ngành mà AI tools được áp dụng dễ dàng nhất, và AI assistance cải thiện năng suất công việc hàng ngày rõ rệt nhất. Junior developer (lập trình viên mới vào nghề) và novice worker (người ít kinh nghiệm) hưởng lợi nhiều nhất khi dùng AI để viết code. Nhưng hãy nghĩ kỹ hơn một bước: trong những ứng dụng có độ rủi ro cao (high-stakes applications), code do AI viết vẫn cần được con người debug và kiểm thử trước khi triển khai. Lớp xác minh bổ sung đảm bảo an toàn này chỉ hoạt động được khi chính các kỹ sư có đủ năng lực để hiểu code và phát hiện lỗi. Và đây là nghịch lý đang hình thành: khi AI ngày càng mạnh, việc giám sát các hệ thống AI ngày càng phức tạp đòi hỏi con người phải hiểu code sâu hơn — nhưng nếu chính AI đã khiến khả năng hiểu code yếu đi thì sao? Ngay cả khi kỹ năng phần mềm của con người mang tính bổ trợ cho thế mạnh của AI, con người vẫn cần nắm vững các khái niệm nền tảng của phát triển code. Sự kết hợp giữa yêu cầu năng lực liên tục trong môi trường high-stakes và mức tăng năng suất đã được chứng minh nhờ AI khiến software engineering trở thành “phòng thí nghiệm” lý tưởng để nghiên cứu AI tác động đến skill formation (hình thành kỹ năng) ra sao.
Nghiên cứu này đặt câu hỏi trực diện: việc sử dụng và phụ thuộc vào AI có ảnh hưởng đến quá trình phát triển kỹ năng software engineering không? Xuất phát từ thực tế áp dụng AI ồ ạt trong ngành, các tác giả tập trung vào kịch bản phổ biến nhất — kỹ sư học kỹ năng mới ngay trong quá trình làm việc. AI tools có thể giúp họ năng suất hơn, nhưng liệu đồng thời cũng kìm hãm quá trình hình thành kỹ năng? Cụ thể hơn: khi quy trình hoàn thành task có AI hỗ trợ, liệu kỹ sư có bị ngăn cản việc hiểu sâu về các công cụ mà họ dùng để hoàn thành task đó? Để trả lời, nhóm nghiên cứu thiết kế thí nghiệm ngẫu nhiên hóa (randomized experiments), đo lường skill formation bằng cách yêu cầu người tham gia hoàn thành coding tasks với một thư viện hoàn toàn mới mà họ chưa từng sử dụng — mô phỏng cách kỹ sư thực tế tiếp cận kỹ năng mới, bởi các thư viện mới liên tục xuất hiện trong những ngôn ngữ như Python. Sau đó, năng lực của họ với thư viện mới được đánh giá. Hai câu hỏi nghiên cứu chính là: (1) AI có cải thiện năng suất cho coding task đòi hỏi khái niệm và kỹ năng mới không, và (2) việc sử dụng AI có làm giảm mức độ hiểu biết về những khái niệm và kỹ năng mới đó không.
Kết quả nổi bật: nhanh hơn nhưng hiểu kém hơn
Shen và Tamkin thiết kế thí nghiệm xoay quanh thư viện Trio — một thư viện Python cho lập trình bất đồng bộ (asynchronous), ít phổ biến hơn asyncio — với mô hình xử lý đồng thời có cấu trúc (structured concurrency). Họ chọn Trio chính vì tính mới: gần như không ai trong số người tham gia từng sử dụng nó, tạo điều kiện đo lường quá trình học từ con số không.
Kết quả định lượng đáng chú ý. Nhóm dùng AI hoàn thành task có nhanh hơn một chút, nhưng sự khác biệt về thời gian không đạt ý nghĩa thống kê. Trong khi đó, điểm đánh giá kỹ năng giảm 17% — tương đương hai bậc điểm trên thang 27 điểm — với kích thước hiệu ứng Cohen’s d = 0.738 và p = 0.010. Nói cách khác: AI không giúp nhanh hơn đáng kể, nhưng chắc chắn làm người dùng hiểu ít hơn.
Nhưng tại sao AI không tạo ra speedup rõ rệt? Phân tích định tính — xem lại toàn bộ screen recording của từng người tham gia — cho thấy một phần câu trả lời nằm ở chính quá trình tương tác với AI. Một số người đặt tới 15 câu hỏi, hoặc dành hơn 30% thời gian chỉ để soạn query. Thời gian “tiết kiệm” nhờ AI viết code bị bù lại bởi thời gian giao tiếp với AI.
Điều đáng suy ngẫm hơn: nhóm không dùng AI phát triển kỹ năng tốt hơn phần lớn nhờ quá trình tự gặp lỗi và tự sửa lỗi. Khi phân loại hành vi tương tác AI thành sáu khuôn mẫu, ba khuôn mẫu giữ được kết quả học tập đều có một đặc điểm chung — chúng đòi hỏi nỗ lực nhận thức nhiều hơn và tư duy độc lập hơn. Ví dụ: chỉ hỏi AI về khái niệm, hoặc yêu cầu AI giải thích sau khi đã generate code.
Bức tranh lớn hơn: AI và năng suất qua lăng kính nghiên cứu
Kể từ khi ChatGPT, Copilot, Claude và các trợ lý hội thoại tiên tiến khác trở nên phổ biến vào cuối năm 2022, AI tools đã được sử dụng rộng rãi trong vô số lĩnh vực. Các nghiên cứu về cách con người tương tác với AI qua prompt (câu lệnh) đã mở ra cái nhìn chi tiết về ứng dụng thực tế của AI — từ phát triển phần mềm, giáo dục, thiết kế đến khoa học. Nhưng bức tranh nghiên cứu này tiết lộ điều gì khi nhìn tổng thể?
Productivity Gains (Mức tăng năng suất): Nhiều nghiên cứu ghi nhận năng suất cải thiện rõ rệt khi sử dụng AI assistants. Brynjolfsson và cộng sự phát hiện rằng trợ lý hội thoại dựa trên AI giúp nhân viên call center giải quyết trung bình nhiều hơn 15% số vấn đề. Dell’Acqua và cộng sự có kết quả tương tự: các consultant (nhà tư vấn) hoàn thành trung bình nhiều hơn 12.2% task khi có AI hỗ trợ so với khi không có. Dù hiệu ứng trên kỹ năng khác nhau giữa các nghiên cứu, một mô hình nhất quán xuất hiện trong công việc call center, tư vấn, trả lời câu hỏi pháp lý, và viết lách: người ít kinh nghiệm hơn và kỹ năng thấp hơn có xu hướng hưởng lợi nhiều nhất. Tuy nhiên, có một ngoại lệ đáng suy ngẫm: khi GPT-4 được cung cấp cho các chủ doanh nghiệp nhỏ tại Kenya, lời khuyên kinh doanh từ AI giúp những người có doanh thu cao cải thiện kết quả — nhưng lại làm tệ hơn kết quả của những người có doanh thu thấp hơn. AI không phải thuốc tiên cho tất cả.
Riêng trong lĩnh vực software engineering, Peng và cộng sự phát hiện rằng các software developer dùng Copilot hoàn thành task nhanh hơn 55.5% so với nhóm đối chứng, và lập trình viên mới vào nghề hưởng lợi nhiều hơn từ AI coding assistance. Các nghiên cứu tiếp theo tại các công ty phần mềm lớn cho thấy AI-generated code completions (gợi ý code tự động từ AI) giúp tăng năng suất 26.8% — đo bằng pull requests, commits và software product builds. Nghiên cứu này cũng xác nhận: coder ít kinh nghiệm hơn nhận được mức tăng năng suất lớn hơn. Nhưng đây chính là nghịch lý cần được đặt câu hỏi: trong khi junior developer hay developer ít kinh nghiệm nhận được productivity uplift (mức tăng năng suất) lớn nhất từ AI, thì chính những người này lẽ ra phải đang phát triển kỹ năng mới nhanh chóng tại nơi làm việc. Vậy tác động của những công cụ này lên quá trình skill formation của nhóm người này là gì? Liệu sự phát triển kỹ năng của novice worker (người mới) có bị ảnh hưởng nghiêm trọng khi họ vẫn đang trong quá trình học nghề? Câu hỏi thực sự ở đây là: năng suất tăng thêm đó đến miễn phí, hay có một cái giá phải trả?
Cognitive Offloading (Giảm tải nhận thức): Những lo ngại về tác động của AI assistance lên sự suy giảm kỹ năng đã được nhiều công trình gần đây nhấn mạnh. Ví dụ: các chuyên gia y tế được đào tạo với sự hỗ trợ của AI có thể không phát triển được kỹ năng quan sát trực quan nhạy bén để nhận diện một số bệnh lý. Trong các khảo sát với knowledge workers (người lao động tri thức), việc sử dụng AI thường xuyên có liên quan đến khả năng tư duy phản biện kém hơn và mức cognitive offloading (giảm tải nhận thức — giao phó hoạt động tư duy cho công cụ bên ngoài) tăng cao. Hơn nữa, knowledge workers báo cáo nỗ lực nhận thức thấp hơn và mức tự tin giảm khi sử dụng generative AI tools (công cụ AI tạo sinh). Tuy nhiên, cần lưu ý: các khảo sát này mang tính quan sát và có thể không nắm bắt được mối quan hệ nhân quả thực sự của việc sử dụng AI.
Skill Retention (Giữ lại kỹ năng): Một hướng nghiên cứu liền kề là khả năng con người giữ lại kiến thức và kỹ năng sau khi được AI hỗ trợ. Wu và cộng sự phát hiện rằng ngay cả khi generative AI cải thiện hiệu suất tức thời trên các task tạo nội dung (viết bài Facebook, viết đánh giá hiệu suất, soạn email chào mừng), mức cải thiện đó không duy trì được trong các task tiếp theo khi con người tự thực hiện một mình. Đối với các task data science (khoa học dữ liệu), Wiles và cộng sự mô tả tác động của AI lên consultant phi kỹ thuật như một “exoskeleton” (bộ khung xương ngoài) — năng lực kỹ thuật nâng cao nhờ AI không tồn tại khi người dùng không còn quyền truy cập AI nữa. Nghiên cứu của Shen và Tamkin đặt câu hỏi tiếp nối tự nhiên: liệu việc sử dụng AI tools có thể gây ra kết quả học tập tệ hơn trong quá trình tiếp thu kỹ năng tại nơi làm việc — đối với chính những chuyên gia kỹ thuật?
Overreliance (Phụ thuộc quá mức): Phần lớn các nghiên cứu kinh tế về năng suất được AI nâng cao đều ngầm giả định rằng AI là đáng tin cậy. Nhưng thực tế thì sao? Generative AI hoàn toàn có thể tạo ra nội dung sai hoặc hallucinated content (nội dung bịa đặt). Khi các model có khả năng sai sót nhưng vẫn được triển khai để hỗ trợ con người, những quyết định của con người đi theo quyết định sai của model được gọi là “overreliance” (phụ thuộc quá mức vào AI, kể cả khi AI sai). Dù đã có các phương pháp được đề xuất để giảm overreliance, chúng chủ yếu tập trung vào thông tin tại thời điểm ra quyết định như explanations (giải thích) hay debate (tranh luận) — chưa giải quyết được gốc rễ của vấn đề.
Giáo dục lập trình trong thời AI: chúng ta đang đo đúng thứ cần đo?
Đo lường skill formation phụ thuộc rất lớn vào ngữ cảnh. Trong khoa học máy tính, các khóa học nhập môn thường đánh giá qua câu hỏi trắc nghiệm, viết code, và đọc/giải thích code. Gần đây, phỏng vấn code và thảo luận trực tiếp về code của sinh viên cũng được chứng minh mang lại kết quả học tập tích cực.
Nhưng giả định ẩn ở đây là gì? Rằng cách sinh viên tương tác với AI trong lớp học phản ánh cách họ sẽ dùng AI ngoài thực tế. Các nghiên cứu quan sát cho thấy sinh viên dùng AI để viết code, sửa lỗi, và giải thích khái niệm thuật toán — và sinh viên có năng lực yếu hơn thường tìm đến AI nhiều hơn. Đáng chú ý, một số sinh viên tự nhận thức được rủi ro “dependence worry” — lo ngại phụ thuộc quá mức vào công cụ AI. Trong khi đó, sinh viên năm trên không phụ thuộc vào AI mà chỉ hỏi vài câu ở giai đoạn đầu.
Trong môi trường chuyên nghiệp, bức tranh cũng đa dạng không kém. Nghiên cứu về cách developer dùng AI trong coding puzzle và task phát triển phần mềm cho thấy nhiều kiểu tương tác phong phú: từ interactive debugging, thảo luận về code, đến đặt câu hỏi cụ thể. Một đầu phổ yêu cầu AI làm toàn bộ bài toán — cho ra code chất lượng thấp nhất. Đầu kia chỉ hỏi những câu tối thiểu — hiệu quả cao nhất. Các nghiên cứu khác cũng xác nhận AI hỗ trợ quá trình phát triển phần mềm thông qua truy cập tài liệu dễ dàng hơn và sinh code chính xác cho các API cụ thể.
Câu hỏi mà phần lớn nghiên cứu giáo dục này chưa trả lời: tương tác với AI trong bao lâu và theo cách nào thì bắt đầu ăn mòn quá trình học — thay vì hỗ trợ nó?
Khung lý thuyết: con đường tắt hay con đường khác?
Triết lý “learning by doing” — học qua thực hành — không phải ý tưởng mới. Kolb’s experiential learning cycle và Problem-Based Learning (PBL) đều xây dựng trên cùng một nền tảng: kết nối việc hoàn thành task thực tế với việc hình thành khái niệm và phát triển kỹ năng mới. Trong giáo dục kỹ thuật phần mềm, experiential learning được áp dụng cụ thể để mô phỏng giải quyết vấn đề trong môi trường chuyên nghiệp.
Nhưng đây là chỗ đáng dừng lại. Nếu “learning by doing” là nền tảng, thì AI thay đổi gì trong quá trình “doing”? Shen và Tamkin mô hình hóa AI assistance như một con đường học khác — không phải cùng đích đến bằng phương tiện khác, mà là một lộ trình có thể bỏ qua hoàn toàn giai đoạn học sâu. Giả thuyết của họ: dùng AI để generate code trong quá trình phát triển thực chất là chọn phím tắt đến đích hoàn thành task mà không đi qua giai đoạn học rõ ràng.
Giả định này có đứng vững trong mọi trường hợp? Chưa chắc. Nó mặc định rằng quá trình “gõ code, gặp lỗi, sửa lỗi” là con đường duy nhất hoặc tốt nhất để học. Nhưng nếu một developer yêu cầu AI generate code rồi dành thời gian đọc kỹ, đặt câu hỏi, và thử modify — đó có phải là shortcut không? Hay là một con đường học khác mà framework chưa tính đến?
Chính vì nhận ra sự đa dạng trong cách dùng AI, nghiên cứu không chỉ so sánh nhị phân “AI vs không AI” mà còn phân tích định tính các usage pattern — cách mỗi người dùng AI đại diện cho một learning path khác nhau đến cùng mục tiêu hoàn thành task.
Từ bối cảnh này, hai câu hỏi nghiên cứu được đặt ra:
RQ1: AI assistance có cải thiện năng suất hoàn thành task khi cần kỹ năng mới không?
RQ2: Việc sử dụng AI assistance ảnh hưởng thế nào đến quá trình phát triển những kỹ năng mới đó?
Năng suất và năng lực: hai đường thẳng song song?
Nếu phải chắt lọc, điều thay đổi trong cách chúng ta nghĩ về AI sau nghiên cứu này là: năng suất và năng lực không tự động đi cùng nhau. Mọi cuộc tranh luận về AI productivity đều ngầm giả định rằng làm nhanh hơn nghĩa là giỏi hơn — hoặc ít nhất, không kém đi. Dữ liệu từ Shen và Tamkin cho thấy giả định này cần được kiểm tra nghiêm túc.
Điều thú vị là framework của họ không đóng cửa với AI. Họ không nói “đừng dùng AI để học.” Họ nói: cách bạn dùng mới là thứ quyết định. Cognitive engagement — nỗ lực nhận thức chủ động trong quá trình tương tác — mới là biến số phân chia giữa học được và không học được. Và đây là điểm mà nghiên cứu mở ra nhiều hơn là khép lại.
Câu hỏi còn mở: nếu cognitive engagement là chìa khóa, liệu chúng ta có thể thiết kế AI tools theo cách buộc người dùng phải tư duy — thay vì cho phép họ ngồi yên và nhận kết quả? Hay bản chất của convenience là nó sẽ luôn chiến thắng effort, đặc biệt khi deadline đang đến gần?
Để trả lời, chúng ta cần nhìn kỹ hơn vào bên trong thí nghiệm — con số cụ thể, cách đo, và những gì xảy ra khi 52 lập trình viên ngồi trước màn hình với (hoặc không có) một AI assistant sẵn sàng viết code thay họ.
Thí nghiệm: Đo lường cái giá của sự tiện lợi
Hầu hết chúng ta đánh giá một thí nghiệm qua kết quả cuối cùng — con số p-value, kích thước hiệu ứng, biểu đồ đẹp. Nhưng những con số đó chỉ đáng tin khi phương pháp đứng vững. Và phương pháp chỉ đứng vững khi người thiết kế đã va chạm đủ nhiều với thực tế — khi chính những thất bại trong pilot study buộc họ phải sửa lại mọi giả định ban đầu.
Nghiên cứu của Shen và Tamkin không bắt đầu bằng một thí nghiệm hoàn hảo. Nó bắt đầu bằng bốn lần thử — và bốn lần phát hiện ra thứ mà thiết kế trên giấy không thể dự đoán: con người gian lận, câu hỏi tự hé đáp án cho nhau, và Python syntax trở thành rào cản thay vì đối tượng nghiên cứu. Câu hỏi đặt ra: khi chúng ta muốn đo lường “cái giá” của sự tiện lợi AI, bản thân việc đo lường đã phức tạp đến mức nào?
Chọn đúng kỹ năng để đo
Trước khi đo tác động của AI lên việc học, cần chọn được thứ gì đó đủ mới để mọi người đều phải học — nhưng đủ thực tế để phản ánh tình huống công việc hàng ngày. Nhóm nghiên cứu đã thử nghiệm nhiều kỹ năng khác nhau mà lập trình viên junior có thể gặp trong công việc: từ phân tích dữ liệu đến vẽ biểu đồ. Cuối cùng, họ chọn thư viện Trio — một thư viện Python cho lập trình bất đồng bộ (asynchronous programming), xử lý đồng thời và I/O.
Tại sao Trio mà không phải asyncio — thư viện bất đồng bộ phổ biến nhất trong Python? Chính vì Trio ít được biết đến hơn (nếu đo bằng số lượng câu hỏi trên StackOverflow). Điều này quan trọng: nếu dùng asyncio, nhiều lập trình viên đã có kinh nghiệm sẵn, và thí nghiệm sẽ đo kiến thức cũ thay vì đo quá trình hình thành kỹ năng mới. Trio cũng yêu cầu nắm các khái niệm vượt ra ngoài Python thuần túy — như structured concurrency (mô hình xử lý đồng thời có cấu trúc) — nhưng đồng thời được thiết kế để dễ sử dụng. Sự kết hợp giữa “mới” và “dễ tiếp cận” làm cho nó đặc biệt phù hợp cho một thí nghiệm về học tập.
Nhóm nghiên cứu thiết kế năm bài tập sử dụng Trio, mô phỏng quá trình tự học một công cụ mới qua tutorial ngắn — giống như khi kỹ sư mới vào công ty phải đọc tài liệu onboarding và làm bài tập nhỏ để làm quen với thư viện nội bộ. Mỗi bài tập bao gồm mô tả vấn đề, code khung, và giải thích ngắn gọn về các khái niệm Trio cần thiết.
Sau nhiều lần thử nghiệm pilot, chỉ hai bài tập đầu tiên được giữ lại cho nghiên cứu chính — mỗi bài mất khoảng 10 đến 20 phút khi thử nghiệm ban đầu. Bài thứ nhất yêu cầu viết một timer in ra từng giây trôi qua trong khi các hàm khác đang chạy — qua đó giới thiệu khái niệm cốt lõi về nurseries (cơ chế quản lý task đồng thời), khởi tạo task, và chạy hàm song song trong Trio. Bài thứ hai liên quan đến truy xuất bản ghi với xử lý lỗi bản ghi bị thiếu, giới thiệu error handling và memory channels. Hai bài tập này độc lập nhau — người tham gia nhận đủ hướng dẫn và ví dụ để hoàn thành từng bài mà không cần bài kia.
Thí nghiệm chạy trên nền tảng phỏng vấn trực tuyến với giao diện chat AI tích hợp. Nhóm được dùng AI (treatment) được khuyến khích sử dụng trợ lý AI để hỗ trợ hoàn thành bài tập. Trợ lý này sử dụng GPT-4o làm mô hình nền, được prompt để đóng vai trợ lý lập trình thông minh, có quyền truy cập code hiện tại của người dùng, và có khả năng tạo ra code hoàn chỉnh, chính xác cho cả hai bài tập khi được yêu cầu.
Giả định ẩn ở đây đáng chú ý: trợ lý AI trong thí nghiệm này có thể giải quyết hoàn toàn cả hai bài tập. Đây không phải AI yếu hay AI bị giới hạn — nó đủ mạnh để thay thế hoàn toàn quá trình suy nghĩ của người dùng. Sự lựa chọn này có chủ đích: nó tạo ra kịch bản worst-case cho việc học, nơi sự cám dỗ “giao phó” là lớn nhất.
Đánh giá kỹ năng: Không chỉ viết code
Nếu chỉ đo khả năng viết code, thí nghiệm sẽ bỏ lỡ phần quan trọng nhất. Dựa trên một meta-analysis trước đó về đánh giá trong giáo dục khoa học máy tính, nhóm nghiên cứu xác định bốn loại câu hỏi đo lường kỹ năng lập trình — và mỗi loại có mức độ liên quan khác nhau đến năng lực giám sát code AI:
Debugging — khả năng nhận diện và chẩn đoán lỗi trong code. Đây là kỹ năng thiết yếu để phát hiện khi code do AI viết sai và hiểu tại sao nó sai.
Code Reading — khả năng đọc hiểu code đang làm gì. Kỹ năng này cho phép con người kiểm chứng code AI viết trước khi triển khai.
Code Writing — khả năng viết code hoặc chọn cách viết đúng. Ở mức thấp (nhớ cú pháp hàm), kỹ năng này sẽ ngày càng ít quan trọng khi AI code tools phát triển; ở mức cao (thiết kế hệ thống), nó vẫn thiết yếu.
Conceptual — khả năng hiểu nguyên lý cốt lõi đằng sau công cụ và thư viện. Hiểu khái niệm là nền tảng để đánh giá liệu code AI có sử dụng đúng design patterns theo cách thư viện được thiết kế để dùng hay không.
Nhưng đây là chỗ đáng dừng lại. Nhóm nghiên cứu loại bỏ câu hỏi code writing khỏi bài đánh giá. Lý do: để giảm tác động của lỗi cú pháp — thứ dễ dàng sửa bằng một câu hỏi AI hoặc tìm kiếm web. Quyết định này phản ánh một quan điểm rõ ràng: trong thời đại AI, nhớ cú pháp không còn là thước đo năng lực có ý nghĩa. Điều quan trọng là bạn có hiểu code đang làm gì, có phát hiện được lỗi, và có nắm được nguyên lý hoạt động hay không.
Hai bài tập bao phủ 7 khái niệm cốt lõi của Trio. Bài đánh giá gồm các câu hỏi debugging, code reading, và conceptual cho 7 khái niệm này. Nhóm nghiên cứu thử nghiệm 5 phiên bản quiz qua các vòng user testing và pilot studies, áp dụng item response theory — đảm bảo mỗi câu hỏi tương quan đủ mạnh với điểm tổng, có mức điểm trung bình phù hợp, và quan trọng nhất: không tồn tại local item dependence (khi câu trả lời một câu hỏi cho phép suy ra đáp án câu khác bằng cách nhìn sang các câu hỏi khác). Phiên bản cuối cùng gồm 14 câu hỏi, tổng 27 điểm. Rubric chấm điểm được nộp trong bản pre-registration trước khi chạy thí nghiệm — một bước quan trọng để đảm bảo nhóm nghiên cứu không thể điều chỉnh thang đo sau khi đã biết kết quả.
Thiết kế thí nghiệm: Ba giai đoạn, một giả định cần kiểm tra
Thiết kế between-subjects randomized experiment (thí nghiệm ngẫu nhiên giữa các nhóm) nghe đơn giản trên giấy: chia người tham gia ngẫu nhiên thành hai nhóm, một nhóm có AI, một nhóm không. Nhưng giả định ẩn đằng sau thiết kế này là gì? Rằng ta có thể cô lập tác động của AI bằng cách kiểm soát mọi biến số khác. Thực tế phức tạp hơn nhiều.
Quy trình thí nghiệm gồm ba giai đoạn, mỗi giai đoạn đều chứa đựng những lựa chọn thiết kế đáng suy ngẫm.
Giai đoạn khởi động — tất cả người tham gia hoàn thành một bài Python cơ bản (thêm viền quanh danh sách chuỗi ký tự, trung bình 4 phút), không liên quan gì đến bất đồng bộ, và không ai được dùng AI. Mục đích không chỉ để “làm quen giao diện” — mà để đo baseline Python fluency. Nếu không có bước này, làm sao phân biệt “AI giúp học Trio nhanh hơn” với “AI bù đắp cho kỹ năng Python yếu”?
Giai đoạn Trio — 35 phút để hoàn thành hai bài tập. Nhóm treatment có trợ lý AI qua giao diện chat. Mọi người đều được yêu cầu “hoàn thành càng nhanh càng tốt.” Nhưng đây là chỗ đáng dừng lại: chỉ dẫn “nhanh nhất có thể” tạo ra áp lực thiên về tốc độ hơn là hiểu sâu — và chính áp lực này có thể đẩy nhóm AI về phía delegation thay vì engagement. Liệu kết quả có khác nếu chỉ dẫn là “hãy đảm bảo bạn hiểu code trước khi submit”?
Giai đoạn đánh giá — quiz + khảo sát. Quan trọng: quiz diễn ra ngay sau task, không có khoảng nghỉ để ôn lại. Điều này đo kiến thức hình thành trong quá trình làm, không phải khả năng ghi nhớ dài hạn.
52 người hoàn thành toàn bộ — 26 mỗi nhóm. Tiêu chí tuyển chọn đáng chú ý: hơn một năm kinh nghiệm Python, code Python ít nhất hàng tuần, đã thử AI coding assistance, và chưa bao giờ dùng Trio. Nhóm nghiên cứu ghi lại mọi keystroke khi viết code, toàn bộ transcript chat với AI, và phản hồi khảo sát trước-sau. Quy trình kéo dài tối đa 1 giờ 15 phút (trung bình 58,5 phút), mỗi người nhận 150 USD — một mức đủ cao để đảm bảo nỗ lực nghiêm túc, nhưng liệu có tạo ra áp lực “phải hoàn thành” thay vì “phải hiểu”?
Thiết kế between-subjects (giữa các nhóm) ở đây có một hệ quả quan trọng mà chúng ta nên nhận ra: mỗi người chỉ trải nghiệm một điều kiện. Không ai vừa làm có AI vừa làm không AI. Điều này loại bỏ hiệu ứng học tập chéo (carryover effects) nhưng đồng thời đòi hỏi hai nhóm phải thực sự tương đương nhau từ đầu. Bảng cân bằng cho thấy hai nhóm gần như đồng đều về số năm kinh nghiệm lập trình, tần suất sử dụng Python, điểm quiz bất đồng bộ trước thí nghiệm, và kinh nghiệm với asyncio — với chênh lệch không đáng kể ở mỗi chỉ số.
Bốn lần thất bại dạy được nhiều hơn thành công
Nếu phần Methods cho chúng ta thấy thí nghiệm nên chạy thế nào, thì phần Pilot Studies cho thấy thực tế đã xảy ra những gì. Và thực tế thì hỗn loạn hơn nhiều.
Non-compliance — khi người tham gia “phá luật”
Bốn pilot study chạy trước nghiên cứu chính tiết lộ một vấn đề mà nhiều thí nghiệm kiểm soát né tránh: con người không tuân thủ luật chơi. Trong hai pilot đầu tiên trên nền tảng crowdworking P1, 35% người tham gia trong nhóm không được dùng AI vẫn sử dụng AI — copy hướng dẫn ra ngoài, paste kết quả vào. Nhóm nghiên cứu phát hiện hành vi này qua bản ghi keystrokes: khi người dùng copy toàn bộ đề bài hoặc paste một đoạn code hoàn chỉnh vào editor, dấu vết là rõ ràng.
Họ thử siết chặt hướng dẫn, cảnh báo rõ hơn. Kết quả? Con số giảm từ 35% xuống... 25%. Vẫn không thể chấp nhận được, và nền tảng P1 không hỗ trợ ghi màn hình để kiểm chứng. Nhóm nghiên cứu buộc phải chuyển sang nền tảng crowdworking P2, nơi có thể ghi lại toàn bộ screen recording. Qua hai pilot tiếp theo (mỗi pilot 20 người), screen recording xác nhận: nhóm kiểm soát không dùng AI, và không ai dùng AI trong lúc làm quiz.
Điều này gợi ý một vấn đề sâu hơn: trong thời đại AI có mặt khắp nơi, thiết kế thí nghiệm “không AI” ngày càng khó thực thi. Bản thân sự tồn tại của công cụ AI tạo ra áp lực mạnh mẽ để người tham gia sử dụng nó — nhất là khi họ được yêu cầu hoàn thành task “càng nhanh càng tốt.”
Local Item Dependence — khi câu hỏi tự trả lời lẫn nhau
Pilot Study C phát hiện một lỗ hổng khác trong thiết kế đánh giá: local item dependence. Qua screen recording, nhóm nghiên cứu quan sát thấy người tham gia cuộn lên cuộn xuống giữa các câu hỏi, so sánh code snippets từ câu này để suy ra đáp án câu khác. Quiz vô tình trở thành bộ gợi ý cho chính nó.
Giải pháp: chia quiz thành nhiều trang riêng biệt, đảm bảo các câu hỏi trên cùng một trang không cung cấp manh mối cho nhau. Screen recording từ Pilot D xác nhận biện pháp này giảm local item dependence hiệu quả. Đồng thời, nhóm nghiên cứu giảm số bài tập từ năm xuống hai. Thay đổi này không chỉ vì lý do thời gian — nó loại bỏ một biến nhiễu: trong điều kiện AI, người tham gia có thể hoàn thành nhiều bài tập hơn trong cùng thời gian cho phép, nghĩa là họ được tiếp xúc với nhiều khái niệm hơn đơn giản vì họ làm nhanh hơn. Giảm xuống hai bài tập cô lập việc học từ chính hai bài đó, tách biệt khỏi hiệu ứng “hoàn thành nhiều hơn.”
Python syntax — rào cản sai mục tiêu
Pilot Study D (n=20) mang đến tín hiệu đầu tiên về hiệu ứng chính: nhóm AI hoàn thành nhanh hơn (Cohen’s d=1.11, p=0.03) nhưng điểm quiz thấp hơn đáng kể (Cohen’s d=1.7, p=0.003). Nhưng khi xem screen recording kỹ hơn, một vấn đề bất ngờ xuất hiện: chỉ 60% nhóm kiểm soát hoàn thành cả hai bài tập trong 35 phút, so với 90% nhóm AI. Và nguyên nhân không phải vì Trio quá khó — mà vì nhiều người vật lộn với cú pháp Python cơ bản như try/except blocks và string formatting. Những chậm trễ này không liên quan gì đến thư viện đang được nghiên cứu.
Đây là lúc bằng chứng buộc thiết kế phải thay đổi. Vì mục tiêu là đo khả năng học Trio chứ không phải đo khả năng nhớ cú pháp Python, nhóm nghiên cứu thêm gợi ý cú pháp về string formatting và try/except cho nghiên cứu chính. Quyết định này phản ánh nguyên tắc thiết kế thí nghiệm: loại bỏ rào cản không liên quan đến biến đang đo (germane vs. extraneous cognitive load).
Nhóm nghiên cứu cũng xử lý kết quả pilot một cách cẩn trọng: thay vì lấy effect size quan sát được (d=1.7 cho quiz, d=1.11 cho thời gian), họ giả định effect size bảo thủ hơn (d=0.85 — bằng nửa hiệu ứng quan sát) cho power analysis và pre-registration, vì hiệu ứng từ pilot thường bị thổi phồng do cỡ mẫu nhỏ.
Nghiên cứu chính: 52 người, một câu hỏi rõ ràng
Để tuyển 50 người tham gia, nhóm gửi lời mời đến 58 crowd workers. Người tham gia được cân bằng theo nhiều thuộc tính: số năm kinh nghiệm lập trình, số năm kinh nghiệm Python, kinh nghiệm với thư viện asyncio, tần suất dùng Python trong năm qua, và điểm kiểm tra khái niệm bất đồng bộ (5 câu trắc nghiệm). Thông tin nhân khẩu học được thu thập sau khi hoàn thành task để tránh đe dọa khuôn mẫu (stereotype threat). Đa số người tham gia có bằng cử nhân, từ 25 đến 35 tuổi, làm việc như lập trình viên freelance hoặc chuyên nghiệp.
53 người hoàn thành cả ba phần. Theo tiêu chí loại trừ đã pre-register, 1 người bị loại sau khi bỏ trống 4 câu hỏi quiz vì không nhận ra quiz có nhiều phần và hết giờ. Mẫu cuối cùng: 52 người, 26 mỗi nhóm.
Nhưng bằng chứng nào cho thấy kết quả đáng tin?
Nghiên cứu chính (n=52): Khi con số bắt đầu nói
Giả thuyết phổ biến nhất về AI và năng suất lập trình là: AI giúp nhanh hơn. Nhưng 52 người tham gia thí nghiệm này kể một câu chuyện khác — hoặc chính xác hơn, câu chuyện phức tạp hơn nhiều.
Kết quả lớn nhất nằm ở kỹ năng, không phải tốc độ. Điểm đánh giá kỹ năng giảm 17% ở nhóm dùng AI — tương đương khoảng cách 4,15 điểm trên thang 27, hay hai bậc điểm (Cohen’s d=0.738, p=0.01). Khi kiểm soát thời gian hoàn thành bài khởi động như covariate (biến đồng biến), hiệu ứng vẫn có ý nghĩa thống kê (Cohen’s d=0.725, p=0.016). Nhưng chờ đã — còn thời gian hoàn thành thì sao? Nhóm AI có nhanh hơn một chút, nhưng sự khác biệt không đạt ý nghĩa thống kê. AI assistant có thể generate toàn bộ giải pháp khi được yêu cầu — vậy tại sao không nhanh hơn rõ rệt?
Một phần câu trả lời nằm ở tính không đồng nhất trong cách dùng AI. Khoảng 20% nhóm treatment giao phó hoàn toàn cho AI viết code — nhóm này nhanh hơn control rõ rệt (trung bình 19,5 phút so với 23 phút). Nhưng phần còn lại — những người hỏi 15 câu, dành 10 phút soạn query, yêu cầu giải thích — kéo trung bình thời gian nhóm AI lên. Nói cách khác: AI không tạo ra speedup đồng đều. Nó tạo ra một phổ từ “nhanh vọt” đến “chậm hơn cả không dùng AI.” Con số trung bình san phẳng câu chuyện thật.
Giả định cần kiểm tra: liệu hiệu ứng suy giảm kỹ năng chỉ xảy ra ở lập trình viên ít kinh nghiệm? Dữ liệu cho thấy không — ở mọi mức độ kinh nghiệm, nhóm control đều đạt điểm cao hơn nhóm treatment. Điều này quan trọng vì nó xác nhận Trio thực sự đặt ra kỹ năng mới cho tất cả, không chỉ newbie.
Nhưng phát hiện đáng suy ngẫm nhất nằm ở phân tích thăm dò (exploratory — không pre-register trước). Khi tách điểm quiz theo loại câu hỏi, khoảng cách lớn nhất giữa hai nhóm xuất hiện ở câu hỏi debugging — và nhỏ nhất ở code reading. Tại sao? Cả hai nhóm đều đọc code trong quá trình làm bài. Nhưng nhóm control gặp nhiều lỗi hơn — và chính quá trình đối mặt với lỗi đã rèn luyện khả năng phát hiện lỗi mà nhóm AI không có cơ hội trải nghiệm.
Và đây là chi tiết mà dữ liệu tự báo cáo bổ sung: nhóm control tự đánh giá mức độ học tập cao hơn (trên thang 7 điểm). Cả hai nhóm đều thấy bài tập thú vị, nhưng nhóm AI cảm thấy task dễ hơn — trong khi cả hai nhóm thấy quiz khó ở mức tương đương.
Dữ liệu này đặt chúng ta trước một nghịch lý quen mà lạ. AI không tăng tốc đáng kể — nhưng làm giảm 17% kỹ năng đo lường được. Và khoảng cách lớn nhất nằm ở debugging — chính kỹ năng mà lập trình viên cần nhất để giám sát code do AI tạo ra. Nhóm không dùng AI gặp nhiều lỗi hơn trong quá trình làm bài — và chính quá trình đối mặt với lỗi đã rèn luyện khả năng phát hiện lỗi.
Có một chi tiết đáng chú ý: nhóm AI cảm thấy bài tập dễ hơn, nhưng cả hai nhóm đều thấy bài quiz khó như nhau. Nghĩa là cảm giác “dễ” khi làm bài không chuyển thành năng lực thực sự khi bị kiểm tra. Sự dễ dàng là ảo giác.
Giữa con số và câu chuyện
Nếu phải chắt lọc, phát hiện cốt lõi ở đây không chỉ là “AI giảm 17% kỹ năng.” Đó là một phát hiện quan trọng, nhưng nó chỉ là bề mặt. Phát hiện sâu hơn nằm ở cách con số đó được đo — và những gì nó không thể đo.
Thí nghiệm này chứng minh rằng ngay cả trong một thiết kế ngẫu nhiên có đối chứng (RCT) — tiêu chuẩn vàng của nghiên cứu nhân quả — con đường từ thiết kế đến kết quả đáng tin cậy đầy rẫy những quyết định phương pháp luận ảnh hưởng sâu sắc đến kết quả. Chọn Trio thay vì asyncio, loại bỏ code writing khỏi đánh giá, thêm gợi ý cú pháp, chia quiz thành nhiều trang — mỗi quyết định đều định hình điều gì được đo và điều gì bị bỏ qua.
Nhưng có những câu hỏi mà dữ liệu định lượng không thể trả lời. Tại sao một số người dùng AI vẫn học được tốt trong khi người khác thì không? Sự khác biệt nằm ở đâu — ở chiến lược sử dụng, ở mindset, hay ở mức độ nỗ lực nhận thức? Con số 17% là trung bình — nhưng bên trong con số trung bình đó, có những người dùng AI mà vẫn giữ được kỹ năng, và có những người không dùng AI mà điểm vẫn thấp. Câu chuyện cá nhân nào ẩn sau những con số? Để trả lời, chúng ta cần nhìn sâu hơn vào cách mỗi người tương tác với AI — và đó là nơi phân tích định tính bắt đầu hé lộ những khuôn mẫu mà thống kê không thể nắm bắt.
Sáu khuôn mặt của người dùng AI: Khi con số trung bình che khuất câu chuyện thật
Con số 17% nghe gọn gàng. Nhóm dùng AI giảm 17% điểm kỹ năng so với nhóm tự làm — một kết luận dễ nhớ, dễ trích dẫn. Nhưng con số trung bình có một đặc tính nguy hiểm: nó san phẳng mọi sự khác biệt bên trong. Khi Shen và Tamkin ngồi xem lại toàn bộ screen recording của 51 người tham gia, họ phát hiện điều mà thống kê tổng thể không thể cho thấy — bên trong nhóm dùng AI, có những người đạt 86% và có những người chỉ đạt 24%. Cùng một công cụ, cùng một bài tập, nhưng cách tương tác khác nhau dẫn đến kết quả khác nhau hoàn toàn.
Câu hỏi không còn là “AI có hại cho việc học không?” mà trở thành: AI hại cho việc học khi nào, và với ai?
Từ thống kê sang hành vi: sáu khuôn mẫu hiện ra
Nhưng con số tổng thể bỏ lỡ gì? Để trả lời, Shen và Tamkin làm điều mà ít nghiên cứu nào chịu làm: ngồi xem lại toàn bộ screen recording của 51 người tham gia — từng keystroke, từng lần chạy code, từng câu hỏi gửi cho AI, từng khoảng lặng khi suy nghĩ. Phân tích định tính (qualitative analysis) này tốn công, nhưng nó hé lộ thứ mà thống kê tổng thể không bao giờ cho thấy: cùng một công cụ, mỗi người dùng theo một cách hoàn toàn khác.
Bốn trục phân tích nổi lên từ dữ liệu — và mỗi trục đều thách thức một giả định:
Thời gian tương tác AI: Giả định “dùng AI thì nhanh hơn” bị lung lay ngay tại đây. Một số người dành tới 11 phút chỉ để soạn câu hỏi — trong bài tập 35 phút. Thời gian “tiết kiệm” nhờ AI viết code bị bù lại bởi thời gian giao tiếp với AI.
Loại câu hỏi: Không phải ai dùng AI cũng dùng giống nhau. Có người chỉ hỏi khái niệm, có người chỉ yêu cầu generate code, có người kết hợp cả hai lẫn debugging (gỡ lỗi). Và mỗi cách dùng dẫn đến kết quả học tập khác nhau — những ai nhờ AI debug nhiều nhất lại mất thời gian nhất và học ít nhất.
Gặp lỗi: Nhóm không dùng AI gặp nhiều lỗi hơn đáng kể — cả lỗi cú pháp lẫn lỗi đặc thù Trio. Nhưng thay vì là bất lợi, lỗi lại trở thành lợi thế: chính quá trình tự đối mặt và giải quyết lỗi đã thúc đẩy skill formation (hình thành kỹ năng).
Thời gian viết code thực: AI không chỉ thay đổi tốc độ làm bài — nó thay đổi bản chất hoạt động. Thời gian viết code bị co lại, thay bằng thời gian đọc và đánh giá output AI. Hai hoạt động này khác nhau về bản chất nhận thức.
Từ bốn trục này, nhóm nghiên cứu xây dựng một phân loại sáu khuôn mẫu tương tác — dựa trên loại câu hỏi, số lượng, tần suất trên mỗi task, và thời gian viết code thực. Sáu khuôn mẫu chia thành hai cực rõ ràng: ba khuôn mẫu điểm thấp (dưới 40% quiz) và ba khuôn mẫu điểm cao (trên 65% quiz). Khoảng cách giữa hai cực là vực thẳm — dù mỗi cụm có cỡ mẫu nhỏ, điều mà chúng tiết lộ về cách dùng AI đáng giá hơn bất kỳ p-value nào.
Ba khuôn mẫu điểm thấp — khi AI trở thành phím tắt nhận thức
Các khuôn mẫu điểm thấp có điểm chung là phụ thuộc nặng vào AI — hoặc để generate code, hoặc để debug. Điểm quiz trung bình của các nhóm này dưới 40%. Người tham gia thuộc các khuôn mẫu này thể hiện ít tư duy độc lập hơn và nhiều cognitive offloading (giảm tải nhận thức — giao phó tư duy cho AI) hơn.
AI Delegation (Giao phó hoàn toàn cho AI viết code, n=4): Nhóm này phụ thuộc hoàn toàn vào AI để viết code và hoàn thành task. Họ hoàn thành nhanh nhất và gần như không gặp lỗi nào trong quá trình làm bài.
Progressive AI Reliance (Bắt đầu tự làm rồi dần giao hết cho AI, n=4): Nhóm này khởi đầu bằng 1-2 câu hỏi, rồi dần giao toàn bộ việc viết code cho AI. Họ đạt điểm quiz thấp chủ yếu vì không nắm được bất kỳ khái niệm nào trong task thứ hai.
Iterative AI Debugging (Lặp đi lặp lại nhờ AI debug mà không tự hiểu, n=4): Nhóm này dựa vào AI để debug hoặc xác minh code. Họ đặt nhiều câu hỏi hơn cho AI, nhưng nhờ AI giải quyết vấn đề thay vì tự mình tìm hiểu. Kết quả: điểm quiz thấp và tốc độ hoàn thành task cũng chậm hơn tương đối.
Ba khuôn mẫu điểm cao — khi AI khuếch đại thay vì thay thế tư duy
Các khuôn mẫu điểm cao là những cụm hành vi có điểm quiz trung bình từ 65% trở lên. Người tham gia trong các cụm này dùng AI để generate code, hỏi câu hỏi khái niệm, hoặc kết hợp cả hai.
Generation-Then-Comprehension (Generate code trước, hỏi hiểu sau, n=2): Nhóm này để AI tạo code trước, rồi copy hoặc paste vào bài làm. Sau khi có code, họ quay lại hỏi AI những câu hỏi tiếp nối để hiểu sâu hơn. Họ không nhanh đặc biệt, nhưng thể hiện mức độ hiểu biết cao trong bài quiz. Điểm quan trọng: cách tiếp cận này nhìn bề ngoài gần giống hệt nhóm AI Delegation — nhưng có thêm một bước: dùng AI để kiểm tra chính sự hiểu biết của mình.
Hybrid Code-Explanation (Hỏi code kèm giải thích cùng lúc, n=3): Nhóm này soạn những câu hỏi kết hợp — vừa yêu cầu generate code, vừa yêu cầu giải thích code được tạo ra. Việc đọc và hiểu phần giải thích tốn thêm thời gian.
Conceptual Inquiry (Chỉ hỏi conceptual questions, tự viết code, n=7): Nhóm này chỉ đặt câu hỏi khái niệm và dựa vào sự hiểu biết được cải thiện để tự hoàn thành task. Dù gặp nhiều lỗi, họ cũng tự mình giải quyết được các lỗi đó. Trung bình, đây là khuôn mẫu nhanh nhất trong nhóm điểm cao và nhanh thứ hai tổng thể, chỉ sau AI Delegation.
Đây là chỗ đáng dừng lại. Hãy nhìn vào hai khuôn mẫu: AI Delegation và Generation-Then-Comprehension. Ở bề mặt, hành vi gần như giống nhau — cả hai đều bắt đầu bằng việc nhờ AI generate code. Nhưng nhóm thứ hai làm thêm một bước: hỏi lại để hiểu code đó hoạt động ra sao. Chỉ một bước nhỏ đó — chuyển từ “nhận” sang “kiểm tra” — đã tạo ra khoảng cách hàng chục phần trăm trong điểm đánh giá kỹ năng.
Điều này gợi ý rằng ranh giới giữa “dùng AI hiệu quả” và “dùng AI có hại” không nằm ở lượng code mà AI generate, mà nằm ở mức độ cognitive engagement (nỗ lực nhận thức) của người dùng. Đây không phải chỉ là vấn đề kỷ luật cá nhân — nó phản ánh một cấu trúc sâu hơn về cách con người học.
Thời gian tương tác AI: Tốc độ không đến miễn phí
Trái với các nghiên cứu trước đó — vốn ghi nhận AI giúp tăng tốc đáng kể khi lập trình — kết quả nghiên cứu này không cho thấy cải thiện năng suất có ý nghĩa thống kê nếu chỉ nhìn vào tổng thời gian hoàn thành giữa nhóm treatment và control. Lý do nằm ở thời gian tương tác với AI. Một số người trong nhóm dùng AI dành lượng thời gian đáng kể (lên đến 11 phút) chỉ để tương tác với trợ lý AI — gõ câu hỏi, suy nghĩ về cách đặt câu hỏi. Nhóm nghiên cứu đo thời gian này bằng cách ghi nhận khoảng cách giữa lúc người dùng bắt đầu gõ câu hỏi (ghi nhận là sự kiện AI Interaction) và lúc AI trả lời (ghi nhận là sự kiện AI Query).
Vì người tham gia có thể hỏi AI bao nhiêu câu tùy thích trong thời gian cho phép, một số người đặt hơn năm câu hỏi và dành đến sáu phút để soạn một câu hỏi duy nhất — trong bài tập chỉ kéo dài 35 phút. Với median thời gian hoàn thành chỉ 19 phút ở nhóm AI, sáu phút cho một câu hỏi chiếm tỷ trọng rất lớn. Dù hiệu ứng này có thể phần nào do task ngắn, Becker et al. cũng ghi nhận hiện tượng chậm lại tương tự ở các lập trình viên giỏi trong task dài hơn — khi người chờ AI viết code dễ bị phân tâm.
Nhưng nhìn từ góc độ skill formation (quá trình hình thành kỹ năng mới), thời gian soạn câu hỏi có thể không phải lãng phí. Screen recording cho thấy người tham gia suy nghĩ kỹ trước khi hỏi AI — đọc lại hướng dẫn, viết lại câu hỏi, cân nhắc cách diễn đạt. Một số người mất vài phút chỉ để soạn một câu hỏi duy nhất. Đây là một nghịch lý đáng chú ý: chi phí thời gian này rõ ràng hơn ở chat-based assistants (trợ lý dạng chat) so với agentic coding assistants (công cụ AI tự viết code), nhưng mức mất mát kiến thức ở agentic hoặc autocomplete settings — nơi người dùng không cần soạn câu hỏi — nhiều khả năng còn lớn hơn. Nói cách khác: nếu tương tác ngắn hơn dẫn đến hoàn thành nhanh hơn, thì tác động tiêu cực lên skill formation gần như chắc chắn cũng lớn hơn. Khi phân tích từng câu hỏi riêng lẻ, không phải câu hỏi nào cũng đòi hỏi nhiều suy nghĩ và thời gian — và chính sự khác biệt này mở ra một lớp phân tích tiếp theo.
Năm loại câu hỏi — và điều chúng tiết lộ
Nếu cách dùng AI quyết định kết quả học tập, thì câu hỏi tiếp theo là: mọi người hỏi AI điều gì? Nhóm nghiên cứu phân loại toàn bộ input gửi cho AI thành 5 loại: explanation (giải thích), generation (tạo code), debugging (gỡ lỗi), capabilities questions (hỏi về khả năng của AI), và appreciation (cảm ơn).
Con số thú vị nhất không phải loại câu hỏi nào phổ biến nhất — mà là loại nào vắng mặt ở nhóm điểm thấp. Câu hỏi giải thích chiếm đa số (q=79), và 21 trên 25 người đặt ít nhất một câu hỏi giải thích — phản ánh mức tham gia nhận thức cao. Loại phổ biến thứ hai là yêu cầu generate code (q=51), nhưng chỉ hai phần ba nhóm treatment dùng AI để tạo code. Bốn người chỉ generate code mà không hỏi bất kỳ câu giải thích nào. Và đây là dữ liệu đáng dừng lại: 3 trong 8 người có điểm quiz thấp nhất thuộc nhóm “chỉ generate, không hỏi.” Điều này gợi ý rằng nếu toàn bộ nhóm AI chỉ dùng AI để tạo code — kịch bản ngày càng phổ biến với agentic tools — khoảng cách skill formation so với nhóm control sẽ còn lớn hơn nhiều.
Một loại câu hỏi khác đáng chú ý vì tương quan ngược: debugging (q=9). Tỷ lệ câu hỏi debugging cao tương quan với thời gian hoàn thành chậm hơn và điểm quiz thấp hơn. Tại sao? Vì những người này không debug để hiểu — họ paste thông báo lỗi cho AI rồi chờ AI sửa. Đây là cognitive offloading (giảm tải nhận thức) ở dạng tinh vi nhất: trông có vẻ đang làm việc với lỗi, nhưng thực chất đang chuyển toàn bộ quá trình tư duy cho AI.
Và một chi tiết mà dữ liệu tình cờ ghi lại: dù tất cả đều đã dùng AI assistant trước đây, một số người vẫn hỏi “AI có nhìn thấy code của mình không?” Một số khác bày tỏ lời cảm ơn sau khi hoàn thành task — dù điều này tốn thêm thời gian quý giá. Sự lịch sự trong tương tác người-AI xuất hiện ngay cả dưới áp lực thời gian — một nhắc nhở rằng con người đối xử với AI assistant không hoàn toàn như với một công cụ thuần túy.
Paste hay gõ tay — có thực sự quan trọng?
Nhiều người tin rằng gõ lại code bằng tay giúp học tốt hơn copy-paste — giống như sinh viên chép bài tay để nhớ lâu. Giả định này nghe hợp lý, nhưng dữ liệu kể một câu chuyện bất ngờ.
Cách người tham gia “nhận” code từ AI phân hóa thành bốn nhóm: paste trực tiếp (n=9), gõ lại thủ công (n=9), kết hợp cả hai (n=4), và một nhóm nhỏ (n=4) gần như tự viết code — chỉ hỏi AI câu hỏi làm rõ. Về tốc độ, nhóm paste trực tiếp nhanh nhất, trong khi nhóm gõ tay và kết hợp hoàn thành gần tương đương nhóm không dùng AI. Chỉ một phần nhỏ tương tác với AI thực sự mang lại cải thiện năng suất.
Nhưng đây là phát hiện đáng ngạc nhiên: về điểm quiz — thước đo skill formation — không có sự khác biệt đáng kể giữa nhóm gõ tay và nhóm paste trực tiếp. Nỗ lực cơ học (gõ lại từng dòng) không chuyển thành nỗ lực nhận thức (cognitive effort). Thời gian bỏ ra để gõ tay không tạo ra lợi thế học tập rõ rệt.
Điều này đặc biệt quan trọng trong bối cảnh rộng hơn: nếu nỗ lực cơ học không tạo ra lợi thế nhận thức, thì các chiến lược như “gõ lại code thay vì paste” hay “đọc từng dòng trước khi dùng” không phải giải pháp cho vấn đề cognitive offloading. Điều thực sự quan trọng không phải là bàn tay có gõ hay không — mà là não bộ có đang xử lý thông tin hay không.
Lỗi: người thầy mà không ai muốn gặp
Đây có lẽ là phát hiện có sức nặng nhất trong toàn bộ phân tích định tính — và nó đi ngược lại trực giác.
Cách người tham gia gặp và giải quyết lỗi khác nhau đáng kể giữa nhóm treatment và control. Trên nền tảng thí nghiệm, người tham gia có thể dùng nút Run hoặc terminal để chạy code bao nhiêu lần tùy thích. Nhìn chung, hầu hết mọi người chạy code lần đầu sau khi đã cố gắng hoàn thành phần lớn bài tập, và chỉ chạy lại sau khi sửa đổi. Nhóm nghiên cứu ghi nhận mọi lỗi mà từng người tham gia gặp phải khi xem lại toàn bộ screen recording.
Tần suất lỗi: AI che chắn, nhưng cũng che mất bài học
Nhóm AI gặp ít lỗi hơn rõ rệt so với nhóm control: median người tham gia nhóm treatment chỉ gặp một lỗi trong toàn bộ bài tập, trong khi median nhóm control là ba lỗi. Phần lớn người trong nhóm AI hoàn thành task ngay lần chạy đầu tiên. Ngược lại, ở nhóm control, hầu hết gặp nhiều lỗi trong quá trình hoàn thành từng task. Trong số 12 người hoàn thành cả hai task mà không gặp lỗi nào, chỉ có hai người thuộc nhóm control — nghĩa là 10 người còn lại đều thuộc nhóm AI.
Số liệu phân bố lỗi theo nhóm:
Nhóm AI (treatment): Median 1.0 lỗi (Q1-Q3: 0.0-3.0); Task 1: 0.0 (0.0-2.0); Task 2: 0.0 (0.0-1.0)
Nhóm không AI (control): Median 3.0 lỗi (Q1-Q3: 2.0-5.0); Task 1: 2.0 (0.5-3.0); Task 2: 2.0 (0.5-2.0)
Không phải lỗi nào cũng bình đẳng — lỗi Trio mới là yếu tố quyết định
Không phải lỗi nào cũng có trọng lượng như nhau trong quá trình hình thành kỹ năng. Một số lỗi đòi hỏi hiểu biết sâu hơn về thư viện Trio — và chính điều này có thể giải thích sự khác biệt trong kết quả học tập. Các lỗi phổ biến nhất không liên quan trực tiếp đến Trio: NameError và AttributeError thường chỉ là lỗi đánh máy ở tên biến hoặc tên hàm, được sửa nhanh chóng. Nhưng có những lỗi liên quan trực tiếp đến Trio: RuntimeWarning xuất hiện khi một coroutine không được await, TypeError xuất hiện khi một hàm Trio nhận coroutine object thay vì async function. Những lỗi này buộc người lập trình phải hiểu các khái niệm cốt lõi — cách Trio xử lý coroutines và cách dùng từ khóa await — chính xác là những gì bài kiểm tra đánh giá. Dù nhóm AI cũng gặp lỗi, số lỗi liên quan đến Trio ít hơn rất nhiều.
Với nhóm control, tần suất gặp lỗi cao hơn dẫn đến nhiều tư duy phản biện hơn về những gì đang xảy ra trong code và cách sử dụng thư viện mới. Hơn nữa, việc liên tục gặp lỗi đặc thù của Trio đảm bảo rằng các khái niệm cụ thể này được tiếp thu trong quá trình hoàn thành task. Hai sự khác biệt này cùng gợi ý rằng gặp lỗi có thể đóng vai trò then chốt trong quá trình hình thành kỹ năng lập trình. Hơn nữa, động lực ban đầu của nghiên cứu — bảo tồn kỹ năng debugging — có thể phụ thuộc vào việc các kỹ năng này được hình thành mà không cần dựa vào AI.
Nếu chúng ta phải chắt lọc, insight cốt lõi ở đây là: AI không chỉ giúp tránh lỗi — nó loại bỏ một kênh học tập quan trọng. RuntimeWarning khi quên await, TypeError khi truyền coroutine thay vì async function — mỗi lỗi này là một micro-lesson buộc người lập trình phải hiểu cách thư viện hoạt động ở mức sâu nhất. Nhóm dùng AI “thoát” khỏi những lỗi này, nhưng đồng thời cũng thoát khỏi bài học mà lỗi mang lại.
Nguyên lý này không chỉ đúng trong lập trình. Trong y khoa, bác sĩ nội trú học nhiều nhất từ những ca khó — những ca mà chẩn đoán ban đầu sai, buộc họ phải nghĩ lại từ đầu. Trong thể thao, cầu thủ phát triển nhanh nhất khi đối mặt với đối thủ mạnh hơn mình — khi bị phá vỡ chiến thuật và phải tìm cách mới. Lỗi, thất bại, friction — chúng không phải chướng ngại trên đường học, mà là chính con đường.
Thời gian viết code thực: thước đo bị bỏ quên
Phần lớn các nghiên cứu về AI và năng suất đo tổng thời gian hoàn thành task. Nhưng tổng thời gian che giấu một sự thay đổi cấu trúc quan trọng: thời gian thực sự viết code (active coding time) đã bị co lại đáng kể ở nhóm dùng AI.
Nhóm không dùng AI dành phần lớn thời gian cho việc viết, chạy, sửa code — một chu trình liên tục buộc họ phải tương tác trực tiếp với ngôn ngữ và thư viện. Nhóm dùng AI chuyển phần lớn thời gian đó sang đọc và hiểu output của AI — một hoạt động khác về bản chất. Sự dịch chuyển từ “làm” sang “đọc” này cũng đã được Becker et al. ghi nhận trong các nghiên cứu trước đó.
Nhưng có một nghịch lý thú vị: trong cả hai nhóm, những người dành nhiều active coding time hơn lại có điểm thấp hơn. Tại sao? Vì lập trình viên giỏi hơn viết code nhanh hơn — họ cần ít thời gian hơn để hoàn thành cùng một task nhờ kiến thức nền tốt hơn. Active coding time ở đây phản ánh trình độ đầu vào, không phải mức độ nỗ lực. Điều quan trọng không phải là bao lâu, mà là làm gì trong khoảng thời gian đó.
Tiếng nói từ chính người tham gia
Phản hồi của người tham gia cho thấy một chiều sâu mà số liệu không nắm bắt được. Khoảng một phần tư người tham gia để lại nhận xét sau khi hoàn thành bài tập và kiểm tra.
Nhóm không dùng AI có phản hồi tích cực đáng ngạc nhiên: họ thấy bài tập thú vị, hướng dẫn task giúp họ hiểu Trio tốt. Nhóm dùng AI thì ngược lại — nhiều người thừa nhận ước mình đã chú ý hơn đến chi tiết của thư viện, đã đọc kỹ code được generate hơn, hoặc đã yêu cầu giải thích sâu hơn. Cụ thể, có người tự mô tả mình là “lazy” và nhận ra rằng “there are still a lot of gaps in (their) understanding”.
Đây là một dạng meta-cognition (nhận thức về chính quá trình nhận thức của mình): người dùng AI biết họ đã không học được nhiều, nhưng trong lúc làm task, áp lực hoàn thành nhanh đã đẩy họ về phía delegation. Sentiment tổng thể của nhóm control tích cực hơn nhóm treatment — mặc dù cả hai nhóm làm cùng task, cùng bài kiểm tra. Trải nghiệm tự mình giải quyết vấn đề, dù khó hơn, lại mang lại cảm giác thoả mãn hơn.
Bức tranh rộng hơn: khi nghiên cứu chạm đến thực tế
Phát hiện chính của nghiên cứu này — AI giảm skill formation khi học kỹ năng mới — có hàm ý vượt ra khỏi phòng thí nghiệm. Trong bối cảnh thực tế, khoảng cách giữa nhóm high-scoring patterns (65-86% quiz score) và low-scoring patterns (24-39% quiz score) đặt ra câu hỏi: ai sẽ chọn con đường nào?
Giả định ẩn ở đây là mọi người có quyền tự do chọn cách tương tác với AI. Nhưng trong môi trường doanh nghiệp, nơi deadline áp sát và KPI đo bằng output, junior developers chịu áp lực hoàn thành nhanh nhất có thể. Họ có đủ không gian để chọn Conceptual Inquiry thay vì AI Delegation không? Nghiên cứu không trả lời câu hỏi này — nhưng nó cho thấy rằng nếu tổ chức chỉ đo năng suất ngắn hạn mà bỏ qua skill formation, chi phí dài hạn có thể rất lớn.
Và ở chiều ngược lại, phát hiện về debugging đáng lo ngại nhất trong các lĩnh vực safety-critical. Nếu kỹ năng debugging — khả năng phát hiện và sửa lỗi — bị suy giảm vì AI đã loại bỏ quá trình gặp lỗi trong quá trình học, thì chính những người được giao nhiệm vụ giám sát code AI sẽ là người ít được trang bị nhất để làm điều đó. Đây là một vòng xoắn mà nghiên cứu chỉ mới bắt đầu chạm tới.
Nhưng cũng cần nói thẳng: cognitive engagement không phải là bỏ AI đi. Ba khuôn mẫu high-scoring đều dùng AI — chỉ là dùng theo cách vẫn buộc não bộ phải tham gia. Hỏi conceptual questions thay vì chỉ generate code. Yêu cầu giải thích kèm theo code. Generate trước rồi hỏi để hiểu. Mỗi cách đều tốn thêm thời gian, nhưng đổi lại là kiến thức thực sự được hình thành.
Những câu hỏi còn mở
Shen và Tamkin thẳng thắn về giới hạn của nghiên cứu — và chính sự thẳng thắn này mở ra những câu hỏi đáng suy ngẫm hơn bản thân kết quả.
Giới hạn lớn nhất có lẽ nằm ở dạng AI được sử dụng. Nghiên cứu dùng chat-based interface — nơi người dùng phải soạn câu hỏi, suy nghĩ về cách diễn đạt. Nhưng xu hướng đang chuyển nhanh sang agentic AI coding tools — công cụ tự viết code mà con người chỉ duyệt output cuối. Nếu chat interface — vốn buộc một mức cognitive engagement tối thiểu — đã gây suy giảm 17% kỹ năng, thì agentic tools sẽ tác động thế nào? Đây không phải câu hỏi giả — nó là câu hỏi cấp bách nhất mà nghiên cứu tiếp theo cần trả lời.
Giới hạn thứ hai liên quan đến thời gian. Skill formation thực tế diễn ra qua nhiều tháng, nhiều năm — không phải một giờ. Một thí nghiệm dọc (longitudinal study) theo dõi cùng nhóm người qua thời gian sẽ cho thấy liệu hiệu ứng suy giảm kỹ năng tích lũy hay tự điều chỉnh. Và ở chiều ngược lại: người tham gia là lập trình viên freelance, không có cùng động lực học như khi thư viện đó thực sự cần cho công việc. Nghiên cứu trong môi trường onboarding thực tế — nơi junior developer phải nắm vững kỹ năng mới — sẽ cho kết quả sát thực hơn.
Hai giới hạn kỹ thuật cũng đáng lưu ý. Nghiên cứu thu thập self-report về mức quen thuộc với AI nhưng không đo thực tế kỹ năng prompting — trong khi sáu khuôn mẫu cho thấy cách hỏi AI có thể quan trọng hơn việc có hỏi hay không. Và skill formation được đo qua quiz — một phương pháp có giá trị, nhưng không phải duy nhất. Nếu đánh giá bằng cách yêu cầu hoàn thành một task mới mà không có AI, kết quả có thể khác.
Cuối cùng, một counterfactual mà nghiên cứu chưa đặt ra: nếu thay AI bằng người hỗ trợ — pair programming, code review, mentoring — skill formation sẽ bị ảnh hưởng tương tự hay khác hoàn toàn? Câu hỏi này quan trọng vì nó phân tách hai biến: nhận hỗ trợ nói chung vs nhận hỗ trợ từ AI cụ thể.
Cognitive engagement — nguyên lý vượt qua lập trình
Nếu phải chắt lọc toàn bộ phân tích này về một nguyên lý, đó là: công cụ không quyết định kết quả học tập — mức độ tham gia nhận thức của người dùng mới quyết định. AI Delegation và Conceptual Inquiry đều dùng cùng một AI assistant, nhưng một bên đạt 24% và bên kia đạt trung bình cao nhất trong tất cả các khuôn mẫu.
Nghiên cứu cũng ghi nhận một tín hiệu đáng chú ý: các dịch vụ LLM lớn đã bắt đầu cung cấp learning modes (ví dụ ChatGPT Study Mode, Claude Code Learning / Explanatory mode) — những chế độ được thiết kế để AI hỗ trợ mà vẫn giữ cognitive engagement. Đây là hướng đi mà sáu khuôn mẫu trong nghiên cứu này gợi mở: không phải loại bỏ AI khỏi quá trình học, mà thiết kế lại cách AI tham gia.
Nhưng câu hỏi lớn nhất vẫn còn mở — và có lẽ sẽ định hình thập kỷ tới của giáo dục và phát triển nghề nghiệp: trong một thế giới mà AI ngày càng có thể làm thay nhiều hơn, chúng ta dựa vào điều gì để quyết định kỹ năng nào vẫn cần con người thực sự nắm vững? Những người tham gia nền kinh tế AI mới không thể chỉ quan tâm đến năng suất mà AI mang lại — họ phải quan tâm đến tính bền vững dài hạn của quá trình phát triển chuyên môn giữa làn sóng công cụ AI mới liên tục xuất hiện. Nếu ranh giới giữa “đủ hiểu để giám sát” và “không hiểu nhưng vẫn ký duyệt” tiếp tục mờ đi, thì sáu khuôn mặt trong nghiên cứu này không chỉ là phân loại học thuật — chúng là tấm gương phản chiếu cách mỗi chúng ta đang chọn quan hệ với công cụ mạnh nhất mà mình từng có.