คุณเริ่มต้นด้วยเทอร์มินัลหนึ่งหน้าต่างกับ Claude Code จากนั้นมีงานชิ้นที่สองเข้ามา คุณก็เปิดเทอร์มินัลอีกหน้าต่างแล้วสั่ง Codex ทำงานนั้น งานแก้ฝั่งฟรอนต์เอนด์ก็โยนไปที่หน้าต่างที่สาม ตอนนี้คุณกำลังสลับหน้าต่างไปมาระหว่างสามหน้าต่าง พยายามจำว่าอันไหนกำลังรอคุณอยู่ อันไหนถามคำถามเมื่อสิบนาทีที่แล้ว และอันไหนเงียบ ๆ ทำงานเสร็จแล้วนั่งว่างอยู่ mentre คุณเผาความสนใจไปกับอีกสองอันที่เหลือ ไม่มีอะไรลุกเป็นไฟ แต่คุณได้กลายเป็นตัวกลางที่คอยจัดสรรงานระหว่างเอเจนต์เหล่านั้นไปแล้ว และงานนี้ก็สเกลได้แย่กว่าพวกมันทุกตัว
ต้นทุนไม่ใช่ตัวเทอร์มินัล แต่เป็นตัวคุณ เมื่อรันเอเจนต์ด้วยมือ ทุกการตัดสินใจว่าอะไรจะเกิดขึ้นต่อไปนั้นอยู่ที่เดียว คือในหัวของคุณ เอเจนต์ตัวไหนจะได้งานถัดไป diff ล่าสุดปลอดภัยไหม อะไรพังระหว่างที่คุณกำลังอ่านหน้าต่างอื่น การประสานงานทั้งหมดนี้คืองานจริง เป็นงานที่ไม่ได้รับค่าจ้าง และมันโตเร็วกว่าจำนวนเอเจนต์ที่คุณเพิ่มเข้าไป
บทความนี้จะแยกให้เห็นว่าการรันเอเจนต์เขียนโค้ดด้วยมือนั้นมีต้นทุนจริงเท่าไร บิลซ่อนอยู่ตรงไหนจนกว่ามันจะทบต้นทบดอก และมีเวิร์กโฟลว์แบบไหนที่กำจัดมันได้เกือบหมด Sharkly คือเลเยอร์การจัดการที่วางอยู่เหนือเอเจนต์ของคุณ คุณยังใช้ Claude Code, Codex หรือรันไทม์ตัวไหนก็ตามที่ใช้อยู่ และ Sharkly จะเก็บงาน การแยกสภาพแวดล้อม และการรีวิวไว้ในที่เดียวกัน แทนที่จะกระจายอยู่ทั่วกำแพงเทอร์มินัล
สรุปสั้น ๆ
การรันเอเจนต์เขียนโค้ดด้วยมือดูเหมือนฟรี เพราะไม่มีเครื่องมือไหนคิดเงินตรงนั้น ต้นทุนจริงคือความสนใจของคุณ คุณกลายเป็นตัวกลางจัดเส้นทางระหว่างเอเจนต์ เป็นหน่วยความจำว่าตัวไหนกำลังทำอะไร และเป็นคนรีวิวคนเดียวที่ต้องตามทุกหน้าต่างให้ทัน ต้นทุนนี้ยังน้อยอยู่ที่เอเจนต์สองสามตัว และจะทบต้นทบดอกเมื่อเกินห้าตัว คุณจะทำด้วยมือต่อไปก็ได้ หรือจะจัดเส้นทางเอเจนต์ที่มีอยู่ผ่านเลเยอร์งานอย่าง Sharkly ที่มอบหมายงาน แยกการรันแต่ละครั้ง และส่งผลลัพธ์ทุกอย่างกลับมาที่ Task เพื่อรีวิว
ปัญหไม่ใช่เทอร์มินัล แต่เป็นตัวคุณ
มีคำนิยามหนึ่งที่ควรจำไว้: เทอร์มินัลคือที่ที่เอเจนต์รัน ส่วนงาน (task) คือสิ่งที่มันรัน เมื่อคุณจัดการเอเจนต์ด้วยมือ ไม่มีอะไรเชื่อมสองสิ่งนี้เข้าด้วยกันนอกจากตัวคุณ เทอร์มินัลแสดงผลลัพธ์ แต่มันไม่รู้ว่างานคืออะไร เสร็จหรือยัง หรือใครตัดสินใจว่าอะไรจะเกิดขึ้นต่อไป คุณต้องป้อนข้อมูลทั้งหมดนี้จากความจำ ทีละหน้าต่าง
นั่นคือเหตุผลที่ "เทอร์มินัลเยอะเกินไป" เป็นอาการ ไม่ใช่ตัวโรค การแยกเอเจนต์ตัวเดียวออกเป็นห้า pane ด้วย tmux ไม่ได้ลดการประสานงานลง มีแค่จัดเรียงมันใหม่ คุณยังต้องถือแผนที่ว่า pane ไหนเป็นเจ้าของงานไหน อันไหนกำลังรันอยู่ และอันไหนเสร็จแล้วรอคนมาดู แผนที่นี้ไม่ได้อยู่ที่ไหนที่แชร์ได้ พอคุณลุกไปมันก็ล้าสมัยทันที และพอเพื่อนร่วมทีมต้องการมัน มันก็ไม่มีอยู่จริง
การรันเอเจนต์ด้วยมือมีต้นทุนจริงเท่าไร
บิลถูกจ่ายด้วยความสนใจ และความสนใจมีราคาที่วัดได้ เมื่อคุณสลับไปมาระหว่างงานที่ไม่เกี่ยวข้องกัน คุณไม่ได้กลับเข้าที่ทันที งานวิจัยเกี่ยวกับงานความรู้ที่ถูกขัดจังหวะโดย Gloria Mark และเพื่อนร่วมงาน ตีพิมพ์ที่ CHI 2008 พบว่าคนเราใช้เวลาเฉลี่ยมากกว่ายี่สิบนาทีในการกลับไปทำงานที่ถูกขัดจังหวะ หลังถูกดึงตัวออกไป ส่วนสรุปงานวิจัยเรื่องการสลับงานของ American Psychological Association ระบุว่าการสูญเสีย productivity จากการสลับงานสูงถึง 40 เปอร์เซ็นต์ ทุกครั้งที่เอเจนต์ทำงานเสร็จแล้วคุณหันไปหน้าต่างอื่น คุณต้องจ่ายภาษีแบบนี้ไม่รูปแบบใดก็รูปแบบหนึ่ง
การรันเอเจนต์ด้วยมือทำให้การสลับนั้นกลายเป็นลูปหลักของคุณ นี่คือจุดที่ต้นทุนสะสม:
| ต้นทุนที่ซ่อนอยู่ | หน้าตาเป็นอย่างไรเมื่อทำด้วยมือ | ทำไมมันจึงทบต้นทบดอก |
|---|---|---|
| การจัดเส้นทาง | คุณตัดสินใจเองว่าเอเจนต์ตัวไหนได้งานใหม่แต่ละชิ้น จากความจำ | ยิ่งเอเจนต์เยอะ ยิ่งมีคู่จับให้ต้องจำไว้ในหัวมากขึ้น |
| การโหลดบริบทใหม่ | คุณอ่านเทอร์มินัลแต่ละอันซ้ำเพื่อจำว่ามันกำลังทำอะไร | ทุกการสลับเป็นการรีเซ็ตนาฬิกาในการกลับเข้าสู่งานนั้น |
| สถานะคลาดเคลื่อน | แต่ละเทอร์มินัลมี branch, env และการแก้โค้ดครึ่ง ๆ กลาง ๆ ของตัวเอง | สองงานในไดเรกทอรีเดียวนั้นทำลายกันเงียบ ๆ |
| งานรีวิวค้างสะสม | คุณเป็นคนเดียวที่เห็นการรันแต่ละครั้งเกิดขึ้น | งานที่เสร็จแล้วต้องรอคนคนเดียวที่รีวิวได้ |
| ไม่มีบันทึกที่แชร์ได้ | สถานะอยู่ใน session ของคุณ ไม่ได้อยู่ที่ไหนที่เพื่อนร่วมทีมเห็น | พอคุณลุกไป ความคืบหน้าก็ล่องหน ไม่มีใครรับช่วงต่อได้ |
ไม่มีข้อไหนโผล่มาในรูปของระบบแครช มันโผล่มาในรูปของวันที่รู้สึกยุ่งทั้งวันแต่ได้ PR ที่ merge แล้วแค่สามอัน แทนที่จะเป็นแปดอัน โดยไม่มีช่วงเวลาไหนที่คุณชี้ได้ว่าเป็นตัวปัญหา
โหมดความล้มเหลวซ่อนตัวจนกว่าจะทบต้นทบดอก
ที่เอเจนต์สองตัว คุณถือแผนที่ทั้งหมดในหน่วยความจำทำงานได้ และต้นทุนก็เกือบเป็นศูนย์ เรื่องนี้ควรพูดตรง ๆ เพราะเป็นจุดที่คำแนะนำส่วนใหญ่ขายปัญหาเกินจริง: ถ้าคุณรันเอเจนต์หนึ่งหรือสองตัวบนเครื่องเดียว และรีวิวแต่ละตัวก่อนเริ่มตัวถัดไป คุณยังไม่ต้องมีเลเยอร์การจัดการ ให้จำนวนชิ้นส่วนที่ขยับได้เป็นศูนย์ไว้ก่อน
สมการจะเปลี่ยนเมื่องานทับซ้อนกันในเวลา หรือทับซ้อนกันในสถานะ รันสามเอเจนต์ใน checkout เดียวกันแล้วคุณจะเจอปัญหาการแยกสภาพแวดล้อมที่พูดถึงใน เอเจนต์เขียนโค้ดหลายตัวใน repo เดียวกัน: เอเจนต์สองตัวแตะไฟล์เดียวกัน แล้วตัวหนึ่งเขียนทับอีกตัวเงียบ ๆ แก้ด้วย worktree ต่อหนึ่งงาน ตามวินัยใน worktree ของเอเจนต์เขียนโค้ด แล้วคุณก็แลกปัญหาการ merge กับปัญหาการทำบัญชี: ไดเรกทอรีไหนคืองานไหน อันไหนลบได้ปลอดภัย อันไหนคนกำลังรีวิวอยู่ แก้ด้วยการเปิดเทอร์มินัลเพิ่ม你又กลับไปที่จุดเริ่มต้น มีแค่หน้าต่างเยอะขึ้น
ต้นทุนสุดท้ายคืออันที่เงียบงัน เมื่อทุกการรันเกิดขึ้นในเทอร์มินัลส่วนตัว งานที่เสร็จแล้วก็ไม่มีที่ไปนอกจากความสนใจของคุณ การรีวิวกลายเป็นคอขวด เพราะคุณเป็นคนเดียวที่ดูเอเจนต์ทำงาน และคนเดียวที่บอกได้ว่า diff ดีหรือไม่ เอเจนต์แบบขนานไม่ช่วยอะไรถ้าการรีวิวผลลัพธ์ต้องรอคนคนเดียว นั่นคือกับดักที่อธิบายไว้ใน ทำไมเอเจนต์เขียนโค้ดที่ดีที่สุดจึงสำคัญน้อยกว่าวิธีที่คุณจัดการมัน: โมเดลเร็วขึ้น แต่คิวรีวิวของคุณไม่ได้เร็วขึ้น
เลเยอร์การจัดการกำจัดอะไรออกไป
บอร์ดงานกำจัดส่วนที่คุณเคยทำด้วยมือออกไป นั่นคือการเป็นเนื้อเยื่อเชื่อมระหว่างเอเจนต์กับงาน ใน Sharkly Task คือหน่วยที่เป็นเจ้าของการรัน คุณมอบหมาย Task ให้กับ Agent แล้ว Sharkly จะเตรียม worktree ที่แยกออกมาให้บน Computer ที่เชื่อมต่อไว้ รัน session ของเอเจนต์ตรงนั้น แล้วส่ง diff, log และตัวบล็อกใด ๆ กลับมาที่ Task นั้น การจัดเส้นทาง การแยกสภาพแวดล้อม และบันทึกที่คุณเคยถือไว้ในหัว กลายเป็นคุณสมบัติของ Task แทน

นั่นทำให้การแบ่งงานสะอาด เอเจนต์ค้นคว้า ลงมือ ทำการทดสอบ และรายงานผล คนเป็นคนกำหนดทิศทาง ให้อำนาจ และรับผลลัพธ์ Sharkly ไม่ใช่ตัวแทนของ Claude Code, Codex หรือรันไทม์ที่คุณใช้อยู่ พวกนั้นเป็นตัวลงมือทำ Sharkly เพิ่ม Task ที่แชร์กันได้, Computer ที่เชื่อมต่อ และเลเยอร์การรีวิวเข้าไปรอบ ๆ เพื่อให้บริบท ความคืบหน้า อุปสรรค ผลลัพธ์ และการรีวิวโดยมนุษย์มองเห็นได้ตลอดตั้งแต่คำขอจนถึงการปล่อย แทนที่จะกระจัดกระจายอยู่ในห้า session ที่มีแค่คุณเห็น เมื่อคุณต้องดูการรันหลายตัวพร้อมกัน นั่นแหละคือสิ่งที่ แดชบอร์ดเอเจนต์มีไว้จริง ๆ และเป็นเหตุผลที่ทีมสุดท้ายอยากได้เลเยอร์ที่อยู่เหนือ Claude Code และ Codex มากกว่าเทอร์มินัลอีกหน้าต่าง
ถ้าคุณรันเอเจนต์หลายตัวอยู่แล้ว นั่นคือเวิร์กโฟลว์ที่ Sharkly สร้างขึ้นมารองรับ คุณจะจัดเส้นทางด้วยมือข้ามเทอร์มินัลต่อไปก็ได้ หรือจะรันเอเจนต์เขียนโค้ดที่มีอยู่ผ่าน Sharkly แล้วให้บอร์ดถือแผนที่แทน
เมื่อไหร่ที่ทำด้วยมือก็โอเค และเมื่อไหร่ที่ไม่ใช่
เกณฑ์ตัดสินใจแบบตรงไปตรงมานั้นสั้น:
- รันเอเจนต์ด้วยมือเมื่อ คุณมีหนึ่งหรือสองตัว บนเครื่องเดียว และคุณรีวิวแต่ละตัวก่อนเริ่มตัวถัดไป ต้นทุน overhead ของเครื่องมือใด ๆ ยังไม่คุ้ม
- เปลี่ยนไปใช้เลเยอร์งานเมื่อ เอเจนต์ตัวที่สามโผล่มา งานข้ามมากกว่าหนึ่ง repository หรือมีคนอื่นนอกจากคุณที่ต้องเห็นว่ากำลังรันอะไรอยู่ นั่นคือจุดที่ต้นทุนการประสานงานเริ่มเกินความจุสมองคนเดียว
สัญญาณไม่ใช่จำนวนเทอร์มินัล แต่มันคือช่วงเวลาที่คุณเผลอถามตัวเองว่า "เดี๋ยวนะ นั่นมันหน้าต่างไหน?" คำถามนั้นคือภาษีการประสานงานที่โผล่มาเป็นประโยค และมันคือความโกลาหลของเอเจนต์แบบเดียวกับที่บอร์ดงานถูกสร้างขึ้นมาเพื่อยุติ
คำถามที่พบบ่อย
tmux หรือ terminal multiplexer นี่พอไหม? มันจัดเรียงหน้าต่าง แต่ไม่ได้กำจัดการประสานงานออกไป คุณยังต้องถือว่า pane ไหนเป็นเจ้าของงานไหน อันไหนเสร็จแล้ว และใครรีวิว multiplexer แก้ปัญหาพื้นที่บนจอ ต้นทุนของการรันเอเจนต์ด้วยมือคือความสนใจ ไม่ใช่พิกเซล
รันเอเจนต์ด้วยมือได้กี่ตัวก่อนจะเจ็บ? คนส่วนใหญ่อยู่ที่หนึ่งหรือสองตัวก็โอเค และเริ่มรู้สึกที่ราวสามถึงห้าตัว โดยเฉพาะเมื่อข้ามมากกว่าหนึ่ง repository จำนวนที่แน่นอนขึ้นอยู่กับว่าแต่ละงานรันนานแค่ไหนและต้องรีวิวมากเพียงใด สัญญาณบอกคือเมื่อการจัดเส้นทางและอ่านหน้าต่างซ้ำกินเวลามากกว่าการรีวิวจริง
บอร์ดงานทำให้เอเจนต์เร็วขึ้นไหม? ไม่ และ Sharkly ก็ไม่ได้อ้างเช่นนั้น เอเจนต์รันด้วยความเร็วเท่าเดิม สิ่งที่เปลี่ยนคือ overhead ของคุณ: การจัดเส้นทาง การแยกสภาพแวดล้อม และการรีวิวหยุดอยู่ในหัวคุณ แล้วเริ่มกลับมาที่ Task ที่ซึ่งงานมองเห็นและรีวิวได้
แล้วการเก็บบริบทข้าม session ล่ะ? เทอร์มินัลส่วนตัวทำมันหายทันทีที่คุณปิด การผูกการรันเข้ากับ Task เก็บเป้าหมาย diff และการพูดคุยไว้ด้วยกัน ซึ่งเป็นปัญหาการรักษาบริบทข้าม sessionที่แก้ได้ในระดับบันทึก แทนที่จะพึ่งความจำ
ยังใช้ Claude Code กับ Codex ด้วยกันแบบนี้ได้ไหม? ได้ Sharkly จัดการงานรอบ ๆ เครื่องมือ ไม่ได้แทนที่เครื่องมือ อ่านวิธีรัน Claude Code กับ Codex ด้วยกันเพื่อดูแพตเทิร์น



