คำตอบแบบสรุป: Anthropic Scion คือระบบควบคุมเวอร์ชัน (version control system) ภายในองค์กรที่ Anthropic พัฒนาขึ้นมา หลังจากที่ coding agent ทำให้ยอดการ merge ใน monorepo พุ่งทะยานจากประมาณ 2,500 ครั้งต่อวันในเดือนพฤษภาคม 2026 ไปเป็นมากกว่า 30,000 ครั้งต่อวันภายในเดือนกันยายน โดย Scion จะรันทั้ง commit, merge และ rebase บนฝั่งเซิร์ฟเวอร์ ระบบนี้ใช้งานเป็นการภายใน และ Anthropic ระบุว่าไม่ได้พัฒนาขึ้นมาเพื่อใช้ทดแทน Git โดยทั่วไป
Anthropic ทำอะไรกับ Scion และทำไมจึงต้องสร้างขึ้นมา
เมื่อวันที่ 13 ตุลาคม 2026 ทีมวิศวกรของ Anthropic ได้เผยแพร่บทความ Redesigning source control at Anthropic โดยเปิดประเด็นไว้อย่างตรงไปตรงมาว่า "การเขียนโค้ดไม่ใช่คอขวดของการพัฒนาระบบหรือการทำวิจัยอีกต่อไป" แต่พวกเขาระบุว่า คอขวดที่แท้จริงคือ "โครงสร้างพื้นฐานสำหรับนักพัฒนาทั้งหมดที่ถูกสร้างขึ้นเพื่อรองรับสเกลการทำงานของมนุษย์ ไม่ว่าจะเป็นระบบควบคุมเวอร์ชัน, ระบบ build และ CI"
ตัวเลขสถิติช่วยอธิบายเหตุผลได้ชัดเจน โดยในเดือนพฤษภาคม 2026 บริษัทมีการ merge โค้ดประมาณ 2,500 ครั้งต่อวัน แต่พอถึงเดือนกันยายน ตัวเลขกลับพุ่งขึ้นสูงกว่า 30,000 ครั้ง นั่นคือการเติบโตขึ้นถึง 12 เท่าภายในเวลาเพียง 4 เดือน ซึ่ง Anthropic ชี้ว่าเป็นผลมาจากการใช้ AI agent ในการเขียนโค้ด
Git สามารถรับมือกับสเกลการทำงานของมนุษย์ได้สบาย แต่เมื่อเจอกับสเกลระดับ agent มันก็เริ่มรับไม่ไหว Anthropic รายงานว่ามียอด CI checkout ราว 25 ล้านครั้งต่อวัน ขนาดประวัติของ main branch พุ่งเฉียด 100 GB และต้องใช้ internal Git mirror ภายในหลายร้อยตัวในช่วงพีก หากใช้วิธีการ fetch แบบทั่วไป ปริมาณทราฟฟิกของ Git อาจทะลุเกิน 600 PB ต่อวัน
ด้วยเหตุนี้ ทีมงานเพียง 7 คนจึงได้ร่วมกันพัฒนา Scion รวมถึงเครื่องมือ code review ที่ชื่อ Antique, ระบบค้นหาโค้ด (code search) และระบบควบคุมสิทธิ์การเข้าถึงระดับไดเรกทอรี โดยพวกเขาสามารถย้าย monorepo ออกจาก Git ได้สำเร็จภายใน 5 เดือน ยิ่งไปกว่านั้น Anthropic ยังให้ Claude Mythos Preview ช่วยเขียน ingestion pipeline สำหรับแปลงข้อมูลจาก Git ไปยัง Scion ขึ้นมาใหม่ ซึ่งโค้ดที่เขียนใหม่นี้ใช้หน่วยความจำน้อยลงถึง 20 เท่า และทำงานได้เร็วกว่าเดิมถึง 4 เท่า
หากทีมของคุณเริ่มนำ Claude Code, Codex หรือ coding agent ตัวอื่นๆ มาใช้งาน บทความนี้เปรียบเสมือนภาพตัวอย่างของคอขวดถัดไปที่คุณต้องเผชิญ Sharkly ถูกสร้างขึ้นมาเพื่อแก้ปัญหานี้โดยเฉพาะ: ระบบช่วยรวมการทำงานของ agent ผลลัพธ์ และการรีวิวโค้ดไว้บน Task ส่วนกลางร่วมกัน แทนที่จะกระจัดกระจายอยู่ตามเทอร์มินัลต่างๆ
Scion แตกต่างจาก Git อย่างไร
Git ออกแบบมาบนสมมติฐานว่าการ clone ทุกครั้งคือการคัดลอกประวัติทั้งหมดมาเก็บไว้ในเครื่องอย่างสมบูรณ์และทำงานแบบออฟไลน์ได้ แต่ Scion กลับมองตรงกันข้าม โดยมองว่า client เชื่อมต่อออนไลน์อยู่ตลอดเวลา และแทบไม่ต้องประมวลผลอะไรเองบนเครื่อง
| Git | Anthropic Scion | |
|---|---|---|
| Where commits, merges and rebases run | ประมวลผลบนเครื่อง (Local) เช่น แล็ปท็อปของคุณ | ประมวลผลบนเซิร์ฟเวอร์ |
| Local data | ประวัติทั้งหมดแบบสมบูรณ์ | Object cache ที่จำกัดขนาดไว้, การ checkout แบบ sparse หรือ virtualized |
| Unit of work | Commit ที่ชี้ไปยังโครงสร้าง Tree | Changeset ใน write-ahead log พร้อมระบุรายการไฟล์ที่มีการเปลี่ยนแปลง |
| Branches and refs | ต้นทุนต่ำและสนับสนุนให้ใช้งาน | ไม่แนะนำให้ใช้ ยกเว้น branch main และ release |
| Fetch | Packfile | ดึงแยกทีละ object (trees ก่อน แล้วตามด้วย blobs) และไม่ต้องคอยทำ repository maintenance |
| Offline work | ทำได้ | ทำไม่ได้ |
| Main clients | มนุษย์ | Agent, ระบบ CI และงานวิจัยประมวลผล |
สถาปัตยกรรมของ Scion แบ่งออกเป็น 3 ระดับ ได้แก่ scion-daemon บนแต่ละโหนด, scion-cache ประจำแต่ละภูมิภาค (Region) และ scion-server ตัวหลักที่เป็นศูนย์กลาง สั่งการผ่านเครื่องมือ CLI ฝั่งไคลเอนต์ชื่อ scn โดยมีอัตรา cache hit สูงกว่า 99% ในทุกระดับ
ผลลัพธ์ที่ได้นั้นคุ้มค่ามหาศาล อัตราการใช้ CPU และหน่วยความจำลดลงถึง 200 เท่าเมื่อเทียบกับระบบ Git mirror เดิม การ checkout สำหรับ CI และงานวิจัยใช้เวลาเพียงไม่กี่วินาทีจากเดิมที่กินเวลาหลายนาที อีกทั้งยังช่วยคืนประสิทธิภาพ CPU ให้กับระบบ CI ได้ถึง 25%
สิ่งที่คุณต้องยอมแลกกับการทำ commit บนฝั่งเซิร์ฟเวอร์
การ commit บนเซิร์ฟเวอร์ทำให้ต้องสละจุดเด่นสำคัญที่สุดที่ทำให้ Git ประสบความสำเร็จ นั่นคือการมีประวัติของโค้ดทั้งหมดบนเครื่อง ซึ่งช่วยให้คุณเปิดคอมทำงานบนเครื่องบินได้ ซึ่ง Anthropic ก็ยอมรับเรื่องนี้อย่างตรงไปตรงมา โดยกล่าวว่า Scion “ไม่ใช่ตัวเลือกที่เหมาะจะนำมาใช้แทน Git สำหรับการใช้งานทั่วไปแต่อย่างใด” และการปรับแต่งเพื่อเปิดให้องค์กรอื่นนำไปใช้นั้นคงเป็นเรื่องยาก ทั้งนี้ระบบยังไม่ได้มีการเปิดให้ใช้งานภายนอก และในบทความก็ไม่ได้ระบุว่าเป็นโอเพนซอร์ส
แนวทางการจัดการ Concurrency ก็ต่างจากที่หลายคนคาดคิด Anthropic ไม่ได้บังคับให้ทุกการ merge ต้องต่อคิวตามลำดับผ่าน Global lock แต่ปล่อยให้การเปลี่ยนแปลงที่เกิดขึ้นพร้อมกันอาจเกิด conflict ได้ แล้วอาศัยการตรวจจับปัญหาผ่านการทดสอบแบบ post-merge (หลังการ merge) และ pre-deploy (ก่อน deploy) แทน
Git สำหรับ AI Agent: บทเรียนสำหรับทีมที่ไม่มี Scion
คุณอาจจะไม่ได้ใช้ Scion และจริงๆ แล้วคุณก็ไม่จำเป็นต้องใช้มัน เพราะ repository ของคุณไม่ได้มีขนาด 100 GB และไม่ได้มีการ checkout ถึง 25 ล้านครั้งต่อวัน แต่สิ่งที่มีประโยชน์อย่างแท้จริงจากบทความนี้คือ "ลักษณะของปัญหา" ที่สามารถเกิดขึ้นได้กับทีมทุกขนาด
เมื่อ AI agent เป็นผู้เขียนโค้ด คอขวดจะขยับเลื่อนลงไปสู่ขั้นตอนถัดไป โดยเริ่มย้ายไปอยู่ที่การ merge ก่อน แล้วจึงตามด้วยการ review โค้ด ซึ่งทั้งรายงานจาก DevOps.com และบทความของ TechSpot ต่างมองตรงกันว่า Scion คือตัวอย่างของการปรับโครงสร้างพื้นฐานให้ทันกับปริมาณงานที่ agent ผลิตออกมา แม้แต่ทีมงานเพียง 5 คนที่รัน agent 10 ตัว ก็ย่อมต้องเจอกับกำแพงปัญหาแบบเดียวกันนี้ในสเกลที่ย่อมลงมา
คุณอาจเริ่มสังเกตเห็นสัญญาณเตือนเหล่านี้แล้ว:
- Agent สองตัวแก้ไขไฟล์เดียวกันในบ่ายวันเดียวกัน จนคุณต้องมานั่งแก้ conflict ด้วยตัวเอง
- Pull request กองพะเนินเร็วกว่าความเร็วที่คนจะอ่านทัน
- คิวของ CI ยาวขึ้นเรื่อยๆ ทุกสัปดาห์ ในขณะที่ agent ยังคงเขียนโค้ดได้เร็วเท่าเดิม
- ไม่มีใครบอกได้ว่า agent ตัวไหนแก้โค้ดตรงไหน หรือแก้ไปเพราะอะไร
- Branch ที่เปิดไว้ตั้งแต่วันอังคาร พอถึงวันศุกร์นำมารีเบสแล้วเละเทะจนแก้ไม่ไหว
Anthropic จัดการกับปัญหาข้อ 1 และข้อ 3 ด้วยการสร้างโครงสร้างพื้นฐานใหม่ขึ้นมา แต่สำหรับคุณ คุณสามารถรับมือกับปัญหาทั้ง 5 ข้อนี้ได้ด้วยการปรับกระบวนการทำงานและใช้เครื่องมือ Git ที่มีอยู่แล้ว
ปัญหา Merge Conflict จาก Coding Agent: ทำไมถึงทวีคูณขึ้นอย่างรวดเร็ว
Merge conflict ไม่ได้เพิ่มขึ้นตามจำนวนคนหรือจำนวน agent แต่แปรผันตาม "ความทับซ้อนของงาน" หาก agent 10 ตัวทำงานในเป้าหมายกว้างๆ เดียวกัน พวกมันจะเข้าไปแตะและแก้ไขไฟล์เดิมๆ ซ้ำซ้อนอยู่ตลอดเวลา ในทางกลับกัน หาก agent 10 ตัวแบ่งกันทำ 10 งานย่อยที่มีขอบเขตชัดเจน โอกาสที่จะชนกันย่อมน้อยมาก ดังนั้นขนาดของแต่ละ Task จึงสำคัญกว่าจำนวนของ agent
การเปิด branch ทิ้งไว้นานๆ ยิ่งทำให้ปัญหาหนักขึ้น เพราะทุกชั่วโมงที่ branch ยังเปิดค้างอยู่ main branch ก็เดินหน้าไปเรื่อยๆ Agent ยิ่งทำให้ช่องว่างนี้เห็นชัดขึ้น เพราะพวกมันเปิด branch ใหม่ได้เร็วกว่าที่มนุษย์จะปิด branch เสียอีก บทความก่อนหน้าของเราเรื่อง ปริมาณวันทำงานของ agent ที่คนหนึ่งคนสามารถรีวิวได้ในหนึ่งวันทำงาน ได้แจกแจงตัวเลขให้เห็นถึงช่องว่างตรงนี้ไว้แล้ว
สิ่งที่คุณทำได้ตั้งแต่วันนี้โดยไม่ต้องพึ่งพา Scion
แนวทางปฏิบัติ 5 ประการนี้ครอบคลุมเกือบทุกสิ่งที่ทีมทั่วไปจำเป็นต้องใช้ โดยไม่จำเป็นต้องเปลี่ยนไปใช้ระบบ version control ตัวใหม่เลยแม้แต่น้อย
แยก Worktree สำหรับแต่ละ Task โดยเฉพาะ
Git worktree คือ working directory เพิ่มเติมที่เชื่อมโยงอยู่กับ repository เดียวกัน การใช้หนึ่ง worktree ต่อหนึ่ง task จะช่วยป้องกันไม่ให้มี agent สองตัวเขียนไฟล์ลงในไดเรกทอรีเดียวกันพร้อมกัน
git worktree add ../tasks/COIN-212 -b agent/COIN-212 origin/main
cd ../tasks/COIN-212
# run the agent here, commit, push, open a PR
git worktree remove ../tasks/COIN-212
เราได้อธิบายขั้นตอนการตั้งค่าไว้ในบทความ Git worktrees สำหรับ AI coding agents และแนะนำวิธีจัดการเคลียร์พื้นที่ใน การจัดการ worktree โดยไม่ยุ่งยากเรื่องการเคลียร์ไฟล์
กำหนด Task ให้มีขนาดเล็กและมีขอบเขตที่ชัดเจน
เขียนรายละเอียดของแต่ละ task ให้ชัดเจน โดยระบุชื่อไฟล์หรือโมดูลที่อนุญาตให้แก้ไข พร้อมทั้งระบุวิธีตรวจสอบที่ยืนยันว่างานเสร็จสิ้น Task ที่มีขนาดพอดีกับ diff ที่เปิดรีวิวได้สะดวกจะ merge ได้อย่างราบรื่น ต่างจาก task ที่เขียนกว้างๆ ว่า "รีแฟกเตอร์ระบบ auth" ซึ่งมักจะเกิดปัญหา
ใช้ Merge Queue กั้นก่อนเข้า main branch
ระบบ merge queue จะทดสอบ pull request แต่ละรายการเทียบกับ branch main เวอร์ชันล่าสุดรวมกับการเปลี่ยนแปลงทั้งหมดที่ต่อคิวก่อนหน้า แล้วจึงค่อยทำการ merge ตามลำดับ ฟีเจอร์ merge queue ของ GitHub สามารถตั้งค่าสำหรับ protected branch ได้ ซึ่งนี่คือโซลูชันสำหรับทีมขนาดเล็กที่ทำงานคล้ายกับที่ Anthropic จัดการด้วยการทดสอบ post-merge ช่วยให้คุณไม่ต้องมานั่งปวดหัวกับโค้ดที่พังหลังจาก merge เข้าไปแล้ว
เชื่อมโยงการรีวิวเข้ากับ Task พร้อมหลักฐานประกอบ
การดูเพียงแค่ diff ไม่สามารถบอกผู้รีวิวได้ว่า agent ได้รับคำสั่งให้ทำอะไร หรือได้ทดสอบอะไรไปแล้วบ้าง การรีวิวจะรวดเร็วขึ้นมากเมื่อคำสั่งการทำงาน (request), ประวัติการรัน, ผลลัพธ์ของการทดสอบ และ diff ถูกรวบรวมไว้ในที่เดียวกัน ดูเพิ่มเติมได้ที่ วิธีรีวิวโค้ดที่สร้างโดย AI ด้วยหลักฐานระดับ Task และ ทำไมการรีวิวโดยมนุษย์ถึงกลายเป็นคอขวด
กำหนดให้ Agent ต้องรอการอนุมัติก่อนเสมอ
ปล่อยให้ agent ค้นคว้าข้อมูล, เขียนโค้ด, ทดสอบ และรายงานผลไป แต่ให้มนุษย์เป็นผู้กำหนดทิศทาง อนุมัติขั้นตอนที่มีความเสี่ยง และตรวจรับผลงาน การให้ agent หยุดรอการอนุมัติจากคนก่อน merge อาจทำให้เสียเวลาเพียงไม่กี่นาที แต่หากปล่อยให้ agent นำโค้ดที่ยังไม่ผ่านการรีวิวไป merge ลง main อาจทำให้คุณต้องเสียเวลาแก้ปัญหาไปทั้งวัน คู่มือของเราเรื่อง Approval gate สำหรับ coding agent จะช่วยแนะนำว่าควรตั้งจุดพักตรวจไว้ที่ขั้นตอนใดบ้าง
Sharkly เข้ามาตอบโจทย์ตรงนี้อย่างไร
Sharkly ไม่ได้มาแทนที่ Git และไม่ได้ช่วยแก้ปัญหา merge conflict โดยตรง Agent ของคุณยังคง commit โค้ดไปยัง repository ผ่าน Git host เดิมที่คุณใช้งานอยู่ แต่สิ่งที่ Sharkly ช่วยจัดการคือขั้นตอนการทำงานที่เกี่ยวข้องกับ commit เหล่านั้น
งานแต่ละชิ้นของ agent จะถูกกำหนดเป็น Task ที่มีผู้รับผิดชอบ (Assignee), สถานะ และบันทึกประวัติการรัน (execution record) โดย agent จะทำงานบน Computer ของคุณเอง ผ่านรันไทม์อย่าง Claude Code, Codex หรืออื่นๆ ที่คุณใช้งานอยู่แล้ว และใน Temporary mode แต่ละ Task จะได้รับไดเรกทอรีที่แยกจากกันอย่างเป็นอิสระ ส่วนงานที่เชื่อมต่อกับ repository ก็สามารถเตรียมแยก worktree ต่างหากได้ เพื่อป้องกันไม่ให้ Task ที่ทำงานพร้อมกันเขียนไฟล์ลงโฟลเดอร์เดียวกัน
เมื่อ agent ทำงานเสร็จสิ้น ก็สามารถตั้งสถานะ Task ให้รอการรีวิวจากมนุษย์ได้ การแจ้งเตือนจะถูกส่งไปยัง Inbox เพื่อให้ผู้รับผิดชอบเปิดดู Task ตรวจสอบผลลัพธ์พร้อมบริบททั้งหมด และตัดสินใจว่าจะอนุมัติ (accept), สั่งรันใหม่ (retry) หรือมอบหมายงานใหม่ (reassign) โดยประวัติการทำงานของ Task และบทสนทนาที่ติดตามผลจะแสดงอยู่บนไทม์ไลน์ของ Task ทำให้บอร์ดการทำงานกลายเป็นคิวสำหรับการรีวิวโค้ดของคุณไปในตัว
นี่คือการผสานแนวทางปฏิบัติบนฝั่ง Git เข้ากับพื้นที่ส่วนกลางที่รวบรวมทั้งคำสั่งการทำงาน, การประมวลผล, หลักฐาน และการตัดสินใจไว้ในจุดเดียว หากคุณกำลังเปรียบเทียบทางเลือกต่างๆ บทความ รวมเครื่องมือสำหรับจัดการ AI coding agent ที่ทำงานพร้อมกัน ได้รวบรวมข้อมูลในตลาดไว้อย่างครอบคลุม
ใครที่ควรเริ่มลงมือปรับใช้เรื่องนี้ทันที
ทีมที่มีการใช้งาน agent ตั้งแต่ 3 ตัวขึ้นไปในแต่ละวัน คุณกำลังเข้าใกล้ปัญหาคอขวดของการ merge แล้ว ควรเริ่มนำ worktree และ merge queue มาปรับใช้ตั้งแต่สัปดาห์นี้
นักพัฒนาที่ทำงานคนเดียวและรัน agent หลายตัวพร้อมกัน คอขวดของคุณอยู่ที่การรีวิวโค้ด ไม่ใช่การ merge ให้ย่อยขนาดของ task ลงมาจน diff แต่ละครั้งใช้เวลาอ่านไม่เกิน 10 นาที
หัวหน้าทีม Platform และ Infrastructure ให้คอยจับตาดูระยะเวลารอคิวของ CI และอายุของ PR บทความของ Anthropic ระบุชัดเจนว่าระบบ source control และ CI คือสิ่งแรกๆ ที่พังก่อนส่วนอื่น และระบบของคุณก็น่าจะเจอปัญหาในลำดับเดียวกันนี้ การตั้งค่า รัน agent แบบขนานด้วย worktree ที่แยกจากกัน จะช่วยยืดเวลาให้คุณเตรียมรับมือได้
บทสรุป
Anthropic Scion เป็นสัญญาณเตือนมากกว่าที่จะเป็นผลิตภัณฑ์ที่คุณจะนำมาใช้งานได้ ปริมาณการ merge ของ Anthropic เติบโตขึ้นถึง 12 เท่าภายใน 4 เดือน จนการออกแบบที่เน้นทำงานออฟไลน์ของ Git ไม่ตอบโจทย์อีกต่อไป ทำให้ทีมงาน 7 คนต้องสร้างระบบควบคุมเวอร์ชันขึ้นมาใหม่เพื่อรองรับผู้ใช้งานที่เป็น agent เป็นหลัก ซึ่งทีมส่วนใหญ่คงไม่มีความจำเป็นต้องทำถึงขนาดนั้น
อย่างไรก็ตาม ทุกทีมที่เริ่มใช้งาน coding agent จะต้องเผชิญกับการเปลี่ยนแปลงในทิศทางเดียวกัน นั่นคือการเขียนโค้ดมีต้นทุนที่ถูกลงเรื่อยๆ แต่การ merge และการรีวิวโค้ดกลับมีต้นทุนที่สูงขึ้น ดังนั้นจึงควรแยกแต่ละ task ออกจากกัน, ควบคุมให้ task มีขนาดเล็ก, จัดคิวการ merge ให้เป็นระเบียบ และรีวิวโค้ดโดยพิจารณาจากหลักฐานประกอบ
หากต้องการรวมกระบวนการรีวิวทั้งหมดไว้ในที่เดียว ลองเชื่อมต่อ Computer เข้ากับ Sharkly สร้าง Agent สักหนึ่งตัว แล้วลองมอบหมาย Task ขนาดเล็กที่มีความเสี่ยงต่ำดู เพื่อสังเกตดูว่าผลลัพธ์ที่ได้เป็นอย่างไร แล้วจึงค่อยตัดสินใจต่อจากจุดนั้น
คำถามที่พบบ่อย (FAQ)
Anthropic Scion คืออะไร?
Scion คือระบบควบคุมเวอร์ชันที่ Anthropic พัฒนาขึ้นมาใช้งานภายในองค์กร โดยนำมาใช้แทนที่ Git สำหรับ monorepo ของบริษัทในปี 2026 ระบบจะประมวลผล commit, merge และ rebase บนฝั่งเซิร์ฟเวอร์ทั้งหมด ส่วนเครื่องลูกข่าย (client) จะเก็บไว้เพียง bounded cache ภายในเครื่องเท่านั้น
ทำไม Anthropic ถึงต้องเปลี่ยนจากการใช้ Git?
เนื่องจาก coding agent ทำให้ยอดการ merge ต่อวันเพิ่มขึ้นจากประมาณ 2,500 ครั้งในเดือนพฤษภาคม 2026 ไปเป็นมากกว่า 30,000 ครั้งภายในเดือนกันยายน ทั้งระบบ Git mirror, การ checkout และระบบ CI ไม่สามารถรองรับปริมาณการทำงานระดับนั้นได้ทัน ส่งผลให้ระบบ source control กลายเป็นคอขวดหลักขององค์กร
Scion เป็นโอเพนซอร์สหรือเปิดให้คนทั่วไปใช้งานหรือไม่?
ยังไม่มีการเปิดให้บุคคลทั่วไปใช้งาน Anthropic ระบุว่า Scion ไม่ได้เหมาะสำหรับเป็นตัวแทน Git ในการใช้งานทั่วไป และคงเป็นเรื่องยากที่จะนำไปเปิดให้องค์กรอื่นใช้งาน โดยจุดประสงค์ของการแชร์แนวทางการออกแบบนี้ เพื่อให้ผู้อื่นสามารถนำแนวคิดไปปรับประยุกต์ใช้กับ Git ได้
จะลดปัญหา merge conflict ระหว่าง coding agent ได้อย่างไร?
แยก worktree สำหรับแต่ละ task ให้ชัดเจน, กำหนดขอบเขตของแต่ละ task ให้มีขนาดพอดีกับ diff ที่สามารถรีวิวได้ง่าย, ทำการ merge บ่อยๆ และตั้งค่า merge queue ไว้ก่อนเข้า branch main เนื่องจาก conflict เกิดจากความทับซ้อนของการแก้ไขไฟล์ การจำกัดขอบเขตของงานจึงมีความสำคัญมากกว่าจำนวนของ agent
ทีมขนาดเล็กจำเป็นต้องใช้ระบบควบคุมเวอร์ชันตัวใหม่หรือไม่?
แทบไม่มีความจำเป็นเลย ปัญหาของ Anthropic เกิดจากประวัติโค้ดที่มีขนาดเกือบ 100 GB และการ checkout ถึง 25 ล้านครั้งต่อวัน แต่ในระดับการทำงานทั่วไป การใช้ worktree, merge queue และการรีวิวโค้ดในระดับ task ก็เพียงพอต่อการรองรับโหลดงานได้อย่างสบาย
