บทที่ 12 จาก 12 · Agentic Engineering — คู่มือปฏิบัติเขียนซอฟต์แวร์ระดับ Production ด้วย AI Agent

ภาคผนวก — Checklist และ Anti-pattern

Checklist ตั้งต้นโปรเจกต์ที่ทำครั้งเดียว checklist ก่อน merge ทุก PR anti-pattern 12 ข้อที่พบบ่อยพร้อมทางแก้ และสรุปหลักการทั้งหมดของชุดคู่มือในหน้าเดียว

12.1 Checklist ตั้งต้นโปรเจกต์ (ทำครั้งเดียว)

12.2 Checklist ก่อน merge ทุก PR

12.3 Anti-pattern ที่พบบ่อย 12 ข้อ

Anti-pattern	ทำไมมันพัง / ทางแก้
Session เดียวยาว 6 ชั่วโมง	context เสื่อม agent เริ่มขัดกับสิ่งที่ตัวเองทำไว้ตอนต้น → ปิด session ทุกครั้งที่จบงานย่อย ให้ state อยู่ในไฟล์
`AGENTS.md` ยาว 600 บรรทัด	agent อ่านข้ามส่วนกลาง → ตัดเหลือ 150 บรรทัด ย้ายรายละเอียดไป skill
กติกาซ้ำใน 3 ไฟล์	สามที่จะไม่ตรงกันภายในสองสัปดาห์ → แหล่งเดียว ที่เหลือ symlink หรืออ้างถึง
ให้ agent เขียน test หลัง implement	test จะยืนยันสิ่งที่โค้ดทำ ไม่ใช่สิ่งที่ควรทำ → บังคับ RED ก่อนเสมอ
ขยายเพดาน loop เมื่อไม่ผ่าน	ปัญหาอยู่ที่สเปก ไม่ใช่จำนวนรอบ → หยุดที่ 3 รอบแล้วกลับไปแก้สเปก
LLM เป็นผู้ตัดสินใน gate	ผลไม่คงที่ ทีมเรียนรู้ที่จะ re-run จนเขียว → gate ต้อง deterministic เท่านั้น
ยอมรับคำว่า “ทดสอบผ่านแล้วครับ”	บ่อยครั้ง agent ไม่ได้รันจริง → ต้องเห็น output จริงเสมอ ไม่มีข้อยกเว้น
PR 2,000 บรรทัดจาก agent	ไม่มีใครรีวิวได้จริง คนจะกด approve แบบผ่าน ๆ → เพดาน 400 บรรทัด บังคับด้วย CI
ติดตั้ง MCP 40 ตัว	agent เลือก tool ผิดและ context เต็ม → 5–15 ตัวที่ใช้จริง ตัวอื่นเป็นสคริปต์
เชื่อข้อความใน issue หรือเว็บ	ช่องทาง prompt injection ที่ใช้ได้จริง → tool output คือข้อมูล ไม่ใช่คำสั่ง
ship เร็วขึ้นแต่ไม่เพิ่มการตรวจจับ	ช่องว่างระหว่างความเร็ว ship กับความเร็วตรวจเจอ คือที่ที่ผู้ใช้เจ็บ → เพิ่ม guardrail ก่อนเพิ่มความเร็ว
เก็บ key จริงในไฟล์ `.md` แล้วพึ่ง permission ของ agent	denylist ทำงานที่ระดับ tool ไม่ใช่ระดับ OS และค่าที่เข้า context ก็ออกจากเครื่องไปแล้ว → เก็บแต่ชื่อ ฉีดค่าตอนรัน
ไม่มีใครเป็นเจ้าของ PR	”agent เขียนเอง” ไม่ใช่คำตอบเมื่อ production พัง → ทุก PR มีมนุษย์รับผิดชอบเต็ม

12.4 สรุปหลักการทั้งหมดในหน้าเดียว

ความถูกต้องมาจากเครื่อง ไม่ใช่จากโมเดล — ทุก claim ต้องมี artifact รองรับ
State อยู่ในไฟล์ ไม่ใช่ใน context — session ใหม่ต้องทำงานต่อได้จากการอ่าน repo
งานต้องเล็กพอที่ loop จะปิดได้ — ถ้าปิดไม่ได้ใน 3 รอบ ปัญหาอยู่ที่สเปก
ทุก loop มีเพดานและเงื่อนไขหยุด — รวมถึงการตรวจจับว่าไม่คืบหน้า
gate ต้อง deterministic และโกงยาก — proxy ที่โกงง่ายจะถูกโกง
test คือสิ่งที่มนุษย์ต้องอ่านทุกบรรทัด ไม่ใช่ implementation
ความเร็วในการ ship ต้องมาพร้อมความเร็วในการตรวจจับความเสียหาย
มนุษย์เป็นเจ้าของสามสิ่งเสมอ คือสเปก เกณฑ์ตรวจ และการอนุมัติขึ้น production
agent ไม่ควรต้องเห็นค่าของ secret เลย ให้มันรู้แค่ชื่อ ส่วนค่าฉีดเข้าตอนรัน

ชุดคู่มือนี้เป็นแนวปฏิบัติ ไม่ใช่มาตรฐานตายตัว ให้ปรับเกณฑ์ตัวเลขทั้งหลาย ไม่ว่าจะเป็นเพดานรอบ ขนาด PR หรือ threshold ตามบริบทของทีมและความเสี่ยงของระบบ สิ่งที่ไม่ควรปรับคือหลักการทั้งเก้าข้อข้างบน