โรงงานซอฟต์แวร์ ในมุมมองด้านสว่างและด้านมืด

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

แนวคิดเรื่องโรงงานซอฟต์แวร์นี้เป็นคำที่ย้อนกลับไปถึงบทความของ Bob Bemer เรื่อง "The economics of program production" ซึ่งนำเสนอในปี 1968 เป็นเวลาครึ่งศตวรรษที่หลายคนใฝ่ฝันถึงโลกที่ซอฟต์แวร์เป็นกระบวนการผลิตที่ทำซ้ำได้และวัดผลได้ (คล้ายกับการปั๊มชิ้นส่วนรถยนต์ในโรงงาน) แทนที่จะเป็นงานฝีมือที่แยกส่วนของแต่ละบุคคล ในอดีต ความฝันนี้โดยทั่วไป (แม้จะไม่ทั้งหมด) มักจะล้มเหลว ส่วนหนึ่งเป็นเพราะความยากลำบากในการ "ปั๊ม" ความคิดออกมา

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

@dexhorthy ผู้ร่วมก่อตั้ง HumanLayer เพิ่งให้การบรรยายที่ยอดเยี่ยมในงาน AI Engineer World's Fair ชื่อ "Harness Engineering is not Enough: Why Software Factories Fail." ซึ่งน่าติดตามในหัวข้อนี้

ลูปคืออะตอม โรงงานคือลูปที่ทำงานในวงกว้าง

โครงสร้างคือทุกสิ่งทุกอย่าง และมันเริ่มต้นจากหน่วยเล็กๆ ทั้งสแต็กนั้นประกอบด้วยแนวคิดสามชั้นที่ซ้อนทับกัน: ลูป (loop), ฮาร์เนส (harness), และโรงงาน (factory)

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

ประเด็นของ วิศวกรรมลูป (loop engineering) คือการที่คุณหยุดกำหนด prompt ให้เอเจนต์ทีละเทิร์น และเริ่มออกแบบระบบเล็กๆ ที่กำหนด prompt ให้เอเจนต์แทน

ฮาร์เนสคือกำแพงรอบๆ ลูป: แซนด์บ็อกซ์ที่มันทำงาน, เครื่องมือที่มันสามารถเข้าถึงได้, หน่วยความจำที่คงอยู่ระหว่างการรันแต่ละครั้ง, และเกตที่ตัดสินว่าอะไรหมายถึง "เสร็จ" ลูปคือพฤติกรรม; ฮาร์เนสคือสภาพแวดล้อมที่พฤติกรรมนั้นทำงานอยู่ภายใน

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

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

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

ลูป → ฮาร์เนส → โรงงาน โรงงานไม่ใช่เอเจนต์ที่ฉลาดกว่า; มันคือลูปที่ถูกควบคุมหลายๆ ตัวที่ป้อนเกตตรวจสอบเพียงจุดเดียว โดยมีมนุษย์เป็นเจ้าของลูปด้านนอก โรงงาน ที่วาดไว้

สไลด์สำคัญที่ Dex ใช้เวลามากที่สุดนั้นยอดเยี่ยมเพราะมันเป็นแผนภาพการเดินสายไฟที่ชัดเจน ซึ่งทำให้เห็นภาพสิ่งที่มิฉะนั้นแล้วจะเป็นลูปที่เห็นได้ชัด นี่คือมุมมองของฉัน:

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

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

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

ทำไมเราถึงเรียกมันว่า "มืด"

โรงงานมืด (dark factory) ทำงานโดยปิดไฟทางกายภาพ เพราะสิ่งเดียวบนพื้นโรงงานคือเครื่องจักร และเครื่องจักรไม่ต้องการแสงในการมองเห็น โรงงานซอฟต์แวร์มืดก็เป็นการกระทำแบบเดียวกัน: โค้ดถูกส่งออกโดยที่มนุษย์ไม่ได้อ่าน ตรวจสอบโดยเครื่องจักรอื่นเท่านั้น

ภาพนี้ยืมมาจากการผลิต ต้นกำเนิดของมันคือทางกายภาพมากกว่าดิจิทัล ซึ่งมีรากฐานมาจากโรงงานที่ปิดไฟและงานดำเนินการโดยหุ่นยนต์ FANUC ในญี่ปุ่นได้ดำเนินการโรงงานแบบ lights-out มาตั้งแต่ปี 2001; Xiaomi ในปี 2024 ได้เปิดโรงงานมืดที่มีระบบอัตโนมัติสูงของตัวเอง สิ่งที่เหมือนกันคือผลิตภัณฑ์ถูกประกอบและจัดส่งโดยไม่มีมนุษย์คนใดอ่านมันเลย คำว่า "มืด" เกิดขึ้นเมื่อการกระทำของการอ่านนั้นถูกเอาออกจากกระบวนการ

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

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

วิศวกรรมฮาร์เนสนั้นไม่เพียงพอ

ฮาร์เนสของการประสานงาน, การสร้างต้นแบบในแซนด์บ็อกซ์, และการเรียกใช้เครื่องมือเมื่อโมเดลโต้ตอบกับโลกและกันและกัน จะมีประสิทธิภาพและประสิทธิผลมากขึ้นเรื่อยๆ อย่างไรก็ตาม มีความล้มเหลวโดยธรรมชาติภายในโมเดลในการพยายามรักษาคุณภาพของโค้ดเบสในระยะยาวและผ่านการเปลี่ยนแปลงแบบเพิ่มเติม และฉันคิดว่ามีเหตุผลที่ดีที่จะเชื่อว่าโมเดลเพียงอย่างเดียวจะสูญเสียการต่อสู้กับ หนี้ความเข้าใจ (comprehension debt) ในที่สุด

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

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

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

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

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

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

ข้อจำกัดพื้นฐานในโรงงานซอฟต์แวร์ไม่ใช่ปริมาณโค้ดที่เราสามารถผลิตออกมาได้: แต่มันคือความเร็วที่เราสามารถตรวจสอบได้

แรงดันย้อนกลับ (back pressure) คือกฎที่ว่าคุณสามารถให้อิสระแก่ลูปได้มากเท่าที่คุณสามารถตรวจสอบได้อย่างถูกและเชื่อถือได้เท่านั้น และไม่มากไปกว่านั้น การตรวจสอบ ไม่ใช่การสร้าง คือข้อจำกัดที่แท้จริงของโรงงาน

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

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

การสร้างคือปากที่กว้าง; การตรวจสอบคือคอที่แคบ การเร่งปากให้เร็วขึ้นเพียงทำให้กองที่คอคอยลึกขึ้น

การเปิดไฟกลับมา

โรงงานสว่าง (lit factory) คือไปป์ไลน์เดียวกันโดยเปิดไฟทิ้งไว้ในจุดที่วิจารณญาณอาศัยอยู่ เอเจนต์ยังคงทำงานส่วนใหญ่ แต่มีมนุษย์อ่านสิ่งที่ออกมาก่อนที่จะส่งออก และไฟจะเปิดอยู่ทุกที่ที่การตัดสินใจที่ผิดพลาดมีค่าใช้จ่ายสูง

เวอร์ชันสว่างไม่ได้แค่เพิ่มการตรวจสอบต่อท้าย แต่ย้ายจุดของวิจารณญาณมนุษย์ไปยัง upstream ไปยังผลิตภัณฑ์ การออกแบบ และสถาปัตยกรรม ก่อนที่เอเจนต์จะเริ่มลูป

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

คุณอาจคิดว่าทั้งหมดนี้ฟังดูไม่น่าตื่นเต้น คุณพูดถูก ตาข่ายนิรภัยประกอบด้วยแนวทางปฏิบัติทางสถาปัตยกรรมธรรมดาสามัญที่เรารู้จักกันมานานและส่วนใหญ่ไม่สนใจ: ชนิดและลายเซ็นเมธอดที่ดีเพื่อให้ข้อผิดพลาดถูกจับโดยคอมไพเลอร์แทนที่จะเป็นในระบบการผลิต; รอยต่อการทดสอบ (test seams) ที่เราสามารถยึดพฤติกรรมและทำให้มองเห็นการเปลี่ยนแปลงได้; การจัดวางโค้ดเพื่อให้ผู้อ่านคนถัดไป ไม่ว่าจะเป็นมนุษย์หรือโมเดล รู้ว่าจะหาสิ่งที่พวกเขาสนใจได้ที่ไหน; การทำให้ call stack สั้นและอ่านง่าย; การรักษาขอบเขตของคอมโพเนนต์ให้ชัดเจนเพื่อให้การเปลี่ยนแปลงไม่มีรัศมีการระเบิดที่ใหญ่; และการฉีด dependency (dependency injection) เพื่อให้เราสามารถสลับชิ้นส่วนหนึ่งกับอีกชิ้นหนึ่งได้ ไม่มีอะไรใหม่เลย เราพูดกันมาโดยตลอดว่าเราใส่ใจเรื่องสถาปัตยกรรมที่ดี แต่ตอนนี้ที่เราใช้เอเจนต์เขียนโค้ดอัตโนมัติ สถาปัตยกรรมนั้นก็กำลังทำงานที่สองในฐานะตาข่ายนิรภัยราคาถูกและปลอมแปลงได้ยาก เพื่อป้องกันข้อผิดพลาดที่เอเจนต์จะทำ

ตาข่ายนิรภัยนั้นต้องอยู่ภายนอกโมเดล เพราะโมเดลจะไม่จัดหามันให้ เอเจนต์เขียนโค้ดที่ให้ความรู้สึกมีความสามารถมากที่สุด อย่าง Claude Code และ Codex ถูกฝึกโดย reinforcement learning กับฮาร์เนสและเครื่องมือของพวกมันเอง: คล่องแคล่วกับเครื่องมือและสำนวนทั้งหมดของวงการ แต่ไม่ใช่กับสิ่งต่างๆ เช่น ความสามารถในการบำรุงรักษาในระยะยาว สถาปัตยกรรมที่ตั้งใจซึ่งเราพูดถึงมาโดยตลอดคือเครื่องมือที่จับหนี้นั้น และการลงทุนที่เราทำในมันคือการที่เราซื้ออิสระของเรากลับคืนมา

นำสิ่งนั้นรวมกับโครงสร้างพื้นฐานที่ปลอดภัย และคุณจะได้ลูปที่แน่นหนาและมีความเสี่ยงต่ำที่คุณสามารถรันโดยไม่มีคนดูแล Horthy อธิบายไว้ในโพสต์ล่าสุด: งาน cron ของ GitHub Actions ทุกคืนที่แก้ไขแอนตี้แพทเทิร์นเพียงอย่างเดียว ไม่ว่าจะเป็นการละเมิด lint หรือ prop ที่ไม่จำเป็น คอมมิต และเปิด pull request เล็กๆ หนึ่งอัน ด้วยตัวของมันเอง เพื่อให้ทีมตื่นขึ้นมาเจอโค้ดเบสที่ดีขึ้นเล็กน้อยและ diff ที่สั้นพอที่จะอ่าน แต่สำหรับลูปที่มีเดิมพันสูงพอ คุณคงไม่อยากเสี่ยงตื่นขึ้นมาเจอระบบ auth, ระบบเรียกเก็บเงิน, หรือสัญญา API สาธารณะที่พัง ให้เปิดไฟไว้ตรงนั้น และไว้วางใจว่ามนุษย์ที่มีวิจารณญาณและความรู้ในการทำงานจริงเกี่ยวกับระบบจะจับข้อผิดพลาดได้

อะไรทำให้ลูปสมควรเป็น "มืด"

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

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

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

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

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

ลูป, กราฟ หรือ state machine?

คุณควรอ่าน "State machines in 2 minutes" โดย @DavidKPiano

เมื่อคุณมอบหมายงานให้เอเจนต์ คุณอาจจะสร้างกราฟรอบๆ งานนั้น ไม่ว่าคุณจะเรียกกราฟนั้นว่า finite state machine หรือชุดของการเรียกใช้บริการที่เชื่อมโยงตามเงื่อนไข มันเป็นกรอบความคิดที่ซอฟต์แวร์ไม่ได้แค่ทำตามกฎนามธรรมบางอย่าง แต่เป็นเวิร์กโฟลว์ที่มีโครงสร้าง: ทุกโหนดคือขั้นตอนที่ชัดเจน และทุกขอบระหว่างโหนดคือเงื่อนไขที่ชัดเจน

นั่นฟังดูเหมือนมีโครงสร้างมาก แต่ส่วนใหญ่มีอยู่แล้วในซอฟต์แวร์ใดๆ เนื่องจากโค้ดใดๆ สามารถแสดงเป็นกราฟควบคุมการไหล (control-flow graph) ดังนั้นความแปลกใหม่ที่แท้จริงเพียงอย่างเดียวคือเอเจนต์ที่ยืนกรานในอิสระนั้นกำลังเดินไปรอบๆ กราฟเฉพาะ และอิสระของมันถูกจำกัดอยู่ภายในโหนด และนี่คือส่วนที่คนมักลืม ซึ่ง Dex เขียนไว้ เมื่อปีที่แล้ว: ซอฟต์แวร์มีโครงสร้างนั้นอยู่เสมอ มีเหตุผลที่เราเคยวาดโปรแกรมเป็นผังงาน (flow chart)

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

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

ในฐานะกราฟ สิ่งแรกที่คุณทำคือวางแผนว่าควรเกิดอะไรขึ้น ทำซ้ำบั๊กหรือไปขอข้อมูลเพิ่มเติม, หาสาเหตุ, ลองแก้ไข, รันการทดสอบ, และปล่อยให้การรันที่ล้มเหลวกลับไปที่ขั้นตอนการแก้ไข ในขณะที่การรันที่ผ่านไปยังขั้นตอนการตรวจสอบ ซึ่งมีเพียงการอนุมัติเท่านั้นที่จะถึงจุด "เสร็จ" เอเจนต์ยังคงฉลาดภายในแต่ละกล่อง; มันแค่ไม่สามารถเดินออกนอกเส้นทางที่คุณอนุญาต Santi วางผังนี้ด้วยแผนภาพที่ทำให้เห็นความแตกต่างได้ชัดเจน

แน่นอนว่า เสน่ห์ที่แท้จริงของกราฟนั้นคือมันคือแรงดันย้อนกลับที่วาดเป็นแผนภาพ คุณสละอิสระของเอเจนต์บางส่วนและได้รับการตรวจสอบที่บังคับและจุดล้มเหลวที่อ่านง่ายกลับคืนมา ดังนั้นเมื่อการรันตาย คุณสามารถชี้ไปที่โหนดที่ฆ่ามันได้ มันเป็นสัญชาตญาณเดียวกันกับที่อยู่เบื้องหลังคำพูดตรงไปตรงมาของ Dex ที่ว่าเอเจนต์ที่เรียกว่าเอเจนต์ส่วนใหญ่นั้นไม่ได้มีความเป็น agentic มากนักเลย "โค้ดที่กำหนดขึ้นเป็นส่วนใหญ่ โดยมีขั้นตอน LLM โรยไว้ตรงจุดที่เหมาะสม" และนี่ไม่ใช่แค่ผลพลอยได้จากวิธีที่ผู้คนบังเอิญสร้างสิ่งต่างๆ ในตอนนี้: คุณสามารถเห็นรูปแบบนี้ได้ใน LangGraph และ LlamaIndex Workflows, ในไฮบริดเวิร์กโฟลว์-กราฟ-เหนือ-เอเจนต์ของ Jerry Liu ที่มีลูปด้านนอกที่เติบโตส่วนต่างๆ ของกราฟในขณะที่มันทำงาน, และในคำเตือนของ David Khourshid ว่านี่คือ state machines และ actor model จริงๆ ที่กลับมาในชุดใหม่

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

ที่ที่มนุษย์อยู่จริงๆ

สังเกตว่ามนุษย์ไม่เคยออกจากโรงงาน พวกเขาย้ายที่อยู่

ฉันคิดว่าวิศวกรจำเป็นต้องเป็นเจ้าของ ลูปด้านนอก (outer loop) มากขึ้นเรื่อยๆ เอเจนต์สามารถตรวจสอบบั๊ก, เขียนรายงานการวินิจฉัย, ใช้การแก้ไข, รันการทดสอบ, และเขียนรายงาน นั่นคือการดำเนินการของลูปด้านใน และพวกมันสามารถทำได้อย่างมีประสิทธิภาพเท่ากับใครๆ แต่นั่นไม่เคยคืองาน สิ่งที่คุณเป็นเจ้าของคือสิ่งที่ฉันเรียกว่าลูปด้านนอก: ตัดสินใจว่านี่เป็นวิธีที่ถูกต้องในการแก้ปัญหาหรือไม่, ตรวจสอบว่าการวินิจฉัยและการนำไปใช้นั้นสมเหตุสมผล, อนุมัติการเปลี่ยนแปลง, และรับผิดชอบผลที่ตามมาหากผิดพลาด เส้นแบ่งระหว่างสองลูปคือหลักฐาน, diffs, การทดสอบ, log, และคำอธิบายสั้นๆ ที่เชื่อมโยงพวกมัน ชนิด, รอยต่อ, และ rubric ทำให้สามารถดูแลทั้งหมดนี้ได้โดยไม่ต้องทำงานมากมายสำหรับทุกการเปลี่ยนแปลง

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

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

Pangram ให้คะแนน บทความนี้ว่าเป็น 100% ที่เขียนโดยมนุษย์