หัวข้อต้นฉบับ: ภาษีการจัดระบบ

ผู้เขียนต้นฉบับ: Addy Osmani

แปลและเรียบเรียง: Peggy

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

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

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

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

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

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

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

สิ่งที่เรียกว่า "ภาษีการจัดระเบียบ" (Orchestration Tax) โดยพื้นฐานแล้วคือราคาที่คุณจ่ายเมื่อลืมข้อเท็จจริงนี้ และทางออกที่แท้จริงเพียงอย่างเดียวคือการเริ่มออกแบบความสนใจของคุณเอง เหมือนกับการออกแบบระบบคอนเคอร์เรนต์ใดๆ

ก่อนหน้านี้ผมได้เข้าร่วมเสวนาแบบโต๊ะกลมที่ Google I/O ร่วมกับ Richard Seroter, Aja Hammerly และ Ciera Jaspan พูดคุยเกี่ยวกับสถานะปัจจุบันของวิศวกรรมซอฟต์แวร์และแนวโน้มการพัฒนาในอนาคต เมื่อใกล้จบ Richard ถามเราว่า สิ่งหนึ่งที่นักพัฒนาควรนำกลับไปและเปลี่ยนแปลงมากที่สุดหลังจากฟังเสร็จคืออะไร

ผมตอบสิ่งที่คิดซ้ำแล้วซ้ำเล่ามาหลายเดือนว่า การรู้สึกว่าตัวเองยุ่ง ไม่ได้หมายความว่ามีผลผลิตจริง คุณสามารถรัน Agent 20 ตัวพร้อมกันและรู้สึกยุ่งมาก แต่ไม่ได้หมายความว่าคุณส่งมอบงานเทียบเท่ากับ Agent 20 ตัว

ในช่วงต้นของการสนทนานั้น Richard ตั้งชื่อให้กับปัญหานี้ เขาบอกว่า "สิ่งที่คุณเพิ่งพูดถึงคือภาษีการจัดระเบียบ คุณไม่สามารถจัดการ Agent 20 ตัวในสมองของคุณเองได้สำเร็จ"

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

ในเสวนานั้นมีประโยคหนึ่งที่ผมพูดออกไปแบบไม่คิดมาก แต่กลับติดอยู่ในใจผมตลอดมา: การรัน Agent หลายตัว ไม่ได้หมายความว่ามีคุณเพิ่มขึ้นอีกคนในโลก

ความไม่สมมาตรที่ผู้คนไม่ได้นับรวม

ในเวิร์กโฟลว์ของ Agent มีความไม่สมมาตรที่ซ่อนอยู่

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

คนนั้นคือคุณ และคุณมีแค่คนเดียว

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

เมื่อคุณเริ่มมองการพัฒนา Agent เป็นระบบที่ทำงานพร้อมกัน (concurrent system) คุณจะตระหนักว่ามนุษย์เองก็เป็นเพียงส่วนประกอบหนึ่งในระบบนี้เท่านั้น เป็นส่วนประกอบแบบอนุกรมที่ช้ามาก

คุณคือทรัพยากรแบบเธรดเดียว

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

Python มี Global Interpreter Lock หรือ GIL คุณสามารถสร้างเธรดได้กี่อันก็ได้ แต่ในเวลาเดียวกันจะมีเพียงเธรดเดียวเท่านั้นที่สามารถรัน Python bytecode ได้ เพราะทุกเธรดต้องขอรับล็อคนี้ก่อน

คุณคือ GIL ของ AI Agent ของคุณ

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

กฎของ Amdahl อธิบายเรื่องนี้ได้อย่างแม่นยำ: ขีดจำกัดสูงสุดของการเร่งความเร็วจากการทำ parallelization ขึ้นอยู่กับส่วนที่ยังต้องทำงานแบบอนุกรมในกระบวนการ ถ้ากระบวนการของคุณมีส่วนที่ไม่สามารถทำ parallel ได้มาก ไม่ว่าคุณจะเพิ่ม core กี่ตัว สุดท้ายก็จะชนขีดจำกัดแข็ง

ในการพัฒนา Agent ส่วนที่เป็นอนุกรมนี้คือวิจารณญาณ (judgment)

การเปิด Agent 8 ตัวไม่ได้ช่วยเร่งเวลาการตัดสินใจของคุณ มันแค่ทำให้คิวที่รอคุณจัดการยาวขึ้นเท่านั้น

นี่คือความจริงเก่าแก่ในวิศวกรรมประสิทธิภาพ แต่หลายคนยังคงประหลาดใจกับมัน: การปรับแต่งส่วนที่ไม่ใช่คอขวดไม่ได้ช่วยเพิ่ม throughput โดยรวม คุณแค่กองงานที่ยังไม่เสร็จไว้ข้างหน้าคอขวดเท่านั้น

การเพิ่ม Agent ช่วยปรับแต่งส่วนที่ไม่ใช่ข้อจำกัดอยู่แล้ว ข้อจำกัดที่แท้จริงคือขั้นตอนการ review และ throughput ของทั้งระบบก็เท่ากับ throughput ของขั้นตอนนี้พอดี

ภาษีการจัดเรียง (Orchestration Tax) คือช่องว่างเชิงโครงสร้างระหว่างความสามารถในการผลิตของ Agent กับสิ่งที่คุณสามารถรวมเข้าด้วยกันได้จริง มันเกิดขึ้นเมื่อคุณให้ทรัพยากรแบบเธรดเดียวจัดการระบบที่ทำงานพร้อมกัน

การฝืนทนไม่สามารถแก้ขีดจำกัดเชิงโครงสร้างได้

ในงานเสวนาครั้งนั้น ฉันพูดประโยคหนึ่ง: ฉันไม่เคยรู้สึกว่าเครื่องมือของฉันมีประสิทธิภาพเท่านี้มาก่อน แต่ฉันก็ไม่เคยรู้สึกเหนื่อยเท่านี้มาก่อนเช่นกัน

ความรู้สึกทั้งสองนี้เป็นจริงอย่างสมบูรณ์ และมันมาจากสาเหตุเดียวกัน

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

ทุกครั้งที่คุณหันกลับไปตรวจสอบ Agent ที่หลุดจากขอบเขตความสนใจของคุณไปแล้ว คุณต้องจ่ายต้นทุนการสลับบริบท (context switching cost) คุณต้องล้างสมองและโหลดบริบทอื่นจากศูนย์อีกครั้ง

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

Agent 5 ตัวไม่ใช่การทำงาน 1 เท่าซ้ำ 5 ครั้ง มันคือการโหลดบริบทแบบ Cold Start 5 ครั้ง บวกกับกระบวนการสมองที่ทำงานเบื้องหลัง คอยกังวลว่าตอนนี้คุณควรไปตรวจสอบ Agent ตัวไหน

คุณไม่สามารถแก้ไขข้อจำกัดเชิงโครงสร้างด้วยการ "พยายามมากขึ้น" ภาษีนี้ต้องจ่ายเสมอ

ถ้าคุณพยายามฝืน มันจะปรากฏในรูปแบบอื่นในที่สุด: ไม่ว่า Code Review จะตื้นเขินขึ้นเรื่อยๆ หรือคุณเข้าสู่สภาวะ "ยอมแพ้ทางปัญญา" (Cognitive Surrender) เพราะการสร้างวิจารณญาณของตัวเองใช้ความสนใจมากเกินไป คุณก็แค่ยอมรับโค้ดที่ Agent เขียนไปตรงๆ

คุณจะจ่ายภาษีนี้อย่างตั้งใจ หรือปล่อยให้มันค่อยๆ ทำลายความเข้าใจในระบบของคุณอย่างเงียบๆ

ออกแบบความสนใจของคุณเหมือนออกแบบระบบ

ดังนั้น คุณต้องปฏิบัติต่อความสนใจของตัวเองเหมือนทรัพยากรแบบ Serial ที่หายาก

คุณจะไม่ออกแบบระบบกระจายศูนย์ (Distributed System) โดยไม่คิดถึงคอขวด (Bottleneck) ดังนั้น โปรดให้ความเคารพสมองของคุณแบบเดียวกัน

ต่อไปนี้คือวิธีที่ได้ผลจริงสำหรับฉัน:

ขยายทีม Agent ตามความสามารถในการ Review ไม่ใช่ตามความสามารถของ UI

ระบบ Concurrent ที่ดีใช้กลไก Backpressure เพื่อป้องกันไม่ให้คิวเติบโตไม่สิ้นสุด ผู้ผลิตต้องช้าลงเพื่อให้ตรงกับความสามารถในการประมวลผลของผู้บริโภค

จำนวน Agent ของคุณคือผู้ผลิต ความสามารถในการ Review ของคุณคือผู้บริโภค จำนวน Agent แบบขนานที่ถูกต้องคือจำนวนที่คุณสามารถทำ Code Review ได้อย่างจริงจัง สำหรับคนส่วนใหญ่ นี่มักจะเป็นเลขหลักเดียวที่ต่ำ

เครื่องมือ AI ยินดีให้คุณเปิด Agent 20 ตัว แต่นั่นเป็นแค่ฟีเจอร์ของ UI ไม่ได้หมายความว่าคุณมีความสามารถในการจัดการมันจริงๆ

จัดหมวดหมู่ภารกิจ

เมื่อ Richard ถามฉันว่าจัดการเรื่องนี้อย่างไร ฉันพูดถึงวิธีนี้ ฉันจะแบ่งภารกิจออกเป็นสองกอง

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

กองที่สอง คืองานที่ซับซ้อน ซึ่งตัวงานจริงๆ คือการตัดสินใจ เช่น บั๊กที่แปลกประหลาด หรือการออกแบบสถาปัตยกรรม

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

การตรวจสอบแบบเป็นชุด

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

ให้สายจูงที่ยาวขึ้นกับ Agent ปล่อยให้งานสะสมเล็กน้อย แล้วจัดการมันเป็นชุดเดียว

ใช้ล็อคนี้เฉพาะกับการตัดสินใจ

อย่าใช้สมองของคุณไปกับสิ่งที่เครื่องจักรสามารถตรวจสอบได้เอง ให้ Agent เขียนเทสต์ที่ผ่านได้ หรือสร้างภาพหน้าจอ

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

ปกป้องเวลาที่เป็นลำดับของคุณ

คอขวดต้องการเวลาที่ดีที่สุดของคุณ ไม่ใช่เศษเวลาที่เหลือระหว่างการตรวจสอบ Agent หลายๆ ครั้ง

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

การจัดระบบไม่ใช่งานจริงๆ มันเป็นเพียงค่าใช้จ่ายที่เกิดจากงาน

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

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

ความยุ่งวุ่นวายไม่เท่ากับการผลิตที่สูง

สิ่งนี้สำคัญมาก เพราะรูปแบบความล้มเหลวนี้แทบจะมองไม่เห็นสำหรับตัวคุณเอง

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

คุณสามารถยุ่งจนถึงขีดสุด แต่แทบไม่มีผลงานจริงเลย จากมุมมองภายใน ประสบการณ์ทั้งสองนี้แทบจะเหมือนกัน

Ciera พูดถึงงานวิจัยของ Margaret-Anne Storey เกี่ยวกับหนี้สิน เราคุยกันถึงหนี้ทางเทคนิค และหนี้ทางปัญญา

ภาษีการจัดระเบียบที่ไม่ได้จ่าย จะทำให้คุณสะสมหนี้ทั้งสองประเภทนี้พร้อมกัน

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

ดังนั้น บทสรุปที่แท้จริงคือ: การเปิดใช้งานเอเจนต์ไม่ใช่ความสามารถ ใครๆ ก็สามารถรัน 20 ตัวได้

ความสามารถที่แท้จริงคือการออกแบบระบบรอบทรัพยากรแบบอนุกรมที่ไม่สามารถโคลนหรือทำแบบขนานได้

ทรัพยากรนั้นคือความสนใจของคุณ

ออกแบบมันเหมือนกับที่คุณออกแบบส่วนประกอบสำคัญที่ต้องพึ่งพาในสภาพแวดล้อมการผลิต

[ลิงก์ต้นฉบับ]

ยินดีต้อนรับสู่ชุมชนทางการของ BlockBeats:

กลุ่ม Telegram สมัครสมาชิก: https://t.me/theblockbeats

กลุ่ม Telegram พูดคุย: https://t.me/BlockBeats_App

บัญชี Twitter ทางการ: https://twitter.com/BlockBeatsAsia