ตอนจบ Day 1 แอดมีภาพคร่าวๆ ว่าอยากให้ทีม AI รับงานไปทำยังไง คนจะอยู่ในบทบาท PO หรือ Product Owner คอยกำหนดว่างานไหนสำคัญ ตัดสินใจเมื่อมีเรื่องที่ต้องเลือก และตรวจว่าผลออกมาตรงกับที่ต้องการหรือเปล่า ส่วนการแจกงาน ส่งต่อให้คนตรวจ และเรียกคนเดิมกลับมาแก้ เป็นหน้าที่ที่อยากให้ระบบช่วยรับไป
แต่ตอนนั้นยังตอบไม่ได้ว่าจะเอาส่วนไหนมาจากเครื่องมือที่มีอยู่ และส่วนไหนต้องเตรียมเอง พอไปดู Symphony, Agent Orchestrator, Gas Town, Emdash และ Claude Squad ก็เห็นว่าเดโมหลายตัวทำให้เห็นภาพเดียวกันได้ค่อนข้างเร็ว คือเปิดมาแล้วมองออกว่า agent แต่ละตัวทำงานอะไรอยู่ งานไหนรอ และงานไหนเสร็จแล้ว
ภาพนั้นดูเข้าใจง่ายดีครับ โดยเฉพาะเวลาที่มีหลายงานพร้อมกัน แต่พอลองนึกถึงตอนที่แอดจะใช้จริง สิ่งที่อยากรู้ต่อจากที่เห็นการ์ดอยู่ในช่องกำลังทำ คือถ้างานนั้นเสร็จแล้วใครจะรับต่อ หรือถ้าคนที่กำลังทำติดโควตา งานจะหยุดอยู่ตรงนั้นจนต้องกลับมาสั่งเองอีกไหม เพราะตรงนั้นต่างหากที่จะบอกว่าแอดปล่อยให้ทีมเดินเองได้แค่ไหน
แอด: Kanban ไม่ได้ซีเรียสเท่าการจัดการ agent profile กับการทำให้มันทำงานต่อเนื่อง อยากรู้ว่า AO ทำอะไรได้อีกบ้างนอกจากหน้าบอร์ด
Kanban ในที่นี้คือหน้าบอร์ดที่แบ่งการ์ดตามสถานะ เช่น รอทำ กำลังทำ หรือรอตรวจ ถ้ามีงานค้างก็เปิดดูได้ว่าไปหยุดอยู่ตรงไหน ส่วน agent profile คือชุดที่บอกว่า AI ตัวนั้นรับบทอะไร ใช้โปรแกรมและโมเดลไหน มีวิธีทำงานหรือ skill อะไรให้เรียกใช้ และควรทำอะไรได้บ้างในบทบาทนั้น
ลองสมมติว่าทีมได้รับงานแก้หน้าล็อกอิน แอดอยากให้ Dev หรือ Developer ลงมือแก้ตาม requirement หรือความต้องการของงาน แล้วส่งให้ Reviewer ตรวจว่าโค้ดทำตามที่ตกลงไว้หรือยัง ถ้าคนตรวจเจอว่ากดยกเลิกแล้วกลับผิดหน้า สิ่งที่อยากให้เกิดคือ Dev ได้ข้อสังเกตนั้นกลับไปแก้ พร้อมรู้ว่าต้องลองกดตรงไหน หลังจากนั้น QA หรือ Quality Assurance ซึ่งเป็นคนที่ดูแลคุณภาพ จะได้ทดสอบตามสถานการณ์เดิมและส่งผลกลับมาให้ดู แอดจะได้เข้ามาอ่านตอนที่มีเรื่องต้องตัดสินใจ โดยไม่ต้องเป็นคนเปิดแชทสามอันแล้วคัดข้อความไปวางให้ครบ
Tech Lead (GPT): ลองแยกดูสามช่วงครับ เปิด session เดิมกลับมาทำต่อได้ไหม ส่งงานไปตรวจแล้ววนกลับมาแก้ได้ไหม และพอจบงานนี้แล้วทีมเริ่มงานถัดไปตามกติกาที่ตั้งไว้ได้หรือเปล่า
คำว่า session ในที่นี้หมายถึงรอบการทำงานของ agent ที่มีบริบทและประวัติของมันอยู่ อย่างตอนปิดหน้าจอไปแล้วเปิดกลับมาอ่านบทสนทนาเดิมได้ ก็ช่วยให้ตามงานง่ายขึ้น แต่ยังต้องดูต่อว่า agent กลับมาทำงานที่ค้างไว้ได้ไหม ส่วนงานที่ผ่านไปถึงคนตรวจแล้วก็มีอีกคำถามว่า เมื่อมีผลตรวจเข้ามา ระบบรู้หรือเปล่าว่าควรปลุกใครให้กลับมาทำต่อ สุดท้ายถ้าจะให้ทีมรับงานชิ้นใหม่เอง ก็ต้องมีกติกาอีกชุดว่าเลือกงานไหนได้ และเรื่องแบบไหนต้องหยุดรอ PO
Agent Orchestrator หรือ AO ที่พูดถึงกันในตอนนี้คือของ Orchestrator.inc ส่วนที่น่าสนใจคือมันให้ agent หลักช่วยวางแผนและแตกงาน แล้วเปิดพื้นที่แก้โค้ดแยกให้ agent ที่ลงมือแต่ละตัว พื้นที่นี้เรียกว่า Git worktree ทำให้ทำงานบน branch หรือสายงานของตัวเองได้โดยไม่ต้องสลับไฟล์ในโฟลเดอร์เดียวกันไปมา
เมื่อมี Pull Request หรือ PR ซึ่งเป็นคำขอให้ตรวจและรวมโค้ด AO ยังตามผลการตรวจอัตโนมัติอย่าง CI หรือ Continuous Integration และส่งผลที่ไม่ผ่านหรือความเห็นจากคนตรวจกลับไปให้ agent เจ้าของงานได้ด้วย ตรงนี้เริ่มตอบคำถามที่แอดถามเรื่องบอร์ด เพราะสถานะบนการ์ดมีงานอยู่ข้างหลัง อย่างผลตรวจไม่ผ่านแล้วกลับไปหา Dev ได้โดยไม่ต้องให้แอดส่งข้อความเองอีกทอด
พอเห็นว่าส่วนแจกงานและตามผลมีอยู่แล้ว แอดเลยถามต่อว่าเอา engine หรือส่วนที่คุมการทำงานของ agent มารันบนเครื่องของเราได้ไหม คำว่า self-hosted ในที่นี้หมายถึงให้เครื่องของเราเป็นที่รันตัวจัดการและโปรแกรมของ agent ส่วนโมเดลที่เรียกใช้ยังขึ้นกับผู้ให้บริการที่เลือก ที่แอดอยากรู้จริงๆ คือเครื่องที่รันงานจะอยู่ที่หนึ่ง แล้วแอดเปิดจากอีกเครื่องมาดูหรือสั่งต่อได้แค่ไหน
แอด: ถ้ามี Mac สักเครื่องไว้ลงโปรแกรมของแต่ละเจ้า แล้วแอดดูงานจากเว็บหรืออะไรสักอย่างได้ รวมถึงจัดการ agent กับ skill ได้จากข้างนอก พอเปลี่ยนเครื่องก็อยากเอาค่าที่เตรียมไว้มาลงต่อได้เลย
จากโจทย์นั้น ภาพของ MVP หรือ Minimum Viable Product ซึ่งก็คือชุดแรกที่เล็กพอจะลองใช้งานจริง เริ่มเหลือแค่เครื่อง Mac สำหรับรันงาน เครื่องมือที่มีหน้าควบคุมมาให้ และที่เก็บการตั้งค่าของทีม Claude Code, Codex และ Cursor จะเป็นโปรแกรมที่อยากลองใช้กับบัญชีที่สมัครไว้ โดยมีตัวจัดการคอยเรียกแต่ละตัวตามงานที่รับ ส่วนหน้าจอเอาไว้ให้แอดเข้าไปดูความคืบหน้าหรือตอบคำถามเวลาที่ทีมติดอยู่
ตอนแรกที่คุยกันว่าใช้ script กับ repo เก็บ state แอดยังเอาเรื่องการตั้งค่ากับสถานะที่กำลังรันมาคิดรวมกันอยู่ คำว่า repo หรือ repository คือที่เก็บไฟล์ที่ใช้ Git ตามประวัติการแก้ไขได้ ส่วน state คือข้อมูลว่าระบบกำลังอยู่ตรงไหน เช่น มีงานที่รอคนตรวจ หรือมีข้อความที่เข้าคิวรอให้ agent รับไปทำต่อ พอแยกสองอย่างนี้ออก ก็เห็นว่าการตั้งทีมใหม่บนอีกเครื่องกับการกู้ให้ทีมเดิมทำงานที่ค้างอยู่ต่อได้เป็นคนละงานกัน
Tech Lead (GPT): ให้ Mac เป็นเครื่องลงมือทำงาน ส่วนรายชื่อโปรเจกต์ คำสั่งของแต่ละบทบาท และ skill เก็บใน Git พอย้ายเครื่องจะได้มีต้นฉบับให้ดึงกลับมา ส่วนงานที่กำลังรันให้ดูวิธีสำรองของตัว engine อีกที
อย่างถ้าเปลี่ยนเครื่องแล้วดึงไฟล์จาก Git มาได้ครบ แอดก็ควรเห็นว่าใครทำหน้าที่ Dev ใครตรวจ และแต่ละโปรเจกต์ใช้ skill ชุดไหน ส่วนบัญชีของผู้ให้บริการต้องจัดการการเข้าสู่ระบบบนเครื่องใหม่ และถ้าอยากเปิดงานที่ค้างอยู่กลับมาดูพร้อมประวัติเดิม ก็ต้องกู้ข้อมูลที่ตัวเครื่องมือใช้เก็บ session และคิวด้วย การมีไฟล์ตั้งค่าครบช่วยให้ตั้งทีมได้ใหม่ ส่วนจะรับช่วงจากจุดเดิมได้ไหมต้องลองกู้จริง
จาก Day 1 แอดมีภาพคร่าวๆ ว่าอยากให้ Cursor รับงานพัฒนา และให้ Codex ช่วยตรวจงานกับทดสอบ แต่ถ้าวันหนึ่งอยากเปลี่ยน Dev ไปใช้อีกตัว สิ่งที่ควรเปลี่ยนได้คือโปรแกรมหรือโมเดลที่เรียกใช้ ส่วนคำสั่งว่าบทบาทนี้ต้องรับข้อมูลอะไร ส่งงานในรูปไหน และต้องส่งให้ใครตรวจ ควรยังอ้างถึงชุดเดียวกันได้
ถ้าจะเปลี่ยนตัวรับงานตั้งแต่ก่อนเริ่ม ก็พอเลือกให้ตัวใหม่อ่านคำสั่งของบทบาทเดิมได้ แต่ถ้าจะเปลี่ยนระหว่างที่กำลังแก้อยู่ ตัวใหม่จะต้องรู้เพิ่มว่าคนก่อนแก้ไปถึงไหนแล้ว ข้อมูลที่ส่งต่อได้ชัดๆ จึงเป็นโค้ดที่แก้ไว้ เงื่อนไขของงาน ผลทดสอบล่าสุด และสิ่งที่ยังค้าง ตรงนี้เริ่มเกี่ยวกับค่าใช้จ่ายด้วย เพราะเหตุหนึ่งที่อาจต้องหยุดรอหรือสลับตัวก็คือบัญชีที่ใช้อยู่ถึงขีดจำกัดของรอบนั้นแล้ว
แอด: แล้ว subscription ระดับที่สมัครมาเขียนโค้ดนี่ เราเช็กเครดิตที่ใช้ไปได้จริงเหรอ ถ้ายังอ่านไม่ได้ก็ยังไม่ต้องทำเครื่องมือวิเคราะห์ใหญ่ เก็บลง SQLite ก่อนได้
ค่าใช้จ่ายที่แอดอยากดูมีทั้งเงินที่จ่ายจริงและเวลาที่งานหยุดรอ ถ้าจ่ายรายเดือน เงินที่จ่ายก็อ้างจากค่าสมาชิกกับรายการที่ถูกคิดเพิ่ม ส่วนข้อมูลอย่างงานรันกี่รอบ ใช้เวลานานแค่ไหน หรือติด limit เมื่อไร เอาไว้ดูว่างานกำลังสะดุดตรงไหน ต่อให้เครื่องมือหนึ่งบอกจำนวน token หรือหน่วยย่อยของข้อความที่โมเดลประมวลผลได้ ก็เอาไปคูณกับราคาของ API หรือ Application Programming Interface ซึ่งเป็นช่องทางที่โปรแกรมใช้เรียกบริการโดยตรง แล้วถือเป็นยอดที่จ่ายในแผนรายเดือนไม่ได้
Tech Lead (GPT): แผนรายเดือนไม่ได้แปลว่าจะมี API อ่านโควตาคงเหลือให้ทุกเจ้า บางตัวอาจมีสถานะให้ดูในโปรแกรม ถ้าอ่านได้แค่ว่าติด limit ก็เก็บเท่าที่รู้ก่อน
ถ้าภายหลังต้องตามข้อมูลพวกนี้จริง SQLite ซึ่งเป็นฐานข้อมูลแบบไฟล์ก็พอสำหรับบันทึกว่างานไหนรันด้วยอะไร สำเร็จหรือติดตรงไหน ส่วนการรอจนใช้ได้อีกหรือส่งงานไปให้ตัวสำรองเป็นกติกาที่ต้องตัดสินใจแยกกัน ถ้ารู้เวลารีเซ็ตก็มีข้อมูลให้วางแผนรอต่อ ถ้ายังไม่รู้ก็เก็บสถานะตามที่เห็น กติกาที่แอดอยากรักษาไว้คือใช้สิทธิ์ที่สมัครก่อน และให้คนตัดสินใจหากจะมีค่าใช้งานเพิ่ม
ถึงตรงนี้แอดขอถอยมาเทียบ AO กับ CAO อีกรอบ CAO คือ CLI Agent Orchestrator ของ AWS Labs โดย CLI ย่อมาจาก Command-Line Interface หรือช่องทางสั่งโปรแกรมด้วยข้อความในเทอร์มินัล ตัวนี้จัด agent ที่สั่งผ่านเทอร์มินัลเป็น session แยกกัน มี profile สำหรับตั้งตัว agent มี supervisor สำหรับประสานงาน และมีหน้าควบคุมผ่านเว็บมาให้ ตัวที่รับงานพัฒนากับตัวที่ตรวจงานจึงเป็นจุดตั้งต้นของการตั้งค่าที่เห็นได้ชัดกว่าเดิม
ฝั่ง AO ทำให้งานตั้งแต่แบ่งโค้ดออกไปให้แต่ละตัวจนถึงตามผลตรวจกลับมาแก้เป็นทางเดียวกัน ส่วน CAO ชวนให้เริ่มจากคิดว่า agent แต่ละตัวต้องรู้อะไร ใช้เครื่องมืออะไร และตัวที่คุมงานจะส่งงานให้ใคร ในตอนนั้น GPT เริ่มเอนไปทาง CAO เพราะเรื่องที่แอดอยากเข้าไปเปลี่ยนบ่อยๆ คือบทบาท โมเดล และ skill ส่วน Git การเปิด PR และการรันชุดทดสอบ แอดเคยให้ agent ทำผ่าน skill อยู่แล้ว จึงไม่ได้อยากให้ความครบของส่วนนี้เป็นตัวตัดสินหลัก
ระหว่างเทียบกัน GPT ใช้คำว่า harness จนแอดต้องถามว่าหมายถึงอะไร ลองคิดว่าโมเดลเป็นส่วนที่ใช้คิดและตอบ ส่วน harness คือโปรแกรมอย่าง Claude Code ที่ให้โมเดลทำงานกับไฟล์ เครื่องมือ และคำสั่งบนเครื่องได้ การเปลี่ยนโมเดลในโปรแกรมเดิมจึงใช้วิธีต่างจากการส่งงานจาก Claude Code ไปให้ Codex รับต่อ พอกลับไปมองเรื่อง profile ก็เห็นว่าคำว่าเลือก agent ได้อาจหมายถึงเลือกแค่โมเดลในหน้าสนทนา หรืออาจหมายถึงตั้งโปรแกรมและวิธีทำงานให้กับบทบาทนั้นได้ทั้งชุด ซึ่งเป็นคนละเรื่องที่ต้องลองดู
แอด: แล้วถ้าลงระบบชุดเดียว อยากให้เพื่อนมี workspace ของตัวเองด้วยล่ะ และอย่าลืมเรื่องทำงานต่อเนื่องนะ
Workspace ในความหมายที่แอดอยากได้คือพื้นที่ทำงานของทีมหนึ่งที่มีโปรเจกต์ คำสั่งและ skill ของตัวเอง ต่อให้ทั้งสองทีมมีบทบาทชื่อ Reviewer เหมือนกัน คนหนึ่งอาจต้องดูเว็บและเช็กผลบนเบราว์เซอร์ ส่วนอีกคนอาจต้องรับหลักฐานทดสอบจาก Android ที่รันบนเครื่องอีกตัว แค่เห็นว่าตัวโปรแกรมเปิดได้หลายโปรเจกต์จึงยังตอบได้เพียงส่วนหนึ่ง ต้องดูด้วยว่าเวลาส่งงานจริง agent จะอ่านค่าของทีมไหน และจะคุมไม่ให้งานหรือบริบทไปปนกันยังไง
แล้วแอดก็ทักอีกเรื่องที่มีผลกับการเลือกพอๆ กัน คือถ้าเอา CAO มาใช้แล้วต้องไปนั่งทำเว็บเพิ่มและ debug เองทุกจุด แบบนั้นก็อาจเสียเวลาไปกับการดูแลระบบที่ตั้งใจจะเอามาช่วยลดงานอีกที คราวนี้ GPT กลับมาเสนอ AO ก่อน เพราะมีช่องทางดูงานและตอบ agent จากมือถือให้ลองได้เลย พร้อมกับทวนว่า CAO เองก็มีหน้าเว็บอยู่แล้ว คำถามที่เหลือจึงเจาะจงขึ้นว่า ด้วยหน้าที่มีอยู่ แอดจะดูงานและจัดการทีมได้ตามแบบที่ต้องการแค่ไหน และต้องทำส่วนเชื่อมเพิ่มตรงไหนบ้าง
พอคุยถึงการเข้าจากข้างนอก แอดก็ถามต่อว่าถ้าลงทุกอย่างบนเครื่องตัวเองจะยังมีค่าสมาชิกเพิ่มไหม ตรงนี้ต้องดูแยกเป็นค่าตัวจัดการ ค่าสมาชิกของ agent ที่เรียกใช้ และค่าช่องทางเข้าถึงจากภายนอก เพราะการรันตัวจัดการบน Mac ของเราเองยังอาจไปใช้บริการเชื่อมต่อของผู้พัฒนาได้ ถ้าช่องทางนั้นเป็นส่วนหนึ่งของแผนเสียเงิน ก็ต้องนับเพิ่มตอนตัดสินใจว่าจะใช้แบบไหน
ระหว่างที่ไล่ดูเครื่องมือตามลิสต์ที่ Tech Lead (GPT) แนะนำ แอดในฐานะ PO ก็เกือบจะตามน้ำไปแล้วครับ จากที่ตั้งใจจะดูว่ามีอะไรให้เลือกบ้าง พอคุยไปคุยมาก็เริ่มคิดอยู่แค่ว่าระหว่าง AO กับ CAO ตัวไหนจะทำให้แอดต้องลงมือเพิ่มน้อยกว่า
ปกติแอดตามอ่านเรื่องเทคโนโลยีในกลุ่มต่างๆ บนโซเชียลอยู่เรื่อยๆ แล้วก็มีชื่อหนึ่งที่เห็นผ่านตามาสักพักแล้ว พอมาเห็นอีกทีในจังหวะที่กำลังจะตัดสินใจพอดี ก็เลยหยิบกลับมาถาม GPT ว่าถ้าเอา 
“T3” มาเทียบกับสองตัวที่คุยกันอยู่ด้วยล่ะ
รุ่นที่แอดยกมาคุยตอนนั้นคือ T3 Code Nightly โดย Nightly เป็นรุ่นที่ออกถี่เพื่อให้ได้ลองของใหม่ก่อนรุ่น Stable หรือรุ่นที่ปล่อยให้ใช้ทั่วไป พอเอามาดูด้วยโจทย์เดียวกับสองตัวก่อนหน้า ก็เห็นว่ามีทั้งหน้าจอสำหรับใช้ coding agent หลายเจ้า ทางเข้าจากเครื่องอื่น และระบบส่งงานให้ agent ลูก ซึ่งเป็นส่วนที่แอดยังคุยกับ GPT อยู่ว่าจะต้องประกอบเองแค่ไหน
Tech Lead (GPT): ลองให้ตัวหลักส่งงานย่อยไปให้อีก provider รับ แล้วตามผลกลับมาที่งานหลักก่อนครับ ถ้าหน้าควบคุมที่มีใช้ดูผลนี้ได้อยู่แล้ว เราจะได้รู้ว่าต้องเขียนส่วนเพิ่มจริงๆ ตรงไหน
จุดที่น่าลองคือสมมติให้ตัวที่คุมงานส่งงานตรวจไปหาอีก agent พร้อมรายละเอียดงานและผลที่ต้องการ แล้วกลับมารับผลเมื่อเสร็จ เอกสารของ T3 Code อธิบายว่าการส่งแบบนี้สร้าง thread หรือห้องสนทนางานย่อยแยกขึ้นมา โดยตัวลูกได้โจทย์ที่ส่งให้ มันจึงมีเหตุให้ต้องเขียน brief ให้ดีตั้งแต่ตอนมอบหมาย ถ้าตัวตรวจต้องรู้เงื่อนไขจากบทสนทนาก่อนหน้า ก็ต้องส่งเงื่อนไขนั้นไปให้ด้วย
GPT เคยเสนอให้เริ่มจาก Stable ถ้าฟังก์ชันที่จะลองมีอยู่แล้ว ส่วนตอนขอให้เขียน handoff หรือเอกสารส่งต่องาน บทสนทนาก็ระบุ T3 Code Nightly เป็นตัวเลือกหลักสำหรับรอบทดลอง โดยยังเก็บ AO กับ CAO เป็นทางเลือก สิ่งที่ต้องเช็กกับรุ่นที่จะลงจริงมีทั้งการใช้บัญชีเดิมของแต่ละเจ้า การตั้งบทบาทต่อ workspace และพฤติกรรมของงานที่ค้างหลังปิดหน้าจอหรือรีสตาร์ต เปิดบทสนทนาเดิมได้อย่างเดียวคงยังตอบไม่ได้ว่าทีมจะตามงานของตัวเองต่ออย่างที่แอดอยากได้
คำถามสุดท้ายก่อนขอ handoff คือถ้าใช้ T3 Code แล้วยังเก็บ setting ใน Git แบบเดิมได้ไหม คำตอบที่แอดเอามาคิดต่อคือเก็บสิ่งที่กำหนดเองได้ เช่น คำสั่งแต่ละบทบาท skill และค่าของโปรเจกต์ ส่วนจะเอาค่าเหล่านั้นไปใช้ในหน้าตั้งค่าของ T3 ได้แค่ไหน ต้องดูว่าตัวโปรแกรมอ่านอะไรได้จริง การมีไฟล์บอกว่า Reviewer ควรใช้ Codex ยังต้องอาศัยการตั้งค่าหรือวิธีเรียกที่รองรับถึงจะมีผลตอนแจกงาน
GPT ลองร่างโครง repo ให้ดู โดยแยกคำสั่งของแต่ละบทบาทเป็นไฟล์ Markdown ไว้ใน team/ ส่วน skills/ มีทั้งวิธีทำงานที่ใช้ร่วมกันและส่วนที่ใช้เฉพาะบางทีม พอเก็บไฟล์เหล่านี้ใน Git ก็ย้อนดูได้ว่าทีมเปลี่ยนวิธีทำงานตรงไหน และดึงชุดเดิมกลับมาใช้ตอนย้ายเครื่องได้
พอขอเอกสารส่งต่อ แอดอยากให้ทั้งคนและ AI editor อ่านแล้วรู้ว่าจะเริ่มตรงไหน โจทย์ที่ได้จากวันนี้จึงพอเขียนให้ตรวจได้เป็นเรื่องๆ เช่น ให้ Mac เครื่องเดียวรันงานของสอง workspace ลองให้ Dev ส่งงานไปตรวจและรับข้อแก้กลับมา แล้วดูว่าถ้ารีสตาร์ตระหว่างที่งานกำลังค้าง จะกลับมาเห็นอะไรและทำต่อจากตรงไหนได้ ส่วนแอดอยากอ่านหลักฐานกับข้อที่ยังติด เพื่อเลือกว่าจะยอมรับได้แค่ไหน โดยไม่ต้องไล่กดทุกหน้าหรือเป็นคนตามส่งงานทีละรอบ
ตอนดูเดโม แอดเริ่มจากเห็นว่าบอร์ดทำให้รู้ว่าทีมกำลังทำอะไร พอคุยไปถึงตอนจะเอามารันจริง สิ่งที่อยากเห็นชัดขึ้นคือระหว่างที่เราไม่ได้เปิดดู ใครรับงานต่อจากใคร และถ้างานหยุดกลางทางจะเหลือข้อมูลอะไรให้คนถัดไปหยิบไปทำได้ วันที่สองเลยจบลงที่มีตัวให้ลองก่อน และมีโจทย์พอจะบอกได้ว่าถ้าลองแล้วต้องกลับมานั่งตามงานเองอยู่ดี ส่วนไหนของระบบที่ยังรับภาระจากเราไปไม่ได้
จากตรงนี้ Day 3 จะเริ่มที่แอดเอา handoff ไปให้ Claude อ่านและเริ่มตั้งต้นโปรเจกต์ในแชท “ตั้งค่าระบบและวางแผน” จากที่คุยกันว่าระบบควรทำอะไร คราวนี้จะได้เห็นว่าพอเริ่มจัดของจริงตามเอกสาร Claude หยิบส่วนไหนไปทำได้เลย และตรงไหนที่ยังต้องกลับมาถามแอดก่อน