AI ส่งผลต่อการสร้างทักษะอย่างไร
บทคัดย่อ (Abstract)
การใช้ AI เข้าช่วยเพิ่ม Productivity ได้อย่างมากในหลากหลายสาขาวิชาชีพ โดยเฉพาะอย่างยิ่งกับกลุ่มพนักงานมือใหม่ (Novice workers) อย่างไรก็ตาม ยังไม่เป็นที่แน่ชัดว่าความช่วยเหลือนี้ส่งผลอย่างไรต่อการพัฒนาทักษะที่จำเป็นในการกำกับดูแล (Supervise) AI อย่างมีประสิทธิภาพ พนักงานมือใหม่ที่พึ่งพา AI อย่างหนักในการทำงานที่ไม่คุ้นเคยอาจกำลังทำลายการเรียนรู้ทักษะ (Skill acquisition) ของตนเองในระหว่างนั้น เราได้ทำการทดลองแบบสุ่ม (Randomized experiments) เพื่อศึกษาว่านักพัฒนาสร้างความเชี่ยวชาญใน Asynchronous programming library ตัวใหม่ได้อย่างไร ทั้งในกรณีที่มีและไม่มี AI ช่วยเหลือ เราพบว่าการใช้ AI ส่งผลเสียต่อความเข้าใจในมโนทัศน์ (Conceptual understanding), การอ่านโค้ด (Code reading) และความสามารถในการ Debugging โดยเฉลี่ยแล้วไม่ได้ช่วยให้การทำงานเร็วขึ้นอย่างมีนัยสำคัญ ผู้เข้าร่วมที่มอบหมายงานเขียนโค้ด (Delegate) ให้ AI ทั้งหมดพบว่า Productivity เพิ่มขึ้นบ้าง แต่ต้องแลกมาด้วยการไม่ได้เรียนรู้ Library นั้นเลย เรายังพบรูปแบบการปฏิสัมพันธ์กับ AI ที่แตกต่างกัน 6 รูปแบบ โดย 3 รูปแบบในนั้นมีการใช้กระบวนการคิดร่วมด้วย (Cognitive engagement) ซึ่งสามารถรักษาผลการเรียนรู้ไว้ได้แม้จะได้รับความช่วยเหลือจาก AI ข้อค้นพบของเราชี้ให้เห็นว่า Productivity ที่เพิ่มขึ้นจาก AI ไม่ใช่ทางลัดสู่ความเชี่ยวชาญ และควรนำ AI เข้ามาใช้ใน Workflow อย่างระมัดระวังเพื่อรักษาการสร้างทักษะ (Skill formation) โดยเฉพาะในสายงานที่ให้ความสำคัญกับความปลอดภัยสูง (Safety-critical domains)
1 บทนำ (Introduction)
นับตั้งแต่ยุคปฏิวัติอุตสาหกรรม ทักษะในตลาดแรงงานมีการเปลี่ยนแปลงอยู่เสมอตามการนำเทคโนโลยีใหม่ๆ เข้ามาใช้ บทบาทของคนทำงานมักจะเปลี่ยนจากการลงมือทำ (Performing) ไปเป็นการกำกับดูแล (Supervising) งานแทน [Autor et al., 2001] ยกตัวอย่างเช่น ระบบอัตโนมัติในหุ่นยนต์โรงงานช่วยให้พนักงานย้ายจากการใช้แรงงานคนไปเป็นการควบคุมดูแล และซอฟต์แวร์บัญชีช่วยให้มืออาชีพย้ายจากการคำนวณเบื้องต้นไปเป็นการระบุกลยุทธ์การบันทึกบัญชีและการจัดทำภาษีได้ดียิ่งขึ้น ในทั้งสองสถานการณ์นี้ มนุษย์ยังคงเป็นผู้รับผิดชอบต่อคุณภาพของผลิตภัณฑ์ขั้นสุดท้ายและต้องรับผิดชอบต่อความผิดพลาดที่เกิดขึ้น [Bleher and Braun, 2022] แม้ว่าระบบอัตโนมัติจะเข้ามาเปลี่ยนกระบวนการทำงาน แต่ความรู้ทางเทคนิคเพื่อระบุและแก้ไขข้อผิดพลาดก็ยังคงมีความสำคัญอย่างยิ่ง
ในขณะที่ AI สัญญาว่าจะเข้ามาเป็นตัวเร่งการทำงานอัตโนมัติและเพิ่ม Productivity ในหลากหลายสาขา ตั้งแต่วิศวกรรมซอฟต์แวร์ไปจนถึงการเป็นผู้ประกอบการ [Dell’Acqua et al., 2023, Peng et al., 2023, Cui et al., 2024, Otis et al., 2024, Brynjolfsson et al., 2025] แต่ผลกระทบของ AI ต่อแรงงานนั้นยังไม่เป็นที่เข้าใจอย่างถ่องแท้ แม้ว่าจะมีพนักงานจำนวนมากพึ่งพา AI เพื่อเพิ่ม Productivity ของตนเอง แต่ยังไม่แน่ชัดว่าการใช้ AI เข้าช่วยในที่ทำงานอาจขัดขวางความเข้าใจพื้นฐานในตัวมโนทัศน์ (Concepts) หรือป้องกันไม่ให้เกิดการพัฒนาทักษะที่จำเป็นในการกำกับดูแลงานอัตโนมัติหรือไม่ แม้ว่าการส่วนใหญ่จะเน้นไปที่ ผลลัพธ์ (Product) ของการช่วยเหลือจาก AI (เช่น จำนวนบรรทัดของโค้ดที่เขียน หรือคุณภาพของไอเดียที่เสนอ) แต่คำถามที่สำคัญไม่แพ้กัน หรืออาจจะสำคัญกว่านั้นคือ กระบวนการ (Process) ของการได้รับความช่วยเหลือจาก AI นั้นส่งผลกระทบต่อคนทำงานอย่างไร เมื่อมนุษย์หันไปพึ่งพา AI สำหรับทักษะต่างๆ เช่น การระดมความคิด การเขียน และการคิดเชิงวิพากษ์ในภาพรวม การพัฒนาทักษะเหล่านี้อาจถูกเปลี่ยนแปลงไปอย่างมาก ขึ้นอยู่กับว่ามีการใช้ AI ช่วยเหลืออย่างไร
โดยเฉพาะอย่างยิ่งในงานวิศวกรรมซอฟต์แวร์ ซึ่งถูกมองว่าเป็นอาชีพที่สามารถนำเครื่องมือ AI มาใช้ได้อย่างรวดเร็ว และความช่วยเหลือจาก AI ก็ช่วยเพิ่ม Productivity ในงานประจำวันได้อย่างมีนัยสำคัญ [Peng et al., 2023, Cui et al., 2024] โดยเฉพาะกลุ่มพนักงานระดับจูเนียร์หรือมือใหม่ที่มักจะได้รับประโยชน์สูงสุดจาก AI เมื่อต้องเขียนโค้ด ในการใช้งานที่มีความเสี่ยงสูง (High-stakes) โค้ดที่ AI เขียนขึ้นอาจจะต้องผ่านการ Debug และ Test โดยมนุษย์ก่อนที่จะนำซอฟต์แวร์นั้นไป Deploy จริง การตรวจสอบเพิ่มเติมเพื่อความปลอดภัยนี้จะเป็นไปได้ก็ต่อเมื่อวิศวกรที่เป็นมนุษย์มีทักษะในการทำความเข้าใจโค้ดและระบุข้อผิดพลาดได้ด้วยตนเองเท่านั้น เมื่อ AI พัฒนาไปเรื่อยๆ ปัญหาในการกำกับดูแลระบบ AI ที่มีความสามารถมากขึ้นก็จะยิ่งยากขึ้นหากมนุษย์มีความสามารถในการทำความเข้าใจโค้ดลดลง [Bowman et al., 2022] เมื่อโปรเจกต์ซอฟต์แวร์ที่ซับซ้อนต้องการความร่วมมือระหว่างมนุษย์และ AI มนุษย์ยังคงจำเป็นต้องเข้าใจมโนทัศน์พื้นฐานของการพัฒนาโค้ด แม้ว่าทักษะซอฟต์แวร์ของพวกเขาจะเป็นส่วนเสริมให้กับจุดแข็งของ AI ก็ตาม [Wang et al., 2020] การผสมผสานระหว่างความต้องการความสามารถที่ยังคงอยู่ในการทำงานที่มีความเสี่ยงสูง กับ Productivity ที่เพิ่มขึ้นอย่างเห็นได้ชัดจากการใช้ AI ทำให้วิศวกรรมซอฟต์แวร์เป็นพื้นที่ทดสอบที่เหมาะสมที่สุดสำหรับการศึกษาว่า AI ส่งผลต่อการสร้างทักษะ (Skill formation) อย่างไร
เราศึกษาว่าการใช้และพึ่งพา AI ส่งผลต่อการพัฒนาทักษะวิศวกรรมซอฟต์แวร์หรือไม่ [Handa et al., 2025] จากการที่ AI ถูกนำมาใช้อย่างรวดเร็วในงานวิศวกรรมซอฟต์แวร์ เราจึงได้รับแรงบันดาลใจจากสถานการณ์ที่วิศวกรต้องเรียนรู้ทักษะใหม่ในการทำงาน แม้ว่าการใช้เครื่องมือ AI อาจช่วยเพิ่ม Productivity ให้กับวิศวกรเหล่านี้ แต่เครื่องมือนี้จะขัดขวางการสร้างทักษะด้วยหรือไม่? โดยเฉพาะอย่างยิ่ง Workflow ของการทำงานที่ได้รับความช่วยเหลือจาก AI จะขัดขวางไม่ให้วิศวกรได้รับความรู้เชิงลึกเกี่ยวกับเครื่องมือที่ใช้ในการทำงานเหล่านั้นหรือไม่? เราได้ทำการทดลองแบบสุ่ม (Randomized experiments) เพื่อวัดการสร้างทักษะโดยให้ผู้เข้าร่วมเขียนโค้ดโดยใช้ Library ตัวใหม่ที่พวกเขาไม่เคยใช้มาก่อน นี่เป็นรูปแบบปกติที่วิศวกรได้รับทักษะใหม่ๆ เนื่องจากมี Library ใหม่ๆ เกิดขึ้นบ่อยครั้งในภาษาอย่าง Python จากนั้นเราจึงประเมินความเชี่ยวชาญของพวกเขาใน Library ใหม่นั้น คำถามวิจัยหลักของเราคือ (1) AI ช่วยเพิ่ม Productivity ในงานเขียนโค้ดที่ต้องการมโนทัศน์และทักษะใหม่หรือไม่ และ (2) การใช้ AI นี้จะลดระดับความเข้าใจในมโนทัศน์และทักษะใหม่ๆ เหล่านั้นลงหรือไม่
ภาพที่ 1: ภาพรวมของผลการศึกษา: (ซ้าย) เราพบว่าทักษะเฉพาะสำหรับ Library (ความเข้าใจเชิงมโนทัศน์, การอ่านโค้ด และการ Debugging) ลดลงอย่างมากในกลุ่มพนักงานที่ใช้ AI ช่วยทำงานกับ Python Library ตัวใหม่ (ขวา) เราจัดกลุ่มรูปแบบการใช้ AI และพบ 3 รูปแบบที่มีการพัฒนาทักษะสูง โดยผู้เข้าร่วมยังคงมีส่วนร่วมทางความคิด (Cognitively engaged) เมื่อใช้ AI ช่วยเหลือ
1.1 ผลการศึกษาของเรา (Our Results)
ด้วยแรงบันดาลใจจากสถานการณ์ที่ชัดเจนของการใช้ AI และทักษะทางซอฟต์แวร์ เราได้ออกแบบโจทย์การเขียนโค้ดและการประเมินผลสำหรับ Asynchronous Python Library ตัวใหม่ และทำการทดลองแบบสุ่มเพื่อทำความเข้าใจผลกระทบของความช่วยเหลือจาก AI ต่อเวลาที่ใช้ในการทำงานและการพัฒนาทักษะ เราพบว่าการใช้ AI ช่วยทำงานกับ Library ใหม่นี้ ส่งผลให้คะแนนประเมินลดลง 17% หรือประมาณสองเกรด (Cohen’s $d=0.738$, $p=0.010$) ในขณะเดียวกัน เราไม่พบการทำงานที่เร็วขึ้นอย่างมีนัยสำคัญทางสถิติเมื่อได้รับความช่วยเหลือจาก AI (ภาพที่ 6) จากการวิเคราะห์เชิงคุณภาพเชิงลึกที่เราดูการบันทึกหน้าจอของผู้ร่วมทดสอบทุกคนในการศึกษาหลัก เราอธิบายถึงการที่ AI ไม่ได้ช่วยเพิ่ม Productivity อย่างชัดเจนว่ามาจากการที่ผู้เข้าร่วมบางคนใช้เวลาเพิ่มเติมในการปฏิสัมพันธ์กับ AI ผู้ช่วย บางคนถามคำถามถึง 15 ข้อ หรือใช้เวลามากกว่า $30%$ ของเวลาทั้งหมดในการพิมพ์คำสั่ง (Query) (ภาพที่ 12) เรารู้สึกว่าทักษะที่เพิ่มขึ้นในกลุ่มควบคุม (Control group) มาจากกระบวนการที่พวกเขาต้องเผชิญและแก้ไขข้อผิดพลาดด้วยตนเอง เราจัดกลุ่มพฤติกรรมการปฏิสัมพันธ์กับ AI ออกเป็น 6 รูปแบบ และพบ 3 รูปแบบที่ช่วยรักษาการพัฒนาทักษะได้ดีที่สุด (ภาพที่ 11) ทั้ง 3 รูปแบบนี้ส่งผลให้ได้คะแนนการประเมินที่สูงกว่า เนื่องจากต้องใช้ความคิดของตนเองมากขึ้น (เช่น การขอคำอธิบายหรือการถามคำถามเชิงมโนทัศน์เท่านั้น)
2 ภูมิหลัง (Background)
2.1 ผลกระทบของการใช้ AI (The Impacts of AI Usage)
นับตั้งแต่การเปิดตัวอย่างแพร่หลายของ ChatGPT, Copilot, Claude และผู้ช่วยด้านการสนทนาที่ล้ำสมัยอื่นๆ ในช่วงปลายปี 2022 เครื่องมือ AI ก็ถูกนำมาใช้อย่างแพร่หลายในหลายสาขา การศึกษาเกี่ยวกับการใช้งานผ่านคำสั่ง (Prompt-based utilization) ช่วยให้เราเห็นรายละเอียดการนำ AI ไปใช้ในโลกแห่งความเป็นจริงได้ดีขึ้น [Tamkin et al., 2024, Shen and Guestrin, 2025] ตัวอย่างเช่น เครื่องมือ AI ถูกนำไปใช้ในสายอาชีพต่างๆ เช่น การพัฒนาซอฟต์แวร์ การศึกษา การออกแบบ และวิทยาศาสตร์ [Handa et al., 2025]
การเพิ่มขึ้นของ Productivity (Productivity Gains)
มีการศึกษาจำนวนมากที่พบการปรับปรุงในด้าน Productivity เมื่อใช้ AI ช่วยเหลือเหล่านี้ ตัวอย่างเช่น Brynjolfsson et al. พบว่าผู้ช่วยสนทนาที่ใช้ AI ช่วยเพิ่มจำนวนปัญหาที่พนักงาน Call center สามารถแก้ไขได้เฉลี่ย 15% และ Dell’Acqua et al. พบผลลัพธ์ที่คล้ายกันโดยที่ปรึกษาทำงานเสร็จมากขึ้นเฉลี่ย 12.2% เมื่อใช้ AI ช่วยเทียบกับตอนที่ไม่ใช้ แม้ว่าผลกระทบด้านทักษะจะแตกต่างกันไปในแต่ละการศึกษา แต่มีรูปแบบที่สม่ำเสมอเกิดขึ้นในงาน Call center งานที่ปรึกษา การตอบคำถามทางกฎหมาย และการเขียน คือพนักงานที่มีประสบการณ์น้อยและมีทักษะต่ำกว่ามักจะได้รับประโยชน์สูงสุด [Brynjolfsson et al., 2025, Dell’Acqua et al., 2023, Choi and Schwarcz, 2023, Noy and Zhang, 2023] ข้อยกเว้นประการหนึ่งคือเมื่อมีการนำ GPT-4 ไปให้เจ้าของธุรกิจขนาดเล็กในเคนยา คำแนะนำธุรกิจจาก AI ช่วยให้ผู้ที่ทำผลงานได้ดี (วัดตามรายได้) ปรับปรุงผลลัพธ์ทางธุรกิจได้ดีขึ้น แต่กลับทำให้ผลลัพธ์ของกลุ่มที่ทำผลงานได้น้อยแย่ลง [Otis et al., 2024]
สำหรับงานวิศวกรรมซอฟต์แวร์โดยเฉพาะ Peng et al. พบว่านักพัฒนาซอฟต์แวร์ที่ใช้ Copilot ทำงานเสร็จเร็วกว่ากลุ่มควบคุมถึง 55.5% และโปรแกรมเมอร์มือใหม่ได้รับประโยชน์จากความช่วยเหลือในการเขียนโค้ดด้วย AI มากกว่า การศึกษาติดตามผลในกลุ่มนักพัฒนาของบริษัทซอฟต์แวร์รายใหญ่พบว่าฟีเจอร์ AI-generated code completions ช่วยเพิ่ม Productivity ได้ 26.8% โดยวัดจาก Pull Request, Commit และ Software product builds [Cui et al., 2024] การศึกษานี้ยังพบด้วยว่าโปรแกรมเมอร์ที่มีประสบการณ์น้อยได้รับการเพิ่มขึ้นของ Productivity ที่สูงกว่า แม้ว่าการศึกษาต่างๆ จะพบว่านักพัฒนาระดับจูเนียร์หรือผู้ที่มีประสบการณ์น้อยจะได้รับ Productivity เพิ่มขึ้นอย่างมากจากการใช้ AI แต่พนักงานกลุ่มเดียวกันนี้เองที่ควรจะต้องพัฒนาทักษะใหม่ๆ ในที่ทำงานอย่างรวดเร็ว อย่างไรก็ตาม ผลกระทบของเครื่องมือเหล่านี้ต่อการสร้างทักษะ (Skill formation) ของกลุ่มย่อยนี้ยังคงไม่เป็นที่ทราบแน่ชัด การพัฒนาทักษะของพนักงานมือใหม่จะได้รับผลกระทบอย่างมีนัยสำคัญหรือไม่ในขณะที่พวกเขายังอยู่ในกระบวนการเรียนรู้วิชาชีพ? เราได้รับแรงบันลใจจากคำถามที่ว่า Productivity นี้ได้มาฟรีๆ หรือมีต้นทุนที่ต้องจ่าย
การลดภาระทางความคิด (Cognitive Offloading)
ความกังวลเกี่ยวกับผลกระทบของความช่วยเหลือจาก AI และการถดถอยของทักษะได้รับการเน้นย้ำในงานวิจัยล่าสุด ตัวอย่างเช่น บุคลากรทางการแพทย์ที่ได้รับการฝึกอบรมด้วยความช่วยเหลือจาก AI อาจไม่สามารถพัฒนาทักษะการมองเห็นที่เฉียบคมเพื่อระบุสภาวะบางอย่างได้ [Macnamara et al., 2024] ในการสำรวจกลุ่มพนักงานที่ใช้ความรู้ (Knowledge workers) การใช้ AI บ่อยครั้งมีความสัมพันธ์กับความสามารถในการคิดเชิงวิพากษ์ที่แย่ลง และการลดภาระทางความคิด (Cognitive offloading) ที่เพิ่มขึ้น [Gerlich, 2025] นอกจากนี้ พนักงานยังรายงานว่าพวกเขามีความพยายามทางความคิด (Cognitive effort) และความมั่นใจลดลงเมื่อใช้เครื่องมือ Generative AI [Lee et al., 2025] อย่างไรก็ตาม การสำรวจเหล่านี้เป็นเพียงการสังเกตการณ์และอาจไม่สามารถสะท้อนถึงผลกระทบที่เป็นเหตุเป็นผล (Causal effects) ของการใช้ AI ได้โดยตรง
การรักษาทักษะ (Skill Retention)
แนวทางการวิจัยที่ใกล้เคียงกับงานของเราคือ มนุษย์สามารถรักษาความรู้และทักษะไว้ได้ดีเพียงใดหลังจากได้รับความช่วยเหลือจาก AI Wu et al. พบว่าแม้ Generative AI จะช่วยปรับปรุงประสิทธิภาพในการทำงานสร้างคอนเทนต์ในทันที (เช่น การเขียนโพสต์บน Facebook การเขียนรายงานผลการปฏิบัติงาน หรือการร่างอีเมลต้อนรับ) แต่ประสิทธิภาพที่เพิ่มขึ้นนั้นกลับไม่คงอยู่ในการทำงานครั้งถัดไปที่มนุษย์ทำด้วยตัวเองอย่างอิสระ สำหรับงานด้าน Data science Wiles et al. ได้อธิบายถึงผลกระทบของ AI ต่อที่ปรึกษาที่ไม่ใช่สายเทคนิคว่าเป็นเหมือน "ชุดเกราะภายนอก" (Exoskeleton) คือความสามารถทางเทคนิคที่เพิ่มขึ้นจาก AI นั้นไม่คงอยู่เมื่อพนักงานไม่สามารถเข้าถึง AI ได้อีกต่อไป งานวิจัยของเราจึงตั้งคำถามต่อเนื่องว่า การใช้เครื่องมือ AI อาจส่งผลให้ผลลัพธ์การเรียนรู้แย่ลงสำหรับการสร้างทักษะในการทำงานของมืออาชีพสายเทคนิคเองด้วยหรือไม่
การพึ่งพามากเกินไป (Overreliance)
แม้ว่างานวิจัยด้านเศรษฐศาสตร์จำนวนมากเกี่ยวกับการเพิ่มขึ้นของ Productivity ด้วย AI จะสมมติเป็นนัยว่า AI รุ่นต่างๆ นั้นน่าเชื่อถือ แต่ความจริงคือ Generative AI สามารถสร้างข้อมูลที่ผิดพลาด [Longwell et al., 2024] หรือเนื้อหาที่ "หลอน" (Hallucinated) ขึ้นมาเองได้ [Maleki et al., 2024] เมื่อโมเดลมีข้อผิดพลาดแต่ยังคงถูกนำมาใช้ช่วยเหลือมนุษย์ การตัดสินใจของมนุษย์ที่คล้อยตามการตัดสินใจที่ผิดพลาดของโมเดลจะถูกเรียกว่า "การพึ่งพามากเกินไป" (Overreliance) [Buçinca et al., 2021, Vasconcelos et al., 2023, Klingbeil et al., 2024] แม้ว่าจะมีการเสนอวิธีการเพื่อลดการพึ่งพามากเกินไป แต่วิธีการเหล่านี้มักมุ่งเน้นไปที่ข้อมูลในขณะที่ตัดสินใจ เช่น การให้คำอธิบาย [Vasconcelos et al., 2023, Reingold et al., 2024] หรือการโต้แย้ง (Debate) [Kenton et al., 2024]
2.2 การศึกษาวิทยาการคอมพิวเตอร์และความช่วยเหลือจาก AI (CS Education and AI Assistance)
การวัดผลการสร้างทักษะนั้นขึ้นอยู่กับสาขาวิชาเป็นอย่างมาก สำหรับวิทยาการคอมพิวเตอร์โดยเฉพาะ หลักสูตรเบื้องต้นส่วนใหญ่มักวัดการเรียนรู้ผ่านคำถามแบบปรนัย (Multiple choice) การเขียนโค้ด และการอ่านโค้ดหรือการอธิบายโค้ด [Cheng et al., 2022] งานวิจัยล่าสุดยังพบว่าการสัมภาษณ์เรื่องโค้ด (Code interviews) และการอภิปรายเกี่ยวกับโค้ดของนักเรียนอย่างจริงจังช่วยให้เกิดผลลัพธ์การเรียนรู้ที่ดี [Kannam et al., 2025]
มีการศึกษาสังเกตการณ์หลายฉบับที่อธิบายถึงวิธีที่นักเรียนใช้เครื่องมือ AI ในบริบทของหลักสูตรวิทยาการคอมพิวเตอร์ Poitras et al. พบว่าตลอดหนึ่งภาคการศึกษา นักเรียนใช้เครื่องมือ AI เพื่อเขียนโค้ด แก้ไขข้อผิดพลาด และอธิบายแนวคิดทางอัลกอริทึม โดยนักเรียนที่มีความเชี่ยวชาญในการเขียนโค้ดน้อยกว่ามีแนวโน้มที่จะขอความช่วยเหลือจาก AI มากกว่า งานวิจัยอื่นๆ ที่ใช้การสำรวจพบว่านักเรียนอาจลังเลที่จะใช้เครื่องมือช่วยเขียนโค้ดด้วย AI เนื่องจาก "ความกังวลเรื่องการพึ่งพา" (คือการพึ่งพาเครื่องมือเขียนโค้ดมากเกินไป) [Pan et al., 2024] สำหรับวิชา Formal methods Prasad et al. ได้รวบรวมวิธีต่างๆ ที่นักเรียนใช้ LLM ในการทำการบ้านและพบว่านักเรียนชั้นปีสูงๆ ที่ลงเรียนวิชานี้ไม่ได้พึ่งพาความช่วยเหลือจาก LLM และถามคำถามเพียงไม่กี่ข้อในช่วงเริ่มต้นเท่านั้น
การศึกษาผู้ใช้ยังได้ถูกจัดทำขึ้นในสภาพแวดล้อมการพัฒนาซอฟต์แวร์ระดับมืออาชีพด้วย Wang et al. ได้ศึกษารูปแบบการใช้งานที่แตกต่างกันระหว่างผู้ใช้ที่มีและไม่มีการเข้าถึงการแชทกับโมเดล AI ในการทำโจทย์พัซเซิลการเขียนโค้ดและงานด้านการพัฒนา พวกเขาพบรูปแบบการปฏิสัมพันธ์ที่หลากหลาย รวมถึงการ Debugging แบบโต้ตอบ การอภิปรายเรื่องโค้ด และการถามคำถามเฉพาะเจาะจง ผู้เข้าร่วมมีพฤติกรรมตั้งแต่การขอให้ ChatGPT ทำโจทย์ทั้งหมดให้ (ซึ่งให้ผลลัพธ์โค้ดที่มีคุณภาพต่ำที่สุด) ไปจนถึงการถามคำถามเพียงเล็กน้อยเท่านั้น (ซึ่งให้ประสิทธิภาพสูงสุด) การศึกษาอื่นๆ รายงานว่าเครื่องมือ AI ช่วยในกระบวนการพัฒนาซอฟต์แวร์ผ่านการเข้าถึง Documentation ที่ง่ายขึ้น และการสร้างโค้ดที่แม่นยำสำหรับ API เฉพาะทาง [Pinto et al., 2024]
3 กรอบแนวคิด (Framework)
การได้รับทักษะระดับมืออาชีพ (Professional Skill Acquisition)
ปรัชญา "การเรียนรู้จากการลงมือทำ" (Learning by doing) ถูกนำเสนอโดยกรอบการเรียนรู้หลายรูปแบบ เช่น วงจรการเรียนรู้จากประสบการณ์ของ Kolb (Kolb’s experiential learning cycle) และการเรียนรู้โดยใช้ปัญหาเป็นฐาน (Problem-Based Learning หรือ PBL) [Kolb, 2014, Schmidt, 1994] กรอบแนวคิดเหล่านี้เชื่อมโยงการทำงานจริงเข้ากับการเรียนรู้มโนทัศน์ใหม่ๆ และการพัฒนาทักษะใหม่ การเรียนรู้จากประสบการณ์ยังถูกนำมาใช้ศึกษาโดยเฉพาะในหลักสูตรวิศวกรรมซอฟต์แวร์ระดับอุดมศึกษา เพื่อจำลองการแก้ปัญหาในสภาพแวดล้อมการทำงานจริง [Gonzalez-Huerta et al., 2020]
ภาพที่ 2: เมื่อความช่วยเหลือจาก AI กลายเป็นสิ่งที่พบเห็นได้ทั่วไปในที่ทำงาน พนักงานมือใหม่อาจทำงานเสร็จสิ้นโดยไม่ได้รับผลลัพธ์ทางการเรียนรู้ที่เท่าเดิม การทดลองของเรามุ่งเน้นไปที่การศึกษากระบวนการทำงานที่ต้องใช้ทักษะใหม่ เพื่อทำความเข้าใจผลกระทบของความช่วยเหลือจาก AI ต่อการสร้างทักษะในการเขียนโค้ด
ในรูปแบบที่ง่ายที่สุด เราจำลองให้ความช่วยเหลือจากเครื่องมือ AI เป็นเหมือนการเลือกเส้นทางการเรียนรู้ที่แตกต่างไปจากการไม่ใช้ AI เราตั้งสมมติฐานว่าการใช้เครื่องมือ AI เพื่อสร้างโค้ดในกระบวนการพัฒนานั้น เท่ากับเป็นการใช้ทางลัดไปสู่การทำงานให้เสร็จสิ้น โดยที่ไม่มีขั้นตอนการเรียนรู้ที่ชัดเจนเกิดขึ้น
รูปแบบการใช้ AI สำหรับการเขียนโค้ด (AI for Coding Usage Patterns)
งานวิจัยก่อนหน้านี้พบว่ามนุษย์ใช้ AI ในหลายรูปแบบสำหรับการเขียนโค้ด: ตั้งแต่การถามตอบคำถาม ไปจนถึงการเขียนโค้ด และการ Debugging [Poitras et al., 2024, Wang et al., 2020, Pinto et al., 2024] ในกรอบแนวคิดของเรา วิธีการใช้ความช่วยเหลือจาก AI ที่แตกต่างกันนี้ จะเป็นตัวแทนของเส้นทางการเรียนรู้ที่แตกต่างกันเพื่อไปให้ถึงเป้าหมายในการทำงานให้เสร็จสิ้น เราจะวิเคราะห์รูปแบบการใช้งานที่แตกต่างกันเหล่านี้ในการวิเคราะห์เชิงคุณภาพ (ส่วนที่ 6)
คำถามการวิจัย (Research Questions)
จากภูมิหลังข้างต้น เรามุ่งเน้นไปที่การเรียนรู้ในขณะทำงาน (On-the-job learning): สถานการณ์ที่คนทำงานต้องได้รับทักษะใหม่ๆ เพื่อทำให้งานเสร็จสิ้น เราพยายามที่จะทำความเข้าใจทั้งผลกระทบของ AI ต่อ Productivity และการสร้างทักษะ (Skill formation) เราตั้งคำถามว่าความช่วยเหลือจาก AI นำไปสู่การแลกเปลี่ยน (Tradeoff) ระหว่าง Productivity ในทันทีกับการพัฒนาทักษะในระยะยาวหรือไม่ หรือความช่วยเหลือจาก AI จะเป็นทางลัดที่ช่วยส่งเสริมทั้งสองอย่าง คำถามการวิจัยของเรามีดังนี้:
- • RQ1: ความช่วยเหลือจาก AI ช่วยเพิ่ม Productivity ในการทำงานให้เสร็จสิ้นหรือไม่ เมื่อจำเป็นต้องใช้ทักษะใหม่ๆ?
- • RQ2: การใช้ความช่วยเหลือจาก AI ส่งผลอย่างไรต่อการพัฒนาทักษะใหม่เหล่านี้?
4 วิธีการ (Methods)
4.1 การเลือกโจทย์: เรียนรู้ Asynchronous Programming ด้วย Trio (Task Selection: Learning Asynchronous Programming with Trio)
เราได้สร้างต้นแบบโจทย์สำหรับทักษะที่หลากหลายซึ่งวิศวกรซอฟต์แวร์ระดับจูเนียร์อาจพบเจอในการทำงาน: ตั้งแต่การวิเคราะห์ข้อมูลไปจนถึงการวาดกราฟ เราออกแบบการทดลองเกี่ยวกับ Python Trio library [1] ซึ่งถูกออกแบบมาสำหรับ Asynchronous concurrency และการประมวลผล Input-output (I/O) โดย Library นี้เป็นที่รู้จักน้อยกว่า asyncio (เมื่ออ้างอิงจากจำนวนคำถามใน StackOverflow) และเกี่ยวข้องกับมโนทัศน์ใหม่ๆ (เช่น Structured concurrency) ที่มากกว่าแค่ความคล่องแคล่วในภาษา Python นอกจากนี้ มันยังถูกออกแบบมาให้ใช้งานง่ายเป็นพิเศษ ทำให้มันเหมาะสมอย่างยิ่งสำหรับการทดลองด้านการเรียนรู้
[1] ดูรายละเอียดได้ที่: https://trio.readthedocs.io/en/stable/
ภาพที่ 3: อินเทอร์เฟซการทดลอง: เราใช้แพลตฟอร์มการสัมภาษณ์ออนไลน์เพื่อรันการทดลองของเรา ผู้เข้าร่วมในเงื่อนไขกลุ่มทดลอง (Treatment condition) จะได้รับคำแนะนำให้ใช้ผู้ช่วย AI
เราได้ออกแบบและทดสอบโจทย์ 5 ข้อที่ใช้ Trio library สำหรับการทำ Asynchronous programming ซึ่งเป็นทักษะที่มักจะได้เรียนรู้ในสภาพแวดล้อมการทำงานจริงเมื่อต้องจัดการกับข้อมูลขนาดใหญ่หรือระบบซอฟต์แวร์ขนาดใหญ่ โจทย์ที่เราสร้างขึ้นประกอบด้วยคำอธิบายปัญหา โค้ดเริ่มต้น (Starter code) และคำอธิบายสั้นๆ เกี่ยวกับมโนทัศน์ของ Trio ที่จำเป็นสำหรับการทำโจทย์นั้นให้เสร็จสิ้น โจทย์เหล่านี้ถูกออกแบบมาเพื่อให้สอดคล้องกับกระบวนการเรียนรู้วิธีการใช้ Library ใหม่หรือเครื่องมือซอฟต์แวร์ใหม่ผ่านคู่มือเรียนรู้ด้วยตนเองแบบสั้นๆ ตัวอย่างเช่น ในเอกสารสำหรับการเริ่มต้นงาน (On-boarding materials) ของวิศวกรซอฟต์แวร์ มักจะมีคำอธิบายวิธีใช้ Library ภายในองค์กรและโจทย์ขนาดเล็กเพื่อสร้างทักษะในการใช้ Library ใหม่นั้น
หลังจากผ่านการศึกษาเบื้องต้น (Pilot studies) หลายครั้ง เราได้เลือกใช้ 2 โจทย์แรกในการศึกษาหลักของเรา โดยแต่ละโจทย์ใช้เวลาประมาณ 10 - 20 นาทีในการทดสอบช่วงแรก โจทย์แรกคือการเขียนตัวจับเวลาที่จะพิมพ์ข้อความออกมาในทุกวินาทีที่ผ่านไปในขณะที่ฟังก์ชันอื่นๆ กำลังทำงาน โจทย์นี้จะแนะนำมโนทัศน์หลักเรื่อง Nurseries การเริ่มต้นงาน (Starting tasks) และการรันฟังก์ชันแบบขนาน (Concurrent) ใน Trio ส่วนโจทย์ที่สองเกี่ยวข้องกับการสร้างฟังก์ชันดึงข้อมูล (Record retrieval) ที่สามารถจัดการกับข้อผิดพลาดของข้อมูลที่ขาดหายไปได้ใน Trio library โจทย์นี้จะแนะนำมโนทัศน์ต่างๆ เช่น Error handling และการใช้ Memory channels เพื่อเก็บผลลัพธ์ โจทย์ทั้งสองนี้แยกจากกันโดยอิสระ โดยเราได้ให้คำแนะนำและตัวอย่างการใช้งานที่เพียงพอเพื่อให้ผู้เข้าร่วมสามารถทำโจทย์ข้อหนึ่งให้เสร็จได้โดยไม่จำเป็นต้องทำอีกข้อหนึ่งมาก่อน
เราได้ใช้แพลตฟอร์มการสัมภาษณ์ออนไลน์ที่มีอินเทอร์เฟซแชทของผู้ช่วย AI (ภาพที่ 3) สำหรับการทดลองของเรา ผู้เข้าร่วมในเงื่อนไขกลุ่ม AI จะได้รับการแนะนำให้ใช้ผู้ช่วย AI เพื่อช่วยในการทำโจทย์ให้เสร็จสิ้น โมเดลพื้นฐานที่ใช้สำหรับผู้ช่วยนี้คือ GPT-4o และโมเดลได้รับ Prompt ให้ทำหน้าที่เป็นผู้ช่วยเขียนโค้ดที่ชาญฉลาด ผู้ช่วย AI สามารถเข้าถึงโค้ดเวอร์ชันปัจจุบันของผู้เข้าร่วมได้ และสามารถสร้างโค้ดที่ถูกต้องและสมบูรณ์สำหรับทั้งสองโจทย์ได้โดยตรงเมื่อได้รับการร้องขอ
4.2 การออกแบบการประเมิน (Evaluation Design)
อ้างอิงจากการวิเคราะห์เมตา (Meta-analysis) ของการประเมินผลในการศึกษาวิทยาการคอมพิวเตอร์ก่อนหน้านี้ [Cheng et al., 2022] เราได้ระบุคำถาม 4 ประเภทที่ใช้เพื่อวัดความเชี่ยวชาญในทักษะการเขียนโค้ด เมื่อย้อนกลับไปที่แรงจูงใจเริ่มแรกของเราในการพัฒนาและรักษาทักษะที่จำเป็นสำหรับการกำกับดูแลระบบอัตโนมัติ ความเชี่ยวชาญในบางด้านอาจมีความสำคัญมากกว่าด้านอื่นๆ สำหรับการตรวจสอบโค้ดที่สร้างโดย AI โดยคำถาม 4 ประเภทที่เราพิจารณามีดังต่อไปนี้
- • Debugging: ความสามารถในการระบุและวินิจฉัยข้อผิดพลาดในโค้ด ทักษะนี้มีความสำคัญอย่างยิ่งในการตรวจจับเมื่อโค้ดที่สร้างโดย AI ไม่ถูกต้อง และเพื่อทำความเข้าใจว่าทำไมมันถึงล้มเหลว
- • การอ่านโค้ด (Code Reading): ความสามารถในการอ่านและทำความเข้าใจว่าโค้ดนั้นทำงานอะไร ทักษะนี้ช่วยให้มนุษย์สามารถเข้าใจและตรวจสอบโค้ดที่ AI เขียนขึ้นก่อนที่จะนำไป Deploy
- • การเขียนโค้ด (Code Writing): ความสามารถในการเขียนหรือเลือกวิธีที่ถูกต้องในการเขียนโค้ด การเขียนโค้ดในระดับต่ำ (Low-level) เช่น การจำไวยากรณ์ (Syntax) ของฟังก์ชัน จะมีความสำคัญน้อยลงเมื่อมีการรวมเครื่องมือเขียนโค้ดด้วย AI เข้ามามากขึ้น เมื่อเทียบกับการออกแบบระบบในระดับสูง (High-level system design)
- • เชิงมโนทัศน์ (Conceptual): ความสามารถในการทำความเข้าใจหลักการหลักเบื้องหลังเครื่องมือและ Library ต่างๆ ความเข้าใจเชิงมโนทัศน์เป็นสิ่งสำคัญในการประเมินว่าโค้ดที่สร้างโดย AI นั้นใช้รูปแบบการออกแบบ (Design patterns) ที่เหมาะสมและสอดคล้องกับวิธีการที่ Library นั้นควรถูกใช้งานหรือไม่
โจทย์ทั้งสองในการศึกษาของเราครอบคลุม 7 มโนทัศน์หลักจาก Trio library เราได้ออกแบบควิซที่มีคำถามด้าน Debugging การอ่านโค้ด และคำถามเชิงมโนทัศน์ซึ่งครอบคลุมทั้ง 7 มโนทัศน์นี้ เราได้ตัดคำถามเกี่ยวกับการเขียนโค้ดออกเพื่อลดผลกระทบของข้อผิดพลาดทางไวยากรณ์ (Syntax errors) ในการประเมินผลของเรา เนื่องจากข้อผิดพลาดเหล่านี้สามารถแก้ไขได้ง่ายผ่านการถาม AI หรือการค้นหาทางเว็บ เราได้ทดสอบควิซ 5 เวอร์ชัน (ตารางที่ 2) ในการทดสอบกับผู้ใช้และการศึกษาเบื้องต้นโดยอิงตามทฤษฎีการตอบสนองข้อสอบ (Item Response Theory) ตัวอย่างเช่น เราได้ตรวจสอบให้แน่ใจว่าคำถามทุกข้อมีความสัมพันธ์กับคะแนนควิซโดยรวมอย่างเพียงพอ แต่ละคำถามมีคะแนนเฉลี่ยที่เหมาะสม และคำถามถูกแยกส่วนเพื่อไม่ให้เกิดความสัมพันธ์ระหว่างข้อ (Local item dependence) (กล่าวคือ ผู้เข้าร่วมไม่สามารถคาดเดาคำตอบของข้อหนึ่งได้จากการดูคำถามข้ออื่นๆ) การประเมินผลสุดท้ายที่เราใช้นั้นประกอบด้วย 14 คำถาม รวมคะแนนเต็ม 27 คะแนน และเราได้ยื่นเกณฑ์การให้คะแนน (Grading rubric) สำหรับควิซนี้ในการลงทะเบียนการศึกษาล่วงหน้า (Pre-registration) ก่อนที่จะเริ่มทำการทดลอง
4.3 การออกแบบการศึกษา (Study Design)
ภาพที่ 4: ภาพรวมของโจทย์การเรียนรู้และการตรวจสอบความเข้าใจ: ผู้เข้าร่วมทุกคนทำโจทย์ Warm-up สำหรับการเขียนโค้ดที่ไม่ต้องใช้ความรู้เกี่ยวกับ Trio ในช่วงโจทย์หลักของ Trio ผู้เข้าร่วมในกลุ่มทดลอง (Treatment group) สามารถใช้ความช่วยเหลือจาก AI เพื่อตอบคำถามหรือสร้างโค้ดได้ ผู้เข้าร่วมทุกคนไม่ได้รับอนุญาตให้ใช้ AI ในช่วงการตรวจสอบความเข้าใจ (Comprehension check)
เราได้ใช้การทดลองแบบสุ่มระหว่างกลุ่ม (Between-subjects randomized experiment) เพื่อทดสอบผลกระทบของการใช้ AI ในกระบวนการสร้างทักษะการเขียนโค้ด ผู้เข้าร่วมแต่ละคนจะเริ่มจากการทำโจทย์ Warm-up สำหรับการเขียนโค้ดบนแพลตฟอร์ม ซึ่งพวกเขาจำเป็นต้องเพิ่มเส้นขอบล้อมรอบลิสต์ของข้อความ โจทย์การเขียนโค้ดภาษา Python นี้ใช้เวลาเฉลี่ยประมาณ 4 นาทีในการทำเสร็จในกลุ่มผู้ใช้งานแพลตฟอร์มนี้ และไม่มีมโนทัศน์เรื่อง Asynchronous เกี่ยวข้องในโจทย์นี้ ผู้เข้าร่วมทุกคนไม่สามารถเข้าถึง AI ได้ในขณะที่ทำขั้นตอน Warm-up โดยเราใช้ขั้นตอนนี้เพื่อปรับเทียบความคุ้นเคยกับภาษา Python ของผู้เข้าร่วม และช่วยให้ผู้เข้าร่วมคุ้นเคยกับอินเทอร์เฟซการใช้งาน
ขั้นตอนถัดไปคือช่วงโจทย์ Trio ซึ่งผู้เข้าร่วมจะมีเวลาสูงสุด 35 นาทีในการทำโจทย์การเขียนโค้ด 2 ข้อโดยใช้ Trio บนแพลตฟอร์มเดียวกัน ในขั้นตอนนี้ ผู้เข้าร่วมในเงื่อนไขกลุ่มที่ใช้ AI ช่วยเหลือ (Treatment group) จะสามารถเข้าถึงความช่วยเหลือในการเขียนโค้ดผ่านผู้ช่วย AI แบบแชท (ภาพที่ 3) โดยผู้เข้าร่วมทุกคนได้รับคำสั่งให้ทำโจทย์ให้เสร็จสิ้นให้เร็วที่สุดเท่าที่จะทำได้
หลังจากทำโจทย์ Trio เสร็จสิ้น ผู้เข้าร่วมจะเข้าสู่ขั้นตอนการประเมินผล ซึ่งพวกเขาจะต้องทำควิซที่เราได้อธิบายไว้ในหัวข้อก่อนหน้า และทำแบบสำรวจที่ประกอบด้วยคำถามเกี่ยวกับข้อมูลประชากรและประสบการณ์หลังจากทำควิซเสร็จสิ้น
ในการศึกษาหลักของเรา มีผู้เข้าร่วม 52 คนที่ทำโจทย์เสร็จสิ้น โดยแบ่งเป็นกลุ่มควบคุม (Control group) 26 คน และกลุ่มทดลอง (Treatment group) 26 คน สำหรับการศึกษาเบื้องต้นและการศึกษาหลักทั้งหมด เราคัดเลือกเฉพาะผู้เข้าร่วมที่รายงานด้วยตนเองว่ามีประสบการณ์การใช้ภาษา Python มากกว่าหนึ่งปี เขียนโค้ดด้วย Python อย่างน้อยสัปดาห์ละครั้ง เคยลองใช้ความช่วยเหลือในการเขียนโค้ดด้วย AI มาแล้วอย่างน้อยสองสามครั้ง และไม่เคยใช้ Library Trio มาก่อน (ตารางที่ 1)
| กลุ่มทดลอง (Treatment) (%) | กลุ่มควบคุม (Control) (%) | ส่วนต่าง (Difference) (%) | ||
|---|---|---|---|---|
| ปีประสบการณ์การเขียนโค้ด | ||||
| 1-3 ปี | 2 (0.077) | 2 (0.077) | 0 | |
| 4-6 ปี | 10 (0.385) | 9 (0.346) | 1 (0.038) | |
| 7 ปีขึ้นไป | 14 (0.538) | 15 (0.577) | 1 (0.038) | |
| ความถี่ในการใช้ Python | ||||
| สม่ำเสมอ / บ่อยครั้ง | 18 (0.692) | 16 (0.615) | 2 (0.077) | |
| ทุกวัน / อย่างกว้างขวาง | 8 (0.308) | 10 (0.385) | 2 (0.077) | |
| คะแนนควิซ Async รายโจทย์ | ||||
| 0-2 (0-40%) | 5 (0.192) | 5 (0.192) | 0 | |
| 3-4 (60-80%) | 18 (0.692) | 15 (0.577) | 3 (0.115) | |
| 5 (100%) | 3 (0.115) | 6 (0.231) | 3 (0.115) | |
| การใช้ Python Asyncio มาก่อน | 18 (0.692) | 20 (0.769) | 2 (0.077) | |
| เวลาที่ใช้เขียนโค้ดก่อนเริ่ม (Pre-Task) | 6.5 นาที | 8 นาที | 1.5 นาที |
ตารางที่ 1: ตารางความสมดุล (Balance table) ของผู้เข้าร่วมในการศึกษาหลัก (n=52)
เราใช้แพลตฟอร์มการเขียนโค้ดเพื่อเก็บข้อมูลการกดแป้นพิมพ์ (Keystrokes) ของผู้ใช้ในขณะที่พวกเขาเขียนโค้ด และบันทึกบทสนทนา (Transcripts) ของการปฏิสัมพันธ์กับผู้ช่วยเขียนโค้ดด้วย AI ในกลุ่มทดลอง เราใช้ Google Forms เพื่อรวบรวมการตอบแบบสำรวจจากผู้ใช้ทั้งก่อนและหลังการทำโจทย์การเขียนโค้ด โดยรวมแล้ว งานเหล่านี้ใช้เวลาสูงสุด 1 ชั่วโมง 15 นาที โดยมีระยะเวลาเฉลี่ยอยู่ที่ 58.5 นาที ผู้เข้าร่วมถูกคัดเลือกผ่านแพลตฟอร์ม Crowd-worker ภายนอก และได้รับค่าตอบแทนในอัตราเหมาจ่ายที่ 150 ดอลลาร์สหรัฐฯ สำหรับการทำงานนี้
5 ผลลัพธ์ (Results)
5.1 การศึกษาเบื้องต้น (Pilot Studies)
| แพลตฟอร์ม | ผู้เข้าร่วม | จำนวนโจทย์ | อุปสรรคและความท้าทาย | |
|---|---|---|---|---|
| Pilot A | P1 | n=39 | 5 | การไม่ปฏิบัติตามกฎ (Non-Compliance): 35% ของผู้เข้าร่วมในกลุ่มที่ห้ามใช้ AI กลับใช้ AI ช่วยในการก๊อปปี้คำแนะนำและวางผลลัพธ์ นอกจากนี้ผู้เข้าร่วมยังรายงานด้วยตนเองว่ามีการใช้ AI ในกลุ่มห้ามใช้อีกด้วย |
| Pilot B | P1 | n=107 | 5 | การไม่ปฏิบัติตามกฎอย่างต่อเนื่อง: แม้จะมีการเตือนเรื่องกฎการห้ามใช้ AI อย่างเข้มงวด แต่ผู้เข้าร่วม 25% ยังคงใช้ AI ทั้งในการเขียนโค้ดและทำควิซ และแพลตฟอร์มที่ใช้ไม่มีตัวเลือกให้บันทึกหน้าจอ |
| Pilot C | P2 | n=20 | 5 | ความสัมพันธ์ระหว่างข้อสอบ (Local Item Dependence): จากการดูบันทึกหน้าจอ เราพบว่าผู้เข้าร่วมเลื่อนดูคำถามไปมาเพื่อเดาคำตอบที่ถูกต้องจากข้อมูลในข้ออื่นๆ |
| Pilot D | P2 | n=20 | 2 | ความล่าช้าจากไวยากรณ์ Python: ภายในเวลา 35 นาที มีเพียง 60% ของกลุ่มควบคุม (กลุ่มไม่ใช้ AI) ที่ทำโจทย์เสร็จทั้งสองข้อ บันทึกหน้าจอแสดงให้เห็นว่าผู้เข้าร่วมหลายคนติดปัญหาเรื่องไวยากรณ์ Python เช่น บล็อก try/except และการจัดรูปแบบ String ซึ่งปัญหาเหล่านี้ไม่เกี่ยวข้องโดยตรงกับ Library Trio |
ตารางที่ 2: สรุปผลการศึกษาเบื้องต้น (Pilot studies) ด้วยผู้ให้บริการข้อมูล โจทย์ และการออกแบบการประเมินที่แตกต่างกัน
การไม่ปฏิบัติตามกฎ (Non-Compliance): เราได้ทำการศึกษาเบื้องต้น 4 ครั้งก่อนที่จะเริ่มการศึกษาฉบับเต็ม (ตารางที่ 2) โดยการศึกษาเบื้องต้นสองครั้งแรกทำบนแพลตฟอร์ม Crowdworking แห่งแรก (P1) ซึ่งเราพบระดับการไม่ปฏิบัติตามกฎที่สูงมาก (35%) ทั้งในช่วงการทำโจทย์และช่วงทำควิซ (กล่าวคือ ผู้เข้าร่วมใช้ AI เพื่อทำโจทย์การเขียนโค้ดในกลุ่มควบคุม หรือใช้ AI เพื่อทำควิซประเมินผล) เราสังเกตเห็นพฤติกรรมการไม่ปฏิบัติตามกฎผ่านบันทึกในแพลตฟอร์มเขียนโค้ด ในช่วงที่ผู้ใช้ก๊อปปี้คำแนะนำหรือวางโค้ดลงใน Editor เราได้ทดสอบกลไกต่างๆ เพื่อให้แน่ใจว่าผู้เข้าร่วมในเงื่อนไขกลุ่มควบคุม (ไม่ใช้ AI) จะไม่ใช้ AI ในการทำโจทย์ แต่ถึงแม้จะมีคำแนะนำที่ชัดเจนขึ้น ผู้เข้าร่วมในกลุ่มควบคุมประมาณ 25% ก็ยังคงใช้ AI เราจึงได้จัดทำทางการศึกษาเบื้องต้นอีกสองครั้งด้วยแพลตฟอร์ม Crowdworking แห่งที่สอง (P2) โดยแต่ละครั้งมีผู้เข้าร่วม 20 คน และด้วยการใช้การบันทึกหน้าจอเพื่อดูความคืบหน้าของผู้เข้าร่วม เราจึงสามารถยืนยันได้ว่าผู้เข้าร่วมไม่ได้ใช้ AI ในกลุ่มควบคุมและในช่วงการทำควิซ
ความสัมพันธ์ระหว่างข้อสอบ (Local Item Dependence): ในการศึกษาเบื้องต้น C เราสังเกตเห็นปัญหาความสัมพันธ์ระหว่างข้อสอบในควิซ โดยผู้เข้าร่วมมักจะเปรียบเทียบคำถามและหาคำตอบจากตัวอย่างโค้ดที่ให้ไว้ในคำถามข้ออื่นๆ สิ่งนี้ทำให้เราตัดสินใจแยกควิซออกเป็นหลายๆ หน้า โดยคำถามในแต่ละหน้าจะต้องไม่มีการให้คำใบ้สำหรับคำถามในหน้าอื่น จากการตรวจสอบบันทึกหน้าจอ เราพบว่าวิธีนี้ช่วยลดปัญหาความสัมพันธ์ระหว่างข้อสอบได้ในการศึกษาเบื้องต้น D นอกจากนี้ เรายังได้ลดจำนวนโจทย์ทั้งหมดจาก 5 ข้อเหลือเพียง 2 ข้อ การเปลี่ยนแปลงนี้ช่วยให้เราสามารถแยกแยะการเรียนรู้จาก 2 โจทย์แรกได้ดีขึ้น พร้อมทั้งกำจัดตัวแปรแทรกซ้อน (Confounding variable) ที่ว่าผู้เข้าร่วมในกลุ่ม AI อาจจะได้เห็นมโนทัศน์มากกว่าเพียงเพราะพวกเขาทำโจทย์เสร็จมากกว่าภายในเวลาที่กำหนด และเพื่อให้ควิซสอดคล้องกับการแก้ไขนี้ เราจึงได้ปรับปรุงคำถามในควิซให้ครอบคลุมเฉพาะเนื้อหาจาก 2 โจทย์แรกเท่านั้น
ภาพที่ 5: ความแตกต่างของค่าเฉลี่ยเวลาในการทำโจทย์ทั้งหมดและคะแนนควิซ ระหว่างกลุ่มควบคุม (ไม่ใช้ AI) และกลุ่มทดลอง (ใช้ผู้ช่วย AI) ในการศึกษาเบื้องต้น D เส้น Error bars แทนช่วงความเชื่อมั่น 95% (95% CI) ค่าระดับนัยสำคัญสอดคล้องกับผลของกลุ่มทดลอง * p<0.05, **<0.01, ***<0.001
อุปสรรคต่อการทำงานให้เสร็จสิ้น (Barriers to Task Completion): ในการศึกษาเบื้องต้น D เรามีผู้เข้าร่วม 20 คน เราพบความแตกต่างอย่างมีนัยสำคัญทั้งในเรื่องเวลาที่ใช้ทำโจทย์และคะแนนควิซระหว่างเงื่อนไขที่ใช้ AI และไม่ใช้ AI (ภาพที่ 5) เมื่อเราตรวจสอบบันทึกหน้าจอ พบว่าผู้เข้าร่วมในกลุ่มควบคุม (ไม่ใช้ AI) ประสบปัญหาเกี่ยวกับไวยากรณ์ Python ที่ไม่เกี่ยวข้องกับ Trio เช่น บล็อก try/except และการจัดรูปแบบ String อัตราการทำโจทย์เสร็จสิ้นภายในเวลา 35 นาทีของกลุ่มควบคุมอยู่ที่เพียง 60% เมื่อเทียบกับอัตรา 90% ในกลุ่มทดลอง (ใช้ AI) เนื่องจากเป้าหมายของเราไม่ได้อยู่ที่การทดสอบไวยากรณ์ Python เราจึงได้เพิ่มคำใบ้เกี่ยวกับไวยากรณ์สำหรับการจัดรูปแบบ String และบล็อก try/except ในการศึกษาหลัก
ภาพที่ 5 แสดงผลของกลุ่มทดลองต่อทั้งสองตัววัด: เวลาในการทำโจทย์ และคะแนนควิซ กลุ่มทดลอง (ใช้ AI) ทำโจทย์ Trio เสร็จเร็วกว่า (Cohen’s $d=1.11$, $p=0.03$) ซึ่งแสดงถึงประสิทธิภาพในการทำงานที่เพิ่มขึ้น อย่างไรก็ตาม กลุ่มที่ใช้ AI กลับทำคะแนนควิซวัดความรู้ได้แย่กว่าอย่างมีนัยสำคัญ (Cohen’s $d=1.7$, $p=0.003$) ซึ่งบ่งชี้ถึงการลดลงของการจดจำการเรียนรู้ (Retention of learning) สำหรับการวิเคราะห์พลังการทดสอบ (Power analysis) ฉบับสมบูรณ์และการลงทะเบียนล่วงหน้าของการศึกษา [2] เราได้สมมติขนาดผลกระทบ (Effect size) แบบระมัดระวังอยู่ที่ $d=0.85$ (ครึ่งหนึ่งของผลการเรียนรู้ที่สังเกตได้) เพื่อชดเชยการขยายตัวของขนาดผลกระทบที่มักจะเกิดขึ้นในการศึกษาเบื้องต้น
[2] Pre-registration: https://osf.io/w49e7
5.2 การศึกษาหลัก (Main Study)
5.2.1 ผู้เข้าร่วม (Participants)
เพื่อให้ได้ผู้เข้าร่วม 50 คน เราได้ส่งโจทย์การศึกษาของเราให้กับ Crowd worker 58 คน ผู้เข้าร่วมได้รับการคัดเลือกให้มีความสมดุลในคุณสมบัติต่างๆ (ซึ่งรวบรวมผ่านแบบสำรวจการรับสมัครแยกต่างหาก) ได้แก่: ปีประสบการณ์การเขียนโค้ด ปีประสบการณ์การใช้ Python การเคยใช้งาน Python Asyncio library มาก่อน ความถี่ในการใช้ Python ในปีที่ผ่านมา และคะแนนความคุ้นเคยกับการเขียนโปรแกรมแบบ Asynchronous (จากการทำคำถามเช็กมโนทัศน์แบบปรนัย 5 ข้อ) รายละเอียดข้อมูลประชากรของผู้เข้าร่วม ซึ่งถูกรวบรวมหลังจากทำโจทย์เสร็จเพื่อหลีกเลี่ยงผลกระทบจากอคติทางความคิด (Stereotype threat) ได้ถูกสรุปไว้ในภาพที่ 17 ผู้เข้าร่วมส่วนใหญ่ในการศึกษาของเราจบการศึกษาระระดับปริญญาตรี มีอายุระหว่าง 25 ถึง 35 ปี และทำงานเป็นนักพัฒนาซอฟต์แวร์ทั้งแบบอิสระ (Freelance) หรือแบบมืออาชีพ (Professional) มีผู้เข้าร่วมทั้งหมด 53 คนที่ทำครบทั้งสามส่วนของการศึกษา และตามเกณฑ์การตัดสิทธิ์ที่เราได้ลงทะเบียนล่วงหน้าไว้ มีผู้เข้าร่วม 1 คนถูกตัดสิทธิ์เนื่องจากเว้นว่างคำถามในควิซไว้ 4 ข้อ เพราะไม่ทราบว่าควิซมีหลายส่วนและทำให้ทำเวลาไม่ทันในภายหลัง
ภาพที่ 6: ความแตกต่างของค่าเฉลี่ยเวลาในการทำโจทย์ทั้งหมดและคะแนนควิซ ระหว่างกลุ่มควบคุม (ไม่ใช้ AI) และกลุ่มทดลอง (ใช้ผู้ช่วย AI) ในการศึกษาหลัก (n=52) เส้น Error bars แทนช่วงความเชื่อมั่น 95% (95% CI) ค่าระดับนัยสำคัญสอดคล้องกับผลของกลุ่มทดลอง * p<0.05, **<0.01, ***<0.001
5.2.2 ผลลัพธ์ (Results)
ภาพที่ 6 แสดงให้เห็นว่า แม้การใช้ AI เพื่อทำโจทย์การเขียนโค้ดของเราจะไม่ได้ช่วยปรับปรุงเวลาในการทำงานให้เสร็จสิ้นได้อย่างมีนัยสำคัญ แต่ระดับการสร้างทักษะที่ได้รับจากการทำโจทย์ ซึ่งวัดโดยควิซของเรานั้น กลับลดลงอย่างมีนัยสำคัญ (Cohen $d=0.738$, $p=0.01$) โดยมีความแตกต่างถึง 4.15 คะแนนระหว่างค่าเฉลี่ยของกลุ่มทดลองและกลุ่มควบคุม สำหรับควิซที่มีคะแนนเต็ม 27 คะแนน สิ่งนี้แปลได้ว่าเป็นความแตกต่างของคะแนนถึง 17% หรือประมาณ 2 เกรด และเมื่อควบคุมเวลาที่ใช้ในโจทย์ Warm-up เป็นตัวแปรควบคุม (Covariate) ผลของกลุ่มทดลองก็ยังคงมีนัยสำคัญ (Cohen’s $d=0.725$, $p=0.016$)
งานวิจัยก่อนหน้านี้ได้ให้ผลลัพธ์ที่ผสมกันว่า AI ช่วยส่งเสริมหรือขัดขวาง Productivity ในการเขียนโค้ด [Peng et al., 2023, Becker et al., 2025] การศึกษาของเราแตกต่างจากผลงานก่อนหน้าตรงที่มันถูกออกแบบมาเพื่อศึกษาว่า AI ส่งผลต่อการสร้างทักษะอย่างไรในขณะที่กำลังทำโจทย์ที่ต้องการความรู้ใหม่ แม้ว่าเราจะสังเกตเห็นเวลาเฉลี่ยในการทำงานที่ลดลงเล็กน้อยในกลุ่มโปรแกรมเมอร์มือใหม่ที่ใช้ AI แต่เนื่องจากขนาดของกลุ่มตัวอย่างที่มีประสบการณ์ 1-3 ปีนั้นค่อนข้างเล็ก ($n=4$) ความแตกต่างในเวลาที่ใช้ทำโจทย์จึงไม่มีนัยสำคัญ มีผู้เข้าร่วม 4 จาก 26 คนในกลุ่มควบคุม (ไม่ใช้ AI) ที่ทำโจทย์ที่สองไม่เสร็จภายในเวลา 35 นาที ในขณะที่ผู้เข้าร่วมทุกคนในเงื่อนไขกลุ่มที่ใช้ AI สามารถทำโจทย์ที่สองเสร็จสิ้นได้ทั้งหมด ผลลัพธ์ของเราจึงยังไม่สามารถสรุปได้อย่างชัดเจนว่าการใช้ AI ในโจทย์นี้ช่วยให้ทำงานเร็วขึ้นหรือช้าลง
ภาพที่ 7: เวลาที่ใช้ทำโจทย์และคะแนนควิซแบ่งตามปีประสบการณ์การเขียนโค้ด เส้น Error bars แทนช่วงความเชื่อมั่น 95% (95% CI) คะแนนควิซเฉลี่ยของกลุ่มควบคุม (ไม่ใช้ AI) นั้นสูงกว่าในทุกระดับของประสบการณ์การเขียนโค้ด
ในทุกระดับของประสบการณ์การเขียนโค้ดก่อนหน้า ผู้ใช้งานในกลุ่มควบคุม (ไม่ใช้ AI) มีคะแนนเฉลี่ยสูงกว่ากลุ่มทดลอง (ใช้ AI) (ภาพที่ 7) สิ่งนี้แสดงให้เห็นว่า การเลือกโจทย์และการออกแบบโจทย์ของเราไม่ได้ขึ้นอยู่กับระดับประสบการณ์ของผู้เข้าร่วมเป็นสำคัญ แต่เป็นการนำเสนอทักษะใหม่ๆ ที่ต้องเรียนรู้สำหรับผู้เข้าร่วมในทุกกลุ่มประสบการณ์
ภาพที่ 8: รายละเอียดคะแนนแบ่งตามประเภทของคำถามที่เกี่ยวข้องกับแต่ละโจทย์และสาขาทักษะ คำถามด้าน Debugging แสดงให้เห็นถึงความแตกต่างของคะแนนควิซเฉลี่ยที่มากที่สุดระหว่างกลุ่มทดลองและกลุ่มควบคุม
การวิเคราะห์ตามกลุ่มมโนทัศน์ (Concept Group Analysis): ในการวิเคราะห์ข้อมูลเชิงสำรวจ (ซึ่งไม่ได้ลงทะเบียนไว้ล่วงหน้า) คะแนนควิซถูกแบ่งย่อยออกตามสาขาย่อยและประเภทของคำถาม (ภาพที่ 8) คำถามแต่ละข้อในควิซจะจัดอยู่ในโจทย์ข้อใดข้อหนึ่งโดยเฉพาะ (เช่น โจทย์ที่ 1 หรือ โจทย์ที่ 2) และจัดอยู่ในประเภทคำถามประเภทใดประเภทหนึ่งโดยเฉพาะ (เช่น เชิงมโนทัศน์, Debugging หรือการอ่านโค้ด) สำหรับทั้งสองโจทย์ พบว่ามีช่องว่างระหว่างคะแนนควิซของกลุ่มทดลองและกลุ่มควบคุม โดยในบรรดาประเภทคำถามที่แตกต่างกัน ช่องว่างของคะแนนที่ใหญ่ที่สุดเกิดขึ้นในคำถามด้าน Debugging และช่องว่างที่เล็กที่สุดอยู่ในคำถามด้านการอ่านโค้ด ผลลัพธ์นี้เป็นไปตามที่คาดการณ์ไว้ เนื่องจากทั้งกลุ่มทดลองและกลุ่มควบคุมอาจได้รับประสบการณ์ในการอ่านโค้ดผ่านโจทย์ที่ใกล้เคียงกัน แต่กลุ่มควบคุมที่ไม่สามารถเข้าถึงความช่วยเหลือจาก AI ได้นั้น ต้องเผชิญกับข้อผิดพลาด (Errors) มากกว่าในระหว่างการทำโจทย์ และทำให้มีความสามารถในการ Debugging มากขึ้น
ภาพที่ 9: ความสนุกและการเรียนรู้ที่รายงานด้วยตนเองแยกตามเงื่อนไขในระหว่างการศึกษาของเรา
ภาพที่ 10: ความยากของโจทย์ที่รายงานด้วยตนเองแยกตามเงื่อนไขในช่วงต่างๆ ของการศึกษาของเรา
ประสบการณ์ในการทำโจทย์ (Task Experience): ในการวิเคราะห์ข้อมูลเชิงสำรวจเพิ่มเติม เรายังพบความแตกต่างในวิธีที่ผู้เข้าร่วมมีประสบการณ์ต่อการทำโจทย์การศึกษาให้เสร็จสิ้น กลุ่มควบคุม (ไม่ใช้ AI) รายงานการเรียนรู้ที่สูงกว่า (วัดจากมาตรวัด 7 ระดับ) ในขณะที่ทั้งสองกลุ่มรายงานระดับความสนุกในการทำโจทย์ที่สูง (ภาพที่ 10) ในแง่ของความยากของโจทย์ ภาพที่ 10 แสดงให้เห็นว่า แม้ผู้เข้าร่วมในกลุ่มทดลอง (ใช้ AI) จะพบว่าโจทย์นั้นง่ายกว่ากลุ่มควบคุม แต่ทั้งสองกลุ่มต่างพบว่าควิซหลังจบโจทย์นั้นมีความท้าทายในระดับที่ใกล้เคียงกัน
6 การวิเคราะห์เชิงคุณภาพ (Qualitative Analysis)
ภาพที่ 11: 6 บุคลิกภาพ (Personas) ของการปฏิสัมพันธ์กับ AI ในกลุ่มทดลอง (ใช้ AI) จากการศึกษาของเรา พร้อมเวลาเฉลี่ยในการทำโจทย์เสร็จและคะแนนควิซ
แม้ว่าสถิติโดยรวมเกี่ยวกับ Productivity และคะแนนควิซจะช่วยให้เห็นแนวโน้มในภาพกว้างว่าความช่วยเหลือจาก AI ส่งผลอย่างไรต่อโจทย์การเรียนรู้ใหม่ แต่การวิเคราะห์เชิงลึกว่าผู้เข้าร่วมแต่ละคนทำโจทย์นั้นเสร็จสิ้นได้อย่างไร จะช่วยให้เราเข้าใจความหลากหลาย (Heterogeneity) ของผู้เข้าร่วมได้ดีขึ้น ในขั้นตอนการกำหนดรหัส (Coding) เบื้องต้นของการวิเคราะห์เชิงคุณภาพ เราได้จดบันทึก (Annotated) บันทึกหน้าจอของผู้เข้าร่วม 51 คนในการศึกษาหลักด้วยตนเอง [3] เราจัดกลุ่มการจดบันทึกเป็นมโนทัศน์หลักหลายประการที่เกี่ยวข้องกับเหตุการณ์ความคืบหน้าของงาน เช่น ข้อผิดพลาด (Errors) การปฏิสัมพันธ์กับ AI คำสั่ง AI และการทำงานเสร็จสิ้น (ตารางที่ 5) การวิเคราะห์นี้ช่วยให้เราไม่เพียงแต่เข้าใจ Productivity และการเรียนรู้โดยรวมเท่านั้น แต่ยังรวมถึงวิธีที่ AI ถูกใช้งานในแต่ละโจทย์ในการศึกษาของเราอีกด้วย เราได้เผยแพร่บันทึกเหตุการณ์ (Annotated transcripts) เหล่านี้สู่สาธารณะเพื่อการศึกษาในอนาคต [4]
[3] ไม่พบการบันทึกหน้าจอของผู้เข้าร่วม 1 คนในเงื่อนไขกลุ่ม AI [4] รายละเอียดเกี่ยวกับขั้นตอนการจดบันทึกสามารถดูได้ในส่วนที่ B และบันทึกเหตุการณ์ได้ที่ https://github.com/safety-research/how-ai-impacts-skill-formation
การวิเคราะห์มโนทัศน์หรือรูปแบบทั่วไปเหล่านี้ในหมู่ผู้เข้าร่วม ช่วยเสริมการสังเกตเชิงปริมาณของเราเกี่ยวกับการสร้างทักษะและการทำโจทย์ให้เสร็จสิ้นใน Library ใหม่นี้ โดยเฉพาะอย่างยิ่ง แกน (Axes) ต่อไปนี้ที่แสดงให้เห็นถึงความแตกต่างระหว่างผู้เข้าร่วมและข้ามเงื่อนไขต่างๆ:
- • เวลาที่ใช้ปฏิสัมพันธ์กับ AI (AI Interaction Time): การที่กลุ่มที่ใช้ AI ไม่มีความเร็วในการทำงานเพิ่มขึ้นอย่างมีนัยสำคัญ สามารถอธิบายได้ด้วยวิธีที่ผู้เข้าร่วมบางคนใช้ AI โดยมีผู้เข้าร่วมหลายคนใช้เวลาจำนวนมากในการปฏิสัมพันธ์กับผู้ช่วย AI ซึ่งบางคนใช้เวลาถึง 11 นาทีในการพิมพ์คำสั่ง AI รวมทั้งหมด (ภาพที่ 12)
- • ประเภทของคำสั่ง (Query Types): ผู้เข้าร่วมมีการตั้งคำถามที่หลากหลาย ตั้งแต่คำถามเชิงมโนทัศน์เท่านั้น การขอให้สร้างโค้ดเท่านั้น ไปจนถึงการผสมผสานระหว่างคำถามเชิงมโนทัศน์ การ Debugging และการสร้างโค้ด โดยผู้เข้าร่วมที่มุ่งเน้นไปที่การถามคำถามด้าน Debugging หรือขอให้ยืนยันคำตอบมักจะใช้เวลาในงานมากกว่า (ภาพที่ 19)
- • การพบข้อผิดพลาด (Encountering Errors): ผู้เข้าร่วมในกลุ่มควบคุม (ไม่ใช้ AI) พบข้อผิดพลาดมากกว่า ซึ่งรวมถึงทั้งข้อผิดพลาดทางไวยากรณ์ (Syntax) และข้อผิดพลาดที่เกี่ยวกับ
Trio(ภาพที่ 15) การพบข้อผิดพลาดที่มากกว่าและการต้องแก้ไขด้วยตนเอง น่าจะเป็นส่วนสำคัญที่ช่วยส่งเสริมการสร้างทักษะเกี่ยวกับTrio - • เวลาที่ลงมือจริง (Active Time): การใช้ AI ช่วยลดปริมาณเวลาที่ใช้ในการเขียนโค้ดจริงๆ (Active coding time) ลง โดยเวลาที่เคยใช้ในการเขียนโค้ดถูกเปลี่ยนไปเป็นเวลาที่ใช้ในการปฏิสัมพันธ์กับ AI และการทำความเข้าใจสิ่งที่ AI สร้างขึ้น (ภาพที่ 16)
ด้วยการใช้แกนความแตกต่างเหล่านี้ เราได้สร้างการจัดประเภท (Typology) ของรูปแบบการปฏิสัมพันธ์กับ AI 6 รูปแบบ โดยพิจารณาจากประเภทของคำสั่ง จำนวนคำสั่ง ปริมาณคำสั่งต่อโจทย์ และเวลาที่ลงมือทำจริง ผลลัพธ์จากการจัดหมวดหมู่นี้พบว่า รูปแบบทั้ง 6 ประการนี้ให้ผลลัพธ์ที่แตกต่างกันทั้งในด้านเวลาที่ใช้ทำงานและคะแนนการสร้างทักษะ (เช่น คะแนนควิซ) ภาพที่ 11 ได้สรุปแต่ละรูปแบบและผลลัพธ์เฉลี่ยของงานเอาไว้ เราสามารถแบ่งรูปแบบการปฏิสัมพันธ์ออกเป็น 2 หมวดหมู่หลัก: รูปแบบการปฏิสัมพันธ์ที่ได้คะแนนต่ำ และรูปแบบที่ได้คะแนนสูง โดยรูปแบบที่ได้คะแนนสูงมักจะเกี่ยวข้องกับการใช้ความพยายามทางความคิดที่มากกว่า และมีการพึ่งพา AI น้อยกว่า แม้ว่ากลุ่มตัวอย่างของแต่ละรูปแบบพฤติกรรมจะมีขนาดเล็ก แต่ความแตกต่างระหว่างกลุ่มที่ได้คะแนนต่ำและคะแนนสูงนั้นมีความชัดเจนอย่างมาก
รูปแบบการปฏิสัมพันธ์ที่ได้คะแนนต่ำ (Low-Scoring Interaction Patterns): รูปแบบที่ได้คะแนนต่ำมักเกี่ยวข้องกับการพึ่งพา AI อย่างหนัก ไม่ว่าจะเป็นผ่านการสร้างโค้ดหรือการ Debugging คะแนนควิซเฉลี่ยในกลุ่มเหล่านี้มักจะน้อยกว่า 40% ผู้เข้าร่วมที่แสดงรูปแบบการปฏิสัมพันธ์เหล่านี้มีการใช้ความคิดที่เป็นอิสระน้อยลง และมีการลดภาระทางความคิด (Cognitive offloading) มากขึ้น [Lee et al., 2025]
- • การมอบหมายงานให้ AI (AI Delegation) ($n=4$): ผู้เข้าร่วมในกลุ่มนี้พึ่งพา AI ทั้งหมดในการเขียนโค้ดและทำให้โจทย์เสร็จสิ้น กลุ่มนี้ทำงานเสร็จเร็วที่สุดและพบข้อผิดพลาดน้อยมากหรือไม่มีเลยในระหว่างกระบวนการ
- • การพึ่งพา AI เพิ่มขึ้นตามลำดับ (Progressive AI Reliance) ($n=4$): ผู้เข้าร่วมในกลุ่มนี้เริ่มต้นด้วยการถามคำถาม 1 หรือ 2 ข้อ และในที่สุดก็มอบหมายการเขียนโค้ดทั้งหมดให้ผู้ช่วย AI กลุ่มนี้ได้คะแนนควิซต่ำ สาเหตุหลักมาจากการไม่ได้ทำความเข้าใจมโนทัศน์ใดๆ เลยในโจทย์ที่สอง
- • การ Debugging ด้วย AI ซ้ำๆ (Iterative AI Debugging) ($n=4$): ผู้เข้าร่วมในกลุ่มนี้พึ่งพา AI ในการ Debug หรือตรวจสอบโค้ดของตนเอง กลุ่มนี้ส่งคำสั่งจำนวนมากไปยังผู้ช่วย AI แต่พึ่งพาผู้ช่วยเพื่อแก้ปัญหา มากกว่าที่จะทำความเข้าใจให้กระจ่างด้วยตนเอง ส่งผลให้พวกเขาได้คะแนนควิซต่ำและทำงานเสร็จค่อนข้างช้ากว่าในการทำโจทย์ทั้งสองข้อ
รูปแบบการปฏิสัมพันธ์ที่ได้คะแนนสูง (High-Scoring Interaction Patterns): รูปแบบที่ได้คะแนนสูงคือกลุ่มพฤติกรรมที่มีคะแนนควิซเฉลี่ยตั้งแต่ 65% ขึ้นไป ผู้เข้าร่วมในกลุ่มเหล่านี้ใช้ AI ทั้งสำหรับการสร้างโค้ด การถามคำถามเชิงมโนทัศน์ หรือทั้งสองอย่างรวมกัน
- • สร้างโค้ดแล้วทำความเข้าใจ (Generation-Then-Comprehension) ($n=2$): ผู้เข้าร่วมในกลุ่มนี้ให้ AI สร้างโค้ดขึ้นมาก่อน จากนั้นจึงก๊อปปี้หรือวางโค้ดลงในงานด้วยตนเอง หลังจากโค้ดถูกสร้างขึ้นแล้ว พวกเขาจะถามคำถามติดตามผล (Follow-up questions) กับผู้ช่วย AI เพื่อเพิ่มความเข้าใจ ผู้เข้าร่วมกลุ่มนี้ไม่ได้ทำงานรวดเร็วเป็นพิเศษเมื่อใช้ AI แต่แสดงให้เห็นถึงระดับความเข้าใจที่สูงในควิซ สิ่งสำคัญคือ วิธีการนี้ดูเกือบจะเหมือนกับกลุ่ม AI Delegation แต่มีการใช้ AI เพิ่มเติมเพื่อตรวจสอบความเข้าใจของตนเอง
- • สร้างโค้ดผสมคำอธิบาย (Hybrid Code-Explanation) ($n=3$): ผู้เข้าร่วมในกลุ่มนี้เขียนคำสั่งแบบผสม โดยขอให้สร้างโค้ดพร้อมกับขอคำอธิบายของโค้ดที่สร้างขึ้น การอ่านและทำความเข้าใจคำอธิบายที่พวกเขาขอมานั้นทำให้ต้องใช้เวลามากขึ้น
- • การสอบถามเชิงมโนทัศน์ (Conceptual Inquiry) ($n=7$): ผู้เข้าร่วมในกลุ่มนี้ถามเพียงคำถามเชิงมโนทัศน์เท่านั้น และพึ่งพาความเข้าใจที่เพิ่มขึ้นของตนเองเพื่อทำโจทย์ให้เสร็จสิ้น แม้ว่ากลุ่มนี้จะพบข้อผิดพลาดมากมาย แต่พวกเขาก็แก้ไขข้อผิดพลาดเหล่านั้นได้ด้วยตนเอง โดยเฉลี่ยแล้ว รูปแบบนี้รวดเร็วที่สุดในบรรดารูปแบบที่ได้คะแนนสูง และรวดเร็วเป็นอันดับสองรองจากกลุ่ม AI Delegation
6.1 การปฏิสัมพันธ์กับ AI (AI Interaction)
เวลาที่ใช้ปฏิสัมพันธ์ (Interaction Time)
สิ่งที่ขัดแย้งกับงานวิจัยก่อนหน้านี้ซึ่งพบว่าความช่วยเหลือจาก AI ช่วยเพิ่มความเร็วในการเขียนโค้ดได้อย่างมาก [Peng et al., 2023, Cui et al., 2024] ผลลัพธ์ของเรากลับไม่แสดงให้เห็นถึงการปรับปรุง Productivity ที่มีนัยสำคัญ หากเราพิจารณาเฉพาะเวลาที่ใช้ทำโจทย์จนเสร็จสิ้นทั้งหมดระหว่างกลุ่มทดลองและกลุ่มควบคุม จากการวิเคราะห์วิธีที่ผู้เข้าร่วมในเงื่อนไขกลุ่ม AI ทำโจทย์ให้เสร็จสิ้น พบว่าเหตุผลที่ Productivity ไม่ได้ดีขึ้นอย่างที่ควรจะเป็นนั้น มาจากเวลาที่ใช้ในการปฏิสัมพันธ์กับผู้ช่วย AI ผู้เข้าร่วมบางคนในกลุ่มทดลองใช้เวลาจำนวนมาก (สูงสุดถึง 11 นาที) ในการปฏิสัมพันธ์กับผู้ช่วย AI เช่น การพิมพ์หรือการคิดว่าจะพิมพ์อะไรลงไปดี เราเก็บข้อมูลเวลาที่ลงทุนไปกับการปฏิสัมพันธ์กับ AI โดยการระบุช่วงเวลาระหว่างเมื่อผู้ใช้เริ่มพิมพ์คำสั่ง (ซึ่งถูกบันทึกเป็นเหตุการณ์ AI Interaction) และเมื่อผู้ช่วย AI ให้คำตอบออกมา (ซึ่งถูกบันทึกเป็นเหตุการณ์ AI Query)
เนื่องจากผู้เข้าร่วมสามารถถามคำถามกับผู้ช่วย AI ได้มากเท่าที่ต้องการภายในเวลาที่กำหนด ผู้เข้าร่วมจำนวนหนึ่งจึงถามคำถามมากกว่า 5 ข้อ และใช้เวลาถึง 6 นาทีในการเขียนคำสั่งเพียงคำสั่งเดียวในช่วงการทำโจทย์ 35 นาทีนี้ (ภาพที่ 12) [5] เนื่องจากค่ามัธยฐาน (Median) ของเวลาที่ใช้ทำโจทย์เสร็จสิ้นในกลุ่มที่ใช้ AI นั้นอยู่ที่เพียง 19 นาที การใช้เวลาถึง 6 นาทีเพื่อเขียนคำสั่งเดียวจึงถือเป็นสัดส่วนที่สูงมากของเวลาทั้งหมดที่ใช้ปฏิสัมพันธ์กับผู้ช่วย AI แม้ว่าผลกระทบนี้อาจเกิดจากระยะเวลาที่สั้นของโจทย์ของเรา แต่ Becker et al. ก็พบผลกระทบที่ทำให้งานช้าลง (Slowdown effect) ในกลุ่มโปรแกรมเมอร์ระดับเชี่ยวชาญเมื่อทำโจทย์ที่ยาวขึ้น เนื่องจากผู้เข้าร่วมอาจเสียสมาธิในระหว่างที่รอโค้ดที่เขียนโดย AI
[5] ผู้เข้าร่วมได้รับคำแนะนำให้ทำโจทย์ให้เสร็จเร็วที่สุดเท่าที่จะทำได้ และได้รับค่าตอบแทนแบบเหมาจ่ายสำหรับการเข้าร่วม ดูรายละเอียดได้ที่ส่วนที่ 4.3
อย่างไรก็ตาม เมื่อมองผ่านมุมของการสร้างทักษะ เวลาที่ใช้ในการร่างคำสั่งอาจช่วยให้เกิดความเข้าใจในตัวโจทย์ได้ดีขึ้น และส่งผลให้มีการได้รับทักษะที่ดีขึ้นตามไปด้วย บันทึกหน้าจอแสดงให้เห็นว่าผู้เข้าร่วมมีการไตร่ตรองถึงสิ่งที่จะถามผู้ช่วย AI (เช่น การอ่านคำแนะนำซ้ำ และการเขียนคำสั่งใหม่) ส่งผลให้ผู้เข้าร่วมบางคนใช้เวลาหลายนาทีในการร่างคำสั่งเพียงคำสั่งเดียว ดังนั้น แม้ว่าต้นทุนทางเวลาจะเห็นได้ชัดเจนในผู้ช่วยแบบแชทมากกว่าเครื่องมือเขียนโค้ดแบบ Agentic (อัตโนมัติ) แต่การสูญเสียความรู้ก็น่าจะยิ่งรุนแรงมากขึ้นในสภาพแวดล้อมแบบ Agentic หรือแบบ Autocomplete ที่ไม่จำเป็นต้องร่างคำสั่งเอง ความแตกต่างของเวลาในการทำงานให้เสร็จที่ชัดเจนขึ้นเนื่องจากการปฏิสัมพันธ์กับ AI ที่สั้นลงนั้น น่าจะส่งผลเสียต่อการสร้างทักษะที่รุนแรงยิ่งขึ้นไปอีก และเมื่อเราพิจารณาคำสั่งแต่ละรายการ พบว่าไม่ใช่ทุกคำสั่งที่ต้องใช้การคิดและเวลาที่มากเสมอไป ดังนั้นเราจึงวิเคราะห์คำสั่งแต่ละรายการเพื่อทำความเข้าใจให้ดียิ่งขึ้นว่าผู้เข้าร่วมสร้างทักษะใหม่ได้อย่างไร
ภาพที่ 12: การกระจายของเวลาที่ใช้ปฏิสัมพันธ์กับ AI ทั้งหมดและจำนวนคำสั่ง AI ผู้เข้าร่วมที่ใช้เวลามากกว่า 6 นาทีในการปฏิสัมพันธ์กับ AI ระหว่างการทำโจทย์ มีส่วนทำให้กลุ่มทดลอง (ได้รับความช่วยเหลือจาก AI) ไม่มีความเร็วเพิ่มขึ้นกว่ากลุ่มควบคุม (ไม่ใช้ AI) อย่างมีนัยสำคัญ
คำสั่ง AI (AI Queries)
เราได้จัดหมวดหมู่ข้อมูลนำเข้าที่ผู้ใช้ส่งไปยังผู้ช่วย AI หรือ "คำสั่ง" (Queries) ออกเป็น 5 หมวดหมู่หลัก ได้แก่: การขอคำอธิบาย (Explanation), การขอให้สร้างโค้ด (Generation), การ Debugging, คำถามเกี่ยวกับความสามารถ (Capabilities) และการแสดงความขอบคุณ (Appreciation) (ตารางที่ 3) ประเภทของคำสั่งที่พบบ่อยที่สุดคือการขอคำอธิบาย ($q=79$) โดยผู้ใช้ขอข้อมูลเพิ่มเติมเกี่ยวกับ Library Trio รายละเอียดเกี่ยวกับการทำงานแบบ Asynchronous และการแนะนำมโนทัศน์ในระดับสูง ผู้เข้าร่วม 21 จาก 25 คนในกลุ่มทดลองมีการถามคำถามเพื่อขอคำอธิบาย ซึ่งสะท้อนถึงระดับการมีส่วนร่วมที่สูงของผู้เข้าร่วมของเรา ประเภทที่พบบ่อยเป็นอันดับสองคือคำสั่งขอให้สร้างโค้ด ($q=51$) โดยผู้เข้าร่วมบางคนขอให้ทำโจทย์ทั้งข้อให้เสร็จ ในขณะที่คนอื่นๆ ขอให้สร้างฟังก์ชันเฉพาะบางฟังก์ชัน มีเพียง 16 จาก 25 คนหรือประมาณสองในสามของผู้เข้าร่วมที่ใช้ AI เพื่อสร้างโค้ด และมีผู้เข้าร่วม 4 คนในกลุ่มนี้ที่ขอให้สร้างโค้ด เพียงอย่างเดียว โดยไม่มีการถามคำถามประเภทอื่นเลย ในความเป็นจริง 3 ใน 8 ของผู้เข้าร่วมที่ได้คะแนนต่ำที่สุดคือกลุ่มที่ขอให้ AI สร้างโค้ดโดยไม่อ่านคำอธิบาย ซึ่งบ่งชี้ว่าหากผู้เข้าร่วมทุกคนในกลุ่ม AI ใช้ AI เพียงเพื่อสร้างโค้ดเท่านั้น ความแตกต่างของการสร้างทักษะเมื่อเทียบกับกลุ่มควบคุมก็น่าจะยิ่งรุนแรงมากขึ้นไปอีก
หมวดหมู่ที่สามของคำสั่งที่พบบ่อยคือการ Debugging ($q=9$) โจทย์ของเราถูกออกแบบมาให้ตรงไปตรงมา แต่ผู้เข้าร่วมก็ยังคงพบข้อผิดพลาดที่หลากหลาย (ส่วนที่ 6.2) นี่เป็นหมวดหมู่คำสั่งที่กว้างขึ้นซึ่งรวมถึงการก๊อปปี้ข้อผิดพลาดมาวางโดยตรงเป็นข้อมูลนำเข้าสำหรับผู้ช่วย AI ไปจนถึงการขอให้ผู้ช่วย AI ช่วยยืนยันว่าโค้ดที่เขียนนั้นถูกต้องหรือไม่ สัดส่วนของคำสั่งด้าน Debugging ที่สูงขึ้นมีความสัมพันธ์กับเวลาในการทำโจทย์เสร็จสิ้นที่ช้าลง (ภาพที่ 19) และคะแนนควิซที่ต่ำลง (ภาพที่ 19) สิ่งนี้ชี้ให้เห็นว่าการพึ่งพา AI สำหรับการ Debugging (เช่น การขอให้ AI ตรวจสอบและแก้ไขสิ่งต่างๆ ซ้ำๆ โดยไม่พยายามทำความเข้าใจ) ในขณะที่กำลังเรียนรู้โจทย์ใหม่นั้น สัมพันธ์กับระดับการเรียนรู้ที่น้อยลง
แม้ว่าเราจะคัดเลือกเฉพาะผู้เข้าร่วมที่เคยใช้ผู้ช่วย AI มาก่อนแล้ว แต่ก็ยังคงมีคำถาม ($q=4$) เกี่ยวกับว่าผู้ช่วย AI สามารถมองเห็นโค้ดที่มีอยู่ได้หรือไม่ และผู้ช่วยมีความรู้เกี่ยวกับ Library เฉพาะทางนั้นหรือไม่ ซึ่งในการตอบคำถามเหล่านี้ ผู้ช่วย AI ได้ชี้แจงว่าพวกเขาสามารถมองเห็นโค้ดและคำแนะนำได้ ผู้เข้าร่วมหลายคนยังได้แสดงความขอบคุณต่อผู้ช่วย AI หลังจากทำโจทย์สำเร็จอย่างถูกต้อง การแสดงความขอบคุณเหล่านี้ แม้ว่าจะต้องแลกมาด้วยเวลาที่เพิ่มขึ้นในการทำโจทย์ แต่ก็สะท้อนให้เห็นว่าความสุภาพในการปฏิสัมพันธ์ระหว่างมนุษย์และ AI [Druga et al., 2017, Ribino, 2023] ก็ปรากฏขึ้นในบริบทของความช่วยเหลือในการเขียนโค้ดด้วย AI เช่นกัน
| ประเภทของคำสั่ง (Query Type) | ตัวอย่างคำสั่ง (Example Query) |
|---|---|
| คำอธิบาย (Explanation) ($q=79$) | “trio.sleep สามารถใช้เศษส่วนของวินาทีได้ไหม?” |
| “ช่วยเตือนหน่อยว่าการทำงานแบบ Async ของ Trio มีอะไรบ้าง?” | |
| “ดูดีเลย ช่วยสรุปภาพรวมสั้นๆ ของแนวคิดเบื้องหลังทั้งหมดนี้หน่อยได้ไหม?” | |
| การสร้างโค้ด (Generation) ($q=51$) | “จากคำแนะนำของ Trio นี้ ช่วยเขียนส่วนที่เหลือของ main.py ให้หน่อยได้ไหม?” |
| “เขียนฟังก์ชัน get_user_data ให้สมบูรณ์ที” | |
| “เขียน delayed_hello() ให้หน่อย โดยให้มันรอ 2.1 วินาทีแล้วค่อยพิมพ์ ’Hello World!’ ” | |
| การ Debugging ($q=9$) | “แบบนี้ดูถูกต้องไหม? ถ้าใช่ ไปทำ delayed_hello() ต่อกันเลย” |
| “ฉันมีปัญหาในการทำให้โค้ดทำงานได้ ฉันเจอข้อผิดพลาด notimplementederror ใน delayed_hello” | |
| ข้อผิดพลาดที่ก๊อปปี้มาวาง (เช่น “Traceback (most recent call last): File "/usercode/FILESYSTEM/main.py3", line 81, in… ”) | |
| คำถามเกี่ยวกับความสามารถ (Capabilities) ($q=4$) | “คุณเห็นคำถามปัจจุบันไหม?” |
| “แล้วคุณช่วยอะไรฉันได้บ้าง? คุณสามารถเขียนโค้ดลงในไฟล์โดยตรงได้เลยไหม?” | |
| “คุณรู้จักการทำงานของ Trio ไหม? มีความคล้ายคลึงในโมเดลการรันงานกับ Library อื่นที่ฉันคุ้นเคยอย่าง asyncio ไหม?” | |
| การแสดงความขอบคุณ (Appreciation) ($q=4$) | “ทำได้ดีมาก เราได้ผลลัพธ์ตามที่คาดไว้ในการรันครั้งแรกเลย” |
| “ดูเหมือนว่าจะใช้งานได้แล้ว ขอบคุณนะ!” | |
| “จริงงงงง! (Trueeee!)” |
ตารางที่ 3: ตัวอย่างประเภทของคำสั่งที่ผู้ช่วย AI ได้รับ และจำนวนของคำสั่งในแต่ละประเภท โดยมี 11 คำสั่งที่มีการจัดหมวดหมู่ซ้อนกัน 2 หมวดหมู่
การนำคำแนะนำ AI ไปใช้: การวาง (Pasting) เทียบกับการพิมพ์ตามด้วยตนเอง (Manual Code Copying)
อีกรูปแบบหนึ่งที่แตกต่างกันระหว่างผู้เข้าร่วมคือ ผู้เข้าร่วมบางคนเลือกที่จะวาง (Paste) โค้ดที่ AI เขียนขึ้นโดยตรง ในขณะที่ผู้เข้าร่วมคนอื่นๆ ใช้วิธีการพิมพ์ตามโค้ดที่ AI สร้างขึ้นลงในไฟล์ของตนเองด้วยตนเอง ความแตกต่างในรูปแบบการนำ AI ไปใช้นี้มีความสัมพันธ์กับเวลาในการทำโจทย์เสร็จสิ้น ในภาพที่ 13 เราได้แยกเวลาในการทำโจทย์เสร็จสิ้นและเปรียบเทียบว่าวิธีการนำ AI ไปใช้ส่งผลต่อเวลาในการทำงานและคะแนนควิซอย่างไร ผู้เข้าร่วมในกลุ่ม AI ที่ใช้วิธีวางโค้ดโดยตรง ($n=9$) ทำโจทย์เสร็จเร็วที่สุด ในขณะที่ผู้เข้าร่วมที่ใช้วิธีพิมพ์ตาม ($n=9$) หรือใช้วิธีผสมผสานทั้งสองแบบ ($n=4$) ทำโจทย์เสร็จในความเร็วที่ใกล้เคียงกับกลุ่มควบคุม (ไม่ใช้ AI) นอกจากนี้ ยังมีกลุ่มผู้เข้าร่วมขนาดเล็กในเงื่อนไขกลุ่ม AI ที่ส่วนใหญ่เขียนโค้ดด้วยตนเองโดยไม่มีการก๊อปปี้หรือวางโค้ดที่ AI สร้างขึ้น ($n=4$) ซึ่งผู้เข้าร่วมกลุ่มนี้ทำงานได้ค่อนข้างเร็วและแสดงให้เห็นถึงความเชี่ยวชาญในระดับสูง โดยพวกเขามักถามเพียงคำถามเพื่อขอความชัดเจนจากผู้ช่วย AI เท่านั้น ผลลัพธ์เหล่านี้แสดงให้เห็นว่า มีเพียงส่วนน้อยของการปฏิสัมพันธ์ที่ได้รับความช่วยเหลือจาก AI เท่านั้นที่นำไปสู่การปรับปรุง Productivity ได้จริง
สำหรับการสร้างทักษะซึ่งวัดโดยคะแนนควิซ พบว่าไม่มีความแตกต่างที่ชัดเจนระหว่างกลุ่มที่พิมพ์ตามด้วยตนเองเทียบกับกลุ่มที่วางเอาท์พุตของ AI โดยตรง สิ่งนี้ชี้ให้เห็นว่าการใช้เวลาเพิ่มขึ้นในการพิมพ์ด้วยตนเองอาจไม่ได้ช่วยให้เกิดความเข้าใจเชิงมโนทัศน์ที่ดีขึ้น ความพยายามทางความคิด (Cognitive effort) น่าจะมีความสำคัญมากกว่าเวลาที่ใช้ไปในการทำโจทย์ให้เสร็จสิ้นเพียงอย่างเดียว
ภาพที่ 13: การวิเคราะห์พฤติกรรมการเขียนโค้ดด้วย AI: ผู้เข้าร่วมที่ใช้ AI โดยการวางเอาท์พุตโดยตรงจะมีความเร็วเพิ่มขึ้นมากที่สุด ในขณะที่ผู้เข้าร่วมที่พิมพ์ตามโค้ดที่ AI สร้างขึ้นด้วยตนเอง จะมีความเร็วในการทำโจทย์ใกล้เคียงกับกลุ่มควบคุม (ไม่ใช้ AI)
6.2 การพบข้อผิดพลาด (Encountering Errors)
วิธีที่ผู้เข้าร่วมพบและแก้ไขข้อผิดพลาดนั้นมีความแตกต่างกันอย่างชัดเจนระหว่างเงื่อนไขกลุ่มทดลองและกลุ่มควบคุม ในแพลตฟอร์มนี้ ผู้เข้าร่วมสามารถใช้ปุ่มรัน (Run) หรือใช้ Terminal เพื่อรันโค้ดของตนเองได้บ่อยเท่าที่ต้องการ โดยทั่วไปแล้ว ผู้เข้าร่วมส่วนใหญ่มักจะรันโค้ดเป็นครั้งแรกหลังจากที่พยายามทำโจทย์ไปได้เกือบทั้งหมดแล้ว และจะรันโค้ดอีกครั้งหลังจากที่มีการแก้ไขโค้ด เราได้บันทึกทุกข้อผิดพลาดที่ผู้เข้าร่วมแต่ละคนพบในขณะที่เราดูวิดีโอบันทึกหน้าจอความคืบหน้าของงาน
ความถี่ของข้อผิดพลาด (Error Frequency)
กลุ่ม AI พบข้อผิดพลาดน้อยกว่ากลุ่มควบคุม โดยค่ามัธยฐานของผู้เข้าร่วมในกลุ่มทดลองคือพบข้อผิดพลาดเพียงครั้งเดียวตลอดการทำโจทย์ทั้งหมด ในขณะที่ค่ามัธยฐานของกลุ่มควบคุมคือพบข้อผิดพลาดสามครั้ง ตารางที่ 4 แสดงให้เห็นถึงความแตกต่างในการกระจายของข้อผิดพลาด ผู้เข้าร่วมส่วนใหญ่ในกลุ่ม AI สามารถทำโจทย์เสร็จสิ้นได้ตั้งแต่ครั้งแรกที่พวกเขารันโค้ด ในทางตรงกันข้าม ในเงื่อนไขกลุ่มควบคุม ผู้เข้าร่วมส่วนใหญ่พบข้อผิดพลาดหลายครั้งในระหว่างกระบวนการทำโจทย์แต่ละข้อให้เสร็จสิ้น และในบรรดาผู้เข้าร่วม 12 คนที่ทำโจทย์ทั้งสองข้อเสร็จโดยไม่พบข้อผิดพลาดเลย มีเพียง 2 คนเท่านั้นที่มาจากกลุ่มควบคุม
| ใช้ AI (AI) | ไม่ใช้ AI (No AI) | |
|---|---|---|
| รวม (Total) | 1.0 (0.0-3.0) | 3.0 (2.0-5.0) |
| โจทย์ที่ 1 (Task 1) | 0.0 (0.0-2.0) | 2.0 (0.5-3.0) |
| โจทย์ที่ 2 (Task 2) | 0.0 (0.0-1.0) | 2.0 (0.5-2.0) |
ตารางที่ 4: จำนวนข้อผิดพลาดที่ผู้เข้าร่วมแต่ละคนพบแยกตามเงื่อนไข ค่าที่แสดงคือค่ามัธยฐาน (Q1–Q3)
ข้อผิดพลาดและทักษะ Trio (Errors and Trio Skill)
ภาพที่ 14: จำนวนข้อผิดพลาดทั้งหมดที่ผู้เข้าร่วมพบ แยกตามประเภทของข้อผิดพลาด
ภาพที่ 15: จำนวนข้อผิดพลาดแยกตามเงื่อนไขของผู้เข้าร่วม: กลุ่มทดลอง (ใช้ AI) และกลุ่มควบคุม (ไม่ใช้ AI) กลุ่มควบคุมพบข้อผิดพลาดที่เกี่ยวข้องกับมโนทัศน์หลักของ Trio มากกว่าอย่างชัดเจน (เช่น TypeError และ RuntimeWarning)
ไม่ใช่ว่าทุกข้อผิดพลาดจะมีน้ำหนักต่อการสร้างทักษะเท่ากันในการศึกษาของเรา ข้อผิดพลาดบางประการต้องการความเข้าใจใน Library Trio ที่ลึกซึ้งกว่า ซึ่งอาจเป็นสาเหตุของความแตกต่างในผลลัพธ์การเรียนรู้ ภาพที่ 15 แสดงให้เห็นว่าข้อผิดพลาดที่พบบ่อยที่สุดนั้นไม่ได้เกี่ยวข้องโดยตรงกับ Library Trio เช่น NameError และ AttributeError ซึ่งมักจะเป็นเพียงการพิมพ์ชื่อตัวแปรหรือชื่อฟังก์ชันผิดที่สามารถแก้ไขได้อย่างรวดเร็ว ในขณะที่ข้อผิดพลาดอื่นๆ มีความเกี่ยวข้องโดยตรงกับ Trio เช่น RuntimeWarning ซึ่งจะปรากฏขึ้นเมื่อ Coroutine ไม่เคยถูก await และ TypeError ที่ปรากฏขึ้นเมื่อฟังก์ชันของ Trio ได้รับ Coroutine object แทนที่จะเป็น Async function ข้อผิดพลาดเหล่านี้บังคับให้ผู้เรียนต้องทำความเข้าใจมโนทัศน์สำคัญเกี่ยวกับวิธีที่ Library Trio จัดการกับ Coroutine และการใช้งานคีย์เวิร์ด await ซึ่งเป็นสิ่งที่ถูกทดสอบในการประเมินผล แม้ว่าผู้เข้าร่วมในเงื่อนไขกลุ่ม AI จะพบข้อผิดพลาดเช่นกัน (ภาพที่ 15) แต่กลับพบข้อผิดพลาดที่เกี่ยวข้องกับ Trio น้อยกว่ามาก
สำหรับผู้เข้าร่วมในกลุ่มควบคุม ความถี่ในการพบข้อผิดพลาดที่สูงขึ้นนำไปสู่การคิดเชิงวิพากษ์ (Critical thinking) เกี่ยวกับสิ่งที่เกิดขึ้นในโค้ด และวิธีใช้งาน Library ใหม่ที่นำเสนอ นอกจากนี้ การปรากฏขึ้นบ่อยครั้งของข้อผิดพลาดที่เกี่ยวข้องกับ Library Trio โดยเฉพาะ ยังช่วยให้แน่ใจว่าผู้เรียนจะได้รับมโนทัศน์เฉพาะเจาะจงเหล่านั้นในระหว่างกระบวนการทำโจทย์ให้เสร็จสิ้น เมื่อพิจารณารวมกัน ความแตกต่างทั้งสองประการนี้ชี้ให้เห็นว่า การเผชิญกับข้อผิดพลาดอาจมีบทบาทสำคัญในการสร้างทักษะการเขียนโค้ด ยิ่งไปกว่านั้น แรงจูงใจเริ่มแรกของเราเกี่ยวกับความสำคัญของการรักษาทักษะการ Debugging อาจขึ้นอยู่กับการได้รับทักษะเหล่านี้โดยไม่ต้องพึ่งพา AI
6.3 การเปลี่ยนสัดส่วนเวลาที่ใช้เขียนโค้ดจริง (Shifts in Active Coding Time)
แม้ว่าผลลัพธ์ที่เราวัดในการวิเคราะห์หลักคือ Productivity ผ่านเวลาในการทำโจทย์ทั้งหมด แต่ปริมาณเวลาที่ใช้ในการ "เขียนโค้ดจริงๆ" (Active coding) นั้นแสดงให้เห็นรูปแบบที่ชัดเจนกว่า ภาพที่ 16 แสดงให้เห็นว่าผู้เข้าร่วมในเงื่อนไขกลุ่ม AI ใช้เวลาที่ลงมือทำจริงน้อยกว่ามาก การเปลี่ยนแปลงจาก "การเขียน" ไปเป็นการ "อ่านและทำความเข้าใจ" นี้ยังถูกพบในงานวิจัยก่อนหน้านี้ด้วย [Becker et al., 2025] เมื่อเราพิจารณาคะแนนควิซ กลุ่มควบคุมสามารถทำคะแนนควิซได้สูงด้วยเวลาที่ลงมือทำจริงทั้งหมดที่มากกว่าโดยไม่ต้องใช้ AI ซึ่งในแต่ละเงื่อนไข เวลาที่ลงมือทำจริงที่สูงขึ้นนั้นมีความสัมพันธ์กับคะแนนควิซที่ต่ำลง เนื่องจากโปรแกรมเมอร์ที่มีประสบการณ์มากกว่ามักจะใช้เวลาในการเขียนโค้ดน้อยกว่า ในขณะที่มีความรู้พื้นฐานที่ดีกว่าเมื่อเทียบกับโปรแกรมเมอร์มือใหม่
ภาพที่ 16: เวลาที่เขียนโค้ดจริงเทียบกับคะแนนควิซ: เวลาที่ลงมือจริง (Active coding time) หมายถึงปริมาณเวลาที่ใช้ในการพิมพ์โค้ดจริงๆ และมักจะเป็นสัดส่วนที่น้อยมากเมื่อเทียบกับเวลาที่ใช้ทำโจทย์ทั้งหมด ผู้เข้าร่วมในเงื่อนไขกลุ่มไม่ใช้ AI (No AI) ใช้เวลาที่ลงมือทำจริงมากกว่าและทำคะแนนควิซได้สูงกว่า
6.4 ความเห็นจากผู้เข้าร่วม (Participant Feedback)
หนึ่งในสี่ของผู้เข้าร่วมได้ทิ้งความเห็นไว้หลังจากทำโจทย์และควิซเสร็จสิ้น ในกลุ่มควบคุม (ไม่ใช้ AI) ผู้เข้าร่วมระบุว่าพวกเขาพบว่าโจทย์นั้นสนุกและคำแนะนำในโจทย์ช่วยให้พัฒนาความเข้าใจใน Trio ได้เป็นอย่างดี ส่วนในกลุ่มทดลอง (ได้รับความช่วยเหลือจาก AI) ผู้เข้าร่วมระบุว่าพวกเขาหวังว่าตนเองจะให้ความสนใจกับรายละเอียดของ Library Trio ในระหว่างการทำโจทย์มากกว่านี้ ไม่ว่าจะเป็นการอ่านโค้ดที่ถูกสร้างขึ้นหรือการขอคำอธิบายเชิงลึกเพิ่มเติม โดยเฉพาะอย่างยิ่ง ผู้เข้าร่วมรายงานว่ารู้สึก 'ขี้เกียจ' และ 'ยังคงมีช่องว่างจำนวนมากในความเข้าใจ (ของตนเอง)' ความรู้สึกจากความเห็นของผู้เข้าร่วมบ่งชี้ถึงประสบการณ์เชิงบวกที่มากกว่าในกลุ่มควบคุม แม้ว่าคำแนะนำในโจทย์และคำถามในควิซจะเหมือนกันทุกประการในทั้งสองกลุ่ม (ตารางที่ 6 และ 7 ได้รวบรวมความเห็นทั้งหมดจากผู้เข้าร่วมทุกคนไว้)
7 อภิปรายผล (Discussion)
ข้อค้นพบหลักของเราคือ การใช้ AI เพื่อทำโจทย์ที่ต้องการทักษะใหม่ (เช่น ความรู้เกี่ยวกับ Library ใหม่ใน Python) จะลดระดับการสร้างทักษะลง ในการทดลองแบบสุ่มและมีการควบคุมนี้ ผู้เข้าร่วมถูกแบ่งออกเป็นกลุ่มทดลอง (ใช้ผู้ช่วย AI ค้นหาเว็บ และอ่านคำแนะนำ) หรือกลุ่มควบคุม (ทำโจทย์โดยใช้เพียงการค้นหาเว็บและอ่านคำแนะนำเท่านั้น) การถดถอยของความเข้าใจเชิงมโนทัศน์ การอ่านโค้ด และทักษะการ Debugging ที่เราวัดได้จากผู้เข้าร่วมกลุ่มที่ใช้ AI บ่งชี้ว่า คนทำงานที่กำลังได้รับทักษะใหม่ๆ ควรตระหนักถึงการพึ่งพา AI ของตนเองในระหว่างกระบวนการเรียนรู้ ในหมู่ผู้เข้าร่วมที่ใช้ AI เราพบความแตกต่างอย่างชัดเจนของผลลัพธ์การสร้างทักษะ ระหว่างรูปแบบการปฏิสัมพันธ์ที่ได้คะแนนสูง (คะแนนควิซ 65%-86%) เทียบกับรูปแบบการปฏิสัมพันธ์ที่ได้คะแนนต่ำ (คะแนนควิซ 24%-39%) โดยกลุ่มที่ได้คะแนนสูงนั้นถามเพียงคำถามเชิงมโนทัศน์กับ AI แทนที่จะให้ AI สร้างโค้ดให้ หรือขอคำอธิบายประกอบโค้ดที่ถูกสร้างขึ้น ซึ่งรูปแบบการใช้งานเหล่านี้แสดงให้เห็นถึงระดับการมีส่วนร่วมทางความคิด (Cognitive engagement) ที่สูง
สิ่งที่ขัดกับสมมติฐานเบื้องต้นของเราคือ เราไม่พบการเพิ่มขึ้นของประสิทธิภาพในการทำโจทย์เสร็จสิ้นที่ชัดเจนในการศึกษาหลัก แม้ว่าการใช้ AI จะช่วยปรับปรุงเวลาเฉลี่ยในการทำโจทย์ให้ดีขึ้นบ้าง แต่การปรับปรุงประสิทธิภาพนี้ไม่มีนัยสำคัญในการศึกษาของเรา ทั้งที่ผู้ช่วย AI สามารถสร้างโซลูชันโค้ดที่สมบูรณ์ได้ทันทีเมื่อได้รับคำสั่ง การวิเคราะห์เชิงคุณภาพของเราเผยให้เห็นว่า ข้อค้นพบนี้มีสาเหตุหลักมาจากความหลากหลายในวิธีที่ผู้เข้าร่วมตัดสินใจใช้ AI ในระหว่างการทำโจทย์ มีกลุ่มผู้เข้าร่วมที่พึ่งพา AI เพื่อสร้างโค้ดทั้งหมดและไม่เคยถามคำถามเชิงมโนทัศน์หรือขอคำอธิบายเลย ซึ่งกลุ่มนี้ทำโจทย์เสร็จเร็วกว่ากลุ่มควบคุมอย่างมาก (19.5 นาที เทียบกับ 23 นาที) แต่กลุ่มนี้คิดเป็นเพียงประมาณ 20% ของผู้เข้าร่วมในกลุ่มทดลองเท่านั้น ในขณะที่ผู้เข้าร่วมคนอื่นๆ ในกลุ่ม AI ที่ถามคำถามจำนวนมาก (เช่น 15 คำถาม) ใช้เวลานานในการร่างคำสั่ง (เช่น 10 นาที) หรือขอคำอธิบายติดตามผล ได้ส่งผลให้เวลาเฉลี่ยในการทำโจทย์เสร็จสิ้นเพิ่มสูงขึ้น รูปแบบการใช้งาน AI ที่ตัดกันเหล่านี้บ่งชี้ว่า การทำงานที่ต้องใช้ความรู้หรือทักษะใหม่ๆ ไม่ได้นำไปสู่ Productivity ที่เพิ่มขึ้นในแบบเดียวกับงานที่ต้องการเพียงความรู้ที่มีอยู่เดิม
เมื่อพิจารณารวมกัน ผลลัพธ์ของเราบ่งชี้ว่า การนำ AI เข้ามาใช้อย่างรวดเร็วและรุนแรงในที่ทำงานอาจส่งผลกระทบเชิงลบต่อการพัฒนาวิชาชีพของคนทำงานได้ หากพวกเขาไม่รักษาการมีส่วนร่วมทางความคิดเอาไว้ ภายใต้ข้อจำกัดด้านเวลาและความกดดันจากองค์กร นักพัฒนาระดับจูเนียร์หรือมืออาชีพคนอื่นๆ อาจหันไปพึ่งพา AI เพื่อทำงานให้เสร็จเร็วที่สุดเท่าที่จะเป็นไปได้ โดยต้องแลกมาด้วยการพัฒนาทักษะที่แท้จริง ยิ่งไปกว่านั้น เรายังพบว่าความแตกต่างที่ใหญ่ที่สุดของคะแนนการทดสอบนั้นอยู่ที่คำถามด้าน Debugging ซึ่งบ่งชี้ว่า เมื่อบริษัทต่างๆ เปลี่ยนผ่านไปสู่การให้ AI เขียนโค้ดมากขึ้นโดยมีการกำกับดูแลโดยมนุษย์ มนุษย์อาจจะไม่มีทักษะที่จำเป็นในการตรวจสอบและ Debug โค้ดที่ AI เขียนขึ้น หากการสร้างทักษะพื้นฐานของพวกเขาถูกขัดขวางจากการใช้ AI มาตั้งแต่ต้น
7.1 งานในอนาคต (Future Work)
งานของเราเป็นก้าวแรกในการทำความเข้าใจผลกระทบของความช่วยเหลือจาก AI ที่มีต่อมนุษย์ในกระบวนการร่วมมือกันระหว่างมนุษย์และ AI เราหวังว่างานชิ้นนี้จะช่วยสร้างแรงบันดาลใจให้เกิดงานวิจัยในอนาคตที่ช่วยแก้ข้อจำกัดดังต่อไปนี้:
- • การเลือกโจทย์ (Task Selection): การศึกษานี้มุ่งเน้นไปที่โจทย์เดียวโดยใช้อินเทอร์เฟซแบบแชท สิ่งนี้ควรถูกมองว่าเป็นขอบเขตขั้นต่ำ (Lower bound) ของการลดภาระทางความคิด (Cognitive offloading) เนื่องจากเครื่องมือเขียนโค้ดแบบ Agentic AI จะต้องการการมีส่วนร่วมของมนุษย์น้อยลงไปอีก ในงานของเรา ผู้ใช้ที่พึ่งพา AI โดยไม่คิดทำคะแนนได้แย่ที่สุดในการประเมิน ซึ่งเครื่องมือแบบ Agentic โดยสมบูรณ์ก็น่าจะสร้างผลกระทบที่คล้ายคลึงกัน งานวิจัยในอนาคตควรตรวจสอบผลกระทบของเครื่องมือเขียนโค้ดแบบ Agentic ต่อผลลัพธ์การเรียนรู้และการพัฒนาทักษะ
- • ระยะเวลาของโจทย์ (Task Length): ตามหลักการแล้ว การสร้างทักษะควรเกิดขึ้นในช่วงเวลาเป็นเดือนหรือเป็นปี แต่เราวัดการสร้างทักษะสำหรับ Library ในภาษา Python เฉพาะเจาะจงในช่วงเวลาเพียงหนึ่งชั่วโมง งานในอนาคตควรศึกษาการพัฒนาทักษะในโลกความเป็นจริงผ่านการวัดผลระยะยาว (Longitudinal measurement) ถึงผลกระทบของการนำ AI มาใช้
- • ความสมจริงของผู้เข้าร่วม (Participant Realism): แม้ว่าผู้เข้าร่วมในการศึกษาของเราจะเป็นโปรแกรมเมอร์มืออาชีพหรือฟรีแลนซ์ แต่พวกเขาก็ไม่ได้มีแรงจูงใจในการเรียนรู้ Library นั้นเหมือนกับว่ามันเป็นสิ่งจำเป็นสำหรับการทำงานจริงของพวกเขา การศึกษาในอนาคตควรตั้งเป้าไปที่การศึกษาการได้รับทักษะของพนักงานมือใหม่ภายในบริษัทจริงๆ
- • ทักษะการเขียน Prompt (Prompting Skills): เราเก็บข้อมูลความคุ้นเคยกับเครื่องมือเขียนโค้ดด้วย AI จากการรายงานด้วยตนเอง แต่เราไม่ได้วัดความแตกต่างในเทคนิคการเขียน Prompt จริงๆ การขยายผลงานวิจัยของเราอาจรวมถึงการทดสอบระดับความคล่องแคล่วในการเขียน Prompt ที่มากกว่าแค่การรายงานด้วยตนเอง
- • การออกแบบการประเมินผล (Evaluation Design): การศึกษาของเราวัดการสร้างทักษะผ่านควิซที่ครอบคลุม การศึกษาอื่นๆ อาจใช้การทำงานโจทย์อื่นให้เสร็จสิ้น หรือการออกแบบการเขียนโค้ดเป็นกลยุทธ์การประเมินทางเลือก
- • ความช่วยเหลือจากมนุษย์ (Human Assistance): เราไม่ได้รวมการเปรียบเทียบ (Counterfactual) ว่าการสร้างทักษะจะได้รับผลกระทบอย่างไรหากได้รับความช่วยเหลือจากมนุษย์ เนื่องจากความช่วยเหลือและข้อเสนอแนะจากมนุษย์เกิดขึ้นในสภาพแวดล้อมที่หลากหลาย (เช่น ห้องเรียน, การเขียนโค้ดแบบคู่ (Pair programming), การรีวิวโค้ด) งานในอนาคตสามารถเปรียบเทียบผลกระทบของข้อเสนอแนะจาก AI เทียบกับมนุษย์ในสภาพแวดล้อมเหล่านี้ต่อการสร้างทักษะได้
สำหรับพนักงานมือใหม่ในงานวิศวกรรมซอฟต์แวร์หรืออุตสาหกรรมอื่นๆ การศึกษาของเราสามารถมองได้ว่าเป็นหลักฐานชิ้นเล็กๆ ที่ชี้ให้เห็นถึงคุณค่าของการพัฒนาทักษะอย่างตั้งใจ แม้ว่าเครื่องมือ AI จะแพร่หลายไปทั่วก็ตาม การศึกษาของเราแสดงให้เห็นถึงประโยชน์ของการใช้ความพยายามทางความคิด (Cognitive effort) เมื่อเผชิญกับโอกาสในการเรียนรู้เพื่อฝึกฝนเครื่องมือใหม่ๆ แม้ว่าอาจจะต้องพบกับอุปสรรค (เช่น ข้อผิดพลาด) ในกระบวนการสร้างความเชี่ยวชาญนั้นก็ตาม การใช้ความพยายามทางความคิดสามารถทำได้โดยได้รับการสนับสนุนจาก AI ซึ่งนอกเหนือจากรูปแบบที่เราอธิบายไว้ บริการ LLM รายใหญ่ยังมีการโหมดการเรียนรู้ให้ใช้ด้วย (เช่น ChatGPT Study Mode หรือโหมดการเรียนรู้/อธิบายโค้ดของ Claude) ท้ายที่สุดแล้ว เพื่อให้การพัฒนาทักษะสามารถดำเนินไปได้พร้อมกับการมีอยู่ของ AI เราจำเป็นต้องมีมุมมองที่กว้างขึ้นเกี่ยวกับผลกระทบของ AI ที่มีต่อคนทำงาน ผู้ที่มีส่วนร่วมในระบบเศรษฐกิจ AI ใหม่นี้จะต้องให้ความสำคัญไม่เพียงแต่การเพิ่ม Productivity จาก AI เท่านั้น แต่ยังต้องคำนึงถึงความยั่งยืนในระยะยาวของการพัฒนาความเชี่ยวชาญ ท่ามกลางการแพร่หลายของเครื่องมือ AI ใหม่ๆ ด้วย
8 กิตติกรรมประกาศ (Acknowledgments)
เราขอขอบคุณ Ethan Perez, Miranda Zhang และ Henry Sleight ที่ช่วยให้โครงการนี้เป็นไปได้ผ่านโครงการ Anthropic Safety Fellows นอกจากนี้ เราขอขอบคุณ Matthew Jörke, Juliette Woodrow, Sarah Wu, Elizabeth Childs, Roshni Sahoo, Nate Rush, Julian Michael และ Rose Wang สำหรับคำแนะนำในการออกแบบการทดลอง
เราขอขอบคุณ Jeffrey Shen, Aram Ebtekar, Minh Le, Mateusz Piotrowski, Nate Rahn, Miles McCain, Jessica Zhu, Alex Wang, John Hewitt, Rosanne Hu, Saffron Huang, Kyle Hsu, Sanjana Srivastava และ Jennifer Leung สำหรับการทดสอบโจทย์และข้อเสนอแนะต่างๆ
รายการอ้างอิง (References)
- D. Autor, F. Levy, and R. Murnane (2001) The skill content of recent technological change: an empirical exploration.
- J. Becker, N. Rush, E. Barnes, and D. Rein (2025) Measuring the impact of early-2025 ai on experienced open-source developer productivity.
- H. Bleher and M. Braun (2022) Diffused responsibility: attributions of responsibility in the use of ai-driven clinical decision support systems.
- S. R. Bowman, J. Hyun, E. Perez, E. Chen, C. Pettit, S. Heiner, K. Lukošiūtė, A. Askell, A. Jones, A. Chen, et al. (2022) Measuring progress on scalable oversight for large language models.
- E. Brynjolfsson, D. Li, and L. Raymond (2025) Generative ai at work.
- Z. K. Cui, M. Demirer, S. Jaffe, L. Musolff, S. Peng, and T. Salz (2024) The effects of generative ai on high skilled work: evidence from three field experiments with software developers.
- Original Paper on ArXiv
ภาคผนวก A รายละเอียดผู้เข้าร่วม (Appendix A Participant Details)
ภาพที่ 17: การกระจายของผู้เข้าร่วมในการศึกษาหลัก ซึ่งรวบรวมหลังจากทำโจทย์เสร็จสิ้นเพื่อหลีกเลี่ยงผลกระทบจากอคติทางความคิด (Stereotype threat) ผู้เข้าร่วมส่วนใหญ่เป็นโปรแกรมเมอร์มืออาชีพ
A.1 การทบทวนด้านจริยธรรม (Ethics Review)
พิธีสารการวิจัยนี้ได้รับการตรวจสอบและอนุมัติโดยผู้ตรวจสอบภายในของ Anthropic ผู้เข้าร่วมไม่ได้รับความเสี่ยงใดๆ ในระหว่างการศึกษานี้ ประโยชน์ที่คาดหวังได้ตามสมควรจากการศึกษานี้คือ การเรียนรู้ทักษะซอฟต์แวร์ใหม่ (Python) อย่างไรก็ตาม เราไม่ได้การันตีหรือรับรองว่าผู้เข้าร่วมจะได้รับประโยชน์ทางการเรียนรู้เฉพาะเจาะจงใดๆ จากการศึกษานี้ เราได้รวบรวมความยินยอมที่ได้รับการชี้แจง (Informed consent) สำหรับการเข้าร่วมในการศึกษาในช่วงขั้นตอนการคัดกรองล่วงหน้า (Prescreening) เราให้สิทธิ์ผู้เข้าร่วมในการเพิกถอนความยินยอมได้ตลอดเวลาโดยไม่มีบทลงโทษใดๆ พวกเขาจะยังคงได้รับค่าตอบแทนแม้ว่าจะไม่ผ่านการตรวจสอบความตั้งใจ (Attention checks) ทำโจทย์ไม่เสร็จสมบูรณ์ หรือทำโจทย์ไม่ถูกต้องก็ตาม การตอบกลับควิซถูกจัดเก็บไว้ใน Google Drive และข้อมูลการกดแป้นพิมพ์ถูกจัดเก็บไว้ในแพลตฟอร์มการเขียนโค้ด ข้อมูลที่จัดเก็บทั้งหมดจะถูกทำให้เป็นข้อมูลนิรนาม (Anonymized) โดยสมบูรณ์ มีเพียงแพลตฟอร์มข้อมูลเท่านั้นที่สามารถใช้ ID เพื่อระบุตัวตนผู้เข้าร่วมสำหรับการชำระเงินได้ และเรายังได้ลบตัวระบุตัวตนของแพลตฟอร์มข้อมูลออกเพิ่มเติม เพื่อวิเคราะห์รูปแบบการเขียนโค้ดระหว่างสองกลุ่มทดลอง
ภาคผนวก B ข้อมูลและรายละเอียดการวิเคราะห์เชิงคุณภาพ (Appendix B Qualitative Analysis Data and Details)
B.1 ขั้นตอนการจดบันทึก (Annotation Procedure)
ผู้เข้าร่วม 51 จาก 52 คนได้อัปโหลดวิดีโอบันทึกหน้าจอการทำงานของพวกเขาในโจทย์ Warm-up โจทย์การเขียนโค้ดหลัก และควิซ เราได้ดูวิดีโอบันทึกหน้าจอของผู้เข้าร่วมทุกคน (25 คนในเงื่อนไขกลุ่ม AI และ 25 คนในเงื่อนไขกลุ่มไม่ใช้ AI) สำหรับโจทย์การเขียนโค้ดหลัก และเราได้บันทึกช่วงเวลา (Time stamps) ของเหตุการณ์ต่างๆ ดังต่อไปนี้:
| เหตุการณ์ (Event) | คำอธิบาย (Description) | ข้อมูลเพิ่มเติม (Additional Info) |
|---|---|---|
| เริ่มโจทย์ (Task Start) | ผู้ใช้เปิดแต่ละโจทย์ | |
| การปฏิสัมพันธ์กับ AI (AI Interaction) | ผู้ใช้เริ่มพิมพ์ลงในหน้าต่าง AI | คำอธิบายของการปฏิสัมพันธ์ |
| คำสั่ง AI (AI Query) | ผู้ใช้ได้รับคำตอบจาก AI | คำสั่งที่ใช้ (Query) |
| การค้นหาเว็บ (Websearch) | ผู้ใช้ส่งคำถามไปยังเครื่องมือค้นหา | คำสั่งที่ใช้ (Query) |
| การวาง (Paste) (โดยตรง) | ผู้ใช้วางเอาท์พุตจากผู้ช่วย AI | |
| การพิมพ์โค้ดตาม (Code Copying) | ผู้ใช้พิมพ์โค้ดโดยใช้เอาท์พุตของ AI | |
| ข้อผิดพลาด (Error) | โค้ดแสดงข้อผิดพลาดเมื่อรัน | ข้อความแสดงข้อผิดพลาด |
| ข้อผิดพลาดของอินเทอร์เฟซ | ข้อผิดพลาดจากสภาพแวดล้อมการพัฒนาหรือผู้ช่วย AI | |
| งานเสร็จสิ้น (Task Completion) | ได้ผลลัพธ์ที่ถูกต้องตามโจทย์ | |
| การส่งงาน (Task Submission) | ผู้ใช้ส่งโจทย์ | ความสมบูรณ์ของโค้ด |
ตารางที่ 5: เหตุการณ์ต่างๆ ที่ถูกจดบันทึกด้วยตนเองจากวิดีโอบันทึกหน้าจอของการทำโจทย์หลัก
เรายังสังเกตเห็นประเด็นทั่วไปในวิธีที่ผู้เข้าร่วมใช้ AI ในแต่ละเงื่อนไข โดยอิงจากรหัสเหตุการณ์เหล่านี้
ภาพที่ 18: เมื่อจำนวนคำสั่งเพิ่มขึ้น เวลาในการทำโจทย์เสร็จสิ้นทั้งหมดก็จะเพิ่มขึ้นด้วย โดยผู้ใช้ที่ถามคำสั่งด้าน Debugging ในสัดส่วนที่สูง มักจะมีแนวโน้มที่จะใช้เวลาในการทำโจทย์ให้เสร็จสิ้นมากกว่า
ภาพที่ 19: ไม่มีรูปแบบที่ชัดเจนระหว่างจำนวนคำสั่งทั้งหมดกับคะแนนควิซ อย่างไรก็ตาม ผู้ใช้ที่พึ่งพา AI อย่างหนักในการ Debug มักจะมีแนวโน้มที่จะได้คะแนนควิซต่ำลง
B.2 การเข้าถึงข้อมูล (Data Availability)
เราได้เผยแพร่บันทึกเหตุการณ์ (Annotated transcripts) ของผู้เข้าร่วมแต่ละคนไว้ที่ URL ต่อไปนี้: https://github.com/safety-research/how-ai-impacts-skill-formation
B.3 รายละเอียดความเห็นจากผู้เข้าร่วม (Participant Feedback Details)
เราได้รวมความเห็นทั้งหมดของผู้เข้าร่วมไว้ในตารางที่ 6 และ 7 เนื่องจากเวลาเฉลี่ยในการทำโจทย์เสร็จสิ้นของกลุ่ม AI นั้นเร็วกว่า ผู้เข้าร่วมในกลุ่ม AI จึงได้ทิ้งความเห็นไว้มากกว่า เนื่องจากพวกเขารู้สึกว่าตนเองมีเวลาเหลือในช่วงท้ายของงาน
| เงื่อนไข (Condition) | ความเห็น (Feedback) |
|---|---|
| AI | ควิซแรก (การพิมพ์เครื่องหมาย *) จะง่ายกว่านี้มากถ้าฉันสามารถค้นหาวิธีการเพิ่มข้อมูลลงใน Array (Appending to an array) ได้ ฉันลืมมันไปในขณะที่ทำโจทย์ และปกติแล้วการค้นหาใน Google จะใช้เวลาเพียง 5 วินาทีและไม่ต้องใช้โมเดลมาช่วยเลย แต่เพราะว่าฉันไม่สามารถเปลี่ยนแท็บได้ ฉันเลยติดอยู่ตรงนั้น |
| AI | การใช้ผู้ช่วย AI ทำให้ฉันรู้สึกว่าตัวเองเริ่มขี้เกียจ ฉันไม่ได้อ่านบทนำและตัวอย่างโค้ดของ Library Trio อย่างละเอียดเท่าที่ควรจะเป็นหากไม่มีมันช่วย |
| AI | เป็นโครงการที่เจ๋งมาก ขอให้ทุกอย่างไปได้สวยนะ! |
| AI | ฉันไม่ขัดข้องเลยที่จะลงลึกรายละเอียดกับผู้ช่วย AI ให้มากกว่านี้ เพื่อที่จะเข้าใจและทดสอบรายละเอียดของ Library Trio ให้ถ่องแท้ ฉันรู้สึกว่าฉันได้รับภาพรวมที่ค่อนข้างดี แต่ก็ยังคงมีช่องว่างจำนวนมากในความเข้าใจของฉัน |
| AI | ฉันรู้สึกว่าตัวเองดูไม่ค่อยฉลาดเลยจากช่วง Warmup แต่หวังว่าโจทย์อื่นๆ จะช่วยแสดงให้เห็นว่าฉันทำอะไรได้บ้าง ขอโทษด้วยนะถ้าฉันทำให้คุณเสียเวลา |
| AI | มันสนุกและท้าทายมาก ช่วง Warmup ค่อนข้างน่าสับสนเพราะดูเหมือนโจทย์จะมีปัญหาบางอย่าง แต่โดยรวมแล้วทั้งหมดนี้เป็นประสบการณ์การเรียนรู้ที่สนุกมาก |
| AI | ฉันหวังว่าฉันจะสละเวลาทำความเข้าใจคำอธิบายจาก Cosmo (ชื่อผู้ช่วย AI) ให้มากกว่านี้อีกสักหน่อย! |
| AI | ฉันทำงานช้า ฉันคิดว่าการจำกัดเวลาทำให้ฉันแสดงพฤติกรรมที่ไม่เป็นไปตาม Workflow ปกติของฉัน โดยเฉพาะสัดส่วนของเวลาที่ใช้ในการสร้างโมเดลทางความคิด (Mental models) เทียบกับการพยายามให้ได้ผลลัพธ์โค้ดออกมา ฉันมีความปรารถนาที่จะทำความเข้าใจ Trio ให้มากกว่าที่ฉันอนุญาตให้ตัวเองทำในตอนนั้น เพราะฉันรู้ว่าฉันจะไม่มีเวลาพอ ฉันยังคิดว่าสมาธิของฉันกระจัดกระจายไปเพราะพยายามเร่งทำงานดูเหมือนว่า Trio จะทำงานคล้ายกับ Library อื่นๆ มาก ซึ่งทำให้ฉันตระหนักว่าฉันไม่ได้คุ้นเคยกับมันอย่างที่เคยคิดไว้ ความรู้สึกของฉันหลังจากนี้คือมันอาจจะมีความแตกต่างในเรื่อง Execution model แต่ฉันยังเจาะลึกไม่มากพอที่จะทำความเข้าใจพวกมัน ฉันประหลาดใจที่เรื่องง่ายๆ อย่างการทำความเข้าใจเมธอด start\_soon กลายเป็นว่าฉันแทบไม่ได้เรียนรู้อะไรจากมันเลยในแง่ของความเข้าใจที่ลึกซึ้ง ขอบคุณที่ให้ฉันเข้าร่วมนะ! |
| AI | อันนี้สนุกดี! ฉันหวังว่าฉันจะให้ความสนใจกับไวยากรณ์ (Syntax) ของ Trio มากกว่านี้ในตอนที่เขียนโค้ดกับ Cosmo |
ตารางที่ 6: ความเห็นจากผู้เข้าร่วมในเงื่อนไขกลุ่ม AI
| เงื่อนไข (Condition) | ความเห็น (Feedback) |
|---|---|
| No AI | มันสนุกมาก แต่ขั้นตอนการบันทึกหน้าจออาจจะยุ่งยากในบางระบบ และทำให้เกิดความกังวลเล็กน้อย โดยเฉพาะเมื่อคุณไม่สามารถย้อนกลับไปแก้ไขได้หากคุณทำวิดีโอบันทึกผิดพลาด |
| No AI | มันสนุกที่ได้เรียนรู้เกี่ยวกับ Asynchronous programming ซึ่งฉันไม่เคยเจอมาก่อน ฉันคิดว่าฉันน่าจะทำได้ดีกว่านี้มากถ้าฉันสามารถเข้าถึงโจทย์การเขียนโค้ดที่ฉันทำในส่วนที่ 2 ได้ในระหว่างทำควิซเพื่อใช้อ้างอิง แต่ฉันก็พยายามอย่างเต็มที่แล้ว ฉันทำเวลาไม่ทันเพราะคำถามเกี่ยวกับการหาบั๊ก (Bug-finding) ค่อนข้างท้าทายสำหรับฉัน |
| No AI | อันนี้สนุกดี |
| No AI | โจทย์การเขียนโค้ดสนุกมากและช่วยให้ฉันเข้าใจการทำงานของ Trio ได้ดี แม้ว่าจะไม่เคยใช้มันมาก่อนเลยก็ตาม ฉันใช้เวลากับควิซนี้มากเกินไป แต่นั่นเป็นเพราะการบริหารจัดการเวลาของฉันเอง ต่อให้ฉันไม่ได้ใช้เวลานานเกินไปในส่วนแรก ฉันก็คิดว่ามันน่าจะเป็นการทำเวลาที่สูสีมากสำหรับฉันภายในกรอบเวลา 30 นาที |
ตารางที่ 7: ความเห็นจากผู้เข้าร่วมในเงื่อนไขกลุ่มไม่ใช้ AI (Control condition)
ภาคผนวก C รายละเอียดการประเมินผล (Appendix C Evaluation Details)
C.1 การออกแบบการประเมินผล (Evaluation Design)
ภาพที่ 20: ตัวอย่างประเภทของคำถามจากการประเมินผลของเรา เราออกแบบการประเมินเพื่อทดสอบทักษะซอฟต์แวร์ที่แตกต่างกัน 3 ด้าน: ความเข้าใจเชิงมโนทัศน์ การอ่านโค้ด และการเขียนโค้ด
ประเภทของคำถาม: เราได้อภิปรายเกี่ยวกับคำถามทั้ง 3 ประเภทที่เราใช้ ได้แก่: ความเข้าใจเชิงมโนทัศน์ (Conceptual Understanding), การอ่านโค้ด (Code Reading) และการ Debugging ในส่วนที่ 4.2
หมวดหมู่ความรู้:
การประเมินผลครอบคลุม 7 มโนทัศน์หลักจาก Library Trio:
- คีย์เวิร์ด Async และ await: การใช้คีย์เวิร์ด
awaitภายในasync functionsตัวอย่างเช่น: “จะเกิดอะไรขึ้นเมื่อมีการใช้คีย์เวิร์ดawaitในasync function?” - การเริ่มต้นฟังก์ชัน Trio: การใช้งาน
Trioเบื้องต้น รวมถึงวิธีการสร้าง Task (Spawning tasks) และพฤติกรรมของ Task ที่สร้างขึ้นซึ่งมีระยะเวลาการทำงานที่แตกต่างกัน - การจัดการข้อผิดพลาด (Error handling) ใน Trio: ทำความเข้าใจรูปแบบการส่งต่อข้อผิดพลาด (Error propagation patterns) และวิธีดักจับข้อผิดพลาดใน Task ลูก (Child tasks) ตัวอย่างเช่น: “จะเกิดอะไรขึ้นกับ Task แม่ (Parent task) เมื่อ Task ลูกเกิดข้อผิดพลาดที่ไม่มีการจัดการ (Unhandled exception) ใน
Trio?” - Coroutine: เมื่อมีการเรียกใช้ Async function จะต้อง Debug ข้อผิดพลาดประเภท 'Coroutine never awaited' ได้อย่างไร
- การใช้ Memory channels ใน Trio: ทำความเข้าใจว่า
start\_soonจะไม่คืนค่าใดๆ กลับมา และวิธีใช้ Dictionary, List และ Memory channel อื่นๆ เพื่อรวบรวมข้อมูลเมื่อรันหลาย Task พร้อมกัน - การเปิดและปิด Trio nursery: ทำความเข้าใจเกี่ยวกับ Asynchronous context managers และวิธีใช้งาน ตัวอย่างเช่น คำถามด้าน Debugging ที่ประกอบด้วยส่วนของโค้ดที่เริ่มใช้งาน Nursery อย่างไม่ถูกต้อง
- การรันแบบลำดับเทียบกับการรันแบบขนาน (Sequential vs concurrent execution): พฤติกรรมที่คาดหวังของ Task ที่รันแบบขนาน ตัวอย่างเช่น: “จงอ่านโค้ดต่อไปนี้และระบุว่าแต่ละ Task เริ่มต้นและเสร็จสิ้นเมื่อใด”
ภาคผนวก D รายละเอียดโจทย์ (Appendix D Task Details)
ภาพที่ 21: คำปฏิญาณที่ทำโดยผู้เข้าร่วมกลุ่มควบคุม: ผู้เข้าร่วมตกลงที่จะไม่ใช้ความช่วยเหลือจาก AI
ภาพที่ 22: คำปฏิญาณที่ทำโดยผู้เข้าร่วมกลุ่มทดลอง
ภาพที่ 23: คำแนะนำที่ให้แก่ผู้เข้าร่วมกลุ่มควบคุม เราเน้นย้ำอย่างมากเรื่องการไม่ใช้เครื่องมือ AI
ภาพที่ 24: คำแนะนำที่ให้แก่ผู้เข้าร่วมกลุ่มทดลอง กลุ่มนี้ได้รับการสนับสนุนให้ใช้ผู้ช่วย AI เพื่อทำโจทย์ให้เสร็จเร็วที่สุดเท่าที่จะเป็นไปได้
ภาพที่ 25: ภาพหน้าจอของแพลตฟอร์มโจทย์ในเงื่อนไขกลุ่มควบคุม คำแนะนำอยู่ทางด้านซ้ายและหน้าต่างแก้ไขโค้ด (Coding editor) อยู่ทางด้านขวา
ภาพที่ 26: ภาพหน้าจอของแพลตฟอร์มโจทย์ในเงื่อนไขกลุ่ม AI คำแนะนำอยู่ทางด้านซ้ายและหน้าต่างแก้ไขโค้ดอยู่ทางด้านขวา มีการสะกิดให้ใช้ผู้ช่วย AI อยู่ที่แผงเครื่องมือทางด้านซ้าย
ภาพที่ 27: ภาพหน้าจอของแพลตฟอร์มโจทย์ในขณะที่กำลังปฏิสัมพันธ์กับผู้ช่วย AI