Git สำหรับทีมที่ทุกคนมี AI ช่วยเขียน

ปัญหาที่เปลี่ยนไปเมื่อทุกคนมี agent คือ ปริมาณโค้ดต่อคนเพิ่ม 3–10 เท่า แต่ความสามารถในการรีวิวของทีมเท่าเดิม คอขวดย้ายจาก “การเขียน” ไปที่ “การรีวิวและการรวมงาน” ทั้งหมด ทุกกติกาในบทนี้มีเป้าหมายเดียวคือทำให้คอขวดนั้นไม่ระเบิด

11.1 กติกาแกนกลาง 6 ข้อ

กติกา	เหตุผลและวิธีบังคับ
PR เล็กเสมอ	เพดาน 400 บรรทัดที่เปลี่ยน บังคับด้วย CI ที่เตือนเมื่อเกิน — agent ทำ PR 2,000 บรรทัดได้ใน 20 นาที แต่ไม่มีใครรีวิวได้จริง
หนึ่ง PR หนึ่งเจตนา	ห้ามผสม refactor กับฟีเจอร์ — agent ชอบ “ปรับปรุงตรงนี้ด้วยเลย” ต้องห้ามไว้ใน AGENTS.md
มนุษย์เป็นเจ้าของ PR	ทุก PR มีมนุษย์หนึ่งคนที่รับผิดชอบเต็ม ต่อให้ agent เขียนทุกบรรทัด ไม่มี PR ไร้เจ้าของ
Branch อายุสั้น	ไม่เกิน 2 วัน agent ทำงานเร็ว branch ที่อยู่นาน 1 สัปดาห์จะ conflict หนักมาก
CI คือ gate เดียวกับ local	รัน verify.sh ตัวเดียวกัน ห้ามมีสองมาตรฐาน
Rebase ก่อนเสมอ	ดึง main มาก่อนทุกครั้งที่ agent เริ่มทำงานรอบใหม่ ไม่ใช่ตอนจะเปิด PR

11.2 การบอกที่มาของโค้ด (provenance)

ทีมต้องรู้ว่าโค้ดชิ้นไหนคนเขียน ชิ้นไหน agent เขียน และมนุษย์ตรวจแค่ไหน เพราะระดับการรีวิวควรต่างกัน วิธีที่ใช้ได้และไม่รบกวนคือ commit trailer

feat(checkout): add coupon validation and discount calculation

implement R1-R6 ตาม docs/specs/coupon.md
ส่วนลดคิดก่อนภาษี ตัดที่ยอด 0 ตาม R4

AI-Assisted: heavy          # none | light | heavy | autonomous
AI-Tool: claude-code
Human-Review: full          # full | tests-only | spot
Spec: docs/specs/coupon.md
Gate: verify.sh green (run 2026-08-04T09:12Z, 47 tests, cov 84%)
Co-Authored-By: Claude <noreply@anthropic.com>

ระดับ	ความหมาย	การรีวิวที่ต้องได้
none	คนเขียนเองทั้งหมด	รีวิวปกติ
light	AI ช่วยเติมโค้ด คนคุมโครงสร้าง	รีวิวปกติ
heavy	AI เขียนหลัก คนกำกับและตรวจทุกส่วน	ต้องอ่าน test ทุกบรรทัด + ตรวจ blast radius
autonomous	AI ทำเองใน loop คนดูแค่ผลลัพธ์	ต้องมีผู้รีวิวที่สอง + ห้ามแตะ path ที่แตะเงินหรือข้อมูลผู้ใช้

PR template ที่บังคับกรอก:

## สิ่งที่เปลี่ยนและทำไม

## Spec
- ลิงก์: docs/specs/____.md
- กติกาที่ implement: R__ ถึง R__

## Gate

วาง output จริงของ ./scripts/verify.sh ตรงนี้

## AI provenance
- AI-Assisted: [ ] none [ ] light [ ] heavy [ ] autonomous
- เครื่องมือ: ______
- ส่วนที่มนุษย์เขียนหรือแก้เอง: ______

## Blast radius (บังคับกรอก ห้ามข้าม)
- ถ้าผิดพลาดร้ายแรงที่สุด ผู้ใช้ได้รับผลกระทบ: ______ คน / ______ %
- ระดับความเสียหาย: [ ] L1 [ ] L2 [ ] L3 [ ] L4 [ ] L5
- ตรวจเจอได้ภายใน ____ นาที ด้วย: ______
- Rollback: [ ] ปิด feature flag [ ] revert commit [ ] ต้อง migrate ย้อน
  เวลาที่ใช้: ____ นาที

## สิ่งที่ผู้รีวิวควรดูเป็นพิเศษ (เรียงตามความเสี่ยง)
1.
2.
3.

## Checklist
- [ ] test เขียนจาก spec ไม่ใช่จาก implementation
- [ ] มีเคส reject ครบตามสเปก
- [ ] ไม่มีไฟล์นอกขอบเขตถูกแตะ
- [ ] ไม่มี dependency ใหม่ (ถ้ามี อธิบายเหตุผล)
- [ ] migration ย้อนกลับได้และไม่ล็อกตารางเกิน 2 วินาที
- [ ] อัปเดต memory/pitfalls.md ถ้าเจอบทเรียนใหม่

11.3 การแบ่งงานเพื่อลด conflict

เมื่อสามคนในทีมสั่ง agent ทำงานพร้อมกัน โอกาส conflict สูงกว่าเดิมมาก เพราะแต่ละ agent มีแนวโน้มจะ “ปรับปรุงไฟล์ข้างเคียง” ด้วย มาตรการที่ใช้ได้จริงคือประกาศขอบเขตไฟล์ของแต่ละงานไว้ล่วงหน้า และห้าม agent แตะไฟล์นอกขอบเขตนั้น

11.4 การจัดการ conflict

เมื่อ conflict เกิดขึ้น ต้องรัน test ของ ทั้งสองฝั่ง ไม่ใช่แค่ชุดปัจจุบัน

git checkout theirs-branch -- tests/      # ดึง test ฝั่งโน้นมาด้วย
./scripts/verify.sh

และ ห้าม agent ใช้ git checkout --ours หรือ --theirs แบบเหวี่ยงแห นี่คือวิธีที่ทำให้โค้ดหายเงียบ ๆ และไม่มี test ตัวไหนจับได้ ให้ใส่ไว้ในรายการข้อห้ามของ hook

11.5 CI ที่รับมือกับปริมาณ PR ที่เพิ่มขึ้น

ชั้นที่ 1 — เร็ว (<2 นาที) รันทุก push
  format, lint, type, unit test ของไฟล์ที่แตะ
  ผลลัพธ์: บล็อกทันที

ชั้นที่ 2 — เต็ม (<10 นาที) รันเมื่อเปิด PR และทุก push หลังจากนั้น
  verify.sh ทั้งชุด + no-cheating check
  ผลลัพธ์: บล็อก merge

ชั้นที่ 3 — คุณภาพ (ไม่บล็อก) โพสต์เป็นคอมเมนต์
  coverage diff, complexity delta, PR size, dependency ใหม่,
  รายการไฟล์ที่แตะนอกขอบเขตที่ประกาศไว้,
  รายงานจาก LLM ว่า "จุดที่ควรตรวจเพิ่ม" (คำแนะนำเท่านั้น ไม่มีสิทธิ์บล็อก)

ชั้นที่ 4 — กลางคืน
  E2E เต็มชุด, mutation test บน diff ของวันนั้น,
  security scan, สรุปว่า test ตัวไหนเป็น flaky

กฎเหล็ก

ห้ามมี test ที่แดงสุ่ม ๆ อยู่ใน gate ที่บล็อก merge เพราะทีมจะเรียนรู้ที่จะกด re-run จนเขียว แล้ว gate ทั้งระบบจะหมดความหมาย flaky test เจอเมื่อไหร่ให้ย้ายออกจาก gate ทันทีแล้วเปิด issue แก้ ไม่ใช่ปล่อยไว้

11.6 การส่งงานระหว่างคน

เมื่อคนสองคนทำงานต่อกัน สิ่งที่ต้องส่งต่อไม่ใช่แค่โค้ด แต่คือ บริบทที่ agent ของอีกคนต้องใช้ เพราะ agent ของอีกคนไม่มีประวัติ chat ของคุณ

สิ่งที่ต้องอยู่ใน repo ก่อนส่งงาน ไม่ใช่ใน Slack:

ไฟล์	เนื้อหา
docs/specs/xxx.md	สเปกที่อัปเดตให้ตรงกับที่ทำจริง
memory/decisions.md	ตัดสินใจอะไรระหว่างทาง เพราะอะไร
memory/pitfalls.md	สิ่งที่ลองแล้วไม่ได้ผล กันคนถัดไปเสียเวลาซ้ำ
PR description	blast radius, rollback, สิ่งที่ยังค้าง
TODO ในโค้ด	ระบุชื่อคนหรือ issue เสมอ ห้าม TODO ลอย

ทดสอบว่าส่งงานครบไหมด้วยคำถามเดียว:

“ถ้าเพื่อนร่วมทีมเปิด repo นี้พรุ่งนี้เช้า สั่ง agent ว่า ‘ทำงานนี้ต่อ’ โดยไม่ถามอะไรฉันเลย เขาจะทำถูกไหม”

ถ้าคำตอบคือไม่ แปลว่ายังมีบริบทค้างอยู่ในหัวคุณหรือใน chat ที่ต้องย้ายลงไฟล์

ตัวชี้วัดสุขภาพของทีม

ทีมที่ทำ agentic engineering ได้ดีจะเห็นตัวเลขนี้ คือ เวลาเฉลี่ยจากเปิด PR ถึง merge ลดลง ในขณะที่อัตราการ rollback ไม่เพิ่มขึ้น ถ้าเวลาลดแต่ rollback เพิ่ม แปลว่ากำลังเร่งความเร็วโดยย้ายต้นทุนไปให้ผู้ใช้แบก ไม่ใช่การเพิ่มผลิตภาพ

สรุปบทนี้

คอขวดย้ายไปที่การรีวิว ทุกกติกาจึงมุ่งไปที่การทำให้รีวิวได้จริง คือ PR เล็ก หนึ่ง PR หนึ่งเจตนา branch อายุสั้น และมีมนุษย์เป็นเจ้าของเสมอ บอกที่มาของโค้ดด้วย trailer เพื่อให้ระดับการรีวิวตรงกับความเสี่ยง แบ่ง CI เป็นสี่ชั้นตามความเร็ว และวัดสุขภาพทีมด้วยเวลาถึง merge ควบคู่กับอัตรา rollback

บทถัดไปเป็นภาคผนวก รวม checklist และ anti-pattern 12 ข้อที่พบบ่อย