วิธีการขยายตัวแทนการเขียนโค้ด AI ในทีมพัฒนา

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

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

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

สิ่งที่แตกก่อน: บริบทที่ใช้ร่วมกัน

นักพัฒนาทุกคนที่รันเอเจนต์กำลังสอนมันให้รู้จักเวอร์ชันของฐานข้อมูลโค้ดของตนเองอย่างเงียบๆ

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

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

CLAUDE.md สำหรับ Claude Code, AGENTS.md สำหรับ Codex และเอเจนต์ CLI อื่นๆ ส่วนใหญ่ และในทางปฏิบัติทีมจำนวนมากเก็บ ไฟล์บริบทที่พกพาได้ แทนที่จะรักษาสองไฟล์ที่แยกจากกัน กลไกมีความสำคัญมากกว่าชื่อไฟล์: คำแนะนำมีอยู่ในที่เก็บข้อมูล ดังนั้นมันจึงมาพร้อมกับ git pull แทนที่จะมาจากใครก็ตามที่อยู่ในห้อง

สิ่งที่ควรอยู่ในนั้น:

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

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

การทดสอบที่มีประโยชน์ก่อนเพิ่มบรรทัด: ถ้าทีมงานดึงสิ่งนี้ มันช่วยพวกเขาหรือทำให้พวกเขาเสียหาย?

สิ่งที่แตกที่สอง: เอเจนต์สองตัว ไฟล์เดียว

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

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

มีสองกลไกที่แก้ไขมัน และคุณต้องการทั้งสองอย่าง

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

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

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

สิ่งที่แตกที่สาม: การตรวจสอบ

ทุกอย่างเกี่ยวกับการตรวจสอบในระดับทีมตามมาจากตัวเลขหนึ่ง: จำนวน diff ที่เข้ามาต่อชั่วโมง

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

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

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

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

สิ่งที่แตกที่สี่: ค่าใช้จ่าย และการสนทนาเกี่ยวกับค่าใช้จ่าย

การใช้โทเค็นหยุดเป็นรายละเอียดส่วนบุคคลในทันทีที่มันปรากฏในใบแจ้งหนี้ของทีม

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

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

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

สิ่งที่เปลี่ยนแปลงในพิธีกรรมของทีม

สามสิ่ง ตามประสบการณ์ของเราและในสิ่งที่ทีมรายงาน

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

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

การเฉพาะทางย้ายจากคนไปยังบทบาท เมื่อเอเจนต์จัดการการเขียน คำถามที่น่าสนใจคือใครตรวจสอบอะไร และทีมมักจะโน้มเอียงไปสู่การมอบหมายบทบาทให้กับเอเจนต์ในลักษณะเดียวกับที่พวกเขามอบหมายให้กับคน: หนึ่งคนในด้านการดำเนินการ หนึ่งคนในด้านการตรวจสอบ หนึ่งคนในด้านการทดสอบ นี่คือแนวคิดเบื้องหลัง Agent Teams ซึ่งงานจะถูกส่งจากบทบาท Dev ไปยังบทบาท QA พร้อมกับ diff ความเสี่ยง และคำแนะนำการทดสอบที่แนบมา และเกณฑ์คุณภาพจะถูกตัดสินโดยชุดการทดสอบของคุณแทนที่จะเป็นความคิดเห็นของเอเจนต์เกี่ยวกับงานของมัน

การตั้งค่าที่ถืออยู่

ย่อสั้นๆ ในลำดับที่สำคัญ:

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

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

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