Green Check ไม่ได้แปลว่าถูก: นิสัยการ Verify และ Paradox of Supervision ในวันที่ Agent เขียนโค้ดแทน

ประโยคที่ทำให้ผมสบายใจเร็วที่สุดในแต่ละวัน อาจเป็นประโยคที่ควรทำให้ผมระวังที่สุดครับ นั่นคือ "เสร็จแล้วครับพี่ test เขียวหมด"

ประโยคนี้มาได้ทั้งจากน้องในทีมและจาก agent บางทีก็มาจากทั้งสองพร้อมกัน เพราะน้องสั่ง agent ทำ แล้วส่งสรุปของมันต่อมาให้ผม ใน PR มีติ๊กเขียวเรียงเป็นแถว lint ผ่าน type check ผ่าน unit test ผ่าน build ผ่าน หน้าจอแบบนั้นให้ความรู้สึกเหมือนงานจบแล้ว เหลือแค่กด merge

แต่ถ้าถามว่าติ๊กเขียวเหล่านั้นพิสูจน์อะไรให้ผมบ้าง คำตอบจริง ๆ มักแคบกว่าความรู้สึกมาก

ผมเป็นทั้ง developer, PM และ PO ที่ Mulberrysoft ดูแลทีม junior ทำงานกับลูกค้าที่ requirement แทบไม่เคยครบ และใช้ Claude, Codex กับ agent อื่น ๆ แทบทุกวัน ซีรีส์นี้เริ่มจากการให้ agent ทำงานแทนโดยไม่ให้มันคิดแทน ต่อด้วยวันที่คำตอบของ agent กลายเป็นความเห็นของเรา หนี้ความเข้าใจที่ไม่ขึ้นบน dashboard และเจตนาที่ agent จ่ายแทนไม่ได้ ในโพสต์แรกผมเขียนหัวข้อสั้น ๆ ว่าติ๊กเขียวไม่ได้แปลว่าตรวจครบ โพสต์นี้อยากขยายหัวข้อนั้นให้เต็ม และต่อไปถึงคำถามที่ผมเลี่ยงมานาน คือถ้าวันหนึ่งเราตรวจไม่เป็นแล้ว ใครจะตรวจ

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

สีเขียวตอบคำถามเดียว

เวลาเห็น test ผ่าน สมองเรามักแปลเป็นคำว่า "ถูก" ทันทีครับ แต่ test แต่ละตัวตอบคำถามที่แคบมาก unit test ของฟังก์ชันคำนวณส่วนลดบอกว่า input ชุดที่เขียนไว้ได้ output ตามที่คาด type check บอกว่า type สอดคล้องกัน build บอกว่าโค้ดคอมไพล์ได้ ไม่มีตัวไหนบอกว่าส่วนลดนี้ถูกตามที่ลูกค้าตกลงไว้

ในบทความบน X ของ Addy Osmani เรื่อง critical thinking ตอนที่ agent ทำงานแทน มีนิสัยหนึ่งที่ผมอ่านแล้วอยากพิมพ์แปะจอ คือเมื่อ check ไหนเขียว ให้ถามสองคำถามคู่กันเสมอ มันพิสูจน์อะไร และมันไม่ได้พิสูจน์อะไร

คำถามแรกเราถามกันอยู่แล้วโดยอัตโนมัติ แต่คำถามที่สองแทบไม่มีใครถาม เพราะสีเขียวไม่มีช่องให้แสดงสิ่งที่มันไม่ได้ตรวจ หน้าจอ CI ไม่เคยขึ้นข้อความว่า "ไม่ได้ทดสอบกรณี refund" หรือ "ไม่ได้รันกับข้อมูลจริง" ช่องว่างพวกนี้มองไม่เห็นจนกว่าเราจะตั้งใจมองหา

ลองดูตัวอย่างที่ผมเจอบ่อยในงาน agent ครับ test ผ่านเพราะ mock ทุก dependency จนไม่ได้แตะ logic ที่เปลี่ยน test ผ่านเพราะ agent แก้ assertion ให้ตรงกับพฤติกรรมใหม่ไปพร้อมกับโค้ด CI เขียวเพราะ job ที่ควรรันไม่ได้ trigger กับ path นี้ หรือมี test ถูก skip อยู่สองตัวโดยไม่มีใครเห็น ทุกกรณีให้ติ๊กเขียวหน้าตาเหมือนกันหมด

นิยามคำว่า "verified" ก่อนเริ่ม เพราะหลังเสร็จเราจะหาเหตุผลให้ตัวเอง

ส่วนที่ผมว่าคมที่สุดในหัวข้อนี้ของ Addy คือเรื่องจังหวะเวลาครับ เขาแนะนำให้ นิยามว่าอะไรนับเป็น verified ไว้ตั้งแต่ก่อนเริ่มงาน เพราะถ้ารอไปนิยามหลังเห็นผล เราจะเริ่มหาเหตุผลมารองรับสิ่งที่ได้มาแล้ว

ผมอ่านตรงนี้แล้วนึกถึงตัวเองชัดมาก ตอนเห็น PR ที่ดูดี test เขียว สรุปสวย ผมจะเริ่มคิดว่า "จริง ๆ เคสนั้นก็ไม่น่าเกิดหรอก" หรือ "ส่วนนั้นเดี๋ยว QA ก็เจอเอง" ประโยคเหล่านี้ไม่ได้ผิดเสมอไป แต่มันมักเกิดขึ้นหลังจากที่ผมอยากให้งานเสร็จแล้ว ไม่ใช่ก่อน เกณฑ์ที่ตั้งตอนอยากปิดงาน มักต่ำกว่าเกณฑ์ที่ตั้งตอนยังไม่เห็นอะไรเสมอ

ข้อนี้เชื่อมกับโพสต์ Intent Debt โดยตรงครับ ใน checklist ที่ผมเขียนไว้ มีข้อ "เสร็จแปลว่าอะไร" อยู่แล้ว พออ่าน Addy รอบนี้ผมเลยเห็นว่าข้อนั้นไม่ได้เป็นแค่ส่วนหนึ่งของ prompt มันคือสัญญาที่เราทำกับตัวเองล่วงหน้า ว่าจะไม่ลดเกณฑ์ลงตอนที่เหนื่อยและอยากกด merge

Addy ยังพูดถึงเส้นชัยว่าควรเป็นหลักฐานที่จับต้องได้ เช่น test ที่รันแล้ว screenshot log หรือ trace ไม่ใช่คำบอกเล่าว่าทำแล้ว และให้ อ่านคำสั่งกับ output ก่อนอ่านสรุปของ agent ข้อหลังนี้ผมเขียนไว้แล้วในโพสต์แรก แต่ขอย้ำอีกรอบเพราะยังทำพลาดอยู่ครับ สรุปคือการตีความ ส่วน output คือสิ่งที่เกิดขึ้นจริง ถ้าอ่านสรุปก่อน เราจะเอาภาพนั้นไปอ่าน output แล้วเห็นแต่สิ่งที่ยืนยันมัน

Verify loop ที่ดี และขอบเขตของมัน

ฝั่งที่ทำให้ผมมองโลกในแง่ดีขึ้นคือคำแนะนำที่ Boris Cherny คนสร้าง Claude Code พูดไว้บ่อย และ Addy ก็หยิบมาเล่าต่อ คือ "give Claude a way to verify its work" ให้ agent มีวิธีตรวจงานตัวเอง

ภาพที่ผมเข้าใจคือ แทนที่ agent จะเขียนโค้ดแล้วส่งกลับมาเลย ให้มันรัน test เอง เปิด browser ดูหน้าจอเอง อ่าน output แล้ววนแก้จนกว่าจะผ่าน ก่อนที่คนจะได้เห็นงานด้วยซ้ำ ในงานจริงผมเห็นผลชัดครับ งานที่ให้ agent รัน test และดู log ได้เอง กลับมาพร้อมบั๊กโง่ ๆ น้อยกว่างานที่มันเขียนอย่างเดียวแบบเห็นได้ชัด และผมได้เวลาไปดูเรื่องที่ยากกว่า

แต่ผมคิดว่าต้องพูดอีกครึ่งหนึ่งด้วยครับ loop นี้ทำให้ agent ผ่านเกณฑ์ที่เราให้ไว้ได้ดีขึ้น ไม่ได้ทำให้เกณฑ์นั้นถูกขึ้น ถ้าเราให้มันตรวจด้วย test ชุดที่มันเขียนเอง มันก็จะวนจนกว่า test ของมันเองจะเขียว ถ้าเกณฑ์ที่ให้ไปคือ "build ผ่าน" มันก็จะได้ build ที่ผ่าน สีเขียวจาก loop ที่ดีที่สุดก็ยังพิสูจน์ได้แค่คุณสมบัติที่เรานิยามไว้

ส่วนนี้เป็นความเห็นของผมเองนะครับ ผมคิดว่ายิ่ง verify loop ดีขึ้น เรายิ่งต้องระวังมากขึ้น เพราะสิ่งที่กลับมาถึงมือเราจะผ่านการขัดเกลามาแล้วหลายรอบ บั๊กที่หาง่ายถูกเก็บหมด สิ่งที่เหลือคือความผิดพลาดที่อยู่นอกเกณฑ์ทั้งหมด ซึ่งเป็นแบบที่หายากที่สุด

Test ที่เขียวอย่างมั่นใจ บน acceptance ที่ผิด

มุมนี้ผมเจอในฐานะ PM ครับ และเป็นเหตุผลหลักที่ผมอยากเขียนโพสต์นี้

ลูกค้าส่ง requirement มาว่า "สมาชิกระดับ Gold ได้ส่วนลด 10%" น้องในทีมสั่ง agent ทำ ได้โค้ดพร้อม test ครบ ทั้งสมาชิก Gold ได้ 10% สมาชิกปกติไม่ได้ ยอดศูนย์บาทไม่พัง ทุกอย่างเขียว แต่ไม่มีใครถามว่าส่วนลดนี้ซ้อนกับคูปองได้ไหม คิดก่อนหรือหลัง VAT และถ้าสมาชิกเพิ่งเลื่อนระดับกลางเดือนต้องนับยังไง

agent เลือกคำตอบให้ทุกข้อแล้วครับ และเขียน test ยืนยันคำตอบเหล่านั้นด้วย ผลคือเรามี test ที่ล็อกพฤติกรรมซึ่งไม่มีใครตัดสินใจไว้ แล้วเอาสีเขียวมาประทับให้ดูเหมือนข้อตกลง ในโพสต์ Intent Debt ผมเรียกอาการนี้ว่าคำเดาที่ถูกประทับตรา พอมาดูในมุม verification มันน่ากลัวกว่าเดิมอีก เพราะ test ที่เข้ารหัส acceptance ผิด จะปกป้องความผิดนั้นไว้ ถ้าวันหลังมีคนแก้ให้ถูก test จะแดง และคนแก้อาจคิดว่าตัวเองทำพัง

ตรงนี้คือจุดที่ผมต้องเตือนตัวเองว่าหมวก PO ถอดไม่ได้ครับ คำว่า verified ในสายตา developer คือ test ผ่าน แต่ในสายตาลูกค้าคือระบบทำสิ่งที่เขาต้องการ สองอย่างนี้ทับกันได้ ถ้าเราตั้งใจทำให้ทับ แต่ไม่ได้ทับกันเอง คนที่นิยามว่า verified สำหรับลูกค้าแปลว่าอะไร ยังเป็น PM และ PO ไม่ใช่ agent และไม่ใช่ test suite

เวลาน้องบอกว่า "เสร็จแล้วครับ test เขียว" ผมจึงอยากเปลี่ยนคำถามถัดไปของตัวเอง จาก "โอเค merge เลย" เป็น "test พวกนี้ยืนยัน acceptance ข้อไหนของลูกค้า แล้วข้อไหนที่ยังไม่มีอะไรยืนยัน" ผมไม่ได้ตั้งใจจับผิดน้องนะครับ คำถามนี้ผมต้องถามตัวเองกับงานที่ผมสั่ง agent เองเหมือนกัน

Paradox of supervision

มาถึงส่วนที่ทำให้ผมนั่งนิ่งไปนานที่สุดครับ

Anthropic เขียนรายงานเรื่องAI กำลังเปลี่ยนการทำงานที่ Anthropic อย่างไร จากการสำรวจและสัมภาษณ์ engineer กับนักวิจัยในบริษัทเอง ประเด็นหนึ่งที่คนในบริษัทพูดถึงถูกเรียกว่า "paradox of supervision" ใจความที่ผมเข้าใจคือ การจะใช้ Claude ให้ได้ผลต้องมีคนคุมงานมัน แต่การคุมงานให้ดีต้องใช้ทักษะการเขียนโค้ดและ debug ซึ่งเป็นทักษะที่อาจเสื่อมลงถ้าใช้ AI มากเกินไป

ต้องบอกตามตรงว่าผมอ่านแค่หน้าสรุปของรายงาน ไม่ได้ลงไปดูข้อมูลทั้งหมด และนี่เป็นสิ่งที่คนในบริษัทเล่าถึงความกังวลของตัวเอง ไม่ใช่การวัดผลว่าทักษะหายไปเท่าไร ใครอยากเช็กกดลิงก์ไปอ่านได้เลยครับ

แต่ต่อให้อ่านอย่างระวังที่สุด มันก็ยังเป็นประโยคที่วนกลับมาหาตัวเองแบบไม่ปล่อย ทุกนิสัยที่ผมเขียนมาข้างบน ทั้งถามว่าสีเขียวไม่ได้พิสูจน์อะไร อ่าน output ก่อนสรุป หรือสังเกตว่า test ถูก mock จนไม่ได้แตะ logic ล้วนต้องใช้คนที่อ่านโค้ดเป็นและเคยไล่บั๊กเองมาก่อน ถ้าทักษะนั้นหายไป นิสัยเหล่านี้ก็เหลือแค่พิธีกรรม เราจะเปิด output แล้วมองไม่ออกว่าตรงไหนผิดปกติ

ในโพสต์ Comprehension Debt ผมเล่าถึงอีกงานของ Anthropic เรื่องผลของ AI ต่อการสร้างทักษะการเขียนโค้ด ซึ่งกลุ่มที่ใช้ AI ได้คะแนน quiz เฉลี่ย 50% เทียบกับ 67% ของกลุ่มที่เขียนเอง และช่องว่างกว้างที่สุดอยู่ที่คำถามเรื่อง debugging งานนั้นมีข้อจำกัดเยอะ ทั้งกลุ่มตัวอย่างเล็ก และวัดคนที่กำลังเรียน library ใหม่ ผมจึงไม่ขอลากเลขไปไกล แต่พอวางคู่กับ paradox นี้ ภาพมันสอดคล้องกันจนอึดอัด ทักษะที่หายไปก่อน อาจเป็นทักษะที่เราใช้ตรวจ agent พอดี

ส่วนที่ผมห่วงเรื่องทีม junior

สำหรับผม paradox นี้ยังมีอีกชั้นหนึ่งครับ

ผมเองได้ไล่บั๊กด้วยมือมาก่อนจะมี agent ต่อให้ทักษะผมเสื่อมลงบ้าง ก็ยังมีพื้นให้ยืน แต่น้องที่เริ่มงานในปีนี้อาจไม่เคยมีพื้นนั้นเลย ถ้าตั้งแต่วันแรกทุกบั๊กถูกโยนให้ agent แก้ น้องจะไม่ได้สร้างสัญชาตญาณว่า stack trace แบบนี้น่าจะมาจากตรงไหน หรือ test แบบนี้ดูดีเกินจริง

ปัญหาคือในทีมเล็กอย่างของผม น้องเหล่านี้คือคนที่จะต้องรีวิวงาน agent ในอีกสองสามปีข้างหน้า ถ้าเราไม่ได้ปลูกทักษะการคุมงานไว้ตอนนี้ วันนั้นเราจะมีคนกด approve เยอะ แต่มีคนที่ verify ได้จริงน้อย

ผมไม่ได้คิดจะห้ามน้องใช้ agent นะครับ มันคือเครื่องมือที่น้องต้องใช้เป็นในอาชีพนี้ แต่ผมคิดว่าต้องตั้งใจกันพื้นที่ให้น้องได้ฝึกส่วนที่ agent ทำให้ข้ามไปได้ง่ายเกินไป

นิสัยที่ผมจะใช้จริง

ส่วนนี้ผมเรียบเรียงจาก Addy, Boris และงานของ Anthropic ผสมกับสิ่งที่ลองในงานจริงครับ ผมไม่ได้ใช้ครบทุกข้อกับทุกงาน แต่งานที่แตะเงิน สิทธิ์ ข้อมูลลูกค้า หรือสิ่งที่ลูกค้าจะเห็น ผมตั้งใจไล่ให้ครบ

เขียนนิยาม verified ไว้ก่อน prompt ก่อนสั่ง agent ผมจะเขียนสามถึงห้าบรรทัดว่าหลักฐานอะไรบ้างที่ทำให้ผมยอมเรียกงานนี้ว่าเสร็จ เช่น test ที่ครอบ acceptance ข้อไหน หน้าจอที่ต้องเห็นบน staging หรือ log ที่ต้องไม่มี error แล้วใส่นิยามนี้ลงใน prompt ด้วย เพื่อให้ verify loop ของ agent วนกับเกณฑ์ของผม ไม่ใช่เกณฑ์ที่มันคิดเอง

แยก test ที่ยืนยัน acceptance ออกจาก test ที่ agent เขียนเพิ่ม สำหรับงานสำคัญ ผมจะขอให้เคส acceptance หลักมาจากคนก่อน จะเขียนเป็นภาษาคนก็ได้ แล้วให้ agent แปลงเป็น test ส่วน test อื่นที่มันเขียนเพิ่มให้ถือว่าเป็นโบนัส ไม่ใช่หลักฐานว่าตรงกับที่ลูกค้าต้องการ

ถามคู่กันทุกครั้งที่เห็นสีเขียว มันพิสูจน์อะไร และไม่ได้พิสูจน์อะไร ผมจะขอให้ทั้งน้องและ agent ปิดรายงานด้วยบรรทัด "ยังไม่ได้ตรวจ" เสมอ ถ้าบรรทัดนี้ว่าง ผมจะถือว่ายังไม่ได้คิด ไม่ใช่ตรวจครบแล้ว

เปิดหลักฐานก่อนอ่านสรุป ดูคำสั่งที่รัน ดู output จริง ดู screenshot หรือ trace ถ้ามี แล้วค่อยอ่านสรุปของ agent เพื่อเทียบ ถ้าสรุปอ้างถึงสิ่งที่ผมหาไม่เจอใน output ผมถือว่าสรุปนั้นยังไม่ได้รับการยืนยัน

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

ให้น้องทำงานจริงหนึ่งชิ้นโดยไม่มี agent ไม่ต้องบ่อยครับ เดือนละชิ้นเล็ก ๆ ก็พอ เลือกงานที่มีบั๊กหรือมี edge case ให้คิด แล้วรีวิวด้วยกัน ผมไม่ได้อยากวัดว่าน้องเร็วแค่ไหน แต่อยากให้น้องมีประสบการณ์ของการติดและการหาทางออกเอง เพราะนั่นคือวัตถุดิบของสัญชาตญาณที่จะใช้ตรวจ agent ในวันหน้า

ให้ agent ช่วยฝึก ไม่ใช่ช่วยข้าม งานของ Anthropic เรื่องทักษะบอกว่ากลุ่มที่ใช้ AI เพื่อถามให้เข้าใจ ได้ผลดีกว่ากลุ่มที่ปล่อยให้ AI ทำแทน ผมจะลองให้น้องใช้ agent แบบถามว่า "ทำไม error นี้ถึงเกิด" ก่อนจะถามว่า "ช่วยแก้ให้หน่อย"

ท้ายที่สุด

ถ้ามองทั้งซีรีส์ ผมเริ่มเห็นว่า critical thinking กับ agent มีจุดที่ต้องโผล่ออกมาอยู่ไม่กี่จุดครับ ก่อนเริ่มงานคือ intent ว่าเราต้องการอะไร ระหว่างทางคือการไม่ยอมให้คำตอบของมันกลายเป็นความเห็นของเราเฉย ๆ ตามที่เขียนไว้ในเรื่อง cognitive surrender หลังงานสะสมคือการรู้ยอดหนี้ความเข้าใจ และตอนที่งานกลับมาถึงมือ คือ verification

Verification คือจุดที่ทุกอย่างก่อนหน้ามาเจอกันครับ ถ้าไม่มี intent เราก็ไม่รู้จะ verify กับอะไร ถ้ายอมจำนนไปแล้ว เราก็จะ verify แค่ว่าสรุปอ่านลื่นไหม และถ้าหนี้ความเข้าใจสูงจนไม่มีใครอ่านโค้ดออก ต่อให้อยาก verify ก็ทำไม่ได้

ส่วน paradox of supervision เตือนผมว่าความสามารถในการ verify ไม่ได้อยู่กับเราตลอดไปเอง มันต้องถูกใช้ถึงจะยังอยู่ ผมยังจะให้ agent ทำงานมากขึ้นเรื่อย ๆ และให้มัน verify ตัวเองมากขึ้นด้วย แต่ผมจะกันส่วนหนึ่งไว้ให้ตัวเองกับทีมได้ทำของยากด้วยมือ เพื่อให้วันที่ต้องตรวจจริง เรายังตรวจเป็น

ดังนั้นครั้งถัดไปที่ได้ยินว่า "เสร็จแล้วครับ test เขียว" ไม่ว่าจากน้องหรือจาก agent ผมจะถามกลับแค่ว่า เราตกลงกันไว้ตั้งแต่แรกไหมว่าเขียวแค่ไหนถึงเรียกว่าเสร็จ

ถ้าตกลงไว้ นั่นคือการ verify ครับ ถ้าไม่ได้ตกลงไว้ สีเขียวนั้นก็เป็นแค่สีที่ทำให้เราสบายใจเร็วขึ้น