Anthropic เลิกใช้ git กับ monorepo หลัก หันมาใช้ Scion ที่สร้างเอง — merge ต่อวันโตจาก 2,500 เป็น 30,000+ ภายใน 4 เดือน ทีม 7 คนสร้างและย้ายเสร็จใน 5 เดือน

Anthropic เผยแพร่บทความ Redesigning source control at Anthropic เมื่อ 13 ต.ค. 2026 เล่าว่าตอนนี้การเขียนโค้ดไม่ใช่คอขวดของบริษัทแล้ว เพราะ Claude เขียนโค้ดได้เร็วกว่าที่โครงสร้างพื้นฐานสำหรับนักพัฒนาจะรับไหว ตัวเลขที่ชัดที่สุดคือ เดือนพฤษภาคม 2026 monorepo ของ Anthropic มี code change ที่ merge เฉลี่ยราว 2,500 ครั้งต่อวัน พอถึงเดือนกันยายนเพิ่มเป็นกว่า 30,000 ครั้งต่อวัน และบริษัทไม่คิดว่าอัตรานี้จะช้าลง

ทางออกของ Anthropic คือสร้าง Scion ระบบ version control ของตัวเอง แล้วย้าย monorepo ออกจาก git ทั้งหมดภายใน 5 เดือน ในช่วงเดียวกันยังสร้างเครื่องมือ code review ชื่อ Antique, code search และระบบสิทธิ์ (IAM) สำหรับ source control ด้วย ทั้งหมดนี้ทำโดย ทีม 7 คน

ทำไม git ไม่พอ

ประวัติของ branch main อย่างเดียวใหญ่เกือบ 100 GB และ working copy แบบบีบอัดใหญ่กว่า 25 GB งาน CI ต้อง checkout โค้ดราว 25 ล้านครั้งต่อวัน ยังไม่นับเครื่องนักพัฒนา sandbox ของเอเจนต์ และงานวิจัย ถ้าดึงข้อมูลแบบตรงๆ จะเป็น traffic ของ git กว่า 600 PB ต่อวัน Anthropic ใช้วิธีแก้มาครบแล้ว ทั้ง shallow clone, sparse checkout และ snapshot ใน blob storage ช่วงพีคต้องดูแล git mirror ภายในหลายร้อยตัว แต่เมื่ออัตรา merge เพิ่มขึ้น วิธีเหล่านี้ก็ดูแลยากขึ้นเรื่อยๆ

ข้อสังเกตสำคัญคือ git ถูกออกแบบให้ทุก clone เป็น repository สมบูรณ์ที่ทำงาน offline ได้ แต่ client เกือบทั้งหมดของ Anthropic เป็นเอเจนต์และ job ที่ออนไลน์อยู่แล้วโดยธรรมชาติ ข้อดีที่ทำให้ git เหมาะกับงานกระจายศูนย์จึงกลายเป็นตัวที่ทำให้ขยายระบบไม่ได้

หลักการออกแบบของ Scion

Scion นำบทเรียนจาก Piper ของ Google และ Sapling ของ Meta มาใช้ โดยมีหลักการหลักดังนี้:

• client ออนไลน์ตลอด client ขอข้อมูลจาก server เมื่อต้องใช้ ไม่ต้องมีสำเนาทั้ง repo
• server ทำงานหนักแทน client ทั้ง blame, history, การสร้าง commit, merge และ rebase เกิดบน server ส่วน client เก็บ cache ขนาดจำกัด และทุก query ที่ client ใช้ก็เปิดเป็น API ด้วย ทำให้ job ส่วนใหญ่ไม่ต้องมี repo ในเครื่องเลย เช่น pipeline bisect และ revert อัตโนมัติ
• หน่วยของงานคือ “changeset” ใน write-ahead log ซึ่งเก็บเฉพาะไฟล์ที่เปลี่ยนเทียบกับ parent แรก ไม่มี packfile ไม่มี lock และแทบไม่ใช้ ref การเลื่อน ref เป็นแค่ compare-and-swap บนแถวเดียวใน Spanner
• ข้อมูลที่ต้องคำนวณเพิ่ม (derived data) เช่น blame และ path history คำนวณแบบ recursive จาก parent จะคำนวณล่วงหน้าหรือคำนวณเมื่อต้องใช้ก็ได้
• checkout ผ่าน cache หลายชั้น (scion-daemon ต่อเครื่อง → scion-cache ระดับ region → scion-server) ทุก object เป็น content-addressed จึง cache ได้ทุกชั้น แต่ละชั้นมี hit rate เกิน 99%

ผลลัพธ์ที่ Anthropic รายงานคือ ใช้ CPU และหน่วยความจำ น้อยกว่าระบบ git mirror เดิม 200 เท่า งาน CI และงานวิจัย checkout เร็วขึ้นราว 2 หลัก (จากหลักนาทีเหลือหลักวินาที) และ CI ได้ CPU คืนมา 25%

บทเรียนเรื่องการทำงานกับเอเจนต์

ส่วนที่นักพัฒนาทั่วไปนำไปใช้ได้มากที่สุดคือบทเรียนท้ายบทความ ตอนแรกทีมเขียน pipeline สำหรับนำเข้าข้อมูลจาก git มา Scion เองด้วยมือ พอได้ใช้ snapshot ภายในของ Claude Mythos Preview ก็ลองให้เขียนใหม่ทั้งหมด ได้เวอร์ชันที่ ใช้หน่วยความจำน้อยลง 20 เท่าและเร็วขึ้น 4 เท่า โดยยังรักษา invariant เดิมไว้ได้ วิศวกรทุกคนในทีมยอมรับว่า Claude เขียนโค้ดเก่งกว่าตัวเอง แต่บทบาทของวิศวกรกลายเป็น “คนที่บอก Claude ว่าไม่” เพราะเอเจนต์บางครั้งละเมิดข้อจำกัดหลักของระบบ เช่น อ่าน commit log ทีละรายการเพื่อหาว่า change ไหน merge เมื่อไร แทนที่จะถาม code review tool การ review แบบ adversarial ก็ทำให้ Claude ใส่ validation เกินจำเป็นได้เหมือนกัน ตอนนี้ทีมยัง review ทุก change แต่ดูที่ เจตนาของการเปลี่ยนแปลง แทนการอ่านโค้ดทุกบรรทัด

อีกไอเดียที่น่าสนใจคือ “superfan” ซึ่งเป็น Claude ประจำ Slack channel ที่คอยเฝ้า component เดียว (เช่น scion-cache) ผ่าน telemetry และ log ตลอดเวลา จับความผิดปกติแบบใหม่ที่ alert ทั่วไปตรวจไม่เจอ ส่วน merge queue แบบล็อกทั้ง repo ใช้ไม่ได้แล้วเมื่อมี change merge เป็นพันระหว่างที่เทสต์ยังรัน Anthropic จึงหันไปลงทุนกับการเทสต์หลัง merge และก่อน deploy แทน

ไม่เปิดซอร์ส และไม่ใช่ตัวแทน git

Anthropic บอกตรงๆ ว่า Scion ไม่เหมาะเป็นตัวแทน git สำหรับงานทั่วไป แนวคิดนี้เหมาะกับ monorepo ขนาดใหญ่มากเท่านั้น และระบบนี้ผูกกับ code review, code search และ CI ภายในจนเปิดให้คนอื่นใช้ได้ยาก แต่บริษัทคาดว่าปัญหาแบบนี้จะพบได้ทั่วไปใน 6–12 เดือน ข้างหน้า จึงเสนอให้ GitHub, GitLab และชุมชน OSS นำแนวคิดบางส่วนไปใส่ใน git เช่น RPC ฝั่ง server ที่เป็นมาตรฐานเดียวกันทุก forge และ negotiation protocol แบบใหม่

มุมมอง AI Curator

ตัวเลข 2,500 → 30,000 merge ต่อวันใน 4 เดือนเป็นสัญญาณสำคัญกว่าตัว Scion มันบอกว่าเมื่อเอเจนต์เขียนโค้ดได้จริง คอขวดจะย้ายไปอยู่ที่ทุกอย่างที่ออกแบบมาสำหรับมนุษย์ ทั้ง source control, CI, merge queue และ code review ทีมไทยส่วนใหญ่ยังห่างจากขนาดนี้มาก ไม่ต้องสร้าง VCS เอง แต่ควรวัดตั้งแต่ตอนนี้ว่าเวลาจาก “เอเจนต์เขียนเสร็จ” ถึง “ขึ้น production” หมดไปกับอะไร เพราะคอขวดแรกที่เจอมักเป็นคิว CI และคนที่ต้อง review

ต้องอ่านบทความนี้อย่างระวังด้วย เพราะเป็นเรื่องเล่าของ Anthropic เอง ที่มีแรงจูงใจทางการค้าชัดเจน ไม่มีตัวเลขอิสระ และ Anthropic เองก็ยอมรับว่าใช้โทเคนภายในได้มากกว่าธุรกิจทั่วไปมาก จำนวน merge ที่เพิ่มขึ้น 12 เท่าไม่ได้แปลว่าซอฟต์แวร์ที่ใช้งานได้จริงเพิ่มขึ้น 12 เท่า บทเรียนที่ใช้ได้ทันทีคือเรื่องบทบาทวิศวกร คือ review ที่เจตนามากกว่าทุกบรรทัด กำหนด invariant ของระบบให้ชัดเพื่อให้รู้ว่าเมื่อไรต้องบอกเอเจนต์ว่าไม่ และให้เอเจนต์ช่วยเฝ้าระบบควบคู่กับ alert แบบเดิม

---

แหล่งข่าว

• Anthropic Engineering — Redesigning source control at Anthropic
• Hacker News — discussion thread