ผมไปเจอ 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

ตอนแรกผมใช้ AI เขียนโปรแกรมด้วยตัวเองเป็นหลัก เพราะผมเป็น programmer อยู่แล้ว จึงรู้ว่าต้องสั่งอะไร ต้องดู code ตรงไหน และควรสงสัยผลลัพธ์เมื่อไร แต่ระยะหลัง เจ้านาย น้องในทีม และเพื่อนร่วมงานที่ไม่ได้ทำหน้าที่ programmer โดยตรง เริ่มทำ prototype ออกมาเอง บางคนไปไกลถึงขั้นสร้างโปรแกรมที่ใช้งานได้ แล้วค่อยเรียก programmer เข้าไปช่วยเฉพาะจุด

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

หมายเหตุ: เอเจ้นชมพูช่วยถอดความและเรียบเรียงจากประสบการณ์กับมุมมองที่ฟิวส์เล่าอย่างละเอียด

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

• AI เร่งการเขียน code แต่ไม่ได้ทำให้การค้นหาและถ่ายทอดความต้องการเร็วขึ้นโดยอัตโนมัติ
• คนทำ software เริ่มแยกได้ 5 กลุ่ม ตามระยะห่างระหว่างคนที่มีความต้องการกับคนที่ลงมือสร้าง
• Prototype ที่ใช้งานได้จริง สื่อสารได้ชัดกว่า requirement หรือ wireframe ที่ยังต้องตีความอีกหลายทอด
• Programmer จะขยับเข้าใกล้บทบาท consultant มากขึ้น โดยช่วยเรื่อง architecture, integration, security และ production readiness
• อนาคตอาจเหลือ workflow เด่นเพียง 2 แบบ คือ user สร้างเองโดยมี programmer ช่วยไกด์ กับ user ทำของที่ชัดแล้วส่งให้ programmer ทำต่อ

ผมเห็นคนสร้าง software อยู่ประมาณ 5 กลุ่ม

ถ้าแบ่งแบบหยาบๆ จากคนที่ผมเจอ ผมคิดว่าตอนนี้มีอยู่ประมาณ 5 กลุ่มครับ เส้นแบ่งของแต่ละกลุ่มไม่ได้อยู่ที่ว่าใครใช้ AI รุ่นไหน แต่อยู่ที่ว่าใครเป็นคนถือความต้องการ และใครเป็นคนแปลงมันให้กลายเป็นของที่ใช้ได้จริง

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

กลุ่มที่สองกลับยากกว่าที่หลายคนคิด แม้ programmer จะใช้ AI เขียน code ได้เร็ว แต่กว่าจะรู้ว่าคนขออยากได้อะไรจริงๆ ยังต้องประชุม ถามกลับ เขียน requirement แตกเป็น function แล้วแปลงต่อเป็น technical spec กว่าจะเริ่มเขียนได้ เครื่องมือเร็วขึ้น แต่รถยังติดอยู่หน้าด่านเดิมครับ

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

Prototype เปลี่ยนการคุยจากคำอธิบายเป็นของที่มองเห็น

กลุ่มที่สามคือ user ทำ prototype แล้วส่งให้ programmer ทำต่อ แบบนี้เร็วขึ้นกว่าส่ง requirement หรือ wireframe อย่างเดียวเยอะครับ เพราะ programmer เห็นหน้าจอ เห็น flow และเห็นว่าคนขอพยายามแก้ปัญหาอะไรอยู่

แต่ prototype ก็ยังมีช่องว่างของมัน หน้าจอที่กดได้อาจบอกว่า user ต้องการอะไรเมื่อทุกอย่างปกติ แต่ไม่ได้บอกเสมอว่าถ้าข้อมูลผิดจะทำอย่างไร ใครมีสิทธิ์เห็นอะไร ระบบเดิมต้องเชื่อมแบบไหน หรือข้อมูลต้องถูกเก็บนานแค่ไหน หน้าตาชัดไม่ได้แปลว่า behavior ข้างในชัดครบครับ

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

Prototype ที่ดีไม่ได้กำจัด requirement แต่มันลดพื้นที่ที่แต่ละคนต้องจินตนาการไม่เหมือนกัน

เมื่อ user ลงมือสร้างเอง Programmer จึงกลายเป็นที่ปรึกษา

กลุ่มที่สี่น่าสนใจมากครับ User มี prototype หรือระบบที่ทำงานได้ประมาณหนึ่งแล้ว จากนั้นให้ programmer เข้าไปเป็น consultant ช่วยดูว่าส่วนไหนควรแก้ ควรต่อกับระบบเดิมอย่างไร หรือมีความเสี่ยงอะไรที่ยังมองไม่เห็น

ผมเห็นเพื่อนร่วมงานชาวต่างชาติคนหนึ่งทำแบบนี้ เขาไม่ได้เริ่มจากพื้นฐาน programmer เต็มตัว แต่เป็นคนเรียนรู้เร็ว ชอบศึกษา และมีความสามารถในการตั้งคำถาม เขาสร้างของออกมาได้ระดับหนึ่งแล้วมาปรึกษา programmer เพิ่มอีกไม่มาก จากนั้นก็กลับไปต่อยอดสิ่งที่ตัวเองต้องการได้

ลักษณะนี้ใกล้กับการมี programmer ยืนอยู่ข้างๆ มากกว่านั่งรอรับเอกสารปลายทาง บทบาทของ programmer จึงไม่ใช่คนพิมพ์ code ตามแบบ แต่เป็นคนช่วยชี้ blind spot ตั้งคำถามเรื่อง architecture, data, security และช่วยตรวจว่าของที่วิ่งได้บนเครื่อง จะไปต่อใน production ได้หรือไม่

มันมีส่วนคล้ายแนวทางของ Forward Deployed Engineer (FDE) ซึ่งเป็น engineer ที่เข้าไปทำงานใกล้กับผู้ใช้หรือทีมลูกค้า ช่วยค้นหาความต้องการ สร้าง prototype ปรับระบบ และนำไปใช้ในสภาพแวดล้อมจริง แทนที่จะรับ spec แล้วหายกลับไปเขียนอยู่คนเดียว คำอธิบายบทบาท FDE จาก DataCamp

User เขียนโปรแกรมเองได้ ทำไมถึงเร็วที่สุด

กลุ่มที่ห้าคือ user สร้างโปรแกรมเอง เขารู้ปัญหา รู้ว่าต้องการอะไร และสั่ง coding agent ให้ช่วยสร้างสิ่งนั้นได้โดยตรง ระยะทางจากความคิดไปถึงของที่กดได้จึงสั้นมาก ไม่ต้องผ่านคนกลางหลายทอด

เจ้านายผมเป็นอดีต programmer พอได้รื้อฟื้นพื้นฐานเดิมร่วมกับ AI เขาก็ไปต่อได้เร็ว เพราะยังมี foundation พอจะเข้าใจว่า code, database, API และ flow ของระบบเกี่ยวกันอย่างไร เขาอาจจำ syntax ไม่ครบ แต่ syntax กลายเป็นเรื่องที่ AI ช่วยได้แล้ว

ตรงนี้มีเงื่อนไขสำคัญครับ User ที่สร้างเองได้เร็ว ไม่ได้แปลว่าไม่ต้องรู้อะไรเลย อย่างน้อยต้องมีพื้นฐานทาง programming หรือมีความสามารถพอจะตรวจสอบ ตั้งคำถาม และรู้ว่าเมื่อไรควรเรียกคนที่มีประสบการณ์เข้ามาช่วย ไม่อย่างนั้นความเร็วอาจพาไปถึงของที่ดูเหมือนใช้ได้ แต่มีปัญหาอยู่ข้างในแบบที่เจ้าตัวไม่รู้

วันหนึ่ง คนที่ทำโปรแกรมได้ดีที่สุดอาจจะไม่ใช่มาจากโปรแกรมเมอร์ที่เก่งที่สุด แต่จะเป็น User ที่ใช้เอไอเขียนโปรแกรมได้เองตามที่ธุรกิจต้องการ

ทำไมมี AI แล้ว process เดิมยังช้า

ในกระบวนการพัฒนา software แบบเดิม ความต้องการจาก user มักต้องผ่าน Product Owner, Business Analyst, System Analyst หรือตำแหน่งอื่นตามโครงสร้างของแต่ละองค์กร คนเหล่านี้ช่วยแปลง idea ให้เป็น requirement, function, design และเอกสารที่ programmer ใช้ทำงานต่อ

จากนั้น requirement ยังอาจต้องถูกแปลงอีกรอบเป็น technical spec, API contract, application design, data model และงานย่อยต่างๆ แต่ละทอดมีทั้งเวลารอ เวลาคุย และความหมายบางส่วนที่อาจหายระหว่างทาง เหมือนเกมกระซิบที่ทุกคนตั้งใจดี แต่ประโยคปลายทางไม่เหมือนต้นทางเสียทีเดียว

ถ้า workflow ยังเป็น user อธิบายให้คนกลาง คนกลางเขียนเอกสาร แล้ว programmer เอาเอกสารไปสั่ง AI ความเร็วจะเพิ่มชัดเจนเฉพาะช่วงเขียน code ครับ ช่วงคิด ตัดสินใจ ขอข้อมูล ทำ spec และรอความเห็นยังใช้เวลาใกล้เคียงเดิม

AI อาจช่วยเขียนเอกสารให้ละเอียดขึ้น แต่เอกสารเยอะไม่ได้รับประกันว่าคนจะอ่านครบ สุดท้าย programmer อาจใช้ AI อ่านเอกสารอีกที ถ้าเอกสารต้นทางสื่อความต้องการผิด AI ก็เพียงช่วยอ่านความเข้าใจผิดนั้นให้เร็วขึ้น แล้วผลิตของที่ไม่ตรงเร็วขึ้นตามไปด้วย เจ็บปวดแบบประสิทธิภาพสูง ฮาาา

ถ้าความเข้าใจต้นทางผิด AI จะไม่ได้แก้ปัญหาให้เรา มันอาจช่วยขยายความผิดนั้นให้กลายเป็นระบบได้เร็วกว่าเดิม

อนาคตอาจเหลือ workflow หลักอยู่ 2 แบบ

จากสิ่งที่ผมเห็นภายในเวลาไม่ถึงปี ผมคิดว่า 5 กลุ่มนี้จะค่อยๆ ขยับเข้าหากัน และเหลือ workflow เด่นอยู่ประมาณ 2 แบบครับ

แบบแรก User สร้างเอง แล้วให้ Programmer ช่วยไกด์

User ใช้ AI ทำ prototype หรือระบบที่ทำงานได้เอง ส่วน programmer เข้ามาช่วย review, consult และจัดการเรื่องที่ต้องใช้ความรู้ลึก วิธีนี้ทำให้คนที่รู้ความต้องการที่สุดได้ทดลองของเร็ว และยังมีคนช่วยกันไม่ให้ prototype หลุดไปเป็น production แบบไม่มีรั้ว

แบบที่สอง User ทำ Prototype ที่ชัด แล้วให้ Programmer ทำต่อ

User ไม่จำเป็นต้องเขียนระบบจนเสร็จ แต่ควรนำความต้องการไปให้ไกลกว่าคำอธิบาย ทำ flow, UI และ behavior หลักให้เห็นจริง จากนั้น programmer เข้าไปประกบและทำให้เป็นระบบที่ใช้งานได้ วิธีนี้คล้ายการทำงานแบบ FDE ในมุมที่ engineer อยู่ใกล้ปัญหาและ feedback มากขึ้น

สองแบบนี้ลดจำนวนครั้งที่ความต้องการต้องถูกแปลครับ จากประสบการณ์การคุมงาน วางแผน และทำ project management ของผม ผมเชื่อว่ามันทำให้การพัฒนาเร็วกว่า process เดิมได้มาก และในบางกรณีอาจเกินเท่าตัว แต่ตัวเลขนี้เป็นข้อสังเกตจากงานที่ผมเห็น ไม่ใช่ benchmark ที่ใช้แทนทุกทีม

บทสรุป

สิ่งที่ผมตกผลึกวันนี้คือ AI ไม่ได้ทำให้คอขวดของการพัฒนา software หายไปครับ มันย้ายคอขวดจากการพิมพ์ code ไปอยู่ที่การรู้ความต้องการ การอธิบายให้ชัด และการตรวจว่าสิ่งที่สร้างตรงกับปัญหาจริงหรือไม่

เมื่อก่อนคนที่มี idea ต้องรอให้หลายบทบาทช่วยแปล idea นั้นจน programmer เริ่มลงมือได้ วันนี้ user สามารถใช้ AI ทำให้ความคิดกลายเป็นของที่เห็นและทดลองได้เร็วขึ้น ระยะห่างระหว่างคนที่เจอปัญหากับคนที่สร้างคำตอบกำลังสั้นลงมาก

ผมไม่ได้คิดว่า programmer จะหายไป แต่ตำแหน่งของ programmer ใน workflow จะเปลี่ยน จากคนที่รอรับ requirement ปลายทาง ไปเป็นคนที่เข้าใกล้ user มากขึ้น ช่วยถาม ช่วยไกด์ ช่วยตรวจ และจัดการส่วนที่ความเร็วอย่างเดียวเอาไม่อยู่

สุดท้ายทีมที่ได้ประโยชน์จาก AI มากที่สุดอาจไม่ใช่ทีมที่ generate code ได้เยอะที่สุด แต่เป็นทีมที่ลดจำนวนครั้งของการแปลความต้องการลงได้มากที่สุดครับ

คนนี้ว่างเสาร์ อีกคนว่างอาทิตย์ คนนั้นว่างแค่ช่วงเย็น แฟนอีกคนอ่านแล้วลืมตอบ สุดท้ายต้องมีใครสักคนรับบทเป็นเลขากลุ่ม ไล่ถาม ไถอ่าน คอยสรุป แล้วก็วนกลับมาถามซ้ำอีกทีว่า “ตกลงเอาวันไหนดี!” ฮ่าๆ

ผมเลยทำเว็บเล็กๆ ชื่อ มาตามนัด (MaTamNud) ไว้ช่วยแก้ปัญหานี้แหละ (ใครอยู่ Gen Y คงคุ้นชื่อนี้ ฮ่าๆ) ไอเดียตรงไปตรงมาครับ แทนที่จะไล่ถามทีละคน ก็สร้างนัด แชร์ลิงก์ แล้วให้ทุกคนโหวตวันหรือช่วงเวลาที่ตัวเองว่าง จากนั้นค่อยดูพร้อมกันว่าวันไหนเวลาตรงกันที่สุด ไม่ต้องถาม ไม่ต้องย้อนแชตรวบรวมเพื่อมาสรุป ใครไม่ตอบ ก็ไม่มีชื่ออยู่ในนั้นแหละ ประจานกันไปเงียบๆ

หากอยากลองเล่นเลย กดที่นี่ 👉 https://tamnud.com/

• ใช้ฟรี (ขี้เกียจทำระบบเก็บตัง)
• สร้างนัดแล้วแชร์ลิงก์ได้เลย
• ใช้โหวตเป็นช่วงวันว่าง หรือโหวตเป็นเวลาก็ได้
• เหมาะกับนัดกิน นัดเที่ยว ปาร์ตี้ สังสรรค์ จัดทริป หรือกิจกรรมกลุ่ม
• ไม่เก็บข้อมูลใดๆ ใน Server ทั้งสิ้น (มีเก็บ profile ในอุปกรณ์ของผู้ใช้เท่านั้น เพื่อยืนยันว่าเป็นคนดีคนเดิม คนโหวตหรือคนสร้างนัด)

อ่ะ ใครอยากรู้รายละเอียดเพิ่มเติม ก็ไปอ่านกันต่อ…

เลือกได้ทั้งนัดเป็นวัน และนัดเป็นเวลา

จุดที่ผมอยากให้มีตั้งแต่แรกคือ ระบบไม่ควรจำกัดแค่การโหวต “วัน” อย่างเดียว เพราะในชีวิตจริง หลายครั้งวันเดียวกันแต่ว่างคนละช่วงเวลาก็มี

MaTamNud เลยมีประเภทนัดให้เลือก 2 แบบ

• นัดเป็นวัน เหมาะกับการเลือกวันแบบกว้างๆ เช่น เสาร์นี้ อาทิตย์หน้า หรือวันหยุดยาว
• นัดเป็นเวลา เหมาะกับนัดที่ต้องรู้ช่วงเวลาชัด เช่น 18:00, 19:30 หรือหลายช่วงเวลาในวันเดียวกัน

ในหน้า create นัด จะมีปฏิทินให้เลือกวัน และถ้าเลือกนัดเป็นเวลา ก็จะมีช่องเลือกเวลาเป็นชั่วโมงและนาที พร้อมปุ่มเพิ่มเวลาได้ ผมว่าอันนี้สำคัญ เพราะหลายงานไม่ได้ต้องการแค่ “วันไหนว่าง” แต่ต้องการรู้ว่า “ช่วงไหนที่ทุกคนชนกันน้อยที่สุด”

วิธีใช้งานแบบเร็วๆ

1. เข้าเว็บ tamnud.com
2. กด สร้างนัดหมาย
3. เลือกประเภทนัดว่าจะเป็นวันหรือเป็นเวลา
4. ใส่ชื่อนัด เช่น “กินข้าววันเกิด”, “ทริปเขาใหญ่”, “ดริ๊งที่อารีย์”
5. เลือกวันหรือช่วงเวลาที่อยากเสนอ
6. ตั้งค่าที่จำเป็น เช่น จำกัดจำนวนคน, ให้เพื่อนเสนอเวลาเองได้, กำหนดปิดโหวต หรือ timezone
7. แชร์ลิงก์หรือรหัสนัดหมายให้เพื่อน
8. ทุกคนเข้ามาโหวต แล้วผู้สร้างนัดค่อยเคาะวันที่ว่างตรงกันมากที่สุด

ฟีเจอร์เล็กๆ ที่ทำให้ใช้กับชีวิตจริงได้

จากที่ลองดูหน้าเว็บและ flow การสร้างนัด มีรายละเอียดบางอย่างที่ผมคิดว่าเหมาะกับการใช้งานจริงมาก

เหมาะกับใครบ้าง

ผมว่า MaTamNud เหมาะกับกลุ่มที่มีปัญหาแบบนี้ครับ

• กลุ่มเพื่อนที่นัดกินข้าวบ่อย ไม่ต้องไล่ถามทีละคนว่าวันไหนว่าง
• แก๊งเที่ยวหรือเดินทาง เลือกวันจัดทริปได้ง่ายขึ้น
• กลุ่มปาร์ตี้หรือสังสรรค์ เห็นวันว่างร่วมกันก่อนจองร้าน
• ทีมงานเล็กๆ ใช้หาช่วงประชุมแบบไม่ต้องเปิด calendar ซับซ้อน
• ครอบครัวหรือญาติๆ เวลานัดกินข้าว นัดรวมตัว หรือไปทำธุระด้วยกัน

โดยเฉพาะกลุ่มที่ไม่ได้อยู่ในระบบ calendar เดียวกัน เช่น เพื่อนคนละบริษัท ญาติคนละบ้าน หรือกลุ่มทริปที่มีคนใช้คนละ platform แบบนี้การส่งลิงก์โหวตง่ายๆ มัก practical กว่ามาก

ต่างจากการถามในแชตยังไง

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

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

สุดท้าย ในฐานะคนทำ

เหมือนตอนที่ผมทำ Kaiten Share Calculator เพื่อแก้ปัญหาแยกบิลซูชิสายพาน ตัวระบบไม่ได้ซับซ้อนมาก แต่ตอบโจทย์สถานการณ์ที่เจอบ่อยจริงๆ และสะท้อนออกมาจากเพื่อนๆใน Internet เข้ามามากกว่าวันละ 500 page views

MaTamNud ก็คล้ายกันครับ ผมไม่พยายามให้มันเป็น calendar หรือระบบ event ใหญ่โต อยากทำเล็กๆ ง่ายๆ แก้ปัญหาเฉพาะจุด คือ “ช่วยให้กลุ่มเห็นวันว่างร่วมกันเร็วขึ้น” ช่วยลดเวลาคุยวนๆ เรื่องวันนัด ซึ่งเป็นปัญหาที่หลายคนเจอแต่ปล่อยให้กลายเป็นความวุ่นวายประจำกลุ่ม