ให้ Agent ทำงานแทนได้ แต่อย่าให้มันคิดแทน: Critical Thinking ในวันที่งานเสร็จเร็วเกินจะสงสัย

เมื่อวันก่อนผมอ่านบทความบน X ของ Addy Osmani ซึ่งทำงานเกี่ยวกับ Claude Code อยู่ที่ Anthropic แล้วรู้สึกเหมือนโดนจี้จุดครับ

ใจความที่ติดอยู่ในหัวผมคือ เมื่อ agent ทำงานแทนเราได้มากขึ้น critical thinking ไม่ได้สำคัญน้อยลงเลย และอาจสำคัญกว่าเดิมด้วยซ้ำ

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

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

จุดยืนของผมหลังอ่านจบมีอยู่ประโยคเดียว ฝากงานให้ agent ได้ แต่อย่าฝากการคิดไปด้วย

ทำไมมันถึงเพลินจนเผลอ

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

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

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

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

เส้นที่ค่อย ๆ ขยับ จากฝากงานไปถึงยอมจำนน

ส่วนที่ผมชอบที่สุดในบทความของ Addy คือการมองเรื่องนี้เป็นเส้นต่อเนื่อง ไม่ใช่สองขั้วว่าใช้ AI หรือไม่ใช้ AI

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

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

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

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

ที่ผมยอมรับว่าทำผิดอยู่

เพื่อไม่ให้โพสต์นี้เป็นการสอนคนอื่นอย่างเดียว ขอสารภาพก่อนครับ

ผมเคยเปิด PR ที่ agent ทำให้ อ่านสรุปด้านบน เห็น test ผ่าน แล้วรู้สึกว่า "รีวิวแล้ว" ทั้งที่ยังไม่ได้ลงไปอ่าน diff จริงจังเลย

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

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

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

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

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

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

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

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

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

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

ติ๊กเขียวไม่ได้แปลว่าตรวจครบ

เรื่องนี้ผมอยากแยกออกมาเป็นหัวข้อของมันเอง เพราะคิดว่าเป็นจุดที่พลาดกันง่ายที่สุด

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

test อาจผ่านเพราะ agent แก้ test ให้ตรงกับพฤติกรรมใหม่ของโค้ด test อาจผ่านเพราะ mock ทุกอย่างจนไม่ได้แตะ logic ที่เปลี่ยน CI อาจเขียวเพราะ job ที่เกี่ยวข้องไม่ได้รันกับ path นี้เลย และประโยค "ทดสอบแล้วทำงานถูกต้อง" ในสรุป อาจหมายถึงแค่ build ผ่าน

ทางแก้ของผมมีสองข้อ และเป็นข้อตกลงที่จะคุยกับทีมด้วยครับ

ข้อแรก เวลาบอกว่าตรวจแล้ว ต้องบอกด้วยว่าตรวจอะไร และยังไม่ได้ตรวจอะไร ไม่ว่าคำรายงานนั้นจะมาจากคนหรือ agent แทนที่จะเขียนว่า "ทดสอบแล้ว" ผมอยากเห็น "รัน unit test ของ payment ผ่านครบ ลอง flow จ่ายเงินบน staging ด้วยบัตรทดสอบหนึ่งรอบ ยังไม่ได้ลอง refund และยังไม่ได้ทดสอบตอน gateway timeout" แค่มีบรรทัดหลังนี้ คนรีวิวก็รู้ทันทีว่าต้องมองตรงไหน

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

prompt เบลอ แต่งานดันดูเสร็จ

อีกเรื่องที่ทำให้ผมนึกถึงงาน PM ของตัวเองมาก คือเรื่อง intent ครับ

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

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

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

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

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

คำถามพวกนี้ตอบไม่ได้ถ้าไม่ได้คิดมาก่อน ซึ่งก็คือจุดประสงค์ของมันนั่นเองครับ

โมเดลเก่งขึ้นแค่ไหน คนก็ยังต้องรับผิดชอบ

คงมีคนแย้งว่า อีกไม่นานโมเดลจะเก่งจนไม่ต้องตรวจแล้ว จะฝึกนิสัยพวกนี้ไปทำไม

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

ตอนข้อมูลผิด ลูกค้าไม่ได้สนใจว่าโมเดลอะไรเขียนโค้ดบรรทัดนั้น ผู้บริหารก็จะไม่ถามหา agent แต่ถามหาคนที่กด merge ชื่อที่อยู่บน commit และบนสัญญาคือชื่อคน

และเมื่อโมเดลเก่งขึ้น ความผิดพลาดที่เหลือก็จะยิ่งหายากขึ้น โมเดลที่ถูก 99 ครั้งจากร้อยครั้ง ทำให้เราเลิกตรวจได้ง่ายกว่าโมเดลที่ถูก 80 ครั้งเสียอีก ผมจึงคิดว่ายิ่งโมเดลเก่ง วินัยเรื่องนี้ยิ่งต้องตั้งใจรักษา เพราะธรรมชาติจะไม่ช่วยเตือนเราแล้ว

ท้ายที่สุด

ผมไม่ได้อ่านบทความนี้แล้วคิดว่าจะใช้ agent น้อยลงครับ ผมน่าจะใช้มากขึ้นเรื่อย ๆ ด้วยซ้ำ

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

พรุ่งนี้ก่อนจะกด Enter ส่ง prompt ถัดไป ผมตั้งใจจะถามตัวเองก่อนหนึ่งคำถามง่าย ๆ ว่า ตอนนี้ผมคิดว่าคำตอบคืออะไร

ถ้าตอบไม่ได้เลย งานที่ควรทำก่อนอาจยังไม่ใช่การพิมพ์ prompt ครับ