Codex เพิ่มโหมด goals — สั่งเป้าหมายแล้วให้ AI รันงาน coding เองยาวๆ จนถึงเกณฑ์ที่ตั้งไว้

ปกติเวลาเราสั่งงาน coding agent คือสั่งทีละ task แล้วคอยป้อนคำสั่งถัดไปเรื่อย ๆ แต่ goals เปลี่ยนวิธีคิดตรงนี้ — แทนที่จะสั่งทีละก้าว เราตั้ง "เป้าหมาย" หนึ่งอันให้ชัด พร้อม "เกณฑ์ความสำเร็จ" ว่าแบบไหนถึงเรียกว่าจบ แล้วปล่อยให้ Codex เดินไปหาเป้าหมายนั้นเอง

ให้นึกภาพง่าย ๆ ว่า goal คือการบอกปลายทางกับเงื่อนไขว่า "ถึงแล้ว" หน้าตาเป็นยังไง แทนที่จะคอยบอกทางเลี้ยวทีละโค้ง ฟีเจอร์นี้ยังเป็นของทดลอง (experimental) เปิดใช้ผ่าน config.toml ด้วยการตั้งค่า `[features] goals = true` แล้วเรียกใช้ผ่านคำสั่ง `/goal` โดยแต่ละ goal จะผูกอยู่กับ chat/thread เดียว ไม่กระจายไปปนกับงานอื่น

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

เบื้องหลัง goals ถูกอธิบายว่าเป็น "Ralph loop" ที่ฉลาดขึ้น — Ralph loop คือการให้ AI วนทำงานเป็นรอบ ๆ ไปเรื่อย ๆ จนกว่าจะถึงเป้า สิ่งที่ทำให้รอบนี้ต่างคือมันจัดการตัวเองได้มากขึ้น: เก็บไฟล์ continuation และ budget ของตัวเอง สรุปงานที่ทำไปแล้วเมื่อใกล้ชน token cap เพื่อไม่ให้ลืม context เดิม และ audit ผลงานของตัวเองระหว่างทาง

อีกเรื่องที่ทำให้ใช้งานจริงได้คือมันรองรับ pause แก้ไข แล้วกู้คืนได้ รวมถึงกู้คืนหลัง crash ด้วย แปลว่าระหว่างที่ปล่อยให้รันยาว ๆ เราเข้าไปแทรกได้ ไม่ใช่กดสั่งแล้วต้องลุ้นยาวจนจบรอบเดียว ส่วนเรื่องระยะเวลา มีรายงานผู้ใช้รัน goals ต่อเนื่องตั้งแต่ 9 ชั่วโมงไปจนถึง 3 วัน

ฝั่งเดโมที่ออกมาให้เห็นภาพคืองานสร้างเกม 2D โดยดึง asset จาก GPT Image 2 มาใช้ และทดสอบด้วย Playwright ซึ่งสะท้อนว่า loop นี้ไม่ได้เขียนโค้ดอย่างเดียว แต่ครอบไปถึงการหา asset และรันเทสต์เพื่อตรวจงานตัวเองในรอบเดียวกัน

"ตั้งเป้าแล้วปล่อยให้ AI ลุยเอง" คือทิศทางใหม่ของ coding agent ที่น่าตื่นเต้นจริง — แต่ขอย้ำจุดที่คนทำงานต้องไม่หลงตาม: รันนานไม่ได้แปลว่างานดี การที่ agent รันต่อเนื่อง 9 ชม. หรือ 3 วันฟังดูว้าว แต่ตัวเลขเวลาไม่ใช่ตัววัดคุณภาพงาน มันบอกแค่ว่า loop ยังไม่หยุด ไม่ได้บอกว่าผลที่ออกมาใช้ได้จริง

สิ่งที่ตัดสินว่างานดีหรือไม่คือ "เกณฑ์ตรวจวัดได้" ที่เราตั้งไว้ตั้งแต่ต้น และจุดที่คนต้องเข้าไปตรวจเองก่อนเอาไปใช้ — Human Gate คือจุดที่คนต้องตรวจ ไม่ปล่อยให้ AI ตัดสินใจแทนทั้งหมด ยิ่งงานที่รันยาวและทำหลายขั้นแบบนี้ ยิ่งต้องมีเกณฑ์ชัดว่า "ผ่าน" หน้าตาเป็นยังไง ไม่งั้นเราจะได้กองงานที่ดูเยอะแต่ไม่รู้ว่าตรงสเปกไหม

ฟันธงสำหรับตอนนี้: น่าลองในงานที่เสี่ยงต่ำและตรวจง่าย — งานทดลอง งาน prototype หรืองานที่เรามีชุดเทสต์ไว้วัดผลอยู่แล้ว เพราะมันเป็นฟีเจอร์ทดลอง ตั้งเป้าให้แคบ เขียนเกณฑ์ความสำเร็จให้วัดได้ด้วยตา (หรือด้วยเทสต์) แล้ววาง Human Gate ไว้ก่อนเอาผลไปใช้จริงทุกครั้ง อย่าเพิ่งเอาไปปล่อยยาวกับงานบริษัทหรือ codebase ที่พังแล้วเดือดร้อน — ให้เริ่มจากงานที่ถ้าพลาดก็แค่ทิ้งแล้วรันใหม่