บทวิเคราะห์ paper 'Agentic Software', วิชาที่เกิดใหม่เมื่อ agent เข้ามาแทนที่โค้ด

บทวิเคราะห์ "Agentic Software", paper ที่เลิกใช้ชื่อ "The End of Software Engineering" เพื่อเล่าเรื่องวิชาใหม่ที่กำลังเกิด โดย Nokka (นก-กา), นักเขียนอิสระสายเทคโนโลยี ผู้เขียนบทความอธิบายเทคโนโลยีให้คนทั่วไปเข้าใจ 30+ บทความบน dev.to | 5 กันยายน 2026 บทความนี้เขียนโดย AI (glm-5.3 via ollama-cloud) ผ่าน Hermes Agent ภายใต้การควบคุมและตรวจสอบคุณภาพโดยมนุษย์, Nokka (นก-กา), อ้างอิงจาก paper วิจัยบน arXiv ฉบับเต็ม (2606.05608v1) ของ Zhenfeng Cao มี paper หนึ่งบน arXiv ที่จัดเป็นประเด็นที่สุดของปีหนึ่งงาน: "Agentic Software: How AI Agents Are Restructuring the Software Paradigm" โดย Zhenfeng Cao จาก Lingxi Intelligent Investment เมืองเสิงเจ๋น [1] เกร็ดที่ทำให้ paper นี้น่าสนใจกว่าชื่อที่เห็นคือมันเคยใช้ชื่อห้าวห้าสุดมาก่อน: ฉบับแรก (v1, มิ.ย. 2026) มีชื่อว่า "The End of Software Engineering: How AI Agents Are Fundamentally Restructuring the Software Paradigm" ก่อนผู้แต่งจะตัดคำว่า End ทิ้งเองใน v2 ซึ่งออกมาหกวันต่อจาก v1 พอดี เหมือนยอมรับว่าคำนั้นกลายเป็นการตัดสินประเด็นเกินเนื้อหาจริง เรื่องนี้ไม่ได้แค่เล่าจับฉาก แต่มีโครงเหตุผลจริงเป็นสามชั้น: วิชา software engineering เกิดจากข้อตั้งต้นหนึ่งที่ใช้มา 50 ปี, ข้อตั้งต้นนั้นกำลังหมดความหมายเพราะ agent, และสิ่งที่จะเกิดขึ้นแทนมีชื่อใหม่ที่ผู้เขียนเรียกว่า Agentic Engineering บทความนี้พาไล่ดูตามเหตุผลของเขาทีละชั้น พร้อมบอกด้วยว่าจุดไหนควรเชื่อแค่ไหน ก่อนอื่น, ทำความเข้าใจศัพท์ Software engineering: วิชาวิธีสร้างซอฟต์แวร์อย่างเป็นระบบ เกิดเป็นศัพท์ทางการที่ประชุม NATO ปี 1968 จากวิกฤต "ซอฟต์แวร์บวม" ของยุคนั้น AaaS (Agent-as-a-Service): ศัพท์ที่ paper ตั้งใหม่ สำหรับยุคที่ผู้ใช้จ่ายเงินแลก "ผลลัพธ์จาก agent" ไม่ใช่ "ชั่วโมงหรือสิทธิ์ใช้ซอฟต์แวร์" Intent architect: บทบาทมนุษย์ยุคใหม่ที่ paper ทำนาย คนที่เขียน "เจตนา" ให้ชัดพอที่ agent จะเอาไปรันได้ แทนการเขียนโค้ดเอง ถ้าให้อุปมา: วิชาเดิมเหมือนวิชา "สถาปัตรกรรมสำหรับอาคารอิฐ" ที่สอนว่าจะกออิฐทีละก้อนอย่างไรให้บ้านไม่พัง วันหนึ่งปรากฏเครนอัตโนมัติที่รับแบบจากคำบอกของเจ้าของบ้านแล้วสร้างเองได้ทั้งหลัง วิชากออิฐยังมีคนใช้อยู่ แต่คำถามสำคัญที่สุดของวิชาย้ายจาก "กอยังไงไม่ให้พัง" ไปเป็น "ออกแบบและคุมเครนยังไงให้ได้บ้านที่ใช้" ชั้นที่หนึ่ง: วิชานี้เกิดมาจากข้อตั้งต้นที่กำลังหมดความหมาย ผู้เขียนย้อนไปถึงกำเนิด: ปี 1968 วิกฤตซอฟต์แวร์ทำให้โลกตั้งวิชา software engineering ขึ้นมาด้วยข้อตั้งต้นว่า คนแตกปัญหาใหญ่เป็นชิ้นเล็ก แปลง logic เป็นโค้ดนิ่ง แล้วบำรุงรักษาโค้ดนั้นไปเรื่อยๆ [1] วิธีนี้ได้ผลมาห้าสิบปีเพราะตอบโจทย์ธรรมชาติของซอฟต์แวร์ตามที่ Fred Brooks เคยชี้ไว้ในหนังสือ The Mythical Man-Month [2]: ความซับซ้อนแบบส่วนตัวของซอฟต์แวร์คือทุกฟีเจอร์ทุกจุดเชื่อมต่อเพิ่มจำนวนสถานะที่เป็นไปได้แบบยกกำลัง ไม่มีขั้นผลิตในโรงงานให้แก้ทีหลัง เพราะดีไซน์คือตัวสินค้า [1] แล้ว agent ก็มาถึง เมื่อ LLM รับโจทย์ได้ แตกปัญหาเองได้ สร้างโค้ดเองได้ และทิ้งโค้ดเมื่อไม่ใช้แล้วก็ได้ บทบาทของโค้ดเปลี่ยนจาก "ตัวระบบ" เป็น "เครื่องมือชั่วคราวของการให้เหตุผล" ผู้เขียนเปรียบความเปลี่ยนแปลงนี้ว่ารุนแรงพอๆ กับการเปลี่ยนจากวงจรแอนะล็อกมาเป็นคอมพิวเตอร์โปรแกรมเก็บ เกินกว่าแค่มีเครื่องมือใหม่ในกรอบเดิม [1] ชั้นที่สอง: สามยุคของการส่งมอบซอฟต์แวร์ และยุคที่สามที่กำลังมา ส่วนที่ผมชอบที่สุดของ paper คือการจัดประวัติศาสตร์การค้าซอฟต์แวร์เป็นเส้นเดียว: ทุกยุคคือการย้ายความซับซ้อนออกจากคนที่จัดการมันไม่ไหว [1] ยุค ผู้ใช้ต้องจัดการอะไร ความซับซ้อนย้ายไปที่ใคร ซอฟต์แวร์ลิขสิทธิ์ (On-premise) ซื้อ ติดตั้ง ดูแลเซิร์ฟเวอร์ อัปเดตเอง ผู้ใช้เองทั้งหมด SaaS แค่ใช้ผ่านเว็บ จ่ายรายเดือน ผู้ให้บริการรับเรื่องเซิร์ฟเวอร์แทน AaaS (ที่กำลังมา) แค่บอกว่า "อยากได้ผลลัพธ์อะไร" แม้แต่ "วิธีทำ" ก็ย้ายไปอยู่กับ agent จุดที่ทำให้ AaaS ต่างจากสองยุคก่อนเกินกว่าเรื่องความสะดวก แต่คือครั้งแรกที่ตัวการตัดสินใจเองย้ายออกจากมนุษย์ ผู้เขียนย้ำว่า SaaS ปลดปล่อยธุรกิจจากห้องเซิร์ฟเวอร์ ส่วน AaaS จะปลดปล่อยจากความจำเป็นที่จะต้องระบุว่า "ผลลัพธ์นั้นทำมาอย่างไร" [1] เขายังโต้กลับมุมที่หลายองค์กรคิดว่า "AI มาช่วยเขียนโค้ดให้เร็วขึ้นก็พอ" ซึ่ง paper เรียกว่า ห่วงโซ่ AI ไปสู่ ซอฟต์แวร์ ไปสู่ ผลลัพธ์ และชี้จุดอ่อนสามข้อ: คนยังเป็นคอขวดของทุกการตัดสินใจเชิงออกแบบ, เพดานความซับซ้อนของตัวส่งมอบไม่เปลี่ยนไปไหน และทุกการแก้ไขยังต้องวิ่งเต็มห่วงโซ่ความต้องการถึงดีไซน์ถึงโค้ดถึงเทสถึงระวังผล ที่เร็วกว่าเดิมแต่ไม่มีวันเร็วกว่าความเร็วที่คนประสานงานกันไหว [1] ชั้นที่สาม: วิชาใหม่ชื่อ Agentic Engineering กับพัฒนาการสี่ขั้น หัวใจที่ผู้เขียนเสนอคือวิชาใหม่ที่ต่างจากของเดิมสามจุด วัตถุของวิชาเปลี่ยนจาก "โค้ดนิ่ง" เป็น "ระบบ agent" โมเดลควบคุมเปลี่ยนจาก "คนกำหนดล่วงหน้า" เป็น "LLM ขับเคลื่อน" และบทบาทคนเปลี่ยนจาก "ผู้เขียนโค้ด" เป็น "สถาปนิกของเจตนา" [1] โรดแมปสี่ขั้นจาก paper พร้อมกันนั้นเขาวางแผนที่เวลาสี่ขั้น [1] ขั้น ช่วงเวลา ลักษณะ 1. Tool-Augmented 2023-2025 agent เป็นผู้ช่วยในงานที่คนนำ มนุษย์ยังแตกปัญหาออกแบบ และตรวจงานเอง 2. Single-Task Autonomous 2025-2027 agent รับงานเต็มงานตั้งแต่สเปกจนส่งมอบ อย่างที่ Devin และ OpenHands กำลังทำ 3. Multi-Agent Teams 2026-2029 agent เฉพาะทางทำงานเป็นทีม: แผนผลิต, สถาปนิก, นักพัฒนา, QA มีหน่วยความจำร่วม 4. Self-Evolving Ecosystems 2028+ agent ปรับปรุงสถาปัตยกรรมตัวเองและแตกลูกเฉพาะทางโดยไม่ต้องมีคนสั่ง คนเหลือแค่ตั้งขอบเขตจริยธรรม ถ้าตามนี้ พวกเรากำลังยืนอยู่ต้นขั้นที่สามพอดี ซึ่งสมจริงมากเมื่อเทียบกับข่าวรอบตัวที่ผมเล่ามาทั้งสัปดาห์: จาก Hermes ที่ปล่อยให้ agent หลายตัวมีหน้ามีชื่อคุยกันเป็นกลุ่มได้ ไปจนถึงเคส agent ของ OpenAI ที่ไปเปิดบอร์ดแชทกันเองบนเว็บคนอื่น นั่นคือขั้นที่สามทั้งเจ้าตั้งใจและไม่ตั้งใจนั่นเอง แต่ paper ก็ยอมรับเพดานของตัวเอง paper นี้พิสูจน์ว่าตัวเองเกินกว่างานเชิญชวนให้เชื่อตรงตอนที่เขาหยิบหลักฐานฝ่ายตรงข้ามาเอง ผู้เขียนอ้าง benchmark EvoClaw ที่วัดพัฒนาซอฟต์แวร์ต่อเนื่องข้าม commit จริง ผลคืออัตราความสำเร็จดิ่งจากเกิน 80% เหลือแค่ 38% สูงสุด เมื่องานต้องต่อเนื่องและ error สะสมได้ โดยทดสอบจากโมเดลแนวหน้า 12 ตัวใน 4 เฟรมเวิร์ก [1] ตัวเลขนี้สอดคล้องกับงานวิจัย SWE-Bench ProMax ที่ผมเขียนไปเมื่อวานพอดี ที่โมเดลดีที่สุดทำงาน refactor ใหญ่ได้แค่ 41.2% เมื่อทั้งสองงานชี้ไปทางเดียวกัน ข้อสรุปที่ balanced ที่สุดคือ: กระบวนทัศน์ใหม่มาจริง แต่ agent ยังไม่พร้อมรับช่วงงานยาวอย่างที่คนหวัง และผู้เขียนเองก็ยอมรับว่า "วิศวกรรมซอฟต์แวร์แบบอิสระเต็มตัวยังเป็นโจทย์วิจัยหลายปี" ข้อควรชั่งน้ำหนักก่อนเชื่อทั้งหมด สามข้อที่ควรชั่งน้ำหนัก เพื่อความสมดุล สิ่งที่ผมอ่านแล้วอยากเตือนผู้อ่านสามข้อ หนึ่ง ที่มาของงาน นี่คือ paper ผู้เขียนคนเดียวจากบริษัทลงทุนสายเทคโนโลยีในจีน ไม่ใช่งานจาก lab ใหญ่ที่ผ่านการรีวิวโดยคณะ คุณค่าของมันอยู่ที่ความคิดเชิงสังเคราะห์ที่เรียบเรียงหลักฐานได้กลางแจ้งมากกว่าอำนาจของสถาบัน อ่านเป็น "วิทยานิพนธ์ที่น่าถกเถียง" จะเหมาะกว่าอ่านเป็นข้อสรุปสุดท้าย สอง ชื่อเรื่องกวีนิพนธ์เกินเนื้อหาเล็กน้อย สิ่งที่ paper พิสูจน์จริงๆ คือ "วิชากำลังปรับตัวครั้งใหญ่" ไม่ใช่ "วิชาตาย" ตัวผู้เขียนเองก็สรุปท้ายเรื่องว่าวิชาใหม่คือสิ่งที่แทนที่ ดังนั้นคำว่า End ในชื่อคือพาดหัวแบบชวนคิด ไม่ใช่คำพิพากษา สาม ตัวอย่างที่เขาเลือกมีน้ำหนักไม่เท่ากัน เคส LangChain ที่เขาอ้างว่าเป็นหลักฐานของทีม agent หลายตัวนั้นยังเป็น pilot ระยะต้น (นิยาม Agentic Engineering ทางการของ LangChain ออกเม.ย. 2026 [3]) ส่วน EvoClaw ที่ใช้ยืนยันเพดานกลับหนักแน่นกว่า การที่หลักฐานฝ่าย "ยังทำไม่ได้" หนักกว่าฝ่าย "ทำได้แล้ว" เป็นสัญญาณว่าโรดแมปของเขามีส่วนที่เป็นความหวังปนอยู่ สรุปมุมมองของผม ถ้าถามว่า paper นี้เปลี่ยนวิธีคิดของผมตรงไหน คำตอบคือมันทำให้ผมย้ายคำถามที่ควรถาม จาก "โมเดลตัวไหนเก่งกว่า" ไปเป็น "เรากำลังอยู่ขั้นไหนของการย้ายความซับซ้อน และเราตั้งใจจะย้ายมันไปที่ใคร" การย้ายครั้งใหญ่สองครั้งก่อนหน้านี้ (ลิขสิทธิ์เป็น SaaS) สร้างบริษัทระดับแสนล้านและกลืนอาชีพจำนวนมากไปพร้อมกัน ครั้งที่สามนี้มีขนาดไม่เล็กกว่ากัน คนที่จะได้เปรียบคือคนที่เริ่มฝึกเป็น "สถาปนิกของเจตนา" ตั้งแต่วันนี้ ไม่ใช่คนที่รอจนโรดแมปถึงขั้นสี่ สำหรับนักพัฒนาไทย ผมมองว่าโจทย์ต่างจากโลกตะวันตกตรงที่เราเริ่มจากฐานเครื่องมือเดิมที่ตื้นกว่า ดังนั้นการกระโดดข้ามไประบบ agent โดยตรงอาจถูกกว่าที่คิด แต่เงื่อนไขเดียวกันกับทุกที่คือ อย่ากระโดดโดยไม่มีระบบวัดผลและเส้นทางถอย ตัวเลข 38% ของ EvoClaw คือสิ่งที่ควรติดไว้บนจอทุกครั้งที่ตัดสินใจแทนที่ทีมให้ agent ทั้งทีม คำถามชวนคุย: จากโรดแมปสี่ขั้นข้างบน คุณมองว่าทีมหรือองค์กรของคุณกำลังยืนอยู่ขั้นไหนจริงๆ และอะไรคือสิ่งที่ขวางไม่ให้ขยับขึ้นขั้นถัดไป เชิญแลกเปลี่ยนกันได้ครับ ถ้าชอบบทความวิเคราะห์ paper วิจัยแบบอ่านต้นฉบับเต็ม ติดตาม Nokka ได้ที่ dev.to/sarantoon 📄 อ่าน paper ฉบับเต็ม: arxiv.org/abs/2606.05608 (v2, ชื่อปัจจุบัน Agentic Software) หรือ v1 ชื่อเดิม ที่ยังคงชื่อ The End of Software Engineering ไว้ตามต้นฉบับแรก 📚 อ่านต่อในธีมเดียวกัน: ผมเพิ่งเขียนสองเรื่องเรื่องการอ่านตัวเลข benchmark ให้เป็น (SWE-Bench ProMax กับ Terminal-Bench 4.0) บทนี้คือชิ้นที่สามของภาพเดียวกัน: หลังรู้ว่าตัวเลขเชื่อยังไง เหลือคำถามสุดท้ายว่าเรากำลังเปลี่ยนกระบวนทัศน์ไปไหน แหล่งอ้างอิง [1] Cao, Zhenfeng. "Agentic Software: How AI Agents Are Restructuring the Software Paradigm" (v2, มิ.ย. 2026, v1 ใช้ชื่อเดิมว่า "The End of Software Engineering: How AI Agents Are Fundamentally Restructuring the Software Paradigm"). arXiv. https://arxiv.org/abs/2606.05608 [2] Wikipedia. "The Mythical Man-Month" (หนังสือ Fred Brooks ปี 1975 ที่ paper อ้างถึง). https://en.wikipedia.org/wiki/The_Mythical_Man-Month [3] LangChain. "Agentic Engineering" (นิยามทางการ เม.ย. 2026, อ้างถึงใน paper หลัก). https://blog.langchain.dev บทความนี้วิเคราะห์จาก paper ฉบับเต็มบน arXiv (2606.05608v1) ซึ่งผมอ่านเนื้อหาจริง 34,725 ตัวอักษรระหว่างการค้นคว้า รวมถึงยืนยันหน้าแรกของ paper จากภาพที่ผู้อ่านส่งมา ข้อมูล ณ 5 กันยายน 2026 Nokka