วิธีติดตามงานที่ AI Coding Agents ทำเสร็จ

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

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

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

สรุปสั้น

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

การติดตามงานที่เสร็จแล้วหมายถึงอะไร

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

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

เอเจนต์ที่จบเงียบๆ นั้น technically ทำงานเสร็จแล้ว แต่คุณลงมือทำอะไรกับมันไม่ได้ สถานะเสร็จที่คุณสนใจคือสถานะที่คนตรวจสอบและรับได้ นั่นคือเหตุผลที่ "เทสต์ผ่าน" ไม่เหมือนกับ "งานถูกติดตามแล้ว"

โมเดล human-in-the-loop สำหรับเอเจนต์เขียนโค้ด ลากเส้นแบ่งไว้ชัดเจน: เอเจนต์ค้นคว้า ลงมือทำ ทดสอบ และรายงาน ส่วนคนกำหนดทิศทางและรับผลลัพธ์ การติดตามคือกลไกที่ทำให้ครึ่งหลังนี้เกิดขึ้นได้

การตั้งค่าแบบทำเอง ทีละขั้น และแต่ละขั้นพังตรงไหน

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

ขั้นที่ 1: ดูว่าเปลี่ยนอะไรไป หลังการรัน คุณอ่านดิฟ

git log --oneline -10
git diff main...HEAD --stat

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

ขั้นที่ 2: แยกงานของแต่ละเอเจนต์ออกจากกัน คุณให้เอเจนต์แต่ละตัวมี git worktree ของตัวเองเพื่อไม่ให้ชนกัน

git worktree add ../auth-refactor -b auth-refactor
git worktree list

พังเมื่อ: รายการยาวเกินกว่าที่คุณจะจำไหว git worktree list บอกแค่พาธ ไม่ได้บอกว่าเอเจนต์ตัวไหนอยู่ในอันไหน มันรับใช้ task ใด หรือเสร็จหรือยัง ดูเอกสาร git-worktree อย่างเป็นทางการ สำหรับกลไกการทำงาน แต่เอกสารก็หยุดแค่การทำบัญชีรายการเท่านั้น

ขั้นที่ 3: ตรวจว่าผลลัพธ์ไปถึง PR แล้ว คุณพึ่ง GitHub

gh pr list --author "@me" --state open
gh pr view 214 --json title,statusCheckRollup

พังเมื่อ: PR มีอยู่แต่ไม่มีใครเขียนว่าทำไม หรือเช็คเป็นสีเขียวทั้งที่การเปลี่ยนแปลงผิด หรือ PR ไม่มีลิงก์กลับไปหาคำขอที่จุดมันขึ้นมา เอกสารอ้างอิง gh pr list แสดง PR ที่เปิดอยู่ ไม่ได้แสดงเจตนา

ขั้นที่ 4: จำว่าคุณสั่งอะไรไป ขั้นนี้ไม่มีคำสั่งใดๆ ข้อกำหนดต้นทางอยู่ในข้อความ Slack ในโน้ต หรือในความจำของคุณ พอคุณรีวิว PR สามวันให้หลัง คุณก็ได้แต่เดาเกณฑ์การยอมรับ

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

การตั้งค่าแบบทำเองเริ่มขยายไม่ได้ตรงไหน

จุดแตกหักไม่ใช่ชั่วขณะหนึ่ง แต่มันคือความชัน และคุณระบุได้ว่าตอนนี้อยู่ตรงไหนของมัน

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

บอร์ดงานเข้ามาเพิ่มอะไร

ทางแก้คือเลิกมองการรันที่จบแล้วเป็นดิฟ แล้วเริ่มมองมันเป็นสิ่งที่ไหลกลับมาหา task

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

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

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

คุณสามารถดาวน์โหลด Sharkly และเชื่อมต่อ Computer เครื่องหนึ่งเพื่อลองใช้กับ task จริงสักหนึ่งงานก่อนจะขยายผล

เมื่อคุณไม่จำเป็นต้องใช้สิ่งเหล่านี้เลย

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

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

เช็กลิสต์ที่คุณลองทำได้วันนี้

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

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

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

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

ฉันจะติดตามได้ยังไงว่าเอเจนต์เขียนโค้ด AI เปลี่ยนอะไรไป? อ่านดิฟ ไม่ใช่สรุปของเอเจนต์ สำหรับเอเจนต์ตัวเดียว git diff กับ PR ก็พอ สำหรับหลายตัว ให้เก็บการรันแต่ละครั้งไว้ในเวิร์กทรีของตัวเอง แล้วส่งดิฟพร้อมสรุปการตรวจสอบกลับไปที่ task ร่วม เพื่อที่คุณจะได้ไม่ต้อง reconstruct มันจาก scrollback

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

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

บอร์ดงานทำให้เอเจนต์ที่เคลื่อนไหวเร็วช้าลงไหม? ไม่ เอเจนต์ยังรันในเวิร์กทรีที่แยกออกมาด้วยความเร็วเต็มที่ บอร์ดเพิ่มเส้นทางไหลกลับเพื่อให้งานที่เสร็จแล้วไปลงที่ที่คุณรีวิวได้ ซึ่งเป็นการตัดขั้นตอนการ reconstruct ด้วยมือออกไป ไม่ใช่เพิ่มเข้ามา