ประโยคที่ว่า Citizens build, Agents execute, Experts govern หลุดออกมากลางวงสนทนาเรื่อง AI เมื่อไม่กี่เดือนก่อน คนที่พูดคือ Rachel Laycock ผู้บริหารของ Thoughtworks บริษัทที่ปรึกษาด้านซอฟต์แวร์ ซึ่งภายหลังนำมาขยายความต่อเป็นบทความบน martinfowler.com ใจความคือคนทั่วไปกลายมาเป็นคนสร้างซอฟต์แวร์ ส่วนงานลงมือทำตกไปอยู่กับ agent หรือโปรแกรม AI ที่รับโจทย์แล้วทำงานเป็นขั้นตอนเองได้ และเหลืองานสุดท้ายไว้ให้ผู้เชี่ยวชาญ คือตัดสินว่าของที่ได้ไว้ใจได้แค่ไหน

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

แอปที่สร้างในวันหยุดก็เป็นซอฟต์แวร์จริง แต่ production เป็นอีกเรื่อง

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

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

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

หกคำถามที่ไม่โผล่มาตอน demo

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

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

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

คืนที่ agent ทำงาน กับวันที่คนตัดสินใจ

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

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

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

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

ค่าของงานไม่ได้หายไป แค่ย้ายที่

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

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

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

องค์กรไม่ได้ขับเคลื่อนด้วยโค้ด แต่ขับเคลื่อนด้วยความเชื่อใจ

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

วลีนี้ไม่ได้แปลว่าวิศวกรกำลังจะหายไป

ข้อสังเกตชุดนี้ไม่ได้แปลว่าทุกคนกำลังจะกลายเป็นวิศวกรซอฟต์แวร์ และไม่ได้แปลว่าองค์กรจะเลิกต้องการวิศวกรซอฟต์แวร์

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

จากคนสร้างฟีเจอร์ สู่คนวางระบบให้คนอื่นสร้างได้

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

สภาพแวดล้อมที่ว่านี้ประกอบด้วยหัวใจสำคัญไม่กี่อย่าง ได้แก่ ระบบกันพลาดอย่าง guardrail ที่วางกติกาไว้ล่วงหน้า, แพลตฟอร์มกลางที่ทีมอื่นหยิบไปใช้ต่อได้, แนวปฏิบัติทางวิศวกรรมที่ตกลงกันไว้ทั้งองค์กร และวงจรสะท้อนผลอย่าง feedback loop ที่ทำให้รู้ตัวเร็วเมื่อมีอะไรเริ่มผิดปกติ

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

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

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

---

ที่มา: บทความ Citizens Build, Agents Execute, Experts Govern จาก martinfowler.com