Gophernment

Posted on Aug 16

จาก Vibe Coding สู่ Agentic Engineering — SDLC ใหม่ที่กำลังมาแทนที่

#ai #programming #softwaredevelopment #productivity

📅 เขียนเมื่อ: สิงหาคม 2026 | อ้างอิง: Whitepaper "The New SDLC With Vibe Coding" (พ.ค. 2026)
⚠️ ตัวเลขและเครื่องมือในบทความอาจเปลี่ยนตามเวลา

ลองนึกภาพตามนะครับ — เมื่อสิบปีก่อน ถ้าคุณจะเขียนฟีเจอร์ใหม่สักตัว คุณต้องนั่งไล่พิมพ์ syntax ให้ถูกต้องทีละบรรทัด ต้องรู้ว่าวงเล็บปิดตรงไหน semicolon อยู่ตรงไหน แล้วค่อยรันแล้วรอ error มาบอกว่าพิมพ์ผิดตรงไหนอีก

ตอนนี้ภาพนั้นกำลังหายไปเร็วมาก

มี whitepaper 51 หน้าเล่มหนึ่งชื่อ "The New SDLC With Vibe Coding" เขียนโดย Addy Osmani, Shubham Saboo และ Sokratis Kartakis ตีพิมพ์บน Kaggle เมื่อเดือนพฤษภาคม 2026 มันพูดถึงเรื่องเดียวที่กำลังเขย่าวงการนักพัฒนา — การที่เราเปลี่ยนจาก "เขียนโค้ด" เป็น "เขียนเจตนา"

ตัวเลขที่เปิดมาทีแรกก็ทำเอาสะดุ้ง: ต้นปี 2026 มีนักพัฒนามืออาชีพ 85% ที่ใช้ AI coding agent เป็นประจำ ครึ่งหนึ่งใช้ทุกวัน และประมาณ 41% ของโค้ดใหม่ทั้งหมดถูก AI เขียนขึ้นมา

แล้วถ้าอยากเห็นภาพชัดที่สุดว่า "วงจรพัฒนาซอฟต์แวร์" (SDLC) เปลี่ยนไปยังไง ดูรูปนี้เลย — ฝั่งซ้ายคือวิธีที่เราทำงานกันมานับสิบปี ฝั่งขวาคือสิ่งที่กำลังมาแทนที่:

เห็นความต่างไหมครับ — ฝั่งซ้ายมนุษย์ต้องทำทุกขั้นตอนเรียงกันไปทีละเฟส แต่ฝั่งขวาเหลือแค่สองจุดที่มนุษย์ต้องอยู่จริง ๆ คือตอน "กำหนดเจตนา" กับตอน "ตรวจสอบคุณภาพ" ส่วนตรงกลางปล่อยให้ AI วน loop ไปเองจนกว่าจะผ่าน

แต่ก่อนจะไปต่อ ผมอยากให้เราเข้าใจคำหนึ่งให้ตรงกันก่อน เพราะมันเป็นหัวใจของเรื่องทั้งหมด

"vibe coding" คำนี้มาจากไหน

เดือนกุมภาพันธ์ 2025 Andrej Karpathy เขียนบรรยายวิธีเขียนโปรแกรมแบบใหม่ที่เขาเรียกว่า vibe coding — แนวคิดคือคุณ "ยอมแพ้ต่อ vibe เต็มตัว แล้วลืมไปเลยว่าโค้ดมีอยู่จริง" คุณแค่บอกสิ่งที่อยากได้เป็นภาษาธรรมดา รับผลลัพธ์จาก AI มาใช้ และถ้ามันพังก็ copy ข้อความ error กลับไปให้ AI แก้ให้

คำนี้ระเบิดขึ้นมาทันที เพราะมันไปแตะสิ่งที่คนทำกันอยู่เงียบ ๆ มานานแต่ไม่มีคำเรียก

แต่พอมันดัง คำก็เลยถูกใช้จนความหมายเลอะเทอะ — senior engineer ที่ใช้ AI ช่วย implement ฟีเจอร์ที่ spec ครบถ้วน ก็ถูกเรียก "vibe coding" เหมือนกับคนที่ prompt มั่ว ๆ แล้วยัดโค้ดขึ้น production ไปดื้อ ๆ

จนกระทั่งต้นปี 2026 Karpathy เองออกมายอมรับว่า framing เดิมมันแคบเกินไป และแนะนำคำใหม่คือ "agentic engineering" สำหรับปลายทางสายที่มีวินัยมากกว่า

เส้นแบ่งจริง ๆ ไม่ใช่ "ใช้ AI หรือไม่" แต่อยู่ที่ "ตรวจสอบแค่ไหน"

นี่คือประเด็นที่สำคัญที่สุดของ whitepaper — vibe coding กับ agentic engineering ไม่ใช่สองสิ่งที่แยกขาดจากกัน แต่อยู่บนเส้นเดียวกัน (spectrum) และสิ่งที่แยกสองปลายออกจากกันไม่ใช่เรื่องว่าใช้ AI หรือเปล่า แต่เป็นเรื่องว่าเราตรวจสอบผลลัพธ์จาก AI มากแค่ไหน

ลองไล่ดูทีละมิติ:

การระบุเจตนา — ฝั่ง vibe coding คือพิมพ์ prompt สบาย ๆ ไม่คิดเยอะ ฝั่ง agentic engineering คือมี spec, architecture doc และ memory file ครบถ้วน
การตรวจสอบ — ฝั่งหนึ่งคือ "เอ๊ะ มันดูใช้ได้มั้ง" อีกฝั่งคือมี test suite, CI/CD gate และ LM judge คอยตรวจ
การแก้ error — ฝั่งหนึ่ง copy error กลับไปให้ AI เฉย ๆ อีกฝั่งคือคนหาต้นตอให้เจอก่อน แล้วให้ AI implement ฟิกซ์

หัวใจจริง ๆ อยู่ที่กลไกตรวจสอบสองตัวที่ทำงานคู่กัน: tests ตรวจส่วนที่ "กำหนดได้" (ฟังก์ชันรับ input นี้ต้องคืน output นั้น) ส่วน evals ตรวจส่วนที่ "กำหนดไม่ได้" (agent เลือกเส้นทางถูกไหม ใช้ tool ถูกไหม ผลลัพธ์ถึงมาตรฐานไหม)

whitepaper พูดตรง ๆ ว่า ถ้าไม่มีทั้ง tests และ evals — ต่อให้ prompt เก่งแค่ไหน มันก็ยังเป็น vibe coding อยู่ดี

แล้วเราควรยืนตรงไหนของเส้นนี้? คำตอบคือขึ้นกับ "เดิมพัน" ของงาน — prototype ในวันหยุดก็ vibe coding ได้เต็มที่ แต่ API ที่คุมธุรกรรมการเงินต้อง agentic engineering เท่านั้น งานจริงส่วนใหญ่อยู่ตรงกลาง และทักษะที่แท้จริงคือรู้ว่าจะขีดเส้นตรงไหนของแต่ละงาน

ทักษะที่แท้จริงไม่ใช่ "prompt" แต่เป็น "context"

มี insight หนึ่งที่ whitepaper ย้ำหลายรอบ และผมว่ามันคือของขวัญที่ดีที่สุดในเล่ม: คุณภาพของโค้ดจาก AI ไม่ได้ขึ้นกับความฉลาดของ prompt แต่อยู่ที่คุณภาพของ context ที่เราป้อนให้มัน

นี่คือที่มาของคำว่า context engineering

ลองคิดแบบนี้ — ถ้าคุณจะให้สมาชิกใหม่มาช่วยเขียนโค้ดในโปรเจกต์ คุณจะไม่ยัดทุกอย่างให้เขารู้ในประโยคเดียว แต่คุณจะให้เขาอ่าน documentation ดู diagram รู้จัก convention ของทีม แล้วค่อยลงมือ

กับ AI ก็เหมือนกัน มันไม่ได้ต้องการ "คำสั่งที่แต่งมาฉลาด ๆ" แต่มันต้องการ context แบบเดียวกับที่มนุษย์เก่ง ๆ ต้องการถึงจะทำงานดีได้

context พวกนี้แบ่งเป็นสองชั้นที่สำคัญ:

Static context — โหลดตลอดเวลา เช่น AGENTS.md, CLAUDE.md, memory ของโปรเจกต์ มันแพง เพราะทุก token อยู่ในทุก interaction ไม่ว่าจำเป็นหรือไม่
Dynamic context — โหลดเฉพาะเมื่อต้องการ เช่น skill ที่ถูกเรียกเมื่อ task ตรง, เอกสารที่ดึงจาก RAG, ประวัติ session มันประหยัด เพราะจ่าย token เฉพาะตอนใช้

และกุญแจที่ทำให้จัดการสองชั้นนี้ได้คือ Agent Skills — แพ็กเกจความรู้ที่ agent โหลดเฉพาะเมื่องานเรียกใช้ แทนที่จะยัดทุกอย่างลง system prompt ตั้งแต่วินาทีแรก

ประโยคที่ผมชอบที่สุดในหัวข้อนี้คือ:

คำถามไม่ใช่ "จะหลอก AI ให้เขียนโค้ดดี ๆ ได้ยังไง" แต่อยู่ที่ "ถ้าจะมีสมาชิกใหม่มาช่วยงาน เขาต้องรู้อะไรบ้าง แล้วเราจะ encode ความรู้นั้นให้ AI ใช้ยังไง"

model ไม่ใช่ทุกอย่าง — แนวคิด Harness ที่คนส่วนใหญ่เข้าใจผิด

ตอนนี้ขอเปลี่ยนจังหวะหน่อย เพราะส่วนถัดไปคือจุดที่ผมเห็นคนเข้าใจผิดกันเยอะที่สุด

เวลาคนใช้ AI coding agent แล้วผลออกมาแย่ สัญชาตญาณแรกของเราคือโทษ model — "model นี้โง่" "รุ่นใหม่ยังไม่เก่ง" แต่ whitepaper บอกว่านั่นคือ intuition ที่ผิด และมันพาเราลงทุนผิดทาง

ความจริงคือ model เป็นแค่ "เครื่องยนต์" ตัวเดียวในโรงงาน — เครื่องยนต์อย่างเดียวผลิตรถออกมาไม่ได้ ต้องมีสายพาน เฟือง และเซนเซอร์ความปลอดภัยคอยประกอบ

สิ่งที่ห่อหุ้ม model อยู่รอบ ๆ — prompt, tools, sandbox, sub-agent, observability, guardrails — เรียกรวมว่า Harness

Agent = Model + Harness

หลักฐานที่ทำให้เรื่องนี้จับต้องได้จริง:

บน Terminal Bench 2.0 มีทีมหนึ่งดัน coding agent จากนอก Top 30 ขึ้นไป Top 5 ได้ โดยเปลี่ยนแค่ harness อย่างเดียว — ไม่เปลี่ยน model เลยแม้แต่ตัวเดียว
งานวิจัยของ LangChain ยกคะแนน agent บน benchmark เดียวกันขึ้น 13.7 คะแนน ด้วยการปรับแค่ system prompt, tools และ middleware รอบ model ที่ fixed ไว้

สรุปเป็นประโยคที่ควรแปะไว้หน้ามอนิเตอร์: เมื่อ agent ทำพลาด อย่าเพิ่งโทษ model — ความจริงส่วนใหญ่คือ configuration ที่พลาด ไม่ว่า tool จะหายไป กฎคลุมเครือ guardrail ไม่มี หรือ context เต็มไปด้วย noise

ปัญหา 80% — ทำไม AI ยังแทนเราไม่ได้ (และก็ไม่ควร)

แล้วทำไมเราถึงยังต้องการคนอยู่ตรงกลาง? whitepaper เรียกมันว่า "80% problem" — AI สร้างโค้ด 80% แรกของฟีเจอร์ได้เร็วมาก แต่ 20% ที่เหลือ ทั้ง edge case, error handling, จุด integration และ requirement ละเอียดอ่อน ต้องอาศัยความรู้เชิงลึกที่ model ยังไม่มี

และที่น่ากังวลกว่าคือ nature ของ error มันเปลี่ยนไปแล้ว — จาก "พิมพ์ syntax ผิด" กลายเป็น "เข้าใจ business logic ผิด", "ไม่ถามตอน requirement คลุมเครือ", "พลาด edge case" หรือ "ตัดสินใจ architecture ที่สร้างหนี้ระยะยาว" ซึ่งตรวจจับยากมากเพราะโค้ดมันดูถูก และอาจผ่าน test พื้นฐานด้วยซ้ำ

ตัวเลขที่หลายคนชอบอ้างว่า AI ทำให้เร็วขึ้น 25–39% ก็ต้องอ่านให้ละเอียด — งานวิจัยของ METR พบว่านักพัฒนาที่มีประสบการณ์ใช้ AI แล้วช้าลง 19% ในงานบางประเภท เพราะเวลาโดนกลืนไปกับการตรวจ แก้ และไล่บั๊กโค้ดที่ AI สร้าง

คนที่ใช้ AI ได้เก่งที่สุดจึงไม่ใช่คนที่รับทุกอย่างที่ AI ยื่นให้ แต่คือคนที่รู้ว่าเมื่อไหร่ควรให้ AI ทำ (งานที่ spec ชัด) และเมื่อไหร่ควรเก็บสมาธิของตัวเองไว้ (requirement คลุมเครือ, trade-off ทาง architecture, การ verify ความถูกต้อง)

เงินที่ซ่อนอยู่ใต้ vibe coding

ส่วนนี้สำคัญเป็นพิเศษสำหรับคนที่ต้องตัดสินใจในระดับทีมหรือองค์กร เพราะมันเปลี่ยนมุมมองจาก "เขียนได้เร็วแค่ไหน" เป็น "ต้นทุนรวมเท่าไหร่"

vibe coding ดูถูกมากตอนเริ่ม — จ่าย subscription เดือนละไม่กี่ร้อย แล้ว prompt ไปเรื่อย ๆ แต่ whitepaper ชี้ให้เห็นว่ามันมี OpEx ที่แฝงตัวและทบต้นอยู่สามก้อน:

Token burn — ยัดไฟล์ก้อนใหญ่แบบไม่มีโครงสร้างเข้า context แล้วให้ AI แก้ผิดซ้ำไปมา วน prompt เผา token เปลือง ๆ
Maintenance tax — โค้ดที่เกิดจาก prompt มั่ว ๆ ไม่มีโครงสร้าง พอบั๊กโผล่ทีหลัง 6 เดือน คนต้องนั่ง reverse-engineer "โค้ดสปาเก็ตตี้" กันเป็นวัน ๆ
Security remediation — ไม่มี eval harness คุม = สร้างโค้ดเร็ว = สร้างช่องโหว่เร็ว และค่าแก้ช่องโหว่ใน production แพงกว่าตอน design เป็นทวีคูณ

ฝั่ง agentic engineering กลับกัน — จ่าย upfront กับการออกแบบ API schema, เขียน test suite, จัดโครงสร้าง context ให้ดีตั้งแต่แรก ซึ่งแพงกว่าในตอนเริ่ม แต่ marginal cost ต่อฟีเจอร์ถัด ๆ ไปลดฮวบ เพราะ AI ทำงานอยู่ใน "โรงงาน" ที่มีกฎคุม output เลยมีโครงสร้าง ผ่าน test และตรง standard

ส่วน context engineering เองก็กลายเป็นกลยุทธ์การเงินไปโดยปริยาย — LLM คิดเงินทุก token ที่เราส่งไป การยัด repo 100,000 token เข้าทุก prompt คือการเผาเงินแบบไม่จำเป็น และทางแก้คือ intelligent model routing: ใช้ model ใหญ่แพงกับงานที่ซับซ้อน แต่ route งานง่าย ๆ (generate test, code review, CI/CD) ไปให้ model เล็กที่ถูกกว่ามาก

แล้วควรเริ่มยังไง

whitepaper ปิดท้ายด้วย checklist ที่เอาไปใช้ได้จริง ผมสรุปเฉพาะตัวที่คิดว่าสำคัญสุดมาให้

ถ้าคุณเป็น developer เริ่มจากสามอย่างนี้พอ:

ตั้ง AGENTS.md ให้โปรเจกต์ — เริ่มจากสิบบรรทัด: stack, convention, กฎตายตัว, workflow แล้วค่อยเพิ่มกฎทุกครั้งที่ agent ทำสิ่งที่ไม่อยากให้ทำซ้ำ
เขียน tests + evals ก่อน generate โค้ด — มันคือ "สัญญา" กับ AI สื่อเจตนาได้แม่นกว่า prompt ไหน ๆ
review ทุกบรรทัดที่จะ ship — ระแวงโค้ดที่ "ฉลาดเกินไป" เช็ค import ว่าเป็นแพ็กเกจจริง ตรวจ error handling ให้ครบ

ถ้าคุณเป็น leader เรื่องสำคัญสุดคือการยกระดับมาตรฐานของทีม:

ทำให้ context engineering เป็น practice ระดับทีม — AGENTS.md, system prompt และ eval suite ต้องถูก review ใน PR, version กับโปรเจกต์ และมีคนรับผิดชอบชัดเจน
ตั้งมาตรฐานที่ "eval" ไม่ใช่ "demo" — demo ผ่านแค่แปลว่าทำสำเร็จครั้งเดียว แต่ eval ผ่านแปลว่าทำสำเร็จทุกครั้ง

ทิ้งท้าย

ถ้าจะย่อ 51 หน้าให้เหลือบรรทัดเดียว ผมขอสรุปแบบนี้:

เราไม่ได้เลิกเขียนโค้ด — เราแค่เปลี่ยนจาก "เขียน syntax" เป็น "เขียนเจตนา" แล้วปล่อยให้เครื่องจักรรับผิดชอบการ implement ส่วนมนุษย์เก็บงานที่เหลือไว้: การตัดสินใจ รสนิยม และการตรวจว่าของที่ออกมาดีจริง

และจุดแบ่งระหว่าง vibe coding ที่น่ากลัว กับ agentic engineering ที่เชื่อถือได้ ไม่ได้อยู่ที่ tool ที่เราเลือกใช้ แต่อยู่ที่ ว่าเราตั้ง harness รอบ ๆ AI ไว้แน่นแค่ไหน

📚 อ้างอิง: The New SDLC With Vibe Coding — Addy Osmani, Shubham Saboo, Sokratis Kartakis (Kaggle, พฤษภาคม 2026)
🔗 อ่านต้นฉบับ: https://www.kaggle.com/whitepaper-the-new-SDLC-with-vibe-coding

DEV Community