บทวิเคราะห์ 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 ไปสู่ ซอฟต์แวร์ ไปสู่ ผลลัพธ์ และชี้จุดอ่อนสามข้อ: คนยังเป็นคอขวดของทุกการตัดสินใจเชิงออกแบบ, เพดานความซับซ้อนของตัวส่งมอบไม่เปลี่ยนไปไหน และทุกการแก้ไขยังต้องวิ่งเต็มห่วงโซ่ความต้องการถึงดีไซน์ถึงโค้ดถึงเทสถึงระวังผล ที่เร็วกว่าเดิมแต่ไม่มีวันเร็วกว่าคว