Andrew Ng ซอยทักษะการใช้ coding agent เป็น 5 ข้อ ข้อที่ 3 เชื่อไปแล้วว่า เทสต์ของคุณได้รันจริง

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

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

พอย้อนกลับไปดู เรื่องนี้ไม่ได้เกิดจากฝีมือ แต่เกิดจากการไม่มีชื่อเรียกของสิ่งที่ยังขาด ทักษะที่ไม่มีชื่อจะฝึกไม่ได้ เพราะไม่รู้ว่ากำลังฝึกอะไรอยู่

เมื่อวันที่ 4 กันยายน 2026 Andrew Ng โพสต์ตอนที่ 3 ของแผนที่ทักษะ AI engineering ของเขา ว่าด้วยการใช้ coding agent และสิ่งที่โพสต์นั้นทำ คือเอาความรู้สึกก้อนใหญ่ที่เรียกรวมๆ ว่า "ใช้ agent เป็น" มาซอยเป็นชื่อ 5 ชื่อ ที่หยิบไปฝึกทีละอันได้จริง

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

ช่วงที่ 1ฐานของทั้ง 5 ทักษะ คือลำดับงาน 3 ขั้น

แผนที่ทักษะ AI engineering ของ Andrew Ng แบ่งทักษะระดับบนสุดไว้ 4 ช่อง คือสร้างและส่งแอป AI ขึ้นใช้งาน · พื้นฐานวิศวกรรมซอฟต์แวร์ · การใช้ coding agent · และการกำหนดรูปของสิ่งที่จะสร้าง ตอนที่ 1 คุยกันไปแล้วว่าช่องแรกแตกเป็น 6 ข้อย่อยอะไรบ้าง ตอนที่ 2 คุยกันไปแล้วว่าช่องที่ 2 มี 5 เสา หน้านี้อยู่กับช่องที่ 3

Andrew Ng เปิดด้วยเหตุผลว่าทำไมช่องนี้ถึงต้องมีชื่อของตัวเอง คือทักษะการชี้ทางให้ agent ทั้งเขียนโค้ดและทำงานที่ไม่ใช่โค้ด อย่างการวิเคราะห์ข้อมูลหรือดูแลระบบ ทำให้เราทำของได้มากขึ้นเยอะ และเขาบอกด้วยว่าช่องนี้เปลี่ยนเร็วกว่าช่องอื่นบนแผนที่ เพราะทั้ง agent แบบปิดอย่าง Claude Code · Codex · Cursor และ agent แบบเปิดอย่าง OpenCode · Pi ต่างเก่งขึ้นเป็นก้าวๆ จากทั้งฝั่ง harness และฝั่งโมเดล พอเป็นแบบนั้น การตามให้ทันจึงไม่ใช่การอ่านสรุปรอบเดียวจบ แต่ต้องทดลอง สร้าง และเรียนไปเรื่อยๆ

ก่อนจะถึงตัวทักษะ Andrew Ng วางฐานไว้ก่อนหนึ่งชั้น เขาบอกว่าจากการสัมภาษณ์ AI engineer ระดับต้นๆ หลายสิบคน บวกกับการมองย้อนดูวิธีทำงานของทีมตัวเอง เขาเจอลำดับงานร่วมกันอยู่ชุดหนึ่ง แบ่งเป็น 3 ขั้น

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

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

Deployment and monitoring คือส่งขึ้นใช้งานแล้วเฝ้าดู ตัวส่งอาจมีท่อส่งงานอัตโนมัติที่เรียกกันว่า CI/CD หรือด่านที่ต้องให้คนกดผ่านคั่นไว้ ส่วนการเฝ้าดูคือการใช้ agent อ่าน log จับปัญหาที่โผล่ขึ้นมา แล้วเสนอกับลงมือแก้ให้ดีขึ้น

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

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

ทั้ง 5 ทักษะข้างล่างนี้คือสิ่งที่ทำให้เดินลำดับข้างบนได้จริง เรียงตามลำดับที่ Andrew Ng เขียนไว้ ไม่ได้เรียงตามความสำคัญ

ช่วงที่ 25 ทักษะ เรียงตามลำดับของ Andrew Ng

1. กำกับลำดับงาน · Directing the workflow

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

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

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

2. ปล่อยอิสระให้ agent · Enabling agent autonomy

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

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

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

3. ตรวจงานที่ agent ส่งกลับมา · Reviewing the work

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

สิ่งที่ต้องออกแบบคือการทดสอบและการพิสูจน์ผลที่เข้ากับงานตรงหน้า ใช้ทั้งการตรวจเชิงพฤติกรรมและเชิงหน้าที่ตามแต่กรณี อาจต้องทดสอบเส้นทางที่ผู้ใช้เดินจริง โดยให้ agent ส่งภาพหน้าจอกลับมาเป็นหลักฐานว่าผ่านหรือไม่ผ่าน ส่วนงานที่ต้องตัดสินเชิงคุณภาพ ก็ใช้ชุด eval ที่อาจมีโมเดลอีกตัวเป็นผู้ให้คะแนน ซึ่งเรียกกันว่า LLM-as-a-judge

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

ข้อนี้คือข้อที่บทความนี้จะกลับมาอีกครั้งในช่วงที่ 3 เพราะมีสมมติฐานหนึ่งซ่อนอยู่ในนั้น ที่แผนที่ไม่ได้พูดถึงเลย

4. ปรับแต่งตัว agent และสภาพแวดล้อมของมัน · Customizing the agent and its environment

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

ฝั่งตัว agent Andrew Ng ระบุไว้ว่ารู้วิธีต่อ skill คือส่วนเสริมความสามารถที่ติดเข้า agent ได้ คนละความหมายกับคำว่าทักษะที่ใช้มาทั้งบทความ · plugin และ MCP server เข้าไป และเป็นครั้งคราวก็ต้องถอดของพวกนี้ออกเมื่อมันหมดความจำเป็น เช่นตอนที่โมเดลรุ่นใหม่ทำสิ่งที่ skill เก่าเคยทำได้เองอยู่แล้ว ตรงนี้เป็นจุดที่คนลืมกันบ่อย เพราะการเพิ่มของรู้สึกเหมือนคืบหน้า ส่วนการถอดของออกไม่รู้สึกเหมือนอะไรเลย นอกจากนั้นยังใช้ hook เพื่อทำส่วนที่ทำซ้ำในกระบวนการพัฒนาให้อัตโนมัติ เช่นการยิงรีวิวโค้ดหรือท่อ CI/CD

ฝั่งสภาพแวดล้อมคือการดูแลที่ที่ agent ทำงาน เริ่มจากการอัปเดต standing context อย่าง AGENTS.md หรือ CLAUDE.md ด้วยข้อมูลของ codebase สมมติฐานเชิงสถาปัตยกรรมที่สำคัญ สไตล์การเขียนโค้ด และรูปแบบการเข้าถึงข้อมูล ต่อด้วยการรู้วิธีรักษาสถานะข้ามหลาย session และข้าม agent ที่วิ่งขนานกัน กับการสะสมสิ่งที่ agent เรียนรู้เอาไว้ตามเวลา เช่นด้วยการทำรอบทบทวนหลังงานจบ ว่าอะไรได้ผลและอะไรไม่ได้ผล ปิดท้ายด้วยการวางข้อตกลงและโครงสร้างให้สม่ำเสมอ เพื่อให้ codebase เป็นที่ที่ agent เดินหาของเจอ กับการเก็บกวาดหนี้ที่ agent สร้างไว้เป็นครั้งคราว และเมื่อทำงานเป็นทีม ก็ต้องคิดต่อว่าจะประสาน context ระหว่าง agent ของนักพัฒนาแต่ละคนยังไง

5. เข้าใจว่า coding agent ทำงานยังไงข้างใน · Coding agent foundations

ข้อสุดท้ายคือฐานที่ทำให้ 4 ข้อแรกตัดสินใจได้แม่น Andrew Ng ไล่ไว้เป็นชุด คือเข้าใจว่า agent ค้นและหยิบของจาก codebase ยังไง จัดการ context window ของมันยังไง การกระทำแต่ละแบบอย่างการเพิ่มเครื่องมือหรือ MCP server กระทบ context ยังไง agent กับ subagent คุยกันแบบไหน และตัว agent เกิดจากการเอา harness ไปห่อ LLM ไว้อีกทีได้ยังไง

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

หมายเหตุปิดท้ายที่ Andrew Ng เขียนไว้เอง

หลังไล่ครบ 5 ข้อ Andrew Ng ทิ้งย่อหน้าหนึ่งที่ควรอ่านให้ครบ เขาบอกว่าโซเชียลมีเดียมักอธิบายวิธีใช้ coding agent แบบง่ายเกินจริง ยกตัวอย่างว่าบางทีการปล่อยให้ agent วิ่งเองหลายชั่วโมงและเผา token คือหน่วยข้อความที่โมเดลคิดเงิน เป็นล้านหรือหลายสิบล้าน ก็มีประโยชน์จริง แต่ตอนนี้ประโยชน์ในทางปฏิบัติของงานที่ปล่อยยาวมากๆ โดยเฉพาะเมื่อเทียบกับต้นทุน "has been amplified beyond reality" คือถูกขยายเกินความจริงไปแล้ว สิ่งที่ได้ผลจริงกว่าคือกระบวนการที่ซับซ้อนและวนซ้ำ ซึ่งการเข้าไปแทรกด้วยวิจารณญาณที่ฝึกมาดี ให้ผลดีกว่ามาก

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

Your skill at using coding agents will make you an effective builder. This positions you to also steer the overall build. I will say more about this in a future post.

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

ช่วงที่ 3สิ่งที่แผนที่ไม่ได้ถาม คือใครตรวจตัวตรวจ

ทั้ง 5 ข้อข้างบนเราไม่มีอะไรจะแย้ง สิ่งที่อยากเติมคือสมมติฐานหนึ่งที่ฝังอยู่ในข้อที่ 3

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

เราวัดเรื่องนี้ไปเมื่อวันที่ 4 กันยายน 2026 ระหว่างซ่อมตอนที่ 2 ของซีรีส์นี้เอง ทุกตัวเลขข้างล่างมาจากรอบนั้น

ตัวรีวิวที่อ่านกฎไม่เจอสักข้อ เรามีบอตรีวิวงานเขียนที่ทำงานด้วยคลังกฎของบ้านเรา เราเรียกมันผ่าน symlink คือทางลัดที่ชี้ไปยังไฟล์จริงอีกที่หนึ่ง แล้วโค้ดข้างในหาไฟล์กฎโดยอ้างอิงจากตำแหน่งของสคริปต์ พอเป็น symlink ตำแหน่งนั้นก็ชี้ไปคนละที่ ผลคือรอบนั้นมันส่งกฎเข้าไปให้ตัวเองอ่าน 0 จาก 29 ไฟล์ แล้วยังหยิบสำเนางานเก่าอายุ 12 วันจากกล่องขาเข้ามาอ่านแทนฉบับปัจจุบันแบบเงียบๆ สิ่งที่กลับมาคือ verdict คือคำตัดสินที่บอตรีวิวพิมพ์กลับมา หน้าตาปกติทุกประการ มีข้อสังเกต มีน้ำเสียงมั่นใจ อ่านแล้วเชื่อได้สนิท

การซ่อมที่ไม่มีใครตรวจซ้ำ ก่อนหน้านั้นวันที่ 31 สิงหาคม ตัวรีวิวเดียวกันนี้ส่งข้อสังเกตกลับมา 3 ข้อ เราแก้ครบทั้ง 3 ข้อ แล้วก็จบตรงนั้น ไม่มีใครส่งกลับไปให้รีวิวอีกรอบ พอกลับมาเปิดใหม่วันที่ 4 กันยายน ของที่เหลือค้างอยู่ต้องใช้อีก 13 รอบถึงจะหมด แบ่งเป็นฝั่งไทย 8 รอบ ฝั่งอังกฤษ 5 รอบ ตัวเลข 3 ข้อที่แก้จบไปตอนนั้นเลยไม่ได้แปลว่าเหลือ 0 มันแปลว่าเราหยุดนับ

ผู้ตรวจที่ตรวจถูกเรื่อง แต่ไม่ใช่เรื่องที่พัง บอตตัวนั้นตรวจภาษา และตรวจได้ดีด้วย สิ่งที่มันไม่เคยถามเลยสักรอบคือบทความอ่านต้นทางที่ตัวเองอ้างถึงหรือยัง พอไม่มีใครถามคำถามนั้น ตอนที่ 2 ก็ออกไปโดยเอ่ยชื่อเสาของ Andrew Ng ครบ 0 จาก 5 เสา ทั้งฉบับไทยและฉบับอังกฤษ และไม่มีไดอะแกรมของแผนที่อยู่บนหน้าเลย บทความเถียงจากแผนที่ที่คนอ่านมองไม่เห็น

verdict ไม่ใช่หลักฐานว่าตัวตรวจกลไกได้รัน บอตรีวิวตัวนี้อ่านอย่างเดียว รันคำสั่งไม่ได้ เลยรัน lint เชิงกลไกเองไม่ได้ และก็บอกเราตามตรงแบบนั้นทุกรอบ ปัญหาอยู่ที่ฝั่งเรา เพราะพอเห็น verdict ที่ดูครบถ้วน เราก็รู้สึกไปเองว่าตรวจครบแล้ว ทั้งที่ตัวตรวจกลไกยังไม่ได้วิ่งเลยสักครั้ง

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

ตัวตรวจที่นับถูก แต่นับผิดโซน ด่านเดียวกันนี้ตัด <script> ทิ้งก่อนตรวจ แล้ววันหนึ่งคำอธิบายศัพท์ของเราไปลงอยู่ใน JSON-LD ของ FAQPage คือข้อมูลโครงสร้างที่เขียนไว้ให้เครื่องมือค้นหาอ่าน และไม่แสดงบนหน้าเว็บจริง แทนที่จะอยู่ในเนื้อความ ด่านนับว่ามีคำนั้นอยู่ 1 ครั้ง ซึ่งตรงตามเกณฑ์พอดี ทุกด่านขึ้นเขียว แล้วคนอ่านก็ไม่เคยเห็นคำอธิบายนั้นเลย บทเรียนตรงนี้สั้นและใช้ได้ทั่วไป คือให้ยืนยันโซนที่ของต้องไปอยู่ ไม่ใช่ยืนยันจำนวนครั้งที่มันปรากฏ

hook ที่ตัดสินเองว่าไม่ต้องตรวจ เรามี pre-commit hook ที่คัดว่า commit ไหนแตะเนื้อความบ้าง วันนั้นเราเพิ่มบรรทัดคำอธิบายศัพท์เข้าไป 1 บรรทัด hook จัดว่านี่ไม่ใช่การแตะเนื้อความ แล้วข้ามการตรวจไป

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

แล้วมีตัวหนึ่งที่ทำถูก

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

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

ช่วงที่ 4พรุ่งนี้ทำอะไรต่างจากเดิม

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

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

อย่างที่สองคือเปลี่ยนสิ่งที่เขียนลงไฟล์ standing context จากคำสั่งว่าให้ทำอะไร เป็นบันทึกว่าสมมติฐานไหนเปลี่ยนไปแล้ว Andrew Ng ชี้จุดนี้ไว้ในข้อ 2 และเป็นข้อมูลที่หายง่ายที่สุดในบรรดาที่มี การจดใช้เวลา 1 นาที ส่วนการอธิบายใหม่ทุก session ใช้เวลาไม่รู้จบ

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