งานไหนควรทำคู่กับ AI งานไหนควรมอบหมายแล้วรอตรวจ

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

กติกา P1 ของตัวอย่างสมมตินี้ใช้ยอดสุทธิสุดท้ายเป็นบาทหลังส่วนลดและภาษี ยอดไม่เกิน 50,000 บาทให้ผู้จัดการอนุมัติ ยอดเกิน 50,000 บาทให้ผู้อำนวยการอนุมัติ และการเปลี่ยนยอดทำให้ผลอนุมัติเดิมใช้ต่อไม่ได้ กติกานี้ไม่ใช่ค่าเริ่มต้นของ Odoo

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

ตกลงกติกาธุรกิจก่อนแบ่งงาน

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

ช่วงนี้เหมาะกับการทำงานคู่กัน เพราะคำตอบหนึ่งอาจเปลี่ยนคำถามถัดไป นักพัฒนาตรวจพฤติกรรมเดิม คุยตัวอย่างกับเจ้าของกระบวนการ แล้วให้ AI ตามหาส่วนของโค้ดที่เกี่ยวข้องได้ การกำกับใกล้ชิดก็ยังต้องมีหลักฐาน การเห็นคำอธิบายที่ฟังมั่นใจบนหน้าจอไม่ได้ยืนยันว่าโปรแกรมทำงานตามนั้น

ในตัวอย่างนี้ เจ้าของกระบวนการขยายกติกาเป็น P1.1 โดยยังให้การเปลี่ยนยอดเงินทำให้ผลอนุมัติเดิมใช้ต่อไม่ได้ ส่วนการแก้หมายเหตุภายในยังคงผลอนุมัติไว้ นี่คือกติกาสมมติของเรื่องนี้ ไม่ใช่กฎจัดซื้อทั่วไป ทีมควรบันทึกคำตัดสินและกรณีตัวอย่างก่อนลงมือ หากยังไม่มีคำตัดสิน ผลงานที่ควรส่งคือคำถามพร้อมผลกระทบ ไม่ใช่กติกาที่ AI เดาขึ้นเอง

มอบหมายผลลัพธ์ที่ตรวจได้

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

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

แยกความสัมพันธ์ของงานก่อนแยกไฟล์

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

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

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

ตรวจขอบเขตควบคู่กับผลงาน

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

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

เอกสารต้นทางแยกการกำกับงานใกล้ชิดออกจากการมอบหมายแล้วกลับมาตรวจ แนวคิดเรื่องกรณีผิดพลาดที่ยังเหลือช่วยเตือนทีมได้ แต่ไม่ควรนำ “ปัญหา 80%” ในเอกสารมาใช้เป็นสัดส่วนคาดการณ์ งานที่ดูเกือบเสร็จอาจยังติดข้อผิดพลาดเรื่องสิทธิ์เพียงจุดเดียว หรือข้อสมมติตรงรอยต่อระบบ อย่าประเมินงานที่เหลือจากความเรียบร้อยของหน้าจอ

เริ่มจากการส่งต่องานหนึ่งชิ้นที่ตรวจได้

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

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

แนวคิดตั้งต้นจากเอกสาร The New SDLC With Vibe Coding ของ Addy Osmani, Shubham Saboo และ Sokratis Kartakis ฉบับพฤษภาคม 2569 ตัวอย่างใบสั่งซื้อ ใบมอบหมาย และวิธีทดลองในบทความเป็นข้อเสนอที่เขียนขึ้นใหม่ ไม่ใช่ผลวิจัยของเอกสาร

อ่านต่อจากผู้เขียนต้นทางเรื่องการวางแผน ตรวจ และรับผิดชอบงาน: Addy Osmani, Agentic Engineering.