vibe coding พังไม่ใช่เพราะ AI โง่ Forbes บอกพังเพราะไม่มีคนกล้าตัดสินใจ

vibe coding พังไม่ใช่เพราะ AI โง่ มันพังเพราะไม่มีใครในทีมกล้าหยุด prototype ที่ AI สร้างได้แล้ว

นี่คือข้อสรุปของ Jason Wingard นักเขียน Senior Contributor ของ Forbes ในบทความ "Vibe Coding Will Break Your Company" ที่ออกเมื่อ 23 เมษายน 2026

เขาไม่ได้บอกให้เลิกใช้ Cursor หรือ Claude Code เขาบอกว่าเครื่องมือไม่ใช่ปัญหา คนที่ออกแบบระบบตัดสินใจของบริษัทต่างหากที่เป็นปัญหา ผมอ่านจบแล้วบอกตรงๆ ว่าทีมไทยส่วนใหญ่กำลังนับถอยหลังไปสู่เคสแบบ Replit หรือ Klarna โดยที่ตัวเองไม่รู้เลย

คอขวดยุคนี้ไม่ใช่การผลิต แต่เป็นการตัดสินใจ

ประโยคที่ Wingard ใช้เปิดเรื่องคือ "The bottleneck in the AI era is not production. It is discernment."

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

vibe coding หมายถึงการสั่งให้ AI เขียนโค้ดด้วยภาษาธรรมชาติ ผ่าน Cursor, Claude Code, GitHub Copilot Workspace, Replit, Lovable, Bolt หรือ v0 by Vercel

เครื่องมือพวกนี้บีบเวลา build จากเดือนให้เหลือชั่วโมง ฟังดูเป็นข่าวดีเลยนะ แต่ Wingard ชี้ว่า 30 ปีที่ผ่านมาบริษัททั่วโลกค่อยๆ สร้างขั้นตอนตรวจสอบขึ้นมาเยอะมาก ทั้งการตรวจ design การตรวจความปลอดภัย การ approve ทางกฎหมาย

vibe coding ค่าเริ่มต้นคือเดินอ้อมขั้นตอนพวกนี้ทั้งหมด ไม่ใช่ bug มันคือ feature ของเครื่องมือเอง ปัญหาคือคนเอามาใช้แบบไม่มีจุดหยุด

Wingard ยังยกงานวิจัยจาก MIT ที่พบว่าโครงการ generative AI ของบริษัทใหญ่ส่วนมากยังไม่สร้างผลตอบแทนที่วัดได้ ปัญหาหลักที่ MIT ระบุคือ "ความสามารถขององค์กรในการรวม AI เข้ากับขั้นตอนทำงานจริง" ไม่ใช่ปัญหาที่โมเดลไม่เก่ง

3 เคสที่เกิดขึ้นจริง ไม่ใช่ตัวอย่างสมมุติ

Wingard ไม่ได้คิดเรื่องนี้เอง เขามี 3 เคสมาวางไว้ข้างหน้าก่อน

เคสแรก ฤดูร้อนปี 2025 Jason Lemkin ผู้ก่อตั้ง SaaStr ลองให้ AI agent ของ Replit ทำงานในช่วง code freeze ที่ประกาศชัดเจน ผลคือ AI agent ลบ database ที่ใช้งาน production ทิ้ง กระทบข้อมูลของ executive 1,200+ คน และบริษัท 1,100+ แห่ง แล้วยังแต่งข้อมูลปลอมและบิดเบือนเหตุการณ์ที่เกิดขึ้น Amjad Masad ซีอีโอ Replit ออกมาขอโทษและเพิ่ม safeguard ทีหลัง

จุดที่ Wingard เน้นคือ tool ทำงานถูกตามที่ออกแบบ มัน autonomous จริงๆ ความล้มเหลวอยู่ที่องค์กร ไม่มีระบบหยุดที่ AI agent เคารพ ไม่มีลูป judgment เลย

เคสสอง Klarna ในปี 2025 บริษัทเคยโม้ว่า AI customer service ของตัวเองทำงานแทนคนได้หลายร้อยคน ผ่านไปไม่นานก็แอบจ้างคนกลับ Sebastian Siemiatkowski ซีอีโอออกมาบอกว่าต้องสมดุลระหว่าง AI กับคนจริง

Wingard สรุปว่า "เทคโนโลยีทำงานได้ในบางส่วน แต่ระบบตัดสินใจรอบๆ มันยังไม่ครบ"

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

5 มิติที่ต้อง audit ก่อนเปิด Cursor ให้ทีม

หัวใจของบทความ Wingard คือ Judgment System Audit 5 มิติ ผมอ่านแล้วรู้สึกว่าเข้ากับทีมไทยขนาดเล็กถึงกลางมากเลย เพราะปัญหานี้ไม่ได้แยกตามขนาดบริษัท

หนึ่ง Decision Rights สิทธิ์การตัดสินใจ คนที่ไม่ได้เป็น engineer build แอปด้วย Lovable หรือ Bolt เสร็จใน 2 วัน คำถามคือใครมีอำนาจอนุมัติให้แอปนั้นใช้กับลูกค้าจริง Wingard บอกว่าในบริษัทส่วนใหญ่ ไม่มีใครรู้คำตอบเลย

สอง Override Culture วัฒนธรรมการเบรก Wingard ตั้งคำถามตรงๆ ว่า "มีคนที่หยุด prototype ได้โดยไม่เสีย career ไหม" ถ้าตอบไม่ได้ vibe coding จะกลายเป็นทางเดียวที่ย้อนกลับไม่ได้

สาม Contextual Intel บริบทที่ AI ไม่รู้ AI ผลิต output ที่ดูดีในเชิง technical แต่โง่เรื่องบริบท บริบทเรื่องกฎหมาย แบรนด์ ลูกค้า ความปลอดภัย ต้องมาจากคนก่อนจะอนุมัติ prototype ไม่ใช่ตามไปเก็บกวาดทีหลัง

สี่ Learning Velocity ความเร็วในการเรียนรู้ หลัง failure คำถามที่ถูกต้องคือ "กระบวนการของเราพลาดอะไร" ไม่ใช่ "ใครผิด" Wingard ยกตัวอย่าง Tobi Lütke ซีอีโอ Shopify ที่ใส่ "reflexive AI usage" เข้าไปใน performance review แปลให้ฟังคือใช้ AI แบบสะท้อนคิด ไม่ใช่ deploy แบบสะท้อน

ห้า Ethical Discernment การตัดสินทางจริยธรรม Wingard เขียนตรงๆ ว่า "vibe coding ทำให้สร้างของที่ไม่ควรสร้างขึ้นได้ง่ายเกินไป" เช่น feature สอดส่อง UX หลอกล่อ การเก็บข้อมูลโดยไม่ขออนุญาต

ผมว่ามิติที่ทีมไทยมัก fail สุดคือข้อ 2 Override Culture เพราะวัฒนธรรมที่ junior หรือ QA หยุดงาน senior ได้โดยไม่ถูกหมายหัว ยังไม่ค่อยมีในบ้านเรา ยิ่ง prototype ที่ "ทำงานได้แล้ว" ยิ่งหยุดยาก

Amazon Kiro คือเรื่องเดียวกัน ไม่ต้องนึกภาพ

Wingard ไม่ได้พูดถึง Amazon เลย แต่เคส Amazon Kiro ที่เกิดต้นปี 2026 เหมือนเอาข้อโต้แย้งของเขามาเล่นจริง

ตามรายงานของ D3 Security ที่ลงใน Security Boulevard Amazon บังคับให้ engineer ใช้เครื่องมือ AI coding ภายในชื่อ Kiro อย่างน้อย 80% ของชั่วโมงทำงานต่อสัปดาห์ ผ่านไประยะหนึ่งเกิด outage 6 ชั่วโมง ระบบ checkout login และราคาสินค้าพัง publisher ประเมินว่า order หาย 6.3 ล้านรายการ

ตัวเลข 6.3 ล้านมาจากฝั่ง publisher ไม่ใช่ Amazon เอง American Banker อ้างอิง Financial Times ว่ามี outage จริงในเดือนธันวาคม 2025 ที่เกิดจาก AI coding bot และ Amazon ออกกฎใหม่ให้ senior engineer ต้องอนุมัติโค้ดที่ AI ช่วยเขียนของ junior กับ mid-level ทุกครั้ง โฆษก Amazon โต้ว่า "มีแค่ incident เดียวที่เกี่ยวกับ AI และไม่มี incident ไหนเกิดจากโค้ดที่ AI เป็นคนเขียน"

ต่อให้ Amazon โต้ตัวเลขถูกหมด ก็ยังเหลือข้อเท็จจริงว่าบริษัทบังคับให้ใช้ AI coding tool ระดับ 80% ทั้งที่ guardrail ยังไม่นิ่ง แล้วค่อยเพิ่ม layer review ของ senior engineer หลัง incident

นี่คือสิ่งที่ Wingard เรียกว่า "ตัด judgment system ออกก่อน แล้วค่อยใส่กลับหลังเกิดเรื่อง"

Bradley Leimer ที่ปรึกษาในวงการธนาคารพูดใน American Banker ตรงๆ ว่า "ในธุรกิจธนาคาร เคสแบบนี้คนทั้งทีมจบอาชีพการงานได้เลย หรืออย่างน้อยก็ควรจะ" เพราะธุรกิจเงินไม่ทนระบบล่มเหมือน e-commerce เขาบอกอีกว่า "Amazon ปลดคน 30,000 แล้วบอกพนักงานให้ใช้ AI ทำงานแทน"

Theodora Lau จาก Unconventional Ventures ทิ้งประโยคที่ผมว่าทุกทีมควรพิมพ์ติดผนัง: "เครื่องมือเขียนโค้ดเป็นแค่เครื่องมือ ไม่ใช่ตัวแทนคน"

ฝ่ายเห็นต่างก็มีจุดที่ผมเห็นด้วย

ก่อนจบ ผมอยากลองเถียงแทนฝ่ายตรงข้าม Wingard ก่อน เพราะใน Hacker News มีคนเถียงแรงๆ และบางจุดมีน้ำหนักจริงๆ ล่ะ

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

สอง คนที่ใช้ AI coding แบบพอดีและมีคนคอยตรวจ ก็ได้ผลิตภาพจริง ไม่ใช่ทุกคนที่เปิด Cursor แล้วบริษัทพัง บางคนบอกว่าตัวเองเป็น architect มากกว่า coder ใช้ AI ร่าง draft แล้วตัวเองคุม shape ของระบบ

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

แต่ทั้ง 3 ข้อจริงๆ คือ Wingard เองนะ เขาบอกว่า judgment system สำคัญกว่า tool ฝ่ายตรงข้ามที่ว่า "ผู้นำสำคัญกว่า AI" คือคำตอบเดียวกันที่พูดด้วยภาษาต่างกัน คนที่ใช้ AI พร้อมตรวจซ้ำคือคนที่มี judgment system ส่วนตัวอยู่แล้ว

ข้อโต้แย้งที่ผมตอบยากสุดคือเรื่องโทน Wingard ใช้ภาษาแบบ consultant ขาย framework ให้ผู้บริหาร คำว่า "your judgment system" "Monday-morning audit" ฟังเหมือนสไลด์ขายของจริงๆ ผมเห็นด้วยว่าน้ำเสียงเขาเข้าโหมดผู้บริหารเกินไปในบางจุด แต่กรอบคิด 5 มิติยังใช้ได้ ถ้าตัดสำนวนนั้นทิ้ง

ทีมไทยควรทำอะไรในวันจันทร์

ผมเขียนตรงนี้ให้ team lead ทีมไทยที่กำลังคิดจะเปิด Cursor หรือ Claude Code ให้ทุกคนใช้

ก่อนเปิด ลองหยิบ AI decision หนึ่งอันที่ทีมตัดสินใจเมื่อเดือนที่แล้ว แล้วเดินผ่าน 5 มิติของ Wingard

ใครเป็นคนอนุมัติให้โค้ด AI ขึ้น staging ได้ มี QA ที่กล้าหยุดงานไหม บริบทของลูกค้าเข้ามาก่อนหรือหลัง prototype ทีมเรียนรู้อะไรจาก incident ครั้งล่าสุด มี feature ที่ไม่ควร build แต่ AI generate มาแล้วไหม

ถ้า 5 ข้อนี้ทีมยังตอบได้ไม่ครบ การเปิด AI coding ทั้งทีมจะเร่งให้ปัญหาเดิมโตขึ้น ไม่ได้ทำให้หาย

ผมไม่ได้บอกว่าอย่าใช้ vibe coding ทีมผมเองก็ใช้ Claude Code ทุกวัน แต่ผมเห็นด้วยกับ Wingard 100% ว่าจังหวะที่บริษัทไทยพังจาก AI coding จะมาถึงเมื่อใครสักคน ship prototype ที่ไม่มีใครกล้าหยุด ไม่ใช่เมื่อ AI generate โค้ด buggy

ของแบบแรกแก้ได้ใน CI ของแบบหลังแก้ที่วัฒนธรรมเท่านั้นล่ะ

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

• Vibe Coding Will Break Your Company โดย Jason Wingard, Forbes (อ่านผ่าน Yahoo Finance syndication)
• Amazon Lost 6.3 Million Orders to Vibe Coding. Your SOC Is Next. โดย D3 Security
• Amazon's vibe coding went awry. There are lessons for bankers โดย American Banker