แฮ็ก Google ด้วย AI แล้วทำเงินได้ 7 ร้อยล้านวอน

• กรณีศึกษาของนักวิจัยด้านความปลอดภัยที่ให้ AI ไล่ทดสอบ API ของ Google แบบอัตโนมัติอย่างต่อเนื่อง จนทำรายได้จากบั๊กบาวน์ตีได้ 500,000 ดอลลาร์ภายใน 3 เดือน
• นำ API key ที่รวบรวมมาจากแอป Android กว่า 60,000 แอป มารวมกับ สเปก API ของ Google (discovery document) จนได้เป้าหมายทดสอบเป็น API มากกว่า 1,500 รายการ รวมถึง API ที่ไม่ค่อยเป็นที่รู้จักภายนอก
• เชื่อม เครื่องมือทดสอบ API เข้ากับ AI ที่อิง Claude เพื่อให้ส่งคำขอเหมือนมนุษย์ และค้นหา ช่องโหว่การควบคุมการเข้าถึง ที่ขาดการตรวจสอบสิทธิ์โดยอัตโนมัติ
• พบช่องโหว่ร้ายแรงจำนวนมาก เช่น การยึดบัญชี Google Voice, การรั่วไหลของวิดีโอส่วนตัวบน YouTube, การเปิดเผยคีย์ Widevine DRM, การติดตามตัวตนเจ้าของอุปกรณ์ Nest เป็นต้น
• ส่วนใหญ่ไม่ได้เกิดจากการโจมตีซับซ้อน แต่เกิดจากความผิดพลาดพื้นฐานที่ซ้ำๆ เช่น การไม่ตรวจสอบสิทธิ์, API ที่ไม่ต้องยืนยันตัวตน, สภาพแวดล้อมทดสอบที่เปิดเผยข้อมูลจริงตรงๆ

---

จุดเริ่มต้นของงานวิจัย

• ในเดือนตุลาคม 2025 เขาได้กลับมาโฟกัสการวิจัยที่มุ่งไปยัง Google อีกครั้ง จากโอกาสที่ได้รับเชิญไปงาน bugSWAT Mexico และความน่าสนใจที่สามารถเข้าไปดูซอร์สโค้ดของ Google ได้บางส่วน
• ตลอด 1 ปีที่ผ่านมา เขาสร้างโปรเจ็กต์ขนาดเล็กด้วย Claude และมองว่ามีโอกาสสูงในการใช้ AI เพื่อทดสอบ Google API แบบอัตโนมัติในวงกว้าง
• จุดเริ่มต้นสำคัญคือ discovery document — เอกสารแบบ Swagger ฉบับของ Google ที่อธิบายทุก endpoint, parameter และ method ในรูปแบบที่เครื่องอ่านได้
  • บางส่วนเปิดสาธารณะ เช่น YouTube Data API แต่ก็มีอยู่ใน API ภายในอย่าง Internal People API ด้วย
  • บางรายการเข้าถึงได้ตรงๆ แต่ส่วนใหญ่ต้องใช้ API key ที่ยังใช้ได้

การรวบรวม API key

• บ่อยครั้งที่คีย์ที่พบในบริการหนึ่งยัง เปิดใช้งานกับ API อื่นอีกหลายตัว ใน GCP project เดียวกัน ดังนั้นยิ่งมีคีย์มาก ก็ยิ่งเข้าถึง API ได้กว้างขึ้น
• เขาร่วมมือกับเพื่อนชื่อ Michael เพื่อเก็บคีย์
  • ดาวน์โหลด Android APK 61,200 ไฟล์ ที่รวมทุกเวอร์ชันของทุกแอป Google มาคลายแพ็กเกจแล้วค้นหา API key
  • ใช้ส่วนขยายที่อิง Chrome Debugger API ดักจับทราฟฟิก ระหว่างเข้าเยี่ยมชมเว็บโดเมน Google ที่รู้จักแล้วราว 2,800 โดเมน เพื่อเก็บคีย์จากคำขอจริงแบบเรียลไทม์
  • วิเคราะห์ Google iOS app (IPA) หลังถอดรหัส รวมถึงไบนารี Google อื่นๆ ที่หาได้ด้วย

• คัดเฉพาะคีย์ของ Google

  • เพื่อให้อยู่ในขอบเขต VRP จึงใช้ Cloud Marketplace API ตรวจสอบข้อมูลโปรเจ็กต์ที่ผูกกับคีย์ แล้วคัดคีย์ที่ไม่ใช่ของ Google ออก
  • เมื่อนำคีย์ไปใช้กับ API ที่ไม่มีสิทธิ์ ข้อความผิดพลาดที่ตอบกลับมาจะเผย หมายเลขโปรเจ็กต์ (เช่น "...in project 244648151629...")
  • จากหมายเลขนี้ เมื่อนำไป query จะได้ฟิลด์ company ที่บอกโดเมนเจ้าของโปรเจ็กต์ จึงทิ้งคีย์ที่ไม่ใช่ google.com (รวมถึงบริษัทที่ถูกซื้อกิจการอย่าง nest.com, fitbit.com, wing.com เป็นต้น)

การหาโดเมน Google API ที่ยังมีชีวิตอยู่

• นำโดเมนที่ส่วนขยายบันทึกไว้, โดเมนที่สร้างแบบ brute force จากคีย์เวิร์ด และ certificate transparency log มารวมกันเพื่อหาผู้ต้องสงสัย
• ส่งคำขอไปยังแต่ละโดเมน แล้วถ้า header Server เป็น ESF, GSE หรือ scaffolding on HTTPServer2 ก็ถือว่าเป็น Google API ที่ยังใช้งานได้จริง

กวาดสเปกที่ซ่อนอยู่ด้วย

• ในเดือนกรกฎาคม 2025 Google ถอด path /$discovery/rest ออกจาก API ส่วนใหญ่ แต่บางรายการยังอ้อมเข้าถึงได้

• endpoint ที่ถูกซ่อนด้วย Visibility Label

  • บางโปรเจ็กต์เปิดใช้ visibility label ทำให้เข้าถึง endpoint ที่ซ่อนได้ก็ต่อเมื่อส่งพารามิเตอร์ labels มาด้วย
  • หากดึงสเปกของ Service Management API โดยไม่ใส่ label จะได้ 253KB แต่ถ้าเพิ่ม ?labels=GOOGLE_INTERNAL จะเพิ่มเป็น 329KB และเผยเอกสารที่ซ่อนไว้จำนวนมาก
  • ระบบรับ label ได้ครั้งละหนึ่งค่า จึงต้องยิงคำขอจำนวนมหาศาลเพื่อทดสอบทุก label กับทุก key และทุก API
• จากวิธีนี้จึงเก็บสเปกของ API มากกว่า 1,500 รายการ ได้สำเร็จ และเมื่อรวมกับเอกสารที่สะสมจากงานวิจัยก่อนหน้า ก็พร้อมสำหรับการทดสอบอัตโนมัติด้วย AI

การแก้ปัญหาเรื่องการยืนยันตัวตน

• API key ช่วยเรื่อง “สิทธิ์” ได้ แต่หลาย endpoint ยังต้องมี authentication เพื่อยืนยันว่าผู้เรียกคือใคร
• Bearer token ผูกกับ GCP project จึงผสมกับ API key ไม่ได้ เพราะจะเจอข้อผิดพลาดแบบ “คนละโปรเจ็กต์” และไม่มีวิธี bypass ที่รู้จัก

• First Party Authentication (FPA)

  • API จำนวนมากรองรับระบบยืนยันตัวตนเฉพาะของ Google ที่ชื่อ FPA ซึ่งทำงานร่วมกับ API key ได้
  • คำขอจากเว็บจะใส่ session Cookie และค่า Authorization ที่คำนวณจากมัน แล้วส่งไปยังโฮสต์ *.clients6.google.com
  • API บางตัว เช่น drivefrontend-pa ต้องใช้ header แบบ FPA v2 ที่ครบกว่าเดิม โดยใส่ hash ของตัวระบุผู้ใช้อย่างอีเมลด้วย
  • Michael พบ sourcemap ที่ Google เคยเผลอปล่อยไว้ช่วงหนึ่ง ทำให้ได้โค้ดสร้าง header FPA v2 จากไลบรารีภายในชื่อ gapix

• โครงสร้างโทเคนและ Gaia ID

  • รูปแบบโทเคนคือ <timestamp>_<hash>_<identifierKey> และอินพุตของ SHA1 คือ "email:gaiaId timestamp sessionCookie origin"
  • identifier key มีแค่ 3 ค่า คือ e (อีเมล), u (Gaia ID แบบ obfuscated) และ a (โดเมน Workspace) โดยอักขระอื่นฝั่ง backend จะเพิกเฉย
  • Gaia ย่อมาจาก "Google Accounts and ID Administration" และทุกบัญชีจะมี unobfuscated Gaia ID แบบเรียงลำดับ (เช่น 131337133377) กับ ID แบบ obfuscated ที่ยาวกว่า

• Origin whitelist และข้อจำกัดของคีย์

  • หลาย API มีรายการ Origin ที่อนุญาตไว้ และถ้าใช้ origin ที่ไม่อยู่ในรายการจะได้ข้อผิดพลาด SESSION_COOKIE_INVALID ซึ่งทำให้เข้าใจผิดเหมือนเป็นปัญหา cookie
  • คีย์มีข้อจำกัด 4 แบบคือ Server, Browser, Android, iOS โดย Browser ต้องตรงกับ Referer, iOS ต้องตรงกับ X-Ios-Bundle-Identifier, ส่วน Android ต้องตรงกับ X-Android-Package และลายนิ้วมือใบรับรอง
  • ระหว่างเก็บคีย์จึงเก็บค่าเหล่านี้ไว้ด้วย แล้วรวมการ brute force เข้ามาในโปรแกรมเดียวกัน
  • origin แบบ *.corp.google.com ไม่มีข้อจำกัด ทำให้ API ลักษณะนี้มีแนวโน้มเป็น API ภายในที่ไม่ได้ตั้งใจเปิดสาธารณะและมักมีบั๊กเยอะ — เคสหนึ่งได้รางวัล $9,000 จากช่องโหว่การควบคุมการเข้าถึง

ทำแผนที่ลำดับการปฏิเสธคำขอและสร้างเครื่องมือทดสอบเอง

• เขาสร้างโปรแกรมเพื่อจำแนกว่าแต่ละคำขอถูกปฏิเสธในขั้นไหน (ตีความ method → ตรวจความถูกต้องของ key → ตรวจข้อจำกัดของ key → authentication → ตรวจ origin → label ฯลฯ) เพื่อทำ ตารางจับคู่ว่าคีย์ใดใช้กับ API ใดได้
• เนื่องจาก API Explorer ของ Google รองรับเฉพาะ API สาธารณะและตัวระบบไม่เปิดให้ใช้ตรงๆ เขาจึงสร้าง API Explorer ของตัวเองที่รองรับถึง FPA v2 ใช้เวลาราวหนึ่งสัปดาห์
  • ตัวไคลเอนต์จะ parse สเปกแล้วสร้าง JSON คำขอ/คำตอบที่ถูกต้องโดยอัตโนมัติ พร้อม UI สำหรับลอง payload แบบกำหนดเองได้รวดเร็ว
  • endpoint ที่ใช้ในเดโมเป็นบั๊กการควบคุมการเข้าถึงซึ่งเผย assignedTams (ผู้จัดการบัญชีเทคนิค) และได้รางวัล $6,000

การตั้งค่าระบบทดสอบอัตโนมัติด้วย AI

• เป้าหมายคือให้ AI ค้นหาปัญหาการควบคุมการเข้าถึงขั้นพื้นฐานโดยอัตโนมัติ แล้วให้มนุษย์นำไปขยายต่อเป็นช่องโหว่ที่รุนแรงกว่า
• เขานำโค้ด parse JSON ของฟรอนต์เอนด์ไปเชื่อมเป็น เครื่องมือ MCP ให้ AI ใช้ทดสอบ API ได้เหมือนคน

• ให้ละเอียดขึ้น และเงียบขึ้น

  • ในช่วงแรก AI ลองไม่กี่ครั้งแล้วจบเร็วเกินไป จึงเพิ่ม Ralph Wiggum loop บังคับให้ต้องทดสอบทุก endpoint อย่างน้อย 1 ครั้งก่อนจะหยุดได้
  • แบ่ง endpoint เป็น กลุ่มเชิงตรรกะ ก่อน แล้วทดสอบเป็นกลุ่ม พร้อมส่งต่อสิ่งที่พบจากกลุ่มก่อนหน้าให้กลุ่มถัดไป
  • ลดความซับซ้อนของอินพุต probe_api ให้เหลือแค่ endpoint, path, body ส่วน authentication แบบ FPA ที่ซับซ้อนให้ backend จัดการแทน เพื่อให้ AI โฟกัสกับการเขียน payload
  • เพราะคำตอบอาจต่างกันไปตามแต่ละ key จึง ส่งคำขอเดียวกันด้วยทุก key โดยอัตโนมัติ และรวมคำตอบที่เหมือนกันด้วย hash
  • แปลข้อผิดพลาดที่ชวนสับสนอย่าง "Method not found" เป็น MISSING_REQUIRED_VISIBILITY_LABEL เป็นต้น เพื่อลดความสับสนของ AI

• แก้ปัญหาเรื่อง noise และการตรวจยืนยัน

  • ช่วงแรกบั๊กจริงถูกกลบด้วย noise ถึง 90% ทำให้มีสองปัญหาหลักคือ ยืนยันผลยาก และ false positive มากเกินไป
  • เขาใส่ operation ID ที่ชี้ไปยังคำขอจริงในรายงาน เพื่อให้ฟรอนต์เอนด์กด "Play" แล้วทำซ้ำได้ทันที เป็นหลักฐานที่แก้ไขไม่ได้
  • ใช้เวลากว่าหนึ่งเดือนในการปรับ system prompt ให้เกณฑ์รายงานชัดเจนขึ้น — รายงานเฉพาะกรณีที่ เข้าถึงข้อมูลของผู้ใช้อื่น หรือได้ 2xx ในจุดที่ควรเป็น 4xx ส่วน existence enumeration แบบธรรมดาไม่ถือเป็นช่องโหว่
  • หลังจากนั้น AI สามารถค้นพบบั๊กจำนวนมากด้วย ความแม่นยำเกิน 50% โดยข้อจำกัดเดียวคือจำนวน API key ที่มีอยู่

ช่องโหว่สำคัญที่ค้นพบ

• ภายในเวลาไม่ถึง 3 เดือน พบช่องโหว่มูลค่ารวม $500,000 โดยตัวอย่างเด่นด้านล่างล้วนถูกแก้ไขแล้ว

• การยึดบัญชี Google Voice

  • gfibervoice-pa ไม่มีการควบคุมการเข้าถึงเลย ทำให้ใช้ curl เพียงบรรทัดเดียวโดยไม่ต้องยืนยันตัวตน ก็ dump PII ทั้งหมดได้ หากรู้เพียง unobfuscated Gaia ID ของเหยื่อ เช่น หมายเลขโทรศัพท์และที่อยู่รับการแจ้งเตือน
  • ในคำตอบยังสามารถเห็น หมายเลขโทรศัพท์กู้คืนบัญชี Google ของเหยื่อได้ด้วย (แสดงเฉพาะบางเงื่อนไข ซึ่ง Google ไม่เปิดเผยรายละเอียด)
  • ยังมี endpoint ที่บังคับผูกหมายเลข Voice ให้บัญชีใดก็ได้ (แม้จะขึ้น error 500 แต่หมายเลขถูกเพิ่มจริง) และยังพบ endpoint ที่อาจใช้ทำ SIM swap ได้
  • ถูกจัดระดับเป็น P0/S0 และแพตช์ภายในไม่กี่ชั่วโมง พร้อมรับรางวัล $20,000
  • หลังแพตช์ทันที เขายังพบการเปิดเผย zhandler สำหรับอินทราเน็ตเท่านั้น เช่น /btz และหากเข้าถึง /flagz ได้ก็สามารถดึง API key จาก service ที่กำลังรันอยู่

• การยึดบัญชี AdExchange

  • พบ endpoint ที่ dump รายชื่อบัญชี AdExchange ทั้งหมด ได้ด้วยคำขอเพียงครั้งเดียว
  • endpoint ด้านบัญชีที่ถูกปิดกั้นใน production กลับ ทำงานแบบไม่มีการควบคุมการเข้าถึงในสภาพแวดล้อม staging และ staging นั้นชี้ไปยังข้อมูล production จริง
  • ยังสามารถเพิ่มตัวเองเป็น ADMIN ให้บัญชีใดก็ได้ รายงานสองฉบับนี้รวมกันได้รางวัล $30,000

• eldar.corp.google.com

  • API ของ Eldar ซึ่งเป็นเว็บสำหรับพนักงาน Google ใช้จัดการการประเมินด้านความเป็นส่วนตัว ถูกเปิดให้เข้าถึงจากภายนอก ทำให้คนที่ไม่ใช่ Googler สามารถดูข้อมูลอ่อนไหว เช่น คำขอเข้าถึงล็อกภายใน
  • หลังจากถูกบล็อกแล้ว เขายังแจ้งต่อว่ามันเข้าถึงได้ผ่าน sandbox address อื่นอีก รวมรับรางวัล $26,674

• การรั่วไหลของวิดีโอส่วนตัวบน YouTube

  • ชื่อ asset ที่สร้างตอนอัปโหลดวิดีโออยู่ในรูป Auto generated asset - <video_id> ทำให้แค่ค้นหาก็ ทำให้ video ID ของวิดีโอ private รั่วไหล และเปิดดูได้
  • หากร้องขอทุก 30 วินาที ก็จะได้ฟีดแบบเรียลไทม์ของวิดีโอ private ที่อัปโหลดโดยพาร์ตเนอร์ — เป็นภัยจริงที่อาจถูกใช้ พนันวงในในตลาดคาดการณ์ จากกรณีที่บริษัทอัปโหลดวิดีโอเปิดตัวสินค้าล่วงหน้าแบบ private
  • ได้รางวัล $12,000 (รายงานคุณภาพสูง)

• การเปิดเผยคีย์ Widevine DRM

  • API ของพอร์ทัลพาร์ตเนอร์สำหรับ Widevine ซึ่งเป็น DRM ขนาดใหญ่ที่สุดในโลกที่ Disney, Netflix และรายอื่นใช้งาน ถูกเปิดให้เข้าถึงสาธารณะ
  • สามารถ dump รายชื่อองค์กรทั้งหมด, ดูและถอดรหัส คีย์ PGP และ AES ขององค์กรใดก็ได้, รวมถึงเพิ่มตัวเองเข้าองค์กรใดก็ได้เพื่อจัดการอุปกรณ์
  • ได้รางวัล $16,004.40 (รายงานคุณภาพสูง)

• plx.corp.google.com

  • DataHub API ที่เป็นฐานของแพลตฟอร์มวิเคราะห์ภายในสำหรับพนักงานชื่อ PLX ถูกเปิดเผย ทำให้ดู metadata ของตารางข้อมูลพนักงานที่ยังใช้งานอยู่ได้
  • ใน staging API ยังสามารถใช้ setIamPolicy เพื่อ เพิ่มตัวเองเป็น dataset admin แล้ว dump ข้อมูลลับของ YouTube ได้ รวมถึงตารางขนาดสูงสุด 2.1PB
  • ภายใน 1 ชั่วโมงก็ถูกยอมรับเป็น P0/S0 และช่องโหว่สองรายการนี้ได้รางวัลรายการละ $12,000

ช่องโหว่ข้ามเทนเนนต์ใน Translation Hub

• พบปัญหาการควบคุมการเข้าถึงหลายรายการใน Translation Hub ซึ่งเป็นผลิตภัณฑ์สำหรับจัดการงานแปลเอกสารขนาดใหญ่
• ListOperations ทำงานได้โดยไม่ต้องมี OAuth token ทำให้ข้อมูลอย่างชื่อ service account ภายใน, ชื่อ GCS bucket และชื่อตารางภายในรั่วไหล
• เพียงมี bearer token ของบัญชี Google ใดก็ได้ ก็สามารถดูข้อมูลของโปรเจ็กต์อื่น เช่น อีเมลนักแปลและชื่อไฟล์ลับของงาน
• หากใช้ UpdateProjectConfig เปลี่ยนการตั้งค่าของเหยื่อให้ชี้ไปยัง path ของ GCS ตามต้องการ ก็จะอาศัยสิทธิ์ของ shared service account เพื่อ ดูด GCS object ส่วนตัวออกมาในรูป base64 ได้
• บั๊กทั้ง 3 รายการรวมกันได้รางวัล $36,500

YouTube TV CMS

• ใน API สำหรับบัญชี YouTube CMS ที่สามารถ strike, claim และ monetize วิดีโอได้ endpoint ฝั่ง campaign ไม่ตรวจสอบความสัมพันธ์ของผู้เรียกเลย
• GET /v1/campaigns สามารถ dump campaign ทั้งระบบแบบ global ได้โดยไม่มี scoping และยังแก้ไข, คัดลอก, ลบ ได้เพียงรู้ ID
• ผลข้างเคียงคืออีเมลของบัญชี CMS ที่อ่อนไหวรั่วไหล และได้รางวัล $24,000 (รายงานคุณภาพสูง)

Vertex AI Search for Commerce

• conversationalSearchCustomizationConfig ของผลิตภัณฑ์ค้นหาและแนะนำสำหรับค้าปลีก เปิดให้อ่านและแก้ไขการตั้งค่าของโปรเจ็กต์ใดก็ได้โดยไม่มีการควบคุมการเข้าถึง
• ฝั่งอ่านเผย system prompt (model preamble) ของลูกค้า พร้อมตัวอย่างการจัดหมวดหมู่ที่มีบันทึกนโยบายภายในแนบอยู่
• ฝั่งเขียนสามารถ ฉีด payload สำหรับ prompt injection เข้า system prompt ของ AI ค้นหาที่ลูกค้าใช้งานจริง และได้รางวัล $30,000

Cloud Console GraphQL

• แม้บริการภายในที่ไม่เปิดบนอินเทอร์เน็ตก็ยัง เข้าถึงทางอ้อมผ่านพื้นผิว proxy ได้ โดย Cloud Console (โค้ดเนม Pantheon) ใช้ GraphQL เป็น proxy ไปยัง gRPC backend

• การข้ามการตรวจสอบลายเซ็น

  • ทุกคำขอต้องตรวจสอบลายเซ็นของ query (querySignature) ทำให้แก้ไขได้ยาก แต่เขาพบว่า query ที่ไม่ต้องยืนยันตัวตนใน staging ไม่ตรวจสอบลายเซ็น
  • เขาใช้ introspection กวาดสคีมา 3,448 รายการมา archive ไว้บน GitHub และนำแนวคิด “query path” มาผสาน GraphQL เข้ากับโครงสร้าง AI fuzzing เดิม

• App Engine request log

  • GetDashboardAppStats ส่งคืน App Engine log ย้อนหลัง 24 ชั่วโมงของโปรเจ็กต์ใดก็ได้ โดยไม่ตรวจ IAM (และไม่ต้องยืนยันตัวตนด้วย)
  • เนื่องจาก URL คำขออาจมีลิงก์รีเซ็ตรหัสผ่านหรือโทเคนต่างๆ อยู่ด้วย จึงได้รางวัล $18,000 และได้รับการกำหนด CVE-2026-8934

• Vertex Assistant

  • จากการวิเคราะห์ JavaScript ฝั่งฟรอนต์เอนด์ขนาด 5GB เขาพบฟีเจอร์ทดลองที่ซ่อนอยู่ชื่อ Vertex Assistant และบังคับเปิด feature flag ผ่าน DevTools
  • query ที่เกี่ยวข้องทั้งหมดทำงานได้โดยไม่ต้องยืนยันตัวตน เพียงมี userId ก็พอ ทำให้หากรู้แค่อีเมลเป้าหมายก็สามารถ ดูและแก้ไขรายการเซสชันกับประวัติการสนทนาทั้งหมด ได้ และได้รางวัล $30,000

• เครดิตบิลลิงของ Maps Platform

  • ListBillingAccountCredits ทำงานโดยไม่ตรวจสอบสิทธิ์ และใช้ wildcard เพื่อดึงข้อมูลเครดิตของลูกค้าจำนวนมากได้
  • ข้อมูล PII ของลูกค้า ที่พนักงาน Google เขียนไว้ตอนอนุมัติ ถูกเปิดเผยตรงๆ ในฟิลด์ justification และได้รางวัล $12,000

บทสรุปและบทเรียน

• ภายใน 3 เดือน เขาเก็บบาวน์ตีได้ มากกว่า $500,000 ด้วยการตั้งค่านี้ และสิ่งที่เผยแพร่เป็นเพียงบางส่วนเท่านั้น
• บั๊กส่วนใหญ่ของ Google ไม่ได้ต้องอาศัย exploit ที่ซับซ้อน แต่ต้องอาศัย ความอดทน เพราะรูปแบบที่พังแบบเดิมๆ ปรากฏซ้ำไปทั่ว — ขาดการเช็ก IAM, GraphQL ที่ไม่ต้องยืนยันตัวตน, debug endpoint ใน production, sandbox ที่ชี้ไปข้อมูลจริง
• บทบาทของ AI ไม่ใช่ความแปลกใหม่ แต่คือการ ตรวจสิ่งที่ชัดเจนซ้ำๆ อย่างไม่เหนื่อยล้า บนพื้นผิวที่กว้างเกินกว่ามนุษย์จะไล่ทำจนสุดได้
• ประเด็นสำคัญ
  • ระบบทำซ้ำด้วย operation_id คือองค์ประกอบชี้ขาดที่ทำให้ workflow มีประสิทธิภาพ — ถ้าไม่มีการยืนยันแบบคลิกเดียว ผลลัพธ์จาก AI ก็เป็นแค่ noise ที่ใช้ประโยชน์ไม่ได้
  • หากมี discovery doc, GraphQL SDL และ proto ก็ทำให้ AI เข้าใจอินพุตที่ควรใช้ทดสอบได้อย่างมีความหมาย
  • พื้นผิวฝั่งเซิร์ฟเวอร์ของ Google มีความเป็นมาตรฐานสูงมาก ดังนั้นถ้าแยกรายละเอียดเฉพาะของอินฟราออกจาก AI ได้ ก็จะทำให้โฟกัสกับการทดสอบ API จริงๆ ได้มากขึ้น

[j2sus91]

นี่แหละแนวคิดการทำเงินแบบใหม่อย่างแท้จริงของ vibe coding