AI แก้ bug ได้ไหม? ได้ครับ มันช่วยสืบหลักฐาน ทำให้ปัญหาเกิดซ้ำ เขียน test และทำ patch ได้เร็วมาก แต่คำตอบที่ถูกกว่าคือ AI ไม่ควรแก้แบบเดาแล้วปล่อยขึ้น production เอง โดยเฉพาะเมื่อปลายทางคือเงิน ลูกค้า หรือเครื่องของลูกค้าครับ
ผมใช้ AI แก้ระบบธุรกิจทุกวัน แต่ผมไม่เคยวัดมันจากความเร็วในการพิมพ์โค้ดอย่างเดียว ผมวัดจากว่า patch นั้นตอบหลักฐานไหม, มี test กันปัญหากลับมาไหม และถ้าผิด เราหยุดหรือย้อนกลับได้แค่ไหนต่างหาก 555 บทความนี้เล่าวิธีทำงานจากเคสจริงที่เกือบกระทบลูกค้า Newton ถึง 86 เครื่องครับ
AI แก้ bug ได้แค่ไหนในงานจริง?
AI ทำงานต้นน้ำถึงกลางน้ำได้ดีมาก: อ่าน log, เทียบ code, หา hypothesis, เขียน test และเสนอ patch เล็ก ๆ ครับ สิ่งที่ยังไม่ควรยกให้มันตัดสินใจลำพังคือการกด deploy, ลบหรือแก้ข้อมูลจริง และเลือก trade-off ที่กระทบลูกค้า
ความเข้าใจผิดที่เจอบ่อยคือคิดว่ามีแค่สองทาง: ให้ AI แก้ทุกอย่างเอง หรือห้ามแตะ code เลย จริง ๆ มีพื้นที่ตรงกลางเยอะมาก เราให้มันเปิด ticket, สรุปเหตุการณ์, ทำ branch, เขียน regression test และเตรียม diff ให้คนดูได้ โดยคนไม่ต้องเสียเวลานั่งเริ่มจากหน้าจอว่าง ๆ แต่ก็ยังไม่เอาระบบจริงไปเสี่ยงกับคำตอบที่ฟังมั่นใจเกินเหตุ
ผมมอง AI เหมือนช่างที่ทำงานเร็วและอ่านคู่มือเก่งมาก ไม่ใช่เจ้าของอาคารครับ ช่างช่วยบอกได้ว่าท่อน้ำรั่วตรงไหนและเปลี่ยนอะไหล่ให้ แต่ก่อนปิดน้ำทั้งตึกหรือทุบผนัง คนที่รับผลกระทบต้องรู้และอนุมัติก่อนเสมอ
เคสจริง: AI ช่วยแก้บั๊กที่อาจกระทบ 86 เครื่องอย่างไร?
เคสนี้ AI ไม่ได้ล่ม แต่มันเปลี่ยนรูปแบบข้อมูลที่ส่งกลับจนหน้าแชตของเราหยิบข้อความไปแสดงไม่ได้ครับ ถ้าดูแค่สถานะว่า agent ทำงานจบ เราจะสรุปผิดว่าระบบปกติ ทั้งที่ลูกค้าเห็นเหมือนไม่มีใครตอบ
ตอน Codex ออกเวอร์ชันใหม่ event ของ interactive chat เปลี่ยนเป็นรูปแบบ item_completed แต่ adapter ใน Newton ยังอ่าน schema เก่าอยู่ ผลคือมีคำตอบอยู่ใน rollout จริง แต่ชั้นแสดงผลหา text ไม่เจอ ถ้าปล่อยให้ระบบ update อัตโนมัติตอนเช้าโดยไม่แก้ รอบเดียวอาจไปถึง 86 เครื่องได้
ผมให้ AI เริ่มจากเปรียบเทียบ event เก่ากับใหม่ แล้วหาว่า parser ของเรารับอะไรบ้าง จากนั้นทำ test ที่ส่ง payload รูปแบบใหม่เข้าไป ผลบนโค้ดเดิมคือ 4 จาก 12 test ล้ม ไม่ใช่เพราะโมเดลตอบผิด แต่เพราะ code แปลข้อมูลไม่ครบ พอแก้ parser ให้รองรับทั้ง schema เดิมและใหม่ test ผ่าน 12 จาก 12 แล้วผมค่อยตรวจหน้าจอแชตจริงและอนุมัติ rollout ครับ
ตัวเลขนี้ไม่ได้บอกว่าหลังจากนั้นจะไม่มี bug อีกเลยนะครับ แต่มันเปลี่ยนบทสนทนาจาก “น่าจะหายแล้ว” เป็น “ก่อนแก้พัง 4 เคส หลังแก้ผ่าน 12 เคส และยังต้องตรวจ user flow นี้ต่อ” ซึ่งเป็นความต่างระหว่างความมั่นใจกับหลักฐานจริง ๆ
ก่อนให้ AI แก้ bug ต้องให้ข้อมูลอะไร?
ให้ symptom ที่ตรวจได้, เวลาที่เกิด, ผลลัพธ์ที่ควรเป็น และขอบเขตที่ห้ามแตะครับ คำสั่งว่า “ระบบพัง แก้ให้หน่อย” กว้างเกินจนเก่งแค่ไหนก็มีสิทธิ์เริ่มจากสมมติฐานผิด
ชุดข้อมูลขั้นต่ำของผมมี 5 อย่าง: ใครเจอปัญหาและเจอตรงไหน, เริ่มเกิดเมื่อไร, log หรือ screenshot ที่เกี่ยวข้อง, สิ่งที่เพิ่งเปลี่ยนก่อนหน้า และ expected behavior ที่ยืนยันได้ เช่น “มีข้อความจาก agent แต่หน้าแชตต้องแสดงข้อความนั้นภายใน 5 วินาที” จากนั้นสั่งชัด ๆ ว่ารอบแรก อ่านอย่างเดียว ห้าม restart ห้าม deploy
การแยกรอบสืบออกจากรอบแก้สำคัญมาก เพราะ symptom เดียวมีต้นเหตุได้หลายอย่าง เว็บช้าอาจไม่ใช่ server, email ไม่ออกอาจไม่ใช่ระบบส่งเมล, และข้อความหายก็ไม่จำเป็นต้องหมายความว่า AI ไม่ตอบ วิธีให้ agent อ่านหลักฐานก่อนค่อยสร้างสมมติฐาน ผมเขียนละเอียดไว้ใน AI Agent ควรอ่าน log ก่อนแก้บั๊กไหม ครับ
ทำไมต้องให้ AI เขียน test ก่อนทำ patch?
เพราะ test เปลี่ยนประโยคว่า “ผมคิดว่าแก้แล้ว” ให้กลายเป็นข้อพิสูจน์ที่รันซ้ำได้ครับ ถ้าเราแก้แล้วปัญหาหายเพียงครั้งเดียว อาจเป็นเพราะจังหวะ ไม่ใช่เพราะ root cause ถูกแก้จริง
ในเคส schema ที่เล่าไป test ใหม่ไม่ได้เป็นแค่ด่านก่อน merge มันทำหน้าที่บันทึกสัญญาว่า event สองรูปแบบต้องแสดงข้อความได้เหมือนกัน วันหน้า vendor เปลี่ยนอีก เราจะรู้ทันทีว่าอะไรพัง แทนที่จะรอให้ลูกค้าทักว่าแชตเงียบก่อน
ผมชอบให้ AI รายงาน test เป็นสามส่วน: อะไร fail บนโค้ดเก่า, patch เปลี่ยนอะไร, และอะไรผ่านหลังแก้ ถ้ามีส่วนที่ test ไม่ครอบคลุม มันต้องเขียนว่า “ยังไม่ได้ตรวจ” ตรง ๆ ไม่ใช่ใช้คำว่าครบหรือปลอดภัยโดยไม่มีหลักฐาน การให้ AI ทดสอบเว็บแทนคน ก็ใช้หลักเดียวกันครับ: ตรวจ flow ที่ลูกค้าใช้จริง ไม่ใช่ดูแค่ว่า process ยังเปิดอยู่
งานแบบไหนให้ AI แก้เองได้ และงานไหนต้องรอคนอนุมัติ?
ให้ AI ทำเองได้กับงานขอบเขตแคบ ย้อนกลับง่าย และมีเกณฑ์ผ่านชัดเจนครับ ถ้า action เปลี่ยนเงิน ข้อมูลส่วนตัว สิทธิ์ลูกค้า หรือเผยแพร่สู่สาธารณะ ผมให้มันหยุดพร้อมหลักฐานและตัวเลือกเสมอ
ตัวอย่างงานที่ผมปล่อยให้เดินเองได้คือรวบรวม log, เปิด issue, รัน test, สร้าง draft patch และแจ้งว่ามี regression งานเหล่านี้ยังตรวจทานก่อนผลไปถึงลูกค้าได้ ส่วนการลบ row ใน database, restart service ที่มีคนใช้, เปลี่ยนราคา, ส่งอีเมล หรือ deploy ไปหลายเครื่อง ต้องมีคนกดยืนยัน เพราะความเสียหายของการเดาผิดหนึ่งครั้งแพงกว่าการประหยัดเวลาไม่กี่นาที
นี่ไม่ใช่การทำให้ AI ช้าครับ มันคือการเอาคนไปวางตรงจุดที่ต้องใช้ judgement จริง ๆ ขณะที่ AI รับงานซ้ำและงานสืบหลักฐานไปเต็มที่ หลักกำหนดสิทธิ์แบบนี้อ่านต่อได้ที่ AI Agent ควรมีสิทธิ์เข้าถึงอะไรบ้าง
เจ้าของธุรกิจที่ไม่ใช่ dev เริ่มใช้ AI แก้ปัญหาอย่างปลอดภัยได้อย่างไร?
เริ่มจากงานหนึ่งที่คุณตรวจผลได้เอง และสั่งให้ AI รายงานก่อนลงมือแก้ครับ ไม่ต้องเริ่มจากให้มันมีสิทธิ์เข้าทุกระบบ เพราะระบบใหญ่ไม่ได้ทำให้เริ่มได้ดีขึ้น
เช่น ถ้าเว็บมีคนแจ้งว่ากรอกฟอร์มไม่ได้ ให้ AI รวบรวมเวลาที่เกิด, ตรวจ error ที่เกี่ยวข้อง, ลองทำตาม flow ด้วยข้อมูลทดสอบ และสรุปว่าอะไรยืนยันแล้ว อะไรยังเป็นสมมติฐาน จากนั้นให้มันเสนอ patch พร้อมวิธีทดสอบก่อน-หลัง คุณไม่ต้องอ่าน code ทุกบรรทัด แต่ควรถามได้ว่า “หลักฐานคืออะไร, ทดสอบที่ไหน, ถ้าไม่หายจะย้อนกลับยังไง”
ถ้าอยากเรียนวิธีแตกงานให้ตรวจได้ ตั้งขอบเขตสิทธิ์ และคุยกับ AI ให้ได้ผลแบบจับมือทำ ผมสอนไว้ใน คอร์ส LearnAI ครับ เป้าหมายไม่ใช่เปลี่ยนทุกคนให้เป็น programmer แต่คือทำให้คุณคุมงานที่ AI ช่วยทำได้จริง
คำถามที่พบบ่อย
AI แก้ bug ได้ไหม?
ได้ครับ AI ช่วยสืบหลักฐาน ทำให้ปัญหาเกิดซ้ำ เขียน test และทำ patch ได้ดี แต่ deploy หรือแก้สิ่งที่กระทบลูกค้าควรมีคนอนุมัติ
ให้ AI แก้ bug บน production เองได้ไหม?
ไม่ควรปล่อยแบบไร้รั้ว งานที่ย้อนกลับง่ายและมี test อาจทำอัตโนมัติได้ แต่เรื่องเงิน ข้อมูลลูกค้า สิทธิ์ และ release ควรหยุดให้คนตรวจ
AI ต้องมีข้อมูลอะไรถึงจะแก้ bug ได้?
บอก symptom ที่ตรวจได้ ช่วงเวลาที่เกิด log ที่เกี่ยวข้อง สิ่งที่เพิ่งเปลี่ยน และผลลัพธ์ที่ควรเป็น ยิ่งโจทย์แคบ หลักฐานยิ่งดีครับ
AI แก้ bug ต่างจากเขียนโค้ดเองอย่างไร?
AI ช่วยอ่านข้อมูลหลายจุดและสร้าง patch ได้เร็ว แต่ไม่ได้รับประกันความถูกต้อง จึงต้องมี test กับคนอนุมัติเป็นประตูสุดท้าย
ถ้าคุณอยากมี AI ที่ไม่ได้แค่ตอบว่าควรแก้อะไร แต่มีพื้นที่ให้มันอ่านหลักฐาน ทำงานเป็นขั้น และหยุดรอคุณตรงจุดเสี่ยง ลองดู Newton ครับ ผมสร้างมันจากวิธีที่ผมใช้กับธุรกิจจริงนี่แหละ: ให้ AI เร็วได้เต็มที่ แต่ไม่ให้การเดาเร็วกว่า evidence
— Pond