Bun เขียนใหม่ทั้งตัวจาก Zig เป็น Rust ด้วย Claude — 535,496 บรรทัดใน 11 วัน, 64 เอเจนต์ขนาน, ราว $165,000

Bun ทีมพัฒนา JavaScript runtime/toolkit ยอดนิยม ประกาศเมื่อ 8 กรกฎาคม 2026 ว่าได้ เขียนโค้ดฐานทั้งหมดใหม่จากภาษา Zig เป็น Rust โดยงานเขียนใหม่ส่วนใหญ่ทำด้วย Claude Code ที่รันเอเจนต์ขนานกันสูงสุด 64 ตัว เป็นเวลา 11 วัน (3–14 พฤษภาคม 2026) แปลงโค้ด Zig 535,496 บรรทัด ใน 1,448 ไฟล์ เป็น Rust — งาน diff รวมเพิ่มโค้ดราว 1 ล้านบรรทัด ผ่าน 6,502 commit (พีคที่ 695 commit/ชั่วโมง) ต้นทุนรวมราว $165,000 ที่ราคา API

นี่ไม่ใช่ demo เล่น ๆ — Bun v1.3.14 คือเวอร์ชันสุดท้ายที่เขียนด้วย Zig และ v1.4.0 คือเวอร์ชันแรกที่เขียนด้วย Rust (ตอนนี้อยู่ใน canary ให้ทดสอบ) โดย Jarred Sumner ผู้สร้าง Bun ระบุว่าถ้าให้มนุษย์ทำงานเดียวกันจะกินเวลาราว 3 engineer-years งานนี้จึงน่าจะเป็น การย้ายภาษาของโค้ดเบสด้วย AI ครั้งใหญ่ที่สุดที่เปิดเผยต่อสาธารณะ จนถึงตอนนี้

เพื่อความโปร่งใส: บล็อกของ Bun เปิดเผยเองว่า “Bun ถูก Anthropic เข้าซื้อกิจการเมื่อธันวาคม 2025 ผมและทีม Bun ทำงานที่ Anthropic” โมเดลที่ใช้เขียนส่วนใหญ่คือ Claude Fable 5 รุ่น pre-release (คลาส Mythos)

ทำไมต้องย้ายจาก Zig ไป Rust

เหตุผลหลักคือ ความปลอดภัยของหน่วยความจำ (memory safety) ไม่ใช่เรื่องประสิทธิภาพ Bun เป็นซอฟต์แวร์ที่ต้องเชื่อมโลกสองใบเข้าด้วยกัน: ค่า JavaScript ที่จัดการหน่วยความจำแบบ garbage-collected (ผ่าน JavaScriptCore) กับไลบรารี C/C++ ที่จัดการหน่วยความจำเอง จุดตัดระหว่างสองโลกนี้คือแหล่งบั๊กคลาสสิก — use-after-free, double-free และ “ลืม free ใน error path”

ในภาษา Rust บั๊กเหล่านี้กลายเป็น compile error และ RAII/Drop ช่วยคืนหน่วยความจำอัตโนมัติ ขณะที่ Zig อาศัย style guide กับการรีวิวโค้ดเป็นหลัก ซึ่งไม่พอสำหรับความซับซ้อนของ Bun — Sumner ระบุตรง ๆ ว่า ไม่โทษ Zig เพราะการผสม GC กับ manual memory management เป็นความต้องการที่หายากพอจนไม่มีภาษาไหนออกแบบมารองรับโดยตรง (ข้อสังเกต: บล็อกต้นทางไม่ได้อ้างเรื่องนโยบายห้าม AI ของ Zig อย่างที่สื่อบางเจ้าเสริม — เหตุผลที่ระบุคือ memory safety ล้วน ๆ)

กระบวนการ: orchestration กับ “รีวิวแบบปรปักษ์”

จุดที่น่าสนใจที่สุดสำหรับนักพัฒนาไม่ใช่ตัวเลข แต่คือ วิธีคุมเอเจนต์จำนวนมากไม่ให้พังงานตัวเอง ทีมใช้ dynamic workflows ของ Claude Code โดยมีวิศวกรคนเดียวเฝ้าดูเอเจนต์ราว 64 ตัวที่กระจายอยู่บน 4 git worktree × 16 เอเจนต์ต่อ workflow ไปป์ไลน์เป็นขั้น:

1. เตรียมงาน — สร้าง PORTING.md (คู่มือ map แพตเทิร์นจาก Zig ไป Rust) และ LIFETIMES.tsv (ระบุ lifetime ที่ถูกต้องของ struct field ทั่วโค้ดเบส)
2. ทดลองก่อน — ลองแปลงกับ 3 ไฟล์ ด้วย 1 implementer + 2 reviewer แบบปรปักษ์ + 1 fixer ต่อไฟล์
3. แปลงขนาน — แปลงทั้ง 1,448 ไฟล์ .zig เป็น .rs โดยมีการรีวิวปรปักษ์ก่อนทุก commit
4. ไล่แก้ compiler error — แก้ราว 16,000 error แบบ crate-by-crate ด้วย Claude 64 ตัวที่ sharding กัน
5. ไต่ระดับเทสต์ — จาก local ไป CI ครบ 6 แพลตฟอร์ม

หัวใจคือ adversarial review: โค้ดทุกชิ้นถูกรีวิวโดย Claude คนละตัวที่ได้เห็นแค่ diff กับคำสั่งให้ “หาบั๊ก” การแยก context window แบบนี้กัน groupthink — อย่างที่ Sumner สรุปว่า “Claude ตัวที่เขียนโค้ดอยากให้โค้ดผ่าน ส่วน Claude ตัวที่รีวิวอยากหาปัญหาให้เจอ” ระบบนี้จับบั๊กจริงได้ เช่น use-after-free จากการปิด libuv pipe แบบ async, การจัดการ negative timespec ตอนแปลง mtime ของไฟล์ และการ eval อาร์กิวเมนต์ของ unwrap_or เร็วเกินไปใน color parsing

ผลลัพธ์ — และหนี้ที่ต้องยอมรับ

ด้านผลลัพธ์ค่อนข้างแข็งแรง: เทสต์เดิมผ่านครบทุกแพลตฟอร์มก่อน merge โดยไม่มีการ skip หรือลบเทสต์, ไบนารีเล็กลงราว 20% (จาก Rust + linker optimization), เร็วขึ้น 2–5% และ throughput ของ HTTP ดีขึ้น 2.8–4.8% เวอร์ชัน v1.4.0 ยังแก้บั๊กไป 128 ตัว เทียบกับ v1.3.14

แต่บล็อกก็ซื่อสัตย์กับ ต้นทุนที่ตามมา:

• หนี้ unsafe — โค้ด Rust ราว 4% อยู่ใน unsafe block (~13,000 คีย์เวิร์ด unsafe ในราว 27,000 บรรทัด จากทั้งหมด ~780,000 บรรทัด) แม้ 78% เป็น single-line สำหรับเชื่อม C/C++ ก็ตาม Bun ยังต้องใช้ไลบรารี C/C++ อย่าง JavaScriptCore ต่อไป จึงจะมี unsafe มากกว่าโปรเจกต์ Rust บริสุทธิ์เสมอ (มี bun-unsafe-audit เป็นงานต่อเนื่องเพื่อลดจำนวนนี้)
• 19 regression ที่รู้ตัว (แก้หมดแล้ว) — เช่น debug_assert! ของ Rust ที่ลบ expression ทิ้งใน release build ทำให้ hot module reloading พังในบางกรณี, UTF-16 decode ที่ panic กับ byte ความยาวคี่, และ off-by-one ที่ Rust bounds check จับได้
• Windows ตามหลัง — Linux เขียวครบตั้งแต่ 9 พ.ค. แต่ Windows ARM64 เพิ่งผ่าน CI ครบวันสุดท้าย (14 พ.ค.)
• สถานะ — v1.4.0 ยังเป็น canary ทีมขอให้ผู้ใช้ช่วยทดสอบและรายงานปัญหา

มุมมอง AI Curator

เรื่องนี้สำคัญกว่าที่ตัวเลข “$165,000 แลก 3 engineer-years” จะบอก เพราะมันเป็น หลักฐานสาธารณะชิ้นแรกที่มีน้ำหนักจริง ว่า AI ทำงาน software engineering ระดับ “ย้ายทั้งโค้ดเบส” ได้ ไม่ใช่แค่ autocomplete หรือเขียนฟังก์ชันเดี่ยว ๆ และบทเรียนที่ใช้ได้จริงไม่ได้อยู่ที่ “Claude เก่งแค่ไหน” แต่อยู่ที่ สถาปัตยกรรมการคุมเอเจนต์: การแยก implementer กับ reviewer เป็นคนละ context, การเขียน PORTING.md/LIFETIMES.tsv เป็น “รัฐธรรมนูญ” ให้เอเจนต์ยึด, และการมี มนุษย์หนึ่งคนเป็นวาล์วสุดท้าย เฝ้าเอเจนต์ 64 ตัว นี่คือแพตเทิร์นที่ทีมไทยลอกไปใช้ได้ทันทีกับงานใหญ่ ๆ เช่น อัป framework ข้ามเวอร์ชัน, ย้าย ORM, หรือ migrate โค้ดข้ามภาษา — โดยไม่ต้องมีงบระดับ Anthropic

แต่ต้องอ่านให้ครบทั้งสองด้าน: “เทสต์ผ่าน 100%” ไม่เท่ากับ “ปลอดภัย 100%” — 13,000 unsafe block กับ 19 regression ที่หลุดออกมาคือ หนี้ทางเทคนิคที่ AI สร้างด้วยความเร็ว และต้องมีมนุษย์มาตามเก็บ (bun-unsafe-audit) จุดที่ทำให้งานนี้สำเร็จไม่ใช่ “ปล่อยเอเจนต์แล้วเดินจากไป” แต่คือ เทสต์สวีทที่แข็งแรงมากอยู่แล้ว + การรีวิวแบบปรปักษ์ + CI 6 แพลตฟอร์ม ที่คอยจับของเสีย ทีมที่ไม่มีตาข่ายนิรภัยระดับนี้แล้วเลียนแบบ “รัน 64 เอเจนต์ทั้งคืน” มีแนวโน้มจะได้โค้ดที่ compile ผ่านแต่พังเงียบ ๆ ในโปรดักชัน บทเรียนสำหรับองค์กรไทยจึงชัด: ก่อนจะเร่งด้วย AI ให้ลงทุนกับเทสต์และ CI ให้แน่นก่อน เพราะสิ่งที่ทำให้ AI เขียนโค้ดครึ่งล้านบรรทัดได้อย่างวางใจ ไม่ใช่ตัวโมเดล แต่คือระบบที่คอยพิสูจน์ว่ามันไม่ได้ทำพัง

อีกชั้นที่ควรจับตา: Bun เป็นบริษัทในเครือ Anthropic และใช้ Claude รุ่น pre-release — ตัวเลขต้นทุน/ความเร็วจึงเป็น best case ที่มีทั้งโมเดลแรงและทีมที่เข้าใจเครื่องมือลึก องค์กรทั่วไปที่ทำตามควรตั้งความคาดหวังแบบระวัง และวัดผลด้วยเงื่อนไขของตัวเอง ไม่ใช่ลอกตัวเลขมาตั้งเป้า

แหล่งข่าว

• Rewriting Bun in Rust — Bun Blog (8 ก.ค. 2026)
• Simon Willison — Rewriting Bun in Rust
• Bun — repository