เมื่อก่อนการ merge คือเส้นชัย คุณเปิด pull request มีคนรีวิว มันถูกรวมเข้าไป แล้วการเปลี่ยนแปลงก็เสร็จสิ้น เอเจนต์เขียนโค้ดได้ค่อย ๆ เลื่อนเส้นนั้นไปโดยไม่มีใครสังเกต เมื่อเอเจนต์หยิบ issue จาก Linear มาทำ เขียนโค้ด และเปิด merge request ในขณะที่คุณกำลังประชุมอยู่ การ merge จึงไม่ใช่จุดจบของงานอีกต่อไป แต่เป็นจุดเริ่มต้นของทุกสิ่งที่การ merge นั้นแตะต้อง
การ merge ไม่ใช่เส้นชัยอีกต่อไป
การ merge ไม่เคยเป็นแค่การ merge เพียงอย่างเดียว ทุกการเปลี่ยนแปลงต้องพึ่งพาระบบรอบข้างมันเสมอ ไม่ว่าจะเป็น issue ที่ตอนนี้ควรถูกปิด เอกสารที่อธิบายบางอย่างคลาดเคลื่อนไปเล็กน้อยตั้งแต่เช้านี้ CI ที่แดงกว่าเมื่อวานเล็กน้อย release notes ที่ยังไม่มีใครเขียน หรือบทสนทนาฝ่ายซัพพอร์ตที่ยังคงรอการแก้ไขที่จริง ๆ แล้วถูกส่งมอบไปตั้งแต่หลายชั่วโมงก่อน
เมื่อวิศวกรคนเดียวส่งมอบการเปลี่ยนแปลงเพียงไม่กี่รายการต่อสัปดาห์ งานติดตามผลเหล่านี้จะแทรกอยู่ในช่องว่างเล็ก ๆ ได้พอดี คุณปิด issue ในขณะที่ pull request ยังเปิดอยู่ คุณจำเอกสารได้เพราะเพิ่งแตะโค้ดนั้นไป แต่เมื่อเอเจนต์ หรือกองทัพเอเจนต์ ส่งมอบการเปลี่ยนแปลงจำนวนมากในแต่ละวัน ช่องว่างเหล่านั้นก็ล้นทะลัก โค้ดไม่ใช่คอขวดอีกต่อไปแล้ว ทุกสิ่งที่อยู่ปลายน้ำของโค้ดต่างหากที่เป็นคอขวด
รูปแบบการดูแลรักษาไม่ได้เปลี่ยนไป
การพัฒนาเร็วขึ้น แต่การดูแลรักษาไม่ได้เร็วตาม เครื่องมือที่เราใช้เพื่อรักษาความสอดคล้องของโปรเจกต์ยังคงเป็นงานมือเป็นส่วนใหญ่ และยังคงพึ่งพาให้ใครสักคนจำได้ว่าต้องหยิบมันมาใช้ในจังหวะที่ถูกต้อง
- merge request ถูกรวมเข้าไปแล้ว แต่ issue ใน Linear ที่มันแก้ไขยังคงเปิดอยู่
- เอกสารยังคงอธิบายพฤติกรรมเก่า และไม่มีใครแน่ใจว่าเป็นหน้าไหนกันแน่
- CI ล้มเหลวเป็นระยะ ๆ มาทั้งสัปดาห์ และทุกคนก็เรียนรู้ที่จะมองข้ามมันไป
- feature flag จากสามเดือนก่อนไม่มีเจ้าของและไม่มีกำหนดวันลบออก
- ฝ่ายซัพพอร์ตตอบ ticket ด้วยวิธีแก้ปัญหาชั่วคราวสำหรับบั๊กที่จริง ๆ ถูกแก้ไปแล้วตั้งแต่วันอังคาร
- มีคนถามว่ารีลีสนี้มีอะไรออกไปบ้าง และคำตอบที่ตรงไปตรงมาคือ "ขอไปอ่าน git log ก่อนนะ"
ไม่มีข้อไหนในนี้เป็นเรื่องใหม่ และไม่มีข้อไหนเป็นปัญหาของเอเจนต์โดยแท้จริง มันคือเอนโทรปีปกติของโปรเจกต์ซอฟต์แวร์ เอเจนต์เพียงแค่เร่งอัตราให้เร็วขึ้นจนกระทั่งระบบที่ไม่เป็นทางการซึ่งเคยรองรับสิ่งเหล่านี้ตามไม่ทันอีกต่อไป
การล้างงานด้วยการสั่งเป็นครั้ง ๆ ไม่สามารถขยายขนาดได้
ทางแก้ที่เห็นได้ชัดคือขอให้เอเจนต์ช่วยล้างงานด้วย และคุณก็ทำได้ เพียงแท็ก @taskgoblin บน merge request แล้วบอกให้มันอัปเดตเอกสาร ปิด issue ร่างข้อความ release note มันได้ผลจริง แต่มันขึ้นอยู่กับทรัพยากรที่หายากที่สุดในลูปทั้งหมด นั่นคือมนุษย์ที่จำได้ว่าต้องขอทุกครั้งในจังหวะที่ถูกต้อง
การดูแลรักษาไม่ใช่งานที่ทำครั้งเดียวจบ มันคือลูป "ตรวจสอบว่าเอกสารเป็นปัจจุบัน" ไม่ใช่สิ่งที่คุณทำเพียงครั้งเดียว "ตรวจให้แน่ใจว่า issue ที่ merge แล้วถูกปิด" ก็ไม่ใช่สิ่งที่คุณทำเพียงครั้งเดียวเช่นกัน สิ่งใดก็ตามที่รอให้คนสังเกตว่าถึงเวลาต้องรันลูปแล้ว จะถูกรันอย่างไม่สม่ำเสมอ เพราะคนเรานั้นไม่สม่ำเสมอในการสังเกตเห็น โดยเฉพาะเมื่อจุดประสงค์ทั้งหมดของเอเจนต์คือการไม่ต้องแบกรับทุกอย่างนี้ไว้ในหัวอีกต่อไป การล้างงานด้วยการสั่งเป็นครั้ง ๆ ย้ายงานไปให้เอเจนต์ทำ แต่การ กำหนดตารางเวลา ของงานนั้นยังคงอยู่ที่เดิม นั่นคือตัวคุณเอง
ทำไมเราจึงสร้าง Loops
การรันเอเจนต์แบบปกติจะถูกกระตุ้นด้วยเหตุการณ์ เช่น การมอบหมาย issue การถูกแท็ก หรือ pull request ใหม่ ส่วน Loop จะถูกกระตุ้นด้วยเวลา คุณมอบคำสั่งถาวรและรอบเวลาให้เอเจนต์ เช่น ทุกเช้าวันทำการ ทุกวันจันทร์ หรือวันแรกของทุกเดือน แล้วมันจะรันตัวเองใน sandbox ด้วยเครื่องมือและสิทธิ์การเข้าถึงเดียวกันกับการรันอื่น ๆ
คำสั่งคืองานทั้งหมด และคำสั่งที่ดีจะอ่านเหมือนคำอธิบายงานมากกว่าความปรารถนา นั่นคือต้องดูอะไร repository ไหน ต้องทำอะไร ไม่ควรทำอะไร และ ส่วนที่ทำให้มันปลอดภัยที่จะรันโดยไม่มีคนควบคุม คือต้องทำอะไรเมื่อไม่มีอะไรต้องทำ ซึ่งก็คือไม่ต้องทำอะไรเลย
ทุกวันทำการเวลา 09:00 น. ให้ดู merge request ที่ merge เข้าไปใน
group/repoในวันที่ผ่านมา และปิด issue ใน Linear ที่มันแก้ไขซึ่งยังคงเปิดอยู่ ถ้าไม่มีก็ไม่ต้องทำอะไร
นั่นคือลูปการดูแลรักษาที่มีเจ้าของ มันไม่ต้องรอให้คุณจำได้ เพราะการรันตามตารางเวลาคือการรันเอเจนต์แบบเต็มรูปแบบ มันจึงสามารถทำได้ตลอดทาง ไม่ใช่แค่ทำเครื่องหมายเอกสารที่ล้าสมัย แต่เปิด merge request ที่แก้ไขมันด้วย ไม่ใช่แค่สังเกตว่า issue ที่ merge แล้วเปิดค้างอยู่ แต่ปิดมันด้วย แล้วรายงานไปยังที่ที่คุณจะเห็นจริง ๆ ไม่ว่าจะเป็นความคิดเห็นบน issue ใน Linear ข้อความในแชนแนล Slack ที่คุณระบุไว้ หรืออีเมลหากไม่มีที่ไหนดีกว่านั้น
และเนื่องจากมันใช้ทุกอย่างที่การรันปกติทำอยู่แล้วซ้ำ จุดที่ยากลำบากจึงถูกจัดการไว้แล้ว เวลาที่พลาดไปจะถูกข้ามแทนที่จะย้อนกลับมาทำ ดังนั้นตัวสเกดูลที่หยุดทำงานไปหนึ่งชั่วโมงจะไม่ตื่นขึ้นมาแล้วยิงการรันย้อนหลังนับร้อยครั้งใส่คุณ แต่ละการรันมีงบประมาณและแนวป้องกันของตัวเอง เราจัดเตรียมชุดเทมเพลตเริ่มต้นสำหรับลูปแบบนี้โดยเฉพาะ ไม่ว่าจะเป็นการรักษา issue และ merge ให้ตรงกัน คอยจับตา CI ที่แดงนานเกินไป ตามหา feature flag ที่ไม่มีเจ้าของอีกต่อไป หรือร่าง release notes เมื่อมีการส่งมอบสิ่งต่าง ๆ เพราะลูปที่เป็นประโยชน์นั้นเหมือนกันในทีมส่วนใหญ่ คุณเพียงแค่กรอก repository และแชนแนลของคุณเข้าไป ส่วนแนวป้องกันนั้นถูกเขียนไว้ให้แล้ว
บทบาทของวิศวกรขยับสูงขึ้นไปอีกระดับ
มีความกังวลอยู่เบื้องหลังเรื่องทั้งหมดนี้ นั่นคือการทำให้การดูแลรักษาเป็นอัตโนมัติหมายถึงการทำให้วิจารณญาณเป็นอัตโนมัติไปด้วยหรือเปล่า คำตอบคือไม่ มันยกระดับวิจารณญาณขึ้นไปอีกขั้นต่างหาก เมื่อลูปต่าง ๆ รันตัวเองได้ คุณก็เลิกเป็นคนที่ต้องจำว่าต้องปิด issue แล้วกลายเป็นคนที่ตัดสินใจว่าลูปไหนควรมีอยู่ แนวป้องกันของมันคืออะไร และ "เสร็จสิ้น" หมายถึงอะไรสำหรับแต่ละลูป คุณรีวิวคำสั่งถาวรแทนที่จะวิ่งไปทำธุระเอง
นั่นคือรูปแบบที่อาวุโสกว่าของงานนี้อยู่ดี เอเจนต์ทำให้การเขียนโค้ดมีต้นทุนต่ำ สิ่งที่เหลืออยู่คือการตัดสินใจว่าอะไรควรเป็นจริงเกี่ยวกับระบบ และทำให้แน่ใจว่ามันยังคงเป็นจริงอยู่เสมอ Loops คือวิธีที่คุณรักษาความจริงนั้นไว้โดยไม่ต้องแบกทุกอย่างไว้ในหัว เอเจนต์สร้างงานขึ้นมา และลูปถาวรก็คอยดูแลรักษามันไว้
