ถ้าสั่ง AI agent ว่า "เพิ่มปุ่ม export เป็น Excel ให้หน้ารายงาน" agent ก็ทำเสร็จใน session เดียว ไม่ต้องมีขั้นตอนอะไร ปัญหาเริ่มเมื่องานใหญ่กว่านั้น เช่น ระบบสต็อกที่ต้องแยกเป็นห้าหกชิ้น ทำหลายวัน และ context ของ agent เต็มไปหลายรอบ
agent ไม่จำว่าเมื่อวานคุยอะไรกัน ถ้าไม่มีที่จด เราต้องเล่าใหม่ทุกครั้ง และสิ่งที่ตกลงกันไว้ก็หายไปทีละข้อ ผมเลยเขียน skill ชื่อ task ขึ้นมา และแก้มาตลอดตั้งแต่มีนาคม 2569 ความรู้ของโปรเจกต์ที่ใช้ได้นานเก็บไว้อีกที่ ส่วนงานที่กำลังทำต้องมีที่จดของตัวเอง
งานหนึ่งชิ้นวิ่งผ่านห้าขั้น
ขั้นที่ผมต้องอยู่ด้วยคือตอนตอบคำถาม ที่เหลือ agent เดินเอง แล้วผมดูผลบนระบบจริง
ทุกงานมีโฟลเดอร์ของตัวเอง
งานแต่ละชิ้นได้เลข เช่น T37 และมีโฟลเดอร์ใน .ai/tasks/<รอบงาน>/ รอบงานตั้งชื่อตามปีเดือน เช่น 2609-v4 ข้างในมีไม่กี่ไฟล์
requirement.mdคำสั่งเดิมของผมแบบคำต่อคำ และสิ่งที่ตกลงกันระหว่างทางtodo.mdรายการชิ้นงานกับสถานะ และบันทึกความคืบหน้าสั้น ๆ ว่าทำอะไรไปแล้ว อะไรที่ session ถัดไปต้องรู้- ไฟล์แผน ของแต่ละชิ้น
ไฟล์ index.md ของรอบงานรวมทุกงานกับสถานะไว้ที่เดียว session ใหม่ที่หยิบงานต่อเปิดไฟล์พวกนี้ก็รู้ว่าถึงไหนแล้ว โดยไม่ต้องให้ผมเล่า
ระหว่างทำงานชิ้นหนึ่ง ถ้าเจอเรื่องอื่นที่ควรแก้ agent จะเปิดเป็น GitHub issue แล้วทำงานเดิมต่อ ไม่เลี้ยวไปทำเรื่องใหม่กลางทาง issue พวกนี้ผมค่อยมาคัดทีหลังว่าจะรวมเข้างานไหนหรือทิ้ง
agent ถามก่อนวางแผนทุกครั้ง
ขั้นนี้ผมว่าคุ้มที่สุด ก่อนเขียนแผน agent ต้องอ่านเอกสารของส่วนนั้นและโค้ดที่มีอยู่ก่อน แล้วถามผม 5–10 ข้อ แต่ละข้อมีตัวเลือกพร้อมภาพตัวอย่างสั้น ๆ และบอกว่าแนะนำข้อไหน ผมจึงตอบได้ด้วยการกดเลือกเป็นส่วนใหญ่
คำถามที่ดีคือคำถามที่ถ้าตอบต่างกันแล้วโครงข้อมูล ตาราง หรือสิทธิ์ของผู้ใช้จะต่างไปด้วย เช่น ใบสั่งซื้อที่อนุมัติแล้วแก้ได้ไหม หรือใครเป็นคนปิดงวด ส่วนเรื่องอย่างชื่อปุ่มหรือสี agent ตัดสินเองแล้วแจ้งให้รู้
ถามผิดทางสักข้อตอนนี้เสียเวลาไม่กี่วินาที แต่ถ้าเดาผิดแล้วไปรู้ตอนเขียนเสร็จ ต้องรื้อกันใหม่ Superpowers ให้ agent ซักจนได้ spec ก่อนเหมือนกัน และ /grill-me ของ Matt Pocock ก็เป็นแนวเดียวกัน เขาบอกว่าเป็น skill ที่คนใช้มากที่สุดในชุด
ทำเสร็จแล้วปิดงานในขั้นเดียว
ขั้น implement ของผมเขียนทั้งโค้ด test สไตล์ และแก้เอกสารที่เกี่ยวข้อง แล้วเปลี่ยนสถานะชิ้นงานเป็นเสร็จเองเลย ไม่มีขั้นรอผมรีวิวแยก
เดิมผมมีขั้น review แยกอยู่ช่วงหนึ่ง แล้วก็ตัดทิ้ง เพราะสิ่งที่ผมอยากรู้จริง ๆ คือระบบทำงานถูกไหม agent พิสูจน์ส่วนนั้นด้วย test ส่วนหน้าจอผมเปิดดูเอง agent ไม่ต้องเปิดเบราว์เซอร์ไล่กดเอง
พอผ่าน test, formatter และ static analysis ในเครื่องแล้ว ส่วนใหญ่ผมก็แค่บอกว่า "commit แล้ว push" ทุกวันนี้ Claude เฝ้า GitHub Actions ต่อเองหลัง push ถ้า CI ไม่ผ่านก็อ่าน log แก้ แล้ว push ใหม่จนผ่าน ไม่ต้องมีขั้นตอนพิเศษ สำหรับเว็บนี้การ push เข้า main คือ deploy ขึ้น production ผมจึงทดสอบบน production ได้เลยหลัง CI ผ่าน
งานหลายชิ้นพร้อมกันแยก session และ worktree
ถ้ารอบงานมีหลายชิ้นที่ไม่แตะไฟล์เดียวกัน ผมให้ทำพร้อมกันได้ session หนึ่งเป็นตัวคุม แบ่งชิ้นงานให้ session ละชิ้น แต่ละ session ทำใน git worktree ของตัวเอง ทำเสร็จก็ส่ง branch กลับมา ตัวคุมเป็นคนเดียวที่ merge และ push
worktree ทำให้หลาย session ไม่แย่งไฟล์กัน แต่โปรเจกต์ Laravel ใน worktree ใหม่ต้องมี .env ฐานข้อมูล และ vendor ของตัวเองก่อนรันได้ ผมทำคำสั่งที่ตั้งให้ครบในทีเดียวไว้ใช้เอง
ทำแบบนี้มีต้นทุน session ใหม่แต่ละตัวต้องอ่านโปรเจกต์ก่อนเริ่มงาน ใช้ราว 40,000–60,000 token ก่อนเขียนโค้ดบรรทัดแรก รอบหนึ่งผมแบ่งงานให้เก้า session ใช้ไปราว 1.3 ล้าน token เพราะทั้งเก้าตัวต่างเปิดอ่านเอกสารสามชิ้นเดียวกันเอง ตั้งแต่นั้นตัวคุมจะคัดข้อกำหนดที่สำคัญใส่ลงในคำสั่งของแต่ละ session เลย ไม่ให้แต่ละตัวไปอ่านเอกสารเอง และรวมงานในส่วนเดียวกันให้ session เดียวทำ
Superpowers ก็มี skill แบ่งงานให้ subagent ทำคู่ขนานใน worktree คล้ายกัน ข้อต่างคือของผมเป็น session ที่ผมเปิดดูและคุยด้วยได้ทีละตัว
งานยาวที่ทำซ้ำเป็นขั้น ๆ ใช้ Ralph loop
Ralph เป็นแนวของ Geoffrey Huntley คือวนเรียก agent ตัวใหม่ซ้ำ ๆ ด้วยคำสั่งเดิม แต่ละรอบเริ่มจาก context ว่าง อ่านบันทึกว่ารอบก่อนทำถึงไหน ทำอีกหนึ่งขั้นที่ตรวจได้ บันทึก แล้วจบ ความจำอยู่ในไฟล์ทั้งหมด งานจึงยาวได้โดย context ไม่เต็ม
ผมใช้กับงานที่แบ่งเป็นขั้นชัดและมี test เป็นตัววัด อย่างครั้งที่ทำให้ test ทั้งชุดรันเร็วขึ้นทีละขั้น รอบของ Ralph ไม่ commit เอง ผมดู diff ที่สะสมไว้ทีหลัง ส่วนงานที่ต้องตัดสินใจระหว่างทาง หรืองานหน้าจอ ไม่เหมาะกับ Ralph
เมื่อ context ใกล้เต็มให้เขียน handoff
ถ้างานยังไม่เสร็จแต่ context ใกล้เต็ม ผมให้ agent เขียนไฟล์ handoff บอกว่าทำอะไรไปแล้ว กำลังทำอะไร อะไรที่ลองแล้วไม่ได้ผล และเตรียมคำสั่งเริ่มต้นไว้ให้ session ใหม่ ปิด session เดิมแล้วเปิดใหม่ งานก็เดินต่อจากจุดเดิม Matt Pocock ก็มี skill /handoff ไว้ทำแบบเดียวกัน
