Google แก้บั๊ก Chrome ด้วย AI ในเดือนมิถุนายนมากกว่าตลอด 2 ปีที่ผ่านมา

 (blog.google)
1 คะแนน โดย GN⁺ 3 시간 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • Chrome ใช้ เอเจนต์ที่ขับเคลื่อนด้วย Gemini เพื่อทำงานอัตโนมัติตั้งแต่การค้นหาช่องโหว่ การจัดหมวดหมู่ การแก้ไข การปล่อยอัปเดต ไปจนถึงการนำอัปเดตไปใช้ และใน Chrome 149 กับ 150 ได้แก้บั๊กด้านความปลอดภัย 1,072 รายการ มากกว่าผลรวมของ 23 ไมล์สโตนก่อนหน้า
  • ระบบตรวจจับช่องโหว่ทำงานโดยผสานหลายโมเดลเข้ากับคลังความรู้จากประวัติ CVE และ Git ของ Chrome, SECURITY.md, และเอเจนต์วิจารณ์แยกต่างหาก ภายใต้สภาพแวดล้อมที่จำกัดการเข้าถึงอินเทอร์เน็ตและระบบภายในอย่างเข้มงวด
  • การจัดหมวดหมู่อัตโนมัติทำหน้าที่ลบสแปมและรายการซ้ำ รวบรวมการทำซ้ำและ stack trace เพิ่มเมทาดาทาอย่างระดับความรุนแรง และมอบหมายผู้รับผิดชอบ ซึ่งประเมินว่าช่วยลด เวลาทำงานของนักพัฒนาหลายร้อยชั่วโมงต่อเดือน
  • เพื่อลด ช่องว่างของแพตช์ ระหว่างการเปิดเผยแพตช์กับการถูกนำไปโจมตี กำลังทดสอบการออกรุ่นความปลอดภัยสัปดาห์ละ 2 ครั้ง พร้อมพัฒนา dynamic patching ที่สลับ child process โดยไม่ต้องรีสตาร์ต และการรีสตาร์ตอัตโนมัติบน macOS
  • ไม่ได้หยุดแค่การแก้บั๊กรายตัว แต่ยังเพิ่มความปลอดภัยของหน่วยความจำด้วย MiraclePtr, std::span, และ Rust พร้อมป้องกันการนำช่องโหว่เข้ามาตั้งแต่ต้นทางด้วยการตรวจด้วย AI ตอนส่งโค้ดและการอัปเดต dependency ภายนอกอัตโนมัติกว่า 2,300 รายการ

วงจรชีวิตของบั๊กความปลอดภัยที่ AI เปลี่ยนไป

  • LLM ได้ขยายขอบเขตของ การตรวจหาช่องโหว่อัตโนมัติ ให้เกินกว่าระดับที่ผู้เชี่ยวชาญด้านความปลอดภัยของมนุษย์จะรับมือได้เพียงลำพัง และ Chrome ใช้ AI เพื่อค้นหาและแก้บั๊กความปลอดภัยหลายร้อยรายการได้เร็วขึ้น
  • ต่างจากบั๊กฟีเจอร์ทั่วไปที่อาจทำให้ UI ค้าง บั๊กความปลอดภัยอาจถูกใช้ใน exploit เพื่อให้อ่านข้อมูลส่วนตัวหรือควบคุมคอมพิวเตอร์ของผู้ใช้โดยที่เจ้าตัวไม่รู้
  • บั๊กความปลอดภัยถูกจัดการตามลำดับคือ การค้นพบ การจัดหมวดหมู่ การแก้ไข การปล่อย Chrome ที่รวมแพตช์ และการรีสตาร์ตเบราว์เซอร์เพื่อนำไปใช้ โดยมีเป้าหมายคือย่นทุกขั้นตอนให้สั้นที่สุด

การขยายการตรวจจับช่องโหว่

  • ทีมความปลอดภัยของ Chrome ได้พัฒนาเทคนิคการตรวจจับที่ใช้ LLM มาเป็นเวลาหลายปี
  • Gemini agent harness ที่สร้างขึ้นในต้นปี 2026 ช่วยเพิ่มประสิทธิภาพการตรวจจับในโค้ดเบสของ Chrome ที่กว้างขึ้นและลด false positive
    • บั๊ก sandbox escape ที่ตรวจพบนี้อาจทำให้ renderer ที่ถูกเจาะหลอกเบราว์เซอร์ให้อ่านไฟล์ในเครื่องได้ และค้างอยู่ในโค้ดมานานกว่า 13 ปี
  • มีการเพิ่มความสามารถต่อไปนี้เข้าไปใน harness สำหรับการตรวจจับ
    • การทำงานร่วมกันข้ามโมเดล ที่ใช้จุดแข็งของทั้งโมเดล open weight และโมเดล proprietary
    • คลังความรู้ที่รวม CVE ทั้งหมดเดิมและประวัติ Git ทั้งหมดของ Chrome
    • แนวทางการเขียน SECURITY.md เพื่อสื่อสาร trust boundary และ threat model ให้ชัดเจน
    • เอเจนต์วิจารณ์ที่อ่าน SECURITY.md ในคอนเท็กซ์แยกต่างหาก
    • การตรวจโค้ดเบสซ้ำหลายรอบเพื่อสะท้อนทั้งความไม่แน่นอนของโมเดลและการพัฒนาที่ดีขึ้นตามเวลา
  • AI วิเคราะห์เฉพาะ ซอร์สโค้ดที่จัดเก็บไว้เท่านั้น บนอุปกรณ์ที่ถูกล็อกและไม่สามารถเข้าถึงอินเทอร์เน็ตทั่วไปได้
    • มีการดักทุกคำขอเครือข่ายและใช้ allowlist ตามแอปพลิเคชันและปลายทาง
    • ไม่รันโมเดลในโหมดไม่จำกัด และจำกัดการเปลี่ยนแปลงระบบของ sub-agent รวมถึงการเข้าถึงไฟล์นอกไดเรกทอรีซอร์สที่กำหนด
  • การตรวจจับด้วย AI ไม่ได้มาแทนที่การทดสอบความปลอดภัยแบบเดิม
    • Fuzzing มีประสิทธิภาพเป็นพิเศษกับบั๊กที่เกิดจากปฏิสัมพันธ์ระยะไกลระหว่างส่วนของโค้ดที่ห่างกัน หรือจากการรวมกันของหลายการทำงานที่ดูไม่เกี่ยวข้องกัน
  • นักวิจัยภายนอกยังคงได้รับรางวัลผ่าน Chrome Vulnerability Reward Program เพื่อค้นหาช่องโหว่ที่ยากและมีผลกระทบสูงต่อไป
    • ต้นปี 2026 จำนวนรายงานทุกประเภทเพิ่มขึ้น และในเดือนมีนาคมมีรายงานบั๊กมากกว่าทั้งปี 2025
    • จึงมีการ ปรับ VRP เพื่อเน้นรายงานที่เพิ่มคุณค่าเหนือผลการตรวจจับภายใน และที่ pipeline อัตโนมัติสามารถรับมือได้ง่าย

การจัดหมวดหมู่อัตโนมัติและการแก้ไขแบบหลายเอเจนต์

  • ในอดีต การจัดหมวดหมู่รายงานด้านความปลอดภัยหนึ่งรายการใช้เวลา ตั้งแต่ 5 นาทีไปจนเกิน 30 นาที และพึ่งพาความเชี่ยวชาญของคนเป็นหลัก แต่ตอนนี้ผสานระบบ rule-based กับ AI เพื่อเพิ่มทั้งปริมาณงานที่ทำได้และความแม่นยำ
  • การจัดหมวดหมู่อัตโนมัติทำงาน 4 ขั้นตอน
    1. ลบสแปมและรายการซ้ำ แล้วตรวจว่าตรงตามเกณฑ์การรับเรื่องหรือไม่ และมีคำอธิบายที่ชัดเจนว่าเป็นช่องโหว่ความปลอดภัยของ Chrome หรือไม่
    2. ตรวจ proof of concept และความสามารถในการทำซ้ำ ทดสอบบนระบบปฏิบัติการและเวอร์ชันเบราว์เซอร์ที่เกี่ยวข้อง แล้วแนบข้อมูลอย่าง stack trace
    3. เพิ่มข้อมูลว่าบั๊กถูกนำเข้ามาครั้งแรกเมื่อใด และเพิ่มระดับความรุนแรง
      • มีการปรับแนวทางระดับความรุนแรงให้ชัดเจนเพื่อให้นำไปใช้แบบอัตโนมัติได้ง่าย
      • นักพัฒนาสามารถเปลี่ยนระดับความรุนแรงที่ไม่ถูกต้อง และเสริมข้อมูล security boundary ผ่าน SECURITY.md ได้
    4. มอบหมายปัญหาไปยังคอมโพเนนต์และผู้รับผิดชอบที่ถูกต้องโดยอัตโนมัติ
  • แม้วัดได้อย่างแม่นยำยาก แต่ประเมินว่าการจัดหมวดหมู่อัตโนมัติช่วยลดเวลาทำงานของนักพัฒนาหลายร้อยชั่วโมงต่อเดือน
  • การแก้ไขช่องโหว่ใช้ workflow แบบหลายเอเจนต์
    • เอเจนต์แก้ไขจะรับคอนเท็กซ์เฉพาะของแต่ละปัญหาและสร้างแพตช์ตัวเลือกหลายแบบ
    • เอเจนต์วิจารณ์จะประเมินตัวเลือกที่เหมาะสมที่สุดและสร้างผลลัพธ์ที่จำเป็นต่อการรีวิวของนักพัฒนา
    • ทั้งสองเอเจนต์ทำงานวนซ้ำคล้าย code review เพื่อตรวจสอบพฤติกรรมของฟังก์ชัน ความสอดคล้องกับสไตล์ของ Chromium และ Google รวมถึงธรรมเนียมของโค้ดภายในพื้นที่นั้น
    • เอเจนต์เขียนทดสอบจะตรวจสอบเทสต์ให้ครอบคลุมแพลตฟอร์มและคอนฟิกที่ Chrome รองรับก่อนถึงมือนักพัฒนา ซึ่งช่วยประหยัดเวลาได้สูงสุดหลายสัปดาห์
  • ปัจจุบัน LLM สร้างตัวเลือกการแก้ไขให้กับช่องโหว่ส่วนใหญ่
    • ใน Chrome 149 และ 150 มีการแก้บั๊กความปลอดภัย 1,072 รายการ มากกว่าผลรวมของ 23 ไมล์สโตนก่อนหน้านั้น
  • Big Sleep และ CodeMender ที่พัฒนาร่วมกับ DeepMind และ Project Zero ถูกผสานเข้ากับ CI เพื่อตรวจทุก CL ทุก 24 ชั่วโมง
    • ในเดือนพฤษภาคมเดือนเดียว สามารถสกัด ช่องโหว่มากกว่า 20 รายการ ไม่ให้ไปถึง production รวมถึงปัญหาระดับวิกฤต S1+

การย่นช่องว่างของแพตช์และการนำอัปเดตไปใช้

  • ช่วงที่ผู้โจมตีสามารถ reverse engineer แพตช์หลังจากโค้ดแก้ไขเข้าไปอยู่ในคลังโอเพนซอร์สสาธารณะแล้ว แต่ก่อนจะถูกแจกจ่ายถึงผู้ใช้และถูกนำไปใช้จริง เรียกว่า การโจมตีแบบ N-day และช่องเวลานี้เรียกว่า patch gap
  • โดยทั่วไปกว่าที่แพตช์ที่ merge เข้า main tree จะไปถึงช่องทาง Stable ที่ผู้ใช้ส่วนใหญ่ใช้งาน มักใช้เวลาหลายสัปดาห์
    • ตามระดับความรุนแรง แพตช์บางส่วนจะถูก merge ตรงเข้า release branch ของ Stable ปัจจุบัน และมีการเฝ้าระวัง crash ใหม่หรือ regression อย่างต่อเนื่อง
    • หลังเปลี่ยน Chrome milestone หลักเป็นรอบ ทุก 2 สัปดาห์ ก็มีการปล่อยอัปเดตความปลอดภัยทุกสัปดาห์
    • เพื่อรับมือกับความเร็วของการโจมตีที่ใช้ AI กำลังทดสอบ การออกรุ่นความปลอดภัยสัปดาห์ละ 2 ครั้ง ด้วย
  • บั๊กความปลอดภัยทั้งหมดที่ไปถึง Stable จะถูกบันทึกเปิดเผยต่อสาธารณะ ไม่ว่าจะค้นพบจากภายในหรือภายนอก
    • กำลังทำระบบสร้าง release note และคำอธิบาย CVE จากแพตช์โดยอัตโนมัติ เพื่อลดคอขวดแบบ manual และย่นเวลาจากการค้นพบไปสู่การเปิดเผย
  • Chrome ใช้ระบบอัปเดตอัตโนมัติมาตั้งแต่ปี 2008 โดยดาวน์โหลดไบนารีใหม่ไว้เบื้องหลังและนำไปใช้ตอนรีสตาร์ตครั้งถัดไป
    • แม้การจัดหมวดหมู่ แก้ไข ทดสอบ และปล่อยอัปเดตจะใช้เวลา 1-2 วัน แต่การรอจนกว่าผู้ใช้จะรีสตาร์ตก็อาจเพิ่มความเสี่ยงจากการโจมตีแบบ N-day อย่างมาก
    • การรีสตาร์ตรบกวนการทำงานและต้องหาเวลามาทำแยกต่างหาก จึงเป็นเรื่องที่ผู้ใช้มักเลื่อนออกไป
  • กำลังพัฒนาฟีเจอร์เพื่อไม่ผลักภาระการรีสตาร์ตไปให้ผู้ใช้
    • Dynamic patching ใช้โครงสร้างหลายโปรเซสของ Chrome เพื่อสลับ child process เบื้องหลังอย่าง Renderer และ GPU ไปเป็นไบนารีใหม่ทีละตัว โดยมีเป้าหมายให้ส่วนใหญ่ไม่ต้องรีสตาร์ตทั้งเบราว์เซอร์
    • กำลังพิจารณาวิธีเก็บสถานะในเครื่องให้มากขึ้นเพื่อให้กู้คืนเซสชันได้แม้ในสถานการณ์ซับซ้อน
    • จะรีสตาร์ตอัตโนมัติเมื่อมั่นใจว่าสามารถกู้คืนเซสชันได้ครบถ้วน
    • Chrome 150 ตรวจจับบน macOS ได้ว่าหน้าต่างทั้งหมดถูกปิดแล้วแต่แอปยังคงอยู่เบื้องหลัง และหากมีอัปเดตรออยู่ก็จะรีสตาร์ตอัตโนมัติ
  • ระยะยาวมีเป้าหมายเป็น เบราว์เซอร์ที่อัปเดตล่าสุดเสมอ โดยผสาน dynamic patching อย่างต่อเนื่องเข้ากับการรีสตาร์ตอัตโนมัติในช่วงที่รบกวนน้อย
  • คำแนะนำสำหรับผู้ดูแลระบบ IT ในองค์กรมีดังนี้
    • ใช้นโยบาย RelaunchNotification เพื่อไล่ระดับตั้งแต่การแจ้งเตือนไปจนถึงการบังคับรีสตาร์ตหลังระยะเวลาที่กำหนด
    • ในสภาพแวดล้อมที่อ่อนไหวและต้องตรวจสอบการเปลี่ยนแปลงก่อน ให้ใช้ Chrome Extended Stable Channel
    • ใช้แดชบอร์ดที่ไม่ขึ้นกับระบบปฏิบัติการของ Chrome Enterprise Core หรือ Premium เพื่อติดตามเวอร์ชันเบราว์เซอร์ทั้งหมดและจัดการอัปเดตอย่างละเอียด

การป้องกันใน C++ และการย้ายไป Rust

  • Chrome ใช้กลยุทธ์สองทาง คือทำให้ช่องโหว่ C++ เดิมใช้โจมตีไม่ได้ใน runtime ไปพร้อมกับเดินหน้าสู่ ภาษาแบบ memory-safe ในระยะยาว
  • เนื่องจากโค้ด Chromium ส่วนใหญ่ยังเป็น C++ toolchain และการลดผลกระทบใน runtime จึงเป็นแนวป้องกันด่านแรกที่ใช้ได้ทันที
    • มีการลดช่องโหว่แบบ Use-After-Free (UAF) ด้วย standard template library แบบเสริมความแข็งแรงและเทคโนโลยีตระกูล MiraclePtr
  • โรดแมปการป้องกัน C++ ประกอบด้วย 3 แกน
    • ขยาย MiraclePtr และ MiracleObject
      • ขยาย MiraclePtr ไปยัง Skia, ANGLE, Dawn, C++ iterator และ std:: container
      • MiracleObject มีเป้าหมายแลกประสิทธิภาพ runtime เฉพาะจุดกับ temporal safety เพื่อทำให้ช่องโหว่ UAF บน GPU main thread ใช้งานโจมตีไม่ได้สูงสุด 90%
    • การย้ายไปใช้ std::span
      • เปลี่ยนโครงสร้างเดิมที่ใช้ pointer กับขนาดคู่กัน ไปเป็น std::span ที่คอมไพเลอร์ตรวจสอบได้ เพื่อตัดปัญหาการเข้าถึงนอกขอบเขต (OOB)
      • 97% ของโค้ด Chrome เองคอมไพล์ผ่านได้โดยไม่มีปัญหาภายใต้คำเตือน unsafe-buffer แบบเข้มงวด และกำลังขยายข้อกำหนดนี้ไปยัง Skia, ANGLE และ Dawn
    • การเสริมความแข็งแรงของโครงสร้างและการจัดสรรหน่วยความจำ
      • ใช้ checked math กับการคำนวณการจัดสรรหน่วยความจำเพื่อปิดเส้นทาง integer overflow
      • ทำ heap partitioning เพิ่มเติมโดยแยกประเภทที่มี pointer กับไม่มี pointer อย่างเข้มงวด เพื่อทำให้การโจมตี UAF ยากขึ้น
  • มองว่าการลดผลกระทบใน runtime ของ C++ จะให้ประโยชน์ส่วนเพิ่มน้อยลงในอีกไม่กี่ปีข้างหน้า
    • การตรวจใน runtime มีต้นทุนสูงกว่าการรับประกันตั้งแต่คอมไพล์ และแม้ไบนารี C++ จะถูก harden อย่างมาก ก็ยังต้องใช้ sandbox ที่เข้มงวดซึ่งจำกัดประสิทธิภาพเพื่อให้เป็นไปตาม Rule of Two
  • ระยะยาวกำลังผลักดันการย้ายไป Rust
    • Rust flywheel: สร้าง SDK กลางที่เปิด API และเครื่องมือบน Chromium ให้ Rust ใช้ได้โดยตรง เพื่อให้เป็นตัวเลือกปกติสำหรับคอมโพเนนต์ใหม่
    • กำจัดพื้นที่ที่บั๊กหนาแน่น: แทนที่โค้ดที่มีความหนาแน่นของบั๊กสูงในอดีตอย่าง data parser ที่ซับซ้อน image codec และ font stack อย่างมีกลยุทธ์
    • แยกโมดูลสิทธิ์สูง: เขียนโมดูลใหม่ด้วย Rust เพื่อให้ฟีเจอร์ซับซ้อนทำงานในพื้นที่สิทธิ์สูงอย่าง browser process ได้โดยไม่ต้องเสียต้นทุนด้านประสิทธิภาพจาก sandbox
  • ยังมีการพิจารณาทำ UI ระดับบนสุดของเบราว์เซอร์ด้วย HTML, CSS และ TypeScript เพื่อลดการพึ่งพาเฟรมเวิร์ก C++ เดิมลงอีก

ปิดกั้นช่องโหว่ก่อนส่งโค้ด

  • การสแกนโค้ดเบสทั้งหมดเป็นระยะเพียงอย่างเดียวตามไม่ทันความเร็วในการพัฒนาของ Chrome จึงย้ายการตรวจด้วย AI มาไว้ใกล้กับ จุดที่ส่งโค้ด มากขึ้น
  • โมเดลการป้องกันใน CI และ commit queue (CQ) จะตรวจการเปลี่ยนแปลงโดยอัตโนมัติ
    • เสนอการแก้ไขเพื่อย้ายไปใช้ std::span
    • ทำเครื่องหมาย dangling pointer
    • บังคับใช้ความปลอดภัยของการคำนวณเชิงตัวเลข
  • โค้ดที่ดูปลอดภัยเมื่อแยกเดี่ยว อาจกลายเป็นปัญหาความปลอดภัยร้ายแรงเมื่อรวมกับการเปลี่ยน logic เล็กน้อยในตำแหน่งอื่น
  • การวิเคราะห์เชิงความหมายของ LLM อย่างต่อเนื่องใน CQ จะค้นหาปฏิสัมพันธ์ที่ละเอียดอ่อนหรือซับซ้อนซึ่ง static analysis แบบดั้งเดิมมองไม่เห็น และสกัดไว้ก่อนที่โค้ดจะเข้า tree

ระบบนิเวศโอเพนซอร์สและ dependency ภายนอก

  • ความปลอดภัยบนเว็บไม่ได้ขึ้นกับ Chrome เพียงอย่างเดียว แต่ยังขึ้นกับโครงการโอเพนซอร์สและความสามารถของผู้ดูแลในการตอบสนองต่อรายงานช่องโหว่ด้วย
    • Google ร่วมกับผู้เข้าร่วมรายอื่น บริจาค 12.5 ล้านดอลลาร์ ให้โครงการ Alpha-Omega เพื่อให้ผู้ดูแลมีทั้งเครื่องมือและการสนับสนุนสำหรับตอบสนองต่อรายงานช่องโหว่ได้รวดเร็ว
    • เข้าร่วมเป็นสมาชิกผู้ก่อตั้งของ โครงการ Akrites ซึ่งมีเป้าหมายลดภาระของ upstream maintainer ด้วยศูนย์กลางรับรายงานช่องโหว่และทีมตอบสนองเหตุการณ์ด้านความปลอดภัย
  • Chromium และโปรเจ็กต์ที่เกี่ยวข้องอย่าง V8, BoringSSL, Skia, ANGLE และ Dawn มี dependency ภายนอกมากกว่า 2,300 รายการ
    • ในจำนวนนี้ราว 1,700 รายการถูกส่งต่อไปถึงผู้ใช้ผ่านผลิตภัณฑ์หลากหลาย เช่น อุปกรณ์ Android แพลตฟอร์ม edge computing และสแตกของบริษัทคลาวด์ขนาดใหญ่
  • pipeline ตรวจช่องโหว่อัตโนมัติจะรวบรวมข้อมูลจากฟีดภายในของ Google, NVD ของรัฐบาลสหรัฐฯ และข้อมูล OSV ที่เน้นโอเพนซอร์ส
  • เพราะการเฝ้าติดตามหลังเกิดเหตุอย่างเดียวอาจยังมีช่องว่างความเสี่ยง จึงเริ่มย้ายไปสู่ pipeline อัปเดตอัตโนมัติ ที่อัปเดต dependency ภายนอกทั้งหมดของ Chrome ไปเป็นเวอร์ชัน upstream ล่าสุดเชิงรุก
  • ในกระบวนการอัตโนมัติยังใช้สัญญาณด้านความปลอดภัยจากโครงการอย่าง GOSSIP เพื่อสะท้อนความเสี่ยงอื่น ๆ ในระบบนิเวศโอเพนซอร์สภายนอกด้วย

เบราว์เซอร์ที่ได้รับการปกป้องอย่างต่อเนื่อง

  • จำนวนบั๊กที่ถูกค้นพบและแก้ไขด้วย LLM ที่เพิ่มขึ้นไม่ใช่ความล้มเหลว เพราะบั๊กที่ถูกแก้ไปหนึ่งรายการหมายถึงฐานที่ผู้โจมตีจะใช้ประโยชน์ได้ลดลงหนึ่งจุด
  • การค้นพบและการแก้ไขเพียงอย่างเดียวยังไม่พอ แต่ต้องแจกจ่ายแพตช์และนำไปใช้ในสภาพแวดล้อมของผู้ใช้ก่อนที่ผู้โจมตีจะฉวยโอกาสได้
  • เป้าหมายคือ Chrome ที่ได้รับการปกป้องอย่างต่อเนื่อง โดยผสานการออกรุ่นที่เร็วขึ้น dynamic patching การรีสตาร์ตอัตโนมัติในช่วงที่รบกวนน้อย และการป้องกันเชิงโครงสร้างเข้าด้วยกัน โดยไม่รบกวนผู้ใช้

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 3 시간 전
ความคิดเห็นบน Hacker News

  • ช่วงที่งานยุ่งเมื่อไม่นานนี้ ได้ลองใช้ AI กับ การปรับแต่งประสิทธิภาพ ค่อนข้างมาก แต่แทบไม่มีประโยชน์ในการกำหนดทิศทางระดับสูงเลย แม้จะชี้จุดน่าสงสัยใน SQL query ก็แทบไม่เห็นความต่างของประสิทธิภาพก่อนและหลัง ถูกข้อเสนอที่ไม่จำเป็นกินเวลา และยังต้องรับมือกับการที่คนอื่นโยนผลลัพธ์ดิบจาก AI มาเหมือนเป็น contribution ที่มีความหมาย
    แต่การให้มันช่วย implement การเปลี่ยนแปลงที่ค้นพบเอง หรือย้าย join ไปเป็น CTE ทำได้ง่ายขึ้นมาก

    • ข้อเสนอที่ยืดยาวแต่ไร้ประโยชน์ นั้นเหนื่อยจริง ๆ เพื่อนร่วมงานคนหนึ่งใช้ Claude กับการสื่อสารแบบ asynchronous ทุกอย่าง ทั้ง Slack, Jira, code review และอีเมล แม้แต่คำถามง่าย ๆ ก็ยังตอบกลับมาเป็นกำแพงข้อความขนาดใหญ่ที่ขอบเขตบานปลายไปเรื่อย ๆ
      แม้จะบอกเครื่องมือ AI ซ้ำ ๆ ว่า “ให้กระชับ”, “ตอบเฉพาะคำถาม”, “อย่าให้ข้อมูลที่ไม่ได้ขอ” มันก็ยังส่งออกมามากเกินจำเป็น ดูเหมือนเป็นความพยายามแฝง ๆ ที่จะใช้ token ให้มากขึ้น
    • ถ้าให้ AI มี เครื่องมือทั้งหมด สำหรับตรวจสอบสมมติฐานของตัวเอง และให้มันรันซ้ำทั้ง lifecycle จะทำงานได้ดีจนน่าประหลาดใจ
    • ถ้าให้ ผลลัพธ์ EXPLAIN ANALYZE พร้อมกับ query ไปด้วย AI ก็ไม่ได้มีปัญหาใหญ่อะไรในการ optimize ดังนั้นคำวิจารณ์ว่ามันไร้ประโยชน์สำหรับการ optimize query จึงค่อนข้างน่าแปลกใจ
    • ควรบอกด้วยว่า ใช้โมเดลไหน โมเดลแนวหน้าด้วยกันก็แตกต่างกันมาก และในทางปฏิบัติ Opus 5.0 อยู่คนละระดับกับ Cursor Grok 4.5 อย่างสิ้นเชิง มากกว่าที่ benchmark บอก และก็เทียบกับ Sonnet หรือ Composer ได้ยากด้วย
    • ความผิดพลาดคือให้ดูแค่โค้ดแล้วหา การปรับแต่งประสิทธิภาพ ควรให้ performance profile, query plan, telemetry และวัดผลก่อนกับหลังการเปลี่ยนแปลง
      จากข้อความโค้ดอย่างเดียวไม่อาจรู้ขนาด cache, ขนาดฐานข้อมูล หรือ network latency ได้ ดังนั้นต้องให้บริบทเหล่านี้เพื่อให้ได้ผลลัพธ์ที่ดีกว่า

  • ข้อมูลสำคัญคือในงาน Pwn2Own ที่เบอร์ลินเมื่อเดือนพฤษภาคมที่ผ่านมา Firefox ไม่ได้จ่ายเงินรางวัลเลย จากที่เคยจ่ายเงินรางวัลทุกงานมาตั้งแต่ปี 2007 การที่ไม่มีช่องโหว่ที่ยืนยันได้เลยสักรายการ แปลว่าช่องโหว่แบบง่าย ๆ แทบจะหมดไปแล้ว และดูเป็นสัญญาณว่าโมเดลลักษณะนี้มีประโยชน์อยู่บ้าง

  • เชื่อว่าแก้บั๊กได้จำนวนมาก แต่ก็สงสัยว่ากระบวนการจริงเป็นอย่างไร อาจเป็นไปได้ว่า Google ออกบล็อก แล้วผู้จัดการผลักดันให้ทีมแก้บั๊กหลาย sprint เพื่อแสดง ผลงานการนำ AI มาใช้ ต่อผู้บริหาร ทำให้ทีมทำงานมากกว่าปกติอย่างมาก

    • Google ทำ automation กับทุกอย่าง มาหลายทศวรรษแล้ว และ fuzzer กับ Project Zero ก็อยู่ในกระแสนั้น การเพิ่ม LLM เข้าไปด้านบน พร้อมปรับปรุง harness และเครื่องมือพัฒนาเพื่อเชื่อม detection, triage, fix และ verification แบบ end-to-end จึงเป็นขั้นต่อไปที่เป็นธรรมชาติ
      ประสิทธิภาพของ LLM ขึ้นกับโครงสร้างการวนซ้ำที่มันทำงานอยู่ และโครงสร้างนั้นก็ขึ้นกับคุณภาพของ verifier ดังนั้นอธิบายได้เพียงพอแม้ไม่มีการอวดผลงานของผู้จัดการ
    • ทุกครั้งที่นำเครื่องมือวิเคราะห์ใหม่ เช่น static analysis หรือ fuzzing มาใช้ บั๊กที่ค้นพบใหม่มักพุ่งขึ้นมากในช่วงแรก และหลังจากจัดการไปแล้ว ความถี่ในการค้นพบก็มีแนวโน้มจะลดลงอีกครั้ง
    • ถ้าต้นปี 2026 รายงานบั๊กทุกหมวดเพิ่มขึ้น จนเดือนมีนาคมมากกว่าทั้งปี 2025 ก็เป็นไปได้ว่าการใช้ AI ทำให้ จำนวนบั๊กเอง เพิ่มขึ้นอย่างมากด้วย เช่น ปี 2025 อาจหาเจอ 50 รายการ แก้ 45 รายการ แต่ปี 2026 หาเจอ 500 รายการ แก้ 450 รายการ
    • AI อาจตีความโค้ดได้เร็ว ช่วยจัดการ บั๊กที่ค้างสะสม ได้เร็วขึ้น และทำให้ code review กับ security review เร็วขึ้นจนพบปัญหาได้มากขึ้น ดูเหมือนจะเกิดปรากฏการณ์คล้ายกันใน Linux kernel รวมถึง Windows และ Apple ด้วย
    • ในองค์กรวิศวกรรมของ Chrome อาจเคยมี วัฒนธรรมเฉื่อยชา ตลอดกว่า 10 ปีที่ผ่านมา ที่ไม่แก้บั๊กถ้าผู้บริหารระดับสูงของ Google ไม่เห็นคุณค่าทางธุรกิจ ตอนนี้จึงสงสัยว่ามีแรงจูงใจทางธุรกิจในการแก้บั๊กเพื่อขาย AI ให้มากขึ้น แล้วโยนเครดิตให้ AI

  • แทนที่จะปล่อยให้ AI ทำงานแบบไร้ทิศทาง ควรใช้มันเป็น เครื่องมือเร่งความเร็ว แต่ดูเหมือนนักวิจารณ์จะสับสนเรื่องนี้ เป็น straw man argument คล้ายกับการโกรธ Excel เพราะ ROI แย่ จึงอยากแบ่งปันวิธีใช้ให้ถูกต้องและมีประสิทธิภาพอย่างเงียบ ๆ กับคนที่ตั้งใจใช้ มากกว่าจะเถียงต่อ

    • เอาเข้าจริงยังไม่ชัดว่า ควรใช้ AI อย่างไร ฝั่งหนึ่งบอกว่าให้บริบททั้งหมดแล้วปล่อยให้มันทำงานเต็มที่ อีกฝั่งบอกว่าต้องชี้แนะอย่างละเอียดและตรวจผลลัพธ์ทั้งหมด ซึ่งทั้งสองฝั่งก็มีคนสนับสนุน
      ถ้าปล่อยทิ้งไว้ ผลลัพธ์จะแย่ลงภายในไม่กี่รอบ แต่ถ้าคอยชี้แนะอย่างละเอียดก็เกิดคุณค่าได้ เพียงแต่ความพยายามนั้น โดยเฉพาะเมื่อมีงานซ้ำ ๆ ก็พอ ๆ กับการเขียนโค้ดเอง
    • ในความเป็นจริง AI เป็นเครื่องมือที่เร่งความเร็วให้นักพัฒนา แต่ ผู้บริหารและแล็บวิจัยแนวหน้า กลับโปรโมตเหมือนว่าอีกไม่นานจะไม่ต้องอ่านโค้ด และโปรแกรมเมอร์ก็จะหายไป
    • เมื่อ AI กลายเป็นเรื่องของ ความมั่นคงระหว่างประเทศและการเมือง แล้ว วงการนี้จึงอาจมีโฆษณาชวนเชื่อจำนวนมาก และการถกเถียงปัจจุบันมีรูปแบบคล้ายการถกเถียงทางการเมืองเมื่อ 10 ปีก่อน
    • นึกถึงการถกเถียงที่แม้อธิบายว่า Bitcoin แก้ปัญหาของฉันในแบบไหน ทุกคนก็ยังบอกว่าเป็นไปไม่ได้ แต่นั่นไม่ได้หมายความว่า AI เหมือนกับ Bitcoin
    • การแก้บั๊ก, ปรับปรุงโค้ด และ refactoring เป็นงานที่เหมาะกับ AI ที่สุด เคยคาดหวังว่าจะได้ขัดเกลาซอฟต์แวร์เก่า ๆ เสียที แต่คนที่ถูกกดดันให้พัฒนาฟีเจอร์ใหม่ที่เร็วขึ้นเรื่อย ๆ จะเชียร์หรือประชดประชันก็ขึ้นกับสภาพแวดล้อมที่ตนถูกวางไว้

  • ไม่ทราบว่าในการแก้อัตโนมัติมีกี่รายการที่ ถูกย้อนกลับ, สร้างบั๊กใหม่ขึ้นมากี่ตัว หรืออัตรา false positive ของเอเจนต์ตรวจจับเป็นเท่าไร โพสต์มีแต่ตัวเลขความสำเร็จ และไม่มีส่วนที่อาจผิดพลาดเลย

    • ในความเป็นจริง แม้จะประชาสัมพันธ์ว่า AI ช่วยให้พบบั๊กและแก้บั๊กได้มาก แต่มีความเป็นไปได้ว่า การแก้บั๊กด้วย AI ให้ได้มากที่สุด กลายเป็นตัวชี้วัดผลงานหลัก จึงใช้ AI ค้นหารายการค้างเก่าที่ง่าย แล้วให้คนแก้
    • หลัง M146 ไม่ได้อธิบายว่า จำนวนบั๊กที่พบพุ่งขึ้นอย่างมาก เป็นเพราะการทดสอบที่ดีขึ้น หรือเพราะตั้งแต่แรกมีบั๊กใหม่ถูกใส่เข้ามามากขึ้น
    • ที่ Amazon มีพื้นที่มากมายสำหรับแชร์ กรณีความสำเร็จของ AI แต่ไม่มีที่ให้แชร์ความล้มเหลวหรือความผิดหวัง จึงไม่น่าแปลกที่ผู้บริหารได้ยินแต่เรื่องเล่าด้านเดียวและตัดสินใจผิดเกี่ยวกับ AI
    • ก็อยากรู้เหมือนกันว่าในบั๊กเหล่านั้น มีกี่ตัวที่ AI สร้างขึ้นใหม่
    • ในด้านความปลอดภัยของเบราว์เซอร์ การมีบั๊กใหม่เกิดขึ้นเล็กน้อยอาจไม่ใช่ปัญหาใหญ่ การโจมตี Pinkie Pie ในปี 2012 ยังต้องเชื่อมบั๊ก 6 ตัวเข้าด้วยกัน และหลังจากนั้นก็มีการโจมตีที่ต้องเชื่อมมากกว่า 10 ตัวขึ้นไป ดังนั้นแค่แก้ได้หนึ่งตัวในนั้นก็ทำให้การโจมตีทั้งหมดใช้ไม่ได้
      ต่อให้แก้บั๊ก 10 ตัวแล้วสร้างใหม่ 2 ตัว ตราบใดที่ไม่ใช่บั๊กร้ายแรงที่ exploit ได้เดี่ยว ๆ ก็ยังได้ประโยชน์สุทธิมาก การโจมตีเบราว์เซอร์ต้องการ ห่วงโซ่ช่องโหว่ ที่ยาวขึ้นเรื่อย ๆ ดังนั้นข้อดีของการใช้ AI ค้นหาบั๊กที่อาจเกิดขึ้นจึงมองข้ามได้ยาก
      https://blog.chromium.org/2012/05/tale-of-two-pwnies-part-1....

  • กังวลว่าในอนาคต Google อาจตัดสินว่า Chromium ไม่จำเป็นต้องมี การค้นหาบั๊กแบบหมู่คณะที่เปิดเผยต่อสาธารณะ แล้วหยุดการพัฒนาแบบเปิด หากเป็นเช่นนั้น กลุ่ม Chromium ในปัจจุบันก็จะกลายเป็นฟอร์กโดยพฤตินัยของเวอร์ชันสาธารณะล่าสุด และแต่ละฟอร์กอาจมีความยากในการดูแลต่างกัน เพราะไม่มีทรัพยากรพอจะรักษาได้เท่า Chrome ที่มี Gemini สนับสนุน

    • Google ควบคุมทิศทางของ Chrome และ Chromium อย่างแข็งแกร่งอยู่แล้ว ดังนั้นถ้าให้ความสำคัญกับ เว็บแบบเปิด ก็ควรใช้ Firefox

  • คำวิจารณ์ AI มักมุ่งไปที่กรอบแคบ ๆ ว่า การสร้างโค้ดอย่างมืดบอด เป็นเรื่องแย่ ซึ่งจุดนั้นยอมรับได้ง่าย แต่การทดสอบเชิงปรปักษ์, การตรวจสอบสมมติฐานของนักพัฒนา, การเสนอ refactoring, เครื่องมือพัฒนาขนาดเล็ก, การเขียนโค้ดพร้อมคำแนะนำ และการติดตาม dependency กับพฤติกรรมใน codebase ขนาดใหญ่ อยู่คนละฝั่งกันและช่วยได้มาก
    คำวิจารณ์ที่เข้าข่ายการสร้างโค้ดอย่างมืดบอดถูกเอาไปปะปนกับการใช้งานทั้งหมดเหล่านี้ง่ายเกินไป

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

  • ประเด็นสำคัญตั้งแต่แรกคือ ในบั๊กเหล่านี้มีกี่ตัวที่เกิดจาก โค้ดที่ LLM เขียน การสร้างบั๊กเพิ่ม 100 เท่าแล้วแก้เพิ่ม 100 เท่าไม่ใช่เรื่องน่าภูมิใจ

    • Chrome เป็นโปรเจกต์ที่มีอายุกว่า 20 ปี ส่วน LLM เพิ่งปรากฏไม่นาน และแม้จะมีตัวสร้างโค้ดด้วย LLM ก็ไม่ได้ทำให้การรีวิวโค้ดกับการทดสอบหย่อนลง อีกทั้งมีการกล่าวถึง issue อายุ 13 ปีด้วย จึงมีความเป็นไปได้ว่าส่วนที่ได้รับผลกระทบไม่ได้มีการพัฒนาใหม่มากนักในช่วงหลัง
      เนื่องจากเป็นโปรเจกต์โอเพนซอร์ส จึงตรวจสอบเองได้จริงว่าบั๊กนั้น LLM สร้างขึ้นหรือไม่
    • หากค่อย ๆ โอนงานเขียนโค้ดให้ AI ความสามารถของมนุษย์ในการ ระบุบั๊กที่อาจแฝงอยู่ ก็อาจลดลงด้วย เมื่อฟีเจอร์ที่ AI เขียนถูกนำไปตรวจซ้ำด้วย AI ก่อน commit เราก็เข้าใกล้โลกที่แม้แต่โค้ดซึ่งรันโครงสร้างพื้นฐานก็ไม่มีมนุษย์เข้าใจ
    • ดูจากสถิติ Git แล้ว จำนวนบรรทัดโค้ด ที่ส่งเข้ามาไม่ได้เปลี่ยนไปอย่างสุดโต่ง ไม่ใช่ทุกคนจะ merge โค้ด AI คุณภาพต่ำเข้าไปทั้งอย่างนั้น และองค์กรใหญ่เดิม ๆ โดยมากก็ไม่ได้ merge ผลงาน vibe coding ที่ไร้ความรับผิดชอบ
    • หากสมมติว่า AI สามารถสร้างโค้ดที่มีบั๊กน้อยลงได้ การที่บั๊กใหม่เพิ่มขึ้น 100 เท่าย่อมหมายความว่า ความเร็วในการพัฒนาฟีเจอร์ใหม่ เร็วขึ้นมากกว่า 100 เท่า หากโมเดลหาเจอบั๊กร้ายแรงอายุ 13 ปีได้ ก็ย่อมน่าจะเขียนโค้ดใหม่ที่ไม่มีบั๊กแบบนั้นได้ด้วยความสามารถเดียวกัน
    • การเมินประวัติและขนาดของโปรเจกต์ แล้วสร้าง ตัวเลขว่าบั๊กเพิ่มขึ้น 100 เท่า ขึ้นมาโดยไม่มีหลักฐานและเรียกสิ่งนั้นว่าเป็นปัญหาหลัก เป็นเรื่องไม่สมเหตุสมผล ในหัวข้อ AI มักเห็นท่าทีพยายามประกอบความจริงขึ้นมาอย่างฝืน ๆ เป็นพิเศษ

  • อยากรู้ว่า Chrome ได้แก้ บั๊กติดตามพฤติกรรม ที่พยายามติดตามผู้ใช้ไม่ว่าจะทำอะไรที่ไหนด้วยหรือเปล่า