- แม้นักพัฒนาจะ ใช้เครื่องมือ AI Coding อย่างแพร่หลาย จนทำให้ผลิตภาพสูงขึ้น แต่ก็กำลังก่อให้เกิด ต้นทุนด้านการรับรู้และต้นทุนเชิงองค์กร ที่มองไม่เห็น
- จากเครื่องมือแบบผู้ช่วยในช่วงแรกอย่าง Copilot·Cursor ล่าสุดได้พัฒนาไปเป็น เอเจนต์อัตโนมัติ และเปลี่ยนโครงสร้างไปสู่รูปแบบที่มนุษย์ต้องคอยช่วย AI
- อย่างไรก็ตาม การใช้งานแบบมอบหมายทั้งหมดนำไปสู่ หนี้ทางการรับรู้ (cognitive debt) และ ความสามารถในการดีบักที่ลดลง ทำให้ ทักษะการแก้ปัญหาและความเข้าใจโค้ด ของนักพัฒนาอ่อนแอลง
- โครงสร้างที่ AI เขียนโค้ดและมนุษย์มีหน้าที่เพียงรีวิว ก่อให้เกิด การพังทลายของเส้นทางการเติบโตสู่ระดับซีเนียร์ และการสูญเสีย ภาวะลื่นไหลเชิงสร้างสรรค์ (flow) จนกัดกร่อนขีดความสามารถทางเทคนิคขององค์กรในระยะยาว
- การใช้ AI เป็นสิ่งจำเป็น แต่ควร กำหนด ‘จุดวิกฤตของการใช้งานที่เหมาะสม’ ด้วยตนเอง และปรับวิธีใช้ให้ยังคงการทำความเข้าใจและการเรียนรู้ของมนุษย์ไว้
วิวัฒนาการของการนำ AI Coding มาใช้
- Copilot·Cursor และเครื่องมืออื่น ๆ ที่ปรากฏในช่วงปี 2022~2023 ใช้การทำดัชนีโค้ดเบสเพื่อให้ฟังก์ชัน autocomplete และแชตตามบริบท
- การค้นหาผ่าน Google หรือ StackOverflow แทบไม่จำเป็นอีกต่อไป และสภาพแวดล้อม IDE ที่ฝัง AI ก็แพร่หลายมากขึ้น
- ต่อมามี เวิร์กโฟลว์แบบเอเจนต์ ที่เปลี่ยนจากการให้ AI เป็นผู้ช่วยมนุษย์ ไปสู่ การพัฒนาที่ขับเคลื่อนโดย AI
- แต่เอเจนต์ยังมีปัญหาความน่าเชื่อถือ เช่น การวนลูป การหลอนข้อมูล และข้อผิดพลาดด้าน dependency
- หลัง Opus 4.5 ระดับของระบบอัตโนมัติก็สูงขึ้น และเริ่มมีบางบริษัทที่นักพัฒนาไม่ได้เขียนโค้ดด้วยตนเอง
- ตัวอย่าง: ผู้ร่วมดำรงตำแหน่ง CEO ของ Spotify กล่าวว่าวิศวกรสามารถ สั่ง Claude ใน Slack เพื่อแก้ไขฟีเจอร์และดีพลอยได้เลย
หนี้ทางการรับรู้และการเสื่อมถอยของทักษะ
- มีการอ้างถึงแนวคิด ‘Digital Dementia’ ของ Manfred Spitzer และ ‘Cognitive Debt’ ของ Margaret-Anne Storey
- เมื่อมอบหมายการคิดซ้ำ ๆ ให้ AI เส้นทางการทำงานของสมองจะอ่อนแอลง และความเข้าใจโค้ดก็ลดลง
- งานวิจัยของ Shen·Tamkin(2026): จากนักพัฒนา 52 คน กลุ่มที่ใช้ AI ช่วยได้ คะแนนต่ำกว่า 17% ในด้านความเข้าใจเชิงแนวคิด การดีบัก และการอ่านโค้ด
- โดยเฉพาะความสามารถในการดีบักที่ลดลงอย่างชัดเจน และพบว่า เพียงใช้ AI แบบรับอย่างเดียวเป็นเวลา 1 ชั่วโมง ก็เกิดการเสื่อมถอยของทักษะที่วัดได้
- เมื่อ AI รับมือโจทย์ท้าทายแทนทั้งหมด จะก่อให้เกิดภาวะ ‘dark flow’ แทนที่จะเป็น ‘flow ที่แท้จริง’ ทำให้เกิดการพึ่งพามากขึ้นโดยไม่เกิดการเรียนรู้
ความย้อนแย้งของโค้ดรีวิวและการพังทลายของซีเนียร์
- หาก AI เป็นผู้เขียนโค้ดและมนุษย์มีหน้าที่เพียงรีวิว จะเกิด ความย้อนแย้งที่รากฐานของความสามารถในการรีวิวหายไปเอง
- นักพัฒนาที่พึ่งพา AI อย่างเต็มที่ทำงานได้เร็ว แต่ ได้คะแนนประเมินต่ำที่สุด
- Storey เสนอว่า “ก่อนดีพลอย มนุษย์ต้องเข้าใจการเปลี่ยนแปลงที่ AI สร้างขึ้นอย่างครบถ้วน”
- แม้ AI จะมอบ ผลลัพธ์ระดับซีเนียร์ ให้ผู้เริ่มต้นได้ แต่ก็เป็นเพียง การลอกเลียนโดยปราศจากความเข้าใจ
- ซีเนียร์สูญเสียความลึกเพราะไม่ได้เขียนโค้ดเอง ส่วนจูเนียร์ก็ไม่เติบโตเพราะไม่ได้ผ่านการลองผิดลองถูก
- ผลลัพธ์คือ pipeline การเติบโตสู่ซีเนียร์พังทลาย
การตัดสินใจผิดพลาดของผู้บริหารและผลข้างเคียงระดับองค์กร
- ผู้บริหารของ Microsoft, Anthropic, Google และบริษัทอื่น ๆ คาดว่า AI จะ เข้ามาแทนที่วิศวกร ภายในไม่กี่เดือน
- Google รายงานว่า ณ ปลายปี 2024 โค้ดใหม่ 50% ถูกสร้างโดย AI
- แต่ตัวเลขลักษณะนี้เป็น การพูดเกินจริงเพื่อขาย AI หรือหนุนราคาหุ้น และไม่สามารถนำไปใช้กับองค์กรทั่วไปได้
- บางบริษัทถึงขั้น วัดปริมาณการใช้ AI เป็น KPI และบังคับใช้กับนักพัฒนา
- กรณีของ Reddit: นักพัฒนาบางคน ปั่นตัวเลขการใช้ AI ด้วยการสั่งงานที่ไร้ความหมาย
- ผลคือเกิด กฎของ Goodhart แทนที่จะเพิ่มผลิตภาพ กลับเหลือเพียง การทำตามอย่างเป็นพิธีการ
ต้นทุนด้านความเป็นมนุษย์และการสูญเสียความคิดสร้างสรรค์
- การเขียนโค้ดมอบ ความสุขจากการจดจ่อและการสร้างสรรค์ แต่การรีวิวโค้ดของ AI กลับทำให้เกิด ความเหนื่อยล้าทางจิตใจ
- เมื่อรางวัลโดพามีนจากการสร้างสรรค์หายไป ก็ยิ่ง เร่งภาวะหมดไฟ
- การพัฒนาซอฟต์แวร์เสื่อมสภาพจนกลายเป็น การควบคุมคุณภาพ (QA) และ ความพึงพอใจเชิงสร้างสรรค์ ก็หายไป
- มีการเปรียบเทียบว่านี่เหมือนกับสถานการณ์ที่ AI ทำงานศิลปะทั้งหมดแทนมนุษย์ และมนุษย์เหลือหน้าที่เพียง ‘พับผ้า’
จุดวิกฤตของการใช้ AI ที่เหมาะสม
- AI เป็นเครื่องมือที่ทรงพลัง แต่ ไม่ใช่ว่ายิ่งใช้น้อยหรือยิ่งใช้มากจะยิ่งดี
- งานวิจัยของ Shen·Tamkin ระบุว่า จากรูปแบบการโต้ตอบกับ AI 6 แบบ
- ‘มอบหมายทั้งหมด·พึ่งพาเพิ่มขึ้นทีละน้อย·ฝากการดีบักให้ AI’ เป็นรูปแบบที่ขัดขวางการเรียนรู้
- ‘ขอคำอธิบาย·ถามเชิงแนวคิด·เขียนโค้ดเองก่อนแล้วค่อยตรวจสอบ’ เป็นรูปแบบที่ช่วยคงการเรียนรู้ไว้
- หัวใจสำคัญคือการคงการมีส่วนร่วมทางการรับรู้ ไม่ใช่แค่ใช้หรือไม่ใช้ แต่คือ ใช้แบบไหน
- หากไม่ใช้ AI เลย ก็จะเสียประสิทธิภาพด้าน การค้นหา การเขียน boilerplate และการสำรวจทางเลือก ไป
แต่หากใช้มากเกินไป ก็จะกระทบ ความเข้าใจ การเติบโตสู่ซีเนียร์ การตรวจจับบั๊ก และภาวะลื่นไหลในการทำงาน
ความเสื่อมถอยที่เกิดขึ้นอย่างเงียบงัน
- ในเชิงตัวชี้วัดอาจเห็นว่า จำนวน PR จำนวนฟีเจอร์ และ cycle time ดีขึ้น
แต่ ทักษะภายใน สมาธิ และความสามารถในการแก้ปัญหา กลับค่อย ๆ อ่อนแอลง
- นักพัฒนากลายเป็น ‘หุ่นยนต์ทาเนย’ ที่ ไม่เข้าใจโครงสร้างที่ AI สร้าง แต่กดอนุมัติอย่างเดียว
- Simon Willison ก็กล่าวถึงโครงการหนึ่งว่าเพราะไม่ได้รีวิวฟีเจอร์ที่ AI สร้าง
เขาจึง “ไม่เข้าใจการทำงานภายในได้อย่างชัดเจนอีกต่อไป”
- สุดท้ายแล้ว ไม่ใช่เครื่องมือที่เสื่อมลง แต่มนุษย์ต่างหากที่กำลังเสื่อมถอย และการเปลี่ยนแปลงนี้ก็ ทั้งไม่ถูกวัดและไม่ถูกจัดการ
- การพึ่งพา AI ดำเนินไปคล้ายการเสพติด และเสี่ยงจะนำไปสู่ ความเสื่อมถอยของทักษะอย่างเงียบงันแต่มีอยู่จริง
1 ความคิดเห็น
ความคิดเห็นจาก Hacker News
ผมยังคงมองว่า การเขียนโค้ดด้วยตัวเองและวาดโครงสร้างมันในหัว เป็นหนึ่งในความสุขของงานนี้
แม้แต่การรีแฟกเตอร์ที่ซ้ำ ๆ หรือน่ารำคาญก็ยังเป็นกระบวนการที่มีความหมายสำหรับผม
ช่วงเวลาที่ยากลำบากเหล่านี้กลายเป็นวัตถุดิบของการเรียนรู้ที่ทำให้ครั้งหน้าหาวิธีที่ดีกว่าได้
มันยังคงเป็น ความหวัง ว่าสักวันหนึ่งกระแสนี้จะย้อนกลับมาอีกครั้ง
ผมเชื่อว่าสักวันหนึ่งคุณค่าของคนที่ยังรักษา ความสามารถในการเลือกและตัดสินใจด้วยตัวเอง ไว้ได้ จะได้รับการยอมรับอีกครั้ง
ถ้าโค้ดเทสต์ยาก ก็แปลว่าควรเปลี่ยน abstraction หรือ interface
เทสต์คือการนำโค้ดกลับมาใช้ซ้ำครั้งแรก ดังนั้นถ้าเทสต์ใช้งานลำบาก เวลานำไปใช้จริงก็น่าจะลำบากเหมือนกัน
ยิ่งเป็นโค้ดที่ผมเขียนเอง ยิ่งนึกภาพได้ง่ายว่าปัญหาน่าจะเกิดตรงไหน
ต่อให้โยน log ให้ LLM มากแค่ไหน มันก็แทนที่สัญชาตญาณแบบนี้ไม่ได้
แต่ก็แอบกังวลว่าแบบนี้จะทำให้ แรงจูงใจในการพัฒนา ecosystem ฝั่งฟรอนต์เอนด์ หายไปหรือเปล่า
แม้แต่งานที่คนอยากโยนให้ LLM ทำ ผมก็ยังสนุกที่จะทำเอง
เวลามองบริษัทต่าง ๆ ค่อย ๆ แย่ง ความสุขเล็ก ๆ น้อย ๆ แบบนี้ไป ก็รู้สึกเศร้า
ตลอด 1 ปีที่ผ่านมา ผมใช้ Claude Code เยอะมาก และช่วงหลังเริ่มรู้สึกถึง การเปลี่ยนแปลงทางอารมณ์ ของเพื่อนร่วมงานต่อการใช้ AI
ผมเลยเขียนเรื่อง ต้นทุนแฝง ที่เกิดจากการใช้ AI มากเกินไป และลองรวบรวมข้อมูลจากหลายแหล่ง
แม้ตอนนี้ยังไม่มีข้อมูลที่ชัดเจนนัก แต่ดูเหมือนนักพัฒนาหลายคนจะรู้สึกคล้าย ๆ กัน
แต่คำว่า “ซอฟต์แวร์ก็เป็นแค่เครื่องมือ” ฟังดูแปลกสำหรับผมเสมอ
เมื่อเครื่องมือสามารถคิดแทนเราได้ เรายังจะเรียกมันว่า “เครื่องมือ” ได้อีกหรือ?
ผมชอบคำว่า “prompt addiction” ที่พูดตรงไปตรงมา แต่ก็น่าจะลองสำรวจมุมของ behavioral addiction ด้วย
มันเร็วและเหมือนควบคุมได้ แต่เรากลับค่อย ๆ สูญเสียการควบคุมไปทีละน้อย
เรื่องยากจริง ๆ คือการหาว่า “จะใช้มันด้วยความเร็วระดับไหนถึงจะยั่งยืน”
ผมเองก็เคยเขียนบล็อกโพสต์ ในประเด็นคล้ายกัน
โดยมองจากมุมของผู้นำที่ต้องช่วยให้องค์กรหา สมดุลที่ยั่งยืน ให้เจอ
ผมไปค้นงานวิจัยเกี่ยวกับ working memory และ ระบบรางวัล ว่ามีผลต่อการเรียนรู้และการจดจ่ออย่างไร
เช่นใน บทความ Nature บอกว่า working memory มี การตอบสนองต่อโดปามีน
และ บทความ Scientific American ก็ระบุว่าการเขียนด้วยมือกระตุ้นสมองได้หลายส่วนมากกว่า
สุดท้ายแล้ว ในงาน เชิงรับที่ให้รางวัลต่ำ ผลดีทางการรับรู้แบบนี้แทบไม่เกิดขึ้นเลย
เพราะงั้นผมเลยคิดว่าเกณฑ์ในการใช้ AI ควรอยู่ที่ “งานนั้นเจ็บปวดและให้รางวัลต่ำแค่ไหน”
ผมยังคง เขียนโค้ดเอง และเข้าใจผลลัพธ์ของมันอย่างครบถ้วน
ผมไม่สนเรื่องเพิ่มความเร็ว สิ่งสำคัญคือ ความเป็นเจ้าของ ว่านี่คือโค้ดของผม
สมัยก่อนผมก็จ้างคนนอกทำได้เหมือนกัน แต่แบบนั้นมันคือเส้นทางที่จะทำให้ผมเหลือบทบาทแค่อ่านโค้ด
เพราะผมกับนักพัฒนารอบตัวส่วนใหญ่รู้สึกถึงแรงกดดันแบบนั้น
ใช้คีย์บอร์ดก็ไม่ได้ทำให้เราลืมเขียนหนังสือ และซื้อกาแฟกินก็ไม่ได้ทำให้เราลืมชงกาแฟ
ช่วงต้นยุค 80 ผมเริ่มเรียนเขียนโค้ดด้วย LSI-11 assembly และท่อง opcode แบบฐานแปด ได้ทั้งหมด
แต่พอมาเรียน FORTRAN 83 ผลิตภาพกลับเพิ่มขึ้น 10 เท่า และผมก็ไม่เสียดายเลยแม้ทักษะยุคนั้นจะฝ่อไป
สักวันหนึ่งภาษาอย่าง C++ หรือ Java ก็คงกลายเป็น ทักษะที่ไม่จำเป็นอีกต่อไป เช่นกัน
ความคิดเชิงตรรกะ ที่สะสมจากการจัดการ opcode ต่างหาก ที่ทำให้การเรียนภาษาถัดมาง่ายขึ้น
วิธีคิดแบบจัดการกับ formal language พวกนี้ลึกทางการรับรู้มากกว่าการเขียน prompt ให้ LLM มาก
แต่การทำงานร่วมกับ AI คือการสื่อเจตนาด้วย ภาษาธรรมชาติที่กำกวม
ถ้าไม่ได้เขียน pseudocode เป็นภาษาอังกฤษ ความแม่นยำก็จะยิ่งลดลง
แถมครั้งนี้ยังมี ความกลัวว่าจะถูกแทนที่ ติดมาด้วย
ถ้ายึด สามรูปแบบการใช้ AI ที่เหมาะสมไว้ได้ ก็จะได้ทั้งผลิตภาพและการเรียนรู้
แต่ถ้าเดินตาม anti-pattern ก็จะนำไปสู่การพึ่งพาเครื่องมือ ความกังวล ความสามารถในการ debug ที่ลดลง และการเสพติดรางวัลฉับพลัน
สุดท้ายก็จะเกิด วงจรเลวร้ายของการเสื่อมถอยทางการรับรู้
ไม่นานมานี้ผมเพิ่งเข้าบริษัทที่ ขับเคลื่อนด้วย AI และบรรยากาศเหมือนแทบห้ามเขียนโค้ดเอง
ผมให้ Claude อ่านเอกสาร API แล้วสร้าง wrapper ขึ้นมา ผลลัพธ์ออกมาสมบูรณ์แบบ
แต่ตัวผมเองกลับ ไม่เข้าใจสัมผัสหรือโครงสร้างของ API เลย
สภาพที่ “ทำอะไรได้เยอะ แต่ไม่รู้อะไรเลย” แบบนี้ทั้ง อึดอัดและว่างเปล่า
ความจำเชิงสะท้อนไม่ได้ถูกสั่งสมขึ้นมา เลยรู้สึกเห็นด้วยกับบทความนี้อย่างมาก
ผมกำลังทำ side project ที่ AI เขียน หลายตัว
แต่มันก็เป็นความรู้สึกแปลก ๆ แบบ “คิดว่าดี แต่ก็ไม่มั่นใจ”
สรุปคือ ต่อให้สร้างร่วมกับ AI เราก็ต้องทิ้ง ร่องรอยของตัวเอง ไว้ ถึงจะรู้สึกถึงความสำเร็จได้
ผมเพิ่งเริ่มเขียนโค้ดมาได้แค่ 8 เดือน และ เรียนรู้ได้เพราะ AI
แต่เวลาที่ Claude เขียนโค้ดให้ ผมเข้าใจแค่ 70% อีกส่วนก็ปล่อยผ่านไป
ความเร็วแบบนี้มันเสพติด แต่ ความสามารถในการคงโครงสร้างทั้งหมดไว้ในหัว กลับลดลง
ถึงอย่างนั้น ถ้าไม่มี AI ผมก็คงสร้างสิ่งที่ทำอยู่ตอนนี้ไม่ได้ ดังนั้นก็ยอมรับ trade-off นี้
ตัวอย่างเช่นชอบใส่ fallback code เกินความจำเป็น
ถ้าไม่มีประสบการณ์ก็อาจไม่รู้ว่านั่นเป็นสิ่งที่ผิด
ระดับของ LLM ตอนนี้อยู่ราว ๆ นักพัฒนาฝึกงานถึงจูเนียร์
คอขวดไม่ใช่ตัวโมเดล แต่คือ ความสามารถของเราในการตรวจสอบ
ผมสงสัยว่าเราจำเป็นต้องใช้ LLM เพื่อ ทำ boilerplate ให้เป็นอัตโนมัติ จริงหรือ
หรือจริง ๆ แล้วใช้ metaprogramming หรือสคริปต์แบบเดิมก็น่าจะพอ?
อีกอย่าง การปฏิเสธ AI โดยหลักการก็อาจเป็นทางเลือกแบบหนึ่งที่ ให้ความพึงพอใจ ได้เหมือนกัน
ทั้งการใช้เมาส์และคีย์บอร์ด การสำรวจไฟล์ การค้นหาคำสั่ง พื้นฐานยังไม่แน่น
เลยยิ่งเกิดแรงยั่วยุว่า “งั้นก็ถาม LLM ไปเลย”
แต่ทางแก้จริง ๆ คือ เพิ่มความชำนาญในการใช้เครื่องมือ และ เรียนรู้ template engine
AI อาจทำให้เกิด การเสื่อมของทักษะ ได้
แต่ถ้ามันเป็นด้านที่ผมไม่ได้อยากโฟกัส ผมก็คิดว่าไม่เป็นไร
เช่น ผมไม่จำเป็นต้องรู้ลึกถึงการ optimize ภายในของ compiler
ถ้าจะเข้าใจการทำงานร่วมกันของหลายระบบ ก็ต้องรู้ หลักการทำงานของ compiler อยู่บ้าง
ส่วนที่ไม่อยากสนใจก็ปล่อยให้ LLM จัดการ
แล้วเอา ทรัพยากรทางสมอง ไปโฟกัสกับปัญหาที่สำคัญจริง ๆ