เส้นแบ่งระหว่าง vibe coding กับ agentic engineering กำลังใกล้กันมากกว่าที่ฉันต้องการ
(simonwillison.net)- เดิมที vibe coding และ agentic engineering ถูกแยกกันด้วยมาตรฐานด้านการตรวจสอบโค้ดและความรับผิดชอบ แต่เมื่อความน่าเชื่อถือของ coding agent สูงขึ้น เส้นแบ่งนี้ก็เริ่มพร่ามัวในการทำงานระดับโปรดักชันจริง
- vibe coding คือแนวทางที่แทบไม่ดูโค้ดเลย ถ้าผลลัพธ์ออกมาตามต้องการก็ยอมรับได้ จึงอาจมีประโยชน์กับเครื่องมือส่วนตัว แต่สำหรับซอฟต์แวร์ที่เกี่ยวข้องกับข้อมูลและประสบการณ์ใช้งานของผู้อื่น วิธีนี้ดูเป็นการทำงานที่ขาดความรับผิดชอบ
- agent อย่าง Claude Code จัดการงานซ้ำๆ อย่างการทำ JSON API endpoint, SQL query, การทดสอบ และเอกสารได้ดีขึ้นเรื่อยๆ จนเกิดการใช้งานโดยไม่ตรวจทุกบรรทัดของโค้ดที่ถูกสร้างขึ้น และนั่นสร้างความเสี่ยงจากการไว้วางใจสิ่งที่ไม่มีชื่อเสียงหรือความรับผิดชอบเหมือนทีมมนุษย์
- ตอนนี้สามารถสร้าง repository ที่มี 100 commits, README ที่ดี และชุดทดสอบครบทั้งระบบได้ภายใน 30 นาที ทำให้ตัดสินคุณภาพจากภาพลักษณ์ภายนอกได้ยากขึ้น และเกณฑ์จริงกลายเป็นว่ามีใคร ใช้งาน ซอฟต์แวร์นั้นอย่างต่อเนื่องหรือไม่
- เครื่องมือ AI ไม่ได้มาแทนประสบการณ์ของ software engineer แต่ขยายศักยภาพมันออกไป และเมื่อความเร็วในการผลิตโค้ดเพิ่มจากวันละ 200 บรรทัดเป็น 2,000 บรรทัด คอขวดจะย้ายไปอยู่ที่การออกแบบ การตรวจสอบ การปฏิบัติการ และการใช้งานจริง
เส้นแบ่งระหว่าง vibe coding กับ agentic engineering
- ใน Heavybit High Leverage Podcast Ep. #9 ซึ่งพูดถึงเครื่องมือเขียนโค้ดด้วย AI ทำให้มองเห็นว่า vibe coding และ agentic engineering กำลังเข้าใกล้กันมากขึ้นในการทำงานจริง
- ก่อนหน้านี้ใน Not all AI-assisted programming is vibe coding (but vibe coding rocks) ผู้เขียนแยกความแตกต่างระหว่าง vibe coding กับการเขียนโปรแกรมแบบมี AI ช่วยอย่างมีความรับผิดชอบไว้อย่างชัดเจน และต่อมาก็เริ่มเรียกอย่างหลังว่า agentic engineering
- vibe coding หมายถึงการแทบไม่ดูโค้ดเลย ผู้ใช้อาจไม่รู้จักการเขียนโปรแกรมด้วยซ้ำ แค่ขอผลลัพธ์ที่ต้องการ ถ้ามันทำงานก็รับไว้ ถ้าไม่ทำงานก็ขอใหม่
- ในกรณีอย่างเครื่องมือส่วนตัวที่บั๊กสร้างผลเสียแค่กับตัวเอง vibe coding อาจมีประโยชน์ แต่เมื่อสร้างซอฟต์แวร์ที่เกี่ยวข้องกับข้อมูลและประสบการณ์ใช้งานของผู้อื่น วิธีนี้ดูเป็นการทำงานที่ขาดความรับผิดชอบ
- agentic engineering คือแนวทางที่ software engineer มืออาชีพเข้าใจข้อจำกัดด้านความปลอดภัย ความสามารถในการบำรุงรักษา การปฏิบัติการ และประสิทธิภาพ แล้วใช้เครื่องมือ AI ให้ดึงศักยภาพของตนเองออกมาได้สูงสุด
- เป้าหมายไม่ใช่การสร้างผลงานคุณภาพต่ำกว่าให้เร็วขึ้น แต่คือการสร้าง ระบบโปรดักชันคุณภาพสูงกว่า ให้เร็วขึ้น
- ปัญหาคือเมื่อ coding agent น่าเชื่อถือขึ้น เราก็เริ่มไม่ตรวจทุกบรรทัดของโค้ดที่มันสร้าง แม้แต่งานระดับโปรดักชัน
ความไว้วางใจที่ทำให้ข้ามการตรวจโค้ด
- เมื่อขอให้ Claude Code สร้าง JSON API endpoint และรัน SQL query เพื่อแสดงผลลัพธ์เป็น JSON ก็เริ่มมีความมั่นใจว่ามันจะทำได้ถูกต้อง
- แม้แต่เมื่อให้มันเพิ่ม automated tests และเอกสาร ก็ยังคาดหวังได้ว่าผลลัพธ์จะออกมาดีพอ และในกระบวนการนั้นก็มีกรณีที่ไม่ได้ตรวจดูโค้ดจริงๆ
- ถ้าไม่ได้ตรวจโค้ด ก็ยังมีความรู้สึกผิดค้างอยู่ ว่าการนำมันไปใช้ในโปรดักชันถือเป็นเรื่องที่รับผิดชอบหรือไม่
- สิ่งนี้อาจมองได้คล้ายกับตอนทำงานเป็น engineering manager ในองค์กรขนาดใหญ่ ที่ต้องใช้ซอฟต์แวร์จากทีมอื่น
- ถ้าทีมอื่นให้บริการ image resize service โดยทั่วไปเราจะไม่อ่านทุกบรรทัดของโค้ดที่ทีมนั้นเขียน
- เราจะอ่านเอกสาร ลอง resize รูปภาพ แล้วจึงปล่อยฟีเจอร์ของตัวเอง
- ก็ต่อเมื่อเห็นบั๊กหรือปัญหาด้านประสิทธิภาพ จึงค่อยเข้าไปดู Git repository
- ส่วนใหญ่แล้วเราปฏิบัติต่อบริการนั้นเหมือน black box ครึ่งหนึ่ง
- agent ก็เริ่มถูกปฏิบัติในลักษณะเดียวกันมากขึ้น แต่ต่างจากทีมมนุษย์ตรงที่ Claude Code ไม่มีชื่อเสียงทางวิชาชีพหรือความรับผิดชอบ (accountability)
- ทีมมนุษย์สามารถสั่งสมชื่อเสียงจากการสร้างซอฟต์แวร์ดีๆ มาก่อน และยังมีแรงกดดันว่าผลงานแย่จะกระทบชื่อเสียงทางวิชาชีพของตนเอง
- Claude Code ไม่มีชื่อเสียงแบบนั้นได้ แต่กำลังสร้างความไว้วางใจจากการจัดการงานง่ายๆ ซ้ำๆ ได้ถูกต้องตามสไตล์ที่ชอบอย่างต่อเนื่อง
- เรื่องนี้มีองค์ประกอบของ normalization of deviance
- ทุกครั้งที่โมเดลเขียนโค้ดได้ถูกต้องโดยไม่ต้องเฝ้าดูใกล้ชิด ความไว้วางใจก็จะเพิ่มขึ้น
- และความเสี่ยงที่จะมั่นใจเกินไปในจังหวะที่มันพลาด จนเกิดความเสียหาย ก็เพิ่มขึ้นตามไปด้วย
การประเมินซอฟต์แวร์ยากขึ้น
- เมื่อก่อนถ้า GitHub repository มี 100 commits, README ที่ดี และ automated tests ก็มักจะตัดสินได้ง่ายว่าโปรเจกต์นี้ผ่านการใส่ใจและทุ่มเทมาพอสมควร
- ตอนนี้สามารถสร้าง Git repository ที่มี 100 commits, README สวยงาม และ tests ที่ครอบคลุมทุกบรรทัดของโค้ดได้ในเวลา 30 นาที
- repository แบบนี้อาจดูภายนอกเหมือนโปรเจกต์ที่ผ่านการใส่ใจและทุ่มเทมาอย่างยาวนาน
- มันอาจดีจริงในระดับนั้นก็ได้ แต่ดูจากภายนอกอย่างเดียวบอกได้ยาก และแม้แต่กับโปรเจกต์ของตัวเองก็เจอปัญหาเดียวกัน
- เกณฑ์ที่สำคัญกว่าคุณภาพของ tests และเอกสารคือ มีใครได้ ใช้งาน ซอฟต์แวร์นั้นจริงหรือไม่
- ต่อให้เป็นผลลัพธ์จาก vibe coding ถ้าคนสร้างใช้มันทุกวันมาตลอดสองสัปดาห์ ก็ยังมีค่ามากกว่าผลงานที่แทบไม่เคยรันแล้วปล่อยออกมา
คอขวดย้ายจากการเขียนโค้ดไปยังขั้นตอนอื่น
- ถ้าจากเดิมสร้างโค้ดได้วันละ 200 บรรทัด แล้วกลายเป็น 2,000 บรรทัด ส่วนอื่นๆ ของวงจรชีวิตการพัฒนาซอฟต์แวร์ก็จะเริ่มพัง
- วงจรชีวิตการพัฒนาซอฟต์แวร์แบบเดิมถูกออกแบบบนสมมติฐานว่าการสร้างโค้ดได้เพียงไม่กี่ร้อยบรรทัดต่อวัน
- การเปลี่ยนของคอขวดไม่ได้กระทบแค่ขั้นตอนปลายน้ำ แต่ยังกระทบขั้นตอนต้นน้ำด้วย
- ใน งานนำเสนอของ Jenny Wen มีมุมมองว่ากระบวนการออกแบบแบบเดิมตั้งอยู่บนสมมติฐานว่า “ต้องทำดีไซน์ให้ถูกต้อง”
- เพราะถ้าส่งต่อให้วิศวกรแล้วไปสร้างสิ่งที่ผิดอยู่ 3 เดือน มันจะกลายเป็นหายนะ
- กระบวนการออกแบบที่กว้างขวางมีอยู่เพราะมันนำไปสู่งานสร้างที่มีต้นทุนสูง
- แต่ถ้าการ build ไม่ได้ใช้เวลา 3 เดือนอีกต่อไป ต้นทุนของความผิดพลาดก็ลดลงมาก ทำให้กระบวนการออกแบบสามารถรับความเสี่ยงได้มากขึ้น
ทำไมถึงยังไม่คิดว่าอาชีพ software engineer จบลงแล้ว
- การคุยกับ agent ดูเหมือน “moon language” ที่คนส่วนใหญ่ฟังไม่รู้เรื่อง
- หนึ่งในเหตุผลที่ไม่คิดว่าอาชีพ software engineer จบลงเพียงเพราะคอมพิวเตอร์เริ่มเขียนโค้ดเองได้ คือเครื่องมือเหล่านี้ทำหน้าที่ขยายประสบการณ์เดิม
- คนที่รู้ว่าตัวเองกำลังทำอะไรอยู่ จะเคลื่อนไหวได้เร็วขึ้นมากเมื่อทำงานร่วมกับเครื่องมือ AI
- ยิ่งใช้เครื่องมือ AI มากเท่าไร ก็ยิ่งยืนยันซ้ำๆ ว่าการสร้างซอฟต์แวร์นั้นยากมาก
- ต่อให้มีเครื่องมือ AI ครบทุกอย่าง งานที่พยายามจะทำให้สำเร็จก็ยังคงยากอยู่ดี
- Matthew Yglesias เขียนใน ทวีต ว่า “พอผ่านไป 5 เดือน ฉันก็พบว่าตัวเองไม่ได้อยากทำ vibecode ฉันอยากให้บริษัทซอฟต์แวร์ที่มีการบริหารจัดการอย่างมืออาชีพ ใช้ AI coding assistance เพื่อสร้างผลิตภัณฑ์ซอฟต์แวร์ที่มากขึ้น ดีขึ้น และถูกลง แล้วขายให้ฉัน” และผู้เขียนก็เห็นด้วย
- สรุปได้ด้วยอุปมาว่า ถึงจะดูวิดีโอ YouTube เรื่องงานประปามากพอจนซ่อมระบบประปาในบ้านเองได้ ก็ยังอยากจ้างช่างประปามากกว่าอยู่ดี
ความเสี่ยงของ SaaS กับการสร้างใช้เองในองค์กร
- แม้ในประเด็นความเสี่ยงที่บริษัทอาจเลิกใช้ SaaS แล้วหันไปสร้างโซลูชันเอง เกณฑ์เรื่องความชอบซอฟต์แวร์ที่ผ่านการพิสูจน์จากการใช้งานจริงก็ยังใช้ได้เหมือนเดิม
- สำหรับโปรเจกต์ส่วนตัว อย่างน้อยก็จะชอบเครื่องมือที่คนสร้างใช้มันเองมาหลายสัปดาห์
- ถ้าขยับไปเป็นเวอร์ชันระดับองค์กร เกณฑ์ก็จะกลายเป็นว่า ถ้าไม่ใช่ CRM ที่บริษัทใหญ่อีกอย่างน้อยสองแห่งใช้งานสำเร็จมาแล้ว 6 เดือน ก็ไม่อยากนำมาใช้
- ก่อนจะยอมรับความเสี่ยง ก็ต้องการโซลูชันที่พิสูจน์แล้วว่าใช้งานได้จริง
1 ความคิดเห็น
ความคิดเห็นจาก Hacker News
vibe coding และ LLM ไม่ได้สร้างองค์กรวิศวกรรมหรือวิศวกรที่ไร้ระเบียบวินัยขึ้นมาใหม่ แต่แค่เปิดเผยและเร่งปัญหาที่มีอยู่เดิมเท่านั้น
วิศวกรจำนวนมากมีมาตรฐานและแนวปฏิบัติในการเขียนโค้ดที่หละหลวมหรือแทบไม่มีเลย และหลายทีมก็มาตรฐานอ่อนมากในการนำโค้ดขึ้นสู่ production
นี่ไม่ใช่ปรากฏการณ์ใหม่ แต่หมายความว่า ตอนนี้ทั้งบุคคลและทีมที่ไม่เคยรักษามาตรฐานตลอดวงจรชีวิตการพัฒนาซอฟต์แวร์ สามารถสร้างโค้ดได้มากขึ้นและทำให้ไอเดียเป็นรูปธรรมได้ง่ายขึ้นมาก
ไม่เคยเห็นเพื่อนร่วมงานคนไหนกลายเป็นวิศวกรที่ดีเพียงเพราะเขียนโค้ดได้เร็วขึ้น
วิศวกรที่เก่งที่สุดเท่าที่ฉันรู้จักคือคนที่ใช้ประสบการณ์และวิจารณญาณอย่างรอบคอบ แบ่งปัน insight สำคัญให้ทีม และพาระบบไปในทิศทางที่ดีขึ้น
“Claude, สร้างระบบให้ฉันหน่อย แต่ขอให้ทำดี ๆ นะ ขอบคุณ!”
เมื่อก่อนถ้า codebase เริ่มต้านการพัฒนาฟีเจอร์ ก็จะแก้คอขวดเฉพาะหน้า แล้วเลื่อนไปจัดการจุดต้านถัดไปในอนาคต
มันเป็นการรีแฟกเตอร์ไปพร้อมกับสร้างฟีเจอร์ แต่ frontier models ผลัก “จุดที่กลายเป็นปัญหา” ออกไปให้ไกลขึ้น
เพราะมันยังพอจัดการกองโค้ดที่ได้รับมาได้ระดับหนึ่ง ปัญหาจึงโผล่ออกมาในรูปแบบที่ LLM สร้าง regression มากขึ้นหรือพลาด requirement มากขึ้น แต่คนจะรู้สึกน้อยลงว่างานมันยากขึ้น
แล้ววันหนึ่งมันจะพังมากจนต้องซ่อม แต่ทั้ง codebase กลายเป็น ชั้นแบบแฟร็กทัล ของการตัดสินใจที่ฉันไม่ได้เป็นคนทำ จนคลี่แก้ออกได้ยาก
พอไม่ได้แก้โค้ดด้วยมือเอง ความรู้สึกทางกายแบบ “ถ้าเพิ่มแบบนี้จะเกิดแรงตึงสูง” ก็หายไป ทำให้จับจังหวะในการทะลวงรีแฟกเตอร์ได้ยากขึ้น
โค้ดยังไงก็รีแฟกเตอร์ได้เสมอ และเราสามารถบังคับให้ agent เขียนเป็นชิ้นเล็ก ๆ แบบโมดูลและแยกไฟล์ได้
ไม่ว่า agent จะเขียนหรือคนจะเขียน วิศวกรรมที่ดีก็คือวิศวกรรมที่ดี
ตอนนี้อย่างน้อยมนุษย์ยังต้องเข้าใจและขับเคลื่อนสถาปัตยกรรมเอง โดยให้ agent ช่วยได้มากในงานสำรวจและเสนอแนวทาง
ถ้าไม่ได้พลาดความก้าวหน้าในช่วงไม่กี่สัปดาห์ที่ผ่านมา สิ่งที่ดูเหมือนเกิดขึ้นไม่ใช่ว่า AI เชื่อถือได้มากขึ้น แต่คือความผิดพลาดของมัน ละเอียดแนบเนียนขึ้น
ถ้าโค้ดคอมไพล์ไม่ได้ก็หาง่าย และถ้าคอมไพล์ได้แต่ทำงานไม่ได้ก็ยังพอหาง่ายอยู่บ้าง
แต่ถ้ามันคอมไพล์ได้และทำงานได้ ทว่าไปพลาดในบาง edge case มีช่องโหว่ด้านความปลอดภัย หรือพา technical debt กับการตัดสินใจด้านสถาปัตยกรรมที่น่ากังขาติดมาด้วย แบบนี้หายากกว่ามาก และภาระในการรีวิวก็ไม่ได้ลดลงเลย
ที่จริงโค้ดที่ดูน่าเชื่อถือกลับสร้างภาระทางความคิดเวลารีวิวมากกว่าโค้ดแย่ ๆ แบบชัดเจนเสียอีก
ให้มันเขียนหลาย ๆ test ก่อน ตรวจว่าโค้ดตรงตามนั้นหรือไม่ และสั่งให้ agent จัดระเบียบโค้ดให้ถูกต้อง
แต่ตอนนี้แรงกดดันจากข้างบนมันแรงมากจนบรรยากาศกลายเป็นว่าต้องเอาไปใช้กว้าง ๆ ทุกที่ และถ้าคัดค้านก็ทั้งน่าท้อใจและเริ่มกระทบข้อจำกัดทางอาชีพจนรู้สึกหมดแรง
พอชี้ปัญหาที่ชัดเจนออกมา ก็จะมีทางอ้อมแก้สารพัดโผล่มา และไม่นานทางอ้อมเหล่านั้นก็เผยปัญหาใหม่อีก ก่อให้เกิดวิธีแก้ใหม่ไม่รู้จบ
จนถึงจุดหนึ่งมันเริ่มเหมือนว่า งานทั้งหมดนี้กำลังทำเพื่อเครื่องจักรเอง
หลายบริษัทดูเหมือนทำเป้าหมายที่แท้จริงเลือนหายไป จนเหลือแค่ LLM เอง
ไม่รู้ว่าคนที่เดิมพันอนาคตบริษัทเพื่อทำวิสัยทัศน์นี้ให้เป็นจริง ได้รับทางออกนุ่มนวลไว้หลบผลลัพธ์หรือไม่ หรือว่าเหตุผลกำลังถูกทิ้งไปทั้งชุด
อาจลดปัญหาได้ด้วยหลักวิศวกรรมที่ดี แต่ก็ยังสงสัยว่าในมุมภาระทางความคิด เวลา developer เงิน และทรัพยากรที่มีจำกัด มันสร้างประสิทธิภาพจริงแค่ไหน
ในประโยคที่ว่า “ถ้าคุณผลิตโค้ดได้จากวันละ 200 บรรทัดเป็น 2,000 บรรทัด อะไรจะพัง” การใช้ จำนวนบรรทัดโค้ด เป็นตัววัดผลผลิตทางวิศวกรรมเป็นเรื่องน่าอาย
การรีวิว 200 บรรทัดกับ 2,000 บรรทัดเป็นภาระงานคนละระดับกันโดยสิ้นเชิง
แต่พอลองสร้างโปรแกรมเดียวกันขึ้นมาใหม่ด้วยหัวตัวเอง และใช้ ChatGPT แค่เหมือน search กับ autocomplete ก็ได้ผลลัพธ์เท่ากันใน 1,500 บรรทัด
พูดตามตรงความต่างด้านความพยายามก็ไม่ได้มากขนาดนั้น แต่แนวทางเขียนเองอาจได้เปรียบตรงที่เวอร์ชัน vibe coding ครั้งแรกช่วยให้ฉันคิดไว้แล้วว่าจริง ๆ อยากสร้างอะไร
การใช้จำนวนบรรทัดโค้ดเป็น input ของการรีวิวซอฟต์แวร์จึงสมเหตุสมผล
เพราะสุดท้ายก็ต้องอ่านทีละบรรทัดจริง ๆ
เพียงแต่มันแย่มากถ้าใช้เป็นตัววัดเดี่ยวของ productivity ของนักพัฒนา และปัญหาก็เกิดเมื่อพยายามใช้แบบนั้น
ถึงอย่างนั้นมันก็ยังมีประโยชน์ เพราะแทบเป็นตัวชี้วัดเดียวที่เข้าใจได้ตรงกันทันทีและเปรียบเทียบกันได้ข้ามบริษัท ทีม ภาษา และบริบทของแอปพลิเคชัน
ต่อให้เป็นทีมเดียวกันทำงานบนผลิตภัณฑ์เดียวกัน การเปลี่ยน 1,000 บรรทัดอาจจบเร็วมาก ขณะที่การแก้บั๊ก 1 บรรทัดอาจต้องใช้เวลาดีบักหลายวัน
เพราะงั้นการเปรียบเทียบ PR, ฟีเจอร์ หรือ story point แบบไม่มีบริบทจึงยาก และถ้ามีตัวชี้วัดมาตรฐานอุตสาหกรรมสำหรับ productivity ของนักพัฒนาที่ทำได้จริง ทุกคนคงใช้กันไปแล้ว แต่โดยธรรมชาติมันยาก
เวลาเปรียบเทียบแบบนี้ มันช่วยได้ถ้าสมมติว่าบริบทเหมือนกัน
เช่น ทีมหนึ่งในบริษัทหนึ่งที่สร้างผลิตภัณฑ์หนึ่งด้วย tech stack และกระบวนการคุณภาพแบบเดิม เมื่อวานทำได้ N1 บรรทัด วันนี้ใช้ AI แล้วทำได้ N2 บรรทัด ความต่างระหว่าง N1 กับ N2 เมื่อดูตามเวลาจะสะท้อนผลกระทบจริงได้ใกล้เคียง
งานวิจัยที่เข้มงวดเกี่ยวกับ productivity ของการพัฒนาที่มี AI ช่วย ก็มักวัดแบบ A/B test โดยเปรียบเทียบ PR ก่อนและหลังใช้ AI ในกลุ่มเดียวกัน
สำหรับฉัน ความต่างอยู่ที่ คุณภาพและความเข้มงวดของ pipeline
vibe coding คือการลองหนึ่งครั้งหรือไม่กี่ครั้ง ตรวจผลแบบคร่าว ๆ แล้วใช้ไปจนกว่าจะพัง
มันเหมาะกับ proof of concept แบบเบา ๆ หรือแอปความเสี่ยงต่ำสำหรับใช้ส่วนตัว ครอบครัว หรือทีมเล็ก
ส่วน agentic engineering สนใจประเด็นที่กว้างกว่า เช่น functional correctness, performance, infrastructure, resilience/availability, scalability และ maintainability
มันมี pipeline หลายขั้นสำหรับจัดการ workflow และอาจมีขั้นตอนอย่างการรับงาน คัดเลือก ระบุสเปก แตกเป็น epic แตกเป็น story เขียนโค้ด ทำเอกสาร และ deploy
แต่ละขั้นจะมีทั้ง quality gate ที่ตัดสินชัดเจน เช่น ผ่าน test หรือผ่านเกณฑ์ performance และการรีวิวแบบจับผิดในเรื่องอย่าง business value ความครบถ้วนของสเปก ความสวยงามของโค้ด หรือความเข้มงวดและความเรียบง่ายของ ubiquitous language
สิ่งนี้ก็เป็นเหมือน slider
บางครั้งเราไม่ได้อยากสัมภาษณ์ เผา token ทำ adversarial review สามรอบ ประเมินคุณค่า และเขียนสเปกละเอียดเพื่อ deploy ฟีเจอร์เดียว ก็แค่อยากโยน ticket เข้าไปในระบบเฉย ๆ
ฉันใช้ Opus, GPT-5.5 และโมเดลเล็กกว่านี้ทุกวัน แต่ไม่ได้มอบงานทั้งก้อนให้มันทำ
ถึงจะทุ่มแรงไปกับการนิยามและขัดเกลาสเปกพอสมควร มันก็ยังทำเรื่องโง่ ๆ เยอะมาก ซึ่งถ้าเป็น PR review โดยมนุษย์ก็คงไม่ผ่าน
ถ้าฉันเชื่อผลลัพธ์ของมัน หรือสร้าง pipeline agent ขนาดใหญ่เพื่อให้ตัวเองรู้สึกมั่นคงปลอม ๆ ก็อาจปล่อยให้สิ่งเหล่านั้นไหลเข้า codebase ไปเฉย ๆ ได้ง่าย
อีก 10 ปีข้างหน้าอาจดีขึ้น แต่ตอนนี้ทั้ง vibe coding และ pipeline แบบ agentic engineering ก็ดูเป็นเพียงรูปแบบต่างกันของธีมเดียวกัน คือการมอบทุกอย่างให้ LLM ทั้งก้อน
เช้าวันนี้เองฉันยังคิดว่าในไฟล์เดี่ยวไฟล์หนึ่ง น่าจะให้ Opus on Max จัดการการเปลี่ยนแปลงได้ แต่เกือบทุกเทิร์นมันก็ยังพลาดหรือตกหล่นบางอย่างจนต้องแก้
โค้ดที่มันเสนอโดยรวมคงใช้ได้ แต่ซับซ้อนเกินไป และยังทำให้ส่วนที่ฉันเคยลดความซับซ้อนด้วยมือกลับถอยหลังไปอีก
ถ้าเหตุการณ์แบบนี้คูณกับ commit จาก agent หลายพันครั้ง codebase ก็จะเสื่อมลงอย่างรวดเร็ว
ทีมพัฒนาจะลำบากเมื่อพยายามสร้างของโดยไม่มี process ที่ถูกต้องอย่างการออกแบบ การทดสอบ และการรีวิว
ก่อนมี agent coding ก็เป็นแบบนั้นอยู่แล้ว แต่ตอนนี้ยิ่งชัดกว่าเดิม และทีมที่เข้าใจวิธีใช้ agent ใน process นี้จะประสบความสำเร็จมากที่สุด
ไม่รู้สึกหรือว่า coding agent มักเข้าใกล้วิธีแก้มากในความพยายามครั้งแรก แต่การเก็บ 10% หรือ 5% สุดท้าย ให้ครบต้องใช้แรงมหาศาล
ถ้าเปลี่ยนวิธีเข้าหาปัญหา agent อาจปิดช่องว่างนั้นได้
เมื่อ 10 ปีก่อน เราจะหยุดเขียนโค้ดทุก ๆ 10-15 นาทีเพื่อรีแฟกเตอร์ ทดสอบ และวิเคราะห์ว่ามันสมบูรณ์หรือยัง
เพราะบั๊กสามารถปนเปื้อนไปทั้งโค้ดส่วนถัด ๆ ไปได้
coding agent ทำแบบนั้นไม่ได้ และจะเดินหน้าต่อทั้งที่ยังแบกบั๊กหรือสถาปัตยกรรมที่ผิดอยู่
ตามสัญชาตญาณเราอยากหยุด agent เป็นระยะ ๆ แต่ด้วยหลายเหตุผลมันทำไม่ได้
ทางออกคือเพราะต้นทุนมันถูกมาก เราจึงหาจุดที่ agent เริ่มพลาดครั้งแรก แก้ prompt แล้วแทนที่จะไปแก้โค้ด ก็ลบทิ้งทั้งหมดแล้วรันใหม่ตั้งแต่ต้น
ทำซ้ำแบบนี้ไปจนกว่า prompt จะให้โค้ดที่สมบูรณ์แบบ
อาจมีคนโต้แย้งว่ามนุษย์ยังต้องทำงานเยอะอยู่ดี แต่นั่นแหละคือประเด็น
มนุษย์ยังจำเป็น และถ้าใช้เครื่องมือแบบนี้ ความเร็วในการเขียนโค้ดจะเพิ่มขึ้น 10 เท่า
การทำ “อะไรสักอย่างที่ใช้ได้” มักทำได้ค่อนข้างเร็ว แต่การประเมินทางเลือกอื่น ๆ ปรับแต่ง และทดสอบจนมั่นใจ ใช้เวลานาน
แก่นของเรื่องนั้นถูกต้อง แต่ไม่มีใครรู้ว่าขอบเขตอยู่ตรงไหน
อีกประมาณปีหนึ่งข้างหน้า ทุกคนคงอยู่ในช่วงค้นหาสิ่งนั้น และนั่นจึงเป็นเหตุผลที่เราได้ยินคำพูดอย่าง “เราต้องสร้าง GitHub ขึ้นมาใหม่” บ่อยมาก
ในหลายกรณี การลงทุนเพื่อทำให้ส่วนสุดท้ายนั้นเป็นระบบอัตโนมัติไม่ได้คุ้มทางเศรษฐกิจ
ฉันคิดว่าผู้ให้บริการ LLM เลือกแนวทางผิดตั้งแต่แรก
พวกเขาควรโฟกัสที่ เสริมแรงงาน มากกว่าการแทนที่แรงงาน และดูเหมือนกำลังได้บทเรียนราคาแพง
การเริ่มใหม่ตั้งแต่ต้นอาจดีกว่า แต่ตอนเริ่มแรกฉันยังไม่รู้ว่าสถาปัตยกรรมที่ต้องการควรหน้าตาเป็นอย่างไร
แค่เพราะ LLM ลำบากในการทำให้ฟีเจอร์เข้ากับสถาปัตยกรรมเดิม ก็ไม่ได้แปลว่าเราจะลบทิ้งทั้ง codebase ที่ใช้งานอยู่แล้วเริ่มใหม่ได้
เป็นบทความที่ยอดเยี่ยมจากคนที่ฉลาด ถ่อมตน และเรียนรู้อยู่ตลอด
ประโยคที่ฉันชอบคือ “มีหลายเหตุผลที่ผมไม่กลัวว่าการที่คอมพิวเตอร์เขียนโค้ดของตัวเองได้ จะหมายถึงจุดจบของอาชีพวิศวกรซอฟต์แวร์ ส่วนหนึ่งก็เพราะสิ่งเหล่านี้เป็น ตัวขยาย ของประสบการณ์เดิม ถ้าคุณรู้ว่ากำลังทำอะไรอยู่ คุณก็จะวิ่งได้เร็วขึ้นมาก”
อีกส่วนที่ชอบคือ “การใช้เครื่องมือเหล่านี้คอยย้ำเตือนเราตลอดว่าสิ่งที่เราทำนั้นยากแค่ไหน การสร้างซอฟต์แวร์เป็นงานที่ยากอย่างดุเดือด ต่อให้มีเครื่องมือ AI ทุกอย่างในโลก สิ่งที่เราพยายามทำกันอยู่ตรงนี้ก็ยังยากมากจริง ๆ”
ข้อสังเกตที่ว่างานต้นน้ำก็เปลี่ยนไปด้วยนั้นแม่นมาก
โดยเฉพาะเครื่องมือฝั่งดีไซน์ที่พัฒนาเร็วมาก จนตอนนี้ดูไม่คุ้มแล้วที่จะต้องแบกรับ ต้นทุนการแปลค้างอยู่ฝั่ง Figma
ส่วนที่น่ากลัวคือ ชั้นของความซับซ้อนจาก AI จะสะสมอยู่ใน codebase และคนจะไม่เข้าใจโค้ดอีกต่อไป จนต้องเสียต้นทุนมหาศาลให้โมเดลรุ่นใหม่ช่วยถอดความและแก้ไขมัน
อีกไม่นานการนำโค้ดกลับมาใช้ซ้ำอาจหายไป แล้วเราจะเผาเงินไปกับการประดิษฐ์วงล้อใหม่ซ้ำแล้วซ้ำเล่า
ตอนทำแอป Android ยุคแรก ๆ จำเป็นต้องใช้ IDE และต้องเขียน boilerplate code ปริมาณมหาศาลอย่างไร้เหตุผล แค่เพื่อคลิกปุ่มแล้วให้มีแจ้งเตือน “Hello World” เด้งขึ้นมา จนรู้สึกเหมือนวิญญาณหลุดออกจากร่าง
พูดตามกันนะ: ซอฟต์แวร์ส่วนใหญ่ใช้ชีวิตเกือบทั้งหมดอยู่ใน ช่วงบำรุงรักษา
เพราะฉะนั้นรายได้ส่วนใหญ่ที่ซอฟต์แวร์สร้างได้ก็มาจากช่วงบำรุงรักษาเช่นกัน
อุตสาหกรรมนี้ผ่านมาเกือบ 100 ปีแล้วก็ยังไม่เข้าใจเรื่องนี้
คำพูดของ Alan Kay ที่ว่าการปฏิวัติคอมพิวเตอร์ยังไม่เกิดขึ้นนั้นถูกต้อง 100%
แม้จะมีความก้าวหน้าทั้งหมดในปัจจุบัน เครื่องมือต่าง ๆ ก็ยังอยู่ในระดับยุคหินเป็นส่วนใหญ่
ความหวังใหญ่ของฉันคือ AI จะเร่งเราไปจนถึงจุดที่ทำให้กระบวนทัศน์เดิมแตกพังอย่างไม่อาจกู้กลับได้ และสุดท้ายเราจะทำสิ่งใหม่ สิ่งที่ต่างออกไป และสิ่งที่ดีกว่าได้
เพราะงั้นตอนนี้ก็ติดเจ็ตแพ็กให้วงจรชีวิตการพัฒนาซอฟต์แวร์ด้วย AI แล้วลุยให้สุด
เคลื่อนที่ให้เร็ว และพังมันให้จริง
เป็นข้อสังเกตที่ตรงเวลามากและตรงกับความรู้สึกของฉันด้วย
ฉันต้องตั้งงานแบบ batch ง่าย ๆ ที่ดาวน์โหลด → แปลง → เปิด API endpoint และแม้จะเขียน prompt ค่อนข้างละเอียด แต่ก็ปล่อยรายละเอียด implementation อย่าง data source ไว้เยอะมาก
Opus 4.7 สร้างออกมาได้ประมาณ 90% ตรงกับวิธีที่ฉันน่าจะทำเอง และยังใส่ convenience method กับการตรวจสอบทีละขั้นมาให้มากกว่าด้วย
มันดีมาก และเปิดพื้นที่ให้ฉันไปคิดปัญหาที่ยากกว่าได้
ฉันเป็นนักพัฒนา Python เป็นหลัก แต่ก็ใช้ภาษา backend อื่นอย่าง Rust หรือ Go อยู่เรื่อย ๆ ซึ่งคุ้นเคยแต่ยังไม่ถึงระดับเดียวกัน
การมีประสบการณ์ประมาณ 13 ปีที่หนักไปทางภาษาเดียว บวกกับการเรียนรู้อย่างเป็นทางการในภาษาอื่น ๆ ทำให้การสั่งงาน LLM ง่ายขึ้นมาก
ภาระของการเรียน syntax, primitive พื้นฐาน, package manager, การทดสอบ ฯลฯ เมื่อเทียบกับวิธีเขียนโปรแกรมแบบก่อนหน้านี้แล้ว ไม่ได้หนักมาก
ไม่นานมานี้ฉันช่วยเพื่อนร่วมงานที่ไม่ใช่นักพัฒนา ซึ่งกำลังใช้ Claude cowork/code ทำ automation ด้าน reporting
เขาเข้าใจงานฝั่ง business intelligence ดี แต่ติดขัดกับการหาสำนวนพื้นฐานสำหรับ vibe coding ตัวห่อ pyautogui ที่จะเปิด RDP แล้วกรอกค่าลงใน abstraction ของ MS Access ที่ครอบฐานข้อมูลของผู้ขายไว้
ดูเหมือนว่าอาชีพนักพัฒนาในฐานะงานอาชีพยังน่าจะไปต่อได้อีก 5-10 ปี