Vibe Coding กับ Agentic Engineering ต่างกันตรงไหน

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

1.1 นิยามที่ใช้ในชุดคู่มือนี้

Vibe coding คือการสั่ง AI เขียนโค้ดแล้วตัดสินผลด้วยสายตาและความรู้สึก รันดู ถ้าเหมือนจะใช้ได้ก็ไปต่อ สเปกอยู่ในหัวคนสั่ง การตรวจสอบคือการอ่านผ่าน ๆ ไม่มีสิ่งใดถูกบันทึกไว้ให้รอบหน้าใช้ซ้ำ มันเร็วมากและเหมาะกับ prototype, สคริปต์ใช้ครั้งเดียว, และการสำรวจว่าไอเดียเป็นไปได้ไหม

Agentic engineering คือการวางระบบให้ agent ทำงานใน loop ที่มีเงื่อนไขความสำเร็จอ่านได้ด้วยเครื่อง คนย้ายบทบาทจาก “คนพิมพ์โค้ด” ไปเป็น “คนออกแบบสเปก เกณฑ์ตรวจ และขอบเขต” ส่วน agent รับหน้าที่เขียน รัน อ่าน error แก้ และรันใหม่ จนผ่านเกณฑ์หรือชนเพดานที่ตั้งไว้

ประโยคเดียวที่แยกสองอย่างนี้ออกจากกัน

Vibe coding: “AI เขียนโค้ด แล้วฉันดูว่าโอเคไหม”

Agentic engineering: “ฉันเขียนนิยามของคำว่าโอเค แล้ว AI ทำจนกว่าเครื่องจะบอกว่าโอเค”

1.2 ตารางเปรียบเทียบ

มิติ	Vibe Coding	Agentic Engineering
Input ของ AI	prompt สนทนา ต่อยอดจากความจำใน chat	ไฟล์สเปก + กติกาโปรเจกต์ + test ที่ fail อยู่
นิยามความสำเร็จ	อยู่ในหัวคน เปลี่ยนได้ตลอด	อยู่ใน verify.sh หรือ CI — deterministic รันซ้ำได้
ผู้ตัดสินความถูก	LLM บวกสายตามนุษย์	compiler, test runner, linter, type checker
ความยาว session	ยาว สะสม context จนเลอะ	สั้นและใช้แล้วทิ้ง state อยู่ในไฟล์ ไม่ใช่ใน context
สิ่งที่เหลือหลังจบงาน	โค้ดอย่างเดียว	โค้ด + test + spec + ADR + กติกาที่ agent รอบหน้าอ่านได้
เมื่อ AI ทำผิด	รู้ตอน user เจอ	รู้ตอน gate แดง ก่อน commit
การทำซ้ำ	ทำใหม่ได้ผลไม่เหมือนเดิม	รัน pipeline เดิมได้ผลเทียบเคียงกัน
ต้นทุนเริ่มต้น	เกือบศูนย์	สูง ต้องลงทุนวางกติกา 1–3 วันแรก
ต้นทุนที่เดือน 6	สูงมาก โค้ดที่ไม่มีใครเข้าใจ แก้ที่ละจุดพังอีกจุด	คงที่ ทีมใหม่และ agent ใหม่เข้ามาต่อได้
เหมาะกับ	prototype, spike, งานใช้ครั้งเดียว, การเรียนรู้	ระบบที่มีคนใช้จริง มีเงิน มีข้อมูล มีทีม

ข้อควรระวัง

Agentic engineering ไม่ได้ดีกว่าเสมอไป มันแพงกว่าที่จุดเริ่มต้น ถ้าโจทย์คือ “อยากรู้ว่าไอเดียนี้เป็นไปได้ไหมภายในสองชั่วโมง” การวาง gate ครบชุดคือการเสียเวลา เกณฑ์ตัดสินง่าย ๆ คือ ถ้าโค้ดนี้จะยังอยู่ในอีกสามเดือน ให้ลงทุนวางระบบ ถ้าไม่ ปล่อยให้ vibe

1.3 โจทย์เดียวกัน ทำสองแบบ

โจทย์: เพิ่มระบบคูปองส่วนลดใน checkout API ที่มีอยู่แล้ว

แบบ Vibe

คน: "เพิ่มระบบคูปองใน checkout ให้หน่อย รองรับส่วนลดแบบ % กับแบบจำนวนเงิน"
AI:  [เขียนไฟล์ coupon.py 180 บรรทัด + แก้ checkout.py]
คน:  [รันดู เปิด Postman ยิงหนึ่งครั้ง ได้ 200 OK] "โอเคใช้ได้"
คน:  git commit -m "add coupon"

สิ่งที่ยังไม่รู้:

คำถาม	สถานะ
คูปองหมดอายุแล้วใช้ได้ไหม	ไม่มีใครลอง
ใช้คูปองสองใบพร้อมกัน	ไม่มีใครลอง
ส่วนลดมากกว่ายอดรวม กลายเป็นติดลบ	ไม่มีใครลอง
race condition ตอนคูปองจำกัดจำนวน	ไม่มีใครลอง
คูปอง % กับภาษี คำนวณลำดับไหน	AI เดาเอง ไม่มีใครยืนยัน

แบบ Agentic

1. คนเขียน docs/specs/coupon.md ใช้เวลา 15 นาที โดยนิยาม 6 กติกาธุรกิจรวมลำดับการคิดภาษี ระบุ 4 เคสที่ต้อง reject พร้อม error code และระบุสิ่งที่อยู่นอกขอบเขต เช่น v1 ไม่รองรับคูปองซ้อน

2. คนหรือ agent เขียน test จาก spec ก่อน ต้องแดงทั้งหมด

$ pytest tests/test_coupon.py
14 failed        [RED]

3. agent ทำงานใน loop คืออ่าน spec แล้วเขียน implementation แล้วรัน verify.sh แล้วอ่าน error แล้วแก้ แล้วรันใหม่

รอบที่ 1: 9 failed
รอบที่ 2: 3 failed
รอบที่ 3: 0 failed

4. gate รันเต็มชุด ทั้ง format, lint, type, unit, property, integration และ coverage diff

$ ./scripts/verify.sh
ALL GATES PASSED    [GREEN]

5. คนรีวิว 3 อย่าง ไม่ใช่รีวิวทุกบรรทัด คือ spec ตรงกับที่ธุรกิจต้องการไหม, test ครอบเคสอันตรายจริงไหมหรือแค่ test สิ่งที่โค้ดทำอยู่, และมี dependency, migration หรือ breaking change แอบเข้ามาไหม

6. merge หลัง canary 5% เป็นเวลา 24 ชั่วโมง โดยดู guardrail metric

เวลาที่ใช้ต่างกันประมาณ 40 นาทีต่อ 3 ชั่วโมงสำหรับฟีเจอร์แรก แต่ฟีเจอร์ที่ 2 ถึง 20 ในโปรเจกต์เดียวกัน แบบ agentic จะเร็วกว่า เพราะ spec template, test fixture, gate และกติกาใน AGENTS.md ถูกใช้ซ้ำได้ทั้งหมด ส่วนแบบ vibe จะช้าลงเรื่อย ๆ เพราะโค้ดที่ไม่มีการทดสอบสะสมจนแตะอะไรก็พัง

1.4 จุดที่ vibe code พังเมื่อระบบโต

อาการ	สาเหตุเชิงโครงสร้าง
แก้ตรงนี้ พังตรงโน้น	ไม่มี regression test ทุกการแก้คือการเดาว่าไม่มีอะไรพึ่งพาโค้ดเดิม
AI เขียนทับของเดิม	ไม่มีไฟล์กติกาบอกว่าโครงสร้างเดิมคืออะไร agent จึงสร้าง pattern ใหม่ทุกครั้ง
โค้ดสามสไตล์ในไฟล์เดียว	แต่ละ session ใช้ context ต่างกัน ไม่มี convention ที่บังคับด้วยเครื่อง
ไม่มีใครกล้า refactor	ไม่มีเกณฑ์ยืนยันว่าหลัง refactor พฤติกรรมยังเหมือนเดิม
onboarding คนใหม่ไม่ได้	เหตุผลของการตัดสินใจอยู่ใน chat ที่หายไปแล้ว ไม่ได้อยู่ใน repo
bug ขึ้น production ถี่	เกณฑ์ผ่านคือ “ดูแล้วน่าจะได้” ซึ่งไม่จับ edge case

ข้อสังเกต

ปัญหาทั้งหกข้อไม่ได้เกิดจาก “AI เขียนโค้ดไม่เก่ง” แต่เกิดจากการที่ระบบไม่มีที่เก็บความรู้ถาวร ทางแก้จึงไม่ใช่การหาโมเดลที่ฉลาดขึ้น แต่คือการย้ายความรู้จาก context window ไปไว้ในไฟล์

สรุปบทนี้

ความต่างไม่ได้อยู่ที่เครื่องมือ แต่อยู่ที่ว่านิยามของคำว่า “ผ่าน” ถูกเขียนไว้ที่ไหน ถ้าอยู่ในหัวคน ระบบจะโตไม่ได้ ถ้าอยู่ในไฟล์ที่รันซ้ำได้ agent จะทำงานเองได้และคนจะรีวิวเฉพาะสิ่งที่สำคัญ

บทถัดไปว่าด้วยแกนกลางห้าข้อของวิธีทำงานแบบนี้ และกายวิภาคของ loop หนึ่งรอบ