จงเป็นเจ้าของลูปภายนอก

• แม้เอเจนต์จะรับหน้าที่ ลูปการทำงานภายใน ที่วนซ้ำระหว่างการสำรวจ·การลงมือทำ·การตรวจสอบ แต่วิศวกรก็ยังต้องเป็นเจ้าของ ลูปภายนอก ที่ตัดสินใจว่าจะปล่อยขึ้นใช้งานหรือไม่ และรับผิดชอบต่อผลลัพธ์
• ระบบเอเจนต์ทำงานบนพื้นฐานของ คุณภาพ (Quality) ซึ่งหมายถึงการตรวจสอบล่วงหน้า, คำตัดสิน (Verdict) ที่ใช้ตัดสินว่าจะนำเข้าสู่โปรดักชันหรือไม่, และ ความสามารถในการตอบอธิบาย (Answerability) ที่ทำให้สามารถอธิบายเหตุผลของการตัดสินใจได้
• จากผลสำรวจของ Sonar ในปี 2026 พบว่า 42% ของโค้ดที่ถูกคอมมิตนั้นสร้างโดย AI หรือได้รับความช่วยเหลือจาก AI อย่างมีนัยสำคัญ และเมื่อความเร็วในการสร้างแซงหน้าความเร็วในการควบคุม การรีวิว·การตรวจสอบ·ความเข้าใจ·การบำรุงรักษาจึงกลายเป็นทรัพยากรที่หายาก
• การใช้งาน AI มาพร้อมกับ การยอมจำนนทางความคิด ที่รับคำตอบผิดไปตรง ๆ, หนี้ทางความคิดที่ทำให้ความเข้าใจโค้ดอ่อนลง, และต้นทุนการประสานงานที่ต้องบริหารเอเจนต์หลายตัวด้วยความสนใจของมนุษย์ที่มีจำกัด
• โรงงานซอฟต์แวร์ที่ขยายได้เกิดขึ้นได้เมื่อไม่ได้ให้อิสระสูงสุดกับเอเจนต์ แต่ให้อิสระแบบ หยุดได้·ปรับได้·ตรวจสอบได้ และมนุษย์ยังรับผิดชอบต่อข้อจำกัด·การตรวจทานแบบสุ่มตัวอย่าง·การตรวจสอบย้อนหลัง·ความเป็นเจ้าของ และผลลัพธ์สุดท้าย

---

ลูปภายนอกของวิศวกรรมแบบเอเจนต์

• การถกเถียงเรื่องวิศวกรรมแบบเอเจนต์กำลังย้ายไปสู่เอเจนต์ harness และลูป, fleet, และ software factory
• ยิ่งมีโมเดลทรงพลังอย่าง Fable และ GPT-5.6 ปรากฏขึ้นมากเท่าไร วิศวกรก็ยิ่งต้องถือครองลูปภายนอกด้วยตนเอง ซึ่งหมายถึง ความรับผิดชอบ ต่อระบบ
• แรงทดของเอเจนต์ที่สูงขึ้นย่อมสร้างหน้าที่รับผิดชอบในระดับเดียวกัน
  • ต้องอธิบายได้อย่างแม่นยำว่ามีอะไรเปลี่ยนไปบ้าง
  • ต้องอธิบายได้ว่าทำไมการเปลี่ยนแปลงนั้นจึงปลอดภัย
  • ต้องรู้ว่าจะเกิดอะไรขึ้นหากการตัดสินใจนั้นผิดพลาด
• หากทำเงื่อนไขเหล่านี้ไม่ได้ ก็ไม่สามารถให้ความชอบธรรมกับการกระทำของเอเจนต์ได้ และองค์กรก็ยากจะใช้งานระบบแบบนั้น

คุณภาพ·คำตัดสิน·ความสามารถในการตอบอธิบาย

• คุณภาพ (Quality) หมายถึงการตรวจสอบทุกอย่างที่ติดตั้งไว้ก่อนปล่อยระบบออกไป และหลักฐานที่ได้จากตรงนี้คือฐานของคำตัดสิน
• คำตัดสิน (Verdict) คือการตัดสินใจขั้นสุดท้ายโดยมนุษย์ว่าจะนำงานนั้นเข้าสู่โปรดักชันหรือไม่ก่อนเข้าระบบที่พึ่งพาอยู่
  • ต่อให้โมเดลเป็นคนเขียนโค้ด คนที่ปล่อยงานภายใต้ชื่อตัวเองก็ยังเป็นผู้รับผิดชอบต่อคำตัดสิน
  • ต้องเลือกอย่างใดอย่างหนึ่งระหว่างปล่อยใช้งาน, บล็อก, เปลี่ยนเส้นทาง, ลดขอบเขตการตอบสนอง, เพิ่ม guardrail, หรือปฏิเสธทั้งหมด
• ความสามารถในการตอบอธิบาย (Answerability) คือการรับประกันว่าเมื่อมีคนถามเหตุผล ก็สามารถอธิบายคำตัดสินนั้นได้
• โมเดลอาจเขียนโค้ดได้หนึ่งบรรทัด แต่ไม่สามารถรับหน้าที่แทนในการตัดสินใจว่าจะส่งต่อเข้าสู่ระบบที่พึ่งพาอยู่หรือไม่

โมเดล·harness·ลูป·โรงงาน

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

เส้นแบ่งที่แยกระหว่างในระบบกับนอกระบบ

• ใจกลางของ software factory คือ เส้นแบ่งที่แยกระหว่างภายในและภายนอกระบบ
• ระบบภายในจะรวบรวมเป็นอินพุตทั้งเจตนาของทีมผลิตภัณฑ์ ความรู้เกี่ยวกับงานปล่อยใช้งานในอดีต เหตุขัดข้องล่าสุด และฟีดแบ็กผู้ใช้ที่เฉพาะเจาะจง
• ลูปของเอเจนต์จะสำรวจงาน ลงมือทำตามแผน และตรวจสอบผลลัพธ์
• เมื่อ หลักฐาน ที่สร้างจากการตรวจสอบข้ามเส้นแบ่งของระบบออกมา มนุษย์ที่เป็นเจ้าของระบบที่พึ่งพาอยู่จะเป็นผู้ตัดสินใจว่าจะเดินหน้าต่อหรือไม่
• ในอดีตเอเจนต์ทำได้เพียงบางส่วนของกระบวนการทำงาน แต่ตอนนี้สามารถรับทั้งลูปการทำงานภายในได้แล้ว และวิศวกรเป็นผู้รับผิดชอบลูปภายนอก
• สิ่งที่เอเจนต์ภายในขอบเขตมอบให้คือ ความสามารถ (capability)
  • สำรวจงาน
  • ลงมือทำตามแผน
  • ทดสอบผลลัพธ์
  • รายงานผลลัพธ์
• สิ่งที่มนุษย์นอกขอบเขตใช้อำนาจคือ agency
  • ตัดสินใจ
  • ตรวจสอบ
  • อนุมัติ
  • เป็นเจ้าของ

ช่องว่างด้านความเชื่อถือและการตรวจสอบที่เกิดจากโค้ด AI

• สัดส่วนของโค้ด AI ไม่ได้อยู่แค่ในระดับรอบนอกอีกต่อไป
• ตามรายงาน 2026 State of Code ของ Sonar 42% ของโค้ดที่ถูกคอมมิตนั้นสร้างโดย AI หรือได้รับความช่วยเหลือจาก AI อย่างมีนัยสำคัญ และผู้ตอบแบบสอบถามคาดว่าสัดส่วนนี้จะยังเพิ่มขึ้นต่อไป ไม่ได้หยุดนิ่ง
• เมื่อค่าใช้จ่ายในการสร้างโค้ดลดลง การรีวิว·การตรวจสอบ·ความเข้าใจ·การบำรุงรักษา จึงยิ่งกลายเป็นทรัพยากรที่หายาก
• เมื่อความเร็วในการสร้างเพิ่มขึ้นเร็วกว่าความเร็วในการควบคุม จึงเกิด ช่องว่างด้านความเชื่อถือ·การตรวจสอบ
  • หลายคนแสดงความไม่ไว้วางใจต่อโค้ด AI
  • แต่มีคนน้อยกว่านั้นที่แปลงความไม่ไว้วางใจให้กลายเป็นขั้นตอนการตรวจสอบที่สม่ำเสมอ
• จึงจำเป็นต้องมีวิธีที่ถูกกว่าและชัดเจนกว่านี้ในการยืนยันความน่าเชื่อถือของโค้ด AI

ข้อจำกัดของธรรมาภิบาลหลังเกิดเหตุ

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

แรงต้านย้อนกลับที่สร้างคุณภาพ

• คุณภาพสามารถมองได้ว่าเป็น แรงต้านย้อนกลับ (back pressure) ที่กระทำต่อระบบ
• เป้าหมายไม่ใช่การให้อิสระสูงสุดเท่าที่เอเจนต์จะมีได้
• ควรให้อิสระกับเอเจนต์เพียงเท่าที่สามารถหยุด ปรับ ตรวจงาน และรักษาบทบาทของมนุษย์ไว้ได้
• ในวิศวกรรมแบบเดิมมีสัญญาณที่แสดงอยู่แล้วว่างานกำลังไปในทิศทางที่ถูกต้องหรือไม่
  • type check
  • การทดสอบ
  • hook
  • ขีดจำกัดของ sandbox
  • audit log
  • monitor
• หากเอเจนต์ปล่อยสัญญาณแบบเดียวกันออกมา ก็สามารถใช้ระบบวิศวกรรมเดิมสร้างแรงต้านย้อนกลับที่เหมาะสมได้

ลูปสี่แบบที่มนุษย์ต้องอยู่ในนั้น

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

เอเจนต์ระยะยาวและความสามารถในการตอบอธิบาย

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

ต้นทุนแฝงสามอย่างของการมอบหมายงานให้ AI

• การยอมจำนนทางความคิด

  • การยอมจำนนทางความคิด (cognitive surrender) คือปรากฏการณ์ที่รับผลลัพธ์จาก AI มาแบบไม่ตั้งคำถาม
  • แม้มอบหมายงานให้เอเจนต์ ผลลัพธ์ก็ยังผูกกับงาน ชื่อเสียง และความรับผิดชอบของผู้ใช้
  • ข้อบกพร่องยังคงอยู่ในซอฟต์แวร์ของผู้ใช้
  • สิ่งที่ต้องเปลี่ยนให้เข้ากับผลลัพธ์ก็ยังเป็นซอฟต์แวร์ของผู้ใช้เอง
  • คำตอบของเอเจนต์สุดท้ายแล้วก็กลายเป็นคำตอบของผู้ใช้ และความรับผิดชอบก็ตามมาด้วย
  • ในงานวิจัยของ Wharton พบว่าแม้ AI จะตอบผิด ผู้เข้าร่วมเกือบ สามในสี่ ก็ยังยอมรับคำตอบนั้น และยังมีความมั่นใจสูงกว่าการตัดสินใจโดยไม่มี AI

• หนี้ทางความคิด

  • หนี้ทางความคิด (cognitive debt) คือภาวะที่ความเข้าใจและความจำเกี่ยวกับวิธีแก้ปัญหาอ่อนแอลง
  • เมื่อมอบหมายงานให้เอเจนต์ กระบวนการคิดก็ถูกส่งออกไปภายนอกด้วย
  • เวลาและพลังงานที่ต้องใช้เพื่อทำความเข้าใจ codebase ขนาดใหญ่ด้วยตัวเองอาจหาได้ยากระหว่างกระบวนการเรียนรู้
  • ผลคือผลงานที่เอเจนต์สร้างขึ้นอาจไปอยู่ในระดับที่เกินความสามารถปัจจุบันของผู้ใช้จะเข้าถึงได้
  • ยิ่งเวลาในการวางแผนของเอเจนต์ยาวขึ้น ช่องว่างระหว่างโค้ดที่สร้างขึ้นกับความเข้าใจของมนุษย์ก็ยิ่งกว้างขึ้น
  • ช่องว่างนี้สะสมได้ และต้นทุนในการไต่กลับขึ้นไปบนเส้นโค้งการเรียนรู้ก็เพิ่มขึ้นแทบเป็นแบบยกกำลัง
  • ในการทดลองแบบสุ่มมีกลุ่มควบคุมของ Anthropic คะแนนแบบทดสอบความเข้าใจของวิศวกรที่เขียนโค้ดด้วย AI อยู่ที่ 50% ต่ำกว่ากลุ่มที่เขียนเองซึ่งได้ 67% อยู่ 17 จุดเปอร์เซ็นต์

• ต้นทุนการประสานงาน

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

วิธีปกป้องความสนใจในระบบ brownfield

• ระบบ brownfield มีความเสี่ยงเป็นพิเศษ เพราะพฤติกรรมที่ต้องตรวจสอบย้อนหลังไม่ได้อยู่แค่ในโค้ด แต่ยังสะสมอยู่ใน บาดแผลและประวัติศาสตร์ ด้วย
• ในการตัดสินใจด้านสถาปัตยกรรม ควรให้ความสำคัญกับความสนใจของมนุษย์เป็นอันดับแรก
• การใช้ worktree·ขอบเขต·หลักฐาน สามารถลดการผูกติดกันระหว่างแผนเริ่มต้นกับงานที่เพิ่งถูกค้นพบระหว่างการลงมือทำได้
• ควรกำหนดเวลาสูงสุดให้กับความพยายามแก้ขั้นตอนที่ยังรันไม่ได้
• สิทธิ์ในการเปลี่ยนซอฟต์แวร์ควรถูกมอบให้ด้วยวิธี opt-in ที่เข้มงวด

Alpha·decay·taste

• รูปแบบหลักสามอย่างที่กำหนดเส้นทางอาชีพและผลงานในหลายสาขาคือ alpha·decay·taste
• Alpha คือพื้นที่นำหน้าที่ผู้ทำผลงานได้สูงสุดในการแข่งขันครอบครอง และเป็นสภาวะของการเดินหมากที่มีมูลค่าสูงที่สุด
• Decay คือรูปแบบที่ตกตะกอนแล้วซึ่งทุกคนเรียนรู้ได้ผ่านการทำซ้ำและการสังเกต และอาจมองได้ว่าเป็นช่วงนิ่งงันรูปแบบหนึ่ง
• Taste คือวิจารณญาณที่ตรวจจับแนวหน้าของ alpha หรือการเปลี่ยนแปลงของ decay ได้ก่อนที่หลักฐานจะปรากฏ
• ข้อเขียนของ Paul Graham ชี้ว่าเมื่อทุกคนสามารถสร้างอะไรก็ได้ การเลือกว่าจะสร้างอะไรยิ่งสำคัญขึ้น
• ตามนิยามของ Mitchell Hashimoto taste คือ การตัดสินใจเชิงคุณภาพที่มีคุณภาพสูง ในช่วงที่ยังไม่มีเกณฑ์วัดเชิงวัตถุ
• การเคลื่อนตัวของ alpha เกิดจากการเปลี่ยนแปลงของ taste และ decay จะหายไปเมื่อผู้คนเริ่มชอบสิ่งอื่น

ทำให้ taste กลายเป็นความสามารถที่นำไปปฏิบัติได้

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

ความต่างระหว่าง developer กับ engineer

• ทุกคนอาจเป็น developer ได้ แต่ไม่ใช่ทุกคนจะเป็น engineer
• developer จะกลายเป็น engineer เมื่อยอมรับ วินัยของงาน ที่เข้มงวดกว่า
  • การให้เหตุผลอย่างถี่ถ้วนและสมเหตุสมผล
  • การพิจารณาข้อจำกัดและ trade-off
  • การรับรู้ความเสี่ยงและขอบเขตการเปิดรับ
  • ความรับผิดชอบที่แท้จริง
• เมื่อวิศวกรรมยากขึ้น ผู้คนจะถอยออกจากงานแบบดูแลจัดการ และแยกบทบาทที่เคยผูกติดอยู่กับความเป็นช่างฝีมือออกมาเพื่อให้หน้าที่ของแต่ละคนชัดเจนขึ้น
  • คนทำต้นแบบ
  • คนสร้าง
  • คนจัดระเบียบ
  • คนขยายการเติบโต
  • คนบำรุงรักษา

เส้นแบ่งของระบบที่มีเพียงมนุษย์เท่านั้นที่ปกป้องได้

• มนุษย์ยังทำหน้าที่เพิ่ม alpha ที่เส้นแบ่งอีกฝั่งของระบบ
  • เลือกว่าสิ่งใดคุ้มค่าที่จะทำ
  • กำหนดว่าจะทำภายใต้ข้อจำกัดแบบใด
  • ตัดสินว่าหลักฐานเพียงพอหรือยังที่จะเดินหน้าต่อ
  • ดูแลผลลัพธ์
• ไม่ว่าจะเป็นทีมเดียวหรือ 100 ทีม เส้นแบ่งนี้มีเพียงมนุษย์เท่านั้นที่เป็นเจ้าของได้
• ความสนใจ·taste·ความรับผิดชอบ คือองค์ประกอบสำคัญที่ทำให้ software factory ทำงานได้
• หากไม่มีความรับผิดชอบ ก็จะไม่มีทั้งกฎ การตอบคำถาม trade-off ความเสี่ยง หรือ safety net
• หากไม่มีใครเป็นเจ้าของผลของการตัดสินใจ agency ที่สูงก็จะนำไปสู่ความโกลาหล

ลายเซ็นที่อยู่ยาวนานกว่าเทคโนโลยี

• ครึ่งชีวิตของความได้เปรียบทางเทคนิคอาจสั้นเพียงหนึ่งรีลีส แต่ครึ่งชีวิตของ ลายเซ็น (signature) ที่ทิ้งไว้ในงานอาจยาวตลอดทั้งอาชีพ
• ลายเซ็นหมายถึงการที่เราสามารถเอาชื่อตัวเองไปรับรองผลลัพธ์ที่ปล่อยออกไปได้
• เทคโนโลยีสร้างแรงทด และความรับผิดชอบเปลี่ยนแรงทดนั้นให้กลายเป็น ความเชื่อถือ
• ผู้ที่เลือกและรับมรดกของผลลัพธ์มีเพียงมนุษย์เท่านั้น
• เอเจนต์อาจเลือก กำหนดเส้นทาง merge หรือ escalate ภายใต้นโยบายได้ แต่ไม่สามารถรับมรดกของผลลัพธ์นั้นแทนได้

สัญญาความรับผิดชอบของ codebase

• แต่ละ codebase อาจต้องมี สัญญาความรับผิดชอบ ที่ระบุเงื่อนไขในการรับการเปลี่ยนแปลงเข้าไว้
  • เช็กลิสต์ยืนยันสิ่งที่เข้าใจตอนอนุมัติ
  • หลักฐานที่ใช้ประกอบการตัดสินใจ
  • ผู้รับผิดชอบต่อการเปลี่ยนแปลง
  • สถานะของระบบหลังจากบล็อกการเปลี่ยนแปลง
• สัญญานี้ควรกล่าวถึงความเชื่อมโยงระหว่างความสนใจและ taste, หลักฐาน·คำตัดสิน·ความเป็นเจ้าของ, รวมถึง alpha·decay·taste อย่างชัดเจน

บันไดของ agency ระดับสูง

• ใน workflow แบบเอเจนต์ agency ระดับสูง คือความสามารถในการรู้ว่าเมื่อใดควรมอบหมาย เมื่อต้องตรวจ เมื่อใดต้องหยุด และเมื่อใดต้องเป็นเจ้าของผลลัพธ์
• บันไดของ agency ไล่จากขั้นต่ำไปสู่ขั้นสูงดังนี้
  1. ทำเครื่องหมายปัญหาที่อาจเกิดขึ้น
  2. สำรวจปัญหา
  3. ลงมือทำงานตอบสนอง
  4. วินิจฉัยสาเหตุ
  5. เสนอแนวทางแก้ไข
  6. แนะนำวิธีแก้
  7. แก้ปัญหา
• ขั้นที่สูงกว่านั้นยังรวมถึง วิจารณญาณ ที่มองเห็นปัญหาแล้วตัดสินว่ามันไม่คุ้มค่าที่จะลงมือแก้ และปล่อยผ่านไป

ทำไม brownfield จึงเป็นแนวหน้าของ software factory

• brownfield คือ แนวหน้า ที่ software factory ซึ่งต้องการขยายตัวจะต้องเผชิญ
• ระบบ greenfield ควบคุมได้ทั้งระบบ จึงวางแผนและสร้างกลไกแรงต้านย้อนกลับที่เพียงพอได้ค่อนข้างง่าย
• แต่เมื่อเพิ่มเอเจนต์อัจฉริยะเข้าไปในระบบ legacy ต้องรับมือกับความซับซ้อนที่อยู่นอกโค้ดด้วย
  • พฤติกรรมทั้งหมดของโปรดักชัน
  • ความคาดหวังในอนาคตของลูกค้า
  • ประวัติการย้ายระบบ
  • รอบการรีลีสและงบประมาณ
  • สมมติฐานที่ไม่ได้พูดออกมา
  • กรณียกเว้น
  • ความแปลกเฉพาะของข้อมูล
  • ขั้นตอน runbook
  • บาดแผลที่สะสมมาโดยไม่มีการจัดการ
• การดูแล brownfield ต้องอาศัย วิศวกรรมที่ยั่งยืน
  • เปลี่ยนความรู้โดยนัยให้เป็นข้อจำกัดที่ชัดเจน
  • รักษาความรู้ให้สม่ำเสมอข้ามทีมและข้ามรุ่น
  • ทำให้ความรู้นั้นเป็นทางการในรูปขั้นตอนทดสอบและสเปกฟังก์ชัน
  • เชื่อมความรู้นั้นเข้ากับหลักฐานที่เป็นวัตถุวิสัย
  • สะสมความล้มเหลวให้เป็นการเรียนรู้เพิ่มเติม
• หากระดับการดูแลจัดการที่ระบบเคยได้รับสะดุดลง ระบบทั้งหมดอาจพังทลายได้

งานใหม่ที่เกิดขึ้นเมื่อขนาดใหญ่ขึ้น

• เมื่อองค์ประกอบเดิมถูกทำให้เป็นอัตโนมัติ มนุษย์จะใช้ alpha และ taste ที่มาจากประสบการณ์เชิงช่างของตนเพื่อออกแบบ งานใหม่
  • ออกแบบลูปใหม่ที่จะนำเข้าไปใช้กับ software factory
  • ใช้ความรู้ที่ได้จากโรงงานเพื่อสร้างระบบ greenfield ที่มีหลักการ
  • สร้างรูปแบบหลักฐานใหม่ที่ใช้ตรวจสอบระบบใหม่ได้
  • ดูแลระบบ brownfield ที่ซับซ้อนจนต้องมีการจัดการเฉพาะทาง
  • ออกแบบและดูแลกลไกแรงต้านย้อนกลับใหม่
  • ออกแบบเอเจนต์ใหม่
  • สร้างกรอบ agency ใหม่
• กิจกรรมเหล่านี้ล้วนเป็นงานวิศวกรรมจริง และยิ่งขยายขนาดก็ยิ่งกลายเป็นปัญหาที่น่าสนใจมากขึ้น

คอขวดที่การทำอัตโนมัติย้ายตำแหน่งไป

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

โมเดลการปฏิบัติการของวิศวกรรมแบบเอเจนต์

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