The New SDLC with Vibe Coding : เมื่อ AI ย้ายคอขวดจาก Code ไปที่ Intent

ช่วงที่ coding agent เริ่มเขียน feature ได้ภายในไม่กี่ชั่วโมง ผมเคยคิดว่าปัญหาใหญ่ของงาน software น่าจะเบาลงเยอะ แต่พอทำจริงกลับพบว่าคิวงานไม่ได้หายไปครับ มันย้ายไปกองอยู่ที่ requirement, architecture, review, test และคำถามว่า ของที่ AI ทำมานั้นเชื่อได้แค่ไหน

ผมไปเจอ whitepaper ของ Google เรื่อง The New SDLC with Vibe Coding และน่าสนใจพอสมควร เพราะเอกสารนี้ ผู้เขียนวางกรอบใหม่ว่า Software Development Life Cycle หรือ SDLC ควรเปลี่ยนอย่างไร เมื่อคนเริ่มขยับจากการเขียน syntax ไปเป็นการระบุเจตจำนง (intent) แล้วให้ agent ลงมือแทน

ในเอกสารนี้ ผู้เขียนทดสอบทำงานระดับ production โดยเทียบระหว่าง Vibe Coding กับ Agentic Engineering ที่มี spec, context, tests, evals, guardrails และคนคอยตัดสินใจ เพื่อให้เห็นภาพใหญ่ และในบทความนี้ผมขอหยิบของ Google ไปเทียบกับ SDLC สำนักอื่นๆ เพิ่มเติม เพื่อให้เห็นภาพชัดขึ้นครับ

หมายเหตุ: ฟิวส์และเอเจ้นชมพูช่วยแปลและเรียบเรียงจาก whitepaper ของ Google เรื่อง The New SDLC with Vibe Coding โดย Addy Osmani, Shubham Saboo และ Sokratis Kartakis พร้อมค้นข้อมูลเสริมจาก Second Brain ของฟิวส์เพื่อใช้เปรียบเทียบแนวทาง SDLC ที่เกี่ยวข้อง

สรุปไฮไลต์สั้นๆ

• คอขวดย้ายจาก syntax ไปที่ intent เมื่อ AI เขียน code เร็วขึ้น งานกำหนดโจทย์ ออกแบบ และตรวจสอบจึงสำคัญกว่าเดิม และอาจจะยังช้าอยู่
• Vibe Coding ไม่เท่ากับ Agentic Engineering งานทดลองรับความเสี่ยงได้ แต่งาน production ต้องมีโครงสร้างและหลักฐาน
• Context Engineering คือทักษะหลัก คุณภาพไม่ได้ขึ้นกับ prompt เก่งอย่างเดียว แต่ขึ้นกับ instructions, knowledge, memory, examples, tools และ guardrails
• Harness ส่งเสริมกับ model ให้กลายเป็นระบบงาน ทั้ง rule files, tools, sandbox, orchestration, hooks, tests, evals และ observability
• บทบาท Developer เปลี่ยน จากคนลงมือ implement เป็น conductor และ orchestrator ที่กำหนดงาน คุมข้อจำกัด และตรวจผล
• Second Brain แต่ละกรอบตอบคนละคำถาม Google ให้แผนที่ภาพใหญ่ ส่วน AWS, Anthropic, Spec-Driven Development และ McKinsey ลงลึกคนละชั้น

The New SDLC with Vibe Coding by Google

เอกสารความยาว 51 หน้านี้ เผยแพร่ตั้งแต่พฤษภาคม 2026 เขียนโดย Addy Osmani วิศวกรและนักเขียนด้าน software engineering, Shubham Saboo ผู้ทำงานด้าน AI agents และ Sokratis Kartakis ผู้ทำงานกับ agent platforms และ Google ADK

คำว่า Vibe Coding เป็นคำที่ Andrej Karpathy ใช้อธิบายการเขียนโปรแกรมแบบปล่อยไปตามจังหวะ สั่ง AI ด้วยภาษาธรรมชาติ รับ output แล้วโยน error กลับไปให้แก้ต่อ แต่ whitepaper ไม่ได้สนับสนุนให้เราใช้วิธีนั้นกับทุกงานครับ

ผู้เขียนอยากให้มองวิธีทำงานกับ AI ให้เหมาะสมกับงาน ด้านหนึ่งคือ Vibe Coding ที่เหมาะกับ prototype, script, personal project หรือ hackathon อีกด้านคือ Agentic Engineering ที่เหมาะกับระบบ production และงานระดับทีม ความต่างไม่ได้อยู่ที่ใช้ AI รุ่นไหน แต่อยู่ที่มี structure, verification และการตัดสินใจของมนุษย์

เครื่องมือเดียวกันใช้ทำ Vibe Coding หรือ Agentic Engineering ก็ได้ สิ่งที่แยกสองแบบออกจากกันคือ เครื่องมือและองค์ประกอบรอบๆ AI ไม่ใช่เฉพาะ model

ผมมองว่าจุดนี้สำคัญ เพราะในช่วงแรกเราเรียกแทบทุกอย่างที่ใช้ AI เขียน code ว่า Vibe Coding จนคำเริ่มกว้างเกินไป, Senior Engineer ที่วางโครงระบบให้มี architecture, test suite และ review gate ชัดเจน ไม่ควรถูกจัดอยู่กลุ่มเดียวกับคนที่สั่งว่า “ช่วยทำระบบ payment ให้หน่อย แล้วกด deploy เลย” แบบหลังนี่ใจถึงเกินไปครับ 555

ปัญหาของ SDLC เดิมไม่ได้หายไป แต่มันถูกบีบไม่เท่ากัน

SDLC ผ่านการเปลี่ยนใหญ่จาก Waterfall ไปสู่ Agile, Continuous Integration และ DevOps มาแล้ว รอบนั้นช่วยลด feedback loop และทำให้ deployment ต่อเนื่องขึ้น แต่ AI กำลังบีบวงจรให้กระชับอีกแบบหนึ่งครับ

Implementation ที่เคยใช้เวลาหลายสัปดาห์อาจเหลือไม่กี่ชั่วโมง ขณะที่ requirement, architecture และ verification ยังเดินด้วยความเร็วของคน การเอา AI ไปเร่งเฉพาะช่วง Build จึงเหมือนขยายโรงงานผลิตสินค้าเป็นสิบเท่า แต่โต๊ะตรวจคุณภาพยังมีเจ้าหน้าที่สองคนเท่าเดิม สุดท้ายกล่องจะไปกองอยู่หน้าโต๊ะ QA แทน

เอกสารได้ยกงานวิจัยและแบบสำรวจที่ให้ภาพสองด้าน บางแหล่งรายงาน productivity เพิ่ม 25-39% ในบางงาน แต่การศึกษาของ METR พบว่านักพัฒนาที่มีประสบการณ์ใช้เวลานานขึ้น 19% กับงานบางประเภท เพราะต้องตรวจ แก้ และ debug output ของ AI เพิ่ม ตัวเลขเหล่านี้ไม่ได้แปลว่า AI ดีหรือไม่ดีแบบฟันธง แต่มันกำลังเตือนเราว่าความเร็วในการ generate code ไม่เท่ากับความเร็วในการส่งมอบ

AI ไม่ได้ทำให้การ implementation หายไป แต่มันเปลี่ยนงานจากการเขียนโค้ด ไปเป็นการกำหนดทิศทาง ตรวจสอบ และรับผิดชอบต่อผลลัพธ์

อีกปัญหาคือสิ่งที่ whitepaper เรียกว่า 80% problem, AI ทำส่วนใหญ่ของ feature ได้เร็ว แต่ส่วนที่เหลือมักเป็น edge cases, error handling, integration point และ business rule ละเอียดๆ ซึ่งต้องใช้การตรวจสอบและการวิเคราะห์สูงมาก เพราะ Code ที่ออกมาดูดีและผ่านการ test พื้นฐาน อาจซ่อนสมมติฐานผิดไว้ ซึ่งน่ากลัวกว่า syntax error มากครับ เพราะหน้าตามันดูน่าเชื่อมาก ไม่ได้แสดงผลลัพธ์ว่ามีอะไรผิดเลย

กระบวนการใหม่เริ่มจาก Context ก่อน Code

หัวใจของแนวทางนี้คือ Context Engineering หรือ เตรียมข้อมูลต่างๆที่ agent ต้องใช้ให้ครบ แล้วค่อยเริ่มงาน ซึ่งจะต่างจาก Vibe Coding ที่จะเขียน prompt หนึ่งย่อหน้าแล้ว คาดว่าจะได้ระบบระดับ production กลับมา

ผู้เขียนได้แบ่งประเภท context ออกเป็น 6 กลุ่ม

• Instructions บทบาท เป้าหมาย และขอบเขตการทำงาน
• Knowledge เอกสาร สถาปัตยกรรม และข้อมูลเฉพาะ domain
• Memory สถานะระยะสั้นและความรู้ที่ต้องจำข้าม session
• Examples ตัวอย่าง behavior และ pattern จาก codebase
• Tools API, scripts, database และบริการที่เรียกใช้ได้
• Guardrails ข้อจำกัด กฎรูปแบบ และการตรวจความปลอดภัย

จากนั้นต้องแยกระหว่าง static context ออกจาก dynamic context ให้ดี โดย

Static context เช่น `AGENTS.md`, `CLAUDE.md` หรือกฎระดับ project จะถูกโหลดบ่อย จึงควรสั้นและมีสัญญาณสูง

ส่วน Dynamic context จะเป็นพวกความรู้เฉพาะทางควรโหลดเมื่อ task ต้องใช้งาน ไม่ว่าจะผ่าน skills, tools หรือ retrieval

ซึ่งการใช้ Static/Dynamic ผิดที่ผิดทาง จะทำให้เปลือง token มากพอสมควร แม้งานแก้อาจจะมีแค่นิดเดียวก็ตาม

เรื่องนี้ผมเองก็เคยพลาดอยู่นาน ตอนใช้ OpenClaw/Hermes Agent ใหม่ๆ แค่ใช้คุยและทำงานเล็กๆ แต่ทำให้ token หมดไวมาก เพราะฝังพวกกฎและความสามารถบางอย่างไปไว้ใน Static context ทำให้ใช้ token ก้อนใหญ่ทุกครั้งที่มีการเปิด session หรือ chat

Factory Model เปลี่ยนสิ่งที่ Developer ต้องสร้าง

เมื่อ context พร้อม ผู้เขียนเสนอ Factory Model มองว่า output หลักของ Developer ไม่ได้มีแค่ code แต่คือระบบที่ผลิต code อย่างเชื่อถือได้ ระบบนี้ประกอบด้วย spec, agents, tests, quality gates, feedback loops และ guardrails

เปรียบง่ายๆ Developer ไม่ได้ยืนประกอบสินค้าทุกชิ้นด้วยมืออย่างเดียว แต่ต้องออกแบบสายพาน เลือกเครื่องจักร ตั้ง sensor และกำหนดว่าของชิ้นไหนผ่านออกจากโรงงานได้ ถ้าสายพานเร็วแต่เครื่องตรวจเสีย เราจะผลิตปัญหาได้เร็วขึ้นเท่านั้น

Harness คือเครื่องจักรรอบตัว Model

Harness Engineering คือการออกแบบชั้นที่ห่อ model ให้ทำงานได้จริง ทั้ง rule files, tools, sandbox, orchestration, subagents, hooks, logs, traces, cost และ latency monitoring สมการสั้นๆ ในเอกสารคือ Agent = Model + Harness (Agent เท่ากับ Model บวก Harness)

• ช่วงวางแผน Harness โหลดกฎและข้อจำกัด
• ช่วง implement มันจัด tool กับ sandbox ให้ agent ใช้
• ช่วง test มันส่งผลล้มเหลวกลับเข้า loop เพื่อแก้ใหม่
• และช่วง review หรือ deploy มันใช้ hooks กับ observability ป้องกันสิ่งที่ห้ามเกิด เช่น secret หลุดหรือ commit ที่ไม่ผ่านเงื่อนไข

เมื่อ Agent ทำผิด คำถามแรกไม่ควรเป็น Model รุ่นนี้ไม่เก่งหรือเปล่า แต่อาจต้องถามก่อนว่าเราใช้ Harness อะไร, เราขาด tool, context, rule, guardrail หรือ feedback loop ตรงไหน

แต่ละช่วงของ SDLC เปลี่ยนอย่างไร

บทบาท Developer จึงสลับอยู่สองโหมด Conductor คือทำงานกับ AI แบบ real-time คอยดูและกำกับทีละจังหวะ เหมาะกับ logic ซับซ้อน งาน debug หรือ codebase ที่ยังไม่คุ้น

ส่วน Orchestrator คือกำหนดเป้าหมาย มอบหมายงานให้ agents ทำแบบ async แล้วกลับมาตรวจ เหมาะกับงานที่ขอบเขตชัด เช่น known bug, migration หรือ test generation

ทีมไม่ต้องเลือกโหมดเดียวตลอดครับ งานหนึ่งอาจเริ่มแบบ conductor ตอนออกแบบ แล้วเปลี่ยนเป็น orchestrator เมื่องานถูกแตกจนชัด ทักษะที่เพิ่มขึ้นคือ specification, decomposition, evaluation และ system design มากกว่าความสามารถในการพิมพ์ syntax เร็วที่สุด

ข้อดีและข้อเสียที่ควรมองให้ครบ

ข้อดีของแนวทางนี้

• แยกพื้นที่ทดลองออกจาก production ทำให้ทีมใช้ Vibe Coding ได้โดยไม่เอาความเสี่ยงแบบเดียวกันไปใช้ทุกระบบ
• วาง Context เป็นทรัพย์สินของทีม rule files, skills, tests และ evals ถูก review และพัฒนาซ้ำได้
• ลดงาน implement ที่ซ้ำ Agent รับงาน scaffold, migration, test generation และ pattern ที่มีคำตอบค่อนข้างชัด
• ทำ handoff ให้ตรวจย้อนหลังได้ intent, constraint, test result และ agent trace ไม่หายอยู่ใน chat เพียงอย่างเดียว
• มองต้นทุนครบกว่าเวลาเขียน code พิจารณา token, review, maintenance, security remediation และ Total Cost of Ownership

ข้อเสียและจุดเสี่ยง

• ลงทุนช่วงต้นน้ำสูง เพราะต้องทำ spec, test, eval, sandbox, hooks และ observability ก่อนจะได้ความสม่ำเสมอ
• Review อาจกลายเป็นคอขวดใหม่ เพราะAgent สร้าง PR ได้หลายชุดพร้อมกัน แต่คนยังมีเวลาอ่านเท่าเดิม
• เสี่ยงสร้างพิธีกรรมชุดใหม่ ถ้าทุกงานต้องแบกเอกสารและมี gate ตรวจนั่นนี่เหมือนกันหมด งานเล็กจะทำงานช้าลงเท่ากับงานใหญ่ โดยที่คุณภาพไม่ต่างจากเดิม
• Harness ต้องมีเจ้าของ เพราะต้องกำหนด Prompt, skill และ rule file และต้องสามารถปรับปรุงได้เรื่อยๆ เหมือน code
• ตัวเลข productivity อาจไม่เกิดกับทีมตรงๆ เพราะประโยชน์ขึ้นกับคุณภาพ codebase, test coverage, domain และวินัยเดิมของทีมที่จะนำไปใช้ต่อ

หากมองในมุมเศรษฐศาสตร์ เอกสารนี้มองการ Vibe Coding ว่ามี CapEx ต่ำ เริ่มเร็ว แต่มีโอกาสแบก OpEx สูงจาก prompt loop, token burn, maintenance และการแก้ security ภายหลัง ส่วน Agentic Engineering ลงทุนช่วงต้นน้ำมากกว่า แต่พยายามลดต้นทุนส่วนเพิ่มด้วย context ที่ดี, reusable skills, automated verification และ model routing

เทียบกับ SDLC อื่นที่ผมติดตามอยู่

ใน Second Brain ของผมมีกรอบ AI SDLC หลายแบบ พอวางข้างกันแล้วพบว่าไม่ได้แข่งกันเป็นผู้ชนะเพียงรายเดียว แต่ละแนวทางกำลังตอบคำถามคนละระดับครับ

ถ้าให้ผมจัดตำแหน่ง Google whitepaper ชิ้นนี้ มันเป็นแผนที่กลางครับ มันช่วยตั้งชื่อสิ่งที่กำลังเปลี่ยน ส่วน Spec-Driven Development ลงลึกเรื่อง contract, Anthropic ลงลึก artifact chain กับ control architecture, AWS ลงลึก collaboration loop และ McKinsey ขยายไปถึง operating model ขององค์กร

Scrum กับ Kanban ก็ไม่ได้หมดประโยชน์ เราอาจยังใช้ Sprint เพื่อกำหนด cadence หรือใช้ WIP limit เพื่อกัน agent สร้างงานเกินกำลัง review เพียงแต่ board และ ceremony ต้องรับรู้ว่า AI กลายเป็น participant ใน flow แล้ว ไม่ใช่แค่เครื่องมือ autocomplete

SDLC ใหม่ไม่ได้ลบหลักวิศวกรรมเดิม มันทำให้ spec, test, review และ governance สำคัญขึ้น เพราะความผิดพลาดถูกขยายเป็น code ได้เร็วกว่าเดิม

ถ้าจะเริ่มใช้กับทีม ควรเริ่มตรงไหน

ผมไม่แนะนำให้เริ่มด้วยการประกาศว่าเราจะ automate ทั้ง SDLC ตั้งแต่วันจันทร์ครับ แบบนั้นน่าจะได้ slide ก่อน ได้ของจริงเมื่อไรค่อยว่ากันอีกที

1. เลือกงานซ้ำที่ขอบเขตชัดหนึ่งอย่าง เช่น test generation, known bug หรือ migration เล็ก
2. เขียน `AGENTS.md` หรือไฟล์กฎให้สั้น ระบุ stack, commands, conventions และสิ่งที่ห้ามทำ
3. กำหนด acceptance criteria กับ tests ก่อนให้ agent implement
4. แยก policy ที่เป็นคำแนะนำออกจากกฎที่ต้องบังคับด้วย hooks, CI หรือ permissions
5. ให้ agent ทำงานใน sandbox หรือ branch แยก แล้วเก็บ trace กับผล test
6. ให้คน review จุดเสี่ยง โดยเฉพาะ business logic, dependency, error handling และ security
7. เก็บ failure ที่เกิดจริงกลับมาเป็น test, eval หรือ rule เพื่อไม่ให้ระบบพลาดแบบเดิมซ้ำ

เมื่อ loop เล็กนี้นิ่งแล้วค่อยขยาย autonomy จาก conductor ไปสู่ orchestrator และค่อยเพิ่มงาน parallel สิ่งที่ต้องวัดไม่ใช่จำนวนบรรทัดที่ AI เขียน แต่ควรดู lead time, rework, escaped defects, change failure rate, review time และต้นทุนรวมด้วย

บทสรุป

หลังอ่าน The New SDLC with Vibe Coding แล้ว ผมคิดว่าจุดหลักของมันไม่ใช่การเสนอ process ใหม่แบบสำเร็จรูป แต่เป็นการทำความเข้าใจว่า เรากำลังทำ Vibe Coding เพื่อทดลอง หรือกำลังทำ Agentic Engineering เพื่อส่งระบบที่คนอื่นต้องพึ่งพา

เส้นแบ่งนี้ช่วยให้เราไม่ต้องเถียงว่า Vibe Coding ดีหรือแย่ เพราะคำตอบขึ้นกับการยอมรับความหลวมได้หรือไม่ งาน production ที่แตะเงิน ข้อมูลลูกค้า หรือระบบสำคัญต้องมี spec, tests, evals, guardrails, observability และคนที่ยอมรับความเสี่ยงอย่างชัดเจน

สิ่งที่เปลี่ยนมากที่สุดจึงไม่ใช่แค่เครื่องมือ แต่เป็นงานของ Developer และหัวหน้าทีมครับ เราจะใช้เวลาน้อยลงกับการพิมพ์ implementation ซ้ำๆ แล้วใช้เวลามากขึ้นกับการกำหนด intent, จัด context, ออกแบบระบบตรวจ และตัดสินว่า output แบบไหนดีพอจะไปต่อ

Generation เริ่มกลายเป็นของที่หาได้ง่ายขึ้น แต่ Verification, Judgment และ Direction กำลังกลายเป็นฝีมือหลักของคนทำ software และผมคิดว่านี่คือประเด็นที่น่าจำที่สุดจาก whitepaper ชิ้นนี้ครับ

ผู้อ่านได้อะไรจากบทความนี้

• เห็นเส้นแบ่งชัดขึ้น ว่างานใดใช้ Vibe Coding ได้ และงานใดต้องใช้ Agentic Engineering
• เข้าใจคอขวดใหม่ เมื่อ implementation เร็วกว่า requirement, architecture และ review
• รู้ส่วนประกอบของ Context และ Harness ที่ทำให้ coding agent ทำงานได้สม่ำเสมอขึ้น
• เห็นการเปลี่ยนของแต่ละ SDLC phase พร้อมจุดที่มนุษย์ยังต้องตัดสินใจ
• เทียบกรอบจาก Second Brain ได้ ทั้ง Google, AWS, Anthropic, Spec-Driven Development, McKinsey, Scrum และ Kanban
• มีแนวทางทดลองแบบเสี่ยงต่ำ โดยเริ่มจากงานเล็ก Verification ก่อน Autonomy และเก็บ failure กลับมาปรับระบบ

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

• The New SDLC with Vibe Coding โดย Addy Osmani, Shubham Saboo และ Sokratis Kartakis
• The New Software Lifecycle โดย Addy Osmani
• AI-Driven Development Life Cycle จาก AWS
• The AI-Native SDLC playbook จาก Anthropic
• Rewiring software delivery for the agentic era จาก McKinsey & Company
• Spec-Driven Development ในยุค AI บทความที่ผมเขียนไว้ก่อนหน้า
• AI-Native SDLC มนุษย์อยู่ตรงจุดไหน และใช้ส่งต่องานกันอย่างไร บทความเปรียบเทียบ playbook ของ Anthropic
• AI เขียนโค้ดเร็วแล้ว แต่ทำไมงานยังช้าอยู่ มุมมองเรื่องคอขวดของ requirement และ workflow