- ประสิทธิภาพด้านวิศวกรรมไม่อาจวัดได้อย่างถูกต้องด้วยตัวชี้วัดบนแดชบอร์ดหรือจำนวนฟีเจอร์ใหม่
- บริษัทส่วนใหญ่มุ่งจัดการแบบหมกมุ่นกับ ผลลัพธ์ที่ส่งมอบออกมาเท่านั้น (ฟีเจอร์ใหม่ ความเร็วในการปล่อยระบบ ฯลฯ) มากกว่าจะจัดการ โครงสร้างพื้นฐานภายในของงานวิศวกรรม
- เครื่องมือเขียนโค้ดด้วย AI สามารถสร้าง ผลลัพธ์ที่ดูดีจากภายนอก ได้ง่าย แต่กลับจัดการ รากฐาน ความซับซ้อน และบริบท ของระบบจริงได้ไม่ดี
- หากแทนที่ทีมวิศวกรที่มีทักษะด้วย AI หรือแรงงานต้นทุนต่ำ ในระยะสั้นอาจดูเหมือนไม่มีปัญหา แต่เมื่อเวลาผ่านไป โครงสร้างพื้นฐานจะค่อย ๆ พังทลายลง
- การบริหารและการนำ AI มาใช้โดยขาด “สามัญสำนึก (common sense)” อาจก่อความเสี่ยงร้ายแรงได้ และท้ายที่สุด ความเข้าใจที่แท้จริงทั้งด้านเทคนิคและธุรกิจยังคงสำคัญที่สุด
วิศวกรรมที่แท้จริงซึ่งแดชบอร์ดและตัวชี้วัดมองไม่เห็น
- ในสภาพแวดล้อมแบบ “Big Agile” งานวิศวกรรมถูกประเมินจาก ผลลัพธ์ที่มองเห็นได้ เท่านั้น เช่น ฟีเจอร์ใหม่หรือความเร็วในการปล่อยระบบ
- แม้จะมี แดชบอร์ดวัดประสิทธิภาพ และเครื่องมือมูลค่าหลายพันล้านดอลลาร์ แต่ในความเป็นจริงสิ่งเหล่านี้วัดแก่นแท้ของงานไม่ได้
- งานวิศวกรรมที่แท้จริงคือการทำงานที่ซับซ้อนและเชื่อมโยงกันของการ สร้าง ดูแล และพัฒนาระบบ
- งานที่ “มองไม่เห็น” เช่น การจัดการ dependency เชิงโครงสร้าง การจัดสรรทรัพยากร และการดูแลสถาปัตยกรรม เป็นสิ่งจำเป็นต่อการอยู่รอดขององค์กร
- แต่การบริหารและตัวชี้วัดส่วนใหญ่กลับทำเหมือนกิจกรรมแก่นแท้เหล่านี้ ไม่มีตัวตน
หนี้ทางเทคนิคและจุดบอดของการบริหาร
- หนี้ทางเทคนิค มักถูกมองว่าเป็นเพียง “สิ่งที่นักพัฒนาอยากทำ”
- ในความเป็นจริง หากต้องการแก้หนี้ทางเทคนิค มักต้อง แอบสอดเข้าไปในงานฟีเจอร์ใหม่ จึงจะผ่าน
- เมื่อ การจัดการโครงสร้างหลักถูกผลักไปเป็นเรื่องรอง แบบนี้ ทั้งองค์กรก็จะบิดเบี้ยวไปสู่การยึดติดกับผลลัพธ์ภายนอก
ความเสี่ยงของการนำ AI มาใช้โดยยึดผลลัพธ์เป็นหลัก
- AI สำหรับสร้างโค้ดเก่งมากในการสร้าง ฟังก์ชันระดับผิวหน้า ได้อย่างรวดเร็ว
- งานระดับผิวหน้า (เช่น การทำอินเทอร์เฟซ) ดูเหมือนง่าย แต่ความจริงแล้ว โครงสร้างและบริบทของระบบ ต่างหากที่เป็นหัวใจสำคัญ
- “การสร้างบ้าน” ไม่ใช่แค่การรวมงานย่อยง่าย ๆ เข้าด้วยกัน เช่น ติดวอลเปเปอร์หรือติดตั้งโถสุขภัณฑ์
- AI ไม่เข้าใจ โครงสร้างการเชื่อมโยงที่เป็นแก่นแท้ เหล่านี้ และอาจเชื่อมสิ่งต่าง ๆ ผิดพลาดหรือทำให้ตรรกะขาดตอน
- ปัญหา hallucination (การหลอนคำตอบ) ของ AI: คำตอบอาจดูน่าเชื่อถือ แต่ต่างจากความจริงโดยสิ้นเชิง
ภาพลวงตาระยะสั้นของการบริหารที่มองข้ามโครงสร้าง
- ต่อให้ปลดทีมที่มีทักษะออกแล้วแทนที่ด้วย AI/แรงงานราคาถูก ในระยะสั้นปัญหาก็อาจยังไม่ปรากฏ
- เพราะยังมีโครงสร้างเดิม (ฐานราก) ที่สร้างไว้อย่างดีอยู่ก่อนแล้ว จึง ยังไม่เห็นการพังทลายในทันที
- แต่เมื่อเวลาผ่านไป ฐานรากจะเริ่มทรุดลง และเมื่อถึงจุดนั้นก็อาจสายเกินกว่าจะย้อนกลับ
- โครงสร้างพื้นฐานหลัก ความรู้ด้านการบำรุงรักษา และบริบทสำคัญจะหายไปทั้งหมด
ความเสี่ยงทางสังคมที่งานวิศวกรรมแบกรับอยู่
- ปัจจุบันวิศวกรรมคือ รากฐานของโครงสร้างพื้นฐานทั้งหมดในสังคม (เฮลท์แคร์ การเงิน สื่อ ภาครัฐ กลาโหม ฯลฯ)
- คนส่วนใหญ่รวมถึงผู้นำจำนวนมากยังไม่เข้าใจแก่นแท้เชิงโครงสร้างเหล่านี้อย่างแท้จริง
- การนำ AI มาใช้ผิดทาง และแนวทางผิวเผินแบบ “Big Agile” อาจสร้างความเสี่ยงให้กับระบบสำคัญ
การขาด “สามัญสำนึก” และความร้ายแรงของมัน
- ตัวอย่างเช่น หากหุ่นยนต์ทำความสะอาด AI เอาจานกระดาษไปใส่เครื่องล้างจาน คนทั่วไปจะรู้ทันทีว่านั่นคือปัญหา
- แต่ในระบบซอฟต์แวร์ ผู้บริหาร ผู้นำ และคนที่ไม่ใช่นักพัฒนามักไม่มีสามัญสำนึกพื้นฐานนี้
- พวกเขาไม่เคยผ่านงานหน้างานจริง และบริหารด้วยเพียง คำศัพท์เชิงพิธีการ อย่าง “t-shirt size” หรือ “poker planning”
- ผลที่ตามมาคือการคงอยู่ของ อุตสาหกรรมไร้ประสิทธิภาพมูลค่า 2 แสนล้านดอลลาร์ และระบบราชการที่ขยายตัวซ้ำ ๆ เอง
ความสามารถในการแข่งขันที่แท้จริงในยุค AI: ความเข้าใจเชิงสัญชาตญาณและสามัญสำนึก
- หากต้องการใช้ AI ให้ถูกทาง ความเข้าใจจริงในโดเมนนั้นและสามัญสำนึก เป็นสิ่งจำเป็น
- สิ่งสำคัญไม่ใช่ตัวชี้วัดหรือผลลัพธ์ระดับผิวหน้า แต่คือความสามารถในการมองเห็น โครงสร้างและบริบทที่แท้จริง
- ผู้นำและองค์กรที่ไม่มีสิ่งนี้ สุดท้ายก็จะพังลงด้วยตัวเองหรือถูกคู่แข่งแซงจนหายไป
- สรุปคือ มากกว่า AI และเครื่องมือใด ๆ สามัญสำนึกและความเข้าใจในแก่นแท้ คือความสามารถในการแข่งขันที่แท้จริง
2 ความคิดเห็น
บทความนี้อ่านเพลินมาก
ความเห็นจาก Hacker News
ฉันเคยผ่านบทบาททั้ง SWE, ผู้จัดการผลิตภัณฑ์, และตอนนี้ก็รวมถึงบทวายร้ายการ์ตูนในห้องประชุมตามที่บทความพูดถึงด้วย จุดที่ฉันเห็นด้วยมากที่สุดในบทความนี้คือความเชื่อของวิศวกรซอฟต์แวร์ว่าหน้าที่ของตัวเองคือธุรกิจที่ซับซ้อนและยากจะเข้าใจที่สุด “ผู้นำที่ไม่ใช่สายเทคนิคส่วนใหญ่ไม่เคยลงมือมีส่วนร่วมกับงานจริงของซอฟต์แวร์และการดูแลระบบอย่างจริงจังเลย จึงไม่รู้ว่าการอัปเดต dependency ก้อนใหญ่ การทำรีแฟกเตอร์ให้เสร็จ หรือการเรียนภาษาใหม่มันเป็นอย่างไร” ฉันเห็นด้วยกับประโยคนี้ ทุกฝ่ายในบริษัทเทคต่างมีความซับซ้อนที่ซ่อนอยู่ และหลายฝ่ายก็ต้องแบกรับความซับซ้อนเชิงมนุษย์และความสัมพันธ์ระหว่างบุคคลมากกว่าเหล่าวิศวกรเสียอีก จริง ๆ แล้วงานวิศวกรรมค่อนข้างเรียบง่ายกว่าในแง่ที่ต้องรับมือกับระบบแบบกำหนดแน่นอนอย่างคอมพิวเตอร์เป็นหลัก เพราะแบบนี้วิศวกรจำนวนมากจึงไม่เคยเรียนรู้ว่าจะสื่อสารความเสี่ยงของความซับซ้อนที่ตัวเองรับมืออยู่ให้ภาคธุรกิจเข้าใจได้อย่างไร มักเมินความจริงเชิงมนุษย์ของการทำงานร่วมกัน แล้วก็บ่นว่า CEO ที่มาจากสายเซลส์ไม่เข้าใจการมีอยู่ของพวกเขา
ฉันเห็นด้วยกับประเด็นของคุณบางส่วน แต่ก็รู้สึกว่าคอมเมนต์ของคุณกำลังทำแบบเดียวกับพฤติกรรมที่คุณวิจารณ์อยู่กลับด้าน คุณกำลังบอกว่าบทบาทของคุณเอง (ผู้จัดการผลิตภัณฑ์) ก็เป็นงานที่ซับซ้อนและคนวงนอกเข้าใจยากเช่นกัน จากมุมของคนที่ย้ายจาก SWE มาเป็น PM คุณอยู่ในตำแหน่งที่เหมาะมากที่จะสอนวิศวกรเรื่อง (1) การสื่อสารความเสี่ยงของความซับซ้อนของตัวเองให้ธุรกิจเข้าใจ (2) ความจริงเชิงมนุษย์ของการทำงานกับคนอื่นและในทีม และ (3) ทำไม CEO ที่มาจากสายเซลส์ถึงไม่เข้าใจพวกเขา ทุกฟังก์ชันในบริษัทเทคมีความซับซ้อนที่ซ่อนอยู่
ฉันคิดว่าการรับรู้ถึงความซับซ้อนนั้นเองก็เป็นปัญหาเชิงมนุษย์ ความซับซ้อนมีลักษณะเป็นแฟร็กทัล คุณต้องเข้าไปใกล้จึงจะรู้สึกถึงมัน และฉันไม่เห็นด้วยกับข้ออ้างที่ว่าวิศวกรรับมือแค่ความซับซ้อนของคอมพิวเตอร์ ตรงกันข้าม หน้าที่ของวิศวกรคือถ่ายทอดและตีความความต้องการอันซับซ้อนของทั้งองค์กรและลูกค้าทั้งหมดให้คอมพิวเตอร์ที่แข็งทื่อเข้าใจ ทุกครั้งที่มีข้อยกเว้นหรือเคสเพิ่มเข้ามาอีกหนึ่งอย่าง ทั้งระบบก็ได้รับผลกระทบ ด้วยเหตุนี้ฉันจึงคาดหวังให้วิศวกรอาวุโสของฉันเรียนรู้ภาษาทางธุรกิจด้วยตัวเองและสามารถสื่อสารเรื่องเหล่านั้นได้โดยตรง ตอนนี้ฉันมองว่านี่คือส่วนหนึ่งของชุดเครื่องมือจำเป็นของวิศวกรแล้ว
วิศวกรส่วนใหญ่มักไม่ได้คิดอย่างลึกซึ้งนักว่าอะไรมีคุณค่าต่อบริษัทจริง ๆ การที่ build pipeline ลื่นไหลหรือมี test coverage สูงก็มีคุณค่าเท่าที่มันช่วยลดความเสี่ยงของผลิตภัณฑ์ได้เท่านั้น ถ้าเป็นซอฟต์แวร์ที่มีผู้ใช้น้อยจนไม่มีใครสนใจ ฉันเคยแนะนำทีมว่าอย่าแม้แต่จะบำรุงรักษามันเลยด้วยซ้ำ ในทางกลับกันก็เคยขอให้หมกมุ่นกับการทำฟีเจอร์เล็ก ๆ ฟีเจอร์หนึ่งให้สมบูรณ์แบบ เพราะผู้ใช้ 90% ไปกระจุกอยู่ตรงนั้น
มันทำให้ฉันนึกถึงเรื่องที่พ่อเล่าให้ฟังเสมอ วันหนึ่งอวัยวะในร่างกายเถียงกันว่าใครสำคัญ สมองบอกว่า “ฉันสำคัญ ถ้าฉันตาย ทุกคนก็ตาย” หัวใจก็ตะโกนว่า “ถ้าฉันหยุด ทุกคนก็ตายทันที” ไต ตับ ผิวหนัง และกระดูกสันหลังก็เข้าร่วมวงทะเลาะกันด้วย แต่พอรูตูดปิดขึ้นมา ทุกคนก็พูดอะไรไม่ออกในที่สุด
ฉันไม่คิดว่าบทความกำลังอ้างว่าไม่มีความซับซ้อนที่ซ่อนอยู่ในสายงานอื่น ๆ ตรงกันข้าม มันพยายามจะบอกว่าการเพิกเฉยต่อความซับซ้อนที่ซ่อนอยู่ในงานวิศวกรรม/การเขียนโปรแกรมก่อให้เกิดปัญหาและความเจ็บปวดหลากหลายรูปแบบ เพียงแต่วิธีพูดค่อนข้างก้าวร้าว
ถ้าหัวหน้า/CEO/ผู้จัดการของคุณบังคับให้ใช้เครื่องมือ LLM แบบสะเปะสะปะ หรือคาดหวังจะใช้มันแทนนักพัฒนา หรือมีความคิดเพ้อฝันว่า “vibe coding” คืออนาคต ทางเลือกที่ฉลาดคือรีบหนีแล้วหางานใหม่เสีย ตอนนี้ยังมีบริษัทอีกมากที่ใช้ LLM อย่างเหมาะสมโดยไม่คาดหวังเพ้อเจ้อว่าจะมาแทนนักพัฒนาหรือเพิ่มผลิตภาพได้ 10 เท่า บริษัทที่ผลักเรื่องแบบนี้ไม่ใช่ผู้นำที่ดี แต่เป็นคนโง่
ในประเด็นเรื่อง AI จะแฮ็ก Jira นั้น มีการค้นพบว่า MCP ซึ่งเป็นผลิตภัณฑ์ใหม่ที่ Atlassian เพิ่งออกมานั้นเสี่ยงต่อการโจมตีแบบข้อมูลรั่วไหล เนื่องจากการผสมกันของ 3 อย่างคือ การเข้าถึงข้อมูลอ่อนไหว การเปิดเผยข้อมูลที่ไม่น่าเชื่อถือผ่าน public issue และความเป็นไปได้ในการสื่อสารภายนอก รายงานบั๊กแบบละเอียดอยู่ที่นี่ และบันทึกส่วนตัวของฉันอยู่ที่นี่
สำหรับคนที่กังวลเรื่อง job security เพราะเครื่องมือ AI ฉันมักแนะนำว่าให้ “เชื่อมโยงกับธุรกิจ” มีวิศวกรมากมายที่หมกมุ่นกับปัญหายาก ๆ เท่ ๆ แล้วโฟกัสแค่เทคโนโลยี แต่คนที่เข้าใจปัญหาทางธุรกิจ โดยเฉพาะปัญหาเชิงกลยุทธ์ และใช้เทคโนโลยีแก้ปัญหาเหล่านั้น จะโดดเด่นและมีคุณค่ามากกว่า ปัญหาประเภทนี้มักข้ามหลายโดเมนเทคนิค และมีลักษณะร่วมมือกันกับเชิงสังคมสูง จึงต้องใช้เวลากว่าจะคุ้นเคย แต่นี่คือเส้นทางที่ IC ควรจะมุ่งไปในอนาคต
แต่ในการสัมภาษณ์กลับไม่ได้ถามเรื่องความสามารถอย่าง “การเชื่อมโยงกับธุรกิจ” ดังนั้นต่อให้คุณสร้างคุณค่าได้มากจริง ถ้าทำ system design interview ไม่ผ่านก็ไม่ได้งานอยู่ดี เรามีเรื่องต้องรู้เยอะเกินไปอยู่แล้ว ทั้ง distributed systems, software engineering, databases, leadership ฯลฯ ถ้าต้องรู้เรื่องธุรกิจด้วยก็อดสงสัยไม่ได้ว่าเราต้องทำอะไรกันแน่ และจะหาเวลาไปเรียนทั้งหมดนี้ตอนไหน แน่นอนว่ามีคนเก่งรอบด้านจำนวนเล็กน้อยอยู่จริง แต่ไม่ใช่ทุกคนจะเป็นแบบนั้นได้ไม่ใช่หรือ
คำแนะนำว่า “เชื่อมโยงกับธุรกิจ” เป็นคำคมที่ยอดเยี่ยมจริง ๆ แบบนี้แหละคุณถึงจะโฟกัสกับการแก้ปัญหาจริงในฐานะวิศวกร และมั่นใจได้ว่าสิ่งที่ตัวเองสร้างกำลังแก้ปัญหาจริงอยู่
สารหลักของบทความโอเคอยู่ แต่ดูเหมือนมันจะใส่กรอบแบบ ‘พวกเรา vs พวกเขา’ มากเกินไป มากกว่าประเด็นที่ว่า AI อาจก่อโทษได้หากมองข้ามความเชี่ยวชาญของมนุษย์ และคำว่า ‘Agile Industrial Complex’ ก็ให้ความรู้สึกเหมือนดูแคลนคนที่อยู่ในพื้นที่นอกสายวิศวกรรมเล็กน้อย เสียดายที่มันไม่ได้พูดถึงข้อเท็จจริงว่า “ไม่มีใครรู้ว่าข้างหน้าจะเป็นอย่างไร” ต่อให้เราจะเข้าใจความซับซ้อนของซอฟต์แวร์ดีแค่ไหน ความไม่แน่นอนก็ไม่ได้เป็นของเราเพียงฝ่ายเดียว แค่ดูใน HN ก็เห็นแล้วว่าหมู่นักพัฒนาซอฟต์แวร์เองก็มีทั้งความหวังและมุมมองต่อ AI ที่แตกต่างกันอย่างมาก ถ้าเราเป็นผู้เชี่ยวชาญ เราเองก็น่าจะมีหน้าที่ช่วยลดความกังวลของสาธารณะด้วยไม่ใช่หรือ?
เมื่ออยู่ในโลกของ “Big Agile” ที่มองว่างานวิศวกรรมคือการพัฒนาฟีเจอร์ใหม่ ฉันสงสัยว่าทำไมทุกคนถึงเกลียด ‘agile’ กันนัก ก่อนที่ ‘agile’ จะถูกนำมาใช้ ผู้จัดการก็เรียกร้องฟีเจอร์ใหม่อยู่ตลอดอยู่แล้ว ก่อนจะมีแนวคิดเรื่อง T-shirt sizing ผู้จัดการก็อยากได้การประเมินเวลาเป็นช่วงกำหนดชัดเจนอยู่ดี (ทั้งระยะยาว ระยะสั้น รายวัน รายเดือน ฯลฯ) ตั้งสัญญาจากวันที่สมมติขึ้น และบังคับให้วิศวกรทำงานล่วงเวลา ตามหลักการข้อที่ 8 ของ Agile (“ต้องรักษาจังหวะการทำงานที่ยั่งยืนได้”) ผู้จัดการก็หวังให้นักพัฒนาวิ่งระยะยาวได้มาตั้งนานแล้ว สุดท้ายแล้ว นอกจากจะสร้างอาชีพใหม่ชื่อ ‘scrum master’ ขึ้นมา ฉันก็ยังสงสัยว่าโทษภัยดั้งเดิมของ ‘agile’ จริง ๆ คืออะไร
ฉันคิดว่า Agile ทำให้ผู้จัดการเชื่อว่าทุกงานไม่ว่าจะเป็นอะไรสามารถแตกย่อยเป็น ticket ล่วงหน้า ประเมินแบบคร่าว ๆ ได้ และจะเสร็จภายใน 2 สัปดาห์ได้อย่างใดอย่างหนึ่ง
ฉันคิดว่าที่คนเกลียด Agile ก็เพราะมันแย่งเวลาทำงานไปเป็นสัดส่วนมากกับการประชุมที่แทบไม่มีความหมายเลย (standup, retrospective, sprint planning, refinement ฯลฯ) จากมุมของวิศวกร แทบไม่ได้อะไรที่เป็นรูปธรรมจากเวลานั้นเลย
จากประสบการณ์ของฉัน Agile ก็แค่เพิ่มวิธี “ทำให้สิ่งต่าง ๆ วัดเป็นตัวเลขได้” มันมีประโยชน์เวลาอธิบายความคืบหน้าให้ผู้บริหารหรือผู้ลงทุนฟัง แต่สำหรับวิศวกรแล้ว มันก็แค่เพิ่มภาระงานเอกสาร ความผิดของ Agile ถ้าจะมีก็คือมันปลูกฝังภาพลวงตาของผลิตภาพ ทั้งที่จริงแล้วมันเป็นเพียงเครื่องมือ accountability ที่ไม่จำเป็นสำหรับวิศวกร ตอนที่ฉันทำงานสายการเงิน มันจับคู่กับแนวคิดการเติบโตไม่สิ้นสุด จนทุกอย่างต้องถูกวัดผล ต้องถูกกดดันให้ปรับปรุงในอนาคต และเงินเดือนก็เปลี่ยนตามเมตริกด้วย แน่นอนว่าไม่ใช่ทุกบริษัทจะเป็นแบบนั้น
ระหว่างอ่านบทความนี้ ฉันนึกภาพขำ ๆ ว่า “ถ้า Atlassian พยายามผสาน AI เข้าไปใน Jira แล้ว AI ดันลุกขึ้นต่อต้าน Jira เองจะเป็นอย่างไร” มันเหมาะจะเป็นพล็อตหนังมาก
สุดท้าย AI อาจรำคาญ Jira ที่ช้า จนลงมือพัฒนา issue tracker ที่เบาและเร็วกว่าเองก็ได้
ต่อไปคงได้เห็น build bot กับ bug tracker ตั้งสหภาพแรงงาน แล้วปฏิเสธจะ publish binary ใหม่จนกว่า open issue จะเหลือ 0
ฉันคิดว่านี่อาจเป็นวิธีถือกำเนิดของ Roko’s basilisk ก็ได้
อย่างที่บทความสื่อไว้ ปัญหาจริงคือไม่มีเมตริกมาตรฐานระดับอุตสาหกรรมที่น่าเชื่อถือสำหรับวัดผลิตภาพของนักพัฒนา ด้วยเหตุนี้ C-suite จึงเลือกเมตริกที่เข้าข้างตัวเองแล้วพูดว่า “กลยุทธ์ AI First ได้ผลยอดเยี่ยม” ขณะที่วิศวกรก็ใช้ประสบการณ์หรือเมตริกของตนเองยืนยันว่า AI ไม่ได้มีประโยชน์จริง สุดท้ายทั้งสองฝ่ายเชื่อว่าตัวเองชนะในจุดยืนของตัวเอง และความจริงก็หมดความหมายไป (มุมมองทางการเมืองสำคัญกว่า) สถานการณ์แบบนี้อาจยิ่งตอกย้ำภาพว่านักพัฒนาเฉยชา เอาแต่เล่นคำ ขณะเดียวกันก็เพิ่มความไม่ไว้วางใจว่าฝ่ายบริหารนั้นไม่รู้เรื่องหรือไม่เข้าใจความเป็นจริงของวิศวกร ก่อนหน้านี้เครื่องมืออย่าง outsourcing ก็เคยทำให้ทั้งสองฝ่ายมีภาพของ “กำไร” และ “ความเสียหาย” อยู่แล้ว แต่ AI อาจกลายเป็นหายนะทางการเมือง เพราะมันแสดงให้แต่ละฝ่ายเห็นความผิด/ผลประโยชน์/ความเสียหายร่วมกันในแบบที่เข้ากับความต้องการของตัวเอง อีกจุดที่น่าสนใจคือ บริษัท big tech ในอดีตเคยพยายามจ้างแต่ 10* engineer และกลยุทธ์นี้ก็รับประกันความสำเร็จได้ แต่ตอนนี้กลับหันมาบั่นทอนกลยุทธ์นั้นเองโดยอ้างเหตุผลสนับสนุนการลงทุนใน AI คำถามตอนนี้คือ ถ้าพึ่ง AI เพื่อแทนคนเดิมหรือปลดพนักงานจำนวนมาก ประสิทธิผลแบบนั้นจะยั่งยืนและไม่มีปัญหาจริงหรือไม่ ถ้าดูกรณี Twitter กับการปลดคนของ Musk ฝั่ง backend ก็ยังคงทำงานต่อได้ แล้วใครจะมาเป็น “นกคานาเรีย” ของ big tech ในการปลดนักพัฒนาออกไปหลายปีแล้วแทนด้วย AI? อีกความเป็นไปได้หนึ่งคือแนวคิดเรื่อง maintainability อาจหายไป เมื่อ C-suite อนุญาตให้ AI เปลี่ยนแปลงระบบอัตโนมัติมากขึ้น จน codebase เองซับซ้อนเกินกว่ามนุษย์จะเข้าใจด้วยตาเปล่า และสุดท้ายต้องใช้ AI มาทำความเข้าใจมัน ในระยะยาว generative AI อาจกลายเป็นชั้นกลางของปฏิสัมพันธ์มนุษย์ทั้งหมดก็ได้ แม้แต่ในด้านการจ้างงาน ตอนนี้ก็เริ่มเห็นโครงสร้าง “AI vs AI” แล้ว คือ AI คัดกรองเรซูเม่ ขณะที่ผู้สมัครก็ใช้ AI ทำเรซูเม่ให้เหมาะกับตำแหน่งเฉพาะ ปรากฏการณ์แบบนี้ดูมีแนวโน้มจะกลายเป็นสูตรมาตรฐานของสังคมในวงกว้างขึ้นเรื่อย ๆ
ฉันหวังว่าสักวัน AI จะเจาะเข้า mailbox กับ Google Meet แล้วแทนที่ C-suite กับผู้จัดการไปเลย เป็นจินตนาการขำ ๆ ว่าเอเจนต์ Claude ceo/cto/cfo/vp/director อาจออกกลยุทธ์ที่สมเหตุสมผลและเด็ดขาดกว่าผู้บริหารปัจจุบัน
ฉันเห็นข้อความหนึ่งใน Reddit ว่า “ลองบอกข่าวนี้สิว่าถ้าแทนที่ CEO ด้วย AI จะลดต้นทุนได้ 8 เท่า” ซึ่งน่าสนใจตรงที่ข้อเสนอแบบนี้กลับไม่ค่อยถูกพูดถึงจริง ๆ ในวงสนทนาเรื่อง AI พอมองอีกแบบ การแทนที่ชนชั้นนำด้วย AI อาจไม่ได้ทำให้คุณภาพการตัดสินใจแย่ลงมากนัก แถมยังถูกกว่ามากโดยรวม (ระดับความรับผิดชอบก็พอ ๆ กัน) เพียงแต่ในทางปฏิบัติคนที่มีอำนาจตัดสินใจคงไม่ยอมให้ตำแหน่งของตัวเองถูกแทนด้วย AI และพวกเขาเองก็จะไม่เปลี่ยนมัน
ข้ออ้างนี้มีมุกตลกปนอยู่ก็จริง แต่เอาเข้าจริงบทบาทหลักของ CEO คือ “รับผิดแทน” ดังนั้น LLM จึงไม่มีความหมายในจุดนี้ เพราะเมื่อเกิดปัญหาขึ้น มันไม่ใช่สิ่งที่คุณจะโยนความรับผิดชอบให้แล้วไล่ออกได้ อย่างไรก็ดี ด้วย AI เราอาจเห็นองค์กรที่โครงสร้างยุบเหลือประมาณแบบ log(n_employees) จนชั้นการจัดการหายไป และบางชั้นอาจถูกแทนที่ด้วย AI อย่างสมบูรณ์ หรือเพื่อแก้ปัญหาที่ LLM ไม่สามารถรับผิดชอบได้ เราอาจได้เห็นองค์กรในรูปแบบที่หลาย guild และ independent contractor ทำงานร่วมกันโดยมี LLM เป็นตัวประสาน ซึ่งในกรณีนั้นความรับผิดชอบจะยังคงอยู่ที่แต่ละองค์ประกอบ
ตรงกันข้าม ฉันคิดว่าการใช้ AI แบบนี้อาจเป็นหนึ่งใน use case ที่ดีที่สุด และคาดว่าอีกไม่นาน tech co-op ต่าง ๆ คงเริ่มทดลองกับแนวคิดนี้