บทความชื่อ Agentic Coding is a Trap โดย Lars Faye นักพัฒนาซอฟต์แวร์รุ่นเก๋า ทะยานขึ้นสู่อันดับหนึ่งของ Hacker News ด้วยคะแนนโหวตกว่า 300 คะแนน และคอมเมนต์ถกเถียงอย่างเผ็ดร้อนกว่า 200 ข้อความในเวลาเพียงไม่กี่ชั่วโมง เนื้อหาหลักพุ่งเป้าท้าทายกระแสที่ทีมพัฒนาทั่วโลกกำลังปล่อยให้ AI Agent เข้ามารับหน้าที่เขียนโค้ดทั้งฟีเจอร์ โดยมีมนุษย์ทำหน้าที่เป็นเพียงคนคอยสั่งการ (Orchestrator)

ข้อโต้แย้งหลักของ Faye ไม่ใช่การปฏิเสธ AI แบบหัวชนฝา แต่เขาระบุว่า รูปแบบการใช้งานที่บริษัทโมเดลพยายามผลักดัน กำลังเปลี่ยนวิศวกรซอฟต์แวร์จาก "ผู้สร้างสรรค์" ให้กลายเป็น "ผู้ตรวจงาน" และที่น่ากลัวคือ ทักษะที่จำเป็นต้องใช้ในการตรวจงาน กลับเป็นทักษะชุดเดียวกับที่กระบวนการแบบ Agentic กำลังทำให้ฝ่อลงไปเรื่อยๆ

ประเด็นนี้นับว่าส่งสัญญาณเตือนโดยตรงถึงทีมพัฒนาในไทย ที่กำลังนำ Cursor, Claude Code และเครื่องมือ Agentic ต่างๆ มาใช้อย่างรวดเร็ว โดยอาจไม่ได้วางแผนรับมือว่าจะรักษาทักษะและความเข้าใจในตัวระบบของทีมไว้ได้อย่างไรในระยะยาว

ภาพฝันกับความเป็นจริงของ Agentic Workflow

ภาพที่ฝั่งการตลาดของบริษัท AI มักนำเสนอคือ ให้ AI ทำหน้าที่พิมพ์โค้ด แล้วคนคอยทำหน้าที่จัดคิวและตรวจงาน Faye ชี้ว่า ภาพนี้ฟังดูเป็นวิวัฒนาการที่หลีกเลี่ยงไม่ได้ แต่ในความเป็นจริงกลับซ่อนต้นทุนแฝงที่หนักหนาสาหัสเอาไว้

ใน บทความต้นฉบับ Faye สรุป 4 ปัญหาสำคัญของ Agentic Coding ไว้อย่างชัดเจน:

1. ความซับซ้อนของระบบรอบข้าง: ต้องสร้างกลไกเสริมมากมายเพื่อควบคุมความไม่แน่นอน (Non-determinism) ของโมเดล
2. การถดถอยของทักษะวิศวกร: ความสามารถในการเข้าใจโค้ดและดีบักระบบลดลงอย่างรวดเร็ว
3. การตกเป็นตัวประกันของผู้ให้บริการ (Vendor Lock-in): เมื่อคลาวด์หรือระบบของ AI ล่ม ทั้งทีมจะไม่สามารถทำงานต่อไปได้
4. ต้นทุนค่าโทเคนที่คาดเดาไม่ได้: แตกต่างจากเงินเดือนวิศวกรที่เป็น Fixed Cost ที่วางแผนได้แน่นอน

แกนหลักของบทความ: Paradox of Supervision

จุดโฟกัสที่คมที่สุดของ Faye คือแนวคิด Paradox of Supervision (ความย้อนแย้งของการคุมงาน) การที่คุณจะตรวจโค้ดที่ AI Agent สร้างขึ้นมาได้อย่างมีคุณภาพ คุณจำเป็นต้องมีทักษะการเขียนโค้ดและดีบักในระดับสูง แต่ยิ่งคุณพึ่งพา Agent มากขึ้นเท่าไร ทักษะเหล่านั้นก็ยิ่งลดลง จนถึงจุดที่คุณไม่สามารถตรวจจับข้อผิดพลาดที่ซับซ้อนได้อีกต่อไป

Faye อ้างอิงงานวิจัยที่ Anthropic เคยทดลองกับกลุ่มนักพัฒนา โดยพบว่าผู้ที่ใช้ AI เขียนโค้ดอย่างเข้มข้น มีทักษะด้านการ Debugging ลดลงถึง 47% ขณะที่รายงานจาก InfoQ และ DevClass ซึ่งอ้างอิงการทดลองแบบ RCT ของ Anthropic กับนักพัฒนา Python ชี้ว่า ทักษะความเข้าใจโค้ดโดยรวมลดลงราว 17% และจุดที่ลดลงหนักที่สุดคือการหาจุดบกพร่องในระบบ

นอกจากนี้ ผู้เชี่ยวชาญในวงการหลายคนเริ่มส่งสัญญาณเตือนในทิศทางเดียวกัน Simon Willison วิศวกรประสบการณ์กว่า 30 ปี ยอมรับว่าเขาสูญเสีย Mental Model (ภาพความเข้าใจเชิงโครงสร้างของแอปพลิเคชัน) เมื่อปล่อยให้ AI Agent ทำงานเป็นหลัก ขณะที่ Sandor Nyako ผู้อำนวยการฝ่ายวิศวกรรมที่ LinkedIn สั่งจำกัดการใช้ AI ในทีมเพื่อปกป้องทักษะ Critical Thinking ในการแก้ปัญหาของวิศวกร

ทำไมครั้งนี้ถึงต่างจากการเปลี่ยนผ่านในอดีต

ฝ่ายสนับสนุน Agentic Workflow มักยกเหตุผลว่า ทุกครั้งที่วงการเทคโนโลยีเปลี่ยนผ่าน มักมีคนออกมาต่อต้านเสมอ ตั้งแต่ยุคเปลี่ยนผ่านจาก Assembly ไปสู่ภาษาชั้นสูง หรือจากเซิร์ฟเวอร์ On-Premise ไปสู่ระบบคลาวด์ แต่ Faye ชี้ให้เห็นความแตกต่างที่สำคัญมากในครั้งนี้

การเปลี่ยนผ่านในอดีตเป็นการ "ยกระดับ Abstraction" แต่วิศวกรยังคงต้องเข้าใจกลไกและกระบวนการทำงานของโค้ด ทว่าในยุค Agentic รูปแบบการทำงานกำลังผลักให้นักพัฒนารุ่นใหม่กระโดดข้ามขั้นตอนลงมือทำจริง (Hands-on Coding) แล้วไปทำหน้าที่เป็นเพียงคนตรวจงานทันที

Faye เปรียบเทียบไว้อย่างน่าคิดว่า การตรวจโค้ด (Code Review) มอบการเรียนรู้ได้เพียงครึ่งเดียวของการลงมือเขียนเอง การให้วิศวกรระดับ Junior ข้ามขั้นตอนการเขียนโค้ดแล้วไปตรวจงานที่ AI สร้างขึ้น จึงไม่ต่างอะไรกับการให้คนที่ทำอาหารไม่เป็นเลย มารับหน้าที่เป็นหัวหน้าเชฟที่คอยยืนชิมรสชาติอย่างเดียว

"เวลาทำงานชิ้นใหม่หรือโจทย์ที่ท้าทาย การลงมือพิมพ์โค้ดด้วยตัวเองคือกระบวนการคิดที่จำเป็น เพื่อให้รู้ว่าแท้จริงแล้วเรากำลังแก้ปัญหาอะไร" (Dax ผู้สร้าง OpenCode)

สเปกที่สมบูรณ์แบบไม่มีอยู่จริง

กลุ่มผู้สนับสนุนเชื่อมั่นในแนวคิด Spec-Driven Development ว่าถ้าเขียนคำอธิบายและข้อกำหนดให้ละเอียดพอ AI จะเขียนโค้ดออกมาได้ถูกต้องแม่นยำ แต่ Faye แย้งว่า ในโลกความเป็นจริง ความต้องการทางธุรกิจมีความกำกวมเสมอ และไม่มีทางเขียน Spec ครอบคลุมได้หมดทุกกรณี

เมื่อเกิดช่องว่าง โมเดลภาษาจะเริ่มเติมเต็มด้วยสมมุติฐานหรืออาการหลอน (Hallucination) นำไปสู่การดีบักที่ไม่รู้จบ และเมื่อปริมาณโค้ดที่สร้างขึ้นมามีมากเกินไป วิศวกรจะเริ่มปล่อยผ่านและกดอนุมัติโดยไม่ได้เข้าใจเนื้อหาทั้งหมด ซึ่งเป็นจุดเริ่มต้นของการสะสม "หนี้ความเข้าใจ" (Understanding Debt) ในระยะยาว

"เมื่อคุณเลือกใช้ Workflow แบบ Fully Agentic เท่ากับว่าผู้ให้บริการโมเดลได้กลายเป็นเจ้าของตัวคุณไปโดยปริยาย" (ThePrimeagen นักพัฒนาและสตรีมเมอร์)

ข้อคิดเห็นจากคอมมูนิตี้ Hacker News

ในกระทู้ Hacker News มีความเห็นหลากหลายที่ร่วมวิเคราะห์ประเด็นนี้:

• ผู้ใช้ fnordpiglet เปรียบ AI เหมือนเด็กฝึกงานที่อ่านเอกสารเก่งและพร้อมรับฟังคำแนะนำ พร้อมตั้งคำถามว่า ในโลกจริงจะมีวิศวกรคนไหนเข้าใจโค้ดทุกบรรทัดในระบบขนาดใหญ่ได้ทั้งหมด
• ผู้ใช้ dilyevsky มองว่า การนำ AI มาช่วยงานจำเจ เช่น การจัดการ Dependency, เขียนสคริปต์ หรือเขียน Unit Test พื้นฐาน ช่วยประหยัดเวลาการทำงานลงได้จริงอย่างมหาศาล

Faye ไม่ได้ปฏิเสธประโยชน์ของการใช้ AI จัดการงานสนับสนุนเหล่านี้ แต่สิ่งที่เขาคัดค้าน คือการโยนการพัฒนาฟีเจอร์หลักทั้งก้อนให้ Agent ทำงานอย่างอิสระโดยที่มนุษย์ไม่ได้มีส่วนร่วมในกระบวนการคิดเลย

5 กฎเหล็กสร้าง Workflow ที่คนยังเป็นนาย

Faye เสนอกฎ 5 ข้อสำหรับทีมที่ต้องการใช้พลังของ AI ควบคู่ไปกับการรักษาความเชี่ยวชาญของทีม:

1. ใช้ AI วางแผน แต่ลงมือเขียนโค้ดด้วยตัวเอง: ใช้ LLM ช่วย Brainstorm และร่างโครงสร้าง แต่ลงมือเขียนโค้ดเอง 20-100% ตามความยากของงาน
2. เขียน Pseudo-code ก่อนสั่งการ: กลั่นกรองตรรกะด้วยตัวเองก่อน เพื่อลดความคลาดเคลื่อนของคำสั่ง
3. ใช้โมเดลเป็นเครื่องมือเฉพาะกิจ: ให้ช่วยสร้างสคริปต์สั้นๆ เขียนเอกสาร หรือทำ Research แทนการให้เขียน Core Business Logic
4. ห้ามสั่งให้สร้างโค้ดเกินกว่าที่จะรีวิวไหวในรอบเดียว: เพื่อป้องกันปัญหาความล้าและปล่อยผ่านโค้ดโดยไม่เข้าใจ
5. ห้ามมอบหมายงานที่ตัวเองทำไม่เป็นให้ AI ทำแทน: วิศวกรต้องเข้าใจตรรกะนั้นก่อน ถึงจะสั่งงานและตรวจสอบความถูกต้องได้อย่างแท้จริง

"ใครที่กระโจนเข้าหา AI Agent แบบเต็มตัวในตอนนี้ กำลังการันตีความล้าสมัยของตัวเองในอนาคต เพราะถ้าคุณยอมยกกระบวนการคิดทั้งหมดให้คอมพิวเตอร์ คุณจะหยุดพัฒนาทักษะ หยุดเรียนรู้ และหยุดเติบโตในสายอาชีพ" (Jeremy Howard ผู้ก่อตั้ง fast.ai)

บทสรุปสำหรับทีมพัฒนาในไทย

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

แหล่งอ้างอิง

• Agentic Coding is a Trap (Lars Faye)
• Hacker News discussion (id 48002442)