วันที่ 17 สิงหาคม GitHub เผชิญกับปัญหาบริการอย่างกว้างขวาง ในวันเดียวกัน Cursor เปิดให้ผู้ใช้ที่จ่ายเงินเข้าถึง Origin early beta คลังรหัสกำลังเชื่อมต่อกับ Agent ที่ทำงานต่อเนื่อง โครงสร้างพื้นฐานร่วมมือปัจจุบันออกแบบมาเพื่อรองรับจังหวะการทำงานของมนุษย์ การวิจัยแสดงว่า 40.2% ของคลังรหัสมี Agent PR ซ้ำซ้อน และอัตราการเกิด merge conflict สูงถึง 41.7% Cursor Origin ถูกออกแบบมาสำหรับการเขียนของ Agent ที่มีความถี่สูง รองรับการ commit ได้ถึง 22.6 ครั้งต่อวินาทีต่อคลังรหัสเดียว รวมคลังรหัส PR checks และการทบทวน Origin ถูกกำหนดให้เป็นชั้นการควบคุมเหนือ Git ที่ออกแบบกระบวนการร่วมมือของ Agent ที่มีความถี่สูงใหม่ทั้งหมด xAI, X, SpaceX และ Cursor ภายใต้การดูแลของ Musk ได้สร้างห่วงโซ่การผลิต AI ที่สมบูรณ์ Colossus ให้พลังการประมวลผล Grok ให้โมเดล Cursor ดำเนินการเขียนโค้ด และ Origin จัดการสถานะวิศวกรรม GitHub กำลังขยายจากความร่วมมือของมนุษย์ไปสู่ Agent ในขณะที่ Cursor ออกแบบ forge ใหม่ตามภาระงานของ Agent ทั้งสองแนวทางนี้กำลังแข่งขันกันอย่างรุนแรง

ผู้เขียนบทความ แหล่งที่มา: LeFeng.com

เจ้าของรหัสแหล่งที่มา กำลังเปลี่ยนจากมนุษย์เป็นเอเจนต์

วันที่ 17 สิงหาคม GitHub เผชิญกับปัญหาบริการในวงกว้าง สายการเชื่อมต่อหลัก เช่น เว็บ API Actions Pull Requests การดำเนินการ Git และ Webhooks ต่างได้รับผลกระทบเป็นลำดับ โดยอัตราความผิดพลาดของคำขอเว็บและ API ในบางช่วงเวลาใกล้เคียงกับ 20%

ในวันเดียวกันนั้น Cursor เริ่มเปิดให้ผู้ใช้ในแผนชำระเงินทั้งหมดเข้าถึง Origin early beta ทีละขั้นตอน ฟีเจอร์ repository, PR, checks, review, merge และ Automations ถูกรวมเข้าไว้ในระบบเดียวกัน และ Cursor ได้กำหนดตำแหน่งอย่างชัดเจนว่า การจัดเก็บโค้ดจะเริ่มถูกออกแบบมาเพื่อ “agent scale”

น่าสนใจที่ทั้งสองเรื่องนี้เกิดขึ้นในเวลาเดียวกัน ทำให้การเปลี่ยนแปลงนี้เด่นชัดยิ่งขึ้น: คลังรหัสกำลังเชื่อมต่อกับเอเจนต์ที่ทำงานต่อเนื่อง越来越多 ขณะที่โครงสร้างพื้นฐานสำหรับการร่วมมือกันของซอฟต์แวร์เดิมได้ปรับตัวให้เข้ากับจังหวะการทำงานของมนุษย์มานาน

คนเขียนโค้ดหลายชั่วโมงอาจสร้าง commit ได้เพียงไม่กี่ครั้ง; ตัวแทนสามารถแก้ไข ผลักดัน และกระตุ้นการตรวจสอบอย่างต่อเนื่องภายในไม่กี่นาที แล้วดำเนินรอบถัดไปตามผลลัพธ์ที่ได้ การส่งคำสั่งที่เร็วขึ้นเป็นเพียงผิวเผิน การเปลี่ยนแปลงที่ลึกซึ้งกว่านั้นคือช่วงเวลาของระบบการผลิตซอฟต์แวร์ทั้งหมดกำลังถูกบีบอัด

ปัญหาใหม่หลายประการที่ GitHub ต้องเผชิญ และปัญหาหลายอย่างที่ Origin ต้องการแก้ไข อาจเริ่มต้นจากที่นี่

01 GitHub ไม่ได้แก่ขึ้นอย่างฉับพลัน

เมื่อ GitHub เกิดขึ้น หน่วยพื้นฐานที่มั่นคงสำหรับการร่วมมือด้านซอฟต์แวร์คือมนุษย์

วิศวกรเขียนโค้ดหลายชั่วโมงแล้วจึงส่ง commit หนึ่งครั้ง; ฟีเจอร์หนึ่งใช้เวลาพัฒนาหลายวันจึงสร้าง PR; การทบทวนอาจเกิดขึ้นหลังจากครึ่งชั่วโมงหรือวันถัดไป; CI ใช้เวลาไม่กี่นาทีถือว่ายอมรับได้ การจัดการ merge conflict ที่ล่าช้าเล็กน้อยก็ไม่ทำให้ระบบทั้งหมดสูญเสียความหมาย

ตามจังหวะนี้ GitHub ได้สร้างระบบ Pull Request, Issue, Review, Actions, Webhook และสิทธิ์การเข้าถึง แม้แต่ในโครงการที่มีการส่งคำขอสูงอย่างต่อเนื่องเช่น Linux Kernel จังหวะนี้ก็ยังคงสะท้อนถึงมิติของเวลาของมนุษย์อย่างชัดเจน

LWN รายงานว่า ตลอดวงจรการพัฒนา Linux 7.0 มี commit ที่ไม่ใช่การรวมกันทั้งหมด 14,251 รายการ จากนักพัฒนา 2,362 คน การส่งข้อมูลเหล่านี้เกิดขึ้นภายในวงจรการพัฒนาที่ยืดเยื้อเป็นหลายสัปดาห์ พร้อมด้วยการอภิปรายผ่านอีเมล การตรวจสอบจากผู้ดูแลระบบ การรวมระบบย่อย และวงจรการปล่อย

Cursor แสดงรูปแบบภาระงานอีกแบบหนึ่งในการนำเสนอ Origin เมื่อเดือนมิถุนายน: 22.6 commit/s ต่อรีโพสิทอรีเดียว

ตัวเลขนี้เป็นข้อมูลการสาธิตแบบเรียลไทม์ ไม่ใช่ benchmark การผลิตที่ผ่านการตรวจสอบซ้ำอย่างอิสระ จึงไม่สามารถพิสูจน์ได้ว่า Origin สามารถรักษาปริมาณการดำเนินการในระดับเดียวกันได้อย่างต่อเนื่องในสภาพแวดล้อมจริง แต่มันเพียงพอที่จะแสดงให้เห็นว่า Origin เหมาะกับ workload แบบใด: ตัวแทนจำนวนมากที่ดำเนินการเขียนข้อมูลอย่างต่อเนื่องไปยังสถานะโค้ดเดียวกัน

นักพัฒนามนุษย์มีข้อจำกัดในการไหลเวียนโดยธรรมชาติ การคิด เขียนโค้ด ประชุม และพักผ่อนจะสร้างช่วงเวลาว่างจำนวนมากระหว่างการส่งงาน ดังนั้น forge ที่ออกแบบรอบมนุษย์สามารถถ่ายโอนภาระระบบจำนวนมากให้เวลาดูดซับ

ตัวแทนไม่มีข้อจำกัดนี้

ตัวแทนหลายสิบตัวสามารถแยกจาก base SHA เดียวกันได้พร้อมกัน แก้ไขไฟล์ที่เกี่ยวข้องในช่วงเวลาใกล้เคียงกัน แล้วผลักดันร่วมกัน เปิด PR เรียกใช้การตรวจสอบ อ่านรีวิว แก้ไขโค้ด และผลักดันอีกครั้ง การ commit หนึ่งครั้งยังอาจกระตุ้นการอัปเดตดัชนี การตรวจสอบสิทธิ์ Webhook CI การสแกนโค้ด การอัปเดตสถานะรีวิว และการคำนวณความสามารถในการรวม

ดังนั้น สิ่งที่ต้องรับภาระจากการเปลี่ยนแปลงไม่ใช่โมเดลวัตถุ Git โดยตรง แต่เป็น forge control plane ที่อยู่บน Git มากกว่า: API, การรับรองตัวตน, งานพื้นหลัง, การจัดตาราง CI, Webhook, การป้องกันสาขา, สถานะการทบทวน, คิวการรวม และภาระแบบลูกโซ่ที่เกิดขึ้นระหว่างส่วนประกอบเหล่านี้

การวิจัยเกี่ยวกับ Agent PR บน GitHub ที่เผยแพร่ในเดือนกรกฎาคมได้สังเกตรูปแบบการประชุมกันนี้แล้ว การวิเคราะห์ได้ศึกษา Agent PR 33,596 รายการจาก 2,807 รีโพสิทอรี โดย 40.2% ของรีโพสิทอรีมี Agent PR ที่ทับซ้อนกันในเวลา

ในการแก้ไขแบบพร้อมกันที่ถูกสุ่มเล่นซ้ำ อัตราความขัดแย้งของการรวมข้อความข้าม Agent PR อยู่ที่ 41.7% ในขณะที่ PR ที่เกิดจาก Agent เดียวกันอยู่ที่ 19.8%

การร่วมมือระหว่างตัวแทนหลายตัวจึงจะก่อให้เกิดปัญหาการควบคุมแบบพร้อมกันใหม่ๆ ข้อผิดพลาดครั้งนี้ของ GitHub ไม่ได้พิสูจน์ว่าการจราจรของตัวแทนได้ทะลุผ่านโครงสร้างพื้นฐานปัจจุบัน แต่มันกลับให้หน้าต่างการสังเกตที่เหมาะสม: เมื่อการผลิตซอฟต์แวร์เปลี่ยนจากเหตุการณ์ของมนุษย์ที่เกิดขึ้นน้อยครั้ง เป็นเหตุการณ์ของเครื่องจักรที่เกิดขึ้นบ่อยครั้ง แผนการจัดสรรกำลังการผลิต การออกแบบคิว การแพร่กระจายสถานะ และแบบจำลองความสอดคล้องต้องเผชิญกับ workload ประเภทใหม่

การออกแบบของ Origin ก็เริ่มต้นจากที่นี่

02 Origin ค่าใช้จ่ายในการร่วมมือในการเขียนใหม่

หาก Origin เพียงแค่เพิ่มจุดเข้าถึงสำหรับการโฮสต์ที่เก็บ Git มันจะยากที่จะสั่นคลอนความสัมพันธ์ของนักพัฒนา ระบบนิเวศโอเพ่นซอร์ส ระบบสิทธิ์ขององค์กร และโซลูชันเครื่องมือที่ GitHub ได้สร้างขึ้นแล้ว

โอกาสของมันมาจากการที่ตัวแทนเปลี่ยนต้นทุนการร่วมมือ stacked PR เป็นตัวอย่างที่ชัดเจน

นักพัฒนาคนมักมีแนวโน้มที่จะจัดระเบียบฟีเจอร์หนึ่งให้เป็น PR ที่สมบูรณ์相对 ทุกครั้งที่แยกเป็น PR หนึ่ง จะเพิ่มบริบทหนึ่งชุด รอบการทบทวนหนึ่งรอบ และความพึ่งพา branch หนึ่งชุด หากการเปลี่ยนแปลงหนึ่งครั้งถูกแยกออกเป็น dozens ของ PR คนมักใช้พลังงานจำนวนมากไปกับการดูแลรักษาความสัมพันธ์เหล่านี้

โครงสร้างต้นทุนของเอเจนต์แตกต่างกัน เมื่อมีการแก้ไขข้ามไฟล์หลายสิบไฟล์ การล้มเหลวในขั้นตอนใดๆ ก็อาจทำให้เอเจนต์ต้องเข้าใจบริบทในวงกว้างอีกครั้ง การแบ่งเป็นชุดการเปลี่ยนแปลงที่เล็กลง จะทำให้การแก้ไข schema, service, UI ฯลฯ สามารถสร้างความพึ่งพาที่ชัดเจน และแต่ละจุดสามารถตรวจสอบได้แยกกัน เมื่อเกิดความล้มเหลว จะจัดการเฉพาะส่วนที่เกี่ยวข้องเท่านั้น

PR ขนาดเล็กจึงสามารถเป็น checkpoint ของ Agent เพื่อให้ภารกิจมีความสามารถในการตรวจสอบแบบส่วนย่อย ลองใหม่แบบส่วนย่อย และติดตามการพึ่งพา

การที่ Cursor ซื้อ Graphite ก็สามารถเข้าใจในบริบทนี้ได้เช่นกัน ปัจจุบัน Origin ในระยะ early beta ยังไม่ได้รับรองกระบวนการ stacked workflow ของ Graphite อย่างสมบูรณ์ แต่ฟีเจอร์ stacked PR และ stack-aware merge queue ที่ Graphite ลงทุนพัฒนามานานนั้น ตรงกับข้อจำกัดที่ตามมาหลังจาก Agent เพิ่มความเร็วในการสร้างโค้ด

เมื่อจำนวน PR เพิ่มขึ้น หน้าที่ของคิวการรวมจะหนักขึ้นด้วย ตัวแทน A และตัวแทน B สามารถทำงานพร้อมกันจาก SHA พื้นฐานเดียวกัน และแต่ละฝ่ายผ่านการทดสอบของตนเอง

หลังจาก A เข้าสู่ main แล้ว ผลการทดสอบของ B สามารถพิสูจน์ได้เฉพาะว่าโค้ดทำงานได้ในสถานะเก่า แต่ไม่สามารถพิสูจน์ได้ว่าปลอดภัยหลังจากเข้าสู่ main ใหม่ ดังนั้น queue จึงต้องสร้างสถานะที่เป็นไปได้ใหม่ตาม main ที่เปลี่ยนแปลงอยู่ตลอดเวลา รัน checks ใหม่ และจัดการกับการพึ่งพาซึ่งกันและกันระหว่าง PR

ความขัดแย้งสามารถค่อยๆ เปลี่ยนจากภาวะหยุดชะงักด้วยมือให้กลายเป็นสถานะล้มเหลวที่สามารถกู้คืนได้ในสายการผลิต Cursor ได้ให้ความสามารถประเภท /babysit ซึ่งจัดการอย่างต่อเนื่องกับข้อเสนอแนะจาก PR การตรวจสอบที่ล้มเหลว และความขัดแย้ง เมื่อการรวมที่เสนอไว้มีปัญหา บริบทที่เกี่ยวข้องสามารถส่งกลับไปให้ตัวแทนเพื่อแก้ไขและตรวจสอบอีกครั้งในสภาพแวดล้อมที่แยกจากกัน

การทบทวนจะได้รับการจัดโครงสร้างตามไปด้วย มนุษย์ทำงานร่วมกันอย่างมากโดยอิงจากภาษาธรรมชาติและประสบการณ์ทีม ในขณะที่ตัวแทนที่ทำงานเป็นเวลานานจำเป็นต้องอ่านอย่างชัดเจนว่า check ใดล้มเหลว หัวข้อใดยังไม่ได้รับการแก้ไข นโยบายใดยังไม่ได้รับการปฏิบัติตาม และ SHA ปัจจุบันคืออะไร

Origin ได้เปิดเผยออบเจ็กต์เช่น repository, commit, checks, PR ผ่าน API และแยกแยะการทบทวนอย่างเป็นทางการกับการอภิปรายทั่วไป

สถานะที่มีโครงสร้างเหล่านี้สามารถถูกใช้งานโดย Automations ได้ทันที การกระตุ้น push, PR opened หรือ PR pushed จะเรียกใช้ cloud agent ผลลัพธ์จะถูกเขียนกลับไปยัง checks และ PR หากล้มเหลวจะเข้าสู่กระบวนการจัดการ MCP, hooks และ Agent API ช่วยให้เครื่องมือภายนอกสามารถเข้าร่วมในสายเหตุการณ์เดียวกันได้

“แยกจาก GitHub” แก้ไขเส้นทางการย้าย การดำเนินการสามารถเริ่มต้นโดยการ mirror รีโพสิทอรี GitHub โดยให้ GitHub ยังคงเป็นแหล่งข้อมูลหลัก พร้อมทั้งย้ายงาน流ของ Agent ไปยัง Origin; เมื่อระบบทำงานอย่างมั่นคงแล้วจึงตัดการซิงค์ออก และให้ Origin จัดการรีโพสิทอรีอย่างอิสระ

สิ่งนี้ทำให้ Cursor สามารถรับหน้าที่ของ Agent, PR, review, checks และ Automation ก่อน แล้วค่อยค่อยเก็บสถานะการวิศวกรรมเพิ่มเติมไว้ในระบบของตัวเอง

เหตุผลเชิงผลิตภัณฑ์ของ Origin จึงชัดเจน: Git ยังคงรับผิดชอบการควบคุมเวอร์ชัน ในขณะที่ Origin ต้องการสร้างใหม่คือชั้นการควบคุมที่หมุนรอบการร่วมมือของ Agent ความถี่สูงเหนือ Git

03 ลาโอมาจัดการสายการผลิต AI หนึ่งสาย

ในช่วงกว่าหนึ่งปีที่ผ่านมา ลำดับการดำเนินการระหว่าง xAI, X, SpaceX และ Cursor ได้ก่อร่างสร้างความสัมพันธ์แบบห่วงโซ่อุปทานที่สมบูรณ์ยิ่งขึ้น

xAI ซื้อ X แล้วเข้าสู่ระบบ SpaceX; Cursor ได้รับทรัพยากรการคำนวณ Colossus แล้วก็เข้าสู่ระบบ SpaceX เช่นกัน ในขณะเดียวกัน Grok 4.6 ถูกเปิดตัว และ Origin เริ่มเปิดให้ใช้งาน

เส้นทางนี้คล้ายกับแนวคิดการผสานรวมตามแนวตั้งที่มัสก์เคยใช้ใน Tesla: เมื่อส่วนภายนอกเริ่มเพิ่มความเสียดทานในการพัฒนาแบบวนซ้ำ ให้ขยายไปยังห่วงโซ่การผลิตทั้ง上游และ下游 และรวมอินเทอร์เฟซที่สำคัญเข้าไว้ในระบบเดียวกัน

ตัวแทนกำลังเผชิญกับปัญหานี้อยู่ในขณะนี้ โมเดลสามารถดำเนินการให้เหตุผลได้ แต่ภารกิจซอฟต์แวร์หนึ่งๆ ยังต้องเข้าถึงรีโพสิทอรี แก้ไขไฟล์ รันการทดสอบ จัดการ CI รับการทบทวน แก้ไขความขัดแย้ง และฟื้นฟูการดำเนินการเมื่อล้มเหลว

หากขั้นตอนเหล่านี้กระจายอยู่ในระบบหลายชุด การซิงค์สิทธิ์ บริบท และสถานะในแต่ละรอบงานจะต้องทำซ้ำๆ ค่าใช้จ่ายของอินเทอร์เฟซจะสะสมอย่างต่อเนื่องในวงจร Agent ที่ทำงานอย่างต่อเนื่อง

Colossus, Grok, Cursor และ Origin สามารถสอดคล้องกับระดับต่างๆ บนบล็อกเชนนี้ได้: Colossus ให้พลังการประมวลผล, Grok ให้ความสามารถของโมเดล, Cursor ให้ Agent สำหรับโค้ดและสภาพแวดล้อมการดำเนินการ, Origin จัดเก็บสถานะ repository, PR, checks และ review

การผลิตโค้ดสร้างเส้นทางที่ต่อเนื่องกัน: แบบจำลองทำการตัดสินใจ Cursor แปลงการตัดสินใจเหล่านั้นเป็นการแก้ไขจริง Origin บันทึกสถานะโครงการและรับผิดชอบการควบคุมความร่วมมือในขั้นตอนถัดไป

สิ่งนี้ยังเปลี่ยนเกณฑ์การประเมิน Grok 4.6 ด้วย ความสามารถของโมเดลยังคงสำคัญ แต่ผลลัพธ์ของระบบ Agent ยังขึ้นอยู่กับสภาพแวดล้อมในการดำเนินการและโครงสร้างพื้นฐานด้านวิศวกรรม แม้รหัสจะมีคุณภาพการสร้างที่ดี หากยังต้องมีการคัดลอก ดำเนินการ ตรวจสอบ และส่งกลับด้วยมือในขั้นตอนถัดไป ความสามารถของโมเดลก็ยากที่จะขยายตัวอย่างต่อเนื่อง

เมื่อโมเดล已达ระดับที่สามารถใช้งานได้ ความเร็วในการนำโค้ดเข้าสู่กระบวนการดำเนินการ ตรวจสอบ และผสานรวมจะยิ่งมีผลต่อผลลัพธ์ของระบบโดยรวม

ตำแหน่งของ X บนโซ่ใบนี้ยังคงไม่ชัดเจนนัก มันมีเนื้อหาแบบเรียลไทม์ ความสัมพันธ์ของผู้ใช้ ตัวตน และเครือข่ายการกระจาย อนาคตอาจกลายเป็นแหล่งที่มาของงานและช่องทางการกระจาย; ในขั้นตอนปัจจุบัน Grok Bot มีรูปแบบผลิตภัณฑ์ที่ใกล้เคียงกับชั้นการดำเนินงานงานอย่างต่อเนื่อง มากกว่าที่ผู้คนจินตนาการว่ามันเป็นเพียง “โรบอตแชทที่รอคำถามอย่างเฉยๆ”

เหตุผลที่ Cursor ต้องการ Origin ก็คือ: หลังจากสร้างโค้ดแล้ว จำเป็นต้องมีระบบเก็บสถานะโครงการไว้อย่างถาวร ประสานงานการแก้ไข ตรวจสอบผลลัพธ์ และเชื่อมต่อกับการดำเนินการถัดไป หากตำแหน่งนี้ยังคงอยู่ภายนอก จะทำให้เกิดการพึ่งพาที่สำคัญในห่วงโซ่การผลิตซอฟต์แวร์ของ Agent

而 Origin 正好填补了这一层。

04 ความแตกต่างระหว่าง GitHub และ Origin

GitHub มี stacked PR, merge queue, REST API อยู่แล้ว และกำลังดำเนินการผสาน Copilot coding agent เข้ากับ Issue, Actions, PR และ code review อย่างต่อเนื่อง หากพิจารณาจากรายการฟีเจอร์เพียงอย่างเดียว ทั้งสองฝ่ายจะมีความซ้ำซ้อนกันเพิ่มขึ้นในอนาคต

ความแตกต่างส่วนใหญ่มาจากการสมมติฐานในการออกแบบ

GitHub สร้างขึ้นบนเครือข่ายนักพัฒนาที่มีความเป็นผู้ใหญ่ ดังนั้นทางที่เป็นธรรมชาติมากกว่าคือให้ Agent เข้าสู่ระบบที่มีอยู่แล้วของ Issue, PR, Actions และ branch protection

Cursor สามารถออกแบบส่วนประกอบเหล่านี้ใหม่จากความร่วมมือของเอเจนต์ความหนาแน่นสูง หากมีเอเจนต์หลายสิบตัวทำงานอย่างต่อเนื่องในรีโพสิทอรีหนึ่ง จำนวน PR เพิ่มขึ้น ขนาดการเปลี่ยนแปลงเล็กลง และการเปลี่ยนแปลงสถานะเร็วขึ้น การทบทวน การตรวจสอบ การรวม และระบบสิทธิ์จำเป็นต้องจัดระเบียบใหม่รอบพฤติกรรมของเครื่องจักร

บทบาทของ PR อาจขยายตัวตามไปด้วย มันสามารถเปลี่ยนจากโค้ดที่แก้ไขเพื่อให้ผู้คนอ่านได้ ไปเป็นหน่วยงานวิศวกรรมที่รวมถึง diff ความสัมพันธ์ที่ขึ้นต่อกัน หลักฐานการทดสอบ แหล่งที่มา ระดับความเสี่ยง และสถานะการอนุมัติ

หน้าที่ของมนุษย์จะเข้ามาอยู่ในระดับกฎมากขึ้น: ไดเรกทอรีใดอนุญาตให้แก้ไขอัตโนมัติ การอัปเกรดการพึ่งพาอนุญาตให้ข้ามเวอร์ชันได้มากแค่ไหน การอัปเดตฐานข้อมูลต้องมีการตรวจสอบใดบ้าง รหัสที่เกี่ยวข้องกับการรับรองตัวตนและการชำระเงินต้องผ่านการอนุมัติใดบ้าง และในสถานการณ์ใดบ้างที่ Agent ต้องหยุดทำงาน

ในทางตรงกันข้าม ตัวชี้วัดของ Agent-native forge ก็จะเปลี่ยนแปลงเช่นกัน 22.6 commit/s นั้นเด่นชัด แต่จำนวน commit เองไม่สามารถแทนความมีประสิทธิภาพในการผลิตซอฟต์แวร์ได้ ตัวชี้วัดที่มีความหมายมากกว่าจะเป็นระยะเวลาตั้งแต่ภารกิจเข้าสู่ระบบจนถึงการ merge ความสามารถในการฟื้นตัวแบบท้องถิ่นหลังจากล้มเหลว สัดส่วนของการเปลี่ยนแปลงที่เสร็จสิ้นโดยอัตโนมัติภายในนโยบาย ต้นทุนการคำนวณของ accepted change และความสนใจของมนุษย์ที่ใช้ไปกับการเปลี่ยนแปลงที่มีความเสี่ยงสูง

Origin ต้องการควบคุมพื้นที่การผลิตซอฟต์แวร์ที่เกิดจากการรวมกันของ repository, checks, review, สิทธิ์ และ events

การแข่งขันระหว่าง GitHub และ Origin จึงจะค่อยๆ เปลี่ยนไปเป็นสองแนวทาง: GitHub จะขยายจากระบบความร่วมมือของมนุษย์ที่สุกงอมไปสู่ Agent ในขณะที่ Cursor พยายามออกแบบ forge ใหม่ตามภาระงานของ Agent

05 ลาหม่าอยู่ชั้นถัดไป

ที่กล่าวมา หลังจากเปิดตัว Grok 4.6 แล้ว ภายนอกมักยังคงอภิปรายเกี่ยวกับ benchmark ความสามารถในการเขียนโค้ด คะแนนการให้เหตุผล และราคาอยู่เสมอ แต่เมื่อพิจารณา Colossus, Grok, Cursor และ Origin ร่วมกัน แท้จริงแล้วการจัดวางนี้ได้ขยายไปยังห่วงโซ่การผลิตซอฟต์แวร์หลังจากโมเดล

Colossus ให้กำลังการประมวลผล Grok รับผิดชอบการให้เหตุผล Cursor เปลี่ยนความสามารถของโมเดลเป็นการแก้ไขโค้ด Origin รับต่อสถานะรีพอสิทอรี PR การตรวจสอบ และการทบทวนหลังจากนั้น เมื่อความสามารถของโมเดลเพิ่มขึ้น ผลประโยชน์สามารถถ่ายทอดตรงตามสายการดำเนินการได้ แม้ว่าโมเดลรุ่นเดียวจะไม่สร้างช่องว่างที่ชัดเจน โครงสร้างพื้นฐานด้านหลังยังสามารถสะสมต่อไปได้

ดังนั้น การที่ Grok 4.6 อยู่ในอันดับใดบนรายการวันนี้ อาจเป็นเพียงผลลัพธ์ชั่วคราว คำถามระยะยาวมากกว่าคือ ใครจะสามารถจัดระเบียบโมเดล สภาพแวดล้อมการดำเนินงาน และสถานะวิศวกรรมซอฟต์แวร์ให้เป็นระบบการผลิตที่ทำงานต่อเนื่อง

เมื่อทุกคนยังคงแย่งกันว่ารุ่นนี้ใครฉลาดกว่า ก็ไม่รู้ว่าลาวมาได้ไปถึงชั้นถัดไปแล้ว