- ความจริงที่ว่าต้นทุนในการเขียนโค้ดลดลงอย่างรวดเร็วกำลังสั่นคลอนนิสัยด้านวิศวกรรมโดยรวม
- ในอดีต การผลิตโค้ดมีต้นทุนสูง จึงก่อให้เกิดวัฒนธรรมการพัฒนาที่มีประสิทธิภาพโดยเน้นการออกแบบ การประเมิน และการวางแผน
- การมาถึงของcoding agentทำให้นักพัฒนาหนึ่งคนสามารถทำหลายงานพร้อมกันได้ (การพัฒนา, รีแฟกเตอร์, ทดสอบ, จัดทำเอกสาร)
- อย่างไรก็ตาม การสร้าง**“โค้ดที่ดี”**ยังคงต้องอาศัยมาตรฐานคุณภาพที่สูงและการตัดสินใจของนักพัฒนา
- ด้วยเหตุนี้ ภารกิจในการสร้างนิสัยการพัฒนาแบบใหม่ทั้งในระดับบุคคลและองค์กรจึงเริ่มเด่นชัดขึ้น
การเปลี่ยนแปลงของต้นทุนการเขียนโค้ด
- ในอดีต การเขียนโค้ดที่สะอาดและผ่านการทดสอบแล้วเพียงไม่กี่ร้อยบรรทัดอาจใช้เวลามากกว่าหนึ่งวัน
- ด้วยเหตุนี้ นักพัฒนาจึงประเมินคุณค่าและลำดับความสำคัญของฟีเจอร์ตามข้อจำกัดด้านเวลาและต้นทุน
- การออกแบบโปรเจ็กต์ การประเมินกำหนดการ และการวางแผนฟีเจอร์ ล้วนยึดอยู่กับ**“การใช้เวลาเขียนโค้ดอย่างมีประสิทธิภาพ”**
- การนำcoding agentมาใช้ทำให้ต้นทุนของการป้อนโค้ดลดลงอย่างรวดเร็ว และทำให้เกณฑ์การตัดสินแบบเดิมเริ่มสั่นคลอน
- วิศวกรหนึ่งคนสามารถรันหลาย agent แบบขนาน เพื่อทำงานพัฒนาพร้อมกันหลายอย่างได้
- การเปลี่ยนแปลงนี้บังคับให้ต้องทบทวนโครงสร้างการตัดสินคุณค่าต่อเวลาแบบเดิม
‘โค้ดที่ดี’ ที่ยังคงมีราคาแพง
- แม้การผลิตโค้ดใหม่จะเกือบฟรีแล้ว แต่การสร้าง**“โค้ดที่ดี”**ยังคงมีต้นทุนสูง
- เงื่อนไขของโค้ดที่ดีมีดังนี้
- ทำงานได้อย่างถูกต้อง และบรรลุเป้าหมายโดยไม่มีบั๊ก
- ผ่านกระบวนการตรวจสอบความถูกต้องเพื่อพิสูจน์ว่าโค้ดเชื่อถือได้
- มุ่งเน้นที่การแก้ปัญหาอย่างเหมาะสม และจัดการสถานการณ์ผิดพลาดได้อย่างคาดการณ์ได้
- รักษาโครงสร้างที่เรียบง่ายและเท่าที่จำเป็นเพื่อเพิ่มความสามารถในการบำรุงรักษาและความเข้าใจ
- การทดสอบและเอกสารต้องได้รับการอัปเดตให้เป็นปัจจุบันอยู่เสมอ
- คำนึงถึงความเป็นไปได้ของการเปลี่ยนแปลงในอนาคต แต่ไม่เพิ่มความซับซ้อนที่ไม่จำเป็น
- ตอบโจทย์คุณลักษณะคุณภาพที่ไม่ใช่เชิงฟังก์ชัน เช่น การเข้าถึง ความปลอดภัย การขยายระบบ และการบำรุงรักษา
- coding agent สามารถช่วยสนับสนุนบางส่วนของกระบวนการเหล่านี้ได้ แต่ความรับผิดชอบสุดท้ายในการรับประกันคุณภาพยังคงเป็นของนักพัฒนา
ความจำเป็นของนิสัยการพัฒนาแบบใหม่
- ในสภาพแวดล้อมของagentic engineering นิสัยการพัฒนาแบบเดิมไม่สามารถใช้ได้อีกต่อไป
- ทั้งระดับบุคคลและองค์กรจำเป็นต้องสร้างวิธีการทำงานและเกณฑ์การตัดสินแบบใหม่
- ขณะนี้ทั้งอุตสาหกรรมกำลังอยู่ระหว่างการกำหนดแนวปฏิบัติที่ดีที่สุด (best practices) เหล่านี้
- แนวทางที่เสนอคือ แม้ในช่วงที่รู้สึกว่า “เสียเวลา” ก็ควรลองรันเซสชัน agent แบบอะซิงโครนัสเพื่อทดลองดู
- ในกรณีแย่ที่สุด ก็เพียงกลับมาตรวจอีก 10 นาทีให้หลัง แล้วพบว่าเป็นแค่การเปลืองโทเค็นเท่านั้น
ตำแหน่งของบทความนี้ในคู่มือ Agentic Engineering Patterns
- บทความนี้เป็นส่วนหนึ่งของ “Principles” ซึ่งเป็นบทแรกของคู่มือ Agentic Engineering Patterns
- บทถัดไปจะต่อด้วยหัวข้อความเข้าใจโค้ด (Understanding code) คือ Linear walkthroughs
- หลังจากนั้น ในหมวด Testing and QA จะมีหัวข้ออย่าง Red/green TDD และ First run the tests
- มีแผนจะเพิ่มอีกสัปดาห์ละ 1–2 บท โดยจะมีลักษณะคล้ายหนังสือ แต่จัดในรูปแบบของ “คู่มือ”
1 ความคิดเห็น
ความคิดเห็นบน Hacker News
ไม่แน่ใจว่าคำกล่าวที่ว่า “โค้ดแพงมาโดยตลอด” จะถูกต้องหรือไม่
สิ่งที่แพงจริง ๆ ไม่ใช่ ตัวโค้ดเอง แต่เป็นทุกกระบวนการรอบข้างมัน — การทำให้ถูกต้อง การบำรุงรักษา การประสานงานข้ามทีม การซัพพอร์ตระยะยาว ฯลฯ ต่างหากที่เป็นต้นทุนหลัก
ถ้าผ่านการทดสอบหรือขั้นตอนอนุมัติมากเกินไป สุดท้ายกระบวนการอาจกลายเป็นต้นทุนส่วนใหญ่เสียเอง
LLM ทำให้ต้นทุนในการสร้าง โค้ดที่พอใช้งานได้ ลดลงมากในระยะสั้น แต่ในระยะยาว ภาระด้านการบำรุงรักษา ความปลอดภัย และการทดสอบอาจเพิ่มขึ้น
สุดท้ายแล้วจะมีการเปลี่ยนแปลงจริงหรือไม่ ต้องดูจากข้อมูลระยะยาว
เมื่อก่อนแม้แต่โค้ดไม่กี่ร้อยบรรทัดก็มีต้นทุนในการเขียนสูง
ลองเอา JavaScript 256 บรรทัดไปใส่ในเครื่องมือ SLOCount ยุคปี 2000 (เวอร์ชัน WebAssembly) ก็ได้ค่าประเมินต้นทุนตามมาตรฐานสมัยนั้นประมาณ $6,461
แน่นอนว่าตัวเลขนี้ดูขำ ๆ ก็พอ
ตอนนี้ฉันรู้สึกเหมือนเป็น ผู้จัดการของตัวเอง มากกว่าคนลงมือทำงานเอง
ความรู้สึกคือ productivity เพิ่มขึ้นราว 2.5 เท่าจากเมื่อก่อน
การเก็บ requirements การออกแบบ การทดสอบ การ deploy และการบำรุงรักษายังจำเป็นอยู่ และต้นทุนส่วนใหญ่ก็เกิดใน ช่วงบำรุงรักษา
เหมือนกฎของ Amdahl ต่อให้ต้นทุนการเขียนโค้ดเข้าใกล้ศูนย์ ต้นทุนของขั้นตอนอื่นก็ยังเป็นข้อจำกัด
ปัญหาคือโดยธรรมชาติของมนุษย์แล้ว สิ่งนี้ทำได้ยาก
ปัจจัยคุณภาพอย่าง ความถูกต้อง การบำรุงรักษาง่าย ประสิทธิภาพ คือ hidden cost ที่เรียนรู้ได้จากประสบการณ์เท่านั้น
ไม่เห็นด้วยกับข้ออ้างที่ว่า “โค้ดแพงมาโดยตลอด”
จริง ๆ แล้วโค้ดแพงเพราะเราพยายามจะเขียน ‘โค้ดที่ดี’ ต่างหาก
ถ้าลดมาตรฐานลง โค้ดที่ถูกสร้างขึ้นก็เร็วและถูก แต่ ความพยายามในการทำให้มันกลับมาเป็นโค้ดที่ดี ก็ยังเท่าเดิม
ถ้าจะปกป้องแนวคิด agent coding ก็ควรใช้ตรรกะอื่น
ถ้าเขียนเอง เราเข้าใจเหตุผลของแต่ละบรรทัด แต่โค้ดที่ AI ทำมานั้นต้องตรวจทุก statement
ตลอดเดือนที่ผ่านมา ฉันใช้งานส่วนใหญ่ผ่าน agent แล้วเจอ บั๊ก edge case ที่มนุษย์คงไม่เขียนออกมาเรื่อย ๆ
สุดท้ายต้นทุนในการรีวิวสูงจนผลได้ระยะสั้นหายไป
แต่ด้วย coding agent ต้นทุนนั้น ลดลงมาก
เพราะ agent ช่วยทำการแก้ไขละเอียด ๆ แทน จึงสร้างโค้ดคุณภาพดีกว่าได้เร็วขึ้น
ความซับซ้อนสะสมได้ ดังนั้นการจัดการมันอย่างระมัดระวังตั้งแต่ตอนเขียนครั้งแรกจึงถูกที่สุด
ตอนนี้ผลได้ระยะสั้นมีมาก แต่ในระยะยาว noise อาจเพิ่มขึ้น 10 เท่าก็ได้
LLM ถนัดงานแบบ tactical programming หรือการทำฟีเจอร์ให้เสร็จเร็ว
เพราะงั้นการจัดการความซับซ้อนในระดับระบบจึงยิ่งสำคัญขึ้น
การสร้างโค้ดถูกพอ ๆ กับการพูดถึงมัน แต่ ทักษะที่เปลี่ยนมันให้เป็นผลลัพธ์ที่มีคุณค่า ต่างหากคือความสามารถจริง
Agentic engineering ก็คือทักษะในการพา input ราคาถูกไปสู่ output ที่มีคุณค่า
Agentic engineering ไม่ใช่แค่การเขียนซอฟต์แวร์ แต่คือ การสร้างเครื่องมือเพื่อแก้ปัญหาเฉพาะอย่างรวดเร็ว
แต่เมื่อแก้ปัญหาเสร็จแล้ว ตัว AI เองก็ไม่น่าสนใจอีกต่อไป
หลายคนกลับทำให้ AI กลายเป็นเป้าหมาย ทั้งที่คุณค่าจริงอยู่ที่ การแก้ปัญหา
เหมือนคำพูดของ Alan Watts ว่า เมื่อได้รับสารแล้วก็ควรวางสาย
แค่เครื่องมือถูกลง ไม่ได้ทำให้เกิดคุณค่าโดยอัตโนมัติ
ความสามารถในการออกแบบและจัดโครงสร้าง ต่างหากคือมูลค่าจริง
สุดท้ายคุณภาพของการตัดสินใจต่างหากที่สำคัญ
การระดมทุนไม่ใช่หลักฐานของคุณค่า
มีข้อกังขากับคำกล่าวที่ว่า “โค้ดแพงมาโดยตลอด”
แม้แต่คำจำกัดความของโค้ดสะอาดและผ่านการทดสอบก็ยังคลุมเครือ
ถ้าทดสอบมากเกินไป ต้นทุนจะพุ่งสูง และ ขั้นตอนอนุมัติระดับองค์กร ก็เป็นต้นทุนก้อนใหญ่เช่นกัน
LLM ลดต้นทุนระยะสั้นได้ แต่ต้นทุนการบำรุงรักษาระยะยาวอาจเพิ่มขึ้น
ตอนฉันเป็นเด็กฝึกงาน ฉันทำงานให้สตาร์ทอัพด้วยค่าจ้างต่ำ แต่ ปัญหาระบบล่ม ความเสียหายของข้อมูล และหนี้ทางเทคนิค สะสมขึ้น
ภายนอกดูเหมือนถูก แต่ hidden cost สูงมาก
ตอนนี้ด้วย LLM มันดูเหมือนจะได้โค้ดคุณภาพดีในราคาถูก แต่เราก็ยังอยู่ในช่วงปรับตัว
ตอนนี้การทำ v1 นั้นถูก แต่ การตัดสินใจซับซ้อนของผลิตภัณฑ์ที่โตเต็มที่ ยังแพงเหมือนเดิม
คุณค่าทางเศรษฐกิจของซอฟต์แวร์อยู่ที่ ข้อมูลที่บรรจุอยู่ในโค้ด
การเขียนโค้ดเป็นเพียงกระบวนการ mapping ข้อมูลนั้นเท่านั้น และคุณภาพของข้อมูลคือสิ่งที่กำหนดมูลค่าที่แท้จริง
การเขียนโค้ดได้เร็วไม่ได้ทำให้คุณภาพของข้อมูลดีขึ้น
มันเหมือนกับการทำสไลด์ในงานที่ปรึกษาให้เร็วขึ้นไม่ได้ทำให้เกิดคุณค่าเอง
เมื่อความเร็วในการ implement สูงเกินไป mental model ของนักพัฒนาอาจไม่ตรงกับโค้ด
บทความที่เกี่ยวข้อง: Cognitive Debt by Simon Willison
เพราะสามารถวนทำ refactoring ได้อย่างรวดเร็ว
AI อาจเข้าใจบริบทได้มากขึ้นเรื่อย ๆ แต่ก็แลกกับการที่มนุษย์ต้องปล่อยมือจากการตัดสินใจ
วันหนึ่งถ้าเครื่องเข้าใจเจตนาได้อย่างสมบูรณ์ มนุษย์อาจถูกผลักออกไปนอกลูป
หัวใจของทุก methodology ในการพัฒนาคือข้อเท็จจริงที่ว่า requirements เปลี่ยนเสมอ
เพราะงั้นโค้ดที่ดีคือ “โค้ดที่แก้ไขได้ง่าย”
แต่ก็ยังน่าสงสัยว่า LLM agent ในตอนนี้สร้างโค้ดแบบนั้นได้หรือไม่
จนกว่าจะเชื่อถือได้เต็มที่ มันก็คงยังอยู่ในระดับ prototype
ถ้า spec ไม่ชัด ทั้งการทดสอบและการตรวจสอบคุณค่าก็จะยากไปหมด
ต่อให้มีการทดสอบ ก็ยังมั่นใจได้แค่ ประมาณ 70%
เร็วกว่าการเขียนเอง และผลลัพธ์ก็ออกมาเป็น โค้ดที่บำรุงรักษาได้
ถ้าระบุให้ชัดเรื่อง clean code และ good practices ก็ได้ผลลัพธ์ที่บำรุงรักษาได้เพียงพอ
สุดท้ายก็เป็นเรื่องของ Garbage in, garbage out
อย่างที่ฉันเขียนไว้ในบทความนี้ (The Final Bottleneck)
ความเร็วในการเขียนโค้ดเพิ่มขึ้นแล้ว แต่ ขั้นตอนหลังจากนั้นยังตามไม่ทัน
ไม่ใช่แค่เรื่องนิสัย แต่ โครงสร้างความรับผิดชอบ การออกแบบภาษา และโครงสร้างระบบทั้งหมด ต้องเปลี่ยนตาม
ถ้า productivity เพิ่มขึ้น 10 เท่าจริง เราคงเห็น สตาร์ทอัพปั่นป่วนตลาด ไปแล้ว
แค่ทำได้ ไม่ได้แปลว่าจำเป็นต้องทำ
แนวทางอย่าง AI evals(measure-first-optimize-last, ai-evals.io) ก็ไปในทิศทางนั้น
ฟีเจอร์ล้นเกิน ไม่ใช่สิ่งที่ใครต้องการ
โค้ดทุกบรรทัดคือ หนี้สิน (liability)
ในยุคที่ LLM สามารถปล่อยโค้ดออกมาเป็นจำนวนมาก หนี้สินนั้นก็พุ่งขึ้นอย่างรวดเร็ว
ตัวเครื่องมือเองไม่ใช่สิ่งเลวร้าย แต่โครงสร้างที่ โปรแกรมซึ่งไร้ความรับผิดชอบมาเขียนโค้ดเบสใหม่ นั้นอันตราย
คำว่า “โค้ดถูก” หมายถึงการสร้างมันถูกลง ไม่ได้หมายความว่า ต้นทุนการอนุมัติก่อน deploy จะถูกลงตาม
ถ้าข้ามขั้นของการตัดสินใจไป ก็ไม่ใช่ productivity ที่ดีขึ้น แต่เป็น control gap ต่างหาก
เร็วขึ้นไม่ได้แปลว่าควรยื่นกุญแจ master key ให้
ไม่ว่ามองด้านไหนมันก็ไม่ได้ถูก
ฉันเองก็เห็นด้วยกับความคิดเห็นนี้แทบทั้งหมด
การเขียนโค้ดถูกลงแล้ว แต่ ต้นทุนในการรีวิวและตรวจสอบความถูกต้อง ยังสูงอยู่
โดยเฉพาะใน monorepo ระดับหลายล้านบรรทัด การทำให้ทดสอบได้ดีคือหัวใจสำคัญ
รู้สึกขอบคุณที่การถกเถียงแบบนี้ช่วยดึงสมดุลกลับมา ท่ามกลางบรรยากาศที่ร้อนแรงเกินไปบน Twitter
code churn นั้นง่ายขึ้น แต่ การยืนยันคุณภาพ กลายเป็นความท้าทายใหม่
การเปลี่ยนแปลงจำนวนมหาศาลที่ LLM สร้างขึ้นทำให้เกิดความล้มเหลวแบบละเอียดอ่อน และกระแสนั้นก็ไม่หยุด
โค้ดไม่ได้ถูก
ยังมี ต้นทุน token อยู่ และโครงสร้างต้นทุนจริงก็ยังไม่ชัดเจน
เราขาดข้อมูลเพราะตอนนี้สตาร์ทอัพที่ยังไม่มีรายได้กำลังผูกขาด supply chain ของ GPU
ยิ่ง LOC เพิ่ม หนี้ก็ยิ่งเพิ่ม
ระยะห่างจากความคิดไปสู่การลงมือทำสั้นลงก็จริง แต่ตัวโค้ดเองก็ยังเป็นความรับผิดชอบอยู่ดี
ตอนนี้มันถูกเพราะมีเงินอุดหนุน แต่ถ้าต้นทุนฮาร์ดแวร์ ไฟฟ้า และบุคลากรลดลง ก็อาจถูกลงได้อีก