พอร์ต TypeScript 100,000 บรรทัดไปเป็น Rust: บันทึกการพอร์ตจริงด้วย Claude Code
(blog.vjeux.com/2026)อดีตวิศวกร Facebook Christopher Chedeau (Vjeux) ทำการทดลองพอร์ตเอนจินการต่อสู้ของ Pokemon Showdown (TypeScript ราว 100,000 บรรทัด) ไปเป็น Rust โดยใช้ Claude Code
เป้าหมายของโปรเจ็กต์
- สร้างออราเคิลความเร็วสูง (ระบบอ้างอิง) สำหรับฝึก AI การต่อสู้ของ Pokemon
- อิมพลีเมนเทชัน TypeScript เดิม → ช้าเกินไป (ไม่สามารถจำลองการต่อสู้ได้หลายล้านครั้ง)
- ภาษาเป้าหมาย: Rust (ประสิทธิภาพสูง) → แต่เจ้าตัวมีประสบการณ์ Rust เป็นศูนย์
ผลลัพธ์สำคัญ
- พอร์ตเสร็จราว 100,000 บรรทัดภายใน 1 เดือน (เวลาทำงานจริงประมาณ 2~4 สัปดาห์)
- สร้างคอมมิตประมาณ 5,000 ครั้ง
- ความเร็วในการทำงานเพิ่มขึ้น 3.5 เท่า
- ผลการทดสอบแบบเปรียบเทียบให้ความสอดคล้อง 99.96% (อิงจากการต่อสู้แบบสุ่ม 2 ล้านครั้ง)
- อีก 0.04% ที่เหลือคาดว่าเป็นบั๊กในโค้ด TS ต้นฉบับ
กลยุทธ์หลักที่ทำให้สำเร็จ
- นำ differential testing มาใช้
- รันต้นฉบับ TS เทียบกับเวอร์ชัน Rust พร้อมกัน → เปรียบเทียบผลลัพธ์
- เคสที่ผลไม่ตรงกัน → แสดงล็อกให้ Claude ดูแล้วสั่งให้แก้ไข
- ทำให้ตรวจสอบได้แม้แทบไม่รู้ไวยากรณ์ Rust
ปัญหาหลักที่ Claude เจอ
- พอร์ตไฟล์เดี่ยวทำได้ดี ↔ แต่มีปัญหาบ่อยในการ รวมข้ามไฟล์
- เช่น นิยามแนวคิดเดียวกัน (
move) เป็นคนละ struct
- เช่น นิยามแนวคิดเดียวกัน (
- ข้อจำกัดของ context window → ระหว่างสรุประหว่างทาง ข้อมูลสำคัญบางส่วนหายไป
- มีแนวโน้มจะทำให้ “ดีขึ้น” → เพิกเฉยต่อคำสั่งแบบชัดเจนว่าให้ “พอร์ตทีละบรรทัด” แล้วพยายามรีแฟกเตอร์ → สร้างบั๊กจำนวนมาก
- คำขอให้ optimize → แผนดูดีมาก แต่แทบไม่ช่วยเรื่องประสิทธิภาพจริง (บางส่วนกลับช้าลง)
การแฮ็กเวิร์กโฟลว์แบบแปลก ๆ
- ทำให้คำขออนุมัติจากผู้ใช้ของ Claude เป็นอัตโนมัติ
- ใช้ AppleScript กด Enter อัตโนมัติทุกไม่กี่วินาที → รันแบบไร้คนเฝ้าได้ 24 ชั่วโมง
- (มีความเสี่ยงด้านความปลอดภัย แต่ยอมรับได้เพราะเป็นออราเคิลแบบใช้ครั้งเดียว)
สถานะปัจจุบันของเครื่องมือเขียนโค้ด AI (การประเมิน)
- งานแปลงเชิงกลและการพอร์ตโค้ดจำนวนมาก → ทรงพลังมาก
- งานระดับสูงอย่างการ optimize ประสิทธิภาพหรือออกแบบสถาปัตยกรรม → ยังไม่ดีพอ
- ข้อถกเถียงใน Hacker News
- ฝ่ายสงสัย: บำรุงรักษาไม่ได้ เป็นโค้ดที่ “แค่คอมไพล์ผ่าน”
- ฝ่ายสนับสนุน: differential testing ทำให้น่าเชื่อถือได้เพียงพอ + ประหยัดเวลาได้มากกว่ามนุษย์อย่างชัดเจน
บทเรียนสำหรับการนำไปใช้จริง 3 ข้อ
- ต้องมี ระบบทดสอบอัตโนมัติ ที่เข้มงวด (ถ้าไม่มี differential testing โอกาสล้มเหลวสูงมาก)
- คำสั่งที่ ชัดเจนและมีขอบเขตแคบ ได้ผลดีที่สุด (“พอร์ตทีละบรรทัด” O vs “ช่วยปรับปรุงให้หน่อย” X)
- AI เป็นเพียง เครื่องมือ → นักพัฒนายังต้องวินิจฉัยปัญหา ออกแบบคำถาม และคุมทิศทางอยู่ดี
→ นี่คือตัวอย่างที่คนซึ่งไม่รู้ Rust เลยสามารถย้ายโค้ดระดับ 100,000 บรรทัดไปสู่ระดับใช้งานได้ภายในหนึ่งเดือน → เป็นทั้งกรณีพิสูจน์ ความใช้งานได้จริงของ AI coding และในขณะเดียวกันก็เป็นการทดลองตัวแทนที่เผยให้เห็น ข้อจำกัดอย่างชัดเจน
1 ความคิดเห็น
นี่มองข้ามไปว่าการเขียน test case ไม่ได้เป็นยาวิเศษสำหรับทุกอย่าง แค่ input กับ output ทำงานปกติไม่ใช่ทั้งหมด สุดท้ายก็ต้องกลับไปรีวิวโค้ดทั้ง 100,000 บรรทัดอีกอยู่ดี