ผลการศึกษาล่าสุดของ Anthropic แสดงให้เห็นว่านักพัฒนาที่พึ่งพา AI ในการสร้างโค้ด (code generation) มีคะแนนทดสอบความเข้าใจในเชิงแนวคิด (concept-understanding) ต่ำกว่าถึง 17 เปอร์เซ็นต์ และไม่ได้ทำงานเสร็จเร็วกว่าเพื่อนร่วมงานที่ใช้วิธีค้นหาจากเอกสารประกอบ (documentation) และการค้นหาทางเว็บแต่อย่างใด ผลการศึกษานี้เน้นย้ำว่า แม้ AI จะสามารถผลิตโค้ดที่ใช้งานได้ภายในไม่กี่วินาที แต่มันไม่ได้ช่วยลดต้นทุนของความเชี่ยวชาญด้านวิศวกรรมที่แท้จริงลงได้

ทำไมการศึกษานี้จึงสำคัญ

การทดลองนี้แบ่งนักพัฒนาออกเป็นสองกลุ่ม กลุ่มหนึ่งได้รับสิทธิ์เข้าถึงเครื่องมือสร้างโค้ดด้วย AI อย่างไม่จำกัด ส่วนอีกกลุ่มแก้ปัญหาเดียวกันโดยใช้เพียงเอกสารประกอบอย่างเป็นทางการและการค้นหาทางอินเทอร์เน็ต หลังจากเสร็จสิ้นการมอบหมายงาน ผู้เข้าร่วมได้ทำแบบทดสอบเพื่อวัดความเข้าใจในหลักการพื้นฐาน พบว่าคะแนนเฉลี่ยของกลุ่มที่ใช้ AI ช่วยเหลือนั้นตามหลังอยู่ 17 เปอร์เซ็นต์ และไม่มีกลุ่มใดที่มีความได้เปรียบด้านความเร็วอย่างมีนัยสำคัญ

ในทางปฏิบัติ "vibe coding" — การเขียน prompt เพื่อให้ AI สร้างโค้ดส่วนหนึ่ง (snippet) แล้วนำไปใช้งานทันทีโดยไม่มีการตรวจสอบอย่างละเอียด — ไม่ได้ช่วยเพิ่มผลิตภาพ (productivity) แต่มันเป็นเพียงการปกปิดช่องว่างทางความรู้ ซึ่งจะกลายเป็นปัญหาในภายหลัง ไม่ว่าจะเป็นบั๊ก (bugs) ความยุ่งยากในการบำรุงรักษา หรือการต้องเขียนโค้ดใหม่ที่มีต้นทุนสูง

บริบทเบื้องหลังตัวเลขเหล่านี้

งานวิจัยของ Anthropic แสดงให้เห็นว่าความคาดหวังนั้นยังไม่สมบูรณ์ ผู้เข้าร่วมที่ใช้ AI ในทุกขั้นตอน เช่น การคัดลอกและวางคำแนะนำ การปรับเปลี่ยนชื่อตัวแปร แล้วข้ามไปทำส่วนอื่น เป็นกลุ่มที่เรียนรู้เกี่ยวกับขอบเขตของปัญหาได้น้อยที่สุด ในขณะที่นักพัฒนาที่ใช้เครื่องมือนี้ในฐานะผู้ร่วมงาน — โดยการตั้งคำถามที่แม่นยำและเฉพาะเจาะจง แล้วจึงนำโค้ดที่ได้มาวิเคราะห์อย่างละเอียด — จะสามารถจดจำโครงสร้างเชิงแนวคิดได้มากกว่า

ความแตกต่างนี้สะท้อนถึงสิ่งที่สังเกตเห็นได้ในอุตสาหกรรมในวงกว้าง นั่นคือ prompt engineer อาจเขียนฟังก์ชันเสร็จได้ภายในไม่กี่นาที แต่ systems engineer จะทำงานได้รวดเร็วกว่าเมื่อความซับซ้อนเพิ่มขึ้น เนื่องจากพวกเขาสามารถคาดการณ์ได้ว่าอะไรจะพังหรืออะไรที่จะไม่สามารถขยายระบบได้ (scale) ความเร็วของพวกเขาจึงสะท้อนถึงการใช้ดุลยพินิจ ไม่ใช่ความไร้ประสิทธิภาพ

ใครคือผู้ชนะ และใครคือผู้แพ้

วิศวกรที่รักษาการใช้ดุลยพินิจ วิศวกรที่เข้าใจสถาปัตยกรรม (architecture) รู้ว่าโครงสร้างส่วนใดควรจะตายตัวหรือยืดหยุ่น และสามารถเขียนส่วนประกอบใหม่ได้โดยไม่ทำให้ระบบพัง จะช่วยประหยัดเงินให้องค์กรในระยะยาว ทักษะของพวกเขาช่วยป้องกันหนี้ทางเทคนิค (technical debt) ที่ซ่อนอยู่ ซึ่งมักจะตามมาหลังจากใช้โค้ดที่สร้างโดย AI ที่ดูสะอาดตาแต่ขาดเจตนาที่ชัดเจนในการเขียน

ผู้เชี่ยวชาญด้าน prompt ผู้ที่มองว่า AI เป็นเหมือนไม้กายสิทธิ์อาจสามารถสร้างต้นแบบ (prototype) ได้อย่างรวดเร็วหรือแก้บั๊กเฉพาะจุดได้ ในระยะสั้นพวกเขาอาจดูเหมือนมีผลิตภาพสูง แต่เมื่อฐานโค้ด (codebase) ขยายใหญ่ขึ้น ข้อสันนิษฐานที่ซ่อนอยู่ในโค้ดส่วนที่ AI สร้างขึ้นจะกลายเป็นภาระ การดีบั๊ก (debugging) จะกลายเป็นการตามหาเจตนาเดิมของผู้เขียน ซึ่งทำให้ต้นทุนในการบำรุงรักษาสูงขึ้น

องค์กร ธุรกิจที่พึ่งพาการพัฒนาด้วย AI เพียงอย่างเดียวมีความเสี่ยงที่จะต้องแบกรับค่าใช้จ่ายที่สูงขึ้นในอนาคต ทั้งการเสียเวลาไปกับการดีบั๊ก การปรับปรุงโครงสร้างโค้ด (refactoring) และการรับวิศวกรใหม่เข้ามาซึ่งต้องมานั่งตีความโค้ดที่คลุมเครือ ในขณะที่บริษัทที่ผสมผสานการใช้ AI เข้ากับแนวทางวิศวกรรมที่มีระเบียบวินัย จะได้รับประโยชน์ด้านความเร็วควบคู่ไปกับการรักษาความเสถียรในระยะยาว

รายละเอียดที่รายงานส่วนใหญ่มักข้ามไป

  • ผลกระทบต่อการเรียนรู้: ช่องว่าง 17 เปอร์เซ็นต์นี้วัดจากแบบทดสอบที่ทดสอบความเข้าใจ ไม่ใช่แค่การจดจำไวยากรณ์ (syntax) ได้ ซึ่งบ่งชี้ถึงการเสื่อมถอยของแบบจำลองทางความคิด (mental models) อย่างแท้จริง ไม่ใช่แค่ความรู้เพียงผิวเผิน
  • เวลาที่ใช้ในการทำงานให้เสร็จ: แม้ว่าการได้โค้ดมาทันทีจะดูน่าดึงดูด แต่การศึกษากลับไม่พบความแตกต่างอย่างมีนัยสำคัญทางสถิติในเรื่องระยะเวลาที่แต่ละกลุ่มใช้ในการทำงานให้เสร็จสิ้น ความเร็วที่เพิ่มขึ้นนั้นเป็นเพียงภาพลวงตา
  • วิธีการเป็นเรื่องสำคัญ: การศึกษานี้ชี้ให้เห็นถึงระดับการใช้งาน AI ที่แตกต่างกัน การพึ่งพา AI เพียงอย่างเดียวให้ผลลัพธ์การเรียนรู้ที่แย่ที่สุด ในขณะที่การใช้ prompt แบบเลือกสรรและมีการตั้งคำถามจะให้ผลลัพธ์ที่ดีกว่า พาดหัวข่าวที่ประกาศว่า “AI ทำให้การเขียนโค้ดเร็วขึ้น” มักจะพลาดรายละเอียดที่สำคัญนี้ไป

ข้อโต้แย้ง: AI ไม่ได้ไร้ประโยชน์

การศึกษานี้ไม่ได้ปฏิเสธประโยชน์เฉพาะด้าน แต่มันเพียงแค่เตือนว่าไม่ควรนำประโยชน์เหล่านั้นมาสรุปเหมารวมกับกระบวนการพัฒนาซอฟต์แวร์ทั้งหมด เมื่อปัญหาเกี่ยวข้องกับการออกแบบระบบ การปรับจูนประสิทธิภาพ (performance tuning) หรือการพิจารณาด้านความปลอดภัย การใช้ดุลยพินิจของมนุษย์ยังคงเป็นสิ่งที่ขาดไม่ได้

บทสรุป

AI อาจจะยื่นสเกตบอร์ดให้คุณ แต่หากปราศจากความรู้เรื่องเบรกและการควบคุมทิศทาง คุณก็อาจจะประสบอุบัติเหตุเมื่อถนนเริ่มโค้งงอ เทคโนโลยีนี้ช่วยลดอุปสรรคในการเขียนโค้ด แต่สิ่งที่ยังคงขาดแคลนคือวิศวกรที่สามารถใช้เหตุผลเชิงระบบ คาดการณ์ความล้มเหลว และดูแลซอฟต์แวร์ให้คงอยู่ต่อไปได้เมื่อมันเติบโตขึ้น การลงทุนในดุลยพินิจเหล่านั้น แทนที่จะหวังว่า prompt จะมาแทนที่ ยังคงเป็นวิธีที่ฉลาดที่สุดในการควบคุมต้นทุนในระยะยาว