จากแชทกลุ่มสู่งานโค้ดที่ตรวจสอบย้อนกลับได้

งานเขียนโค้ดส่วนใหญ่ยังคงเริ่มต้นจากประโยคในแชตกลุ่ม "การ export CSV ตัดแถวสุดท้ายหายไป" "เพิ่ม SSO ก่อน demo ได้ไหม" "Prod โยน 500 กลับมาที่หน้า checkout อีกแล้ว" มีคนกดรีแอ็กชันหัวโป้ง บางทีก็มี coding agent ถูกชี้ไปที่ข้อความนั้น แล้วสามวันต่อมาไม่มีใครตอบได้ว่ามันถูก deploy ไปหรือยัง ใครรีวิว หรือ commit ไหนที่แก้มัน ข้อความเลื่อนหายไป งานกลายเป็นตำนานเล่าต่อกัน

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

บทความนี้จะพาไปดูวิธีเปลี่ยนข้อความในแชตให้เป็นงานเขียนโค้ดที่สืบค้นได้ ตั้งแต่การตั้งแบบ do-it-yourself ล้วน ๆ ว่าให้อะไรคุณได้บ้าง จุดที่มันเริ่ม scale ไม่ไหว และ shared task layer เข้ามาเพิ่มอะไร Sharkly คือ workspace สำหรับเวอร์ชันที่สืบค้นได้ เพราะมันวางอยู่เหนือ coding agent ของคุณ และเก็บเป้าหมาย, run, blockers, diff และการรีวิวของคนไว้ในเรกคอร์ดเดียว คุณมี coding agent อยู่แล้ว หน้าที่คือเปลี่ยนงานของพวกมันให้เป็นสิ่งที่ทีมติดตามได้

ทำไมแชตถึงเป็นที่ตายของงานเขียนโค้ด

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

โหมดความล้มเหลวมันเจาะจงชัด คำขอเข้ามา มีการตกลงกันแบบไม่เป็นทางการในเธรด แล้วเธรดก็ไหลต่อไป สองวันต่อมามีคนถามว่า "เราแก้บั๊ก export นั้นไปหรือยัง" คำตอบต้องอาศัย การค้นหาใน Slack การเดา และการไล่เลื่อนช่องที่วลีเดิมโผล่มาถ้าเก้าครั้ง ถึงคุณหาข้อความเจอ มันก็ไม่บอกว่าการแก้ merge เข้าไปแล้วหรือยัง บทสนทนากับโค้ดอยู่ในระบบคนละที่ที่ไม่เคยรู้จักชื่อกันเลย

ชี้ autonomous coding agent ไปที่ข้อความนั้นแล้วร่องรอยก็สั้นลงอีก agent อ่านบรรทัดใน Slack รันใน terminal บนแล็ปท็อปของใครสักคน แก้ไฟล์ แล้วรายงานกลับเข้าไปในเธรดที่ไหลเร็วเดิมซึ่งกลืนคำขอไปแล้ว ตอนนี้คุณได้ execution log ที่ไม่มีใครเซฟ การเปลี่ยนแปลงที่ไม่มีใครลิงก์ และการตัดสินใจที่ไม่มีใครบันทึก

ไปป์ไลน์แบบ DIY และจุดที่มันเริ่ม scale ไม่ไหว

คุณไม่จำเป็นต้องมีผลิตภัณฑ์เพื่อเริ่มต้น ไปป์ไลน์ do-it-yourself ที่ใช้ได้: คัดลอกข้อความในแชต วางลงใน coding agent เป็น prompt ปล่อยให้มันทำงานใน Git worktree ที่แยกออกมาเพื่อไม่ให้ชนกับ checkout หลักของคุณ แล้วเปิด pull request ที่ลิงก์กลับไปยัง tracking issue ด้วยบรรทัด Closes #123 นั่นคือ traceability จริง ๆ และสำหรับนักพัฒนาคนเดียวที่จัดการทีละคำขอ มันมักเพียงพอแล้ว

นี่คือคู่การตัดสินใจแบบตรงไปตรงมา ถ้าคุณเป็นคนเดียว รัน agent ตัวเดียว ปิดงานหนึ่งก่อนไปงานถัดไป ลูป copy-paste-ไป-worktree ก็ใช้ได้ และคุณไม่ควรเพิ่ม tooling เข้าไป ภาระของระบบที่ใช้ร่วมกันจะแพงกว่าสิ่งที่ได้คืนมา

การตั้งแบบนี้จะเริ่ม scale ไม่ไหวในวินาทีที่สองสิ่งนี้เกิดพร้อมกัน: มี agent รันสองตัว หรือมีคนสองคนจัดเส้นทางงาน หรือมี repository สองที่เกี่ยวข้อง ตอนนั้นไปป์ไลน์แบบ manual จะเริ่มมีรูโหว่:

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

"สืบค้นได้" หมายความว่าอะไรเมื่องานถูกแชร์แล้ว

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

Sharkly มอนเดลสิ่งนี้เป็น Task ซึ่งเป็นหน่วยงานหลักในระบบ Task ไม่ใช่ข้อความในแชตและไม่ใช่ session ใน terminal มันคือเรกคอร์ดที่แชร์กันซึ่งข้อความในแชตกลายเป็น เมื่อคุณตัดสินใจลงมือทำ เป้าหมายอยู่ในคำอธิบาย Agent หรือคนกลายเป็น Assignee การรันของ Agent, blockers, ผลลัพธ์ และการสนทนาติดตามผล ทั้งหมดกลับมาที่ Task timeline แทนที่จะหายไปใน terminal ส่วนตัว เมื่อการเปลี่ยนแปลงลง พูลรีเควสต์ถูกลิงก์ด้วย ID คำขอกับ diff ก็รู้จักชื่อกันเสียที

มีเส้นแบ่งหนึ่งข้อที่สำคัญ เพราะผู้อ่านอาจเข้าใจผิด Sharkly ไม่ใช่ตัวแทนของ Claude Code, Codex หรือ coding agent อื่น ๆ ของคุณ เครื่องมือเหล่านั้นทำงาน execution Sharkly เพิ่มชั้นของ shared task, context และ review เข้าไปรอบ ๆ มัน Agent ยังเขียนโค้ดเอง Sharkly ทำให้งานมอบหมายได้และสืบค้นได้

เปลี่ยนข้อความในแชตให้เป็นงานที่สืบค้นได้ด้วย Sharkly

เวิร์กโฟลว์สั้นพอที่จะเก็บไว้ในหัวได้ เริ่มจากข้อความจริง เช่นบั๊ก export CSV แล้วย้ายมันออกจากช่อง:

1. จับข้อความเป็น Task สร้าง Task โดยใช้คำขอเป็นเป้าหมาย ถ้าแชตของคุณอยู่ใน Slack Slack bot สำหรับ coding agent จะเปลี่ยน mention ให้เป็น Task โดยไม่ต้องออกจากเธรด
2. ปั้นมันให้ Agent รันได้ รายงานบั๊กบรรทัดเดียวไม่ใช่ spec ที่รันได้ เพิ่มขั้นตอนทำซ้ำ พฤติกรรมที่คาดหวัง และเกณฑ์ยอมรับ วินัยเดียวกับการจัดการงานของ AI agent: Task ที่ Agent ปิดได้ต้องมีคำอธิบายที่ Agent ลงมือทำได้
3. มอบหมายและปล่อยให้ Agent รัน Agent เคลม Task ทำงานใน worktree ที่แยกออกมาเพื่อให้งานขนานไม่ชนกัน และสตรีมความคืบหน้ากลับมาที่ Task คุณกำลังดูเรกคอร์ด ไม่ใช่ terminal
4. รีวิวและยอมรับ Agent แนบสรุปการเปลี่ยนแปลง ผลการทดสอบ และข้อจำกัดที่รู้ Aคนยอมรับ ขอแก้ หรือตัดสินใจ merge

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

คุณสร้างเวอร์ชันนี้ด้วยมือได้ด้วย issue กับ worktree หรือใช้ Sharkly จัดการเวิร์กโฟลว์เพื่อให้ร่องรอยยังอยู่ครบเมื่อปริมาณงานพุ่งขึ้น

เช็กลิสต์ที่รันได้วันนี้เลย

ลองรันกับ setup ปัจจุบันของคุณ กล่องที่ยังไม่ติ๊กแต่ละอันคือจุดที่งานที่กำเนิดจากแชตอาจสืบค้นไม่ได้:

• [ ] ทุกคำขอในแชตที่ลงมือทำกลายเป็น Task ที่มีเจ้าของ ไม่ใช่รีแอ็กชันอีโมจิ
• [ ] แต่ละ Task มีคำอธิบายที่ Agent รันได้: ขั้นตอนทำซ้ำ พฤติกรรมที่คาดหวัง เกณฑ์ยอมรับ
• [ ] แต่ละ Agent ที่รันทำงานใน worktree ที่แยกออกมา เพื่อให้สองงานไม่แตะไฟล์เดียวกัน
• [ ] run log, blockers และผลลัพธ์ของ Agent กลับมาที่ Task ไม่ใช่ terminal ที่ปิดไป
• [ ] pull request ถูกลิงก์กับ Task ด้วย ID คำขอกับ diff จึงห่างกันแค่คลิกเดียว
• [ ] คนยอมรับหรือปฏิเสธผลลัพธ์ และการตัดสินใจนั้นถูกบันทึกบน Task
• [ ] คุณตอบได้ว่า "อันนี้เสร็จหรือยัง ใครทำ และ diff อยู่ไหน" โดยไม่ต้องค้นหาในแชต

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

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

ต้องมี Sharkly ไหมถึงจะทำงานที่กำเนิดจากแชตให้สืบค้นได้? ไม่ นักพัฒนาคนเดียวที่รัน agent ตัวเดียวได้ traceability จริงจาก worktree บวก pull request ที่ลิงก์ไปยัง issue แพตเทิร์นAI agent inboxจะเริ่มคุ้มค่าก็ต่อเมื่อคุณมี agent หรือคนหลายคน และลิงก์แบบ manual เริ่มพลาด

อะไรทำให้ข้อความในแชตเป็นงานที่ coding agent รันได้ยาก? มักจะขาดขั้นตอนทำซ้ำ ผลลัพธ์ที่คาดหวัง และเกณฑ์ยอมรับ เปลี่ยน "export พัง" ให้เป็น "export CSV ตัดแถวสุดท้ายหายไป คาดหวัง N แถว ได้ N-1 แก้เมื่อจำนวนตรงกัน" ตอนนี้ Agent มีอะไรให้ปิดงานได้แล้ว

ต่างจากระบบ ticketing ปกติยังไง? ตั๋วใช้ติดตามงานที่คนจะทำ งานเขียนโค้ดที่สืบค้นได้ยังมี execution log ของ Agent การรันที่แยกออกมา และ diff ที่ลิงก์ไว้ เรกคอร์ดจึงครอบคลุมทั้งการตัดสินใจและการเปลี่ยนแปลง ดูhuman-in-the-loop coding agentsสำหรับจุดที่คนยังอยู่ในลูป

Sharkly อ่านช่อง Slack ของฉันได้โดยตรงไหม? คุณต่อ Sharkly Agent เข้ากับ Slack เพื่อให้ mention กลายเป็น Task บทสนทนายังอยู่ใน Slack ส่วนเรกคอร์ดงานที่สืบค้นได้อยู่ใน Sharkly