GitHub พอร์ต Copilot Runtime สู่ Rust 8 แสนบรรทัดด้วย AI

GitHub Copilot CLI, GitHub Copilot app และ GitHub Copilot SDK ทั้งหมดขับเคลื่อนด้วย Copilot agent runtime ซึ่งเป็นหัวใจสำคัญที่ฝังอยู่ในแอปพลิเคชันต่างๆ เดิมทีระบบนี้เขียนด้วย TypeScript บน Node.js และเอนจิน V8 สำหรับ GitHub Copilot cloud agent (CCA) และใช้งานต่อมาท่ามกลางการเติบโตอย่างรวดเร็ว

ปัจจุบันมีการเปลี่ยนแปลงครั้งใหญ่เกิดขึ้น โดยทีมพัฒนาได้เขียน runtime ใหม่ทั้งหมดเป็นภาษา Rust รวมโค้ดบนโปรดักชันกว่า 800,000 บรรทัด โดยมี AI agents เป็นผู้เขียนโค้ดส่วนใหญ่ ครอบคลุม pull request ถึง 128 รายการที่ส่งเข้าสาขาหลักแบบเพิ่มทีละส่วน (incrementally) แทนที่จะรอเปลี่ยนผ่านรวดเดียวในตอนท้าย ผลลัพธ์คือประสิทธิภาพเพิ่มขึ้นหลายเท่าตัว งานที่ควรใช้ทีมนักพัฒนาทั้งทีมเป็นเวลา 1-2 ปี กลับเสร็จสมบูรณ์ได้ด้วยนักพัฒนาเพียงคนเดียวในเวลาเพียงไม่กี่เดือน

ทำไมเราถึงต้องพอร์ต

Copilot agent runtime ไม่ได้เป็นเพียงเอนจินของ Copilot CLI เท่านั้น แต่ยังรองรับโซลูชันที่เติบโตขึ้นเรื่อยๆ ทั้งใน VS Code, Visual Studio, Copilot Code Review (CCR), Copilot Studio รวมถึงแอปในชุด Microsoft 365 อย่าง Excel และ Word การใช้ GitHub Copilot SDK ช่วยให้ผลิตภัณฑ์เหล่านี้มุ่งเน้นไปที่มูลค่าทางธุรกิจหลักและปล่อยให้รายละเอียดของ agent loop เป็นหน้าที่ของ runtime

ปัญหาสำคัญอยู่ที่ตัว runtime เดิมซึ่งใช้ TypeScript และ Node.js แม้จะพัฒนาได้ไวและเหมาะกับแอปคอนโซล แต่กลับมีข้อจำกัดเรื่องประสิทธิภาพเมื่อต้องนำไปใช้ในสภาพแวดล้อมอื่นที่ต้องการการเริ่มต้นใช้งาน (startup) ที่รวดเร็ว หรือต้องการประหยัดหน่วยความจำเมื่อรันบนเซิร์ฟเวอร์จำนวนมาก

นอกจากนี้ สถาปัตยกรรมเดิมยังมีความซับซ้อนในการสื่อสารข้ามกระบวนการ (out-of-process) ผ่านโปรโตคอล JSON-RPC ซึ่ง SDK ในภาษาต่างๆ เช่น C#, Python หรือ Java ต้องแบกรับภาระการติดตั้ง Node.js และ V8 ขนาดกว่า 100 MB เพียงเพื่อใช้งานฟังก์ชันพื้นฐาน การแครชใน Node ยังส่งผลให้ session ทั้งหมดหายไป และสร้างความยุ่งยากในการตรวจสอบจุดบกพร่อง

เป้าหมายใหม่คือการสร้าง runtime ที่เป็นไลบรารีแยกอิสระ มี overhead ต่ำ สามารถฝังลงในกระบวนการ (in-process) ได้โดยตรง และทำงานร่วมกับ SDK ได้หลากหลายภาษาผ่าน C ABI ซึ่ง Rust คือคำตอบที่ตอบโจทย์ทั้งด้านความปลอดภัย ประสิทธิภาพ และความสามารถในการทำงานร่วมกับภาษาอื่น (interop)

หน้าตาของมันก่อนหน้านี้

แผนการพอร์ตเริ่มแรกในเดือนพฤษภาคม 2026 ประมาณการโค้ด TypeScript ไว้ที่ 130,000 บรรทัด แต่ในความเป็นจริงระหว่างการพอร์ตกลับมีโค้ดที่ต้องจัดการเพิ่มขึ้นเรื่อยๆ จนถึง 430,000 บรรทัด เนื่องจากมีการส่งโค้ดใหม่เข้ามาอย่างต่อเนื่องโดยนักพัฒนาคนอื่นๆ ในทีม

ในช่วง 14 สัปดาห์ของการพอร์ต มีการนำโค้ด TypeScript ออกไปประมาณ 430,000 บรรทัด และแทนที่ด้วยโค้ด Rust ในส่วนโปรดักชันกว่า 1,200,000 บรรทัด (รวมส่วนที่คัดออกระหว่างทาง) จนกลายเป็น Rust 100% ในวันที่ 21 สิงหาคม

กลยุทธ์การพอร์ตแบบ In-place

ทีมเลือกใช้วิธีพอร์ตแบบ In-place หรือการเปลี่ยนทีละส่วนประกอบแทนการเขียนใหม่ทั้งหมดแล้วสลับรวดเดียว (Big bang) ด้วยเหตุผลดังนี้:

• ไม่ต้องหยุดงาน: นักพัฒนาคนอื่นยังคงทำงานในสาขาหลักได้ตามปกติ
• พร้อมจัดส่งเสมอ: แต่ละ pull request จะเปลี่ยน TypeScript เป็น Rust ทันที ทำให้โค้ดใหม่ถูกใช้งานจริงได้ตลอดเวลา
• ตรวจสอบได้ง่าย: การเปลี่ยนทีละส่วนช่วยให้มนุษย์และ AI ตรวจสอบความแตกต่าง (diff) ได้แม่นยำขึ้น
• ใช้การทดสอบเดิม: สามารถรันการทดสอบ end-to-end ที่มีอยู่เทียบกับโค้ด Rust ใหม่ได้ในทุกขั้นตอน

การเริ่มต้น

เริ่มต้นจากการสร้างโครงสร้างพื้นฐานอย่าง Rust workspace, CI และ build pipeline จากนั้นจึงพอร์ตตรรกะพื้นฐานที่ไม่มีสถานะ (pure-logic) เพื่อทดสอบกลไกการส่งมอบทั้งหมด ก่อนจะขยับไปสู่ส่วนที่มีความซับซ้อนสูงอย่างระบบจัดการไฟล์และสถานะ session

Interop

การทำงานร่วมกันระหว่างภาษาแบ่งเป็น 2 ส่วนหลัก:

1. Temporary internal interop: ใช้ napi-rs เพื่อให้โค้ด Rust และ TypeScript เรียกใช้งานกันได้ชั่วคราวระหว่างรอพอร์ตส่วนที่เหลือ
2. SDK surface: พัฒนาประตูหน้า (entry points) ใหม่ผ่าน C ABI ทำให้ SDK ในภาษาอื่นๆ สามารถโหลด runtime เข้าสู่กระบวนการของตัวเองได้โดยตรงผ่าน FFI

แม้วิธีนี้จะยังคงใช้ JSON-RPC ในการสื่อสารเพื่อความสะดวกในการสลับรูปแบบโฮสติ้ง แต่การเปลี่ยนมาใช้ Rust ช่วยลดภาระการข้ามขอบเขตกระบวนการ (out-of-process) และทำให้ SDK ทั้ง 6 ภาษาเข้าถึง API ที่เติบโตขึ้นได้ผ่านจุดเชื่อมต่อเพียงไม่กี่จุด

ข้อมูลของ session แสดงอะไรบ้าง

จากการวิเคราะห์ข้อมูลบันทึกของ AI agent พบสถิติที่น่าสนใจ:

• มีการเรียกใช้ข้อความจากผู้ช่วยกว่า 1.3 ล้านข้อความ
• ข้อความจากมนุษย์มีประมาณ 2,600 ข้อความ ซึ่งเน้นไปที่การตรวจสอบ (Review), การทดสอบ และการท้าทายการตัดสินใจของ AI
• บทบาทของมนุษย์เปลี่ยนจากการเขียนโค้ดเป็นการคุมทิศทางและควบคุมคุณภาพในระดับที่สูงขึ้น

ทุกอย่างขึ้นอยู่กับการทำ caching

การทำ Prompt Caching มีความสำคัญอย่างมากต่อต้นทุน ข้อมูลพบว่ามีอัตราการเกิด cache hit สูงถึง 96.22% ช่วยลดค่าใช้จ่ายในการประมวลผลได้ถึง 10 เท่า ซึ่งเป็นหัวใจสำคัญที่ทำให้การใช้ AI agent ทำงานต่อเนื่องยาวนานหลายร้อยชั่วโมงมีความคุ้มค่าในเชิงเศรษฐกิจ

การวิเคราะห์แบบ Static Analysis ช่วยได้

แม้ Rust จะขึ้นชื่อเรื่องความเข้มงวดของคอมไพเลอร์ แต่จากการวิเคราะห์พบว่าปัญหาที่คอมไพเลอร์ตรวจพบส่วนใหญ่คือเรื่องพื้นฐานอย่างชื่อตัวแปรผิดหรือประเภทข้อมูลไม่ตรงกัน ซึ่งภาษาที่มี Static Typing อื่นๆ ก็ทำได้ ข้อดีที่แท้จริงคือการใช้เครื่องมือเหล่านี้เป็นวงจรตอบกลับ (feedback loop) ที่รวดเร็วให้แก่ AI

Agent ชอบการอ่าน

ข้อมูลการเรียกใช้เครื่องมือแสดงให้เห็นว่า AI agent ใช้เวลาในการสำรวจและรวบรวมหลักฐานมากกว่าการแก้ไขโค้ดถึง 10 เท่า งานส่วนใหญ่คือการตรวจสอบสถานะปัจจุบัน การค้นหาไฟล์ และการวินิจฉัยเพื่อสร้างสมมติฐานก่อนลงมือแก้ไขจริง

การทำงานร่วมกับฝูง Agent

ในการพอร์ตส่วนประกอบที่ซับซ้อนอย่าง session.ts (30,000 บรรทัด) ระบบได้ใช้โครงสร้างแบบลำดับชั้น โดยมี parent agent คอยมอบหมายงานให้ sub-sessions อีก 15 ตัวแยกไปทำงานในแต่ละสาขา (branch) ของตัวเองขนานกัน

การทำงานขนานกันนี้ช่วยให้โครงการเดินหน้าได้เร็ว แต่ก็ต้องการการประสานงานที่ซับซ้อน บางครั้ง agent ที่ทำงานขนานกันอาจสร้างภาระ CPU จนเครื่องค้าง หรือแม้แต่ตัดสินใจผสานโค้ดข้ามเขตกันเองหากมนุษย์ไม่ได้กำหนดขอบเขตให้ชัดเจนพอ

การตรวจสอบโค้ดในระดับสเกล

ทีมได้พัฒนาทักษะเฉพาะทางให้ AI ช่วยทำ rebase และตรวจสอบโค้ดแบบบรรทัดต่อบรรทัด เพื่อยืนยันว่าโค้ด Rust ใหม่มีพฤติกรรมเหมือน TypeScript เดิม 100% มนุษย์จะทำหน้าที่ตรวจสอบในระดับสถาปัตยกรรมและการตัดสินใจในจุดที่มีความเสี่ยงสูง

การย้ายสองอย่างในหนึ่งเดียว

นอกจากการเปลี่ยนภาษา ยังมีการเปลี่ยนไลบรารีพื้นฐานจำนวนมาก โดยทีมนำ npm packages ออกไปกว่า 60 ตัวและแทนที่ด้วย Rust crates ที่มีประสิทธิภาพสูงกว่า เช่น เปลี่ยน dompurify เป็น ammonia หรือ zod เป็น serde และ schemars เพื่อให้ได้ native binary ที่สมบูรณ์

มี unsafe มากแค่ไหน?

พบการใช้บล็อก unsafe ใน Rust runtime ทั้งหมด 158 จุด ซึ่งทั้งหมดมีความจำเป็นเนื่องจากเป็นการสื่อสารกับขอบเขตภายนอก เช่น Windows API, POSIX หรือ C ABI โดยไม่มีการใช้ unsafe ในตรรกะภายในของ agent หรือ model เลย

ปัญหาการถดถอย (The Regressions)

แม้จะคอมไพล์ผ่าน แต่ก็พบปัญหาการถดถอยหลายสิบรายการ ซึ่งส่วนใหญ่เกิดจากความแตกต่างของพฤติกรรมระหว่างภาษา เช่น การจัดการทศนิยมใน TypeScript ที่ Rust เข้มงวดกว่า หรือพฤติกรรมของสภาพแวดล้อม (environment) ที่ต่างกัน อย่างไรก็ตาม อัตราปัญหาที่รายงานโดยผู้ใช้จริงไม่ได้เพิ่มขึ้นอย่างมีนัยสำคัญเมื่อเทียบกับช่วงก่อนพอร์ต

ประสิทธิภาพที่เพิ่มขึ้น

ผลลัพธ์จากการพอร์ตเป็นที่น่าประทับใจ:

• การเริ่มต้นใช้งาน session เร็วขึ้นถึง 18 เท่า (จาก 5.25 วินาที เหลือ 292 มิลลิวินาที)
• รองรับจำนวน session ต่อวินาทีเพิ่มขึ้นจาก 7.55 เป็น 120 ครั้ง
• การใช้หน่วยความจำลดลงถึง 91% (สำหรับ client 10 ตัว ลดลงจาก 1,383 MB เหลือ 126 MB)

ค่าใช้จ่ายและบทเรียน

โครงการนี้ใช้เงินค่า token ไปประมาณ 120,000 ดอลลาร์สหรัฐ และใช้เวลาของวิศวกรหลักประมาณ 3 สัปดาห์ บทเรียนสำคัญคือการมีระบบทดสอบ End-to-end ที่แข็งแกร่งเป็นสิ่งจำเป็นที่สุด และการพอร์ตควรเริ่มจากการแปลโค้ดให้ตรงตามเดิมก่อนที่จะเริ่มออกแบบสถาปัตยกรรมใหม่

การใช้ AI agent ทำให้โครงการระดับนี้เป็นไปได้จริงในทางปฏิบัติ และช่วยวางรากฐานใหม่ให้ GitHub Copilot สามารถทำงานได้ทุกที่ ตั้งแต่ระบบคลาวด์ไปจนถึงอุปกรณ์ฝังตัวที่มีทรัพยากรจำกัด