วิศวกรรมเชิงความน่าจะเป็นและพนักงาน 24/7

• การพัฒนาซอฟต์แวร์กำลังเปลี่ยนผ่านอย่างเงียบ ๆ จาก ระบบเชิงกำหนดตายตัวไปสู่ระบบเชิงความน่าจะเป็น และในยุคที่ AI agent สร้าง·รีวิว·รวมโค้ดได้ตลอดทั้งคืน บทบาทของนักพัฒนาและโครงสร้างองค์กรก็กำลังเปลี่ยนไปอย่างรากฐาน
• ภายในทีม AI-native บทบาทต่าง ๆ กำลังขยับขึ้นสู่ระดับสูงกว่าเดิมพร้อมกับ แตกย่อยลงสู่ระดับล่าง ในเวลาเดียวกัน และมีความเสี่ยงที่งานง่าย ๆ แบบการคอยดูแลผลลัพธ์จาก agent จะกลายเป็นสายงานค่าแรงต่ำรูปแบบใหม่
• เมื่อค่าใช้จ่ายในการสร้างโค้ดเข้าใกล้ศูนย์ ปริมาณโค้ดก็พุ่งขึ้นแบบ Jevons’s paradox แต่โจทย์สำคัญคือ การสร้างถูกลง ขณะที่การตรวจสอบไม่ได้ถูกลงตาม
• วิศวกรจูเนียร์ที่เริ่มต้นด้วยการพึ่ง AI และสร้างโค้ดที่ดูขัดเกลาแล้วตั้งแต่แรก กำลังเผชิญกับ วิกฤตการฝึกฝนด้านดีบัก การใช้วิจารณญาณ และความเป็นช่างฝีมือ ซึ่งเกิดขึ้นจริงแล้ว
• เนื่องจากโมเดลปัจจุบันคือโมเดลที่อ่อนที่สุดในบรรดาโมเดลที่จะถูกใช้งานต่อจากนี้ องค์กรจึงต้องสร้าง ระบบที่เตรียมพร้อมสำหรับโมเดลอนาคตที่ยังไม่เปิดตัว ไม่ใช่ยึดอยู่กับขีดความสามารถของวันนี้

---

การเปลี่ยนผ่านสู่วิศวกรรมเชิงความน่าจะเป็น

• อุตสาหกรรมซอฟต์แวร์ถูกสร้างขึ้นบน สัญญาแบบเชิงกำหนดตายตัว มาหลายทศวรรษ — เขียนโค้ด ทดสอบ และปล่อยใช้งาน แล้วก็มีหลักประกันว่ามันจะทำงาน
• แต่สัญญานี้กำลังพังทลาย และในหมู่ผู้ปฏิบัติการระดับสูงของบริษัท AI-native นั้น codebase กำลังกลายเป็นสิ่งที่ “เชื่อว่า น่าจะทำงาน” โดยไม่อาจระบุความน่าจะเป็นที่แน่ชัดได้อีกต่อไป
• จุดเริ่มต้นมาจากประสบการณ์สร้าง side project ชื่อ Compound Loop — ระบบที่ให้ โมเดล frontier หลายตัวถกเถียงกันเอง เพื่อเขียน รีวิว และรวมโค้ดแบบอัตโนมัติ
  • ก่อนนอนก็สั่งให้ระบบทำงานกับปัญหาจริง แล้วตอนเช้าก็ลุกมาคัดแยก PR stack ที่เมื่อคืนยังไม่มีอยู่เลย
  • บางอันยอดเยี่ยม บางอันมีข้อผิดพลาด และบางอันก็ทำให้คำถามที่เราไม่ได้ถามโผล่ขึ้นมา
• นี่เป็นครั้งแรกในประวัติศาสตร์แรงงานความรู้ที่คนเลิกงานไปแล้ว แต่ ไม่ได้พาสำเนาสมองเพียงชุดเดียวออกจากระบบไปด้วย
• แนวคิด 9-9-6 แทบตายไปแล้ว และคำว่าพนักงาน 24/7 ไม่ได้หมายถึงคนที่ทำงาน 24 ชั่วโมง แต่หมายถึงคนที่มี agent ทำงานแบบขนานในวงกว้าง แทน
• จนถึงปี 2026 ทีมส่วนใหญ่ก็ยังติดคอขวดอยู่ที่ การประสานงาน (coordination) มากกว่าการพิมพ์โค้ด และการปรับโครงสร้างองค์กรก็ยังอยู่แค่ระยะเริ่มต้น

การแตกย่อยของบทบาท — เกิดทั้งการเลื่อนขึ้นและเลื่อนลงพร้อมกัน

• ภายในทีม AI-native มีรูปแบบที่ซับซ้อนกว่าคำเล่าแบบเรียบง่ายที่ว่า “ทุกคนยกระดับขึ้น” มาก
• การขยับขึ้นสู่ระดับสูงกว่าเดิม: วิศวกรที่เก่งที่สุดกำลังกลายเป็น PM ที่มีประสิทธิภาพมากขึ้น, PM ที่เก่งที่สุดกำลังกลายเป็น system architect, และ architect ที่เก่งที่สุดก็กำลังขยับไปคิดเรื่อง distribution, growth และโครงสร้างตลาด
  • สำหรับคนกลุ่มนี้ นี่คือสภาพแวดล้อมการทำงานที่มี leverage สูงที่สุดเท่าที่เคยมีมา
• การแตกย่อยลงสู่ระดับล่าง: ขณะเดียวกัน วิศวกรจำนวนมากไม่ได้กลายเป็น architect แต่กำลังเปลี่ยนไปเป็น คนเขียนสเปก, reviewer, และ agent babysitter
  • พวกเขาทำหน้าที่แปลงเจตนาของมนุษย์ให้เป็น prompt ที่เครื่องอ่านได้ และให้คะแนนงานของเครื่องตามมาตรฐานที่ตัวเองก็ไม่ได้ครอบครองอย่างสมบูรณ์
  • บางส่วนเป็นงานสำคัญ แต่บางส่วนก็เป็นเพียง งานป้อนข้อมูลฉบับปี 2026 ที่ถูกห่อด้วยคำศัพท์ใหม่
• บทบาทที่แตกย่อยออกมานี้มีแนวโน้มจะได้ค่าจ้างต่ำกว่า ถูกประเมินคุณค่าต่ำกว่า และในหลายกรณีอาจกลายเป็น ทางตันของอาชีพ
• ช่องว่างรายได้ระหว่าง คน 1 ใน 3 ระดับบน ที่ควบคุม fleet ของ agent ได้อย่างมีประสิทธิภาพ กับคนชั้นกลางที่คอยจัดการผลลัพธ์ อาจกว้างกว่าช่องว่างรายได้ระหว่างวิศวกรกับฝ่ายขายในยุคก่อนเสียอีก
• ในโครงสร้างพื้นฐาน AI นั้น ประสิทธิภาพระดับ kernel, การออกแบบ compiler, และ hardware abstraction ยังเป็น moat ที่ป้องกันได้อยู่ — ที่ชั้นล่างสุดของ system engineering ก็ยังต้องการความแม่นยำแบบเชิงกำหนดตายตัวในระดับสูง

Jevons’s paradox — ฉบับโค้ด

• ในปี 1865 นักเศรษฐศาสตร์ William Stanley Jevons สังเกตว่าเครื่องจักรไอน้ำที่มีประสิทธิภาพมากขึ้นไม่ได้ทำให้การใช้ถ่านหินลดลง แต่กลับ เพิ่มขึ้น — เพราะประสิทธิภาพที่ดีขึ้นทำให้ขอบเขตของสิ่งที่ควรสร้างด้วยเครื่องจักรนั้นกว้างขึ้น
• เมื่อค่าใช้จ่ายต่อหน่วยของการเขียนโค้ดเข้าใกล้ศูนย์ ซอฟต์แวร์ก็เผชิญกับปรากฏการณ์เดียวกัน — ไม่ใช่ว่าเราจะเขียนน้อยลง แต่คือ เขียนมากขึ้นและปล่อยมากขึ้นอย่างมหาศาล
• บริษัทที่เชื่อว่ากฎการสเกลไม่มีที่สิ้นสุดกำลังสร้างองค์กรให้สอดรับกับความเชื่อนั้น และบริษัทเหล่านี้จะเป็นผู้ชนะใน distribution แบบ power law
• สิ่งที่กำลังเกิดขึ้นจริงในภาคสนามแล้ว:
  • agent เปิด PR, รีวิวงานของกันและกัน, แล้วปิดงานโดยที่มนุษย์ไม่ได้แตะแป้นพิมพ์เลย
  • test suite ที่ซ่อมตัวเองได้ เขียนใหม่เองเมื่อโค้ดฐานเปลี่ยน
  • experimental loop แบบอัตโนมัติสามารถรัน วัดผล และยุบ 100 สมมติฐาน ในช่วงเวลาที่ทีมสมัยก่อนทำได้เพียง 3 อย่าง
  • เอกสารถูกอัปเดตอัตโนมัติระหว่าง merge และใช้ AI skill ที่พัฒนาตัวเองได้
• ทีมที่ปรับโครงสร้างโดยยึด agent เป็นศูนย์กลาง กำลังทำผลงานได้ 3 เท่า, 5 เท่า, 10 เท่า เมื่อเทียบกับปีก่อน และกราฟก็ยังไม่แบน แต่ยังพุ่งขึ้นอยู่
• บทเรียนข้อที่สองจาก Jevons: เมื่ออุปทานระเบิดขึ้น การคัดเลือก (selection) คือหัวใจสำคัญ
  • ผู้ปฏิบัติการที่สั่งการ fleet ของ agent ให้ทำปัญหาที่ถูกต้อง กรองสิ่งที่มีคุณค่าจากผลลัพธ์ และรวมผลให้กลายเป็นสิ่งที่สอดคล้องกัน กำลังทำงานที่มี leverage สูงที่สุดในซอฟต์แวร์ ตอนนี้
  • คุณค่าของงานไม่ได้ถูกกำหนดจากแรงในการผลิตอีกต่อไป แต่ถูกกำหนดจาก การตั้งทิศทาง การคัดเลือก และความสอดคล้อง

จากวิศวกรรมเชิงกำหนดตายตัวสู่วิศวกรรมเชิงความน่าจะเป็น

• วิศวกรรมเชิงกำหนดตายตัวคือสัญญาที่ครองประวัติศาสตร์ซอฟต์แวร์เกือบทั้งหมด — เขียนโค้ด ทดสอบ รีวิว แล้วเราก็พอจะเข้าใจได้ว่ามันจะทำงานอย่างไรในขอบเขตที่รู้จัก และบั๊กคือสิ่งที่ ทำซ้ำให้เกิดขึ้นได้
• วิศวกรรมเชิงความน่าจะเป็นมาถึงทีม frontier แล้ว — codebase ส่วนใหญ่ถูกสร้างโดยระบบเชิงความน่าจะเป็น ถูกรีวิวภายใต้แรงกดดันด้านเวลา และถูกรวมเข้ากับองค์รวมที่ไม่มีมนุษย์คนใดออกแบบทั้งหมดเพียงลำพัง
• ความไม่สมมาตรที่สำคัญคือ การสร้างถูกลง แต่การตรวจสอบไม่ได้ถูกลง
  • agent สามารถสร้าง PR 500 บรรทัดได้ภายใน 1 นาที แต่การจับบั๊กละเอียดอ่อนอย่างปัญหา concurrency, การตีความสเปกผิด, หรือการ implement ไม่ตรงเจตนา อาจใช้เวลาของวิศวกรอาวุโส มากกว่า 1 ชั่วโมง
  • การรีวิวสเกลได้ช้ากว่าการสร้าง และสเกลกับปริมาณผลลัพธ์ได้ แย่กว่าแบบเชิงเส้น — ยิ่ง codebase ถูกเขียนโดย agent มากขึ้นเท่าไร บริบทที่ต้องใช้ประเมินแต่ละชิ้นก็ยิ่งมากขึ้นเท่านั้น
• เมื่อเกินขนาดหนึ่ง ระบบจะผลิตมากกว่าที่มนุษย์จะประเมินได้อย่างน่าเชื่อถือ และความถูกต้องก็เริ่มกลายเป็นเรื่องของความน่าจะเป็น
• ตัวอย่างที่เป็นรูปธรรม: race condition ที่ผ่าน test suite ได้ 9 ใน 10 ครั้ง, ฟีเจอร์ที่สมบูรณ์แบบใน staging แต่ล้มเหลวกับ distribution ของ prompt ที่ไม่คาดคิด, หรือ migration ที่ทำให้ข้อมูลเสียหายแบบเงียบ ๆ เพียง 1 แถวจาก 10,000 แถว และเพิ่งถูกพบหลังจากผ่านไป 3 สัปดาห์
• Proximal และ Modular ได้เผยแพร่งานวิจัยร่วมเกี่ยวกับ การทดสอบงานพื้นฐานของระบบ agent frontier และรูปแบบความล้มเหลวที่มีการบันทึกไว้ก็สอดคล้องกับปรากฏการณ์นี้โดยตรง
• รูปแบบความล้มเหลวไม่ได้มาแบบพังครืน แต่เป็น การเสื่อมถอยอย่างช้า ๆ และเงียบ ๆ — การสร้างเพิ่มขึ้น คุณภาพการรีวิวลดลง ข้อบกพร่องที่มองไม่เห็นสะสม และความเชื่อมั่นค่อย ๆ ถูกกัดกร่อนจนกว่าลูกค้า การตรวจสอบ หรือ production incident จะทำให้ปัญหาโผล่ขึ้นมา
• ขณะนี้ยังไม่มีเครื่องมือที่แก้ปัญหานี้ได้อย่างแท้จริง — การ merge ทีละเล็ก การตั้ง gate ที่เข้มงวด ความ ไม่ไว้ใจอย่างไร้ปรานี ต่อผลลัพธ์ที่ดูขัดเกลาแล้ว รวมถึง observability และวินัยเรื่อง rollback เป็นมาตรการเชิงวัฒนธรรมที่ช่วยได้ แต่เมื่อทีมใหญ่เกินจุดหนึ่ง วัฒนธรรมก็สเกลต่อไม่ได้
• ใครก็ตามที่แก้ปัญหานี้ได้ จะเป็นผู้กำหนด ระบบปฏิบัติการของการพัฒนาซอฟต์แวร์จริงจังในอีก 10 ปีข้างหน้า

ความเร็วในการเปลี่ยนผ่านที่ต่างกันตามอุตสาหกรรม

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

• ชั้นเชิงกำหนดตายตัว

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

• ชั้นเชิงความน่าจะเป็น

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

• เขตบรรจบ (Convergence Zone)

  • เมื่อโมเดลฉลาดขึ้นและ harness ดีขึ้น แนวหน้าของพื้นที่ที่ “ทำแบบ probabilistic ก็ยังปลอดภัยพอ” ก็จะขยับต่อไปเรื่อย ๆ
  • วิธีแบบ probabilistic จะ คืบเข้าไปทีละ 10% จากด้านล่าง ในโดเมนที่ตอนนี้ยังดูเป็น deterministic เช่น ประกันสุขภาพ, healthcare บางส่วน, และ enterprise infrastructure บางส่วน
  • ผู้นำด้านวิศวกรรมเชิงความน่าจะเป็นกำลัง สร้าง deterministic guardrail กลับขึ้นมาใหม่ — เช่น formal check, critical path ที่ผ่านการตรวจสอบ, และระบบไฮบริดที่ให้การสร้างแบบ probabilistic ถูกล้อมกรอบด้วยการตรวจสอบแบบ deterministic
• ผู้ชนะในอีก 10 ปีข้างหน้าคือ ทีมที่รู้ว่าตัวเองอยู่ชั้นไหน ต่อต้านสิ่งล่อใจที่จะเสแสร้งว่าอยู่ในอีกชั้นหนึ่ง และกำหนดขอบเขตภายในสแตกของตัวเองได้อย่างแม่นยำ

Agentic Fleet

• “กะโรงงาน” ไม่ใช่อุปมาที่เหมาะสม — เพราะแรงงานโรงงานเคยเป็นระบบที่ถูกทำให้เป็นอัตโนมัติ แต่ตัวแสดงในตอนนี้ไม่ใช่แบบนั้น
• อุปมาที่เหมาะกว่าคือ agentic fleet — เพียงแต่ระดับของความเป็นระเบียบ ลำดับชั้น และความน่าเชื่อถือที่คำว่า “fleet” สื่อความหมายนั้น ยังเป็นสิ่งที่โลกความจริงไม่มีครบ
  • ในทางปฏิบัติ สิ่งที่ผู้ปฏิบัติการส่วนใหญ่ใช้งานอยู่คล้าย ฝูงผู้รับเหมาที่เปราะบาง มากกว่ากองทัพเรือที่ฝึกมาอย่างดี
  • agent มีความสามารถไม่สม่ำเสมอ พฤติกรรมเป็นเชิงความน่าจะเป็น บางครั้งก็ มั่นใจผิดอย่างเต็มเปี่ยม และมีต้นทุนสูงเมื่อใช้งานในวงกว้าง
  • orchestration layer พังได้, context window ระเบิดได้, และค่าใช้จ่ายด้าน reasoning ก็ไปโผล่บนใบเรียกเก็บเงินที่ไม่มีใครอยากเอาไปโชว์บอร์ดบริหาร
• ถึงอย่างนั้น แนวคิดเรื่อง fleet ก็ยังใช้ได้: การจัดองค์ประกอบ (ใช้ agent ต่างชนิดกับงานต่างกัน), การประสานงาน (handoff, dependency, escalation), โครงสร้างการบังคับบัญชา (ตัดสินภารกิจ กำหนดกติกาการทำงาน รีวิวผลลัพธ์), การเข้าเวรเป็นกะ (แม้ผู้บัญชาการจะนอนอยู่ งานก็ยังดำเนินต่อภายใต้ขอบเขตคำสั่ง และมารายงานตอนเช้า)
• นิยามของ fleet ที่ดีไม่ได้อยู่ที่ปริมาณการผลิต แต่อยู่ที่ ความสม่ำเสมอของสิ่งที่ผลิตออกมา
• รูปแบบงานแบบใหม่:
  • ตอนเช้าคัดแยกและ merge
  • ระหว่างวันทำ งานมนุษย์ที่มี leverage สูง — คุยกับลูกค้า วางกลยุทธ์ ตัดสินใจด้านผลิตภัณฑ์ เขียนสเปกที่จะขับเคลื่อนการทำงานกลางคืน
  • ตอนบ่ายเมื่อ agent ชุดแรกกลับมา ก็รีวิวและปรับทิศทาง
  • ปลายวันทำสิ่งที่คนรุ่นก่อนแทบไม่เคยทำ — handoff — ใส่งานเข้าคิวแล้วส่งต่อสเปกให้ fleet ของ agent ลองทำต่อในตอนกลางคืน บางอย่างจะผิด บางอย่างจะยอดเยี่ยม และการตัดสินความต่างระหว่างสองอย่างนั้นก็ยังเป็นงานที่มีแต่มนุษย์เท่านั้นที่ทำได้

จงสร้างสำหรับโมเดลที่ยังไม่เปิดตัว

• จุดที่ถูกย้ำมาอย่างสม่ำเสมอตลอดหลายปีที่ผ่านมา: โมเดลที่คุณใช้ในวันนี้คือโมเดลที่โง่ที่สุดในบรรดาโมเดลที่คุณจะได้ใช้ต่อจากนี้
• แต่ก็ไม่ได้มีหลักประกันว่าการเติบโตของความสามารถจะราบรื่น — ต้นทุน, latency, reliability, และข้อจำกัดด้าน scaling อาจทำให้เส้นโค้งซับซ้อนขึ้น
• อย่างไรก็ดี การเดิมพันในทิศทางนี้ยังได้รับการสนับสนุนอย่างดีจากสิ่งที่สังเกตได้ในชั้นโครงสร้างพื้นฐาน: ความสามารถระดับ frontier ในอีก 6~12 เดือนข้างหน้ามีแนวโน้มจะเหนือกว่าวันนี้อย่างมีนัยสำคัญ และช่องว่างระหว่างโมเดลที่ดีที่สุดในตอนนี้กับอีก 1 ปีข้างหน้าอาจ กว้างกว่าช่องว่างระหว่างปีที่แล้วกับปีนี้
• นัยเชิงกลยุทธ์คือ องค์กรต้องสร้างขีดความสามารถเพื่อใช้ประโยชน์จาก โมเดลที่ยังไม่มีอยู่ในมือ ไม่ใช่โมเดลปัจจุบัน
  • วิธีเขียนสเปก, วัฒนธรรมการรีวิว, การวาง observability, การปฏิบัติการ fleet ของ agent, และพิธีกรรมการฝึกฝนเพื่อรักษาทักษะของจูเนียร์ — ทั้งหมดนี้ไม่ใช่โครงสำหรับรองรับศักยภาพปี 2026 แต่เป็น นั่งร้านสำหรับปี 2027~2028
• บริษัทที่สร้างนั่งร้านนี้ตั้งแต่ตอนนี้ จะสามารถดูดซับการกระโดดของศักยภาพครั้งถัดไปให้กลายเป็น leverage ได้ ส่วนบริษัทที่รอจนกว่าเครื่องมือจะสุกงอม จะต้องใช้ ปีแรกไปกับการเรียนรู้ สิ่งที่ผู้เล่นยุคแรกเรียนรู้ไปแล้ว
• ต้องยอม ลงทุนเกินจำเป็น ในเรื่องสเปก การรีวิว และวินัยเชิงปฏิบัติการ มากกว่าที่โมเดลปัจจุบันเรียกร้อง
• ความไม่เกี่ยวข้องในยุคนี้ไม่ได้ประกาศตัวเองล่วงหน้า — แต่มาในรูปของ ความไร้ความสามารถที่ค่อย ๆ เพิ่มขึ้น จนไล่ทีมที่เมื่อปีที่แล้วยังไม่ได้ดูดีกว่าอย่างชัดเจนไม่ทัน

กล้ามเนื้อที่กำลังจะหายไป

• ไม่ว่าเราจะตั้งต้นจากสมมติฐานว่า AI จะจัดลำดับชนชั้นในสังคมอย่างเด็ดขาดหรือจะทำให้ทุกอย่างเป็นประชาธิปไตยมากขึ้น มนุษย์ก็ยัง เก่งมากในการเพิ่มประสิทธิภาพตามเส้นทางที่ต้านทานน้อยที่สุด
• ข้อเสนอหลักคือ: ถ้าคุณไม่ได้สร้างมันด้วยตัวเอง คุณก็จะสูญเสียความสามารถในการประเมินสิ่งที่ถูกสร้างขึ้นด้วย
• สิ่งที่เกิดขึ้นจริงแล้วคือ วิศวกรจูเนียร์ที่พึ่ง AI ตั้งแต่สัปดาห์แรกสามารถปล่อยงานเร็วและสร้างโค้ดที่ดูขัดเกลาได้ แต่เมื่อโมเดลล้มเหลวในแบบที่มันคาดไม่ถึง พวกเขากลับ หาบั๊กไม่เจอ — เพราะไม่ได้พัฒนา mental model ภายในระบบแบบที่ได้มาจากการนั่งปล้ำกับ stack trace ตอนตีสองเป็นครั้งที่ร้อย
• Taste ไม่ได้เรียนรู้จากการกดอนุมัติร่างที่ดูขัดเกลา, judgment ไม่ได้พัฒนาจากการรับคำตอบที่ดูน่าเชื่อของเครื่องใน 5 วินาทีแทนที่จะใช้ทั้งบ่ายกับปัญหายาก, และ craft ก็ไม่ได้ได้มาจากการรีวิวงานของ agent ตัวอื่น
• นี่คือ วิกฤตการฝึกฝน ที่องค์กรส่วนใหญ่ยังไม่ทันตระหนัก
  • โมเดลฝึกงานแบบช่างฝีมือของ software engineering (จูเนียร์ปล่อยของชิ้นเล็ก → ซีเนียร์รีวิว → จูเนียร์ซึมซับ taste ผ่านหมึกแดง) กำลังพังทลาย — จูเนียร์ปล่อยงานผ่าน agent ขณะที่ซีเนียร์รีวิว ผลลัพธ์จาก agent แทนผลลัพธ์จากมนุษย์
  • แล้วความเป็นช่างฝีมือของคนรุ่นต่อไปจะมาจากไหน? เราจะฝึก taste โดยไม่มีการทำซ้ำได้อย่างไร? และการ mentoring จะถูกแทนที่อย่างไร หากสิ่งที่เมนตีไม่ได้เป็นคนเขียนตั้งแต่แรก?
• ในองค์กรแบบดั้งเดิมส่วนใหญ่ วิศวกรอาวุโสรุ่นปัจจุบันคือ cohort สุดท้ายที่ถูกฝึกมาอย่างเต็มรูปแบบด้วยวิธีการแบบเก่า
• วิธีตอบสนองที่สมดุลคือ ทำอย่างตั้งใจและสม่ำเสมอ กับบางสิ่งที่สำคัญ ด้วยการ ลงมือทำเองแบบยาก ๆ โดยไม่มี fleet — เพราะเพื่อนร่วมงานส่วนใหญ่จะไม่รักษากล้ามเนื้อส่วนนั้นไว้ และอีก 10 ปีข้างหน้า นั่นอาจเป็นสิ่งที่สร้างความแตกต่าง

ส่วนที่ชวนกังวล

• บทความนี้ไม่ได้ตั้งใจจะจบด้วยความมองโลกในแง่ดี — การแสร้งทำว่าไม่มีการเปลี่ยนแปลง ไม่ได้หยุดยั้งการมาถึงของมัน
• งานได้เปลี่ยนไปอย่างถาวรแล้ว และจะเปลี่ยนแบบ ค่อยเป็นค่อยไปและเชิงวิวัฒนาการ ตามจังหวะของ AI
• มนุษย์จะได้ช่วงกลางวันกลับคืนมาเพื่อทำงานที่จำเป็นต้องใช้มนุษย์จริง ๆ ส่วนเครื่องจะยึดคืนช่วงกลางคืนไปเพื่อทำงานที่แต่เดิมก็เป็นเพียงแรงงานแบบซ้ำ ๆ
• ฉากทัศน์ที่อาจเกิดขึ้นในอีกไม่กี่ปีข้างหน้า:
  • ชนชั้นแรงงานที่เหนื่อยล้าจากภาระรีวิว
  • ชนชั้นของบทบาทที่แตกย่อย ซึ่งระบบต้องการแต่ไม่ได้ให้รางวัล
  • คนรุ่นจูเนียร์ ที่ไม่อาจพัฒนาความเป็นช่างฝีมือซึ่งซีเนียร์ปัจจุบันใช้ในการตัดสินใจ
  • ทีมที่สับสนระหว่างปริมาณผลผลิตกับคุณภาพของงาน และไม่ตระหนักถึงช่องว่างจนกว่าจะเกิด incident
  • ช่องว่างที่กว้างขึ้นเรื่อย ๆ ระหว่างองค์กรที่สร้างกล้ามเนื้อเชิงปฏิบัติการสำหรับโมเดลถัดไปแล้ว กับองค์กรที่ยังไม่ได้สร้าง
• ข้อความสำคัญคือ จงสร้างองค์กรสำหรับโมเดลที่คุณยังไม่มีอยู่ในมือ บางครั้งก็จงทำของยากด้วยตัวเองเพื่อไม่ลืมวิธีทำ ส่ง fleet กลางคืนออกไปทำงาน แล้วนอนอย่างสบายโดยรู้ว่างานกำลังเดินหน้า — แต่ก็ต้องตื่นตัวไว้ด้วยว่า บางสิ่งที่กลับมาอาจ ผิดในแบบที่คุณไม่ได้ถูกฝึกให้มองเห็นอีกต่อไปแล้ว
• พนักงาน 24/7 ไม่ใช่คำสัญญา แต่เป็น การจัดวางใหม่และการเดิมพันกับอนาคตของวิศวกรรมเชิงความน่าจะเป็น — เป็นการเดิมพันว่ามนุษย์ในลูปจะยังเฉียบคม ซื่อสัตย์ และได้รับการฝึกฝนมาดีพอที่จะคู่ควรกับการอยู่ในลูป และองค์กรรอบตัวมนุษย์คนนั้นถูก สร้างขึ้นเพื่อโมเดลที่ยังไม่เปิดตัว ไม่ใช่เพื่อโมเดลของวันนี้