- ช่วงหลังมานี้การแพร่หลายของ AI coding agent ทำให้ความเร็วในการพัฒนาเพิ่มขึ้น แต่ คุณภาพของซอฟต์แวร์ที่ลดลงและความไม่เสถียร ก็รุนแรงขึ้นด้วย
- เอเจนต์ สะสมข้อผิดพลาดเดิมซ้ำโดยไม่มีความสามารถในการเรียนรู้แบบวนซ้ำ และในโค้ดเบสขนาดใหญ่จะเกิด การลดลงของ recall ในการค้นหาและความซับซ้อนที่พุ่งสูง
- หากปล่อยให้ดูแลทั้งระบบโดยไม่มีการควบคุมจากมนุษย์ จะนำไปสู่ โค้ดซ้ำ รูปแบบการออกแบบที่ผิดพลาด และโค้ดเบสที่ไม่สามารถบำรุงรักษาได้
- ณ ตอนนี้ควรใช้เอเจนต์อย่างจำกัดกับ งานที่ไม่ใช่แกนหลักหรือพื้นที่เชิงทดลอง และ มนุษย์ต้องยังคงเป็นด่านคุณภาพขั้นสุดท้าย
- การชะลอความเร็วลงและฟื้นคืนความเป็นผู้กระทำของมนุษย์ คือหัวใจสำคัญของการเรียนรู้ การเติบโต และ ระบบนิเวศซอฟต์แวร์ที่ยั่งยืน
ทุกอย่างกำลังพัง
- ในช่วง 1 ปีที่ผ่านมา coding agent พัฒนาไปถึงระดับที่สามารถทำโปรเจ็กต์จริงให้เสร็จได้ แต่ผลลัพธ์ที่ตามมาคือ คุณภาพซอฟต์แวร์ที่ลดลง อย่างชัดเจน
- แม้แต่บริการขนาดใหญ่ก็เริ่มมองว่า uptime 98% เป็นเรื่องปกติ และ บั๊ก UI ก็เกิดขึ้นบ่อย
- มีการกล่าวถึง กรณีระบบล่มที่เกี่ยวข้องกับ AI ของ AWS และคำพูดของ Microsoft เรื่อง สัดส่วนโค้ด AI ที่เพิ่มขึ้น
- บางบริษัทอ้างว่าโค้ดของผลิตภัณฑ์ 100% ถูกเขียนโดย AI แต่ผลงานที่ได้กลับมีคุณภาพต่ำ ทั้ง memory leak, ข้อผิดพลาดของ UI และฟังก์ชันที่ไม่เสถียร
- นักพัฒนาหลายคนรายงานว่า การพัฒนาโดยมีเอเจนต์เป็นศูนย์กลาง ทำให้เกิดโค้ดเบสที่ ไม่สามารถบำรุงรักษาได้ เนื่องจากไม่มี code review ขาดการออกแบบ และมีฟีเจอร์เกินจำเป็น
วิธีที่ไม่ควรทำงานร่วมกับเอเจนต์
- นักพัฒนาจำนวนมากกำลังเสพติด ความเร็วและปริมาณโค้ด จน ยอมสละคุณภาพและอำนาจควบคุม
- มีความพยายามทำ การ orchestration ของเอเจนต์ขนาดใหญ่ โดยชูแนวคิด “กระจายอำนาจ อัตโนมัติ และทำงานได้เอง” แต่ในความเป็นจริงกลับผลิต ผลลัพธ์ที่ไม่เสถียร ออกมาจำนวนมาก
- บางโปรเจ็กต์แทบใช้งานไม่ได้เลย และไม่สามารถคงอยู่ได้หากไม่มีมนุษย์เข้ามาแทรกแซง
- ในระดับโปรเจ็กต์ส่วนตัวอาจพอเป็นไปได้ แต่สำหรับ ผลิตภัณฑ์ที่มีผู้ใช้จริง ส่วนใหญ่กลับจบลงด้วยความล้มเหลว
-
การสะสมข้อผิดพลาดและการขาดการเรียนรู้ ไม่มีคอขวด ความเจ็บปวดที่มาช้า
- เอเจนต์ไม่มี ความสามารถในการเรียนรู้แบบวนซ้ำ จึงทำข้อผิดพลาดเดิมซ้ำแล้วซ้ำอีก
- มนุษย์เรียนรู้จากข้อผิดพลาด แต่เอเจนต์กลับ ทำพลาดแบบเดิมได้ไม่สิ้นสุด
- มนุษย์มีข้อจำกัดด้านความเร็วในการเขียนโค้ด ทำให้การสะสมข้อผิดพลาดเกิดช้า แต่ กองทัพเอเจนต์ไม่มีคอขวด จึงสะสมข้อผิดพลาดแบบระเบิดออกมา
- ผลคือ โค้ดเบสไม่น่าเชื่อถือ และแม้แต่การทดสอบอัตโนมัติก็เชื่อถือไม่ได้
- สุดท้าย การทดสอบด้วยมือกลายเป็นหนทางตรวจสอบเพียงอย่างเดียว ทำให้ทีมพัฒนาวางกับดักให้ตัวเอง
-
พ่อค้าที่เรียนรู้ความซับซ้อน
- เอเจนต์ตัดสินใจแบบเฉพาะจุดโดย ไม่เห็นบริบทของทั้งระบบ
- ผลลัพธ์คือ โค้ดซ้ำ การทำ abstraction ที่ไม่จำเป็น และความสับสนเชิงโครงสร้าง สะสมอย่างรวดเร็ว
- ในองค์กรที่ขับเคลื่อนโดยมนุษย์ ความซับซ้อนแบบนี้มัก ค่อย ๆ สะสมเป็นเวลาหลายปี แต่ทีมที่ใช้เอเจนต์เป็นฐานสามารถไปถึงระดับความโกลาหลเดียวกันได้ภายใน ไม่กี่สัปดาห์
- เอเจนต์ยังคงทำซ้ำ รูปแบบการออกแบบที่ผิดพลาด ที่เรียนมาจากข้อมูลฝึก และหากไม่มีการควบคุมจากมนุษย์ ก็จะสร้าง ความซับซ้อนที่กู้คืนไม่ได้
-
recall ต่ำของการค้นหาโดยเอเจนต์
- เมื่อเอเจนต์พยายามแก้โค้ดหรือทำ refactor มันมัก หาโค้ดที่จำเป็นทั้งหมดไม่เจอ
- ยิ่งโค้ดเบสใหญ่ขึ้น recall ของการค้นหา ก็ยิ่งลดลงอย่างรวดเร็ว จนนำไปสู่ ความซ้ำซ้อนและความไม่สอดคล้องกัน
- แม้จะใช้เครื่องมือต่าง ๆ เช่น Bash, LSP, vector DB ก็ยังมี ข้อจำกัดในโค้ดเบสขนาดใหญ่
- สิ่งนี้ยิ่งทำให้ code smell และความซับซ้อนที่ไม่จำเป็น รุนแรงขึ้น
วิธีที่ควรทำงานร่วมกับเอเจนต์ (อย่างน้อยในตอนนี้)
- เอเจนต์ดึงดูดใจด้วย การสร้างโค้ดที่รวดเร็วและคุณภาพเริ่มต้นที่สูง แต่ถ้ามอบหมายทั้งระบบให้ มันจะ พังทลาย
- กรณีใช้งานที่เหมาะสมคือ งานขนาดเล็กที่ไม่ใช่แกนหลัก, งานที่มี self-evaluation loop ได้, และ งานที่ล้มเหลวแล้วไม่ถึงขั้นวิกฤต
- ตัวอย่างเช่น การสร้างเครื่องมือภายใน, การทดลองไอเดีย, และ งานวิจัยอัตโนมัติที่อิงการวัดประสิทธิภาพ (auto-research)
- มนุษย์ต้องยังคงเป็น ด่านคุณภาพขั้นสุดท้าย และต้อง ตรวจทาน แก้ไข และรวมผลลัพธ์ จากเอเจนต์
- หากฟังก์ชันประเมินสะท้อนเพียงตัวชี้วัดแคบ ๆ เอเจนต์อาจ ละเลยคุณภาพโค้ด ความซับซ้อน และความถูกต้อง ได้
- หัวใจสำคัญคือ การชะลอความเร็วลง
- ต้องกันเวลาไว้เพื่อ คิดว่าจะสร้างอะไร และทำไปทำไม พร้อม ปฏิเสธฟีเจอร์ที่ไม่จำเป็นอย่างเด็ดขาด
- จำกัดปริมาณโค้ดที่เอเจนต์สร้างได้ในแต่ละวันให้อยู่ในระดับที่ สามารถตรวจทานได้
- สถาปัตยกรรม, API และรูปทรงแก่นแท้ของระบบ ต้องให้คนเขียนด้วยตนเอง
- ทำ pair programming กับเอเจนต์ เพื่อให้เกิด แรงเสียดทานและโอกาสในการทำความเข้าใจ ระหว่างกระบวนการเขียนโค้ด
- แนวทางนี้ช่วยสร้าง โค้ดเบสที่บำรุงรักษาได้ เพิ่ม ความพึงพอใจของผู้ใช้ และทำให้ทีมโฟกัสที่ ฟีเจอร์หลักแทนฟีเจอร์ที่ไม่จำเป็น
- หากความเข้าใจของมนุษย์ยังคงอยู่ ปัญหา recall ของการค้นหาโดยเอเจนต์ ก็จะบรรเทาลง และเมื่อเกิดปัญหาก็ยัง แก้ไขได้ด้วยตนเอง
- แม้การออกแบบตั้งต้นจะผิดพลาด ก็ยังคงรักษา ความสามารถในการเข้าใจเหตุผลและปรับปรุงมัน ได้
- สิ่งที่จำเป็นในท้ายที่สุดคือ วินัยและความเป็นผู้กระทำของมนุษย์
- คุณภาพและความยั่งยืนของระบบขึ้นอยู่กับ การแทรกแซงและการตัดสินใจของมนุษย์
- การ “ค่อย ๆ ไป” ต่างหากคือหนทางเดียวที่จะรักษา การเรียนรู้และการเติบโต รวมถึง ระบบนิเวศซอฟต์แวร์ที่ดีต่อสุขภาพ ไว้ได้
2 ความคิดเห็น
Pi – เทอร์มินัลโค้ดดิงฮาร์เนสแบบกระชับ
คนที่สร้างอันนี้นี่เอง
ความคิดเห็นจาก Hacker News
ทุกครั้งที่อ่าน บทความเชิงครุ่นคิด แบบนี้ช่วงนี้ ฉันก็รู้สึกเหมือนตัวเองเหนื่อยล้าขึ้นมาเหมือนกัน
สุดท้ายสิ่งสำคัญคือ "เรากำลังสร้างอะไร" และ "เครื่องมือนั้นช่วยได้จริงหรือไม่"
เราเคยทำพลาดแบบเดิมมาแล้วในยุค Ruby, PHP, Lotus Notes และ Visual BASIC
ต้องใช้เครื่องมืออย่างชาญฉลาด และทำงานด้วยความเร็วที่ทำให้ทีมยังเข้าใจ ความเป็นจริงอันซับซ้อน ของสิ่งที่กำลังสร้างอยู่ได้
จะ Agile หรือ Waterfall, จะ Docker หรือ Podman ก็ไม่ใช่แก่นสำคัญ
ทุกวันนี้เราอยู่ในยุคที่ LLM ลบ production DB แล้ววาดภาพประกอบให้ในบล็อก postmortem ได้ด้วย แต่ฉันไม่แน่ใจว่านั่นคือวิศวกรรมจริง ๆ หรือเปล่า
บางทีการพัฒนาซอฟต์แวร์อาจไม่เคยเป็น ศาสตร์เชิงวิศวกรรม มาตั้งแต่แรกก็ได้
ตลอด 10 ปีที่ผ่านมา วงการซอฟต์แวร์เต็มไปด้วย งานระดับเมตา — เฟรมเวิร์กใหม่ เครื่องมือใหม่ ชั้น virtualization ใหม่ โครงสร้างองค์กรใหม่ ฯลฯ
แต่กลับไม่ชัดเจนว่าเราสร้างสิ่งเหล่านี้ไปเพื่อ "อะไร"
มันให้ความรู้สึกคล้าย โครงสร้างแบบพีระมิด ที่สร้างงานใหม่ขึ้นมาเพื่อค้ำจุนอุตสาหกรรมเอง
ถึงอย่างนั้น วิศวกรรมที่แท้จริงก็มีอยู่ — ตอนที่เราตั้งคำถามอย่างเป็นวิทยาศาสตร์ แล้วใช้คำตอบนั้นมาตัดสินใจ
ในทางกลับกัน ถ้าทำงานตาม "สัญชาตญาณ" และทำตาม CEO อย่างเดียว นั่นไม่ใช่วิศวกรรม
สมัยก่อนหลายทีมไม่มีแม้แต่ version control และถึงมีก็มักแย่มาก
ถ้าไปดู Joel Test ของ Joel Spolsky บริษัทส่วนใหญ่ในยุคนั้นคงตอบว่า "ไม่"
สะพานคำนวณน้ำหนักบรรทุก วัสดุ อายุการใช้งานได้อย่างแม่นยำ แต่เว็บไซต์นั้นแค่ traffic ก็ยังคาดเดายาก
ไม่มีมาตรฐานในการจัดการ ขีดจำกัด ของเซิร์ฟเวอร์หรือเฟรมเวิร์กแบบเชิงปริมาณ
สักวันหนึ่งซอฟต์แวร์อาจกลายเป็นวิศวกรรมจริง ๆ ได้ แต่ตอนนี้ยังอีกไกล
การติดคำว่า "วิศวกร" เข้าไป ดูเหมือนเป็นแค่การทำให้หาเงินได้มากขึ้น
วิศวกรตัวจริงให้ความสำคัญกับการพิสูจน์และการตรวจสอบ แต่พวกเรากลับสนุกกับแพตเทิร์นใหม่ ๆ และการลองของใหม่
เพราะงั้นคำว่า "วิศวกร" เลยทำให้รู้สึกกระอักกระอ่วนมากกว่า
เขาวิจารณ์ว่ามันคือ "วิธีการที่ให้คนที่ไม่รู้การเขียนโปรแกรมมาพยายามทำโปรแกรม" ซึ่งดูเหมือนจะยังจริงอยู่จนถึงตอนนี้
ทุกวันนี้ กระบวนการพัฒนาที่ขับเคลื่อนด้วย AI กำลังแข็งตัวเป็นมาตรฐานของบริษัทใหญ่ ๆ พร้อมกับ การผูกติดกับ vendor ที่หนักขึ้น
ถ้า codebase เปลี่ยนไปเป็นแบบยึด agent เป็นศูนย์กลาง สุดท้ายก็จะมีแต่ agent เท่านั้นที่เข้าใจโค้ด
พอถึงจุดนั้นราคาก็จะสูงขึ้น และมันอาจกลายเป็น การเปลี่ยนผ่านทางเดียว ที่ทำให้นักพัฒนามนุษย์กลับมาได้ยาก
ฝ่ายมองโลกในแง่ดีชอบพูดว่า "เทคโนโลยีจะแค่ถูกลงและดีขึ้นเสมอ" แต่ก็อาจลงเอยเหมือนตลาดน้ำมันก็ได้
มันเหมือนตอนที่เปลี่ยนจาก DVD ไปสู่สตรีมมิง เราเหมือนต้องซื้อหนังเรื่องเดิมสองรอบ
โมเดลอย่าง Claude Opus 4.6 ตอนนี้แพงขึ้นจนอยู่ระดับ 1 ดอลลาร์ต่อนาที แล้ว และ prompt engineering ก็ช่วยประคองอะไรไม่ได้อีกต่อไป
สุดท้ายบริการ AI เองก็กำลังถูกแบ่งเป็นโครงสร้างชั้น ราคาถูก–กลาง–พรีเมียม
ตอนนี้ prompt engineering แทบถูกมองว่าเป็นการ แหกคุก (jailbreaking) แบบแนบเนียน ไปแล้ว
การ "ให้เช่า" ความสามารถด้านแรงงานความรู้กับบริษัท AI เป็นเรื่องเสี่ยง
พอมีคนพูดว่า "ต้นทุนจะไม่ขึ้นไปกว่านี้แล้ว" บทสนทนาก็จบเลย — เพราะจริง ๆ แล้วพวกเขา ทอยลูกเต๋าไปแล้ว
บริษัทยักษ์ใหญ่ด้าน AI ก็น่าจะเดินตามเส้นทางเดียวกัน
สุดท้ายเราอาจติดอยู่ใน ตลาดของผู้เสพติดโทเคน ก็ได้
มือที่มองไม่เห็น ของโอเพนซอร์สน่าจะทำให้ทุกอย่างฟรีในท้ายที่สุด
เมื่อทั้งฮาร์ดแวร์และซอฟต์แวร์พัฒนาขึ้น ราคาต่อการคำนวณก็ลดลงเรื่อย ๆ
เทคโนโลยีที่ไม่มีการใช้งานจริงแบบกระแสบล็อกเชนสุดท้ายก็หายไป แต่ AI มีผู้ใช้จริง
บริการอย่าง Uber ที่เคยถูกวิจารณ์หนักในช่วงแรก สุดท้ายก็ลงหลักปักฐานเป็น ธุรกิจที่ยั่งยืน ได้
ต่างจากน้ำมัน การประมวลผลนั้นถูกลงและเร็วขึ้นทุกปี
ผู้เขียนบทความนี้คือคนที่สร้างเฟรมเวิร์กโอเพนซอร์สสำหรับ coding agent ชื่อ Pi
และมันถูกใช้ใน OpenClaw ด้วย
บล็อกโพสต์เกี่ยวกับ Pi ของเขาก็น่าอ่านเหมือนกัน
เขาเป็นคนที่ลงลึกกับ LLM และ agent มากกว่าใครหลายคน
ยิ่งเป็นบริษัทที่อ้างว่า "AI เขียนโค้ดได้ 100%" ก็ยิ่งมักปล่อย ผลิตภัณฑ์ที่เละเทะ ออกมา
ในยุค DOS หรือ MacOS ถ้าเป็นโค้ดแบบนั้น ระบบทั้งเครื่องอาจล่มได้เลย คุณภาพจึงสำคัญกว่า
ตอนนี้ OS ใจดีกว่าเดิม ทำให้ โค้ดหละหลวม ยังพอรอดได้
เพราะมี OTA update จึงปล่อยสินค้าที่ยังไม่เสร็จดีได้ง่าย และพยายามออกก่อนคู่แข่ง
แค่สิ่งที่เราจำได้คือผลิตภัณฑ์ส่วนน้อยที่ทำออกมาดี
ตอนนี้แค่มีการเชื่อมต่อเครือข่าย แม้แต่ OS ก็อัปเดตได้ง่ายราวกับเกม
coding agent ก็เหมือน 'ไซเรนผู้ล่อลวง'
ตอนแรกมันดูเร็วและฉลาด แต่พอเริ่มคิดว่า "คอมพิวเตอร์ เอางานฉันไปทำแทนที" ทุกอย่างก็พัง
แต่สิ่งนี้เป็นเพียงชั่วคราว — AI กำลังเหนือกว่ามนุษย์แล้วใน ขอบเขตที่วัดผลได้
ปัญหาที่แท้จริงคือ HCI (ปฏิสัมพันธ์ระหว่างมนุษย์กับคอมพิวเตอร์)
การออกแบบอินเทอร์เฟซที่สอดคล้องกับคุณค่าของมนุษย์ต่างหากคือโจทย์สำคัญต่อจากนี้
ตอนนี้คือจุดสูงสุดของ ช่วง AI ร้อนแรงเกินจริง
คล้ายกับสมัยที่ MongoDB หรือ NoSQL เคยประกาศว่า "SQL ตายแล้ว" สุดท้ายผู้คนก็จะกลับมาหา จุดสมดุลที่อยู่กับความจริงได้
NoSQL ไม่ได้หายไป แต่ตอนนี้ถูกใช้เฉพาะในที่ที่จำเป็น
ฉันเห็นด้วยกับคำพูดที่ว่า "ซอฟต์แวร์ทุกวันนี้ทั้งเปราะและเละเทะ" แต่จริง ๆ แล้ว ตัวซอฟต์แวร์เองไม่ได้เปลี่ยนไป
เมื่อก่อนเราไม่ไว้ใจมัน จึงต้องมีคนตรวจเอง และความช้านั้นเองที่ช่วยลดปัญหา
หัวใจของ DevOps คือ เคลื่อนที่ให้เร็วบนฐานของความเชื่อมั่น พร้อมรักษาคุณภาพไว้
เหมือน Andon cord ของ Toyota ถ้าเจอปัญหาต้องหยุดทันทีและแก้ที่ต้นตอ
นี่ไม่ใช่ปัญหาทางเทคนิค แต่เป็น ปัญหาเรื่องวัฒนธรรมและกระบวนการ
ต้องหาจุดที่อินเทอร์เฟซผิดพลาดหรือบริบททางธุรกิจไม่สอดคล้องกันให้เจอแต่เนิ่น ๆ
เมื่อทุกคนใช้ GitHub, AWS, Cloudflare เหมือนกัน ถ้าที่เดียวหยุด ทั้งโลกก็หยุด
ถ้าเจอบั๊กก่อน tape-out พวกเขาจะพิจารณาอย่างระมัดระวังโดยไม่ โทษคนส่งข่าว
ผลผลิตของการเขียนโปรแกรมไม่ได้มีแค่โค้ด แต่รวมถึง ตัวโปรแกรมเมอร์เอง ด้วย
แบบจำลองทางความคิดและความจำระดับกล้ามเนื้อ ที่สะสมขึ้นระหว่างเขียนโค้ดต่างหากคือทรัพย์สินที่แท้จริง
ถ้า AI มาแทนกระบวนการนี้ สุดท้าย การเติบโตของโปรแกรมเมอร์ ก็จะหายไป
Jonathan Blow ก็พูดถึงประเด็นเดียวกันใน "Preventing the Collapse of Civilization"
ดู "Programming as Theory Building" ได้
เมื่อวานฉันคุยเรื่องคล้าย ๆ กันกับเพื่อนร่วมงาน
เราดูเดโมที่ AI อ่าน log แก้บั๊ก และเขียน postmortem ได้เอง แต่
ปัญหาคือ มนุษย์ไม่มีเวลาพอจะทำให้กระบวนการนั้นกลายเป็นความเข้าใจภายในของตัวเอง
เหมือนคำพูดที่ว่า "รถจะวิ่งเร็วได้ก็เพราะมีเบรก"
เราต้องคง แรงเสียดทานของการเรียนรู้ ไว้ในระดับที่มนุษย์ยังตามเข้าใจได้ทัน
ถ้า agent รับรู้และกู้คืนได้เอง มนุษย์ยังจำเป็นต้องเรียนรู้หรือไม่?
แน่นอนว่ามันอาจพลาดสาเหตุราก แต่ถ้า ระบบซ่อมแซมตัวเอง แข็งแกร่งพอ นั่นยังถือเป็นปัญหาอยู่ไหม?
แม้แต่ในมุมของ product design ก็รู้สึกถึงปัญหาคล้ายกัน
ความเร็วในการพัฒนาสูงเกินไปจนไม่มีเวลา ลองใช้เองแล้วตรวจสอบ
ถ้าสั่งสมฟีเจอร์ลงไปบนการออกแบบที่ผิด การย้อนกลับทีหลังก็ยาก
สุดท้ายสิ่งสำคัญคือ ไม่ใช่ความเร็ว แต่คือสมดุลระหว่างคุณภาพกับการเรียนรู้
และกระบวนการแบบนี้ ต้องใช้เวลาเสมอ