🛑 จาก Waterfall ถึง Vibe Coding…
(ทำไมเครื่องมือยิ่งฉลาด แต่ทีม Software ยังสร้าง “กองขยะ” ได้เร็วกว่าเดิม?)
ปัญหาอาจไม่ใช่ว่าเราเลือก Waterfall, Agile หรือ AI ผิด แต่คือทุกยุคเราชอบเอา “วิธีทำงาน” ไปแทน “การคิด” จน Demo เร็วขึ้น แต่ Outcome ไม่ได้ดีขึ้นตาม?
ผมเห็นภาพหนึ่งแล้วขำครับ (ภาพตามที่แนบ)
* แถวแรกเขียนว่า Waterfall เริ่มจากล้อ เพลา ตัวถัง แล้วค่อยประกอบจนกลายเป็นรถยนต์ตอนสุดท้าย แถวถัดมาคือ Agile เริ่มจาก Skateboard แล้วค่อยๆ กลายเป็น Scooter จักรยาน มอเตอร์ไซค์ จนเป็นรถยนต์ ทุกช่วงอย่างน้อยยังมีอะไรให้ลูกค้าใช้เดินทางได้
* พอมาถึง AI ภาพเริ่มเพี้ยนไปอีกแบบ ส่วนแถวสุดท้ายที่เขียนว่า Vibe Coding เริ่มจากรถยนต์ดีๆ หนึ่งคัน แล้วค่อยๆ มีของพอกเพิ่มขึ้นเรื่อยๆ จนสุดท้ายดูคล้ายกองอุปกรณ์ที่ไม่มีใครแน่ใจแล้วว่าข้างในยังมีรถอยู่หรือเปล่า
แน่นอนครับ ภาพนี้เป็น Meme ไม่ใช่ตำรา Software Engineering แต่ผมว่ามันจับความจริงบางอย่างของวงการ Software ได้เจ็บพอสมควร
เราเปลี่ยนเครื่องมือมาเรื่อยๆ แต่ความสามารถของมนุษย์ในการเปลี่ยน “เครื่องมือ” ให้กลายเป็น “ศาสนา” ไม่เคยหายไปไหนเลย
เมื่อก่อนเชื่อว่า Plan ละเอียดพอแล้วทุกอย่างจะราบรื่น ต่อมาเชื่อว่ามี Sprint, Daily และ Jira แล้วเราจะ Agile วันนี้บางทีมเริ่มเชื่อว่าแค่มี AI Agent หรือ Coding Assistant ก็สามารถข้าม Engineering Discipline หลายอย่างไปได้เลย
คำถามจึงอาจไม่ใช่อีกแล้วว่า “Waterfall, Agile หรือ AI อะไรดีที่สุด?” แต่คือ
“ทีมเรายังใช้หลักการเพื่อแก้ปัญหาอยู่ หรือกำลังทำพิธีกรรมตามแฟชั่นของยุคนั้น?”
⸻
🌊 Waterfall ไม่ได้ผิดเพราะมีแผน แต่ผิดเมื่อ “แผน” สำคัญกว่าความจริงที่เพิ่งเรียนรู้
ผมคิดว่าเวลาพูดถึง Waterfall เรามักล้อกันง่ายไปหน่อยครับ
การวางแผนไม่ใช่เรื่องผิด Requirement ไม่ใช่สิ่งชั่วร้าย และบางระบบโดยเฉพาะงานที่มี Dependency, Compliance หรือ Physical Constraint สูง ก็ต้องคิดล่วงหน้ามากกว่าการบอกว่า “เดี๋ยว Sprint หน้าเรียนรู้กัน”
ปัญหาเกิดขึ้นเมื่อ Sequence กลายเป็นสิ่งศักดิ์สิทธิ์จน Feedback เปลี่ยนอะไรไม่ได้
ทีมใช้เวลาหลายเดือนเขียน Specification อย่างละเอียด Business เซ็นแล้ว IT เซ็นแล้ว Vendor เซ็นแล้ว ทุกอย่างดูเรียบร้อยมาก กระทั่งวันหนึ่ง User ได้จับของจริงแล้วบอกว่า
“จริงๆ ผมไม่ได้ทำงานแบบนี้ครับ”
ถ้าระบบตอบกลับว่า
“แต่ Requirement Sign-off ไปแล้วนะครับ”
เราไม่ได้กำลังบริหาร Product แล้วครับ แต่เรากำลังบริหาร เอกสารที่บันทึกความเข้าใจในอดีต
และนี่เป็นเหตุผลหนึ่งที่ Agile Manifesto เมื่อปี 2001 เน้น Working Software, Customer Collaboration และ Responding to Change มากกว่าการยึด Process, Documentation, Contract หรือ Plan เป็นศูนย์กลาง โดยไม่ได้บอกว่าสิ่งด้านขวาไม่มีค่า เพียงแต่สิ่งด้านซ้ายควรถูกให้คุณค่ามากกว่า. (Agile Manifesto)
ดังนั้นหัวใจของ Agile ไม่ได้อยู่ที่ Sprint สองสัปดาห์ครับ แบบที่เราเคยตัวทำกันทุกวันนี้
หัวใจคือ “เราสามารถเรียนรู้จากความจริง แล้วเปลี่ยนทิศได้เร็วแค่ไหน?”
⸻
🛹 Agile พังได้เหมือนกัน…เมื่อเราเอาเน้นเอาพิธีกรรมมาแทน Feedback
แล้วมนุษย์ก็เก่งมากครับ พอมีหลักการดีๆ เราก็รีบเปลี่ยนมันให้เป็น Process เช่น
* ต้อง Daily ทุก 9 โมงตรง
* Sprint ต้องสองสัปดาห์
* Retro ต้องวันศุกร์
* Jira ต้องมี Story Point
* Definition of Done ต้องเขียนตาม Template ตามนี้ เป็นต้น
ผ่านไปพักหนึ่งเราอาจมีทุกองค์ประกอบของ Agile ครบหมดแล้ว ยกเว้นสิ่งหนึ่งคือ
“Agility”
* ผมเคยเห็นทีมที่ Daily ทุกเช้า แต่ Daily กลายเป็น Status Report ให้หัวหน้า
* ทีมมี Sprint Review แต่คนใช้จริงไม่ได้อยู่ในห้อง
* มี Retrospective ทุกสองสัปดาห์ แต่ Action Item เดิมโผล่กลับมาอีก 5-6 Sprint ติดต่อกัน
ทุกอย่าง “ถูกพิธี” แต่ระบบไม่ได้เรียนรู้อะไรใหม่
นี่คือสิ่งที่ผมเรียกว่า “Agile Theatre” (ทำตามพิธีไปงั้นๆ เพราะองค์กรให้ทำ)
และผมคิดว่าโรคนี้สำคัญมากในยุค AI เพราะ AI กำลังทำให้เราสามารถทำ Theatre ได้เร็วกว่าเดิมเสียอีก
* เมื่อก่อนเราสร้าง User Story ที่ไม่มีใครต้องการได้ 20 เรื่องต่อ Sprint
* วันนี้ AI อาจช่วยเราสร้างได้ 200 เรื่อง
“AI ไม่ได้รักษาระบบที่ไม่มี Feedback ครับ มันเพียงเพิ่มความเร็วให้ระบบนั้น”
⸻
🤖 AI เป็น “Amplifier” มากกว่า “ยาวิเศษ”
ข้อมูลของ DORA ปี 2025 น่าสนใจมากครับ งานสำรวจเกือบ 5,000 Technology Professionals พบว่า 90% ของผู้ตอบใช้ AI ในงานแล้ว และมากกว่า 80% รู้สึกว่า AI เพิ่ม Productivity ของตัวเอง แต่ประมาณ 30% ยังรายงานว่ามีความไว้วางใจต่อ Code ที่ AI สร้างน้อยหรือไม่มีเลย (Google Cloud)
สิ่งที่ผมว่าน่าสนใจกว่าตัวเลข Adoption คือ “AI ไม่ได้เข้าไปซ่อมทีมที่มีปัญหา แต่มักขยายสิ่งที่มีอยู่เดิม” ทีมที่มี Workflow, Internal Platform และ Engineering Practice ที่แข็งแรงสามารถเอา AI ไปเพิ่มความเร็วได้มากกว่า ในขณะที่ทีมที่ระบบเดิมเปราะอยู่แล้ว AI สามารถทำให้ข้อจำกัดเหล่านั้นปรากฏชัดขึ้น (Google Cloud)
DORA ยังพบว่าในปี 2025 AI Adoption มีความสัมพันธ์เชิงบวกกับ Delivery Throughput และ Product Performance มากขึ้นกว่าปีก่อน แต่ยังมีความสัมพันธ์เชิงลบกับ Software Delivery Stability ซึ่งทีมวิจัยอธิบายว่าความเร็วที่เพิ่มขึ้นสามารถเปิดเผยจุดอ่อนปลายน้ำได้ หากไม่มี Automated Testing, Version Control และ Fast Feedback Loop ที่แข็งแรงพอ. (Google Cloud)
ผมคิดว่านี่เป็นประโยคที่ผู้บริหารควรจำไว้มากกว่าคำว่า AI Coding เสียอีกครับ
“ความเร็วไม่เคยแก้ระบบที่ไม่มีเบรก มันเพียงทำให้เราชนเร็วขึ้น”
⸻
😎 แล้ว “Vibe Coding” จริงๆ คืออะไร?
คำว่า Vibe Coding ไม่ได้เกิดจาก Framework ทางวิชาการครับ
Andrej Karpathy ใช้คำนี้ในโพสต์บน X เดือนกุมภาพันธ์ 2025 เพื่ออธิบายประสบการณ์การสร้าง Software แบบปล่อยให้ LLM รับงานเขียน Code ไปมาก ใช้ภาษาธรรมชาติบอกสิ่งที่ต้องการ ส่ง Error กลับให้ AI แก้ และในบางช่วงแทบไม่ต้องสนใจ Code โดยตรงเลย (X (formerly Twitter))
บริบทดั้งเดิมของคำนี้มีความขี้เล่นอยู่มากครับ และนั่นเป็นส่วนหนึ่งที่ทำให้มันดัง
ปัญหาเกิดขึ้นเมื่อวิธีที่ยอดเยี่ยมมากสำหรับ
* Prototype
* Personal Tool
* Experiment
* Weekend Project
* หรือการทดลอง Idea อย่างรวดเร็ว
แต่ทุกวันนี้คนกลับย้ายตรงๆ ไปใช้กับ
* Customer Data
* Payment
* Core Business Process
* Enterprise Integration
* หรือระบบที่ต้องอยู่ต่ออีกห้าปี
แล้วเรายังใช้ Mindset แบบเดิมว่า
“มัน Run ได้แล้วนี่ครับ”
งานวิจัยเชิงคุณภาพเกี่ยวกับ Vibe Coding ที่เผยแพร่เป็น preprint ในปี 2025 พบว่าผู้ใช้งานมองเห็นประโยชน์ด้าน Flow, Experimentation และการร่วมสร้างกับ AI จริง แต่ก็พบ Pain Point ซ้ำๆ ในเรื่อง Specification, Reliability, Debugging, Latency, Code Review Burden และ Collaboration เช่นกัน. (arXiv)
นี่จึงเป็นจุดที่ผมคิดว่าเราต้องแยกคำสองคำออกจากกันให้ชัด
“Software Creation กับ Software Engineering”
AI กำลัง Democratize อย่างแรกอย่างรวดเร็ว แต่ไม่ได้ทำให้อย่างหลังหมดความจำเป็น
⸻
🚗 Prototype ที่ “วิ่งได้” ยังห่างจาก Production ที่ “ฝากชีวิตธุรกิจไว้ได้”
ลองนึกภาพง่ายๆ ครับ
“คุณใช้ AI สร้างระบบ Approve Expense ภายในบ่ายเดียว Demo ได้ หน้าตาสวย Submit ได้ Manager Approve ได้ ทุกคนในห้องประชุมประทับใจ”
ถามว่า Software ทำงานไหม?
“ทำงานครับ”
แต่ถ้าถามว่า Production-ready หรือยัง คำถามจะเปลี่ยนไปทันที
* ใครเห็นข้อมูลอะไรได้บ้าง?
* ถ้ามีคนเปลี่ยน Request ระหว่าง Approve จะเกิดอะไร?
* Audit Trail อยู่ไหน?
* ถ้า API Down จะ Recover อย่างไร?
* ถ้าพนักงานลาออก Permission จะถูกถอนหรือไม่?
* ถ้าระบบพังตอนสิ้นเดือน ใครเป็น Owner?
* มี Test หรือไม่?
* มี Monitoring หรือไม่?
* มี Rollback หรือไม่?
* และถ้า AI สร้าง Dependency ที่มีช่องโหว่เข้ามา ใครเป็นคนรู้?
นี่คือความแตกต่างระหว่าง
“รถสตาร์ตติด” กับ “รถที่คุณกล้าพาครอบครัวขึ้นทางด่วน”
NIST Secure Software Development Framework จึงมอง Secure Software Development เป็นชุด Practice ที่ต้องผนวกเข้ากับ Software Development Lifecycle ไม่ใช่กิจกรรมที่ค่อยนำมาตรวจตอน Software เสร็จแล้ว (NIST Computer Security Resource Center)
“AI ทำให้เราสร้างรถได้เร็วขึ้นครับ” แต่ไม่ได้ยกเลิกเบรก เข็มขัดนิรภัย ประกัน การตรวจสภาพ และคนที่ต้องรับผิดชอบเมื่อรถชน
⸻
🛡️ ยิ่ง AI มี “Agency” มาก Demo ยิ่งไม่ใช่หลักฐานว่า Production ปลอดภัย
เรื่องนี้ชัดยิ่งขึ้นเมื่อเราไม่ได้สร้างเพียง Chatbot แต่เริ่มสร้าง AI Agent
สมมติ Agent ไม่ได้แค่ตอบว่า “ควรคืนเงินลูกค้าหรือไม่” แต่มันมีสิทธิ์เรียก API แล้วคืนเงินจริง
“Risk เปลี่ยนระดับทันทีครับ”
OWASP จัด Prompt Injection เป็นหนึ่งในความเสี่ยงหลักของ LLM Applications โดยอธิบายว่า Input สามารถเปลี่ยนพฤติกรรมของโมเดลในทิศทางที่ไม่ได้ตั้งใจ และในระบบที่เชื่อมกับ Tools หรือข้อมูลจริง ผลกระทบสามารถขยายไปถึง Unauthorized Access หรือการตัดสินใจที่ไม่ควรเกิดขึ้นได้ นอกจากนี้ OWASP ยังระบุด้วยว่า RAG หรือ Fine-tuning ไม่ได้ทำให้ Prompt Injection หายไปโดยอัตโนมัติ. (OWASP Gen AI Security Project)
Anthropic ก็ชี้ในแนวทางเรื่อง Agent Evals ปี 2026 ว่าการประเมิน Agent ซับซ้อนกว่า Single-turn LLM มาก เพราะ Agent สามารถเรียก Tool หลายครั้ง เปลี่ยน State ของ Environment และความผิดพลาดในช่วงต้นสามารถ Propagate และ Compound ไปยังขั้นต่อๆ ไปได้. (Anthropic)
ดังนั้นประโยคที่ว่า “เมื่อวาน Demo ผ่านแล้ว” แทบไม่มีความหมายเลยครับ ถ้าเรายังไม่รู้ว่า “มัน Fail อย่างไร?”
⸻
🎯 มืออาชีพจึงไม่ได้เริ่มจาก “เราจะสร้างอะไร?” อย่างเดียว แต่ถามว่า “เราจะรู้ได้อย่างไรว่ามันดี?”
นี่คือสิ่งที่ผมคิดว่าทีม AI ต่างจากทีม Demo อย่างชัดเจนที่สุด ก่อนสร้าง Feature ให้ถามว่า
“ถ้ามันเสร็จแล้ว เราจะพิสูจน์อย่างไรว่ามันดีจริง?”
OpenAI แนะนำแนวคิด Eval-driven Development โดยตรง คือ Evaluate ตั้งแต่ต้นและทำอย่างต่อเนื่อง สร้าง Test ที่สะท้อน Use Case จริง เก็บ Log เพื่อนำ Failure Case กลับมาเป็น Test และใช้ Human Judgment มาช่วย Calibrate การให้คะแนนอัตโนมัติ. (OpenAI Developers)
นี่คือเรื่องที่สำคัญมากสำหรับ Generative AI เพราะระบบเหล่านี้ไม่ได้ Deterministic แบบ Software เดิม Input เดียวกันสามารถให้ Output ต่างกันได้ การบอกว่า “ผมลองสิบครั้งแล้วมันตอบดี” จึงไม่ใช่ Evaluation Strategy. (OpenAI Developers)
ถ้าทำ AI สรุป Complaint ลูกค้า อย่าเริ่มจากถามว่า Model ไหนดีที่สุด เริ่มจากนิยามก่อนว่า
* คำตอบที่ “ดี” คืออะไร?
* ต้องจับ Issue ไหนได้?
* อะไรคือข้อมูลที่ห้ามแต่ง?
* ต้องอ้างหลักฐานหรือไม่?
* Error แบบไหนรับได้?
* และ Failure แบบไหนถือว่า Severity สูงจนห้ามปล่อยขึ้น Production?
เมื่อรู้ตรงนี้ Model กลายเป็น “ตัวแปร” ไม่ใช่ “สิ่งที่เชื่อถือได้ 100%”
⸻
🧪 “Evaluation > Demo” จึงไม่ใช่คำสวยๆ แต่มันคือการเปลี่ยนวิธีคิดทั้งทีม
Demo ถูกออกแบบให้ตอบคำถามว่า “ทำได้ไหม?” Evaluation ต้องตอบว่า “ทำได้ดีพอไหม ภายใต้เงื่อนไขที่โลกจริงจะโยนใส่มัน?”
สองคำถามนี้ห่างกันมากครับ
* Demo มักใช้ Happy Path, Eval ต้องมี Bad Case
* Demo เลือก Prompt ที่สวย, Eval ต้องมีคำถามประหลาด
* Demo โชว์ผลลัพธ์หนึ่งครั้ง, Eval ต้องดู Distribution
* Demo ทำให้ผู้บริหารรู้สึกตื่นเต้น, Eval ทำให้ทีมรู้ว่า ควรกลัวอะไร
นี่เป็นเหตุผลที่ผมคิดว่าในยุค AI คำว่า MVP ต้องมีความหมายเพิ่มอีกหนึ่งชั้น
จากเดิมที่ถามว่า “Minimum Viable Product คืออะไร?” เราต้องถามเพิ่มว่า
“Minimum Viable Evidence คืออะไร ที่ทำให้เรากล้าเชื่อ Product นี้?”
⸻
📏 และอย่าวัดสิ่งที่ง่าย จนลืมสิ่งที่สำคัญ
ทีม Software มีนิสัยหนึ่งที่ผมคิดว่าแก้ยากครับ เราชอบ Metric ที่วัดง่าย
* Velocity
* Story Point
* จำนวน Ticket
* จำนวน Commit
* Code Coverage
* Latency
* Accuracy
* หรือ Benchmark Score
Metric เหล่านี้มีประโยชน์ครับ แต่ไม่มี Metric ใดตอบแทนคำถามว่า
“ลูกค้าได้ Value หรือยัง?”
DORA 2025 พบว่า User-centricity เป็นเงื่อนไขสำคัญที่ช่วยให้ AI สร้างผลลัพธ์เชิงทีมได้ดีขึ้น เพราะ AI จะมีประโยชน์มากขึ้นเมื่อมันถูกชี้ไปยัง Problem ที่ชัดเจนของผู้ใช้จริง. (Google Cloud)
ดังนั้นระบบอาจตอบเร็วขึ้นจาก 5 วินาทีเหลือ 2 วินาที แต่ถ้าตอบเรื่องที่ลูกค้าไม่ได้ต้องการถาม
“เราไม่ได้สร้าง Product ที่ดีขึ้นครับ เราเพียงสร้าง คำตอบที่ผิดได้เร็วขึ้น”
นี่คือเหตุผลที่ผมไม่ค่อยชอบประโยค
“Model ใหม่ Accuracy ดีกว่าเดิม” จนกว่าจะมีประโยคถัดไปว่า “แล้ว Business Outcome อะไรดีขึ้น?”
⸻
⚙️ AI ไม่ได้ทำให้ Engineering Discipline ล้าสมัย แต่มันทำให้ Discipline มีค่ามากขึ้น
นี่คือ Paradox ที่ผมคิดว่าน่าสนใจที่สุดครับ
เวลาคนได้ Tool ที่เร็วขึ้น เรามักคิดว่า Process เก่าหลายอย่างควรถูกตัดออก
* Code Review ช้า
* Test ช้า
* Documentation ช้า
* Architecture Discussion ช้า
* Security Review ช้า
“จริงครับ ทุกอย่างมี Cost และ Process ที่ไม่สร้าง Value ก็ควรถูกฆ่า”
แต่ DORA 2025 กลับชี้ว่าความเร็วจาก AI จะสร้างประโยชน์ได้ดีขึ้นเมื่ออยู่ท่ามกลาง Practice พื้นฐานที่แข็งแรง เช่น Automated Testing, Version Control, Small Batches และ Fast Feedback Loops และ AI Adoption ที่เพิ่มความเร็วโดยไม่มี Control System ที่เหมาะสมสามารถตามมาด้วย Delivery Instability ได้. (Google Cloud)
ดังนั้นสิ่งที่ควรหายไปไม่ใช่ Discipline แต่คือ Waste และสองอย่างนี้ไม่เหมือนกันครับ
* การให้ Developer รอ CAB Meeting สามสัปดาห์เพื่อ Deploy Bug Fix อาจเป็น Waste แต่ Automated Test ที่หยุด Bug ก่อนถึงลูกค้าไม่ใช่ Waste
* การเขียน Documentation 150 หน้าโดยไม่มีใครอ่านอาจเป็น Waste แต่การมี Runbook ที่ทำให้คนอื่นรับ Incident ต่อจากเราได้ไม่ใช่ Waste
“AI ควรช่วยเราเอา Bureaucracy ออกจาก Engineering ไม่ใช่เอา Engineering ออกจาก Software”
⸻
🧹 Vibe Coding ที่อันตรายที่สุด จึงไม่ใช่การใช้ AI เขียน Code
ผมอยากแก้ความเข้าใจตรงนี้ครับ
“ผมไม่ได้คิดว่า Vibe Coding เป็นของไม่ดี”
ตรงกันข้าม ผมคิดว่ามันเป็นหนึ่งในวิธีที่สนุกและทรงพลังที่สุดสำหรับ Exploration
* คนที่ไม่เคยสร้าง Software สามารถเปลี่ยน Idea ให้กลายเป็น Prototype
* Developer สามารถทดลอง Solution หลายแบบภายในเวลาสั้นลง
* Product Manager สามารถสร้างสิ่งที่เคยต้องรอทีม Development เพื่อใช้ในการคุยกับ User
นี่คือเรื่องดีมากครับ
“Vibe Coding ไม่อันตรายตอนที่เรา Vibe”
มันอันตรายตอนที่เรา ลืมว่าตัวเองกำลัง Vibe แล้วเรียกสิ่งนั้นว่า Production Engineering
* Prototype ไม่ต้องมีทุกอย่าง, Production ต้องมีเจ้าของ
* Prototype พังแล้วหัวเราะได้, Production พังแล้วลูกค้าอาจโทรมา
* Prototype สามารถทิ้งได้, Production ต้อง Maintain
ดังนั้นคำถามไม่ใช่ว่า “อนุญาตให้ Vibe Coding หรือไม่?” แต่คือ
“ทีมรู้หรือไม่ว่าตอนไหนต้องเปลี่ยน Mode จาก Vibe มาเป็น Engineering?”
⸻
🔧 Software ยุค AI มีเรื่องสำคัญคือ
1. Start Small, Measure Hard - สร้างทีละเล็ก ส่ง Feedback ให้เร็ว และนิยาม Evaluation ก่อนหลงรัก Demo
2. Problem & Data ก่อน Model Name - อย่าเปลี่ยน Model เพื่อหนีปัญหาที่จริงๆ อยู่ใน Requirement, Data หรือ Workflow เพราะ DORA เองพบว่ามูลค่าของ AI ถูกปลดล็อกผ่านระบบงานและ Practice รอบตัว ไม่ใช่ Tool เพียงอย่างเดียว. (Google Cloud)
3. Trust but Verify - AI Generate ได้ แต่ Test, Eval, Review และ Human Judgment ยังต้องทำหน้าที่พิสูจน์ว่าของที่ Generate นั้นควรถูกใช้จริง. (OpenAI Developers)
4. Design for Failure ตั้งแต่วันแรก - ถ้ามี LLM หรือ Agent อยู่ใน Critical Flow ต้องถามเรื่อง Prompt Injection, Permission, Logging, Rollback, Observability และ Blast Radius ก่อนขึ้น Production ไม่ใช่หลัง Incident. (OWASP Gen AI Security Project)
5. Simplicity ต้องชนะ Ego - ถ้า Rule ธรรมดาแก้โจทย์ได้ อย่าฝืนสร้าง Agent ห้าตัวเพียงเพราะ Slide ดูเท่กว่า Architecture ที่ดีไม่ใช่ Architecture ที่ใช้ Technology มากที่สุด แต่คือ Architecture ที่แก้ปัญหาได้ด้วย Complexity เท่าที่จำเป็น
“ถ้าเรารักษา 5 เรื่องนี้ได้ ต่อให้ชื่อ Framework เปลี่ยนอีกสิบครั้ง ผมคิดว่าทีมก็ยังอยู่รอดครับ”
⸻
👑 ปัญหาระดับ Leadership คือ อย่าให้ “ความเร็วของ Demo” กลายเป็น KPI ที่ทำร้าย Production
ผู้บริหารเองมีบทบาทสำคัญมากครับ เพราะถ้าองค์กรให้รางวัลทีมจากจำนวน AI Use Case, จำนวน Prototype, จำนวน Agent, จำนวน Hackathon, จำนวน Feature ที่ Generate
สิ่งที่ทีมจะผลิตก็คือสิ่งเหล่านั้น แล้วอีกหนึ่งปีต่อมา เราอาจมี Demo 120 ตัว, Production จริง 7 ตัว และทีม Platform อีก 30 คนคอยดับไฟจากสิ่งที่รีบขึ้นระบบไปแล้ว
ถามว่าทีมผิดไหม? ผมว่าไม่ทั้งหมดครับ
“ระบบ Incentive สั่งให้เขาสร้างสิ่งที่เรากำลังวัด”
คำถามของผู้บริหารจึงควรเปลี่ยนจาก “เดือนนี้สร้าง AI Use Case ได้กี่ตัว?” ไปเป็น
“กี่ตัวสร้าง Outcome จริง?”
“กี่ตัวผ่าน Eval?”
“กี่ตัวมี Owner?”
“กี่ตัวผ่าน Security?”
“กี่ตัวมีคนใช้ต่อเนื่อง?”
“และกี่ตัวเรากล้าปิด เพราะพิสูจน์แล้วว่าไม่สร้าง Value?”
องค์กรที่ Mature ไม่ใช่องค์กรที่มี Project เยอะที่สุดครับ บางทีคือองค์กรที่ ฆ่า Project ที่ไม่ควรอยู่ได้เร็วที่สุด
⸻
✨ โลกไม่ได้ขาดคนสร้าง Demo แล้ว…โลกกำลังขาดคนที่รู้ว่าอะไรสมควรกลายเป็นระบบจริง
กลับมาที่ภาพเดิมครับ
* Waterfall เริ่มจากชิ้นส่วนก่อนจะมีรถ
* Agile พยายามทำให้แต่ละช่วงยังส่ง Value ได้
* AI เพิ่มเครื่องยนต์ให้คนสร้างเร็วขึ้น
* Vibe Coding ทำให้คนที่ไม่เคยประกอบรถสามารถบอก AI ว่า “ช่วยทำรถให้หน่อย” แล้วไม่กี่นาทีต่อมาอาจมีรถวิ่งอยู่ตรงหน้า
ผมคิดว่านี่เป็นเรื่องมหัศจรรย์ครับ แต่สิ่งที่เราไม่ควรลืมคือ
“ความสามารถในการสร้างรถ กับความสามารถในการสร้างรถที่ควรได้รับอนุญาตให้วิ่งบนถนน เป็นคนละวิชา”
โลก Software ยุค AI จึงไม่ได้ต้องการคนที่ต่อต้าน AI และไม่ได้ต้องการคนที่ยึด Process เก่าไว้เพราะกลัวการเปลี่ยนแปลง
มันต้องการคนที่รู้ว่าเมื่อไรควรเร็ว เมื่อไรควรช้า
* อะไรควร Prototype?
* อะไรต้อง Engineer?
* อะไรควร Measure?
* อะไรต้อง Secure?
* และอะไรควรถูกฆ่าทิ้งก่อนที่ Technical Debt จะโตพอมีชื่อเล่นเป็นของตัวเอง?
เพราะท้ายที่สุดแล้ว
“Waterfall ไม่ได้ช่วยคุณ…Agile ไม่ได้ช่วยคุณ…AI ก็ไม่ได้ช่วยคุณ…”
ถ้าคุณไม่คิดว่า “เรากำลังแก้ปัญหาอะไร และเรารู้ได้อย่างไรว่าสิ่งที่สร้างขึ้นมาดีกว่าเดิมจริง?”
เทคโนโลยีทุกยุคมีวิธีทำให้เราสร้างของได้เร็วขึ้นครับ แต่ความเป็นมืออาชีพไม่ได้อยู่ที่ความเร็วในการสร้าง มันอยู่ที่ “วินัยในการพิสูจน์ว่า ของที่สร้างนั้นสมควรอยู่ต่อ”
ดังนั้นในวันที่ AI ทำให้ใครๆ ก็สร้าง Software ได้ ทักษะที่แพงที่สุดอาจไม่ใช่การรู้ว่าจะ Prompt อย่างไร หรือใช้ Agent กี่ตัว แต่คือการกล้าพูดว่า
“Demo นี้ว้าวมากครับ…แต่เรายังไม่มีหลักฐานพอที่จะเอามันขึ้น Production”
และบางครั้งประโยคที่สร้าง Value ให้บริษัทมากที่สุด อาจไม่ใช่
“สร้างได้ครับ” แต่คือ “สร้างได้ครับ…แต่เราไม่ควรสร้างมันด้วยวิธีนี้ตั้งแต่แรก”
#วันละเรื่องสองเรื่อง #ExecutiveMindset #SoftwareEngineering #AIEngineering #VibeCoding #Agile #ProductStrategy #TechLeadership #AIGovernance #FutureOfWork #DigitalTransformation
⸻
📚 Source / Reference
* Manifesto for Agile Software Development — ใช้เป็นฐานกลับไปยังหลักการดั้งเดิมของ Agile ได้แก่ Individuals & Interactions, Working Software, Customer Collaboration และ Responding to Change เพื่อแยก “Agile Principles” ออกจาก Agile Rituals ที่องค์กรสร้างขึ้นภายหลัง. (Agile Manifesto)
* Andrej Karpathy — โพสต์ต้นทางที่ใช้คำว่า “Vibe Coding”, February 2025 — ใช้ตรวจที่มาของคำและบริบทดั้งเดิมที่อธิบายการปล่อยให้ LLM รับภาระการเขียน Code จำนวนมากผ่านการโต้ตอบด้วยภาษาธรรมชาติ ไม่ได้นำไปใช้เป็นหลักฐานว่ากระบวนการนี้เหมาะกับ Production ทุกประเภท. (X (formerly Twitter))
* Google Cloud / DORA — State of AI-Assisted Software Development 2025 — งานวิจัยจากข้อมูลเกือบ 5,000 Technology Professionals ใช้เป็นฐานเรื่อง AI ในฐานะ Amplifier, Productivity, Trust ใน AI-generated Code, User-centricity และข้อค้นพบว่า AI สามารถเพิ่ม Throughput แต่ยังสัมพันธ์กับ Delivery Instability หากระบบ Control และ Engineering Practices รอบข้างไม่แข็งแรง. (Google Cloud)
* OpenAI — Evaluation Best Practices — ใช้เป็นฐานเรื่อง Eval-driven Development, Task-specific Evaluation, Logging, Continuous Evaluation และการใช้ Human Judgment ร่วมกับ Automated Grading สำหรับระบบ Generative AI ที่มีความไม่แน่นอนของ Output. (OpenAI Developers)
* Anthropic — Demystifying Evals for AI Agents (2026) — ใช้ประกอบประเด็นว่า Agentic Systems ต้องการ Evaluation ที่ซับซ้อนขึ้น เพราะ Agent สามารถใช้ Tool หลายรอบ เปลี่ยน State และทำให้ Error จากขั้นตอนหนึ่ง Propagate ไปยังขั้นต่อไปได้. (Anthropic)
* OWASP GenAI Security Project — LLM01:2025 Prompt Injection — ใช้เป็นฐานเรื่อง Prompt Injection, Indirect Prompt Injection และความเสี่ยงเมื่อ LLM เชื่อมต่อกับ Tools, Data หรือการตัดสินใจสำคัญ รวมถึงข้อควรระวังว่า RAG หรือ Fine-tuning ไม่ได้กำจัดความเสี่ยงนี้โดยอัตโนมัติ. (OWASP Gen AI Security Project)
* NIST — Secure Software Development Framework (SSDF) — ใช้เป็นฐานคิดว่า Security Practice ควรถูกผนวกเข้าไปตลอด Software Development Lifecycle ไม่ใช่ถูกนำมาตรวจเพิ่มเฉพาะปลายทางก่อน Production. (NIST Computer Security Resource Center)
* Pimenova et al. — “Good Vibrations? A Qualitative Study of Co-Creation, Communication, Flow, and Trust in Vibe Coding” (2025, preprint) — ใช้เป็นหลักฐานเชิงคุณภาพเรื่องประโยชน์และ Pain Point ที่เกิดขึ้นใน Vibe Coding เช่น Flow, Experimentation, Specification, Reliability, Debugging, Latency, Code Review Burden และ Collaboration โดยใช้ในฐานะงานวิจัยเบื้องต้น ไม่ใช่ข้อสรุปทั่วไปของวงการ Software ทั้งหมด. (arXiv)
* กรอบ “Agile Theatre”, “Evaluation > Demo”, “Prototype Mode → Engineering Mode”, “Minimum Viable Evidence” และแนวคิดว่า AI ควรเอา Bureaucracy ออกจาก Engineering ไม่ใช่เอา Engineering ออกจาก Software — เป็นการสังเคราะห์ของผู้เขียนจากหลักฐานและประสบการณ์ด้าน Product / Software Delivery เพื่ออธิบายปัญหาเชิง Organizational Design ไม่ได้นำเสนอในฐานะ Framework จากแหล่งภายนอก
โฆษณา
- ดาวน์โหลดแอปพลิเคชัน
- © 2026 Blockdit
