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

TL;DR

• โครงสร้างการตรวจสอบอัตโนมัติของ YouTube อาจส่งผลต่อผู้พัฒนาแอป AI ได้เช่นกัน

• โดยเฉพาะถ้าคุณทำเงินจากแอปหรือ SaaS ความเสี่ยงจากการตรวจสอบของแพลตฟอร์มจะยิ่งสูงขึ้น

• ประเด็นสำคัญไม่ใช่ “AI สร้างโค้ดได้หรือไม่”

• แต่คือ ใครเป็นคนเข้าใจ ใครเป็นคนตรวจสอบ และใครเป็นผู้รับผิดชอบในการปล่อยใช้งาน

• ตัวเลขสำคัญ

  • METR: เมื่อใช้เครื่องมือ AI นักพัฒนาที่มีประสบการณ์ใช้เวลาทำงานเสร็จช้าลง 19%
  • Veracode: พบช่องโหว่ความปลอดภัยที่รู้จักแล้วในโค้ดที่ AI สร้าง 45%
  • CodeRabbit: โค้ดที่ AI ร่วมเขียนมีข้อบกพร่องสำคัญมากกว่า 1.7 เท่า และช่องโหว่ความปลอดภัยมากกว่า 2.74 เท่า
  • Vangala et al. 2026: เอเจนต์ AI อาจต้องการ dependency ใน runtime จริงมากกว่าที่คาดไว้ถึง 13.5 เท่า
  • คาดการณ์หนี้ทางเทคนิคในปี 2027 อยู่ที่ 1.5 ล้านล้านดอลลาร์ และมีข้ออ้างว่าสตาร์ตอัปกว่า 8,000 แห่งต้องทำงานใหม่

• สรุป: สิ่งที่จำเป็นคือ บันทึกความรับผิดชอบที่ตรวจสอบได้

---

1. กรณีของ YouTube

YouTube ได้เข้มงวดมากขึ้นกับการจำกัดการสร้างรายได้จากคอนเทนต์แบบซ้ำๆ และผลิตจำนวนมากในช่วงปี 2024~2025
เหตุผลอย่างเป็นทางการคือคุณภาพของคอนเทนต์ ความเป็นต้นฉบับ และการจัดการคอนเทนต์ซ้ำ

ประเด็นสำคัญไม่ใช่นโยบาย แต่คือ โครงสร้างการบังคับใช้

• แพลตฟอร์มจัดหมวดหมู่คอนเทนต์ด้วยการตรวจสอบอัตโนมัติ
• ผู้สร้างที่ได้รับแจ้งว่าถูกระงับการสร้างรายได้แบบกะทันหัน มักยากจะรู้เหตุผลเฉพาะของการตัดสิน
• การอุทธรณ์ถูกจัดการแบบเป็นพิธีการ
• กรณีที่ได้รับอนุมัติกลับมีจำนวนจำกัด
• สุดท้ายความเสียหายก็ตกอยู่กับผู้สร้าง

หากโครงสร้างนี้ย้ายมาสู่แพลตฟอร์มซอฟต์แวร์อย่าง app store, ผู้ให้บริการชำระเงิน หรือคลาวด์ แอปหรือ SaaS ที่สร้างด้วยเครื่องมือ AI ก็อาจเผชิญความเสี่ยงคล้ายกันได้

• แพลตฟอร์มประเมินผลลัพธ์โดยอัตโนมัติ
• หากถูกตัดสินว่ามีความเสี่ยง ก็อาจถูกจำกัดการใช้งาน
• นักพัฒนามักยากจะรู้เหตุผลเฉพาะของการตัดสิน
• การอุทธรณ์หรือการโต้แย้งอาจกลายเป็นเพียงขั้นตอนเชิงพิธีการ

---

2. โครงสร้างแบบเดียวกันกำลังเข้ามาใน IDE และเชนการดีพลอย

โครงสร้างความรับผิดชอบโดยคร่าวๆ แบ่งได้แบบนี้

• ผู้ให้บริการเครื่องมือ AI: จำกัดความรับผิดเรื่องความถูกต้อง การไม่ละเมิดสิทธิ และความรับผิดของผลลัพธ์ผ่านข้อกำหนดการใช้งาน
• แพลตฟอร์มการดีพลอย: app store, คลาวด์, ผู้ให้บริการชำระเงิน ฯลฯ จัดการความเสี่ยงด้วยนโยบายและการประเมินระดับความเสี่ยง
• นักพัฒนา/ผู้ปฏิบัติการ: ผู้รับผิดชอบขั้นสุดท้ายที่ยอมรับและดีพลอยโค้ดที่ AI สร้าง

ประเด็นสำคัญสะท้อนอยู่ในโครงสร้างข้อกำหนดการใช้งานของเครื่องมือเขียนโค้ดด้วย AI อย่าง GitHub Copilot

• โดยทั่วไปบริการจะให้มาแบบ “as-is”

• การจะใช้หรือไม่ใช้ข้อเสนอนั้นเป็นการตัดสินใจของนักพัฒนา

• ต่อให้ AI เป็นผู้สร้าง แต่คนที่ยอมรับและดีพลอยก็คือนักพัฒนา

• เครื่องมือเขียนโค้ดด้วย AI รายใหญ่อื่นๆ ก็น่าจะมีโครงสร้างความรับผิดคล้ายกันเป็นส่วนใหญ่

• ดังนั้นเมื่อเกิดข้อผิดพลาด ปัญหาความปลอดภัย หรืออุบัติเหตุในการปฏิบัติการ ความรับผิดชอบขั้นสุดท้ายจึงตกอยู่กับนักพัฒนาหรือผู้ปฏิบัติการ

---

3. ปัญหาของ vibe coding ไม่ใช่เรื่องความเร็ว แต่คือค่าใช้จ่ายในการตรวจสอบที่ซ่อนอยู่

vibe coding ควรถูกมองว่าไม่ใช่แค่ปัญหาด้านประสิทธิภาพ แต่เป็น ปัญหาความรับผิดชอบ

หลักฐานสำคัญมีดังนี้

• งานวิจัยของ METR

  • นักพัฒนาที่มีประสบการณ์คาดว่าการใช้ AI จะทำให้เร็วขึ้น 24%
  • แต่ในความเป็นจริงกลับใช้เวลาทำงานเสร็จนานขึ้น 19%

• รายงานของ Veracode

  • วิเคราะห์ LLM มากกว่า 100 ตัว
  • พบช่องโหว่ความปลอดภัยที่รู้จักแล้วในโค้ดที่ AI สร้าง 45%

• การวิเคราะห์ของ CodeRabbit

  • วิเคราะห์ PR มากกว่า 10 ล้านรายการ
  • โค้ดที่ AI ร่วมเขียนมีข้อบกพร่องสำคัญมากกว่า 1.7 เท่า
  • มีช่องโหว่ความปลอดภัยมากกว่า 2.74 เท่า

• งานวิจัยของ Vangala et al. 2026

  • เอเจนต์ AI ประเมิน dependency ที่ต้องใช้ต่ำกว่าความเป็นจริง
  • ใน runtime จริง อาจต้องใช้ dependency มากกว่าที่คาดถึง 13.5 เท่า

สรุปคือ:

• โค้ดอาจถูกสร้างได้อย่างรวดเร็ว
• แต่ต้องมีใครสักคนอ่านและทำความเข้าใจโค้ดนั้น
• หากข้ามการตรวจสอบ ต้นทุนจะย้อนกลับมาในรูปของการดีบักและการบำรุงรักษา
• ปัญหาด้านความปลอดภัยหรือ dependency มีโอกาสสูงที่จะระเบิดขึ้นระหว่างการให้บริการจริง

---

4. กรณีจริง: แอป Tea กับความเสี่ยงจากการตรวจสอบของแพลตฟอร์ม

กรณีของแอป Tea ไม่ใช่ตัวอย่างว่า “AI คือสาเหตุ” แต่เป็นตัวอย่างที่แสดงให้เห็นโครงสร้างความรับผิดชอบ

• เหตุการณ์ข้อมูลรั่วไหลของแอป Tea ในปี 2025
• เป็นแอปเพื่อความปลอดภัยของผู้หญิง
• มีภาพที่อ่อนไหว 72,000 ภาพถูกเปิดเผย
• สาเหตุคือการตั้งค่า Firebase ผิดพลาดและปัญหาการยืนยันตัวตนของ API
• ความรับผิดชอบต่อสาธารณะยังคงตกอยู่กับฝั่งผู้ปฏิบัติการ/นักพัฒนา

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

ในอนาคต หาก app store, ผู้ให้บริการชำระเงิน และคลาวด์ ใช้การประเมินความเสี่ยงอัตโนมัติมากขึ้น โครงสร้างแบบเดียวกันนี้ก็อาจยิ่งแข็งแรงขึ้น

• ผลลัพธ์จาก AI อาจถูกปักธงโดยอัตโนมัติ
• การตัดสินว่าละเมิดนโยบายอาจถูกสร้างขึ้นบ่อยกว่าเดิม
• การอุทธรณ์ของนักพัฒนา/ผู้ปฏิบัติการอาจกลายเป็นเพียงพิธีการ
• อาจยากที่จะสื่อสารโดยตรงกับผู้รับผิดชอบตัวจริง
• แอปหรือ SaaS ที่ทุ่มเทสร้างขึ้นมาและกำลังสร้างรายได้ อาจถูกจำกัดอย่างกะทันหัน

เพราะฉะนั้น นอกจากคุณภาพของโค้ดแล้ว บันทึกที่สามารถพิสูจน์ความรับผิดชอบได้ก็ยิ่งสำคัญขึ้น

• เอกสารสถาปัตยกรรม
• บันทึกการตรวจสอบความปลอดภัย
• เหตุผลของการเปลี่ยนแปลง dependency
• บันทึกการอนุมัติการดีพลอย
• ผู้รับผิดชอบ

---

5. วิธีรับมือ: บันทึกความรับผิดชอบที่ตรวจสอบได้

“ตราประทับของช่างฝีมือ” ที่ต้นฉบับกล่าวถึง ในทางปฏิบัติใกล้เคียงกับ บันทึกความรับผิดชอบที่ตรวจสอบได้ มากกว่า

สิ่งที่ต้องการไม่ใช่คำประกาศว่า “เราไม่ได้ใช้ AI”
สิ่งที่ต้องการคือบันทึกต่อไปนี้

• ใครเป็นคนกำหนด requirement?
• ส่วนใดถูกสร้างโดย AI?
• ส่วนใดถูกแก้ไขโดยมนุษย์?
• มนุษย์ได้ตรวจสอบอะไรจริงบ้าง?
• ผ่านการทดสอบอะไรบ้าง?
• มีการตรวจสอบความปลอดภัยหรือไม่?
• dependency ใหม่ถูกเพิ่มเข้ามาเพราะอะไร?
• ใครเป็นผู้อนุมัติการดีพลอย?
• ถ้าเกิดเหตุ ใครสามารถอธิบายและแก้ไขได้?

สรุปสั้นๆ

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