วิศวกรคนหนึ่งเล่าว่า ในวันทำงานปกติเขารัน AI agent ขนานกันแปดตัว คนอื่นที่ทำงานแบบเดียวกันบอกว่าสิบบ้าง สิบสองบ้าง แต่พอเกินจุดนั้นไป เปิด agent เพิ่มก็ไม่ได้ทำให้งานเร็วขึ้น เพราะคนคุมตามทุกงานไม่ทันและกลายเป็นคอขวดเสียเอง

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

คอขวดไม่ได้ย้ายตามเฟสของ software delivery lifecycle

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

แต่กรอบนี้ยังอธิบายไม่ได้ว่าทำไมคนที่เปิด agent สิบสองตัวถึงตัน ข้อจำกัดที่เริ่มชัดขึ้นไม่ได้อยู่ในเฟสใดเฟสหนึ่งของงาน AI ไม่ได้เปลี่ยนมาตรฐานของซอฟต์แวร์ที่ดี แต่ทำให้ความสนใจของคนกลายเป็นทรัพยากรที่ขาดแคลน

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

งานที่เหลือให้คนทำคือการคุมวง

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

ในภาพนี้ agent คือนักดนตรี dev คือวาทยกร ส่วนงานที่คนต้องทำจริงๆ มีดังนี้

• เลือกว่าโจทย์ไหนควรไปอยู่กับ agent ตัวไหน
• ป้อน context ที่มันต้องใช้
• ตรวจของที่ส่งกลับมา
• จับข้อผิดพลาดเล็กๆ ที่มองข้ามได้ง่าย
• ตัดสินว่าชิ้นไหนควรวนอีกรอบ ชิ้นไหนพร้อมไปต่อ

แต่ละข้อใช้เวลาไม่นาน ทว่าทุกข้อต้องใช้ความสนใจ และงานแต่ละชิ้นก็กลับมาให้จัดการคนละจังหวะโดยไม่ได้นัดหมาย

คนที่เคยทำงานแบบนี้มาก่อน ก็เคยวินิจฉัยตัวเองผิด

Rachel Laycock ผู้เขียนบทความนี้เป็น CTO งานประจำวันของเธอจึงคล้ายภาพข้างต้น เธอแทบไม่ได้เป็นคนลงมือทำชิ้นงานเองแล้ว แต่ต้องดูหลายสายงานที่เดินพร้อมกัน ทั้งเอกสารกลยุทธ์ที่ส่งกลับมาให้ช่วยดู โอกาสฝั่งลูกค้าที่รอการตัดสินใจ คำถามเรื่อง trade-off ทางเทคนิค และทีมที่ต้องได้ context ก่อนถึงจะไปต่อได้ เรื่องทั้งหมดไหลเข้ามาโดยไม่มีโครงสร้างตายตัว ผ่านบทสนทนา อีเมล เอกสาร ข้อความแชท รวมถึงไอเดียที่ยังคิดไม่จบ งานของเธอคือเลือกว่าจะใส่ใจเรื่องไหน ปะติดปะต่อข้อมูลที่ยังไม่ครบ ป้อน context ให้คนอื่น แล้วทำให้แต่ละสายเดินหน้าต่อ

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

อาการเหล่านี้ตรงกับวันทำงานของคนที่คุม agent หลายตัวจนน่าตกใจ ใครที่กำลังโทษตัวเองว่าจัดตารางได้ไม่ดีพอ อาจกำลังวินิจฉัยปัญหาผิดจุดเหมือนกัน

สี่ข้อที่โค้ชผู้บริหารสอนไว้

โค้ชผู้บริหารคนหนึ่งสอนเธอไว้สี่ข้อ และเธอยังใช้มาจนถึงตอนนี้

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

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

องค์กรโค้ชผู้บริหารมาหลายสิบปี แต่ยังไม่เคยโค้ช dev

Laycock ไม่ได้บอกว่า dev กำลังจะกลายเป็น manager หรือ AI จะมาแทนงานวิศวกรรม เรายังต้องใช้ความเชี่ยวชาญทางวิศวกรรม เพียงแต่ใช้ในจุดอื่นของงานและใช้ถี่ขึ้นมาก เพราะขั้นตอนลงมือทำเร็วขึ้น คำถามที่ต้องตัดสินใจจึงไหลมาถึงเร็วกว่าเดิม

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

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

---

ที่มา: บทความ The Conductor Developer จาก Rachel Laycock