มาถึงช่วงปลายปี 2026 นี้ แอดคงปฏิเสธไม่ได้แล้วว่า AI หรือ Artificial Intelligence ที่เรียกกันว่าปัญญาประดิษฐ์ กำลังเข้ามาทำงานหลายอย่างที่เคยต้องใช้คน และในฐานะ Dev หรือ Developer หรือนักพัฒนาคนหนึ่ง แอดก็มองว่างานของตัวเองคงเป็นกลุ่มแรกๆ ที่จะถูกแทนที่ได้มากขึ้นเรื่อยๆ หากยังไม่ปรับตัว
ในเมื่อรู้ตัวว่าถ้าจะแข่งกับมันด้วยการลงมือทำงานแบบเดิมตรงๆ ก็คงสู้ได้ยาก สิ่งที่ต้องคิดต่อจึงเป็นว่าจะอยู่ร่วมกับมันยังไง ใช้งานมันยังไง และจะใช้งานมันให้เก่งกว่าคนอื่นๆ ที่ทำงานแบบเดียวกับแอดในวันนี้ได้ยังไงด้วย
ถ้าพูดถึงว่าจะปรับตัวยังไงในยุค AI หลายคนก็คงบอกว่า ก็ใช้งานมันให้เป็นสิ แถมยังเป็นเรื่องดีเสียด้วย ถ้ามันช่วยให้เราทำงานได้เร็วขึ้น ลดต้นทุน และแบ่งเบาภาระไปได้มากมาย
มันก็ถูกครับ แต่ความสามารถเหล่านี้ไม่ได้มีให้แค่เราใช้คนเดียว เพื่อนร่วมงานก็ใช้ได้ คนที่ทำงานเหมือนเราก็ใช้ได้ และคนที่ว่าจ้างเราก็เริ่มเห็นแล้วว่า AI ช่วยสร้างเว็บ แอป หรือระบบตัวอย่างออกมาได้เร็วแค่ไหน เราจึงไม่ได้มีแค่ AI เป็นคู่แข่ง แต่ยังต้องตามให้ทันมาตรฐานการทำงานและความคาดหวังใหม่ๆ ของคนรอบตัวด้วย
เมื่อเพื่อนร่วมงานใช้ AI ทำงานบางส่วนได้เร็วขึ้น เวลาที่เคยใช้กับงานลักษณะเดียวกันก็อาจไม่ใช่เวลาที่ทีมยอมรับเหมือนเดิมอีกต่อไป หัวหน้าที่เคยวางแผนจากกำลังคนแบบเดิมก็อาจเริ่มคาดหวังว่าทีมควรส่งงานได้มากขึ้น ส่วนลูกค้าที่เห็นว่าคนอื่นสร้างหน้าตาเว็บหรือแอปออกมาได้ในเวลาไม่นาน ก็ย่อมมีคำถามว่างานของเราทำไมยังต้องใช้เวลาและงบประมาณเท่าเดิม
แม้การทำระบบให้ใช้งานได้จริงยังมีรายละเอียดต่อจากภาพต้นแบบอีกมาก แต่ความเร็วที่ลูกค้ามองเห็นก็กลายเป็นฐานใหม่ที่เขาใช้ประเมินงานไปแล้ว แอดเลยกังวลว่ามูลค่าของสิ่งที่เราเคยทำได้ด้วยความรู้และเวลาของตัวเอง จะถูกกดลงเรื่อยๆ หากสิ่งที่เรายังนำเสนอได้มีเพียงการลงมือเขียนให้เสร็จเหมือนเดิม
จากที่เคยแข่งกันว่าใครทำระบบแบบนี้ได้ จึงเริ่มมีคำถามเพิ่มว่าใครทำได้เร็วกว่า ใช้งบน้อยกว่า และยังรับผิดชอบให้มันใช้งานได้จริงต่อไป ใครๆ อาจเริ่มสร้างชิ้นงานได้ง่ายขึ้น แต่สำหรับคนที่ทำงานนี้เป็นอาชีพ เราต้องคิดด้วยว่าจะทำให้วิธีทำงานของตัวเองยังคุ้มกับสิ่งที่บริษัทหรือลูกค้าจ่ายให้ได้ยังไง
แล้วระหว่างที่ค่างานและค่าตัวของ Dev ในฐานะคนลงมือพัฒนากำลังถูกตั้งคำถาม เราก็มีต้นทุนแฝงเข้ามาเพิ่มด้วย ทั้งค่าสมาชิกเครื่องมือ AI ค่าใช้งานส่วนที่เกินสิทธิ์ และเวลาที่ใช้คอยป้อนข้อมูล ตรวจคำตอบ หรือส่งงานกลับไปแก้ บางอย่างประหยัดเวลาตอนเริ่มทำได้ แต่กลับมาใช้เวลาของเราอีกทีในช่วงตรวจและเก็บรายละเอียด
ถ้าลดเวลาลงมือเขียนได้ แต่ต้องนั่งเฝ้าและรับส่งงานให้ AI ทุกขั้น เราก็อาจแค่ย้ายแรงจากงานแบบหนึ่งไปสู่อีกแบบหนึ่ง ต้นทุนจึงไม่ได้จบที่ว่าสมัครเครื่องมือเดือนละเท่าไร ยังต้องนับแรงของคนที่ทำให้งานนั้นเดินจนส่งมอบได้ด้วย
ในมุมแอด คนที่จะไปต่อได้จึงต้องแข่งเรื่องต้นทุนและเวลากันมากขึ้น ต้องหาวิธีสร้างงานที่ตอบโจทย์ด้วยต้นทุนที่ต่ำลงและเวลาที่สั้นลง โดยยังมีคนรับผิดชอบคุณภาพกับผลที่ตามมา ความสามารถในการใช้ AI ให้เป็นจึงเริ่มดูเหมือนเป็นจุดเริ่มต้น ส่วนคำถามถัดไปคือจะจัดการให้มันช่วยงานได้มากขึ้น โดยที่เราไม่ต้องเพิ่มภาระให้ตัวเองตามไปด้วยได้ยังไง
วันหนึ่งระหว่างที่แอดกำลังรอโควตาการใช้งาน AI รอบใหม่ หรือที่ชอบพูดกันว่ารอ token รีเซ็ต ก็เลยกลับมาคิดถึงเรื่องที่ผ่านตามาสักพักใหญ่แล้ว แต่ยังไม่มีเวลาได้ลองด้วยตัวเองอย่างละเอียด นั่นคือการจัดระบบให้ AI ทำงานต่อกันเองได้ โดยให้แอดเหลือหน้าที่คอยชี้ทิศทางและสั่งเฉพาะเรื่องที่สำคัญจริงๆ
token ที่พูดถึงเป็นหน่วยย่อยของข้อมูลที่ AI ใช้อ่านและสร้างคำตอบ ทั้งข้อความที่เราส่งกับคำตอบที่มันเขียนล้วนใช้ token ส่วนที่แอดกำลังรอให้รีเซ็ตจริงๆ คือโควตาการใช้งานของแพ็กเกจที่สมัครอยู่
แทนที่จะมีผู้ช่วยตัวหนึ่งรอให้เราป้อนคำสั่ง ทำเสร็จแล้วก็รอเราเอาผลไปบอกตัวถัดไป แอดอยากให้มีตัวที่ช่วยทำความเข้าใจงาน มีตัวลงมือ และมีตัวกลับมาตรวจ ถ้าพบปัญหาก็ส่งกลับไปแก้กันได้ ก่อนรวบรวมสิ่งที่ต้องตัดสินใจกลับมาให้เรา
คนที่อยู่ในสายนี้ก็คงเคยผ่านตาเรื่อง multi-agent system หรือการใช้ AI หลายตัวมาทำงานร่วมกันมาบ้างแล้ว ส่วนการจัดว่าใครทำหน้าที่อะไร จะเริ่มทำเมื่อไร และส่งงานต่อกันยังไง ก็คือสิ่งที่เรียกว่า multi-agent orchestration นั่นแหละครับ มันเป็นแนวทางที่แอดอยากกลับมาดูให้ละเอียดขึ้น ว่ามีเครื่องมืออะไรช่วยทำไว้แล้ว และเรายังต้องจัดการเองอีกแค่ไหน
เพราะถ้า AI รับงานไปทำต่อกันได้มากขึ้น หน้าที่ของแอดก็น่าจะค่อยๆ ขยับจากคนที่ลงมือทำทุกส่วน มาเป็นคนกำหนดว่าอยากได้อะไร อะไรสำคัญก่อนหลัง และผลแบบไหนที่ยอมรับได้ คล้ายกับการมีทีมของตัวเองแล้วทำหน้าที่เป็น PO หรือ Product Owner ซึ่งเป็นคนดูแลความต้องการและลำดับความสำคัญของผลิตภัณฑ์ให้ทีมนั้น ส่วนการตามความคืบหน้า รับรู้ incident หรือเหตุขัดข้องของระบบ และตัดสินใจเรื่องสำคัญก็ยังเป็นความรับผิดชอบที่ต้องถือไว้
แอดเลยเริ่มจากการคุยกับ ChatGPT ซึ่งเป็นผู้ช่วย AI แบบสนทนาของ OpenAI ที่ยังพอคุยต่อได้อยู่บ้าง แม้ตอนนั้นจะติดข้อจำกัดการใช้งานของ AI ที่ใช้ทำงานไปแล้ว เอาความต้องการกับเรื่องที่ติดอยู่ไปคุยก่อน ว่าถ้าจะเริ่มจัดทีมแบบนี้ ควรหาเครื่องมือมาใช้หรือทำส่วนไหนเพิ่มเอง
บทสนทนาของเราเลยเริ่มต้นคล้ายแอดกำลังแอคเป็น PO คนหนึ่งที่คุยกับ Tech Lead หรือคนที่ดูแลแนวทางเทคนิคของทีม เริ่มจากความต้องการของแอด สิ่งที่เป็นปัญหา และเงื่อนไขสำคัญ แล้วถามกันไปมา ปรับความเข้าใจ เจาะรายละเอียดบางส่วน สลับกับวนกลับมาดูภาพใหญ่หลายครั้ง
บทความ Day 1 นี้เป็นบันทึกช่วงที่กำลังหาแนวทางนั้นครับ ยังไม่ได้จบที่การเลือกเครื่องมือครบทุกส่วน แต่จบที่รู้ว่าจะต้องกลับไปศึกษาผลิตภัณฑ์อะไร และใช้เงื่อนไขไหนประกอบการตัดสินใจ คำพูดที่ยกมาเรียบเรียงและย่อให้อ่านต่อกัน โดยยังคงเจตนาของบทสนทนาไว้
ก่อนจะไปถึงคำถามว่าต้องใช้โปรแกรมอะไร แอดเริ่มจากภาพการทำงานที่อยากให้เกิดขึ้นก่อน ถ้าให้ AI หลายตัวมาช่วยงาน เราคงไม่ได้อยากส่งโจทย์เดียวกันให้ทุกตัวแล้วรอเลือกคำตอบที่ชอบ เพราะงานพัฒนามีหลายหน้าที่ที่ช่วยกันรับผิดชอบได้อยู่แล้ว
ลองนึกถึงตัวอย่างสมมติว่าอยากเพิ่มการเข้าสู่ระบบด้วยบัญชี Google ให้แอป สิ่งที่ต้องทำยังไม่ได้มีแค่ปุ่มบนหน้าจอ ต้องเข้าใจก่อนว่าผู้ใช้ใหม่กับผู้ใช้เดิมจะเจออะไร ถ้ากดยกเลิกกลางทางจะกลับมาหน้าไหน และถ้าส่วนที่ตรวจบัญชีมีปัญหา แอปควรบอกผู้ใช้ยังไง
คนที่จะช่วยคิดเรื่องพวกนี้กำลังทำงานคนละส่วนกับคนที่จะลงไปเขียนโค้ด แต่ทั้งสองคนต้องอ้างถึงความต้องการ หรือที่เรียกกันในศัพท์เทคนิคว่า Requirement ชุดเดียวกัน
จากนั้นยังมีคนที่จะตรวจว่าโค้ดที่เขียนไปนั้นเข้าใจตรงกันหรือเปล่า และคนที่จะทดสอบว่าถ้าลองใช้งานตามสถานการณ์เหล่านั้นแล้วเกิดอะไรขึ้นจริง
แอดคิดว่าถ้าจะให้ AI มาช่วยเป็นทีม แอดก็อยากได้การแบ่งหน้าที่ประมาณนี้แหละ แต่ละตัวต้องรู้ว่าตัวเองเป็นใคร มีหน้าที่ต้องทำอะไร มากกว่าการมีหลายตัวเปิดรอให้เราป้อนคำสั่งทีละตัว
PO: อยากให้มันคุยกันเอง ไม่ทำงานซ้ำซ้อนกัน แต่ตรวจผลงานและสั่งแก้กันได้ตามลำดับ ส่วนฉันเข้าไปสั่งหรือเช็กงานเป็นครั้งคราว ที่เหลือให้ทีมรันต่อเอง
ตัวช่วยที่ทำงานแบบนี้มักถูกเรียกว่า agent คือ AI ที่มีเครื่องมือให้ลงมือทำบางอย่างต่อจากการตอบข้อความได้ เช่น อ่านไฟล์ในโปรเจกต์ แก้โค้ด หรือเรียกชุดทดสอบ การจะทำอะไรได้บ้างขึ้นอยู่กับโปรแกรมที่ใช้รันและสิทธิ์ที่ให้ไว้ด้วย จึงต้องดูมากกว่าความสามารถในการคุยของโมเดล ซึ่งก็คือตัว AI ที่ประมวลผลข้อมูลและสร้างคำตอบให้เรา
พอมีภาพหน้าที่แล้ว จึงค่อยย้อนมาดูเครื่องมือที่แอดมีใช้อยู่ตอนเริ่มคุย ว่าแต่ละตัวจะเข้ามาช่วยตรงไหนได้บ้าง ชื่อที่อยู่ในภาพตอนนั้นคือ Claude, Cursor และ Codex ซึ่งเกี่ยวข้องกับ AI เหมือนกัน แต่หน้าตาและวิธีใช้ไม่ได้เหมือนกันไปทั้งหมด
Claude เป็นผู้ช่วย AI ที่ใช้คุย วิเคราะห์ข้อมูล และช่วยเรียบเรียงความคิดได้ ส่วนเครื่องมือสำหรับลงมือกับโปรเจกต์โค้ดของฝั่งนี้มีชื่อว่า Claude Code ซึ่งทำงานกับไฟล์และเครื่องมือพัฒนาได้ด้วย ในบทสนทนาแอดจึงเริ่มจากอยากให้ช่วยวิเคราะห์ความต้องการ วางแผนงาน และช่วยทำ MVP หรือ Minimum Viable Product ซึ่งเป็นผลิตภัณฑ์รุ่นแรกที่มีส่วนจำเป็นพอให้เริ่มลองใช้งานได้
งานวางแผนที่อยากให้ Claude ช่วย คือทำให้โจทย์ที่ยังพูดกว้างๆ กลายเป็นงานที่คนอื่นรับไปทำต่อได้ เช่น จากคำว่าอยากให้ล็อกอินด้วย Google ก็ช่วยไล่สถานการณ์ของผู้ใช้ แยกงาน และระบุว่าเสร็จแล้วต้องดูอะไรถึงจะบอกได้ว่าทำตรงความต้องการ ส่วนงาน MVP ก็จะเริ่มจากเส้นทางหลักที่ทำให้เห็นว่าของรุ่นแรกใช้ตอบโจทย์ได้ไหม จึงยังไม่จำเป็นต้องมีรายละเอียดทุกอย่างของผลิตภัณฑ์ระยะยาว
แต่พอมองเป็นทีมที่ต้องรันงานต่อกันจริงๆ แอดต้องแยกคำว่า PM หรือ Project Manager ซึ่งเป็นผู้จัดการโครงการ ออกจากตัวที่ช่วยคิดแผนให้ชัดขึ้น PM ของระบบคือตัว orchestrator หรือส่วนควบคุมการทำงาน ที่คอยแจกงาน คอยปลุกแต่ละคนให้ลุกมาทำงานตอนหลับ รับรู้ว่าใครทำเสร็จ แล้วส่งงานไปให้คนตรวจหรือส่งกลับไปแก้ตามลำดับ
Claude จึงเป็นผู้ช่วยคิดและเตรียมรายละเอียดให้ทีม ส่วนการทำให้แผนนั้นเดินจริงต้องมี orchestrator รับผิดชอบ คำว่าปลุกในที่นี้คือเมื่อถึงคิวของ agent ตัวไหน ต้องมีตัวเรียกให้เริ่มทำงานพร้อมข้อมูลที่ต้องใช้ ไม่ใช่รอให้แอดเปิดแชทแล้วพิมพ์บอกเองทุกครั้ง บทบาทนี้จะค่อยๆ เห็นชัดขึ้นตอนคุยเรื่องการส่งต่องานระหว่างตัว
เหตุผลที่แอดอยากให้ Claude อยู่ฝั่งนี้ คือก่อนส่งงานให้ตัวลงมือ เราต้องมีคนช่วยคุยให้รู้ก่อนว่ากำลังแก้ปัญหาอะไร และอะไรยังไม่ชัด ถ้ารับประโยคกว้างๆ ไปเขียนเลย ต่อให้ทำได้เร็วก็อาจต้องกลับมารื้อใหม่ เพราะแต่ละตัวเข้าใจคำว่าเสร็จไม่เหมือนกัน แอดจึงอยากให้ช่วยไล่คำถามและเรียบเรียงสิ่งที่ตกลงกันไว้ ให้ dev กับคนตรวจอ่านแล้วเริ่มจากความเข้าใจชุดเดียวกันได้
ที่คิดให้ Claude ช่วยสองส่วนนี้ในตอนแรกเป็นการจัดงานจากเครื่องมือที่มีอยู่ก่อน ยังไม่ได้ทดลองเปรียบเทียบว่าใครเหมาะกับทุกงานมากที่สุด และถ้าแบ่งหน้าที่แล้วก็คงต้องระวังไม่ให้คนวางแผนลงไปทำงานซ้ำกับ dev โดยไม่รู้ตัวด้วย
Cursor เป็นโปรแกรมสำหรับเขียนโค้ดที่มี AI ช่วยทำงานอยู่ในตัว คนที่เพิ่งเข้ามาในสาย dev อาจนึกถึงหน้าจอที่เปิดแฟ้มของโปรเจกต์ไว้ด้านหนึ่ง เปิดไฟล์โค้ดตรงกลาง และคุยกับ AI เพื่อให้ช่วยอธิบายหรือแก้ส่วนที่เกี่ยวข้องได้ อีกทางใช้งานหนึ่งคือผ่าน CLI หรือ Command-Line Interface เป็นช่องทางสั่งงานด้วยข้อความผ่าน terminal ซึ่งเป็นหน้าต่างพิมพ์คำสั่งของเครื่อง
ในภาพทีมที่คุยกัน แอดอยากให้ Cursor รับหน้าที่ dev หลัก คือรับงานที่แตกไว้แล้วไปลงมือ เช่น เพิ่มปุ่ม เขียนส่วนเชื่อมข้อมูล และเตรียมการทดสอบเบื้องต้น จากนั้นส่งงานที่เปลี่ยนไปให้คนอื่นตรวจต่อ ถ้าเทียบเป็นทีมคน ก็คล้ายให้เป็น junior หรือนักพัฒนาระดับเริ่มต้นที่รับโจทย์ชัดๆ ไปทำ แล้วมีอีกคนช่วยตรวจ หน้าที่นี้จึงควรมีขอบเขตชัดว่ากำลังแก้โจทย์อะไร ไม่ใช่เปิดให้คิดและทำทุกเรื่องในโปรเจกต์พร้อมกัน
เหตุผลที่อยากให้รับงานลงมือเยอะหน่อย ก็คือแอดมองว่าปริมาณงานที่ให้มันช่วยทำได้คุ้มกับงบค่าสมาชิก $30 ต่อเดือนที่ตั้งไว้ ถ้าจะแบ่งหน้าที่กันจริงๆ แอดก็อยากให้ตัวที่มีต้นทุนพอรับได้ช่วยเดินงานส่วนใหญ่ แล้วค่อยส่งจุดที่ต้องตรวจละเอียดไปให้อีกตัวช่วยดู มากกว่าจะใช้ตัวค่าตัวสูงกับทุกขั้นตั้งแต่เริ่ม
ถ้าดู แพ็กเกจ Cursor ปัจจุบัน ณ วันที่ 7 พฤศจิกายน 2026 ตัว $30 ต่อเดือนใช้ชื่อ Premium แต่ยังมี Plus $8 ที่ให้ใช้เฉพาะโมเดล Grok อยู่ด้วย จึงไม่ใช่แพ็กเกจเสียเงินที่ต่ำที่สุดทั้งหมด และการเลือกโมเดลจากผู้ให้บริการรายอื่นใน Premium ก็มีค่าใช้งานแยกต่างหาก งบ $30 ที่แอดพูดถึงเลยเป็นจุดเริ่มสำหรับเลือกวิธีทำงาน ไม่ใช่เหมารวมว่าจะใช้โมเดลไหนเท่าไรก็ได้ในราคานี้
อีกอย่างที่สนใจคือ Cursor ใช้โควตารายสัปดาห์ ต่างจากรอบการใช้งาน 5 ชั่วโมงที่พบใน Claude บางแพ็กเกจ และ Codex บน Plus หรือ Standard Business แอดอยากลดจังหวะที่ทีมต้องหยุดรอระหว่างวัน แต่ก็ยังต้องดูปริมาณงานที่โควตาจริงรองรับด้วย เพราะตอนนี้ Codex บน Pro ไม่มีเพดานรอบ 5 ชั่วโมงแล้ว และ Claude บางกรณีก็ยกเว้นรอบนี้เช่นกัน จุดที่ต้องกลับไปดูจึงเป็นโควตาและรอบการใช้งานของแพ็กเกจที่เราจะใช้จริง
Codex เป็น coding agent หรือผู้ช่วย AI สำหรับลงมือทำงานกับโค้ดของ OpenAI ที่ช่วยอ่านและแก้โค้ด รวมถึงเรียกเครื่องมือในสภาพแวดล้อมที่อนุญาตได้ มีหลายช่องทางใช้งาน โดยช่องทางที่คุยถึงการนำมารันต่อกันในทีมคือ CLI แอดเริ่มวางไว้ฝั่ง senior dev หรือนักพัฒนาระดับอาวุโส ให้เป็น reviewer หรือคนตรวจงาน และช่วยเรื่องทดสอบอัตโนมัติ เพราะอยากให้มีการกลับมามองงานแยกจากตัวที่เป็นคนเขียน
อีกเหตุผลหนึ่งก็เรื่องค่าตัวครับ ในบรรดาค่าสมาชิกเครื่องมือ AI ที่แอดจ่ายอยู่ Codex แพงเป็นอันดับสอง ก็เลยจับมารับหน้าที่ senior ให้ช่วยเช็คงานรุ่น junior หน่อย อยากให้ดูทั้งว่าโค้ดทำตรงกับสิ่งที่ตกลงกันไหม และมีส่วนไหนที่คนลงมืออาจมองข้าม ก่อนส่งต่อให้ทดสอบตามสถานการณ์ใช้งาน
คำว่า senior ในที่นี้จึงหมายถึงหน้าที่ช่วยตรวจแนวทางและสิ่งที่อาจตกหล่น ส่วน QA หรือ Quality Assurance คือหน้าที่ดูแลให้กระบวนการและผลงานมีคุณภาพตามที่ตกลงกัน เช่น ลองตามสถานการณ์ผู้ใช้และดูผลที่เกิดขึ้น ไม่ได้หมายความว่าแค่ตั้งชื่อ agent ว่า senior หรือ QA แล้วมันจะมีประสบการณ์หรือรับรองความถูกต้องให้เราได้เอง
ภาพนี้ช่วยให้เห็นหน้าตาของ CLI ที่พูดถึงครับ ผู้ใช้พิมพ์โจทย์ลงในหน้าต่างคำสั่ง แล้วตัว agent แสดงสิ่งที่จะทำกับโปรเจกต์ต่อไป เช่น ในตัวอย่างเป็นการขอให้อธิบายโครงสร้างโค้ด จึงมีแผนว่าจะสำรวจส่วนไหนบ้าง ภาพและรุ่นที่ปรากฏเป็นตัวอย่างของต้นทาง ไม่ใช่รุ่นที่แอดเลือกใช้หรือผลทดสอบของทีมเรา
พอวางแบบนี้ สิ่งที่ต้องคุยต่อจึงเป็นวิธีส่งงานระหว่างตำแหน่ง ถ้า dev ทำเสร็จ reviewer ควรได้เห็นอะไร และถ้า QA พบปัญหาจะส่งกลับไปให้ใครแก้ ไม่อย่างนั้นต่อให้เลือกเครื่องมือได้ครบ เราก็ยังต้องเป็นคนเดินงานแทนทีมอยู่เหมือนเดิม
Tech Lead (GPT): ให้ Cursor ลงมือทำงานส่วนใหญ่ แล้วให้ Codex ตรวจและทดสอบแยกจากตัวที่เขียน ส่วน Claude ช่วยทำโจทย์กับแผนให้ชัด เรื่องเปลี่ยนขอบเขตงานหรือการยอมรับผลสุดท้ายยังต้องกลับมาหา PO
เมื่อเริ่มมีหลายหน้าที่ อีกสิ่งที่ตามมาคือจะเก็บงานทั้งหมดไว้ตรงไหน เพราะ requirement หรือความต้องการของงานหนึ่งชิ้นมักไม่ได้จบในประโยคแรกที่คุยกัน บางเรื่องต้องถามเพิ่ม บางเรื่องยังไม่ทำทันที และบางเรื่องต้องรออีกส่วนให้พร้อมก่อน
ก่อนให้ใครหยิบงานไปทำ เราจึงต้องมีรายการสิ่งที่อยากทำหรือจำเป็นต้องทำเก็บไว้ด้วยกันก่อน รายการนี้เรียกว่า backlog ครับ โดยแต่ละเรื่องยังต้องจัดลำดับความสำคัญและดูความพร้อม ไม่ใช่ว่าพอจดไว้แล้วทุกคนจะเริ่มทำพร้อมกันได้ทันที โปรแกรมจัดการงานจึงเข้ามาช่วยเก็บรายละเอียดและทำให้ทีมมองรายการเดียวกันนี้ได้
โปรแกรมกลุ่มนี้ช่วยให้หนึ่งงานมีพื้นที่ของตัวเอง ใส่คำอธิบาย แนบภาพ ระบุผู้รับผิดชอบ และดูสถานะได้ เช่น รอทำ กำลังทำ หรือรอตรวจ บางทีมชอบดูเป็นรายการ บางทีมชอบดูเป็นบอร์ดที่แบ่งคอลัมน์ คล้ายเอากระดาษงานแต่ละใบมาวางตามขั้นตอน เพื่อกวาดตาดูได้ว่างานกองอยู่ตรงไหน
ถ้ากลับไปที่ตัวอย่างล็อกอิน งานชิ้นหนึ่งอาจเป็นคำขอเพิ่มฟีเจอร์ ส่วนอีกชิ้นอาจเป็น defect หรือข้อบกพร่องของระบบ เช่น พบว่ากดยกเลิกแล้วกลับหน้าจอไม่ถูก การเก็บแยกเป็นรายการทำให้คุยต่อได้ว่าอันไหนเป็นสิ่งที่ตั้งใจเพิ่ม และอันไหนเป็นพฤติกรรมที่ต้องกลับไปแก้ โดยไม่ต้องไล่หาว่าข้อความนั้นอยู่ส่วนไหนของแชท
แอดมี Plane ใช้จัดการงานอยู่แล้ว ซึ่งเป็นโปรแกรมในกลุ่มนี้ เลยคิดว่าถ้าจะให้ทีม AI รับงาน ก็น่าจะลองดูว่าต่อจากที่เก็บ backlog เดิมได้ไหม จะได้ไม่ต้องมีที่จดอีกแห่งหนึ่งแล้วคอยย้ายรายละเอียดตามกันเอง
PO: ฉันสามารถใช้ Plane เป็นตัวกลางได้ไหม
Tech Lead (GPT): ใช้ Plane เก็บความต้องการ รายการงาน สถานะ และผลตรวจได้ แต่ยังต้องมี orchestrator คอยอ่านงาน เรียก agent และส่งต่อกัน การมีบอร์ดอย่างเดียวไม่ได้ทำให้ทั้งทีมลุกขึ้นมาทำงานเอง
ลองดูคอลัมน์ในภาพครับ Planned คือกลุ่มงานที่วางแผนไว้ In Progress คือกำลังทำ In Review คืออยู่ระหว่างตรวจ และ Done คือเสร็จแล้ว ภายในการ์ดมีชื่อเรื่องกับข้อมูลประกอบ เช่น หมวด ผู้รับผิดชอบ หรือวันที่ เราจึงดูภาพรวมได้โดยไม่ต้องเปิดรายละเอียดทุกงานก่อน ส่วนจะใช้ชื่อสถานะแบบไหนก็ต้องจัดให้ตรงกับวิธีทำงานของทีม ภาพนี้เป็นบอร์ดตัวอย่างของ Plane ไม่ใช่ข้อมูลโปรเจกต์ของแอด
ในภาพที่คุยกัน PO เปิดงานไว้บนบอร์ด จากนั้นคนวางแผนช่วยทำรายละเอียดให้ชัด คนลงมือรับงานไปทำ แล้วกลับมาแนบผลหรือเปลี่ยนสถานะให้เห็นว่าถึงขั้นไหนแล้ว เวลาที่เราเข้ามาเช็กก็อยากเริ่มดูจากภาพเดียวกันนี้ได้ ว่างานไหนกำลังเดิน งานไหนรอคำตอบ และงานไหนมีหลักฐานพร้อมให้ตรวจ
แต่การมองเห็นงานบนบอร์ดกับการทำให้งานเดินต่ออัตโนมัติยังมีรายละเอียดระหว่างทาง ถ้าเราเลื่อนการ์ดไปคอลัมน์พร้อมทำ ใครจะเป็นคนเรียก agent ให้เริ่ม และถ้า agent หยุดกลางทาง สถานะบนบอร์ดจะรู้ได้จากอะไร ในแผนนี้แอดอยากให้ Plane รับหน้าที่เก็บ backlog กับแสดงความคืบหน้า ส่วนวิธีคุมการรันงานต้องคุยให้ชัดอีกชั้น
คำถามแรกจึงยังไม่ได้พาไปถึงการเลือกส่วนเชื่อมทั้งหมดทันที แต่ช่วยให้เห็นว่าบอร์ดควรมีไว้ตอบคำถามของคนดูแลงานก่อน ส่วนเบื้องหลังที่จะส่งต่องานให้ AI ทำต่อกันได้ เราต้องรู้ว่าใครรับผิดชอบอยู่
ลองอยู่กับงานล็อกอินชิ้นเดิมต่ออีกหน่อยครับ สมมติคนวางแผนแตกงานเสร็จแล้ว แต่ยังไม่มีใครเริ่มเขียน การมีเอกสารครบไม่ได้ทำให้ dev รับงานไปเอง ถัดมาแม้ dev บอกว่าทำเสร็จ ก็ยังต้องมีใครสักคนส่งให้ reviewer และถ้าตรวจแล้วขอแก้ ก็ต้องส่งกลับไปยังงานเดิมพร้อมข้อที่พบ
ในทีมคน เราพอจะคุยกันและตามความเคลื่อนไหวผ่านวิธีทำงานของทีมได้ แต่ถ้าอยากให้ agent ช่วยกันทำงานต่อโดยที่เราไม่ต้องเฝ้า ทุกครั้งที่ส่งต่อจำเป็นต้องมีทางให้ตัวถัดไปรู้ว่าถึงคิวตัวเองแล้ว พร้อมข้อมูลที่ใช้ทำงานต่อได้
ตรงนี้เองที่ orchestrator ต้องรับบท PM ของระบบตามที่คุยไว้ มันไม่ได้มีหน้าที่เพียงช่วยเขียนแผน แต่ต้องจัดคิว แจกงาน และเรียกคนที่ถึงคิวให้เริ่มทำ มันต้องรู้ว่างานนี้อยู่ขั้นไหน ใครรับผิดชอบอยู่ และเงื่อนไขอะไรทำให้ไปขั้นถัดไปหรือส่งกลับไปแก้ คำนี้จึงไม่ได้หมายถึงโมเดล AI ที่ฉลาดกว่าอีกทุกตัวเสมอไป บางส่วนอาจเป็นโปรแกรมที่ทำตามกติกาตรงๆ ก็ได้
พอคุยถึงหลักฐานการส่งงาน เราก็ต้องมองที่โค้ดฉบับที่กำลังตรวจด้วย ในงานพัฒนามักใช้ Git เก็บประวัติการเปลี่ยนแปลง โดย commit เป็นจุดบันทึกหนึ่งชุด ส่วน branch ช่วยแยกแนวทางที่กำลังแก้ และ pull request หรือ PR เป็นคำขอเอาชุดการเปลี่ยนแปลงนั้นมารวมกับงานหลัก จึงเป็นจุดที่ทีมเข้ามาดูและให้ความเห็นก่อนรวมงานได้
ถ้า dev บอกว่าทำเสร็จ reviewer ก็ควรรู้ว่ากำลังตรวจโค้ดจาก commit ไหน และเทียบกับความต้องการข้อไหน สมมติตรวจพบว่ากดยกเลิกล็อกอินแล้วค้างหน้ารอ ผลตรวจควรกลับไปถึงคนทำพร้อมรายละเอียดนี้ ไม่ใช่ให้ PO ไปอ่านแล้วพิมพ์เล่าปัญหาให้ dev อีกรอบ
diff ในที่นี้คือส่วนต่างของโค้ดที่ถูกแก้ ทำให้คนตรวจเห็นว่าเพิ่ม ลบ หรือเปลี่ยนอะไร ส่วนการทดสอบต้องมีผลจากการรันจริงประกอบ เช่น ลองเส้นทางยกเลิกแล้วเกิดหน้าจออะไรขึ้น จะได้แยกระหว่างความตั้งใจในคำอธิบายกับสิ่งที่โปรแกรมทำออกมาจริง
Tech Lead (GPT): ให้ reviewer อ่าน requirement กับ diff จริง และให้ QA ดูผลจากเครื่องมือทดสอบ อย่าตรวจจากคำสรุปของ dev อย่างเดียวว่าทำเสร็จแล้ว
พอรู้ว่าต้องมีตัวคุมงานอีกชั้น แอดก็ถามต่อว่าคนอื่นใช้เครื่องมืออะไรกัน หรือว่าต้องเขียน orchestrator เองทั้งหมด เพราะถ้ามีของที่ช่วยจัดวงจรลงมือ ตรวจ และส่งแก้อยู่แล้ว ก็น่าจะเริ่มจากดูตรงนั้นก่อน
PO: คนอื่นๆ เขาใช้เครื่องมืออะไรกัน หรือสร้างตัวจัดทีมเองกันหมด
Tech Lead (GPT): ไม่จำเป็นต้องสร้างใหม่ทั้งหมด ลองแยกของที่ใช้เก็บงาน ออกจากตัวที่คุมลำดับการทำงาน และตัวที่จัดการ coding agent ก่อน บางโปรแกรมช่วยส่งงานตรวจและวนกลับไปแก้ได้ ส่วนบางตัวช่วยแค่เปิด agent หลายตัวให้คนคอยดูเอง
ถ้าเครื่องมือเดียวทำทั้งงาน review กับ QA แอดก็ยังอยากแยกงานและบริบทให้ชัด ตัวที่เขียนไม่ควรเพียงส่งคำสรุปสวยๆ แล้วให้ตัวตรวจรับรองตามนั้น เพราะอาจเข้าใจผิดตั้งแต่ requirement เหมือนกันทั้งคู่ การกลับไปดูงานต้นทางและหลักฐานของโค้ดฉบับจริงจึงเป็นเรื่องที่ต้องเตรียมไว้ในวิธีทำงาน
ส่วนการจัดคิวก็ไม่จำเป็นต้องส่งให้ AI คิดทุกเหตุการณ์ เช่น ถ้าชุดทดสอบรันไม่ผ่าน ผลจากเครื่องมือก็ควรพางานกลับไปตรวจได้ตามกติกาที่ตกลงกัน การทำให้ทุกตัวคุยกันตลอดอาจใช้ทั้งเวลาและโควตาเพิ่ม โดยยังไม่ได้ช่วยให้งานเดินเร็วขึ้น ตรงนี้เริ่มเชื่อมกลับไปถึงโจทย์ต้นทุนที่แอดสนใจตั้งแต่แรก
แอดอยากเริ่มจากสิ่งที่สมัครใช้อยู่แล้วก่อนครับ เพราะถ้าจะลองวิธีทำงานแบบทีม ก็น่าจะดูให้รู้ก่อนว่าของที่จ่ายอยู่ช่วยทำได้ถึงไหน ยังไม่อยากเปิดค่าใช้งานอีกระบบหนึ่งเพื่อให้เริ่มลองได้ ทั้งที่ยังไม่รู้ว่างานจะเดินต่อกันได้ดีแค่ไหน
พอคิดว่าต้องมีหลายหน้าที่ ก็เลยถามแทรกขึ้นมาว่าตำแหน่ง dev จะสลับไปใช้ตัวอื่นที่เหมาะกับงานและประหยัดกว่าได้ไหม เช่น งานเล็กที่รายละเอียดชัดอาจไม่ต้องใช้ตัวเลือกเดียวกับงานที่ต้องไล่หลายส่วนของระบบ แต่ก่อนจะเลือกจากราคา เราต้องแยกให้ได้ก่อนว่ากำลังเปลี่ยนอะไร
อย่าง reviewer เป็นหน้าที่ที่ต้องการให้ทำ ส่วน Claude Code หรือ Codex CLI เป็น runtime หรือโปรแกรมที่ใช้รัน agent และโมเดลเป็นตัวที่เครื่องมือนั้นเลือกเรียกภายใต้ตัวเลือกกับสิทธิ์ที่รองรับอีกที ถ้าผูกหน้าที่เข้ากับชื่อผลิตภัณฑ์ตายตัว วันไหนอยากเปลี่ยนผู้ช่วย ก็อาจต้องไล่เปลี่ยนวิธีส่งงานไปด้วย
สิ่งที่น่าจะช่วยให้เปลี่ยนได้ง่ายขึ้นคือทำให้ผู้รับช่วงรู้ว่าโจทย์คืออะไร ทำไปถึงไหน และมีหลักฐานอะไรเหลืออยู่ เช่น โค้ดฉบับล่าสุด ผลตรวจที่ยังต้องแก้ และสิ่งที่รอคำตอบจาก PO ส่วนความสามารถในการรับช่วงจริงก็ต้องดูว่าเครื่องมือแต่ละตัวรับข้อมูลและใช้เครื่องมือร่วมกันได้แค่ไหนด้วย
อีกคำที่ต้องแยกคือ subscription ซึ่งหมายถึงแผนสมาชิกที่เราสมัครใช้บริการอยู่ ส่วน API หรือ Application Programming Interface เป็นช่องทางให้โปรแกรมเรียกใช้ความสามารถของอีกโปรแกรมหนึ่งได้ และ self-hosted หมายถึงเอาบางส่วนมาติดตั้ง รัน และดูแลบนเครื่องของเราเอง แต่ละอย่างมีสิทธิ์กับต้นทุนที่ต้องดูแยกกัน การมีแพ็กเกจสำหรับเข้าไปคุยกับ AI จึงยังไม่ใช่คำตอบว่าตัว orchestrator ที่เลือกจะเรียกใช้งานได้แบบไหน ต้องตรวจให้ตรงกับบัญชีและช่องทางที่เราจะใช้จริง
PO: อย่าลืมเรื่องต้นทุนกับ self-hosted นะ subscription ที่มีอยู่ก็ยังไม่แน่ใจว่ารองรับ CLI หรือ API แบบไหนบ้าง
เอกสารของ Claude Code มีช่องทางลงชื่อเข้าใช้ด้วยบัญชี subscription ที่รองรับ ส่วน Codex แยกการใช้สิทธิ์ผ่าน ChatGPT ออกจากการเข้าใช้ด้วย API key หรือรหัสยืนยันสิทธิ์สำหรับเรียก API ซึ่งคิดค่าใช้งานแยกตาม API ขณะที่ Cursor CLI มีทั้งการลงชื่อเข้าใช้ผ่าน browser หรือโปรแกรมเปิดเว็บ และ key ซึ่งเป็นรหัสสำหรับยืนยันตัวตนของ Cursor เอง ชื่อเรียกที่คล้ายกันเหล่านี้จึงต้องตามอ่านทีละเจ้า ไม่ใช้คำว่า key มาสรุปสิทธิ์รวมกัน
อีกเรื่องคือโควตา ถ้าบัญชีที่ใช้ติดข้อจำกัดขึ้นมา แอดอยากให้ระบบรู้ว่าจะรอ หยุด หรือส่งงานไปยังตัวอื่นที่ได้รับอนุญาตไว้แล้ว โดยไม่เปิดการเรียก API แบบเสียเงินตามการใช้งานเพิ่มเอง เพราะความสะดวกที่ทำให้งานไม่หยุดอาจกลายเป็นค่าใช้จ่ายที่เราไม่ได้ตั้งใจรับ ถ้าจะเพิ่มทางเลือกเสียเงินก็ควรรู้และตัดสินใจก่อน
ส่วน self-hosted หมายถึงเอาบางส่วนมารันและดูแลบนเครื่องของเราเอง เช่น เอาตัวจัดทีมกับ CLI ไปวางบน server หรือเครื่องที่เตรียมไว้รันงานและให้บริการ เพื่อให้ทำงานได้แม้ปิดคอมพิวเตอร์ส่วนตัว แต่ถ้ายังเรียกโมเดลผ่านผู้ให้บริการ การประมวลผลของโมเดลก็ยังอยู่กับบริการนั้น ไม่ได้ย้ายเข้ามาอยู่บน server ของเราไปด้วย
เมื่อแอดย้ำว่าอยากรันส่วนควบคุมเอง และใช้ค่าสมาชิกเดิมให้คุ้ม GPT ก็เริ่มให้น้ำหนักกับ Agent Orchestrator ซึ่งในคำตอบใช้ชื่อย่อว่า AO เป็นตัวจัดการงานของ coding agent แล้วค่อยทำส่วนเชื่อมกับบอร์ดและการดูโควตาเพิ่ม
Tech Lead (GPT): สำหรับโจทย์นี้ ผมจะเริ่มดู AO เป็นตัวคุม coding agent ใช้ Plane เก็บงานเหมือนเดิม แล้วเสริมเฉพาะส่วนเชื่อม กติกาการรับงาน และการติดตามโควตา ไม่เริ่มจากเขียน orchestrator ใหม่ทั้งตัว
ตอนนั้นชื่อ AO จึงเข้ามาเป็นตัวเลือกที่แอดต้องจำไว้ก่อนครับ ยังไม่ได้หมายความว่าเลือกใช้แล้ว หรือยืนยันว่าเชื่อมกับบัญชีที่มีได้ครบทุกตัว แต่เป็นคำแนะนำแรกๆ ที่ทำให้เริ่มเห็นว่าบางส่วนอาจมีคนทำไว้ให้แล้ว
การมีเครื่องอยู่แล้วอาจช่วยให้เริ่มได้สะดวกขึ้น แต่ก็ยังต้องนับพื้นที่เก็บงาน เวลาอัปเดต และเวลาจัดการตอนมีปัญหาเข้าไปด้วย ยิ่งอยากให้ทำงานโดยไม่ต้องเฝ้า ก็ยิ่งอยากรู้ว่าเวลาอะไรหลุดไปแล้วเราจะต้องกลับมาทำเองมากน้อยแค่ไหน
สุดท้ายเรื่องต้นทุนเลยกว้างกว่าค่าเรียกโมเดลหนึ่งครั้ง ถ้าเลือกตัวที่ดูประหยัดแต่ต้องส่งแก้ซ้ำมาก หรือคนต้องกลับมาไล่บริบทใหม่อยู่เรื่อยๆ ก็อาจยังไม่ตรงกับสิ่งที่อยากได้ Day 1 นี้แอดจึงยังไม่ได้คำนวณว่าประหยัดกี่บาท แต่เริ่มมีคำถามที่ต้องใช้ดูของในตลาดชัดขึ้นว่า เงินที่จ่ายกับแรงที่ต้องลงเพิ่มมันสัมพันธ์กันยังไง
พอเริ่มเห็นภาพของทีมหนึ่งทีม แอดก็คิดต่อถึง dev คนอื่นๆ ที่ดูแลงานคนละส่วนอยู่แล้ว ถ้าแต่ละคนมีตัวช่วยรับงานในส่วนที่ตัวเองรับผิดชอบได้ด้วย ก็น่าจะลองขยับวิธีทำงานให้แต่ละคนคอยกำหนดเป้าหมายกับดูภาพของโมดูลหรือส่วนการทำงานของระบบที่ตัวเองดูแลมากขึ้นได้
squad ที่พูดถึงตรงนี้คือทีมย่อยที่ดูแลงานในขอบเขตหนึ่ง เช่น ส่วนบัญชีผู้ใช้ ส่วนข้อมูลการสั่งซื้อ หรือแอปมือถือ ภาพที่อยากลองคือมีคนเป็นเจ้าของขอบเขตนั้น แล้วมี agent ช่วยทำหน้าที่ต่างๆ ภายใต้ทีม ไม่ใช่ทุกคนต้องเปลี่ยนชื่อตำแหน่งทันที หรือเลิกเข้าไปดูโค้ดตั้งแต่วันแรก
PO: ถ้าอยากให้แต่ละคนเป็น PO ของ squad แล้วใช้ agent เป็นทีมย่อยรันงานในโมดูลที่รับผิดชอบ จะเข้ามาร่วมงาน แล้วมีทีมของตัวเองได้เลยไหม
Tech Lead (GPT): ทำเป็นภาพระบบที่แต่ละคนมีทีมของตัวเองได้ แต่ Plane กับ AO ไม่ได้แปลว่ามีทุกส่วนนี้พร้อมทันที ต้องแยกเจ้าของทีม ขอบเขตโค้ด สิทธิ์ และโควตา ส่วนตัวที่จัดคิวก็ค่อยเรียก agent ที่มีงานพร้อมให้ทำ
สำหรับแอด ความสนใจอยู่ที่ว่าถ้าเราขยับจากคนที่ต้องลงมือเกือบทุกช่วง ไปเป็นคนที่ช่วยให้ทีมเข้าใจเป้าหมายและตัดสินใจได้ งานของเราจะมีหน้าตายังไง เวลาเดิมที่เคยใช้เขียนบางส่วน อาจเปลี่ยนไปใช้กับการดูว่าข้อเสนอของทีมตอบโจทย์ไหม หรือยอมรับสิ่งที่ต้องแลกจากทางเลือกนั้นได้หรือเปล่า
อย่างในตัวอย่างล็อกอิน AI อาจเสนอให้ทำเส้นทางที่เขียนง่ายก่อน แต่ PO ยังต้องดูว่าผู้ใช้กลุ่มที่สำคัญได้รับผลกระทบไหม หรืองานที่ขอเพิ่มระหว่างทางควรเข้ามาในรอบนี้เลยหรือรอไว้ก่อน ความรู้เรื่องงานจึงยังต้องอยู่กับคนที่รับผิดชอบ เพียงเราอยากมีทีมช่วยหาข้อมูล ลงมือ และตรวจสิ่งที่ตกลงไว้ให้มากขึ้น
เมื่อคิดไปถึงหลายทีม ก็มีเรื่องที่ต้องแยกกันเพิ่ม เช่น แต่ละทีมดู repository หรือที่เก็บโค้ดไหน ใช้เครื่องทดสอบร่วมกันยังไง และโควตาที่ใช้เป็นของบัญชีไหน หากเราตั้งชื่อทีมแยกบนหน้าจอ แต่เบื้องหลังทุกตัวใช้พื้นที่และสิทธิ์ปนกัน ก็ยังตอบไม่ได้ว่าจะทำงานพร้อมกันโดยไม่ชนกันได้แค่ไหน
คำตอบของ AI จึงเริ่มพาไปทางระบบสมาชิก การแยกพื้นที่ทำงาน และการจัดสรรทรัพยากร ซึ่งเป็นเรื่องที่มีเหตุผลเมื่ออยากให้คนอื่นเข้ามาใช้ด้วย แต่ก็ทำให้โจทย์เริ่มใหญ่กว่าการจัดทีมให้ตัวเองใช้อยู่พอสมควร ก่อนคุยต่อเรื่องระบบใหญ่ แอดจึงต้องกลับมาทวนอีกส่วนหนึ่งที่ดูเหมือนตกลงกันแล้ว คือบอร์ดงานควรอยู่ตรงไหนของภาพทั้งหมด
ตอนเริ่มถามเรื่อง Plane แอดสนใจว่าต่อจากที่เก็บงานเดิมได้ไหม แต่พอ AI ขยายสถาปัตยกรรมไปเรื่อยๆ เริ่มมีหลายอย่างอาศัยบอร์ดเป็นจุดศูนย์กลาง จึงอยากแก้ความเข้าใจตรงนี้ก่อน เพราะการเลือกโปรแกรมจัด backlog วันนี้ยังไม่ควรกลายเป็นข้อผูกมัดว่าทุกส่วนต้องใช้วิธีคิดของโปรแกรมนั้นตลอดไป
PO: Plane กะว่าจะเป็นแค่บอร์ดไว้ทำ backlog และ defect อาจมีบอร์ดให้ลูกค้าเห็นงานแบบไม่ละเอียดเท่าทีมภายในด้วย แล้วภายหลังอยากเปลี่ยนไปใช้บอร์ดอื่นได้
Tech Lead (GPT): ถ้าอย่างนั้นให้ Plane เป็นบอร์ดที่เลือกต่อเข้ามา ส่วนสถานะการรันงานกับประวัติของ agent เก็บอยู่ฝั่ง orchestrator จะเปลี่ยนบอร์ดทีหลังก็ค่อยเปลี่ยนส่วนเชื่อม ไม่ให้ทุกขั้นของทีมต้องรู้จัก Plane โดยตรง
เหตุผลของมุมลูกค้าก็เป็นเรื่องของรายละเอียดที่ต้องใช้ครับ คนที่กำลังพัฒนาจำเป็นต้องรู้ว่างานถูกแยกไปแก้ตรงไหน มีผลทดสอบอะไร และติดปัญหาเชิงเทคนิคอะไรอยู่ แต่ลูกค้าอาจอยากรู้เพียงฟีเจอร์ที่คุยกันไว้กำลังทำ อยู่ระหว่างตรวจ หรือมีอะไรที่ต้องตอบกลับ พร้อมมีที่แจ้งปัญหาที่พบจากการใช้งาน
ถ้าลูกค้าแจ้งว่าล็อกอินไม่ได้ เราก็อยากเก็บคำอธิบายของเขาไว้แล้วเชื่อมกลับมาที่งานของทีมได้ โดยทีมอาจแตกไปตรวจหลายชิ้นก่อนกลับมาสรุปเป็นคำตอบเดียวที่เข้าใจได้ ไม่จำเป็นต้องเอาคอมเมนต์ทางเทคนิคทุกช่วงที่ agent คุยกันไปวางในมุมของลูกค้าทั้งหมด
เมื่อวางหน้าที่แบบนี้ บอร์ดจึงเป็นช่องทางรับและแสดงข้อมูลของงาน ส่วนประวัติว่า agent ทำอะไรถึงขั้นไหนควรมีทางเก็บให้ทำงานต่อได้ด้วย และหากวันหนึ่งเปลี่ยนโปรแกรมจัด backlog เราคงไม่อยากต้องทิ้งงานที่กำลังรันอยู่แล้วเริ่มเล่าทุกอย่างให้ agent ฟังใหม่
แนวทางที่คุยกันเลยขยับไปทางมีส่วนเชื่อมระหว่างข้อมูลของระบบรันงานกับบอร์ดที่เลือกใช้ เช่น รู้ว่างานภายในชิ้นนี้สัมพันธ์กับรายการไหนบน Plane แล้วค่อยส่งสถานะหรือคำตอบที่เกี่ยวข้องกลับไป คำว่า adapter ที่ AI ใช้ก็คือส่วนเชื่อมที่แปลงวิธีคุยของสองฝั่งให้เข้าหากันนั่นเอง
ตรงนี้ยังเป็นสิ่งที่อยากเตรียมทางไว้ ไม่ได้หมายความว่าเปลี่ยนบอร์ดแล้วจะย้ายข้อมูลได้เองทั้งหมด เพราะแต่ละโปรแกรมมีสถานะ ช่องข้อมูล และวิธีแบ่งสิทธิ์ต่างกัน อย่างน้อยการแยกหน้าที่ไว้ก่อนก็น่าจะช่วยให้เห็นว่าถ้าจะเปลี่ยน ต้องกลับมาจัดการตรงไหนบ้าง
จากคำถามเล็กๆ ว่าใช้บอร์ดเดิมเป็นตัวกลางได้ไหม จึงเริ่มเห็นภาพที่กว้างขึ้นว่า สิ่งที่อยากทำอาจเป็นที่จัดการทีม AI ซึ่งค่อยเลือกต่อเครื่องมือที่เราคุ้นเคยเข้าไปได้ แล้วแอดก็ลองทวนภาพนี้กับ AI อีกครั้ง
แอดเริ่มคิดว่าถ้าทำให้คนอื่นติดตั้งเองได้ ก็น่าจะมีทางให้เขาเริ่มจากพื้นที่ของทีมตัวเอง แล้วเลือกต่อเครื่องมือที่ใช้จริงเข้าไป เช่น ใครมีบอร์ดงานอยู่แล้วก็เชื่อมบอร์ดนั้น ใครใช้ที่เก็บโค้ดอีกเจ้าก็เลือกส่วนเชื่อมที่ตรงกัน โดยตัวแอดเองจะเป็นคนเริ่มใช้ก่อน
PO: อยากทำเป็น platform ที่ใครก็ติดตั้งและเลือกใช้ได้ ตอนแรกก็ฉันนี่แหละจะใช้ สร้าง workspace แล้วเลือกส่วนเสริม เช่น Plane สำหรับ backlog และ defect กับลูกค้า
workspace ในภาพนี้หมายถึงพื้นที่ทำงานที่รวมสมาชิก โครงการ และการตั้งค่าของทีมไว้ด้วยกัน ส่วน plugin หรือส่วนเสริมคือสิ่งที่เลือกต่อเข้ามาให้ระบบทำงานร่วมกับของภายนอกได้ แนวคิดจึงเป็นว่าทีมหนึ่งอาจใช้ Plane แต่ทีมอื่นไม่จำเป็นต้องเลือกเหมือนกัน เพียงระบบต้องมีวิธีเชื่อมสิ่งที่แต่ละทีมเลือก
Tech Lead (GPT): ถ้าจะให้คนอื่นติดตั้งและเลือกเครื่องมือเองได้ เรากำลังขยับจากระบบของทีมเดียวมาเป็นแพลตฟอร์มแล้ว ต้องมีส่วนกลางจัดการพื้นที่ทำงาน ทีม บทบาท และการรันงาน ส่วน Plane กับตัวช่วย AI แต่ละเจ้าค่อยต่อเข้ามาเป็นส่วนเสริม
ถึงตรงนี้ AO ก็ยังอยู่ในคำตอบครับ แต่บทบาทเริ่มเปลี่ยนจากสิ่งที่เสนอให้ใช้เป็นตัวกลางหลัก มาเป็นตัวที่อาจนำมาประกอบเป็นส่วนรันงานของแพลตฟอร์ม แอดจึงเริ่มต้องตามให้ทันว่าเรายังเลือกของมาใช้ หรือกำลังออกแบบผลิตภัณฑ์ใหม่ครอบมันไปแล้ว
พอฟังดูแบบนี้ AI ก็ช่วยแตกต่อได้อีกหลายอย่าง ทั้งการสร้าง squad จากแบบเริ่มต้น การกำหนด role หรือบทบาทหน้าที่ การเลือกตัวรัน agent การตั้งงบ และหน้าจอดูความคืบหน้า แต่ละส่วนตอบความต้องการบางอย่างจริง ถ้าคนอื่นจะเข้ามาใช้ ระบบก็ควรรู้ว่าเขาเป็นใครและได้รับอนุญาตให้ทำอะไร
ทว่าเมื่อเริ่มรวมทุกอย่างเข้าด้วยกัน เราก็กำลังพูดถึงงานพัฒนาผลิตภัณฑ์อีกตัวหนึ่ง ซึ่งต้องมีรายละเอียดและการตรวจของตัวเอง สมมติเพิ่มหน้าจอเลือก plugin ก็ยังต้องดูว่าตั้งค่าผิดแล้วเกิดอะไรขึ้น ถอดส่วนเสริมขณะมีงานค้างได้ไหม หรืออัปเดตแล้วข้อมูลเดิมยังใช้ได้หรือเปล่า สิ่งเหล่านี้จะกลายเป็นงานที่ทีมต้องดูแลต่อ
แอดยังสนใจภาพแพลตฟอร์มนี้อยู่ แต่ก็เริ่มอยากรู้ว่าต้องทำทั้งหมดตั้งแต่ตอนนี้จริงไหม เพราะถ้าต้องใช้แรงมากเพื่อสร้างระบบมาช่วยลดแรงคน เราอาจต้องรออีกนานกว่าจะได้ใช้ทีมแรกทำงานที่ตั้งใจไว้
การมี AI ช่วยคิดทำให้เห็นของที่อาจต้องมีในอนาคตเร็วขึ้นมาก ส่วนหน้าที่ของคนคุยก็กลายเป็นต้องคอยถามว่าของชิ้นนั้นช่วยแก้โจทย์ของตอนนี้หรือยัง หรือแค่เป็นสิ่งที่อธิบายต่อได้เมื่อเราพูดคำว่า platform ขึ้นมา แอดเลยดึงบทสนทนากลับไปที่ภาพเริ่มต้นอีกครั้ง
ก่อนจะเพิ่มสิ่งที่ระบบต้องทำ แอดอยากทวนภาระการลองใช้งานด้วย POC หรือ Proof of Concept คือการลองเพื่อพิสูจน์ข้อที่ยังไม่แน่ใจ เช่น ตัวรันนี้เรียก agent ที่เรามีและส่งผลกลับมาได้จริงไหม ส่วน UAT หรือ User Acceptance Testing คือการทดสอบเพื่อยอมรับงาน ว่าตรงกับความต้องการใช้งานที่ตกลงกันหรือไม่ แอดไม่ได้อยากข้ามการพิสูจน์แล้วเชื่อคำตอบ AI ไปเลย แต่ไม่อยากเป็นคนไล่ตั้งทุกเครื่องมือและกดทุกเส้นทางด้วยตัวเอง
ส่วนคำว่า provider ที่ใช้คุยกัน หมายถึงผู้ให้บริการเครื่องมือ AI แต่ละเจ้าครับ แอดอยากเริ่มจากค่าสมาชิกที่มีอยู่แล้วให้คุ้มก่อน
PO: กลับมากำหนดทิศทางภาพรวมอีกครั้ง ตอนนี้แค่อยากใช้ subscription สาม provider ที่บอก ให้รันงานกันเองได้เร็วที่สุด ถ้าเตรียมให้เป็น platform ในอนาคตได้โดยไม่เพิ่มเวลาและภาระ POC/UAT มากก็ค่อยทำ แต่ถ้ามีของที่ใกล้เคียงหรือดีกว่าอยู่แล้ว ก็แนะนำมาได้
หลังดึงกลับมาที่การเริ่มใช้เร็วๆ GPT ก็เสนอให้แยกสิ่งที่ต้องได้ตอนนี้ออกจากภาพแพลตฟอร์มในอนาคต และเพิ่มชื่อ Agetor ซึ่งเป็นโปรแกรมจัดงาน agent ผ่านบอร์ดกับขั้นตอนส่งต่องาน เข้ามาเทียบกับ AO อีกครั้ง
Tech Lead (GPT): ตอนนี้เอาทีมที่รับงาน ลงมือ ตรวจ และส่งแก้กันได้ก่อน เลือกของที่มีมาใช้แล้วค่อยต่อส่วนจำเป็น ผมเริ่มให้น้ำหนัก Agetor สำหรับการเริ่มเร็ว ส่วน AO ยังเก็บไว้เทียบเรื่องการตามงานตรวจและแก้โค้ด ไม่ได้ตัดออก
คำแนะนำรอบนี้ทำให้เห็นว่าตัวเลือกเดิมยังอยู่ แต่ลำดับเปลี่ยนตามน้ำหนักของโจทย์ จากเดิมที่คุยเรื่องขยายระบบ ตอนนี้กลับมาเน้นว่าจะทำให้ทีมแรกเริ่มทำงานได้เร็วแค่ไหน โดยไม่ต้องสร้างแพลตฟอร์มให้ครบก่อน
สิ่งที่อยากให้ชัดตรงนี้คือ แอดกำลังหาแนวทางเริ่มใช้งาน ไม่ได้อยากเสียเวลาจมอยู่กับมัน ถ้ามีเครื่องมือที่ช่วยจัดงานและรันวงจรตรวจแก้ได้อยู่แล้ว ก็อยากดูว่าต่อจากของนั้นได้แค่ไหน และเหลือส่วนที่จำเป็นต้องทำเองจริงๆ ตรงไหนบ้าง
ถ้าจะให้ AI ช่วยลดงานได้จริง การเตรียมและตรวจข้อเหล่านี้ก็ควรเป็นส่วนหนึ่งของงานทีมด้วย คนที่ช่วยคิดทางเลือกควรบอกได้ว่าอะไรตรวจจากเอกสารได้ อะไรต้องทดลอง และต้องเอาหลักฐานแบบไหนกลับมาให้ PO ใช้ตัดสินใจ แทนการส่งลิสต์โปรแกรมมาแล้วให้เราไปลองจนรู้คำตอบเองทั้งหมด
ในมุมการเริ่มใช้งาน แอดจึงอยากให้ทีมรับโจทย์ ลงมือ ตรวจ ขอแก้ และกลับมารายงานได้สักวงจรก่อน ส่วนภาพระยะยาวก็ยังเก็บไว้ดูว่าของที่เลือกวันนี้จะเอาความต้องการ ชุดวิธีทำงาน และประวัติงานออกมาใช้ต่อได้ไหม โดยไม่ต้องสร้างแหล่งรวมส่วนเสริมให้คนมาเลือกติดตั้ง หรือ marketplace หรือหน้าจอบริหารหลายบริษัทให้เสร็จตั้งแต่รุ่นแรก
ข้อเสนอของ AI จึงเริ่มกลับมาทางเลือกใช้ของที่มีอยู่ก่อน แล้วค่อยเพิ่มส่วนเชื่อมที่ขาด แต่ถึงจะเลือกของสำเร็จรูป ก็ยังต้องรู้ว่าของนั้นเข้ามารับภาระแทนเราตรงไหน และส่วนไหนยังเหลือให้คนคุมอยู่ เรื่องนี้พาไปสู่คำถามอีกแบบที่แอดลองถาม เพื่อดูว่าจะลดของที่ต้องสร้างลงได้อีกหรือเปล่า
ลองคิดถึงวันที่ทีมกำลังทำแอปมือถือ แล้วเราอยากให้ dev กับ QA ลองเปิดแอปบนเครื่องทดสอบที่อยู่บน server ได้ ถ้ามองทุกอย่างเป็นแพลตฟอร์ม อาจเริ่มคิดถึงหน้าจอเลือกเครื่อง ปุ่มเริ่มทดสอบ และส่วนเสริมสำหรับจัดการงานทั้งหมด แต่สิ่งที่ต้องการก่อนคือให้ทีมใช้เครื่องมือทดสอบนั้นเป็นและส่งผลกลับมาได้
สิ่งที่คุยต่อคือ skill หรือชุดคำแนะนำวิธีทำงานที่เตรียมให้ agent อ่านและนำไปใช้ ส่วนตัวอย่างงานที่แอดนึกถึงคือการทดสอบแอปผ่าน Android emulator ซึ่งเป็นโปรแกรมจำลองอุปกรณ์ Android และ remote server หรือเครื่องอีกเครื่องที่เชื่อมต่อไปใช้งานได้
PO: หรือจริงๆ แค่ต้องการให้ AI chat ตัวหนึ่งคอยเขียน skill ไว้ ให้ AI แต่ละตัวมาอ่านแล้วรันทีมได้เลย นึกถึงวันหนึ่งอยากให้ dev กับ QA ใช้ Android emulator บน remote server ถ้าต้องทำเป็นระบบทุกอย่าง มันจะยุ่งเกินไปไหม
Android emulator คือโปรแกรมจำลองอุปกรณ์ Android บนคอมพิวเตอร์ ทำให้เปิดแอปและลองพฤติกรรมได้โดยไม่จำเป็นต้องหยิบโทรศัพท์จริงมาทุกครั้ง ส่วน remote server ก็คือเครื่องอีกเครื่องที่เราเชื่อมต่อไปใช้งาน ในตัวอย่างนี้อยากให้ทีมใช้เครื่องทดสอบที่เตรียมไว้ร่วมกันได้ แม้ตัว agent จะรันอยู่คนละที่
ถ้าจะลงแอปและดูผลบนเครื่องจำลอง ก็มีเครื่องมืออย่าง ADB หรือ Android Debug Bridge ที่ใช้สื่อสารกับอุปกรณ์หรือ emulator เช่น ติดตั้งแอป เรียกดู log หรือบันทึกเหตุการณ์ของระบบ และส่งคำสั่งที่รองรับได้ แต่ทีมยังต้องรู้ขั้นตอนว่าไฟล์แอปมาจากโค้ดฉบับไหน จะใช้เครื่องไหน และเก็บผลกลับมาไว้ตรงไหน
ตรงนี้เองที่ skill เข้ามาช่วยได้ ในรูปแบบ Agent Skills skill เป็นชุดคำแนะนำที่อาจมีสคริปต์ ซึ่งเป็นชุดคำสั่งให้เครื่องทำงานตามขั้นตอน และเอกสารประกอบอยู่ด้วย เช่น วิธีเตรียมแอป วิธีเลือกเครื่องทดสอบ สิ่งที่ต้องรัน และหลักฐานที่ต้องส่งกลับ คล้ายเก็บวิธีทำงานที่ตกลงกันไว้ให้ agent หยิบมาอ่านเมื่อเจองานประเภทนั้น
ในตัวอย่างนี้ skill อาจบอกให้เริ่มจากจองเครื่องทดสอบ บิ้วหรือแปลงโค้ดให้เป็นไฟล์แอปที่ติดตั้งได้จาก commit ที่กำหนด ติดตั้งแล้วลองตามชุดทดสอบ เก็บ log กับภาพที่เกี่ยวข้อง และคืนเครื่องเมื่อเสร็จ ส่วนคำสั่งที่ต้องทำซ้ำก็เก็บเป็นสคริปต์ให้เรียกได้ แทนการให้ agent คิดวิธีใหม่ทั้งหมดทุกรอบ
Tech Lead (GPT): Skill บอกวิธีทำงาน แต่ไม่ได้ทำให้ agent ตื่นขึ้นมา ส่งงานต่อ หรือกลับมาทำต่อหลังเครื่องเริ่มทำงานใหม่ได้เอง และไม่ได้สร้างสิทธิ์หรือเครื่องมือที่ยังไม่มีให้เกิดขึ้นมา
ถ้ายังไม่มี emulator หรือยังเชื่อมต่อไปที่ server ไม่ได้ การเขียนคู่มือก็ยังไม่พอครับ ต้องเตรียมเครื่องมือและทางเข้าถึงจริง แล้วตรวจว่าทำตามขั้นตอนได้ ส่วนถ้ามีหลายงานใช้เครื่องทดสอบเดียวกัน ก็ต้องมีวิธีไม่ให้ระหว่างที่ QA กำลังทดสอบ อีก agent เข้ามาติดตั้งแอปอีกฉบับทับพอดี
อีกส่วนคือสิทธิ์ในคู่มือกับสิทธิ์จริงเป็นคนละชั้น เราอาจเขียนไว้ว่า QA ใช้เฉพาะเครื่องทดสอบ แต่ environment หรือสภาพแวดล้อมการทำงาน ทั้งเครื่อง โปรแกรม และการตั้งค่าที่ให้ agent เข้าถึงก็ควรถูกจัดไว้ให้ตรงกับขอบเขตนั้นด้วย รวมถึงต้องรู้ว่าเครื่องมือแต่ละตัวอ่าน skill จากที่ไหน จะได้ไม่คิดว่าการวางไฟล์คำแนะนำชื่อ SKILL.md ไว้สักแห่งทำให้ทุกตัวใช้เป็นทันที
แนวทางนี้ทำให้แอดเริ่มเห็นว่าบางความสามารถอาจเพิ่มเป็นวิธีทำงานกับสคริปต์ก่อน ส่วนตัวจัดทีมก็ยังช่วยคุมว่าเมื่อไรควรเรียกใช้และจะส่งผลต่อให้ใคร ยังไม่จำเป็นต้องทำให้ทุกเครื่องมือมีหน้าจอหรือ plugin ของตัวเองตั้งแต่เริ่ม
การเจาะตัวอย่างหนึ่งเรื่องเลยช่วยให้ภาพกว้างเปลี่ยนไปอีกครั้ง เรากำลังแยกสิ่งที่ทีมต้องทำให้เป็น ออกจากสิ่งที่จำเป็นต้องสร้างเป็นระบบให้คนมาควบคุม และน่าจะเอาวิธีคิดเดียวกันกลับไปดูความสามารถส่วนอื่นได้ด้วย
พอให้ทีมเริ่มทำงานต่อกันได้ สิ่งที่แอดยังติดอยู่คือจะมั่นใจในผลได้ยังไงโดยไม่กลับไปตรวจทุกจุดเอง ถ้าสุดท้ายต้องกดทุกหน้าจอใหม่ทั้งหมดก่อนรับงาน การมี agent ช่วยทำเร็วขึ้นก็ยังทิ้งภาระช่วงท้ายไว้กับคนค่อนข้างมาก
คำว่าโดเมนที่แอดใช้คุยในช่วงนี้ หมายถึงกลุ่มงานหรือขอบเขตความรับผิดชอบ เช่น การจัดการงาน การรัน agent และการทดสอบ อยากแยกให้เห็นว่าแต่ละส่วนต้องทำอะไร ก่อนตัดสินใจว่าจะทำเองหรือใช้เครื่องมือที่มีอยู่
PO: แตกเป็นโดเมนใหญ่ๆ แล้วค่อยเลือกได้ไหมว่าแต่ละส่วนทำเองหรือใช้ของอะไร แต่ต้องให้น้ำหนักกับภาระทดสอบด้วย รวมถึงวันนี้เข้ากันได้ไหม แล้วถ้ามันอัปเกรดหรือเลิก maintain จะทำยังไง
Tech Lead (GPT): ได้ เราค่อยตัดสินใจทีละส่วนว่าใช้ของที่มี ทำส่วนเชื่อมเอง หรือพักไว้ก่อน แต่ต้องรวมภาระตรวจของ PO เข้าไปในเกณฑ์ด้วย และไม่ถือว่าให้ AI อ่านโค้ดแล้วจะทดแทนการทดสอบสิ่งที่เกิดขึ้นจริงได้ทั้งหมด
คำตอบรอบนี้ GPT ไม่ได้หยิบเฉพาะเรื่องทดสอบมาคุย แต่แบ่งภาพของระบบออกเป็น 10 modules หรือส่วนงานที่แยกความรับผิดชอบกันได้ เพื่อให้เราเลือกทีละส่วนว่าอะไรจะใช้ของที่มี อะไรต้องทำเพิ่ม และอะไรยังไม่จำเป็นต้องเริ่ม แอดเลยเก็บภาพทั้งก้อนนี้ไว้ก่อน จะได้ไม่คุยเรื่องเครื่องมือตัวหนึ่งจนลืมว่ามันกำลังรับผิดชอบส่วนไหนของระบบ
ก่อนอ่านแต่ละส่วน คำที่ GPT ใช้จัดทางเลือกคือ Adopt หมายถึงเลือกเครื่องมือที่มีมาใช้, Wrap คือทำส่วนเชื่อมครอบไว้ให้เปลี่ยนเครื่องมือข้างในได้, Build คือพัฒนาส่วนที่จำเป็นเอง และ Defer คือพักไว้ก่อน ส่วน P0 คือสิ่งที่ต้องทำให้ทีม AI เริ่มใช้งานได้จริง, P1 คือสิ่งที่ค่อยเพิ่มเมื่อมีงานจริง และ P2 คือสิ่งที่เตรียมแนวทางไว้แต่ยังไม่พัฒนา ระดับความเสี่ยงที่ยกมาด้วยเป็นการประเมินเบื้องต้นในบทสนทนา เพื่อใช้ตั้งคำถามต่อ ยังไม่ใช่ผลทดลองเปรียบเทียบเครื่องมือ
Tech Lead (GPT): ผมจะแบ่งแพลตฟอร์มออกเป็น 10 ส่วน แล้วตัดสินใจทีละส่วนโดยใช้ภาระของ PO เป็นเงื่อนไขร่วมด้วย
1. Agent Runtime: โปรแกรมที่ใช้รัน agent แต่ละตัว
P0 | Adopt + Wrap | ความเสี่ยงสูง
รับผิดชอบการรัน Claude, Codex และ Cursor ผ่านสิทธิ์ subscription ที่มีอยู่ เลือกใช้ตัวรันของแต่ละเจ้าก่อน แล้วทำส่วนเชื่อมให้ระบบเรียก เริ่มงาน หยุด หรือรับผลกลับได้โดยไม่ผูกทุกขั้นเข้ากับผู้ให้บริการรายเดียว
2. Orchestration: การคุมงานให้ทั้งทีมเดินต่อกัน
P0 | Adopt ก่อน | ความเสี่ยงสูง
รับผิดชอบการมอบหมายงาน ส่งต่อจากคนลงมือไปคนตรวจ ส่งกลับไปแก้ และกลับมาทำงานที่ค้างต่อ นี่คือส่วนที่ทำหน้าที่ PM ของระบบ คอยแจกงานและเรียก agent ที่ถึงคิวให้ลุกขึ้นมาทำ ไม่ใช่แค่มีชื่อทีมกับแผนงานอยู่บนหน้าจอ
3. Skills & Tooling: วิธีทำงานและเครื่องมือที่ agent หยิบใช้ได้
P0 | Build เฉพาะส่วนบางๆ | ความเสี่ยงกลาง
เพิ่มความสามารถให้แต่ละบทบาทผ่าน skill, สคริปต์ และเครื่องมือ เช่น วิธีเตรียมแอปหรือวิธีเก็บผลทดสอบ เขียนเฉพาะคำแนะนำกับชุดคำสั่งที่ทีมต้องใช้ร่วมกันก่อน ไม่ต้องทำทุกความสามารถเป็นฟีเจอร์ใหม่ของแพลตฟอร์ม
4. Quality Assurance: การตรวจคุณภาพและพฤติกรรมที่เกิดขึ้นจริง
P0 | Adopt | ความเสี่ยงสูง
เลือกเครื่องมือทดสอบที่มีอยู่มาใช้ตรวจทั้งฟังก์ชัน การเชื่อมต่อระหว่างส่วน และ UI หรือ User Interface ซึ่งเป็นหน้าจอที่ผู้ใช้โต้ตอบด้วย รวมถึง regression test หรือการทดสอบซ้ำว่างานที่แก้ไม่ได้ทำให้ส่วนเดิมเสีย ต้องออกแบบว่าจะตรวจอะไรและเก็บหลักฐานแบบไหน การมี AI อ่านโค้ดอีกรอบยังไม่ใช่ผลทดสอบทั้งหมด
5. Workspace & Roles: พื้นที่ทำงาน บทบาท และสิทธิ์ของทีม
P1 | เริ่มจากการตั้งค่า | ความเสี่ยงกลาง
แยกทีม บทบาท โปรเจกต์ และสิทธิ์ของแต่ละคนกับแต่ละ agent ให้ชัด เริ่มจากโครงสร้างและการตั้งค่าที่ใช้กับทีมแรกได้ก่อน ยังไม่ต้องสร้างหน้าจอบริหารสมาชิกครบทุกแบบ แต่การแยกสิทธิ์จริงต้องตรงกับขอบเขตงานที่ให้ทำ
6. Backlog & Defects: รายการงานและข้อบกพร่องที่ต้องติดตาม
P1 | Plugin / Adopt | ความเสี่ยงกลาง
ใช้ Plane หรือบอร์ดอื่นเก็บงานที่อยากทำกับปัญหาที่พบ รวมถึงมุมให้ลูกค้าเห็นความคืบหน้าหรือแจ้งปัญหา เลือกต่อผ่านส่วนเสริม เพื่อให้เปลี่ยนบอร์ดภายหลังได้ โดยไม่เอาประวัติการทำงานทั้งหมดของ agent ไปผูกไว้กับบอร์ดตัวเดียว
7. Source Control & CI: ประวัติโค้ดและขั้นตรวจเมื่อโค้ดเปลี่ยน
P0 | Adopt | ความเสี่ยงต่ำ
ใช้ Git และ PR จัดการการเปลี่ยนโค้ด ส่วน CI หรือ Continuous Integration คือการนำโค้ดที่เปลี่ยนมารวมและตรวจเป็นระยะ มักตั้งให้บิ้วกับทดสอบอัตโนมัติ รวมถึงกำหนดเงื่อนไขก่อนรวมโค้ดและปล่อยโปรแกรมรุ่นใหม่ เลือกใช้ระบบที่มีอยู่ก่อน ไม่เขียนระบบเก็บโค้ดหรือระบบตรวจชุดใหม่ขึ้นมาเอง
8. Remote Environments: เครื่องและพื้นที่ทดสอบที่ทีมเข้าไปใช้งานได้
P1 | Adopt + Scripts | ความเสี่ยงสูง
เตรียม Android emulator, browser และเครื่องมือรันโปรแกรมแยกเป็นชุดอย่าง Docker รวมถึง staging หรือพื้นที่ทดสอบที่เตรียมให้ใกล้กับระบบใช้งานจริง ใช้ของที่มีแล้วเขียนสคริปต์สำหรับเตรียม เรียกใช้ และคืนสภาพแวดล้อมให้พร้อมสำหรับงานถัดไป ต้องดูด้วยว่าแต่ละ agent มีสิทธิ์เข้าไปทำอะไร และงานหลายชิ้นจะใช้เครื่องร่วมกันอย่างไร
9. Observability & Cost: การมองเห็นสิ่งที่เกิดขึ้นและต้นทุนของงาน
P1 | Adopt + Wrap | ความเสี่ยงกลาง
เก็บ log การใช้งาน โควตา งานที่ล้มเหลว และประวัติที่ใช้ตรวจย้อนหลัง เพื่อให้รู้ว่าทีมติดอะไร ใช้ทรัพยากรไปกับงานไหน และต้องกลับมาถาม PO เรื่องอะไร เลือกเครื่องมือเก็บข้อมูลที่มีอยู่ แล้วทำส่วนเชื่อมเฉพาะข้อมูลของทีม โดยแยกสิ่งที่วัดได้จริงออกจากค่าที่ต้องประมาณ
10. Platform & Extensibility: ตัวแพลตฟอร์มและทางขยายความสามารถ
P2 | Defer | ความเสี่ยงสูง
เรื่องการติดตั้งให้คนอื่นใช้ การรองรับหลาย workspace หน้าจอบริหาร และ Plugin SDK หรือ Software Development Kit ซึ่งเป็นชุดเครื่องมือสำหรับพัฒนาส่วนเสริม ให้เตรียมขอบเขตกับวิธีเชื่อมไว้ก่อน แต่ยังไม่ต้องทำครบตั้งแต่วันแรก เพราะเป้าหมายตอนนี้คือให้ทีม AI เริ่มรับงานและทำงานต่อกันได้
พอเห็นครบทั้ง 10 ส่วน สิ่งที่ต้องเลือกก่อนจึงชัดขึ้นว่าเป็นตัวรัน agent กับตัวคุมงาน เพราะถ้าสองส่วนนี้ยังเดินต่อกันไม่ได้ หน้าจอหรือส่วนเสริมที่ทำเพิ่มก็ยังไม่ช่วยให้ทีมเริ่มทำงาน ส่วนเรื่องทดสอบ วิธีทำงาน และเครื่องทดสอบก็ต้องค่อยๆ เลือกให้ต่อกับวงจรเดียวกันได้ ไม่ได้แปลว่าตัดออกจากความรับผิดชอบเพียงเพราะยังไม่สร้างเป็นหน้าจอ
การทดสอบก็มีหลายระดับ ถ้าตรวจฟังก์ชันเล็กๆ ว่ารับข้อมูลแบบนี้แล้วให้คำตอบแบบไหน มักเรียก unit test ถ้าตรวจว่าส่วนต่างๆ เชื่อมกันแล้วทำงานได้ไหมก็เป็น integration test และถ้าลองเดินตามการใช้งานจากต้นไปปลาย เช่น เปิดหน้า กดปุ่ม แล้วดูผลที่ผู้ใช้จะเห็น ก็เป็นแนว end-to-end หรือ E2E สิ่งเหล่านี้ช่วยตอบคนละคำถาม จึงยังต้องเลือกให้ตรงกับงานที่อยากพิสูจน์
สำหรับเว็บ มีเครื่องมืออย่าง Playwright ที่ช่วยให้เขียนการทดสอบโดยสั่ง browser เปิดหน้า คลิก กรอกข้อมูล และตรวจสิ่งที่ควรปรากฏได้ สมมติในงานล็อกอิน เราอาจอยากให้มีหลักฐานว่ากดยกเลิกแล้วกลับมาหน้าปกติ ไม่ค้างอยู่ที่สถานะกำลังโหลด นี่คือหน้าตาของสิ่งที่ QA ควรนำไปออกแบบให้ตรวจซ้ำได้
ส่วนฝั่งแอปมือถือก็มีเครื่องมืออย่าง Maestro และ Appium ให้ศึกษา ซึ่งช่วยทำงานกับเส้นทางใช้งานของแอปในแนวของตัวเอง ก่อนจะเลือกคงต้องดูว่าเหมาะกับแอปและ environment ที่เรามีแค่ไหน ไม่ใช่เห็นว่ารองรับ Android แล้วถือว่ารายละเอียดทุกอย่างตรงกันหมด
แอดยังไม่ได้เลือกชุดทดสอบจากรายชื่อเหล่านี้ในวันแรก แต่เริ่มรู้แล้วว่าคำว่ามี QA agent ต้องเชื่อมกับของที่ตรวจจริง มันควรบอกได้ว่ารันกับโค้ดฉบับไหน ลองกรณีอะไร ผ่านหรือไม่ผ่าน และดูหลักฐานได้ที่ไหน ถ้าตรวจไม่ครบบางส่วนก็ควรระบุไว้ให้รู้ขอบเขตของคำว่าผ่านด้วย
เช่น การทดสอบว่าปุ่มทำงานได้ไม่ได้ตอบแทน PO ว่าเราควรบังคับลูกค้าทุกคนให้ใช้วิธีล็อกอินนี้หรือไม่ เรื่องความต้องการและสิ่งที่ยอมรับได้ยังต้องมีเจ้าของตัดสินใจ ส่วนสิ่งที่ตกลงว่าควรเกิดขึ้นแล้ว ทีมก็ควรช่วยเตรียมวิธีตรวจให้เราเห็นเป็นหลักฐานได้
ตรงนี้เชื่อมมาถึง digest หรือสรุปความคืบหน้าและเหตุการณ์สำคัญที่แอดอยากอ่านในบทบาท PO ด้วยครับ อยากได้สรุปที่รู้ว่างานไหนเดินไปถึงไหน มี incident อะไรเกิดขึ้น ทีมทำอะไรกับมันไปแล้ว และยังมีเรื่องอะไรที่ต้องตอบหรือตัดสินใจต่อ ถ้าต้องเปิดทุก log เองแล้วค่อยประกอบภาพใหม่ทั้งหมด ความตั้งใจเรื่องลดแรงคนก็ยังไปได้ไม่ไกลนัก
การยอมรับ incident ของโปรเจกต์ยังเป็นเรื่องของคนที่ดูแลอยู่ แอดไม่ได้มองว่าพอมีทีม AI แล้วจะไม่ต้องรู้ว่ามีอะไรเกิดขึ้น เพียงอยากมีคนช่วยรวบรวม ตรวจ และอธิบายผลให้ตามทัน เพื่อให้ใช้แรงไปกับการ steer หรือกำหนดทิศทางมากกว่าการวิ่งเก็บข้อมูลเองทุกจุด
และเมื่อเราต้องพึ่งเครื่องมือเหล่านี้จริง การเลือกก็ต้องนับวันข้างหน้าด้วย ถ้าอัปเดตแล้วเชื่อมต่อกันไม่ได้ ใครจะช่วยตรวจ หรือถ้าโครงการหยุดพัฒนาต่อ เรายังเอา skill, โค้ด และประวัติงานออกมาใช้กับทางเลือกอื่นได้ไหม ของสำเร็จรูปจึงไม่ได้แปลว่าไม่มีภาระดูแล เพียงเราต้องเห็นว่าภาระที่รับมาคุ้มกับงานที่มันช่วยลดได้หรือเปล่า
หลังจากคุยจนรู้ว่าต้องมองหาความสามารถอะไรบ้าง แอดถึงเริ่มอยากได้รายชื่อผลิตภัณฑ์ไปเปิดอ่านต่อ โดยเฉพาะตัวที่จะคอยจัดทีมและส่งงานกลับมาแก้ เพราะถ้ามีของที่ทำวงจรนี้ได้ใกล้เคียงอยู่แล้ว เราก็น่าจะเริ่มจากทำความเข้าใจมันก่อนตัดสินใจสร้างเอง
ระหว่างคุยมีหลายชื่อผ่านเข้ามา และคำแนะนำก็เปลี่ยนน้ำหนักตามคำถาม บางช่วงอยากได้ตัวที่ตามงานจนถึง PR ได้ดี บางช่วงอยากรันบน server แล้วให้หัวหน้าทีมคอยส่งงาน ส่วนอีกช่วงเริ่มสนใจวิธีทำงานผ่าน skills พอขอรายการสำหรับไปศึกษา ตัวที่เคยถูกพูดถึงตั้งแต่แรกกลับหลุดจากรายการไป
ในรายการรอบนี้ GPT ยก AWS Labs CLI Agent Orchestrator หรือ CAO ซึ่งเป็นตัวประสาน agent ผ่านหน้าต่างคำสั่ง ขึ้นมาเป็นตัวเลือกหลัก ส่วน Agetor ยังอยู่เป็นตัวเปรียบเทียบ
Tech Lead (GPT): ถ้าจะเริ่มจากเครื่อง server และให้ทีมใช้ชุดวิธีทำงานที่เตรียมไว้ ผมให้น้ำหนัก CAO ก่อน แล้วศึกษา Agetor เทียบเรื่องบอร์ดกับขั้นตอนส่งต่องาน แต่ยังต้องตรวจการลงชื่อเข้าใช้ด้วยค่าสมาชิกของทั้งสามเจ้าก่อน
พออ่านคำตอบนี้ แอดเลยต้องกลับมาถาม เพราะก่อนหน้านี้ AO ถูกเสนอทั้งเป็นตัวคุมงานหลัก เป็นส่วนรันงานของแพลตฟอร์ม และเป็นตัวที่ให้เก็บเทียบกับ Agetor แต่ในรายการล่าสุดกลับไม่มีชื่อมันแล้ว คนอ่านคำตอบทีละรอบอาจตามของใหม่ไปเรื่อยๆ จนลืมถามว่าตัวเก่าถูกตัดด้วยเหตุผลอะไร
PO: ไหน AO ที่ว่ามาตอนแรกๆ หายไปไหน
Tech Lead (GPT): AO ไม่ควรหายไป ผมตัดออกเร็วเกินไปตอนขยับไปให้น้ำหนัก CAO กับ Agetor ทั้งที่ยังไม่ได้เทียบด้วยเกณฑ์เดียวกัน ควรเก็บ AO กับ CAO ไว้พิจารณาคู่กัน แล้วดูว่าตัวไหนลดงานที่คุณต้องคอยตามเองได้มากกว่ากัน
ที่ต้องถามกลับก็เพราะอยากรู้ว่ามันมีข้อจำกัดอะไรที่ทำให้ควรตัดออก หรือแค่คำตอบล่าสุดขยับไปให้น้ำหนักของใหม่จนลืมตัวเลือกเดิม พอทวนแล้ว AI ก็ปรับกลับมาให้เก็บ AO กับ CAO ไว้พิจารณาคู่กัน และยังมี Agetor เป็นอีกแนวที่อยากเปิดอ่าน ไม่ได้ปิดคำตอบทันทีว่าตัวใดเหมาะกับเราที่สุด
ก่อนอ่านแต่ละตัว ยังมีเรื่องชื่อที่ต้องระวังนิดหนึ่งครับ คำว่า Agent Orchestrator ถูกใช้กับหลายโครงการ ในแชทเองก็มีลิงก์ไปต่าง repository ปรากฏอยู่ด้วย เวลาจดเลยควรเก็บ URL ไปพร้อมชื่อ จะได้ไม่เอาความสามารถของคนละโครงการมารวมกันแล้วเข้าใจว่าเป็นของตัวเดียวกัน
ตัวที่เรียกว่า Orchestrator.inc หรือ AO ในรายการนี้อธิบายตัวเองเป็นแอป desktop หรือโปรแกรมที่ติดตั้งใช้บนคอมพิวเตอร์ สำหรับจัดทีม coding agent ลองมองเป็นหน้าจอรวมที่เห็นงานหลายชิ้น แต่ละชิ้นมี agent กับพื้นที่ทำงานแยกของตัวเอง แทนการเปิดหน้าต่างคำสั่งหลายแห่งแล้วคอยจำว่าอันไหนกำลังทำเรื่องอะไร
คำว่า worktree ที่ปรากฏในเอกสารเป็นความสามารถของ Git ที่ช่วยให้มีแฟ้มงานหลายชุดจากที่เก็บโค้ดเดียวกันได้ จึงเอามาใช้แยกโต๊ะทำงานให้แต่ละ task หรือชิ้นงานที่มอบหมายได้ง่ายขึ้น ส่วน branch กับ PR ก็ยังใช้เก็บแนวทางที่แก้และส่งให้ตรวจตามที่คุยไว้ก่อนหน้า การแยกแบบนี้ช่วยจัดการงาน แต่เวลารวมกลับมาก็ยังต้องตรวจว่างานแต่ละชิ้นทำงานร่วมกันได้
ในเอกสารของ AO ยังมีเรื่อง CI หรือ Continuous Integration ซึ่งเป็นการนำโค้ดที่เปลี่ยนมารวมและตรวจเป็นระยะ โดยมักตั้งให้บิ้วโปรเจกต์และรันชุดทดสอบอัตโนมัติ แล้วส่งผลกลับไปให้ worker หรือ agent ที่รับผิดชอบชิ้นงานนั้นแก้ ถ้าไม่ผ่านหรือมีความเห็นจากการ review ระบบก็ส่งกลับไปหาผู้รับผิดชอบงานนั้นได้ นี่เป็นส่วนที่แอดสนใจ เพราะใกล้กับงานตามแก้ที่ไม่อยากเป็นคนคอยส่งข้อความต่อเองทุกครั้ง
หน้าจอนี้ช่วยให้เห็นสิ่งที่ต่างจากบอร์ด backlog ทั่วไปชัดขึ้น นอกจากงานที่กำลังทำ ยังมีช่อง Needs you สำหรับสิ่งที่ต้องกลับมาหาคน และมีสถานะเกี่ยวกับการตรวจ PR กับการรวมโค้ดอยู่ด้วย ถ้าดูการ์ดจะเห็นข้อมูลอย่าง CI failed หรือ Review pending ประกอบอยู่ จึงเป็นตัวอย่างของการพาสถานะจากการลงมือกับผลตรวจกลับมาอยู่ในที่ที่ตามงานต่อได้
คำถามที่อยากเอาไปศึกษาต่อจึงเป็นว่ารูปแบบรันของมันตรงกับเครื่องที่เราจะใช้ไหม แยกหน้าที่ตามที่ต้องการได้แค่ไหน และช่วงที่มันกลับมาขอคนช่วยเป็นเรื่องประเภทไหนบ้าง ภาพการทำงานจากต้นทางช่วยให้เริ่มนึกออก แต่ยังต้องตรวจเงื่อนไขเหล่านี้ก่อนเอามาเป็นข้อสรุปของทีมเรา
อีกแนวคือ AWS Labs CLI Agent Orchestrator หรือ CAO ซึ่งเริ่มจากการประสานเครื่องมือแบบ CLI หลายตัวผ่าน server และ terminal session หรือชุดการทำงานที่เปิดค้างไว้ในหน้าต่างคำสั่งของแต่ละตัว แล้วให้ supervisor หรือ agent ที่ทำหน้าที่ดูภาพรวม ส่งงานให้ผู้ช่วยเฉพาะด้านได้ทั้งแบบรอตามลำดับและทำบางส่วนพร้อมกัน
ถ้านึกเป็นทีมทำงาน หัวหน้าทีมอาจส่งให้ตัวหนึ่งอ่านโค้ดที่เกี่ยวกับบัญชีผู้ใช้ ขณะอีกตัวช่วยดูชุดทดสอบ แล้วรวบรวมสิ่งที่ได้กลับมาตัดสินใจว่าจะให้ใครลงมือต่อ ตัวอย่างนี้ใช้ให้เห็นลักษณะการประสานงานที่อยากศึกษา ไม่ได้หมายความว่าระบบที่เราต้องการมี workflow หรือลำดับขั้นตอนการทำงานนี้พร้อมใช้แล้วทั้งหมด
เอกสาร CAO มีแนวทางสำหรับ Claude Code, Codex และ Cursor CLI แยกให้ตามอ่าน รวมถึงหน้าจอเว็บสำหรับดูและจัดการ agent ด้วย ส่วนที่แอดอยากเทียบคือ จากความสามารถในการเรียกและส่งงานระหว่างตัวเหล่านี้ ไปถึงวงจร dev, review, fix และ QA ที่อยากใช้ ยังมีอะไรต้องกำหนดเพิ่ม และเราจะดูหลักฐานของแต่ละขั้นได้ยังไง
ในตัวอย่างนี้จะเห็นภาพอีกแบบหนึ่ง คือมีรายการ agent ที่กำลังรัน มี profiles หรือชุดกำหนดลักษณะของ agent และมีปุ่มเปิด terminal ของแต่ละตัว จุดสนใจของหน้าจอจึงอยู่ที่การดูและประสานตัวที่กำลังทำงานอยู่ ส่วนจะให้งานหนึ่งชิ้นผ่านขั้นตอนตรวจอะไรบ้าง ยังเป็นเรื่องที่ต้องกลับไปดู workflow ประกอบด้วย
ความแตกต่างที่ต้องไปดูจึงอยู่ที่ลักษณะงานที่เครื่องมือช่วยจัดให้ ถ้าเราอยากให้หัวหน้าทีมเลือกคนไปทำงานย่อยได้คล่องก็น่าสนใจแนวนี้ ส่วนถ้าอยากลดแรงตาม PR และผลตรวจเป็นหลัก ก็ต้องเอาโจทย์เดียวกันกลับไปถามตัวเลือกอื่นด้วย ยังไม่ควรตัดสินจากการเห็นว่ารองรับ provider ที่มีอยู่ครบอย่างเดียว
Agetor เป็นอีกแนวที่เริ่มจากบอร์ดงานบนเครื่อง แต่ละการ์ดกำหนดโจทย์กับโปรเจกต์และตัว agent ที่จะใช้ได้ แล้วแยก worktree ให้ตอนเริ่มรัน จึงเป็นหน้าตาที่คนซึ่งคุ้นกับการดูงานเป็นคอลัมน์อาจเริ่มเข้าใจได้ง่ายกว่าการตามหลาย terminal พร้อมกัน
เอกสารยังมี reusable profile คือเก็บชุดตั้งค่าของ agent ไว้ใช้ซ้ำ และ pipeline ที่เชื่อมขั้นตอนเข้าด้วยกัน เช่น ให้ตัวหนึ่งช่วยวางแผนแล้วส่งอีกตัวไปลงมือ ก่อนกลับมาตรวจ ถ้าต้องแก้ก็วนกลับตามทางที่กำหนดไว้ ส่วนการออกแบบว่าผลอะไรทำให้ควรไปต่อหรือกลับไปแก้ ก็ยังต้องให้ตรงกับความต้องการของทีมด้วย
ถ้าดูภาพนี้จะเห็นงานที่ยังอยู่ใน backlog แยกจากงานที่กำลังรัน และยังมีที่สำหรับงานที่ติดหรือรอ review อยู่ด้วย สิ่งที่อยากได้จากภาพรวมลักษณะนี้คือเปิดมาแล้วรู้ว่ามีตรงไหนต้องเข้าไปช่วยตอบ แทนการเดาจากการที่ agent เงียบไป แต่ภาพเป็นตัวอย่างของโครงการต้นทาง ยังไม่ใช่ทีมที่แอดติดตั้งและลองใช้เอง
ขณะเดียวกันเอกสารที่เปิดอ่านยังระบุ Codex กับ Cursor เป็น experimental หรือยังอยู่ในระยะทดลอง และมีรายละเอียดต่างกันเรื่องการกลับมาใช้ session หลังเริ่มโปรแกรมใหม่ อีกด้วย ความสะดวกที่เห็นจากหน้าจอจึงต้องอ่านคู่กับข้อจำกัดของตัวที่เราจะเรียกใช้จริง โดยเฉพาะถ้าอยากให้รับงานต่อกันโดยไม่มีคนคอยนั่งเฝ้า
ส่วน Symphony จะเก็บไว้ศึกษาแนวทางที่ระบบคอยรับงานจาก issue tracker ซึ่งเป็นที่เก็บรายการงาน แล้วจัดพื้นที่แยกให้ agent ไปลงมือ ตัวอย่างของโครงการใช้บอร์ด Linear เป็นจุดเริ่มรับงานและนำผลอย่างสถานะ CI หรือความเห็นจากการตรวจกลับมาให้ดู
แอดสนใจแนวคิดว่าคนคุมงานผ่านสิ่งที่อยากให้เสร็จได้ โดยไม่ต้องเริ่มจากเปิด session แล้วคอยบอกทีละขั้น แต่โครงการระบุว่าเป็น engineering preview หรือของที่ยังเปิดให้ทดลองในขอบเขตที่เหมาะสม และมี reference implementation เป็นโค้ดอ้างอิงให้ศึกษา จึงยังไม่ควรอ่านว่าเป็นแพลตฟอร์มที่พร้อมตอบทุกความต้องการของเราแล้ว
รายชื่อเหล่านี้ช่วยให้เริ่มมีของจริงไปเปิดอ่านและเทียบกันต่อได้ แต่ความน่าสนใจของแต่ละตัวก็ยังไม่ได้ตอบว่าเหมาะกับทีมเราเพียงใด สิ่งที่คุยมาก่อนหน้านี้จึงมีประโยชน์ตรงที่ทำให้รู้ว่าจะใช้คำถามอะไรไปดูหน้าตาและวิธีทำงานของเครื่องมือแต่ละตัว
ตอนเริ่มคุย แอดมีความรู้สึกว่าอยากมีทีม AI ช่วยรับช่วงงานต่อกัน แต่ยังนึกไม่ออกว่าควรเริ่มจากจัดตำแหน่ง ใช้บอร์ดเดิม หรือหาโปรแกรมที่ทำสิ่งนี้อยู่แล้ว พอคุยวนไปมา จึงค่อยเห็นว่าสิ่งเหล่านี้เกี่ยวข้องกัน แต่ก็ไม่ได้จำเป็นต้องสร้างหรือเลือกให้จบทั้งหมดพร้อมกัน
การบ้านหลังจบวันนี้เลยเป็นการไปดูผลิตภัณฑ์ในตลาด โดยพกเงื่อนไขที่คุยไว้ไปด้วย อยากให้คำว่าเริ่มได้เร็วหมายถึงเริ่มรันงานที่ตรวจผลได้ ไม่ใช่แค่ติดตั้งเสร็จแล้วค่อยพบว่ายังต้องประกอบอีกหลายส่วน และอยากให้คำว่าประหยัดรวมถึงเวลาของคนที่ต้องคอยดูแลมันด้วย
เวลาเปิดอ่านของแต่ละตัว แอดจึงอยากตอบคำถามเหล่านี้ให้ได้ก่อน
วันแรกนี้จึงยังจบที่การไปทำความเข้าใจของที่มีอยู่ก่อนครับ หลังจากเห็นข้อที่แต่ละตัวช่วยรับภาระได้และข้อที่ยังต้องจัดเองแล้ว ค่อยกลับมาเจาะทีละส่วนว่าจะเลือกใช้ ทำส่วนเชื่อมเพิ่ม หรือพักความสามารถนั้นไว้ก่อน จะได้มีเหตุผลประกอบการเลือกมากกว่าความรู้สึกว่าคำตอบล่าสุดของ AI ดูครบดี
ความคิดเรื่องทีม AI สำหรับแอดเริ่มจากอยากมีคนช่วยแบ่งเบางานให้เดินต่อได้มากกว่านี้ แล้วค่อยตามมาด้วยคำถามว่าต้องใช้เครื่องมืออะไรและคุ้มกับต้นทุนแค่ไหน การคุยแบบ PO กับ Tech Lead ช่วยให้มีทางเลือกมาให้มอง แต่ก็ยังต้องคอยทวนว่าเรากำลังตอบสิ่งที่อยากได้อยู่หรือเริ่มขยายไปทำอย่างอื่นแล้ว
ถ้าวิธีทำงานนี้ไปต่อได้ งานของคนอาจค่อยๆ ขยับมาทางกำหนดความต้องการ อ่าน digest รับรู้ incident และตัดสินใจให้ทีมมากขึ้น ส่วนงานลงมือกับการตรวจที่ตกลงวิธีพิสูจน์ได้ก็อยากให้ AI ช่วยรับไป ภาพนี้ยังเป็นสิ่งที่อยากลอง ไม่ใช่ข้อสรุปว่าทุกคนต้องเปลี่ยนบทบาททันที
อย่างน้อยหลังจบ Day 1 แอดเริ่มรู้แล้วว่าจะกลับไปดูอะไรในเครื่องมือที่มีอยู่ ทั้งวิธีรับช่วงงาน หลักฐานที่ทีมส่งกลับมา และภาระที่เราเองยังต้องดูแลต่อ จากนั้นค่อยใช้ข้อมูลเหล่านี้เลือกให้ได้ทีละส่วน ว่าจะจัดทีมที่อยากใช้จริงให้เริ่มต้นได้ยังไง
โลโก้และหน้าจอข้างต้นเป็นทรัพย์สินของแต่ละโครงการ ใช้ประกอบการอธิบายผลิตภัณฑ์ ภาพหน้าจอเป็นตัวอย่างจากต้นทาง ไม่ใช่หลักฐานว่าทีมของแอดติดตั้งหรือทดสอบผ่านแล้ว ดู ที่มาและเครดิตภาพ ได้ตามไฟล์ที่เก็บไว้ ดู ที่มาภาพ Cursor และ Claude ที่เพิ่มในฉบับนี้ ได้ในไฟล์ประกอบ ที่มาไอคอน Codex