Loop engineering กำลังเป็นที่พูดถึงอย่างมาก หากคุณลองเลื่อนดูฟอรัมทางเทคนิคใดก็ได้ คุณจะพบกับเสียงโต้แย้งที่ว่าเราควรเลิกปฏิบัติกับเอเจนต์ AI เหมือนเป็นแชทบอทที่ต้องคอยสอนด้วยพรอมต์ที่ชาญฉลาด แต่พวกเขาบอกว่าเราควรออกแบบ "ลูป" (loops) แทน ซึ่งก็คือวงจรการทำงานแบบอัตโนมัติที่ปล่อยให้เอเจนต์สามารถวางแผน, ลงมือทำ, ตรวจสอบงานของตัวเอง และทำซ้ำ (iterate) ได้ในขณะที่เราหลับ ข้อเสนอนี้ดูน่าดึงดูดใจมาก เพราะหากลูปถูกสร้างขึ้นมาอย่างดี เอเจนต์จะสามารถทำงานให้อยู่ในเส้นทางได้โดยไม่ต้องมีมนุษย์คอยควบคุมตลอดเวลา เปลี่ยนจากความต้องการดิบๆ ให้กลายเป็นผลลัพธ์ที่เสร็จสมบูรณ์ได้เพียงชั่วข้ามคืน
คำสัญญานั้นดูดีมากในทางทฤษฎี แต่ในทางปฏิบัติ เอเจนต์ส่วนใหญ่มีการทำงานแบบลูปอยู่แล้ว พวกมันสร้างโค้ด, ตรวจสอบข้อผิดพลาดของคอมไพเลอร์หรือการทดสอบที่ล้มเหลว, แก้ไขโค้ด (patch), และรันชุดทดสอบใหม่อีกครั้ง วงจรการตอบสนองพื้นฐานนี้ไม่ใช่เรื่องใหม่ สิ่งที่กลุ่มผู้สนับสนุนกำลังเรียกร้องในตอนนี้คือสิ่งที่ทะเยอทะยานกว่านั้น นั่นคือ "ลูปชั้นนอก" (outer loop) ที่ควบคุมงานทั้งหมด ไม่ใช่แค่เพียงข้อผิดพลาดทางไวยากรณ์ (syntax errors) การสร้างลูปชั้นนอกนี้เองคือจุดที่เริ่มยาก เพราะวิศวกรรมซอฟต์แวร์ไม่ค่อยเป็นระบบปิดที่มีกฎเกณฑ์ตายตัว
ปัญหาในการออกแบบลูป
เป้าหมายของผลิตภัณฑ์นั้นมีความซับซ้อน คุณแทบจะไม่เริ่มงานด้วยนิยามของคำว่า "เสร็จสิ้น" (definition of done) ที่สมบูรณ์แบบ บ่อยครั้งที่คุณจะค้นพบเป้าหมายที่แท้จริงในขณะที่กำลังง่วนอยู่กับการสร้าง (build) ข้อกำหนดที่ฟังดูตรงไปตรงมาบนไวท์บอร์ดอาจกลายเป็นว่ามีกรณีขอบเขต (edge cases) ที่เปลี่ยนรูปแบบของโซลูชันไปโดยสิ้นเชิง เมื่อคุณนำเอเจนต์ไปใส่ไว้ในลูปที่ตายตัว ความตายตัวนั้นจะกลายเป็นข้อเสีย ลูปจะยังคงพยายามทำตามเป้าหมายที่อาจจะเป็นเป้าหมายที่ผิดตั้งแต่แรก หรือที่แย่กว่านั้น ลูปที่ยืดหยุ่นเกินไปบางครั้งอาจแก้ปัญหาการติดขัดด้วยการแอบเปลี่ยนเป้าหมายเงียบๆ เพื่อให้สอดคล้องกับผลลัพธ์ที่มันผลิตออกมาได้ ซึ่งไม่มีผลลัพธ์ใดที่เป็นประโยชน์เลย แบบแรกคือการสิ้นเปลืองทรัพยากรคำนวณ ส่วนแบบหลังคือการส่งมอบงานที่ไร้คุณภาพออกมาอย่างมั่นใจ
ประเด็นที่ลึกกว่านั้นคือต้นทุนในการกำหนดรายละเอียด (specification cost) หากคุณต้องการให้ลูปทำงานโดยไม่มีคนควบคุม คุณต้องเขียนข้อกำหนด (spec) ที่คาดการณ์ได้เกือบทุกอย่าง เอเจนต์ควรเปลี่ยนอะไรบ้าง? พฤติกรรมเดิมส่วนไหนที่สำคัญและต้องรักษาไว้? ภายใต้เงื่อนไขที่แม่นยำแบบไหนที่เอเจนต์ควรหยุดทำซ้ำ? ความเสี่ยงใดที่ยอมรับได้ และผลกระทบข้างเคียงแบบไหนที่ควรสั่งให้หยุดทำงานทันที? การเขียนเอกสารเหล่านั้นอาจใช้เวลานานกว่าการนั่งคุมเอเจนต์และช่วยนำทางผ่านงานนั้นแบบเรียลไทม์เสียอีก คุณกำลังต้องจ่ายต้นทุนล่วงหน้าที่สูงมาก เพื่อแลกกับการทำงานอัตโนมัติที่จะคุ้มค่าก็ต่อเมื่อการตรวจสอบนั้นมีราคาถูกกว่าการลงมือทำอย่างมหาศาลเท่านั้น
เมื่อไหร่ที่ลูปจะคุ้มค่ากับการใช้งานจริง
นั่นไม่ได้หมายความว่า loop engineering ไร้ประโยชน์ แต่มันหมายความว่ามันเป็นเครื่องมือเฉพาะทาง ไม่ใช่กลยุทธ์ที่ใช้ได้กับทุกอย่าง ลูปจะแสดงประสิทธิภาพสูงสุดเมื่อต้นทุนการตรวจสอบเพิ่มขึ้นแบบทวีคูณและเกณฑ์ความสำเร็จมีความชัดเจน ซึ่งมักจะเป็นไปตามเงื่อนไขสามประการนี้
งานเชิงกลที่เป็นกิจวัตร. ลองนึกถึงงานที่ทำให้วิศวกรอาวุโสอยากเกษียณ: การเริ่มแอปพลิเคชันตามลำดับที่กำหนด, การคลิกผ่าน UI การติดตั้ง (deployment) เพื่อยืนยันแต่ละขั้นตอน, การค้นหา (grep) ล็อกเพื่อหาข้อความแสดงข้อผิดพลาดที่ทราบกันดีหลังจากการปล่อยซอฟต์แวร์, หรือการตรวจสอบว่าไฟล์กำหนดค่าถูกเขียนไปยังโหนดที่ถูกต้องทั้งหมด ขั้นตอนเหล่านี้เป็นเรื่องน่าเบื่อสำหรับมนุษย์แต่ตรวจสอบได้ง่ายมาก ลูปสามารถคอยดูแลกระบวนการเหล่านี้ ตรวจสอบ health endpoints หลังการเริ่มระบบใหม่แต่ละครั้ง และทำการย้อนกลับ (roll back) ทันทีเมื่อพบสัญญาณความผิดปกติ โดยที่มนุษย์ยังคงเป็นผู้กำหนดแผนการติดตั้ง ส่วนลูปมีหน้าที่เพียงแค่ดำเนินการตามแผนนั้นด้วยความอดทนของเครื่องจักรในเวลาตีสอง
เป้าหมายการเพิ่มประสิทธิภาพที่วัดผลได้. เมื่อความสำเร็จวัดได้ด้วยตัวเลข ลูปจะมีประสิทธิภาพอย่างมหาศาล เช่น ลดค่า p99 latency ให้ต่ำกว่า 150 มิลลิวินาที, ลดการใช้หน่วยความจำลง 20%, หรือการย้ายส่วนการทำงานหลัก (hot path) จาก Python ไปเป็น Rust และตรวจสอบให้แน่ใจว่า unit tests เดิมทั้งหมดผ่าน ลูปสามารถสร้างการเปลี่ยนแปลง, ทำการทดสอบประสิทธิภาพ (benchmark), เก็บเวอร์ชันที่ให้ผลลัพธ์ดีที่สุดไว้ และทิ้งส่วนที่เหลือ เนื่องจากกระบวนการตรวจสอบเป็นแบบอัตโนมัติและพื้นที่ในการค้นหามีขนาดใหญ่ ต้นทุนที่เพิ่มขึ้นจากการตรวจสอบด้วยมนุษย์จะทำให้งานนี้ไม่สามารถทำได้จริงหากไม่มีลูป เป้าหมายนั้นตายตัว แต่เส้นทางยังไม่แน่ชัด นี่แหละคือจุดที่เหมาะสมที่สุด
คู่มือการปฏิบัติงาน (Operational playbooks). การตอบสนองต่ออุบัติการณ์ (incident response) และตั๋วสนับสนุน (support tickets) มักจะมีรูปแบบที่มนุษย์เคยแก้ไขไว้แล้ว เช่น ข้อผิดพลาดในระบบการผลิตประเภทหนึ่งที่ต้องทำการเปลี่ยนรหัสผ่าน (rotating a credential) และล้างแคช (clearing a cache) เสมอ หรือคำขอสนับสนุนประเภทหนึ่งที่สามารถแก้ไขได้ด้วยการคืนเงินเมื่อเงื่อนไขเฉพาะสามประการครบถ้วน ลูปสามารถเฝ้าดูตัวกระตุ้นเหล่านั้นและดำเนินการตามคู่มือการปฏิบัติงาน โดยจะส่งต่อเรื่อง (escalate) ก็ต่อเมื่อรูปแบบที่กำหนดไว้ผิดเพี้ยนไปเท่านั้น มันไม่ได้ตัดสินว่าคู่มือการปฏิบัติงานนั้นถูกต้องหรือไม่ แต่มันเพียงแค่บังคับใช้ความสม่ำเสมอในระดับและด้วยความเร็วที่วิศวกรที่เข้าเวร (on-call) ไม่สามารถทำได้
ผู้ควบคุม ไม่ใช่ผู้กำหนดมาตรฐานอ้างอิง
มีความแตกต่างที่สำคัญประการหนึ่งที่มักถูกมองข้ามไปในการสนทนาส่วนใหญ่ในปัจจุบัน ลูป (Loops) คือตัวควบคุม (regulators) พวกมันช่วยให้ระบบทำงานสอดคล้องกับเป้าหมายที่กำหนดไว้ล่วงหน้า เหมือนกับที่เทอร์โมสแตทช่วยรักษาอุณหภูมิในห้องให้อยู่ที่ 72 องศา แต่เทอร์โมสแตทไม่ได้เป็นคนเลือกอุณหภูมิ 72 องศาเอง ต้องมีใครบางคนตัดสินใจก่อนว่านั่นคืออุณหภูมิที่เหมาะสม
เมื่อนำมาประยุกต์ใช้กับซอฟต์แวร์ นี่หมายความว่าเอเจนต์ (agent) ที่อยู่ในลูปสามารถแก้ไขบั๊ก รีแฟกเตอร์ฟังก์ชัน หรือปรับจูนพารามิเตอร์ได้ตลอดทั้งวัน อย่างไรก็ตาม มันไม่สามารถตัดสินใจได้ว่าฟีเจอร์ไหนที่จะช่วยลูกค้าได้จริง ๆ หรือบั๊กตัวไหนที่คุ้มค่าแก่การแก้ไขก่อนการปล่อยเวอร์ชันถัดไป การตัดสินใจเหล่านั้นต้องใช้การใช้วิจารณญาณเกี่ยวกับบริบททางธุรกิจ ความเจ็บปวดของผู้ใช้ (user pain) และลำดับความสำคัญเชิงกลยุทธ์ เอเจนต์มีหน้าที่ดำเนินการ แต่มนุษย์มีหน้าที่ตัดสินใจ การสับสนระหว่างสองสิ่งนี้คือสาเหตุที่ทำให้ทีมต่าง ๆ ลงเอยด้วยระบบที่ได้รับการปรับแต่งมาอย่างสวยงาม แต่กลับแก้ปัญหาผิดจุด
Loop engineering มีประโยชน์ แต่ก็มีขอบเขตที่แคบ มันช่วยให้คุณเดินเครื่องจักรได้อย่างมีระเบียบวินัยและรวดเร็ว แต่มันไม่ได้ตัดสินใจว่าควรสร้างเครื่องจักรแบบไหน สร้างให้ใคร หรือความสำเร็จในมุมมองของมนุษย์นั้นมีหน้าตาเป็นอย่างไร การตัดสินใจว่าฟีเจอร์ไหนสำคัญ ความเสี่ยงระดับใดที่ยอมรับได้ และเมื่อใดที่เป้าหมายเองจำเป็นต้องเปลี่ยน คือสิ่งที่ต้องอาศัยวิจารณญาณของคุณ จงสร้างลูปสำหรับงานที่คุณเข้าใจดีพอที่จะตรวจสอบความถูกต้องได้โดยอัตโนมัติ ส่วนเรื่องอื่น ๆ ที่เหลือ จงควบคุมมันด้วยตัวเอง
บทความนี้อ้างอิงจากแนวคิดที่พูดถึงโดย Isaac Hagoel ใน “Loop Engineering Minus The Hype.” สำหรับการสนทนาด้านวิศวกรรมเพิ่มเติม สามารถเข้าร่วมชุมชนแห่งการเรียนรู้ของเราได้ที่ Telegram.