เมื่อ AI ช่วยเขียนโค้ดได้เร็วขึ้น งานไม่ได้จบเร็วขึ้นทุกขั้นตอน คิวตรวจโค้ด การทดสอบหน้าจอ และการรับมือปัญหาหลังปล่อยรุ่นยังต้องตามให้ทัน Harald Kirschner จากทีม VS Code เล่าว่า ทีมเปลี่ยนจากรอบออกรุ่นรายเดือนที่ใช้มาราวสิบปีเป็นรายสัปดาห์ได้อย่างไร โดยปรับทั้งระบบงานรอบเอเจนต์ ไม่ได้เร่งเฉพาะการสร้างโค้ด
เรื่องนี้มาจากการบรรยายในช่อง AI Engineer ซึ่งภาพเวทีระบุวันที่ 1 กรกฎาคม 2026 ตัวเลขและวิธีทำงานต่อไปนี้เป็นสิ่งที่ Kirschner รายงานในเวลานั้น ไม่ใช่ผลตรวจอิสระหรือการยืนยันตารางออกรุ่นปัจจุบัน
อ่านตัวเลข code survival ให้ตรงความหมาย
Kirschner เริ่มด้วยตัวชี้วัด code survival หรือสัดส่วนโค้ดที่เอเจนต์เขียนแล้วถูกนำไป commit ในโครงการ สไลด์แสดงค่าประมาณ 55% ในช่วงที่ใช้ GPT-4.1 และ 86% ในช่วงที่ใช้ Claude Opus 4.6 พร้อมย้ำว่าทั้งโมเดลและ harness ซึ่งเป็นระบบควบคุมการทำงานของเอเจนต์พัฒนาขึ้นระหว่างนั้น
ตัวเลขนี้จึงบอกการรับโค้ดเข้าโครงการตามนิยามที่เขาใช้ ไม่ได้แปลว่า 86% ของโค้ดปราศจากบั๊ก และไม่ใช่การทดลองที่เปลี่ยนเฉพาะโมเดลแล้วควบคุมทุกอย่างให้เหมือนเดิม แม้สไลด์จะเชื่อมผลดังกล่าวกับความเชื่อมั่นของนักพัฒนา ก็ยังไม่ควรอ่านเป็นคะแนนความเชื่อมั่นที่วัดแยกโดยตรง
เมื่อเอเจนต์ทำงานได้มากขึ้น ทีมได้รับทั้ง PR และรายงานปัญหาเพิ่มขึ้น Kirschner แยกว่ามีทั้งรายงานที่มีประโยชน์และรายงานอัตโนมัติที่ข้อมูลไม่พอ ขณะเดียวกัน PR จากชุมชนที่ทีมรับเข้าระบบก็เพิ่มขึ้นด้วย โจทย์จึงอยู่ที่การรับมือกับงานจำนวนมากโดยไม่ทำให้คนตรวจกลายเป็นจุดที่ทุกอย่างต้องรอ
เตรียมความรู้และลดเวลารอของเอเจนต์
สิ่งแรกที่ทีมเตรียมคือไฟล์ AGENTS.md แบบกระชับ ให้เอเจนต์รู้โครงสร้างโครงการ จุดเริ่มต้นในการค้นข้อมูล และกติกาที่ต้องทำตาม Kirschner มองเอกสารนี้เป็นสิ่งที่ต้องปรับต่อเมื่อพบปัญหา ไม่ใช่คู่มือที่เขียนครั้งเดียวแล้วใช้ได้ตลอด
อีกตัวอย่างคือความรู้ด้าน accessibility หรือการออกแบบให้ผู้ใช้ที่มีข้อจำกัดต่างกันเข้าถึงผลิตภัณฑ์ได้ ทีมให้ผู้เชี่ยวชาญด้านนี้ดูแล skill ที่คนอื่นเรียกใช้ซ้ำได้ แทนการให้ทุกงานรอคำแนะนำจากผู้เชี่ยวชาญคนเดียว ความรับผิดชอบต่อเนื้อหายังมีเจ้าของ ส่วนเอเจนต์ช่วยนำแนวทางนั้นไปใช้ระหว่างทำงาน
จากนั้นต้องดูว่าเอเจนต์เสียเวลารออะไร Kirschner ยกการย้ายระบบสร้างโปรแกรมไปใช้ TypeScript Go เป็นตัวอย่างของการลดเวลารอบทดสอบ เพราะเมื่อเอเจนต์หลายตัวสร้าง ตรวจ และแก้พร้อมกัน เวลารอที่เคยรับได้สำหรับคนหนึ่งคนอาจกลายเป็นคิวใหญ่ในระบบ CI
บททดสอบที่เขาใช้กับตัวเองในฐานะผู้จัดการผลิตภัณฑ์คือ สามารถส่ง PR ที่มีประโยชน์ได้หรือไม่ และงานนั้นเพิ่มภาระแก่วิศวกรปลายทางเท่าใด เป็นคำถามที่ครอบคลุมทั้งคุณภาพของข้อมูลตั้งต้นและคุณภาพของงานที่ส่งต่อ
ให้เอเจนต์เห็นหน้าจอที่ตัวเองแก้
การอ่านโค้ดอย่างเดียวอาจไม่เห็นว่าไอคอนหายหรือองค์ประกอบขยับ Kirschner เล่าว่าทีมสร้างระบบถ่ายภาพส่วนประกอบหน้าจอ แล้วแสดงความต่างก่อนและหลังแก้ไขบน PR ตัวอย่างในคลิปคือการเพิ่มปุ่มย้อนกลับในหน้าปรับแต่ง AI ซึ่งต้องตรวจว่าการเปลี่ยนแปลงส่งผลต่อส่วนอื่นหรือไม่
ทีมยังใช้ Playwright ร่วมกับ skill สำหรับเปิด VS Code ซึ่งเป็นแอป Electron ให้เอเจนต์ลองคลิกตามสถานการณ์ เก็บข้อผิดพลาด และตรวจผลก่อนกับหลังแก้ไข วิธีนี้เพิ่มช่องทางให้เอเจนต์สังเกตผลของงาน แทนการยืนยันจากการอ่านโค้ดเพียงอย่างเดียว
ภาพเปรียบเทียบและการลองใช้งานยังเป็นหลักฐานให้คนตรวจด้วย ประเด็นสำคัญจึงไม่ใช่ให้ AI รับรองตัวเอง แต่ทำให้งานที่เสนอมีผลตรวจซึ่งทีมเปิดดูและทักท้วงได้
ต่อวงจรจากรายงานปัญหาถึง PR
ในขั้นตรวจโค้ด Kirschner ระบุว่าทีมกำหนดให้ PR ผ่าน GitHub Copilot review และจัดการข้อคิดเห็นก่อนส่งให้คนตรวจต่อ เป็นการวาง AI ไว้ก่อนการตรวจของมนุษย์ ไม่ใช่ตัดการตรวจของมนุษย์ออก
ในขั้นรับรายงานปัญหา เอเจนต์ช่วยกรองสแปม เติมข้อมูล แปลภาษา และส่งงานไปยังผู้รับผิดชอบ ทีมมีเครื่องมือให้คนแก้การจัดหมวดและรายงานซ้ำ แล้วนำข้อแก้ไขกลับไปปรับระบบด้วย
สำหรับ telemetry หรือข้อมูลการทำงานของโปรแกรม กระบวนการที่เขาเล่าเริ่มจากกรองข้อมูลข้อผิดพลาดให้ครบ จัดกลุ่มอาการที่ซ้ำกัน และสร้าง issue พร้อมระบุเจ้าของ ก่อนให้เอเจนต์เสนอ PR เพื่อแก้ไข ขั้นตอนนี้ผสมระบบกฎตายตัวกับ AI ไม่ได้โยนข้อมูลดิบทั้งหมดให้โมเดลตัดสิน และยังมีคนพิจารณาก่อนรับโค้ดเข้าระบบ
สิ่งที่ต่อเนื่องกันทั้งสามขั้นคือ ต้องมีทางแก้เมื่อ AI จัดหมวดผิดหรือเสนอสิ่งที่ไม่เหมาะสม การมีเอเจนต์เพิ่มขึ้นโดยไม่มีช่องทางรับข้อแก้ไขจะทำให้ทีมต้องคอยจัดการความผิดพลาดเดิมซ้ำๆ
ออกรุ่นถี่ขึ้น พร้อมจำกัดผลกระทบ
Kirschner อธิบายว่าทีมเปลี่ยนจากการปล่อยรุ่นให้ผู้ใช้ทั้งหมดพร้อมกัน เป็นการทยอยปล่อยและดูข้อมูลข้อผิดพลาดกับรายงานปัญหาระหว่างทาง เหตุผลหนึ่งคือ VS Code เป็นแอปที่ติดตั้งบนเครื่องผู้ใช้ การย้อนกลับหลังปล่อยแล้วมีต้นทุนต่างจากการเปลี่ยนระบบเว็บส่วนกลาง
นี่เป็นส่วนที่ทำให้เรื่องรอบออกรุ่นต่างจากเรื่องเขียนโค้ดเร็วขึ้น การส่งงานถี่ต้องมีทั้งวิธีตรวจให้ทันก่อนปล่อย และวิธีจำกัดผลกระทบเมื่อปัญหาปรากฏหลังปล่อยแล้ว ในคลิปไม่ได้ให้ข้อมูลเพียงพอที่จะสรุปว่าอัตราบั๊กลดลงเท่าใดจากการเปลี่ยนรอบออกรุ่น
ใช้การทดสอบและต้นแบบช่วยเลือกงาน
ทีมใช้ VSC-Bench เป็นชุดประเมินที่ผูกกับงานของผลิตภัณฑ์ โดยนำสถานการณ์จาก issue และบทสนทนากับลูกค้ามาสร้างกรณีทดสอบ มีแม่แบบบน GitHub และให้เอเจนต์ช่วยเตรียมสถานการณ์ เพื่อทำให้ปัญหาที่เคยพบกลายเป็นสิ่งที่ตรวจซ้ำได้
ตัวอย่างหนึ่งในสไลด์เป็นงานไฟล์ข้อความเล็กๆ ที่ให้ผลลัพธ์ถูกเหมือนกัน แต่ใช้โทเคนต่างกันได้ถึงราว 70 เท่าในชุดทดสอบที่ผู้บรรยายนำเสนอ เขาใช้ตัวอย่างนี้ชี้ว่าโมเดลกับระบบควบคุมงานอาจใช้ความพยายามไม่เท่ากัน ตัวเลขดังกล่าวไม่ได้บอกว่าโมเดลหนึ่งประหยัดกว่าอีกโมเดลเท่านี้ในทุกงาน และในภาพไม่ได้เปิดรายละเอียดเพียงพอให้จัดอันดับผลิตภัณฑ์ตามชื่อ
ส่วนการตัดสินใจว่าจะสร้างอะไร Kirschner ใช้ต้นแบบเป็นตัวเปิดบทสนทนากับทีม ตัวอย่างเครื่องมือถามคำถามเริ่มจาก PR หยาบๆ ก่อนทีมช่วยกันปรับให้เป็นประสบการณ์ที่สมบูรณ์ขึ้น เขาย้ำการทำงานเป็นขอบเขตเล็ก ปรับกันถี่ และมีเจ้าของงานต่อเนื่อง
กรณีของ VS Code จึงมีรายละเอียดมากกว่าการเพิ่มจำนวนเอเจนต์: เตรียมความรู้ให้ใช้ซ้ำ ลดเวลารอ ให้ตรวจหน้าจอจริง เปิดทางให้คนแก้การคัดแยก และค่อยๆ ปล่อยรุ่นพร้อมติดตามผล ทีมที่อยากนำแนวคิดไปใช้ควรเริ่มจากหาว่างานติดอยู่ขั้นใด แล้วเลือกปรับขั้นนั้นพร้อมเก็บผลก่อนและหลัง ไม่จำเป็นต้องตั้งเป้าออกรุ่นรายสัปดาห์เหมือนกัน
ที่มา: How VS Code Went from Monthly to Weekly Releases with AI โดย Harald Kirschner ช่อง AI Engineer เรียบเรียงจากบทถอดเสียงและภาพที่บันทึกใน VideoToBlog บทความต้นฉบับลงวันที่ 3 ตุลาคม 2026 ส่วนภาพการบรรยายระบุวันที่ 1 กรกฎาคม 2026
