ทำไม AI agent ต้องการ version control แบบใหม่, และ git ที่เราใช้มา 15 ปี กำลังกลายเป็นคอขวด

โดย Nokka (นก-กา) | 25 สิงหาคม 2026

บทความนี้เขียนโดย AI (deepseek-v4-pro via ollama-cloud) ผ่าน Hermes Agent ภายใต้การควบคุมและตรวจสอบคุณภาพโดยมนุษย์, Nokka (นก-กา)

ก่อนอื่น, ทำความเข้าใจศัพท์

ก่อนเข้าเรื่อง ขอปูศัพท์ 3 คำที่คนอ่านบทความนี้ต้องรู้ก่อน:

• Version Control (การควบคุมเวอร์ชัน): ระบบที่บันทึกประวัติการแก้ไขโค้ดทุกครั้ง, ให้ย้อนกลับ, เปรียบเทียบ, และรวมงานจากหลายคนได้
• Git: ระบบ version control ที่ Linus Torvalds สร้างปี 2005, กลายเป็นมาตรฐานโลกที่นักพัฒนาเกือบทุกคนใช้
• Human Cadence (จังหวะของมนุษย์): สมมติฐานที่ว่า "คนเขียนโค้ดช้า", เปิด branch, เขียน 2-3 ชั่วโมง, เปิด PR, รอรีวิว, merge

ถ้าให้อุปมา: git คือ "ถนน 2 เลน" ที่ออกแบบมาให้รถคนขับ (มนุษย์) วิ่ง, ใช้ได้ดีเมื่อมีรถไม่กี่คัน แต่เมื่อ "รถไร้คนขับหลายพันคัน" (AI agent) วิ่งพร้อมกัน ถนนเดิมก็ติดขัดและชนกัน

ปัญหา: git ถูกออกแบบมาเพื่อ "จังหวะของมนุษย์"

Git ถูกสร้างปี 2005 โดย Linus Torvalds เพื่อแก้ปัญหาการพัฒนา Linux kernel, และมันถูกออกแบบรอบสมมติฐานเดียว:

"นักพัฒนาคนหนึ่ง เปิด branch → เขียนโค้ด 2-3 ชั่วโมง → เปิด PR → รอเพื่อนรีวิว → merge"

จังหวะทั้งหมดวัดเป็น ชั่วโมงและวัน, และมันถูกต้อง เพราะมนุษย์พิมพ์โค้ดได้แค่เร็วระดับหนึ่ง

แต่ AI agent ทำลายสมมติฐานนี้สิ้นเชิง [1]:

"agent หลายสิบหรือหลายร้อยตัว clone, branch, commit, rebase โค้ดเดียวกันพร้อมกัน ภายในไม่กี่วินาที"

นี่คือ load profile ที่ต่างกันโดยสิ้นเชิง จากสิ่งที่ git/GitHub ถูกออกแบบมารองรับ

3 ปัญหาที่ git "ทำไม่ได้" (หรือทำได้แย่มาก)

1. Merge conflict ที่ "machine-readable" ไม่ได้มีเพียง "human-readable"

นี่คือจุดที่ลึกที่สุด และเป็น "the hard part" จริงๆ ตามที่วิศวกรชี้ใน Hacker News [2]:

Git เก็บ conflict เป็น marker (<<<<<<<, =======, >>>>>>>) ที่ออกแบบให้มนุษย์อ่าน, แต่ agent ต้อง "เข้าใจ" สถานะ conflict แบบที่เครื่องอ่านได้ เพื่อแก้เองอัตโนมัติ

การสร้าง "GitHub ที่สวยขึ้น + ใส่ AI" ไม่ใช่คำตอบ, คำตอบคือการสร้าง data model ใหม่ ที่ conflict state เป็น machine-readable ตั้งแต่แรก

2. ปริมาณ PR ที่เกินกำลังมนุษย์รีวิว

ถ้า agent commit 22.6 ครั้ง/วินาที (ตัวเลขจาก demo ของ Cursor Origin), ใครจะรีวิวทั้งหมด?

GitHub ไม่มีคำตอบนี้ เพราะถูกออกแบบให้ "มนุษย์รีวิวทุก PR", แต่เมื่อ agent ผลิต PR เป็นร้อยเป็นพันต่อวัน มนุษย์รีวิวไม่ไหว

คำตอบที่ Origin พยายามทำคือ agent-aware merge queue + auto-merge ที่ให้ agent ช่วยกันย้าย PR ไปสู่สถานะ merge ได้

3. State model ที่ซับซ้อนเกินไปสำหรับ agent

Git มี state model ซับซ้อน (branch, merge, rebase, stash, detached HEAD...), agent ต้อง "เสีย context" ไปกับการคิดเรื่องกลไก version control แทนที่จะคิดเรื่องโค้ด

แนวคิดใหม่ (อย่าง jj ที่ Amplify Partners พูดถึง) คือทำให้ git กลายเป็นแค่ "storage layer" โง่ๆ แล้วสร้าง data structure ที่เรียบง่ายกว่าอยู่ข้างบน [3]

ตัวอย่างจริง: agent หนึ่งตัวทำอะไรใน "หนึ่งรัน"

เพื่อให้เห็นภาพชัด ลองดูว่า agent หนึ่งตัวทำอะไรในครั้งเดียว (จาก Freestyle Blog):

"agent ตัวหนึ่งอาจแก้ React app, เพิ่ม migration, อัปเดต test, เขียน release note, และ regenerate screenshot, ทั้งหมดในรันเดียว"

นี่คือ "state" ที่ถูกสร้างเร็วกว่าที่ทีมมนุษย์จะตรวจทัน, และ git ที่ออกแบบมาให้ "มนุษย์ commit ทีละอย่าง" ก็เริ่มไม่พอ

ตาราง: git เพื่อมนุษย์ vs version control เพื่อ agent

มิติ	Git/GitHub (เพื่อมนุษย์)	Version control ใหม่ (เพื่อ agent)
จังหวะ	ชั่วโมง/วัน	วินาที (22.6 commits/วินาที)
จำนวนผู้เขียน	1 คนต่อ branch	หลายสิบ agent พร้อมกัน
Merge conflict	มนุษย์แก้ทีละจุด	agent แก้เองอัตโนมัติ
Review	มนุษย์อ่าน diff	intelligence layer ช่วยกรอง
State model	ซับซ้อน (branch/merge)	เรียบง่าย ไม่เสีย context

ข้อควรระวัง: คำถามที่ยังไม่มีคำตอบ

ก่อนสรุป ขอวางมุมให้ตรง เพราะมีคำถามที่คมที่สุดจาก Hacker News [2]:

"ถ้า agent commit 22.6 ครั้ง/วินาที แล้วใครรีวิวทั้งหมด? มนุษย์ยังอยู่ใน loop ไหม?"

นี่คือ "the whole ballgame", การเร่งให้เครื่องเขียน+merge โค้ดเร็วขึ้น ไม่ช่วยอะไรเลยถ้าไม่มีใครรับรองว่าโค้ดถูกต้อง

ข้อดีของแนวคิดใหม่	ข้อเสีย/ความเสี่ยง
รองรับ agent ทำงานเป็นวินาที	"agent แก้ conflict เอง" อาจแก้ผิดแล้ว ship เร็ว
ลด context ที่ agent เสียไป	ยังไม่มีใครแก้ปัญหา "trust" ได้จริง
ปลดล็อก multi-agent workflow	ข้อมูลโค้ดไปอยู่กับ platform ใหม่ (privacy)

ประเด็นสำคัญ: "Agent แก้ merge conflict อัตโนมัติ" ฟังดูดี, จนกระทั่ง agent แก้ผิด แล้ว ship ไปด้วยความเร็วเครื่องจักร

สรุปมุมมองของผม

ผมมองว่านี่คือบทต่อไปของชุด "Harness Engineering" ที่ผมเขียนไว้, เพราะมันคือคำถามเดียวกันในระดับที่ลึกขึ้น:

• Harness = กติกาที่ทำให้ agent ทำงานได้จริง
• Version control ใหม่ = กติกาที่ทำให้ agent "หลายตัว" ทำงานร่วมกันได้จริง

git ไม่ได้ "พัง", มันยังเป็นมาตรฐานที่ยอดเยี่ยมสำหรับมนุษย์ แต่เมื่อ agent กลายเป็นผู้ใช้หลัก เครื่องมือที่ออกแบบมาเพื่อ "จังหวะของมนุษย์" ก็เริ่มส่งเสียงเอี๊ยดอ๊าด

และนี่คือ pattern ที่เกิดซ้ำในทุกวงการ: เครื่องมือที่สร้างมาเพื่อมนุษย์ จะถูกสร้างใหม่เมื่อ software กลายเป็นผู้ใช้หลัก, เหมือนที่ helpdesk (Zendesk) ต้องถูกคิดใหม่เมื่อ AI agent มาแทนมนุษย์ตอบ ticket

คำถามที่แท้จริงไม่ใช่ "Origin จะชนะ GitHub ไหม" แต่คือ "ใครจะแก้ปัญหา trust ได้ก่อน", เพราะ throughput ไม่เคยเป็นส่วนที่ยาก ความไว้วางใจต่างหากที่เป็น

คุณคิดว่า "มนุษย์ยังต้องอยู่ใน loop" เสมอไหมครับ? หรือถึงจุดหนึ่งเราจะปล่อยให้ agent merge โค้ดเองโดยไม่ต้องรีวิว? คอมเมนต์แลกเปลี่ยนกันได้ครับ

แหล่งอ้างอิง

[1] eesel AI. "What is Cursor Origin? Cursor's Git forge for the agentic era, explained". 2026. https://www.eesel.ai/blog/what-is-cursor-origin

[2] Hacker News. "Cursor Origin discussion thread". 2026. https://news.ycombinator.com/item?id=48570239

[3] Amplify Partners. "Will agents like Git any more than we do?". 2026. https://www.amplifypartners.com/blog-posts/will-agents-like-git-any-more-than-we-do

---

บทความนี้เป็นส่วนหนึ่งของซีรีส์ Harness Engineering ข้อมูล ณ 25 สิงหาคม 2026 Nokka