"make my build faster" — Copilot ใน Visual Studio 2026 จูนเวลาบิลด์ C++ ให้เอง และวัดที่ incremental build ไม่ใช่แค่ clean build

วันที่ 17 กรกฎาคม 2026 ทีม C++ ของ Microsoft ประกาศฟีเจอร์ใหม่ใน GitHub Copilot build performance for Windows ชื่อ Iterative Build Tool ซึ่งเปิดให้ใช้แล้วใน Visual Studio 2026 เวอร์ชัน 18.6.1 (Stable) และ 18.7 (Insiders)

วิธีเรียกใช้เรียบง่ายมาก: เปิดโปรเจกต์ C++ แล้วพิมพ์ “make my build faster” ใน Copilot Chat

แต่สิ่งที่ทำให้ประกาศนี้น่าสนใจกว่าฟีเจอร์ “AI ช่วยจูน” ทั่วไป คือ สิ่งที่มันเลือกจะวัด

ปัญหาคือ clean build ไม่ใช่สิ่งที่นักพัฒนาเจอทุกวัน

เครื่องมือวัดเวลาบิลด์ส่วนใหญ่รายงานเวลา clean build คือลบทุกอย่างแล้วคอมไพล์ใหม่หมด ซึ่งเป็นตัวเลขที่วัดง่ายและเปรียบเทียบง่าย แต่ไม่ตรงกับชีวิตจริงของคนเขียนโค้ด — วันหนึ่งคุณอาจ clean build หนึ่งหรือสองครั้ง แต่คุณกด build หลังแก้ไฟล์ไปสามบรรทัด หลายสิบครั้ง

ผลคือการจูนตามตัวเลข clean build อาจพาไปผิดทาง บทความยกตัวอย่างที่ตรงจุดที่สุดไว้ว่า “For example, precompiled headers can look slower in a clean rebuild but make your real, everyday incremental builds noticeably faster”

นี่คือกับดักคลาสสิกของ precompiled headers — การสร้าง PCH เองกินเวลาในรอบแรก ทำให้ clean build ดูแย่ลง แต่ทุกรอบหลังจากนั้นมันคือกำไรล้วน ๆ ถ้าเครื่องมือของคุณรายงานแค่ตัวเลขแรก คุณอาจถอดสิ่งที่ควรใส่ออกไป

Iterative Build Tool จึงวัดและ แสดงทั้งเวลา clean build และเวลา incremental build เทียบกัน เพื่อให้เห็นภาพครบ

เอเจนต์ที่พิสูจน์ข้อเสนอของตัวเองก่อน

ส่วนที่สำคัญที่สุดในเชิงออกแบบคือลูปการทำงาน ตามประกาศ เอเจนต์จะ เสนอการปรับแต่ง → รัน incremental build จริงเพื่อตรวจสอบว่าได้ผลไหม → เก็บไว้เฉพาะการเปลี่ยนแปลงที่ทำให้เร็วขึ้นจริง โดยการตัดสินใจขั้นสุดท้ายยังอยู่ที่ผู้ใช้

ลูปนี้ต่างจากผู้ช่วย AI แบบเดิมตรงที่มันไม่ได้หยุดอยู่ที่การ “แนะนำ” — LLM รู้ดีอยู่แล้วว่าคำแนะนำเรื่องเร่งบิลด์ C++ มีอะไรบ้าง (unity builds, PCH, /MP, ลด header dependency) เพราะมันอยู่ในบทความนับหมื่นชิ้นบนอินเทอร์เน็ต ปัญหาคือคำแนะนำเหล่านั้น ได้ผลไม่เท่ากันในแต่ละโปรเจกต์ และบางอันทำให้ช้าลงด้วยซ้ำ

การให้เอเจนต์รันบิลด์จริงแล้วเก็บเฉพาะสิ่งที่วัดได้ว่าดีขึ้น จึงเปลี่ยนงานนี้จาก “เดาโดยอาศัยความรู้ทั่วไป” เป็น “ทดลองกับ codebase ตรงหน้า”

มุมมอง AI Curator

สิ่งที่ควรจับจากประกาศนี้คือ รูปแบบ ไม่ใช่ฟีเจอร์

รูปแบบนั้นคือ propose → measure → keep only what wins และมันคือคำตอบตรง ๆ ต่อจุดอ่อนที่ใหญ่ที่สุดของเอเจนต์เขียนโค้ดในปัจจุบัน — เอเจนต์เก่งมากในการผลิตสิ่งที่ ฟังดูถูก แต่ไม่มีทางรู้ว่ามัน ได้ผลจริงไหม ถ้าไม่มีการวัด งานปรับปรุงประสิทธิภาพเป็นสนามที่เผยจุดอ่อนนี้ชัดที่สุด เพราะคำแนะนำที่ถูกต้องตามตำราสามารถทำให้ระบบช้าลงได้จริง ๆ

น่าสนใจว่าประกาศนี้กับอีกเรื่องที่ Microsoft ปล่อยวันเดียวกัน — การใช้ Dev Proxy คั่นไม่ให้ eval ของ agent skill ยิง API จริง — พูดเรื่องเดียวกันจากคนละมุม คือ เอเจนต์จะเชื่อถือได้ต่อเมื่อมีเครื่องวัดที่นิ่งพอจะบอกได้ว่ามันทำถูกหรือผิด ทิศทางของ Microsoft ตอนนี้ดูเหมือนจะไม่ใช่การทำให้เอเจนต์ฉลาดขึ้น แต่คือการสร้างลูปป้อนกลับให้เอเจนต์รู้ตัวว่าพลาด

สำหรับทีมไทยที่ทำงานกับ C++ — เกม, embedded, ระบบการเงินความหน่วงต่ำ, งาน CAD/วิศวกรรม — นี่เป็นเรื่องที่คุ้มค่าลองทันที เพราะเวลาบิลด์คือต้นทุนที่ทุกคนบ่นแต่แทบไม่มีใครได้รับมอบหมายให้แก้ มันไม่เคยชนะ backlog ที่มีฟีเจอร์รออยู่ การมีเอเจนต์ที่ลงมือทดลองและพิสูจน์ผลให้เองจึงลดต้นทุนการเริ่มต้นของงานประเภทนี้ลงมาก

ข้อควรระวังคืออย่าปล่อยให้ตัวเลขบนเครื่อง dev นำทางอย่างเดียว ควรตรวจด้วยว่าการปรับแต่งที่เอเจนต์เก็บไว้ยังสมเหตุสมผลบนเครื่อง CI ซึ่งเริ่มจากศูนย์ทุกครั้ง — เพราะการจูนที่ดีที่สุดสำหรับ incremental build บนเครื่องคุณ ไม่จำเป็นต้องดีที่สุดสำหรับ pipeline ที่ทำ clean build เสมอไป และนั่นคือด้านกลับของบทเรียนเรื่อง PCH ในบทความนี้เอง

แหล่งข่าว

• Faster C++ iterative builds with GitHub Copilot — Microsoft C++ Team Blog (17 ก.ค. 2026)
• Microsoft C++ Team Blog
• Visual Studio 2026 release notes