Agentic Coding คือกับดัก: นักพัฒนาอาวุโสเตือนทักษะวิศวกรซอฟต์แวร์กำลังถดถอย
บทความชื่อ Agentic Coding is a Trap โดย Lars Faye นักพัฒนาอาวุโส ขึ้นอันดับต้นของ Hacker News ที่ 323 คะแนน 226 คอมเมนต์ ภายในประมาณ 8 ชั่วโมง โต้กระแสที่ทีมพัฒนาทั่วโลกกำลังปล่อยให้ AI agent เขียนโค้ดทั้ง feature โดยมีคนทำหน้าที่เพียง orchestrator
ข้อโต้แย้งหลักของ Faye ไม่ใช่การปฏิเสธ AI แต่ระบุว่ารูปแบบการใช้งานปัจจุบันที่บริษัทผู้ให้บริการโมเดลโปรโมต กำลังเปลี่ยนวิศวกรซอฟต์แวร์จากผู้สร้างเป็นผู้ตรวจ และทักษะที่ใช้ตรวจคือทักษะชุดเดียวกับที่ workflow แบบ agentic ทำให้ฝ่อลง
ประเด็นนี้สำคัญต่อทีมพัฒนาในไทยที่กำลังนำ Cursor, Claude Code และเครื่องมือ agentic อื่นมาใช้ตามกระแส โดยอาจไม่ทันตั้งหลักว่าจะรักษาความเข้าใจในโค้ดและทักษะของทีมระยะยาวอย่างไร
กระแสที่ Faye กำลังโต้
กรอบเล่าเรื่องที่บริษัท AI ผลักออกมาคือ AI ทำการเขียนโค้ด คนเป็น orchestrator คอยกำกับ Faye ระบุว่าภาพนี้ฟังดูเป็นความก้าวหน้าที่ปฏิเสธไม่ได้ แต่จริง ๆ แล้วซ่อนการแลกเปลี่ยนที่หนักกว่าที่หลายคนคิด
ใน บทความต้นฉบับ Faye แจกแจงข้อเสีย 4 ข้อของ agentic coding ได้แก่ ความซับซ้อนของระบบรอบข้างที่ต้องเพิ่มเข้ามารองรับความไม่แน่นอนของ AI ทักษะนักพัฒนาที่ถดถอยในวงกว้าง การพึ่งพา vendor รายเดียวซึ่งอ้างเหตุการณ์ Claude Code ล่มทำให้ทั้งทีมหยุดทำงาน และต้นทุน token ที่คาดเดาไม่ได้เทียบกับเงินเดือนพนักงานที่คงที่
ทั้งสี่ข้อนี้ไม่ใช่การคาดเดา แต่เป็นการแลกเปลี่ยนที่ทีมส่วนใหญ่จ่ายอยู่แล้วในปัจจุบัน เพียงแต่ยังไม่ได้นั่งคำนวณว่าได้เท่าไหร่กับเสียเท่าไหร่
หัวใจของบทความคือ paradox of supervision
ข้อโต้แย้งที่หนักที่สุดของ Faye คือสิ่งที่เขาเรียกว่า paradox of supervision การจะตรวจงาน AI agent ให้ได้ผลจริง ต้องอาศัยทักษะการเขียนโค้ดชุดเดียวกับที่ workflow agentic ทำให้ฝ่อลง ยิ่งเร่งใช้ agent หนัก ยิ่งบั่นทอนความสามารถในการตรวจสอบของตัวเอง
Faye อ้างว่างานวิจัยของ Anthropic เองยอมรับเรื่องนี้ แต่ฝังเอาไว้ในรายงาน โดยระบุตัวเลขจากบทความว่าผู้ที่ใช้ AI ในการเขียนโค้ดอย่างหนักมีทักษะ debugging ลดลงถึง 47% รายงานสายอื่นเช่น InfoQ และ DevClass ที่อ้างถึง RCT ของ Anthropic กับนักพัฒนา Python 52 คน ระบุตัวเลขรวมที่ทักษะ comprehension ตกประมาณ 17% โดย debugging เป็นทักษะที่ตกหนักที่สุด ตัวเลขสองชุดสะท้อนการตัดข้อมูลคนละแบบ แต่ทิศทางตรงกันว่าทักษะลดลงจริง
หลักฐานเชิง qualitative ก็ไม่น้อย Faye อ้างคำให้สัมภาษณ์ของ Simon Willison นักพัฒนาประสบการณ์ราว 30 ปี ที่ระบุว่าตนเองสูญเสีย mental model ที่มั่นคงของแอปพลิเคชันเมื่อมอบหมายงานให้ AI agent เป็นหลัก และอ้าง Sandor Nyako ตำแหน่ง Director of Software Engineering ที่ LinkedIn ดูแลวิศวกร 50 คน ที่จำกัดการใช้ AI ของทีมในงานที่ต้องใช้ critical thinking หรือการแก้ปัญหา
ข้อสังเกตคือ คนที่ออกมาเตือนเรื่อง agentic coding ตอนนี้ ส่วนใหญ่ไม่ใช่กลุ่มต่อต้าน AI แต่เป็นวิศวกรที่ใช้เครื่องมือเหล่านี้หนักมาก่อน กระแสตีกลับเริ่มมาจากภายในวงการเอง ไม่ใช่จากนอกวง
ทำไม Faye เถียงว่าครั้งนี้ต่างจากการเปลี่ยนผ่านครั้งก่อน
ข้อโต้แย้งสามัญที่ฝ่ายสนับสนุน agentic coding มักหยิบมาใช้คือ ทุกครั้งที่เทคโนโลยีเปลี่ยน คนยุคก่อนก็เคยบ่นแบบนี้มาแล้ว ตั้งแต่ FORTRAN ไปจนถึง Java, Python และ AWS Faye ยอมรับว่าข้อโต้แย้งนี้ฟังดูสมเหตุสมผล แต่ระบุว่าครั้งนี้ต่างกันที่จุดสำคัญ
การเปลี่ยนผ่านครั้งก่อนเป็นการย้ายทักษะ จาก assembly ไปสู่ภาษาระดับสูง จากเครื่องในห้อง server ไปสู่ cloud วิศวกรยังต้องเข้าใจว่าโค้ดทำอะไร เพียงแต่ abstraction layer เปลี่ยน แต่ครั้งนี้ workflow แบบ agentic ผลักวิศวกรใหม่ไปทำหน้าที่ orchestrator โดยข้ามขั้นตอน hands-on ที่อาวุโสใช้เวลา 30 ปีสร้างขึ้นมา
Faye ระบุว่า code review ให้การเรียนรู้ได้ราว 50% ของสิ่งที่ได้จากการลงมือเขียนเอง การให้ junior กระโดดข้ามขั้น hands-on ตรงไปสู่การตรวจงาน agent จึงเหมือนการให้คนที่ยังไม่เคยทำอาหารเองมาเป็นเชฟใหญ่ที่ทำหน้าที่แค่ชิม
เวลาทำงานชิ้นใหม่หรือชิ้นที่ท้าทาย การที่ตัวเองพิมพ์โค้ดเองคือกระบวนการที่ใช้คิดว่าจริง ๆ แล้วควรทำอะไร — Dax ผู้สร้าง OpenCode
คำพูดของ Dax ผู้สร้าง OpenCode ที่ Faye ยกมาเป็นจุดยืนสำคัญของบทความ การเขียนโค้ดไม่ใช่แค่ขั้นตอนการลงมือทำ แต่เป็นกระบวนการคิด ถ้ามอบหมายขั้นตอนนี้ให้ AI ตั้งแต่ต้น สิ่งที่หายไปไม่ใช่แค่เวลาในการพิมพ์ แต่คือการคิดที่เกิดขึ้นระหว่างพิมพ์
spec ครอบคลุมความกำกวมไม่ได้
ฝั่งที่เชียร์ agentic workflow มักวางใจกับ Spec Driven Development ว่าถ้าเขียน spec ละเอียดพอ AI จะทำงานได้ตรงตามที่ต้องการ Faye ตอบกลับว่าแนวคิดนี้ดูดีในทฤษฎี แต่ในทางปฏิบัติ spec ไม่สามารถครอบคลุมความกำกวมได้ทั้งหมด
เมื่อมีช่องว่าง LLM จะเติมด้วย assumption หรือ hallucination ผลลัพธ์คือต้องตรวจซ้ำ ใช้ token เพิ่มขึ้น และห่างจากโค้ดมากขึ้น ยิ่งให้ agent generate ปริมาณเยอะ ยิ่งตรวจไม่ทัน วิศวกรจึงค่อย ๆ ยอมปล่อยผ่านสิ่งที่ตรวจไม่หมด ซึ่งเป็นจุดเริ่มของหนี้ความเข้าใจที่สะสมยาว
Faye เตือนเรื่องโครงสร้างราคาเสริมว่าผู้ให้บริการโมเดลกำลัง subsidise ราคาอยู่ และทุกเวอร์ชันใหม่มักตามรูปแบบ benchmark สูง ตามด้วย hype และการใช้ token เพิ่มขึ้น 2 ถึง 3 เท่าเพื่อให้ได้ผลลัพธ์เท่าเดิม ทีมที่ฝัง workflow ผูกขาดกับ vendor หนึ่งจึงเสี่ยงทั้งทักษะและงบในเวลาเดียวกัน
เมื่อใช้ workflow แบบ fully agentic ผู้ให้บริการโมเดลจะเป็นเจ้าของนักพัฒนาโดยปริยาย — The Primeagen นักพัฒนาและสตรีมเมอร์
ฝ่ายตรงข้ามมีจุดถูก แต่ตอบไม่หมด
ในกระทู้ Hacker News ที่บทความนี้ขึ้นอันดับต้น มีข้อโต้แย้งจากฝั่งตรงข้ามที่หนักแน่นพอที่ต้อง engage จริง คอมเมนต์ของ fnordpiglet เปรียบเทียบ AI ว่าเหมือน intern ที่อ่านเอกสารเยอะและรับ feedback ได้ พร้อมตั้งคำถามว่าวิศวกรในทีมจริงคนไหนรู้ทุกบรรทัดของ codebase ขนาดใหญ่ คอมเมนต์ของ ookblah ระบุว่าเสียงเตือนแบบนี้เคยมีกับ framework ทุกยุค คนที่อยากเรียนรู้จะปรับตัวได้เอง ส่วน dilyevsky ชี้ว่าการอัตโนมัติงานน่าเบื่อเช่นจัดการ dependency, script และ test ช่วยประหยัดแรงได้จริงในระดับ 50 เท่า
ข้อโต้แย้งเหล่านี้มีน้ำหนัก ไม่มีวิศวกรคนไหนรู้ทุกบรรทัดของ codebase องค์กรจริง การอัตโนมัติงานซ้ำ ๆ ก็เป็นกำไรชัดเจน และตำแหน่ง critic ทุกยุคก็เคยพลาดในการประเมินเทคโนโลยีใหม่
ข้อสังเกตคือ Faye ไม่ได้เถียงเรื่องเหล่านี้ จุดที่บทความโจมตีคือ workflow ที่ผลัก agent ไปเขียน feature ทั้งก้อน ไม่ใช่การให้ agent ช่วยจัดการงานสนับสนุน หลักฐานเชิงคุณภาพอย่างเรื่องของ keyle ที่ออกมาบอกใน Hacker News ว่าตนเองตอบคำถามเกี่ยวกับโค้ดที่ AI เขียนให้ไม่ได้ในที่ประชุม สะท้อนปัญหาที่เกิดเมื่อปริมาณ generated code มากเกินกว่าจะเข้าใจหมด ไม่ใช่ปัญหาของการใช้ AI ในงานเล็ก ๆ
ส่วนเรื่องการเปลี่ยนผ่านเทคโนโลยีในอดีต Faye ตอบไว้ตรง ๆ ว่าครั้งนี้ผลักวิศวกรไปทำงานตรวจซึ่งต้องใช้วิจารณญาณระดับอาวุโส โดยข้ามชั้นการสร้างวิจารณญาณนั้นไป ความต่างนี้คือสิ่งที่ทำให้ pattern ครั้งนี้ไม่ใช่แค่การย้ายทักษะ
workflow ทางเลือกที่ Faye เสนอ
Faye ไม่ได้เรียกร้องให้เลิกใช้ LLM แต่เสนอกฎ 5 ข้อที่รักษาบทบาทผู้สร้างไว้ที่คน ใช้ LLM สำหรับวางแผนและเขียน spec แต่ลงมือ implement ด้วยตัวเอง 20 ถึง 100% ตามความยากของงาน เขียน pseudo-code ก่อนสั่งโมเดลเพื่อบีบช่องว่างระหว่างคำสั่งกับผลลัพธ์ ใช้โมเดลเป็น utility เฉพาะกิจสำหรับ generate งานเล็ก เอกสาร และ research ห้ามให้ generate เกินกว่าที่จะ review หมดในรอบเดียว และห้ามมอบหมายงานที่ตัวเองทำเองไม่ได้
Faye สรุปแนวคิดด้วยอุปมาจาก Star Trek ใช้ LLM แบบ Ship's Computer (คอมพิวเตอร์ผู้ช่วยบนยานที่ตอบคำถามและช่วยคำนวณตามคำสั่งกัปตัน) ไม่ใช่แบบ Data (หุ่นยนต์ที่คิดและตัดสินใจแทน) ผลลัพธ์ที่ตั้งเป้าไม่ใช่ความเร็วที่สูงสุด แต่คือคุณภาพของงานพร้อมความเข้าใจที่ยังเหลืออยู่กับตัวคน
คนที่ทุ่มเข้าหา AI agent แบบเต็มตัวตอนนี้ กำลังการันตีความล้าสมัยของตัวเอง ถ้ามอบการคิดทั้งหมดให้คอมพิวเตอร์ จะหยุดพัฒนาทักษะ หยุดเรียนรู้ และหยุดเก่งขึ้น — Jeremy Howard ผู้ก่อตั้ง fast.ai
สิ่งที่ทีมพัฒนาในไทยควรเอาไปคิดต่อ
ตลาดเครื่องมือ agentic coding ที่กำลังเปิดในไทยมาพร้อมการ marketing ที่หนักมาก Cursor, Claude Code และ tool สาย agent อื่น ๆ ถูกเสนอภายใต้ภาพเดียวกันคือ AI ทำงาน คนคุม กรอบเล่าเรื่องนี้ตรงกับ pattern ที่ Faye, Willison และ Director ที่ LinkedIn กำลังถอนตัวออกอย่างเงียบ ๆ ในทีมของตัวเอง
กฎภายในที่ทีมไทยน่านำไปใช้ทันทีคือ ห้ามให้ AI generate โค้ดเกินกว่าที่จะ review ได้ในรอบเดียว และต้องเขียน plan ด้วยมือก่อนสั่ง agent กฎสองข้อนี้รักษาทั้งความเร็วที่ได้จากเครื่องมือ และความเข้าใจในโค้ดที่ทีมต้องดูแลต่อในระยะยาว สำหรับ junior กฎเสริมที่ Faye เน้นคือห้ามมอบหมายงานที่ตัวเองทำเองไม่ได้ แม้จะช้ากว่าในระยะสั้น แต่เป็นการลงทุนในวิจารณญาณที่ตำแหน่งอาวุโสในอนาคตจะต้องใช้
เงื่อนไขที่ภาพอาจพลิกอยู่ที่สองจุด หากผู้ให้บริการโมเดลแก้ปัญหา non-determinism ได้จริง และราคา token ทรงตัวในระดับที่ทีมเล็กรับได้ ข้อโต้แย้งของ Faye เรื่อง vendor lock-in และต้นทุนจะอ่อนลง แต่ paradox of supervision ยังเหลืออยู่ตราบใดที่งานตรวจยังต้องใช้ทักษะชุดเดียวกับที่ workflow ทำให้ฝ่อ การมองเรื่องนี้เป็นปัญหาเชิงวิธีการ ไม่ใช่ปัญหาเชิงเทคโนโลยี จึงสำคัญกว่าการรอเวอร์ชันใหม่ที่ benchmark สูงขึ้น
แหล่งอ้างอิง
บทความที่เกี่ยวข้อง
ความคิดเห็น
ยังไม่มีความคิดเห็น เป็นคนแรกที่แสดงความเห็น!