AI coding agents คืออะไร และทำไมการเทสจึงกลายเป็นคอขวดใหม่
AI coding agents คือกลุ่มระบบปัญญาประดิษฐ์ที่รับคำสั่งจากนักพัฒนาเพื่อสร้าง แก้ไข และจัดระเบียบโค้ดแบบอัตโนมัติหลายงานพร้อมกัน ลดภาระงานเขียนโค้ดยิบย่อยลงอย่างมาก และเปลี่ยนบทบาทของวิศวกรซอฟต์แวร์ให้กลายเป็นผู้ควบคุมกองทัพเอเจนต์แทนการลงมือเขียนเองทุกบรรทัด โดยมุ่งให้ผลิตฟีเจอร์ได้เร็วขึ้นในโครงสร้างแอปที่ซับซ้อน
โลกวิศวกรรมซอฟต์แวร์เพิ่งเปลี่ยนจากการใช้เครื่องมือช่วยเขียนโค้ดเล็กน้อย ไปสู่ยุคที่งานส่วนใหญ่คือการรู้วิธีสั่ง AI coding agents หลายตัวพร้อมกันให้ทำงานมากกว่าที่วิศวกรคนเดียวเคยทำได้ วิศวกรจำนวนมากรายงานประสบการณ์คล้ายกันคือทุกวันนี้ใช้เวลาไปกับการสั่งเอเจนต์ให้ผลิตโค้ดครั้งละมากๆ แต่กลับพบคอขวดใหญ่ใหม่คือ ไม่สามารถทดสอบฟีเจอร์ได้เร็วเท่ากับความเร็วในการรันเอเจนต์เหล่านั้น พูดง่ายๆ การผลิตโค้ดไม่ใช่ปัญหาอีกต่อไป ปัญหากลับย้ายมาที่การยืนยันว่าโค้ดที่ถูกสร้างทำงานได้จริงบนผลิตภัณฑ์ที่ซับซ้อน
มุมมองที่น่าคิดคือ แม้เราจะลงทุนกับการเขียนโค้ดอัตโนมัติ แต่ถ้าการทดสอบยังอืดเหมือนเดิม ทีมก็ไม่ได้เคลื่อนที่เร็วขึ้นเท่าไร สิ่งที่ขาดหายคือวิธีคิดเรื่อง testing automation และ QA optimization ที่ทันกับยุคเอเจนต์
เมื่อเอเจนต์เขียนโค้ดเร็ว แต่ต้องมานั่งสำรวจหน้าจอใหม่ทุกครั้ง
นักพัฒนาหลายคนพยายามแก้ปัญหาคอขวดด้วยการให้ AI coding agents มาช่วยทำ testing automation และ QA แทนมนุษย์ ฟีเจอร์ทุกชิ้นต้องผ่านรอบเทสเหมือนที่วิศวกรคลิกปุ่ม ไล่หน้าจอ และตรวจสอบว่าฟีเจอร์ทำงานถูกต้อง โดยมักเชื่อมเอเจนต์เข้ากับเครื่องมืออย่าง Playwright MCP เพื่อสั่งให้มันเปิดเบราว์เซอร์ เทสระบบ จากโค้ดในรีโปเดียวกัน
ปัญหาคือเอเจนต์เหล่านี้มีพฤติกรรมแบบมือใหม่เข้าระบบทุกครั้ง วนลูปเปิดหน้า ถ่ายภาพหน้าจอ วิเคราะห์ แล้วค่อยลงมือคลิกหรือกรอกข้อมูลใหม่อีกรอบ ทุกครั้งที่ทำเช่นนี้ มันสิ้นเปลืองทั้งโทเคนและเวลา เพราะต้องค้นหาและทำความเข้าใจหน้าจอราวกับเห็นเป็นครั้งแรก และยังเสียเวลาไปกับการ grep โค้ดเพื่อเดาว่าองค์ประกอบบนหน้าเกี่ยวข้องกับอะไรบ้าง การจะสร้าง lifecycle แบบ AI-native จึงติดที่เราแก้ด้านการสร้างโค้ดแล้ว แต่ด้านการทดสอบและการยืนยันผลยังแทบไม่ขยับ
การปล่อยให้เอเจนต์สำรวจผลิตภัณฑ์เองทุกครั้งอาจพอรับได้ถ้าแอปเล็ก แต่ในระบบใหญ่ที่มีหลายบทบาทผู้ใช้และฟลูว์งานซับซ้อน มันคือการเผาเวลา QA และเครดิตโมเดลอย่างไม่น่าให้อภัย
จาก feature map สู่ product surface graph แผนที่ใหม่ของการเทส
แนวคิดหนึ่งที่เกิดขึ้นคือการสอนเอเจนต์ให้เข้าใจผลิตภัณฑ์ด้วยเอกสาร feature map ซึ่งเป็น markdown ที่อธิบายว่าฟีเจอร์ต่างๆ ทำงานอย่างไร แล้วรวบไว้ในโฟลเดอร์สำหรับการ verification เพื่อให้เอเจนต์ใช้เป็นบริบทเมื่อทดสอบฟีเจอร์ ผลลัพธ์คือเวลาการเทสที่เคยใช้ราว 25 นาทีในฟีเจอร์ที่ต้องไล่หลายหน้าจอ ลดลงเหลือราว 15 นาที นี่คือสัญญาณชัดว่า แผนที่ของฟีเจอร์ช่วยเร่ง QA optimization ได้จริง
แต่ feature map แบบรายการแบนมีข้อจำกัด มันไม่สะท้อนว่าฟีเจอร์ต่างๆ เชื่อมกันอย่างไร ทั้งเส้นทางข้ามหลายหน้า overlay ที่ซ้อนหลายชั้น หรือเส้นทางการใช้งานของผู้ใช้หลาย persona จึงเกิดแนวทางใหม่คือการสร้างกราฟความรู้ที่เก็บวิธีทำงานของผลิตภัณฑ์ว่าฟังก์ชันอยู่ตรงไหน ผู้ใช้เดินทางอย่างไร และเวิร์กโฟลว์ที่ใช้ทำงานคืออะไร ผู้เขียนเรียกกราฟนี้ว่า product surface graph โดยกำหนดให้โหนดแต่ละจุดคือ surface ที่ผู้ใช้หรือเอเจนต์สามารถยืนอยู่และทำงานได้ อาจเป็นหน้า โมดอล ชีต ดรอว์เวอร์ หรือพื้นที่ใดในหน้าเดียวกัน
งานวิจัยด้าน browser agents ก็ชี้ไปในทิศทางเดียวกัน คือการมอง GUI เป็นกราฟของสถานะหน้าและเส้นทาง แล้วให้เอเจนต์วางแผนจากกราฟนั้น แทนลูปเปิดภาพหน้าจอคิดแล้วคลิกทีละขั้น กล่าวอีกแบบ การเทสอย่างมีประสิทธิภาพต้องมีแผนที่ ไม่ใช่แค่ความฉลาดของเอเจนต์
กรณีศึกษา Proaction: โค้ดเร็ว แต่อย่าปล่อยให้การเทสช้ากว่าเซลส์
ตัวอย่างของการคิดแบบ AI-native ในผลิตภัณฑ์เห็นชัดในบริษัทที่สร้างแพลตฟอร์มบริหารฟลีทรถสำหรับธุรกิจตั้งแต่รถยนต์ รถบรรทุก ไปจนถึงเครื่องจักรก่อสร้าง งานขายของพวกเขาต้องอธิบายให้ลูกค้าแต่ละรายเห็นว่าระบบปรับให้เข้ากับฟลีตของตนได้อย่างไร แต่เดิมการทำเดโมเฉพาะรายกินเวลาและกำลังของทีมวิศวกรจนแทบทำไม่ไหว ทีมผู้ก่อตั้งต้องอาศัยแค่การคุยและสไลด์พรีเซนต์ซึ่งไม่ตอบโจทย์มากนัก
เมื่อหันมาใช้เอเจนต์โค้ดอย่าง Codex ผู้ร่วมก่อตั้งที่ไม่ใช่สายเทคนิคสามารถสร้างเดโมโต้ตอบเฉพาะรายเดือนละ 4–6 เดโม ใช้เวลาดemoละ 30–45 นาที และเลี่ยงงานวิศวกรได้ราว 40–60 ชั่วโมงต่อเดือน เขายังประเมินว่าดีลที่เดินหน้าจากคอนแท็กครั้งแรกไปสู่การพัฒนาทางออก แทนที่จะเข้าสู่โหมดเลี้ยงดูระยะยาว เพิ่มขึ้นราว 50–60 เปอร์เซ็นต์ เดโมที่ดึงข้อมูลรถและเวิร์กโฟลว์ของลูกค้าเข้าจริง ทำให้ลูกค้าเห็นรถ เครื่องจักร และการจัดกลุ่มตามวิธีทำงานของตัวเองบนหน้าจอ สามารถชี้จุดที่ต้องปรับและช่วยออกแบบทางออกได้ทันที
บริษัทเดียวกันยังสร้างศูนย์โซลูชันให้ลูกค้าเข้าไปลองเวิร์กโฟลว์เฉพาะธุรกิจและอ่านเอกสารประกอบด้วย Codex และกำลังพัฒนาเอเจนต์ด้วย GPT‑Live‑1 เพื่อให้จัดการงานประจำวันของฟลีตในสิ่งที่เรียกว่า Managed Execution Layer โดยทีมมนุษย์จะเข้ามาเมื่อจำเป็นต้องตรวจหรือแทรกแซง แนวคิดนี้สะท้อนประเด็นเดียวกับการเทส นั่นคือให้เอเจนต์ทำงานประจำอัตโนมัติ แล้วให้คนโฟกัสงานที่มีความเสี่ยงสูงหรือซับซ้อน
อนาคตของ QA คือ browser agents ที่มีแผนที่ในหัว ไม่ใช่แค่เมาส์ในมือ
เมื่อมี product surface graph อยู่เบื้องหลัง browser agents สิ่งที่เปลี่ยนไปคือวิธีคิดเรื่อง QA ทั้งระบบ เอเจนต์ไม่ต้องไล่เปิดทุกหน้าใหม่ แต่สามารถค้นในกราฟ เลือกเส้นทางที่กระทบกับโค้ดที่แก้ แล้ววางแผนเทสแบบเป็นโปรแกรมเต็มชุดได้ ผลงานทดลองแสดงให้เห็นว่าบนบางเบนช์มาร์ก การมีแผนที่หน้าและสถานะช่วยให้งานสำเร็จสูงถึง 95 เปอร์เซ็นต์ เทียบกับฐานที่ราว 66 เปอร์เซ็นต์
ในทางปฏิบัติ การทำ QA optimization แบบนี้ต้องใช้การจัดองค์ประกอบหลายชั้น ตั้งแต่การแยก subagent ที่ดูแลกลุ่ม surface ต่างกันตามโดเมนของแอป ไปจนถึงการจัดวิธีตรวจจับว่าแผนที่เริ่มเก่าและต้อง reindex ใหม่เพื่อตามทันการเปลี่ยนแปลงของโค้ดและ UI แต่เมื่อโครงสร้างนี้เริ่มเข้าที่ เอเจนต์เทสที่เคยต้องเสียเวลานานในการไล่คลิกหน้าจอก็สามารถลดทั้งเวลาและโทเคนลงอย่างมีนัยสำคัญ
บทสรุปสำหรับทีมพัฒนาคือ ถ้าคุณกำลังลงทุนกับ AI coding agents แต่ยังคิดเรื่องเทสแบบเดิม คุณกำลังย้ายคอขวดจากฝั่งเขียนโค้ดไปกองไว้ฝั่ง QA แทน การสร้าง product surface graph และออกแบบ browser agents ที่มีองค์ความรู้เรื่องผลิตภัณฑ์จึงไม่ใช่ของเล่นวิจัย แต่เป็นโครงสร้างพื้นฐานใหม่ของการพัฒนาซอฟต์แวร์แบบ AI-native ที่จะตัดระยะห่างระหว่างการเขียนกับการยืนยันผลลงไปอย่างเห็นได้ชัด
