มอบ Issue ให้ Agent ทำแทน แล้ว Pull Request กลับมาไวแค่ไหนในทางปฏิบัติ

ทีมพัฒนาส่วนใหญ่มี Issue ค้างอยู่ในคิวเสมอ บางอันเป็นบั๊กเล็ก ๆ ที่รู้อาการชัดแต่ไม่มีใครว่างไปแก้ บางอันเป็นงานเสริมที่ไม่ได้เร่งด่วนพอจะแซงคิวงานหลัก สุดท้าย Issue เหล่านี้ก็ค้างอยู่แบบนั้นเป็นเดือน ๆ จนกลายเป็นหนี้ทางเทคนิคที่กองสูงขึ้นเรื่อย ๆ

GitHub Copilot Coding Agent ถูกออกแบบมาเพื่อรับมือปัญหานี้โดยเฉพาะ แทนที่จะต้องรอให้คนในทีมว่างมาหยิบ Issue ขึ้นมาทำ หัวหน้าทีมหรือเจ้าของ Repository สามารถกด Assign Issue นั้นให้ Copilot รับไปทำแทนได้เลย โดย Agent จะไปทำงานอยู่ในสภาพแวดล้อมแยกต่างหากบนคลาวด์ ไม่ใช่เครื่องของใครคนใดคนหนึ่ง แล้วกลับมารายงานผลเป็น Pull Request เมื่อเสร็จ

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

วงจรการทำงานตั้งแต่รับ Issue จนถึงเปิด Pull Request

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

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

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

มอบหมายงานให้ Coding Agent ทำในทางปฏิบัติทำยังไง

การเริ่มใช้ Coding Agent ไม่ซับซ้อนในทางเทคนิค แต่ผลลัพธ์ที่ได้ขึ้นอยู่กับคุณภาพของ Issue ที่มอบหมายไปเป็นหลัก ทีมที่เริ่มใช้ควรทำตามลำดับต่อไปนี้เพื่อให้ได้ผลลัพธ์ที่ใช้งานได้จริงตั้งแต่รอบแรก ๆ:

1. เปิด Issue อธิบายปัญหาหรืองานที่ต้องการให้ชัดเจนที่สุดเท่าที่จะทำได้ ระบุอาการ ไฟล์ที่คาดว่าเกี่ยวข้อง และผลลัพธ์ที่ต้องการเห็นหลังแก้เสร็จ
2. กำหนดขอบเขตของงานให้แคบพอที่จะทำเสร็จในรอบเดียว เช่น แก้บั๊กหนึ่งจุด แทนที่จะเป็นงานใหญ่ที่ต้องเปลี่ยนสถาปัตยกรรมทั้งระบบ
3. กดมอบหมาย Issue นั้นให้ Copilot เป็นผู้รับผิดชอบ เหมือนกับการ Assign งานให้สมาชิกในทีมคนหนึ่ง
4. รอให้ Agent ทำงานในเบื้องหลัง ระหว่างนี้สามารถไปทำงานอื่นต่อได้เลยโดยไม่ต้องเปิดหน้าจอรอ
5. เมื่อ Pull Request ถูกเปิดกลับมา อ่าน diff และคำอธิบายที่ Agent เขียนไว้อย่างละเอียดก่อนตัดสินใจอนุมัติหรือขอให้แก้เพิ่ม

เขียน Issue แบบไหนที่ทำให้ Agent ทำงานได้แม่นกว่า

คุณภาพของ Issue ส่งผลต่อผลลัพธ์มากกว่าที่หลายคนคิด เพราะ Agent ไม่มีบริบทอื่นนอกจากสิ่งที่เขียนไว้ในหัวข้อและรายละเอียดของ Issue บวกกับสิ่งที่มันสำรวจเจอเองในโค้ด ยิ่งข้อมูลตั้งต้นครบ ยิ่งลดโอกาสที่มันจะเข้าใจผิดทิศทาง

• ระบุอาการที่สังเกตได้จริง — บอกว่าเกิดอะไรขึ้นและควรเป็นอะไรแทน แทนที่จะเขียนแค่ 'แก้หน้านี้ให้หน่อย' แบบกว้าง ๆ
• ชี้ไฟล์หรือฟังก์ชันที่เกี่ยวข้องถ้ารู้อยู่แล้ว — ช่วยลดเวลาที่ Agent ต้องเสียไปกับการสำรวจหาเอง
• บอกเงื่อนไขที่ห้ามเปลี่ยน — เช่นห้ามแก้ชื่อฟังก์ชันที่ระบบอื่นเรียกใช้อยู่ หรือห้ามเปลี่ยน API ที่ทีมอื่นพึ่งพา
• แนบตัวอย่างพฤติกรรมที่ถูกต้อง — ถ้ามี Input และ Output ตัวอย่างที่ควรได้ ให้ใส่ไว้ใน Issue เพื่อให้ Agent ตรวจสอบตัวเองได้ระหว่างทำงาน

Agent มองเห็นอะไรบ้างก่อนเริ่มเขียนโค้ดจริง

หลายคนสงสัยว่า Agent รู้ได้ยังไงว่าโปรเจกต์นี้มีข้อกำหนดเฉพาะอะไรบ้าง คำตอบคือมันจะอ่านทั้งเนื้อหาของ Issue โครงสร้างไฟล์ทั้งหมดใน Repository และไฟล์ Custom Instructions ถ้ามีการตั้งค่าไว้ ไฟล์นี้ทำหน้าที่เหมือนคู่มือย่อที่บอกกฎเฉพาะของทีม เช่น ใช้ Library ตัวไหนสำหรับจัดการ State ตั้งชื่อ Component แบบไหน หรือมีรูปแบบการเขียนเทสต์แบบไหนที่ทีมยึดถือ

นอกจากนั้น Agent ยังอ่านประวัติ Commit และ Pull Request ก่อนหน้าในโปรเจกต์เดียวกันเพื่อเรียนรู้สไตล์การเขียนโค้ดที่ทีมใช้จริง ไม่ใช่แค่เขียนโค้ดที่ถูกต้องตามหลักทั่วไปแต่ไม่เข้ากับโปรเจกต์ เช่น ถ้าทีมมีรูปแบบการเขียน Error Handling แบบเฉพาะที่ใช้ซ้ำอยู่ทุกไฟล์ Agent ก็มีแนวโน้มเขียนตามรูปแบบเดิมนั้นแทนที่จะคิดวิธีใหม่ขึ้นมาเอง

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

จุดตรวจสอบก่อนที่ Pull Request จะไปถึงมือคนจริง

แม้ Agent จะรันเทสต์ที่มีอยู่แล้วในโปรเจกต์ระหว่างทำงาน แต่นั่นไม่ได้แปลว่า Pull Request ที่ได้กลับมาพร้อม Merge ทันที เพราะเทสต์ที่ผ่านบอกได้แค่ว่าโค้ดไม่ทำให้พฤติกรรมเดิมที่เคยเขียนเทสต์ไว้พัง แต่ไม่ได้รับประกันว่าตรรกะทางธุรกิจที่ Issue ต้องการนั้นถูกต้องครบถ้วนตามที่ตั้งใจไว้จริง ๆ

ทีมที่ใช้งานจริงควรมีจุดตรวจสอบอย่างน้อยสามชั้นก่อน Merge คือ อ่าน diff ทั้งหมดเพื่อดูว่าตรรกะที่เขียนสมเหตุสมผลไหม ทดลองรันโค้ดในสภาพแวดล้อมทดสอบเพื่อดูพฤติกรรมจริงไม่ใช่แค่อ่านโค้ดเฉย ๆ และตรวจสอบว่ามีการแก้ไฟล์ที่ไม่เกี่ยวข้องกับ Issue โดยไม่จำเป็นหรือเปล่า เพราะบางครั้ง Agent อาจแก้ไฟล์เกินขอบเขตที่ตั้งใจไว้โดยไม่รู้ตัว

อีกจุดที่ควรสังเกตคือคำอธิบายที่ Agent เขียนไว้ใน Pull Request เอง ถ้าคำอธิบายนั้นดูกำกวมหรือไม่มั่นใจในบางจุด เช่นเขียนว่าไม่แน่ใจว่าการแก้แบบนี้ครอบคลุมทุกกรณีหรือไม่ นั่นเป็นสัญญาณให้คนรีวิวต้องดูจุดนั้นอย่างละเอียดเป็นพิเศษ แทนที่จะอ่านผ่าน ๆ แล้วกดอนุมัติตามความเคยชิน

งานแบบไหนควรมอบให้ Coding Agent และแบบไหนควรให้คนทำเอง

ไม่ใช่ทุกงานที่เหมาะกับการมอบหมายให้ Agent ทำแบบเบื้องหลัง ตารางนี้ช่วยแยกให้เห็นภาพชัดขึ้นว่างานแบบไหนเหมาะและไม่เหมาะ:

ข้อจำกัดที่ต้องรู้ก่อนปล่อยงานให้ทำแบบเต็มรูปแบบ

Coding Agent เก่งเรื่องงานที่นิยามชัดเจนและมีตัวอย่างให้อ้างอิง แต่ยังมีจุดที่พลาดได้บ่อยเช่นกัน จุดหนึ่งคือการตีความ Issue ที่เขียนกำกวมผิดทาง เช่น Issue เขียนว่า 'ปรับให้เร็วขึ้น' โดยไม่บอกว่าเร็วขึ้นในแง่ไหน Agent อาจไปแก้จุดที่ไม่ใช่คอขวดจริง เพราะไม่มีข้อมูลเพียงพอจะรู้ว่าปัญหาจริงอยู่ตรงไหน

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

สุดท้ายคือข้อจำกัดเรื่องการเข้าถึงระบบภายนอก บาง Repository มีการเชื่อมต่อกับบริการภายนอกที่ต้องใช้ Credential เฉพาะ ซึ่ง Agent อาจไม่มีสิทธิ์เข้าถึงในสภาพแวดล้อมแยกที่มันทำงานอยู่ ทำให้บางงานที่ต้องทดสอบกับระบบภายนอกจริง ยังต้องให้คนเป็นคนทำหรือทดสอบเพิ่มเติมหลังจาก Agent ส่ง Pull Request กลับมาแล้ว

Workflow ของทีมเปลี่ยนไปยังไงเมื่อ Agent กลายเป็นผู้ร่วมงานอีกคน

ทีมที่เริ่มใช้ Coding Agent จริงจังมักพบว่าบทบาทของ Issue Backlog เปลี่ยนไป จากเดิมที่เป็นแค่รายการงานค้างรอคนว่าง กลายเป็นแหล่งงานที่แจกจ่ายให้ทั้งคนและ Agent พร้อมกันได้ Product Owner หรือหัวหน้าทีมจึงต้องคิดตั้งแต่ตอนเขียน Issue ว่างานชิ้นนี้เหมาะจะมอบให้ Agent ทำ หรือควรเก็บไว้ให้คนในทีมทำเอง

การเปลี่ยนแปลงนี้ยังส่งผลต่อจังหวะการรีวิว เพราะ Pull Request จาก Agent อาจเข้ามาหลายอันพร้อมกันในเวลาไล่เลี่ยกัน หากทีมไม่วางแผนเรื่องกำลังคนที่จะรีวิวไว้ล่วงหน้า Pull Request เหล่านี้อาจกองค้างรอนานพอ ๆ กับตอนที่ Issue ยังไม่ได้มอบหมายให้ใคร ซึ่งทำให้เสียประโยชน์ของความเร็วที่ Agent ควรจะช่วยให้ได้

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

ข้อผิดพลาดที่ทีมมักเจอตอนเริ่มใช้ Coding Agent

• มอบหมาย Issue ที่เขียนกำกวมเกินไป แล้วผิดหวังที่ผลลัพธ์ไม่ตรงเป้า ทั้งที่ต้นเหตุคือข้อมูลตั้งต้นไม่พอ
• ปล่อย Pull Request จาก Agent ค้างไว้นานเกินไปโดยไม่รีวิว ทำให้เสียประโยชน์ของความเร็วที่ควรได้
• มอบหมายงานเชิงสถาปัตยกรรมใหญ่ให้ Agent ทำทั้งชุดในครั้งเดียว แทนที่จะแบ่งเป็นงานย่อยที่ขอบเขตชัดเจน
• ไม่ตั้งค่า Custom Instructions ทั้งที่มีกฎเฉพาะของทีมอยู่แล้ว ทำให้ Agent ต้องเดาสไตล์การเขียนโค้ดเอาเองทุกครั้ง
• เข้าใจผิดว่าเทสต์ผ่านแปลว่า Pull Request ถูกต้องสมบูรณ์แล้ว ทั้งที่ยังต้องตรวจตรรกะทางธุรกิจด้วยคนอยู่ดี

สรุป

Coding Agent เปลี่ยนวิธีที่ทีมจัดการ Issue ค้างในคิว จากรอคนว่างมาทำ กลายเป็นมอบหมายให้ Agent รับไปทำแบบเบื้องหลังได้ ตราบใดที่ Issue นั้นเขียนขอบเขตชัดเจนพอ ตั้งแต่รับงาน วางแผน เขียนโค้ด รันเทสต์ ไปจนถึงเปิด Pull Request กลับมาให้คนรีวิว

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

• Coding Agent ทำงานในสภาพแวดล้อมคลาวด์แยกต่างหาก อ่าน Issue แล้วส่งกลับมาเป็น Pull Request ให้คนรีวิว
• ยิ่ง Issue เขียนขอบเขตและอาการชัดเจนแค่ไหน ผลลัพธ์ที่ได้ยิ่งตรงเป้ามากขึ้นเท่านั้น
• งานตัดสินใจเชิงสถาปัตยกรรมใหญ่หรือกระทบระบบชำระเงินโดยตรง ยังควรให้คนเป็นคนตัดสินใจหลัก

คำถามที่พบบ่อย