Spotify สร้างเครื่องมือภายในชื่อ Xirp ให้วิศวกรของตัวเองใช้จัดการ AI coding session จำนวนมากที่รันขนานกัน หน้าเปิดตัวระบุว่าวิศวกร Spotify รัน agent พร้อมกันได้ 50+ เซสชันผ่าน harness หลายตัว ในที่นี้ harness คือโปรแกรมที่ครอบ agent ไว้และเป็นตัวที่วิศวกรใช้ทำงานจริง worktree และ context ของแต่ละเซสชันแยกขาดจากกัน แต่ context ย้ายข้ามเซสชันได้

คนที่เปิด agent ค้างไว้พร้อมกันสักสามสี่เซสชันจะรู้ว่าส่วนที่ยากไม่ได้อยู่ที่การเปิดเซสชันเพิ่ม เปิด terminal แล้วแตก worktree ใหม่ใช้เวลาไม่กี่วินาที แต่บริบทไม่ได้ตามไปด้วยเอง ถ้าไม่ปูบริบทให้ เซสชันที่เพิ่งเปิดก็เริ่มจากศูนย์ ต้องเล่าใหม่ว่าโครงสร้างโปรเจกต์เป็นแบบไหน งานนี้เดินมาถึงไหนแล้ว และตกลงกันไว้ว่าจะไม่แตะส่วนใด วิธีที่ Xirp แบ่งระบบเป็นชั้น ๆ จึงสะท้อนว่า Spotify มองว่าเพดานของงานแบบนี้อยู่ตรงไหน

worktree แยกกัน แต่ context ต้องข้ามได้

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

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

vendor-neutral ทำให้โมเดลกลายเป็นตัวเลือกระหว่างทาง

ชั้นถัดมาคือการไม่ผูกกับผู้ให้บริการรายใดรายหนึ่ง ระบบออกแบบมาให้เป็น vendor-neutral จึงสลับโมเดลระหว่างทำงานได้ และเลือกโมเดลตามความคุ้มค่าด้าน price-performance ได้ รวมถึงโมเดลโอเพนซอร์สที่ Spotify self-host เอง

การวางชั้นแบบนี้ทำให้การเลือกโมเดลไม่ใช่การตัดสินใจระดับสถาปัตยกรรมแบบเดิม ที่พอเลือกครั้งเดียวทั้ง workflow ก็ต้องผูกกับผู้ให้บริการเจ้านั้นไปยาว ๆ แต่กลายเป็นสิ่งที่เลือกได้ระหว่างทำงานว่าโมเดลตัวไหนคุ้มกับงานตรงหน้า และเมื่อโมเดลโอเพนซอร์สที่ Spotify self-host เองอยู่ในรายการเดียวกับโมเดลของเจ้าใหญ่ ก็แปลว่าชั้นนี้ไม่ได้ผูกกับ API ของใครแบบถาวร

ชั้นที่เครื่องมือให้ไม่ได้ คือความรู้ของทั้งองค์กร

ชั้นที่สามทำให้ Xirp ต่างจากการหา harness ดี ๆ มาใช้มากที่สุด เมื่อ Xirp เชื่อมกับระบบที่ Spotify เรียกว่า Portal ระบบจะป้อน organizational context ให้ agent สี่ด้าน ได้แก่ architecture · dependencies · ownership · decisions พูดอีกแบบคือ ระบบประกอบด้วยอะไรบ้าง อะไรพึ่งพาอะไร ส่วนไหนเป็นของทีมไหน และเคยตัดสินใจอะไรกันไว้แล้ว ความรู้ระดับองค์กรชุดนี้จึงกลายเป็นฐานร่วมที่ทุกเซสชันเริ่มจากจุดเดียวกัน

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

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

อ่านตัวเลข 50+ ให้ถูก แล้วเอาโครงนี้มาเทียบกับ setup ของตัวเอง

ตัวเลข 50+ เป็นการใช้งานภายในของ Spotify หน้าเปิดตัวพูดถึงวิศวกรของบริษัทที่ใช้ Xirp อยู่ ไม่ได้บอกว่านั่นคือเพดานของเครื่องมือ และไม่ได้บอกว่าทีมข้างนอกจะทำได้เท่ากัน การยกตัวเลขนี้ไปตั้งเป็นเป้าของทีมอื่นจึงยังไม่มีอะไรรองรับ

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

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

• เซสชันที่เปิดค้างไว้พร้อมกัน แยก worktree ออกจากกันจริงหรือยัง
• เปลี่ยนโมเดลกลางงานได้ไหม โดยไม่ต้องเริ่มปูบริบทกันใหม่ทั้งหมด
• สิ่งที่ agent เจอในเซสชันหนึ่ง คนอื่นในทีมจะหาเจอและหยิบไปใช้ต่อได้ที่ไหน

เครื่องมือที่ใช้อยู่อาจตอบสองข้อแรกให้แล้วบางส่วน ส่วนข้อสุดท้ายต้องอาศัยความรู้ที่ทีมสร้างขึ้นเอง เพราะแก่นของมันคือความรู้เฉพาะของทีมนั้น ๆ Spotify ตอบข้อนี้ด้วยการเชื่อม Xirp เข้ากับ Portal ซึ่งเดินข้อมูลสองทาง คือป้อนความรู้ที่องค์กรมีอยู่แล้วเข้าไปให้ agent และรับสิ่งที่แต่ละเซสชันทำไว้กลับออกมาให้ทีมอื่นเห็น ถ้ามีแต่ทางป้อนความรู้เข้า agent แต่ไม่มีทางรับสิ่งที่แต่ละเซสชันทำไว้กลับออกมา บริบทของงานก็ยังค้างอยู่กับคนที่รันเซสชันนั้นเหมือนเดิม