ถ้า AI เขียนโค้ด แล้วให้ AI อีกตัวตรวจ คนควรเข้ามาตอนไหน? และถ้าทั้งสองตัวเห็นตรงกันแต่ผิดทั้งคู่ ใครจะจับปัญหาได้?
นี่คือคำถามในบทสัมภาษณ์ Itamar Friedman ซีอีโอของ Qodo โดย Danielle จากทีม Developer Experience ของ OpenAI ในวิดีโอ Qodo - The Last Human Code Review | DevDay 2026 เขาเสนอให้ AI ผู้เขียนและผู้ตรวจแก้ข้อขัดแย้งกันระหว่างทำงาน แล้วเรียกคนเข้ามาเมื่อจำเป็น โดยใช้ทั้งบริบทของระบบและประสบการณ์ที่สะสมอยู่ในทีม
บทสนทนานี้อธิบายแนวทางของ Qodo และมุมมองต่ออนาคตของการพัฒนาซอฟต์แวร์ ไม่ได้แสดงผลทดสอบที่ยืนยันว่า AI ตรวจงานแทนคนได้ทุกกรณี Friedman เองก็ยอมรับว่า ต่อให้ AI และคนเห็นด้วยทั้งหมด บั๊กยังอาจหลุดไปถึงระบบจริงได้
สารบัญ
- ผู้ตรวจต้องรู้มากกว่าโค้ดที่อยู่ตรงหน้า
- เก็บประสบการณ์ของทีมให้ AI เรียกใช้ได้
- โค้ดถูกเฉพาะจุด แต่กระทบบริการอื่น
- จากปรับพรอมป์ต์สู่การออกแบบบทบาท AI
- ให้ AI ส่งเรื่องถึงคนเมื่อมีสิ่งที่ต้องตัดสินใจ
- เห็นตรงกันไม่ได้รับประกันว่าถูก
- พิจารณาฟีเจอร์ทั้งชุด แทนการดู PR แยกกัน
- สิ่งที่ทีมพัฒนานำไปพิจารณาได้
ผู้ตรวจต้องรู้มากกว่าโค้ดที่อยู่ตรงหน้า
Friedman อธิบายว่า Qodo รวบรวมบริบทจากความรู้ที่กระจายอยู่ในทีมวิศวกรรม เพื่อนำไปให้ Codex และใช้ตรวจงานระหว่างที่ AI เขียนโค้ด เป้าหมายคือช่วยให้ชุดการเปลี่ยนแปลงพร้อมรับการตรวจทานมากขึ้นตั้งแต่ต้น
เขาแบ่งงานที่เกี่ยวข้องออกเป็นสามส่วน ได้แก่ การเตรียมบริบทสำหรับสร้างโค้ด การตรวจโค้ด และการกำกับดูแลผ่านแผนที่ซอฟต์แวร์ที่แสดงความเชื่อมโยงของระบบและการเปลี่ยนแปลงเมื่อเวลาผ่านไป
ข้อมูลเหล่านี้ช่วยตอบคำถามที่อ่านโค้ดเพียงจุดเดียวอาจตอบไม่ได้ เช่น บริการใดใช้ข้อมูลชุดเดียวกัน เหตุใดทีมจึงเลือกสถาปัตยกรรมแบบนี้ และการแก้ส่วนหนึ่งจะส่งผลต่อส่วนอื่นอย่างไร ทั้งหมดเป็นแนวทางที่ Friedman อธิบายในคลิป ไม่ใช่ผลประเมินอิสระของผลิตภัณฑ์
เก็บประสบการณ์ของทีมให้ AI เรียกใช้ได้
Qodo เรียกฐานความรู้จากประสบการณ์นี้ว่า wisdom base Friedman แยกความสามารถในการวิเคราะห์ออกจากความเข้าใจที่เกิดจากการทำงานจริง เช่น วิธีที่เคยลองแล้วล้มเหลว หรือเงื่อนไขที่ทำให้ระบบมีปัญหาเมื่อรองรับการใช้งานจำนวนมาก
เขายกกรณีลูกค้าสถาบันการเงินแห่งหนึ่งที่มีคลังโค้ดหลายร้อยแห่งและบริการย่อยจำนวนมาก นักพัฒนาอาวุโสบางคนรู้ว่าอะไรทำได้และอะไรไม่ควรทำซ้ำ แต่เมื่อคนเหล่านั้นออกจากองค์กร ความรู้บางส่วนก็หายไปด้วย คลิปไม่ได้ระบุชื่อลูกค้าหรือเปิดเผยข้อมูลสำหรับตรวจสอบผลลัพธ์ของกรณีนี้
แนวทางที่เขาเล่าคือย้อนอ่านการสนทนาของนักพัฒนาจาก GitHub, GitLab, Bitbucket, Slack และ Teams แล้วสกัดความรู้เกี่ยวกับผลกระทบระหว่างบริการ ความเชื่อมโยงบางอย่างเกิดผ่านข้อมูลที่ส่งต่อกัน จึงอาจไม่ปรากฏชัดในโค้ดของบริการใดบริการหนึ่ง
หากจะนำแนวคิดนี้ไปใช้ ทีมยังต้องกำหนดว่าข้อมูลใดนำเข้าได้ ใครเข้าถึงได้ และกฎใดยังมีผลอยู่ ความเห็นเก่าในแชตไม่ควรกลายเป็นข้อกำหนดปัจจุบันโดยไม่มีคนตรวจสอบ ประเด็นนี้เป็นข้อควรพิจารณาของบทความ ไม่ใช่คำอธิบายขั้นตอนตั้งค่า Qodo
โค้ดถูกเฉพาะจุด แต่กระทบบริการอื่น
อีกตัวอย่างที่ Friedman เล่าคือลูกค้าซึ่งให้บริการธุรกิจขนาดเล็กและกลางหลายล้านราย และเปิดให้ลูกค้าปรับแต่งการทำงานได้มาก การเปลี่ยนโค้ดจึงเกี่ยวข้องกับฐานข้อมูลอยู่บ่อยครั้ง ตัวเลขและลักษณะการใช้งานนี้เป็นข้อมูลจากผู้ให้สัมภาษณ์ โดยไม่มีชื่อลูกค้าหรือหลักฐานประกอบในคลิป
เขาอธิบายว่าโค้ดที่แก้อาจดูถูกต้องเมื่อพิจารณาเฉพาะจุด แต่บริการปลายทางซึ่งใช้ข้อมูลเดียวกันอาจได้รับผลกระทบรุนแรง การตรวจจึงต้องครอบคลุมความสัมพันธ์ระหว่างระบบด้วย
Qodo ใช้การประมวลผลเบื้องหลังเพื่อสร้างและปรับปรุงแผนที่ความเชื่อมโยงของซอฟต์แวร์ตามคำอธิบายของ Friedman แทนที่จะเริ่มรวบรวมบริบทใหม่ทั้งหมดเมื่อมีงานเข้ามา หลักคิดที่นำไปใช้ได้คือเตรียมข้อมูลเรื่องผลกระทบข้ามระบบไว้ให้ผู้เขียนและผู้ตรวจตั้งแต่ก่อนเริ่มงาน
จากปรับพรอมป์ต์สู่การออกแบบบทบาท AI
Friedman เล่าการเปลี่ยนแนวทางจากการปรับคำสั่งหรือ prompt engineering ไปสู่การออกแบบกระบวนการทำงานหรือ flow engineering และการออกแบบกลุ่มเอเจนต์หรือ swarm engineering เขายกงาน AlphaCodium ในปี 2024 เป็นตัวอย่างของการออกแบบกระบวนการแก้โจทย์ แทนการถามตอบกับโมเดลไปเรื่อยๆ
สำหรับการทำงานหลายเอเจนต์ สิ่งที่ต้องกำหนดให้ชัดคือเป้าหมาย เครื่องมือ ขอบเขต และกฎของแต่ละบทบาท เขาเตือนว่าการปล่อยให้เอเจนต์สร้างผู้ช่วยย่อยและเลือกเครื่องมือเองยังอยู่ในช่วงต้น และอาจใช้ทรัพยากรสิ้นเปลือง โดยเฉพาะระบบตรวจงานที่ต้องมีหลักฐานรองรับข้อสรุป
ช่วงท้ายเขาแนะนำให้แบ่งงานเป็นภารกิจย่อย ออกแบบบทบาทที่แต่ละภารกิจต้องใช้ แล้วเลือกโมเดลให้เหมาะกับบทบาทนั้น รวมถึงพิจารณาต้นทุนเมื่อระบบต้องทำงานซ้ำบ่อยๆ
ให้ AI ส่งเรื่องถึงคนเมื่อมีสิ่งที่ต้องตัดสินใจ
Friedman เสนอให้ผู้ตรวจส่งข้อเสนอแนะระหว่างการเขียนโค้ด แทนการรอแสดงรายการปัญหาจำนวนมากบนหน้า pull request หรือ PR ตอนท้าย โดย PR คือข้อเสนอการเปลี่ยนแปลงที่เปิดให้ทีมพิจารณาก่อนรวมโค้ดเข้ากับโครงการ อ่านเพิ่มเติมได้จาก คำอธิบายของ GitHub
ในภาพที่เขาเสนอ AI ผู้เขียนและผู้ตรวจจะพยายามหาข้อสรุปร่วมกันก่อน หากยังเห็นต่างจึงส่งเรื่องให้ผู้พัฒนา เขาคาดว่าวิธีโยนข้อค้นพบทั้งหมดให้คนตรวจปลายทางอาจดูไม่เหมาะสมแล้วภายในปี 2027 ข้อนี้เป็นการคาดการณ์ของ Friedman ไม่ใช่กำหนดเวลาที่ทุกทีมจะเปลี่ยนวิธีทำงาน
ตัวชี้วัดขั้นต่ำที่เขาเสนอคือจำนวนครั้งที่ต้องเรียกผู้พัฒนาเข้ามาช่วยเพื่อให้งานหนึ่ง PR เสร็จด้วยคุณภาพที่ต้องการ จากเดิมที่คนคอยสั่ง AI จึงเปลี่ยนเป็น AI ขอข้อมูลหรือการตัดสินใจจากคน
อย่างไรก็ดี จำนวนครั้งที่เรียกคนน้อยลงเพียงอย่างเดียวไม่ได้ยืนยันว่างานดีขึ้น ทีมที่ทดลองแนวทางนี้ควรดูบั๊กที่หลุด งานแก้ซ้ำ และเวลาที่คนใช้ตัดสินใจควบคู่กันด้วย นี่เป็นข้อเสนอในการประเมินผลของบทความเพิ่มเติมจากตัวชี้วัดที่ผู้ให้สัมภาษณ์ระบุ
เห็นตรงกันไม่ได้รับประกันว่าถูก
เมื่อ Danielle ถามว่าเกิดอะไรขึ้นหาก AI ทั้งสองฝ่ายเห็นตรงกันแต่ผิดทั้งคู่ Friedman ยอมรับว่าความผิดพลาดยังเกิดได้ แม้ผู้พัฒนาและผู้ตรวจที่เป็นมนุษย์จะเห็นด้วยแล้วก็ตาม
คำตอบของเขาคือบันทึกเหตุขัดข้องและบทเรียนกลับเข้า wisdom base เพื่อช่วยหลีกเลี่ยงความผิดพลาดเดิม พร้อมคัดความรู้ที่ไม่เกี่ยวข้องออกเมื่อจำเป็น การเรียนรู้ต่อเนื่องที่เล่าในช่วงนี้หมายถึงการเก็บประสบการณ์ให้ระบบเรียกใช้ ไม่ได้ยืนยันว่าโมเดลจะฝึกตัวเองใหม่จากทุกเหตุการณ์โดยอัตโนมัติ
ประเด็นที่ยังต้องออกแบบให้ชัดคือจะตรวจพบความผิดพลาดก่อนถึงระบบจริงอย่างไร เพราะการที่ AI สองตัวเห็นพ้องกันยังไม่ใช่หลักฐานว่าผลลัพธ์ถูกต้อง การทดสอบและจุดอนุมัติของคนจึงควรสอดคล้องกับความเสี่ยงของงาน ไม่ได้ขึ้นอยู่กับว่าเอเจนต์ตกลงกันได้หรือไม่เพียงอย่างเดียว
สำหรับทีมที่ต้องการวางกระบวนการเก็บบทเรียน แนวทางเขียนบททบทวนหลังเหตุขัดข้องของ Google SRE เป็นแหล่งอ่านเพิ่มเติมที่ต้นฉบับบทความอ้างถึง ควรแยกแหล่งนี้ออกจากคำกล่าวของ Friedman ในคลิป
พิจารณาฟีเจอร์ทั้งชุด แทนการดู PR แยกกัน
Friedman ชวนให้เปลี่ยนหน่วยของงานจาก PR หนึ่งรายการเป็นความสามารถหรือฟีเจอร์ที่เสร็จตั้งแต่ต้นจนจบ เพราะหนึ่งฟีเจอร์อาจประกอบด้วย PR หลายรายการทั้งในคลังโค้ดเดียวกันและต่างคลัง การดูแต่ละรายการแยกกันอาจไม่เห็นภาพรวมของสิ่งที่ต้องส่งมอบ
ในช่วงสัมภาษณ์เขาระบุแผนเปิดตัวสิ่งที่เรียกว่า work package triage เพื่อช่วยทำความเข้าใจและตรวจชุด PR ที่เกี่ยวข้องกัน คำกล่าวนี้เป็นแผน ณ เวลาบันทึกบทสัมภาษณ์ บทความนี้ไม่ได้ใช้คลิปดังกล่าวยืนยันสถานะการเปิดให้ใช้ในปัจจุบัน
สิ่งที่ทีมพัฒนานำไปพิจารณาได้
ข้อเสนอหลักของ Qodo คือให้ผู้ตรวจ AI เข้าถึงประสบการณ์ของทีมและความสัมพันธ์ระหว่างระบบ พร้อมให้ข้อเสนอแนะระหว่างทำงาน ส่วนคำถามว่าคนควรเข้ามาตอนไหนยังต้องตอบตามบริบทและความเสี่ยงของแต่ละทีม
หากจะทดลองแนวทางจากบทสนทนานี้ อาจเริ่มจากรายการสั้นๆ ต่อไปนี้ ซึ่งเป็นข้อสรุปเชิงปฏิบัติของบทความ ไม่ใช่คู่มือติดตั้งผลิตภัณฑ์:
- เลือกงานที่มีเกณฑ์ตรวจชัดและย้อนกลับได้ พร้อมระบุระบบปลายทางที่อาจได้รับผลกระทบ
- รวบรวมกฎ ข้อยกเว้น และเหตุขัดข้องเดิม พร้อมแหล่งอ้างอิง ผู้รับผิดชอบ และวันที่ทบทวน
- แยกบทบาทผู้เขียนกับผู้ตรวจ และกำหนดหลักฐานที่ต้องใช้ในการทักท้วงหรือรับงาน
- กำหนดเหตุที่ต้องส่งเรื่องถึงคน เช่น ข้อมูลไม่ครบ ความเห็นต่างที่แก้ไม่ได้ หรือการเปลี่ยนแปลงที่มีความเสี่ยงสูง
- วัดทั้งภาระคน คุณภาพงานที่ส่งมอบ และต้นทุน ก่อนขยายขอบเขตการใช้งาน
- นำบทเรียนจากปัญหาจริงกลับมาปรับชุดทดสอบและฐานความรู้ โดยทบทวนข้อมูลเก่าด้วย
ที่มา: Qodo - The Last Human Code Review | DevDay 2026 จากช่อง OpenAI บทความเรียบเรียงจากบทถอดเสียงที่แนบกับต้นฉบับ VideoToBlog และแยกความเห็นเชิงประยุกต์ออกจากคำกล่าวของผู้ให้สัมภาษณ์
