เมื่อทุกคนมี AI แต่บริษัทยังไม่สามารถเรียนรู้อะไรได้เลย
(robert-glaser.de)- การเพิ่มผลิตภาพของพนักงานด้วย AI ในระดับบุคคลไม่ได้แปลว่าจะนำไปสู่ การเรียนรู้ในระดับองค์กร โดยอัตโนมัติ และโจทย์สำคัญคือเส้นทางที่ทำให้สิ่งค้นพบจริงย้ายจากบุคคลไปเป็นความสามารถของทีมและองค์กร
- ใน ช่วงกลางที่ซับซ้อน ของการนำ AI มาใช้ เครื่องมืออย่าง Copilot, ChatGPT Enterprise, Claude, Gemini, Cursor ถูกใช้อย่างแพร่หลายแล้ว แต่ความลึกในการใช้งานต่างกันไปในแต่ละทีม และการเรียนรู้บางส่วนก็ซ่อนอยู่ ทำให้เปรียบเทียบและขยายผลได้ยาก
- วิธีบริหารการเปลี่ยนแปลงแบบเดิม เช่น คอมมูนิตี้ เครือข่ายแชมเปียน เดโม แบบสำรวจ และแดชบอร์ด ยากจะสะท้อนบริบท ความล้มเหลว การตรวจสอบ และการแทรกแซงของมนุษย์ที่เกิดขึ้นระหว่างการใช้ AI ในงานจริงได้อย่างเพียงพอ
- วิศวกรรมแบบเอเจนต์ช่วยลดต้นทุนของการทำซ้ำ ทำให้ขยับจากความตั้งใจไปสู่ต้นแบบและการประเมินผลได้อย่างรวดเร็ว แต่กระบวนการ Scrum, สปรินต์ และการส่งต่องานขององค์กรยังอาจตั้งอยู่บนสมมติฐานเดิมว่าการทำซ้ำยังเป็นสิ่งที่หาได้ยาก
- องค์กรต้องมีทั้ง Agent Operations, Loop Intelligence และ Agent Capabilities ร่วมกัน โดยสิ่งสำคัญคือฟีดแบ็กฮาร์เนสที่ช่วยเข้าใจลูปการทำงานจริง ไม่ใช่การเฝ้าดูพนักงาน และเปลี่ยนสิ่งนั้นกลับไปเป็นความสามารถที่นำกลับมาใช้ซ้ำได้กับการเรียนรู้ที่เร็วขึ้น
ช่วงกลางอันซับซ้อนของการนำ AI มาใช้ที่องค์กรยังเรียนรู้ไม่ได้
- จากมุมมองของ Ethan Mollick ใน
Leadership, Lab, and Crowdการเพิ่มผลิตภาพของพนักงานด้วย AI ในระดับบุคคลไม่ได้กลายเป็น ผลลัพธ์ในระดับองค์กร โดยอัตโนมัติ- พนักงานอาจเขียนได้เร็วขึ้น วิเคราะห์ได้มากขึ้น ทำงานอัตโนมัติได้มากขึ้น และทำงานแบบ “ไซบอร์ก” ได้ แต่บริษัทอาจแทบไม่ได้เรียนรู้อะไรเลย
- เครื่องมืออย่าง GitHub Copilot, ChatGPT Enterprise, Claude, Gemini, Cursor ได้เข้ามาอยู่ในบริษัทแล้ว และในแต่ละทีมมักมีคนที่ไปไกลเกินกว่าสื่อการอบรมอย่างเป็นทางการมาก
- ผู้บริหารอาจเห็นการใช้งานไลเซนส์ จำนวนพรอมป์ต์ แบบสำรวจ PoC ภายใน และเอกสารของคณะกรรมการกำกับทิศทาง แต่กลับมองไม่ค่อยเห็นว่าการเรียนรู้จริงเกิดขึ้นที่ไหน
- ในบางบริษัท AI ถูกส่งต่อไปให้ฝ่าย IT ทันที แล้วหลังจากนั้นก็ไม่คืบหน้าอีก
- ช่วงกลางที่ซับซ้อน ของการนำ AI มาใช้ เริ่มต้นจากสภาวะที่การใช้ AI แพร่หลายแล้วแต่ไม่สม่ำเสมอ บางส่วนซ่อนอยู่ เปรียบเทียบกันยาก และยังไม่เชื่อมโยงกับการเรียนรู้ขององค์กร
- หน่วยของการนำไปใช้ไม่ใช่ทั้งองค์กรอีกต่อไป และอาจไม่ใช่แม้แต่ทีม แต่เปลี่ยนเป็นลูป (loop) ภายในงานจริง
สิ่งที่เกิดขึ้นหลังจากทุกคนมี Copilot
- ระยะแรกของการนำ AI มาใช้ดูคล้ายการ rollout แบบ enterprise ดั้งเดิม จึงค่อนข้างคุ้นเคย
- ซื้อที่นั่งใช้งาน กำหนดขอบเขตการใช้ที่ยอมรับได้ จัดอบรม สร้างเครือข่ายแชมเปียน และให้แชร์ use case กันในช่อง Teams
- ช่องทางเหล่านี้อาจคึกคักอยู่พักหนึ่ง ก่อนจะกลายเป็นคลังภายในองค์กรที่เต็มไปด้วยเจตนาดีแต่ไม่ค่อยถูกใช้งาน
- ในระยะที่สอง วิธีใช้ AI จะเริ่มแยกออกจากกันอย่างมากแม้อยู่ในบริษัทเดียวกัน
- บางทีมใช้ Copilot แค่ช่วยเติมโค้ดอัตโนมัติ
- บางทีมใช้ Claude Code ในลูปที่แน่นหนาพร้อมการทดสอบ การรีวิว และการปรับจูนอย่างต่อเนื่อง
- คนดูแลผลิตภัณฑ์เริ่มสร้างซอฟต์แวร์ต้นแบบจริงแทนการทำหน้าจอใน Figma
- วิศวกรอาวุโสมอบหมายการวิเคราะห์สาเหตุรากให้เอเจนต์ แล้วได้วิธีแก้ที่ใช้ได้จริงภายใน 1 ชั่วโมง จากงานที่ถ้าไม่มี AI อาจใช้เวลา 2 สัปดาห์
- จูเนียร์อาจสร้างโค้ดที่ดูดีได้ แต่ไม่รู้ว่าสมมติฐานเชิงสถาปัตยกรรมอะไรถูกแทรกเข้ามาในระบบบ้าง
- ทีมซัพพอร์ตอาจค่อย ๆ เปลี่ยนทิกเก็ตซ้ำ ๆ ให้กลายเป็น workflow อัตโนมัติอย่างเงียบ ๆ และพวกเขารู้จุดเจ็บปวดจริงที่ Center of Excellence ไม่เคยถามถึง
- ในกรอบของ Mollick ฝ่ายผู้นำมีหน้าที่กำหนดทิศทางและให้ไฟเขียว Crowd คือคนที่ทำงานจริงจึงเป็นผู้ค้นพบ use case ส่วน Lab จะเปลี่ยนสิ่งค้นพบนั้นให้กลายเป็นแนวปฏิบัติร่วม เครื่องมือ benchmark และระบบใหม่
- ความยากสำคัญคือสิ่งค้นพบจะเคลื่อนจากบุคคลไปสู่ทีม และจากทีมไปเป็นความสามารถขององค์กรได้อย่างไรในทางปฏิบัติ
วิธีบริหารการเปลี่ยนแปลงแบบเดิมช้าเกินไป
- บริษัทส่วนใหญ่พยายามจัดการการนำ AI มาใช้ด้วยกลไกบริหารการเปลี่ยนแปลงแบบเดิม
- ใช้ชุมชนนักปฏิบัติ เซสชันช่วงกลางวัน เครือข่ายแชมเปียน เอกสาร enablement office hour เดโมรายเดือน แบบสำรวจ และแดชบอร์ด
- ในองค์กรที่แม้แต่การอนุญาตให้ทดลองยังเป็นเรื่องยาก วิธีเหล่านี้ก็ยังมีประโยชน์
- แต่การใช้ AI ที่น่าสนใจจริง ๆ ไม่ได้รอการประชุมคอมมูนิตี้ครั้งถัดไป แต่มันเกิดขึ้นระหว่างการทำงานจริง
- มันปรากฏอยู่ในการรีวิวโค้ด ข้อเสนอการขาย งานวิจัย ต้นแบบผลิตภัณฑ์ เหตุขัดข้องในการปฏิบัติการ กลยุทธ์การทดสอบ และคำถามด้าน compliance
- สำหรับคอมโพเนนต์ผลิตภัณฑ์บางประเภท อาจเกิดรูปแบบที่เข้าใกล้ “dark factory”
- เขียนความตั้งใจ
- ปล่อยให้เอเจนต์วิ่งในลูปแบบหลวม ๆ
- ใส่ backpressure มากพอเพื่อไม่ให้หลุดทิศทาง
- ประเมินผลลัพธ์ด้วยสถานการณ์ที่เข้มงวด
- ขัดเกลาความตั้งใจและวนซ้ำจนได้ผลลัพธ์คุณภาพสูงอย่างต่อเนื่อง
- การเรียนรู้ที่มีประโยชน์มักสูญเสียความคมเมื่อถูกสรุปลงเป็นสไลด์ best practice
- เพราะสิ่งที่สร้างคุณค่าจริงคือบริบทที่หายไป การทดสอบที่ล้มเหลว พฤติกรรม API แปลก ๆ และแรงเสียดทานที่มนุษย์ใช้ดึงเอเจนต์กลับมาเมื่อมันหลุดไปในทางไร้สาระ
- จากมุมมองของ elastic loop การทำงานร่วมกับ AI ไม่ได้มีโหมดเดียว
- มันยืดได้ตั้งแต่การขับร่วมกันแบบใกล้ชิดและ synchronous ไปจนถึงการมอบหมายแบบหลวมและ asynchronous
- คำถามสำคัญไม่ใช่ “คนใช้ AI หรือไม่” แต่คือทีมควรใช้ลูปขนาดไหน ตรงไหนต้องมีแรงต้าน ผลลัพธ์แบบใดต้องคงอยู่หลังลูปจบ และผลลัพธ์นั้นจะกลายเป็นการเรียนรู้ขององค์กรได้อย่างไร
- นี่เป็นคำถามที่ยากกว่าการนับการใช้เครื่องมือหรือจำนวนโทเคนมาก
Scrum ถูกสร้างขึ้นบนสมมติฐานว่าการทำซ้ำมีราคาแพง
- หลายส่วนของกระบวนการซอฟต์แวร์สมัยใหม่ มีอยู่เพราะการทำซ้ำโดยมนุษย์เคยมีต้นทุนสูง
- รวมถึงการวางแผนสปรินต์ การประเมินงาน standup user story การจัดระเบียบทิกเก็ต การส่งต่องาน และพิธีกรรมต่าง ๆ เพื่อประสานงานและลดความเสี่ยง
- หากการทำซ้ำหนึ่งรอบใช้เวลาหลายวันหรือหลายสัปดาห์ ก็จำเป็นต้องมีโครงสร้างเพื่อกันไม่ให้เกิดการทำซ้ำที่สูญเปล่า
- วิศวกรรมแบบเอเจนต์เปลี่ยนเศรษฐศาสตร์ของการทำซ้ำ
- ทำให้สร้างตัวเลือกได้มากขึ้นจริง
- ทำให้ขยับจากความตั้งใจไปสู่ต้นแบบและการประเมินผลได้เร็วขึ้น
- ทำให้คนดูแลผลิตภัณฑ์ได้เห็นซอฟต์แวร์ที่ใช้งานได้เร็วขึ้น
- ทำให้วิศวกรทดสอบสมมติฐานได้มากขึ้นก่อนตัดสินใจ
- มันไม่ได้ทำให้การส่งมอบง่ายอย่างน่าอัศจรรย์ แต่ย้ายข้อจำกัดจากฝั่ง implementation ไปอยู่ที่ความตั้งใจ การตรวจสอบ วิจารณญาณ และฟีดแบ็ก
- หลายองค์กรเรียกตัวเองว่า agile มานาน 20 ปี แต่ยังคง reflex แบบองค์กรที่ agile เคยพยายามลบออก
- AI ทำให้ความคล่องตัวที่แท้จริงดูเป็นไปได้มากขึ้น แต่ระบบยังคงเรียกร้องคำมั่นแบบสปรินต์ 2 สัปดาห์ เอกสารส่งต่องาน และกระบวนการที่ตั้งอยู่บนสมมติฐานว่าการทำซ้ำเป็นสิ่งหายาก
- ลูปอาจเคลื่อนที่เร็วกว่าความเร็วที่องค์กรจะย่อยสิ่งที่เรียนรู้จากลูปนั้นได้
ค่าใช้ AI บีบให้องค์กรต้องถามคำถามที่ดีกว่าเดิม
- การใช้ AI มีแนวโน้มจะถูกวัดได้ชัดเจนขึ้น
- บรรยากาศ enterprise แบบปัจจุบันที่ “ทุกคนเข้าถึงได้และยังไม่ต้องกังวลเรื่องต้นทุนมากนัก” อาจอยู่ได้ไม่นาน
- เรื่อง model routing งบโทเคน การคิดราคาแบบ usage-based ต้นทุนการอนุมาน และ governance ว่างานแบบไหนอนุญาตให้ใช้โมเดลใด จะถูกทำให้ชัดเจนขึ้น
- คำถามสำคัญไม่ใช่การลดต้นทุนโทเคนในเชิงนามธรรม
- เหมือนกับที่คำถามสำคัญของการส่งมอบซอฟต์แวร์ไม่เคยเป็นการลดจำนวนครั้งการกดแป้นพิมพ์ให้ต่ำสุด
- คำถามที่ดีกว่าคือ “เพราะใช้โทเคนเหล่านั้นแล้ว อะไรเปลี่ยนไปบ้าง”
- ควรหลีกเลี่ยงการนับเพียงจำนวน pull request
- ลูปใดปิดได้เร็วขึ้น
- การตัดสินใจใดดีขึ้น
- การวิเคราะห์สาเหตุรากใดคมขึ้น
- การรีวิวใดจับปัญหาได้มากขึ้น
- ทีมใดเรียนรู้รูปแบบที่นำกลับมาใช้ซ้ำได้
- ไอเดียผลิตภัณฑ์ใดถูกยกเลิกได้เร็วขึ้นเพราะต้นแบบช่วยเปิดเผยจุดอ่อน
- AI สร้างการเรียนรู้ตรงไหน และตรงไหนเพียงแค่สร้าง output เพิ่มขึ้น
- “output ต่อโทเคน” เป็นเพียง reflex การวัดผลแบบเก่าที่สวมเสื้อผ้าใหม่
- สิ่งที่สำคัญกว่าคือแนวคิดแบบ การเรียนรู้ต่อโทเคน
Loop Intelligence ในฐานะเส้นทางฟีดแบ็กที่หายไป
- ในช่วงกลางที่ซับซ้อนของการนำ AI มาใช้ บริษัทต้องมีความสามารถ 3 อย่าง
-
Agent Operations
- จัดการว่าเอเจนต์และเครื่องมือ AI ใดกำลังทำงาน แตะระบบใดได้บ้าง และมองเห็นข้อมูลอะไรได้บ้าง
- รวมถึงเรื่องว่าการกระทำใดต้องได้รับอนุมัติ มีตัวตน การตรวจสอบ สิทธิ์ และ runtime visibility อยู่ที่ไหน
- งานแบบเอเจนต์สุดท้ายแล้วแตะระบบจริง จึงทำให้มิติด้านการควบคุมมีความสำคัญ
-
Loop Intelligence
- ระบุว่าลูปที่มี AI ช่วยหรือเป็นเอเจนต์เต็มรูปแบบใดสร้างการเรียนรู้จริง
- มองเห็นว่าลูปใดยังค้างเปิด ลูปใดเสื่อมลง เอเจนต์สร้าง leverage ตรงไหน และแตกแขนงออกนอกเรื่องตรงไหน
- ประเมินได้ว่าทีมใดยังต้องถูกผูกไว้กับการกำกับดูแลอย่างใกล้ชิดเพราะขาดการทดสอบ บริบท หรือสัญชาตญาณ และทีมใดพร้อมจะมอบหมายแบบหลวมขึ้นแล้ว
-
Agent Capabilities
- กระจายความสามารถที่มีประโยชน์ไปทั่วทั้งองค์กร โดยไม่ตั้งสมมติฐานว่ามีเอเจนต์ยักษ์ 3 ตัวแล้วจะทำงานของทุกคนได้
- AI เริ่มเคลื่อนตัวเหมือนเทคโนโลยีพื้นฐานที่ลื่นไหล มากกว่าจะเป็นหมวดแอปพลิเคชันเดียวตายตัว
- มันไม่ค่อยเข้ากับแนวคิดการเลี้ยง “HR agent”, “engineering agent”, “sales agent” อย่างละตัวไว้ในสวนสัตว์ enterprise
- ความสามารถต้องไหลไปยังจุดที่งานจริงเกิดขึ้น
- harness ของพนักงาน
- เอเจนต์เบื้องหลัง
- ทีมผลิตภัณฑ์
- บริการแพลตฟอร์ม
- ทักษะเฉพาะพื้นที่
- เซิร์ฟเวอร์ MCP
- ชุดประเมินผล
- runbook
- ตัวอย่าง
- ขั้นตอนเฉพาะโดเมน
คำถามระดับแพลตฟอร์มและฟีดแบ็กฮาร์เนส
- คำถามสำคัญในระดับแพลตฟอร์มคือความเป็นเจ้าของและการเคลื่อนย้ายของความสามารถที่มีประโยชน์
- ต้องมีวิธีทำให้ทักษะเอเจนต์ที่มีประโยชน์ซึ่งทีมหนึ่งค้นพบ ถูกส่งต่อไปยังทีมอื่นโดยไม่กลายเป็นแค่เทมเพลตที่ตายแล้ว
- harness ของนักพัฒนา harness ของคนดูแลผลิตภัณฑ์ เอเจนต์เบื้องหลังของทีมซัพพอร์ต และ workflow ด้าน compliance ต้องได้รับการเสริมกำลังแตกต่างกัน
- ความสามารถบางอย่างควรอยู่ใกล้ทีม บางอย่างควรอยู่ที่ชั้นแพลตฟอร์ม และบางอย่างไม่ควรถูกทำให้เป็นมาตรฐานเพราะบริบทเฉพาะพื้นที่คือแก่นสำคัญของมัน
- หากมีเพียงหนึ่งในสามความสามารถ ทุกอย่างจะเริ่มผิดรูปอย่างรวดเร็ว
- มีแต่ Agent Operations โดยไม่มี Loop Intelligence จะกลายเป็นระบบราชการแห่งการควบคุม
- มีแต่ Loop Intelligence โดยไม่มี Agent Capabilities จะกลายเป็นชั้นการวิเคราะห์ที่ค้นพบรูปแบบมีประโยชน์ได้ แต่เอากลับใส่งานจริงไม่ได้
- มีแต่ Agent Capabilities โดยไม่มี Operations และ Loop Intelligence จะกลายเป็นความระเกะระกะของเครื่องมือที่แค่รีแบรนด์ใหม่ให้ดูดีขึ้น
- เส้นทางการควบคุม เส้นทางการเรียนรู้ และเส้นทางความสามารถ ต้องมาบรรจบกันที่ใดที่หนึ่ง
- ภายในองค์กรอาจเรียกสิ่งนี้ว่า feedback harness
- สิ่งที่ลูกค้าซื้อไม่ใช่กลไกที่สง่างาม แต่คือความมั่นใจ การตัดสินใจที่ดีขึ้น การเรียนรู้ที่เร็วขึ้น ความสูญเปล่าที่น้อยลง และการมอบหมายงานที่ปลอดภัยขึ้น
- แนวคิดที่อาจสื่อสารกับลูกค้าได้ดีกว่าคือ Loop Intelligence Hub
- feedback harness คืออุปกรณ์ที่คอยฟังลูปการทำงานจริง
- มันมองเห็นงาน พรอมป์ต์ สเปก การรีวิว สถานการณ์ สมมติฐานที่ถูกยอมรับหรือปฏิเสธ สัญญาณการปฏิบัติการ งานที่ต้องทำซ้ำ และการตัดสินใจกับการแทรกแซงของมนุษย์
- มันไม่ได้มีไว้สอดส่องคน แต่มีไว้เพื่อเข้าใจลูป
- เวอร์ชันแรกไม่จำเป็นต้องเป็นแพลตฟอร์มขนาดมหึมา
- เพียงเลือก workflow จริงสักไม่กี่ตัว วัดจุดที่ความตั้งใจ งานของเอเจนต์ การตรวจสอบ และการตัดสินใจของมนุษย์ทิ้งร่องรอยเอาไว้แล้ว เก็บฟีดแบ็กเชิงคุณภาพให้พอเข้าใจว่าทำไมลูปจึงสำเร็จหรือล้มเหลว แล้วแปลงสิ่งนั้นเป็นผลลัพธ์การเรียนรู้ที่นำไปใช้ซ้ำได้
- Loop Intelligence Hub เปลี่ยนสัญญาณให้เป็นรูปแบบที่องค์กรนำไปลงมือทำได้
- backlog สำหรับ enablement
- เรดาร์ความสามารถ
- เอกสารสรุปเพื่อการลงทุน
- ช่องว่างด้าน governance
- workflow ที่นำกลับมาใช้ซ้ำได้
- ความต้องการฝึกอบรม
- ลำดับความสำคัญของการประเมินผล
- ไม่ใช่แดชบอร์ดแบบเดียวใช้ได้ทุกที่ แต่ต้องเป็น output ที่สอดคล้องกับบริบท
- output ที่น่าสนใจไม่ใช่ตัวแดชบอร์ด แต่คือการตัดสินใจที่อยู่เบื้องหลัง
- บางทีมต้องมี backpressure ที่ดีกว่านี้ก่อนจะมอบหมายได้มากขึ้น
- บางกลุ่มผลิตภัณฑ์มีรูปแบบ dark factory ที่ทำซ้ำได้สำหรับคอมโพเนนต์บางชนิดที่แคบมาก
- workflow ด้าน compliance บางแบบต้องมีขอบเขตเครื่องมือที่ถูกกำกับด้วย governance
- ทักษะบางอย่างควรถูกย้ายไปเป็นแพลตฟอร์มเพราะมีถึงห้าทีมที่สร้างขึ้นใหม่ผิด ๆ ซ้ำกัน
- harness ทำหน้าที่เก็บข้อมูล hub ช่วยให้องค์กรตัดสินใจ และชั้นความสามารถจะใส่การเรียนรู้กลับคืนสู่งาน
ถ้ามันกลายเป็นการสอดส่องพนักงาน มันจะล้มเหลว
- หากโครงสร้างนี้กลายเป็นระบบให้คะแนนพนักงาน ทุกอย่างจะพังทันที
- ถ้าพนักงานเชื่อว่าองค์กรกำลังวัดว่าพวกเขาใช้ AI มากพอหรือไม่ พวกเขาจะบิดเบือนสัญญาณ
- ถ้าเชื่อว่าการทดลองทุกอย่างจะกลายเป็นความคาดหวังด้านผลิตภาพ พวกเขาจะซ่อนการทดลองนั้น
- ถ้าเชื่อว่า workflow ที่ดีที่สุดจะกลายเป็นภาระงานมาตรฐานใหม่ทันที พวกเขาจะเก็บมันไว้เป็นเรื่องส่วนตัว
- บริษัทจะได้รูปแบบการนำไปใช้ที่แย่ที่สุด คือการปฏิบัติตามที่มองเห็นได้ แต่การเรียนรู้กลับมองไม่เห็น
- คำถามที่มีประโยชน์ไม่ใช่ “ใครใช้ AI มากพอ”
- AI เปลี่ยนงานตรงไหนในแบบที่องค์กรสามารถเรียนรู้จากมันได้
- ลูปใดมีสุขภาพดีขึ้น
- ทีมใดต้องการ backpressure ที่ดีกว่านี้ก่อนจะมอบหมายมากขึ้น
- หากต้นแบบกำลังกลายเป็นซอฟต์แวร์จริง ทีมผลิตภัณฑ์ใดต้องการสภาพแวดล้อมแบบอื่น
- จำเป็นต้องมีนโยบาย แต่ governance ก็เหมือนการเรียนรู้ตรงที่มันจะเป็นจริงได้ก็ต่อเมื่อถูกนำไปใช้
- เมื่อเอเจนต์เริ่มแตะงานที่อยู่ใกล้กับงานปฏิบัติการ
- เมื่อคนดูแลผลิตภัณฑ์เริ่มสร้างต้นแบบแทนการเขียนสเปก
- เมื่อผู้พัฒนาเริ่มมอบหมายการวิเคราะห์สาเหตุราก
- เมื่อต้นทุนโทเคนพุ่งจนผู้บริหารต้องการคำตอบ
- ตอนนั้นองค์กรจะรู้ว่าตนสร้างระบบการเรียนรู้ไว้จริง หรือแค่ซื้อที่นั่งมาเยอะ ๆ เท่านั้น
ช่วงกลางที่ซับซ้อนไม่ใช่ช่วงที่มีไว้แค่อดทนผ่านไป
- ระยะแรกของการนำ AI มาใช้เป็นเรื่องของการเข้าถึง
- ใครได้เครื่องมือ ใครได้สิทธิ์ ใครเป็นคนเจรจาสัญญา และใครสามารถทดลองโมเดลล่าสุดได้โดยไม่ต้องผ่าน procurement ticket เป็นเรื่องสำคัญ
- ระยะนี้ยังสำคัญอยู่ แต่จะไม่ใช่ข้อแตกต่างในการแข่งขันไปอีกนาน
- การเข้าถึง frontier intelligence อาจเช่าหรือยืมมาได้ แต่การควบคุมการปฏิบัติการและการเรียนรู้ขององค์กรนั้นยืมมาแบบเดียวกันไม่ได้
- ความได้เปรียบถัดไปคือ ความเร็วในการเรียนรู้
- ใครค้นหารูปแบบจริงได้เร็วกว่า
- ใครย้ายสิ่งค้นพบจากบุคคลไปสู่ทีม และจากทีมไปสู่ความสามารถขององค์กรได้
- ใครใส่ backpressure ให้กับลูปแบบเอเจนต์เพื่อกันไม่ให้เอเจนต์แตกแขนงออกไป
- ใครกระจายความสามารถของเอเจนต์ที่มีประโยชน์ได้โดยไม่พยายามทำให้มันเป็นเอเจนต์ enterprise ขนาดยักษ์ตัวเดียวที่ใช้กับทุกคน
- ใครใช้วิศวกรรมแบบเอเจนต์ทำให้ agile เข้าใกล้ความจริงมากขึ้น แทนที่จะเอา AI ไปวางทับบนพิธีกรรมเดิม
- การรอ playbook การนำไปใช้ที่ฟันธงแล้ว ไม่ช่วยให้เข้าใจการเปลี่ยนแปลงนี้ได้ง่ายขึ้น
- แทนที่จะรอคำตอบสุดท้ายจาก vendor ที่ปรึกษา หรือห้องวิจัย AI องค์กรควรวัดงานจริง แชร์การเรียนรู้ที่ยังยุ่งเหยิง เปิดให้คนอื่นช่วยชี้จุดบอด และทำซ้ำอย่างเปิดเผย
1 ความคิดเห็น
ความเห็นจาก Hacker News
ในสภาพแวดล้อมขององค์กรขนาดใหญ่ การนำ AI มาใช้แทบไม่ออกไปไกลกว่านอกทีมพัฒนา และมีเพียงนักพัฒนาเท่านั้นที่ใช้ GitHub Copilot ได้
โค้ดใช้เวลา 6–12 เดือนกว่าจะไปจากการคอมมิตจนถึงการดีพลอยขึ้นระบบจริง และแต่เดิมความเร็วในการพัฒนาก็ไม่ใช่คอขวดอยู่แล้ว
สิ่งที่กินเวลาคือขั้นตอนอย่างการ provision โครงสร้างพื้นฐาน การทดสอบ การอนุมัติ การจัดการการเปลี่ยนแปลง และตารางการดีพลอย และ AI กลับทำให้คอขวดหลังการพัฒนาแย่ลง จนการเปลี่ยนแปลงไปกองรออยู่หน้าขบวนปล่อยรีลีส
ถ้าองค์กรใหญ่จะให้คุ้มกับต้นทุนโทเคน ก็ต้องเรียนรู้วิธีปล่อยซอฟต์แวร์ให้เร็วขึ้น และโค้ดที่ไม่ถูกดีพลอยไม่ใช่ทรัพย์สินแต่เป็นหนี้
จริงอยู่ว่าการพัฒนาซอฟต์แวร์ไม่มีประสิทธิภาพ แต่แก่นสำคัญไม่ใช่การเขียนโค้ด หากเป็นการค้นหาและออกแบบว่าควรเขียนโค้ดอะไร ซึ่งจุดนี้กลับไม่ค่อยถูกนึกถึง
พอ Microsoft ตะโกนว่า “เขียนโค้ดเร็วขึ้น 50%!” ผู้บริหารก็รับไปเป็น “ผลิตภัณฑ์เร็วขึ้น 50% เงินก็มาเร็วขึ้น 50%”
ทันทีที่เริ่มเรียกร้องผลตอบแทนจากการลงทุน มันมีโอกาสสูงที่จะกลายเป็นหายนะ และตอนนี้ทุกคนแค่ยังหลีกเลี่ยงการวัดผลอยู่
สักวันนักลงทุนจะถามว่า “ใช้เงินไป 2 ล้านดอลลาร์ งั้นก็ต้องทำกำไรสุทธิ 4 ล้านดอลลาร์สิ” แต่ผลแบบนั้นคงออกมายาก
Copilot และ Claude ไม่ได้แก้คอขวดจริงอย่างความรู้ในองค์กรที่สะสมมานาน วิธีแก้ปัญหาเฉพาะที่ไม่เคยถูกบันทึกไว้ หรือความเป็นไปได้ในการนำไปใช้ในอนาคต
โค้ดไม่ใช่ตัวผลิตภัณฑ์จริง และไม่ใช่งานจริงด้วยซ้ำ ใน codebase ที่ดี มันแทบเป็นผลพลอยได้ราคาถูกมากจากกระบวนการออกแบบและค้นคว้า
เมื่อขัดเกลาโจทย์ว่า “ทีมจัดซื้อใช้การค้นหายาก” ให้กลายเป็น ticket ที่ลงมือทำได้แล้ว React search filter component ก็แทบถูกกำหนดไว้แล้ว และการเขียนโค้ดก็เกือบเป็นแค่พิธีการ 10 นาที
ถึง Copilot จะลดเหลือ 5 นาที พอเทียบกับการประชุมและโทรคุย 6 ชั่วโมงก่อนหน้านั้น ก็ไม่ได้ชวนทึ่งเท่าไร
เรื่องโภชนาการกับแคลอรีก็มีประโยชน์แค่ถึงระดับหนึ่ง หลังจากนั้นผลตอบแทนจะลดลงและสุดท้ายกลายเป็นผลเสีย
มันอาจไม่ใช่อุปมาที่สมบูรณ์แบบ แต่ช่วยให้มองภาพได้ว่า การผลิตออกมามากขึ้นอาจกลับให้คุณค่าน้อยลง
เคยได้รับฟีดแบ็กจากลูกค้าว่าเอกสารครบและละเอียดมาก แต่เยอะจนล้นเกิน สุดท้ายจึงพบว่าbullet point สั้น ๆไม่กี่ข้อสื่อสารประเด็นสำคัญได้ดีกว่าเอกสาร 5 หน้า
[0] https://en.wikipedia.org/wiki/Theory_of_constraints
[1] https://www.goodreads.com/book/show/113934.The_Goal
[2] https://www.goodreads.com/en/book/show/17255186-the-phoenix-...
ฝ่ายการเงินมาถามว่าสามารถvibe codingแอปสำหรับวางแผนการเงินด้วย Copilot, Cursor, Claude ได้ไหม และยังบอกอีกว่า “CFO ไปลอง Lovable แล้วมั่นใจ เลยสั่งให้เรามา vibe coding แอป”
เหมือนตั้งใจใช้ตรรกะนี้เพราะรู้ว่าพอมีคำว่า “CFO บอกมา” ผู้บริหารจะนิ่งทันที
ตอนท้ายยังห่อคำพูดให้ดูดีอีกว่า “เราควรตรวจสอบว่าแอปที่ vibe coding สามารถอยู่ในโดเมนการเงินองค์กรได้หรือไม่ โดยมีความปลอดภัยของข้อมูลและการบำรุงรักษาที่เหมาะสม”
ที่น่าตกใจกว่าคือ นี่คือเหตุผลที่ออกมาจากบริษัทที่มีรายได้ต่อปีเกิน 2 หมื่นล้านดอลลาร์
สำหรับวิศวกรธรรมดาแบบผม การใช้ AI ในบริษัทไม่มีประโยชน์เชิงปฏิบัติจริงเลย
บริษัทกำลังค่อย ๆ ต้มพวกเรา และกลุ่มชนชั้นนำใน HN อย่างนักลงทุน ผู้บริหาร คนดัง และวิศวกรระดับท็อป ก็จะพูดว่า “จะไปต่อต้านนวัตกรรมได้อย่างไร”
AI/LLM ไม่ใช่นวัตกรรมแบบ TCP/IP, Linux, Postgres
สิ่งอย่าง Claude, Codex, Gemini, Grok มีไว้เพื่อกำไร เป็นเครื่องมือที่รีดผลิตภาพออกมาจนหยดสุดท้าย แล้วพอไม่จำเป็นก็ทำให้ปลดคนออกได้
ถ้า AI ดีจริง ก็ควรใช้โมเดลโอเพนซอร์สและใช้กับโปรเจกต์ส่วนตัวจะดีกว่า
AI อาจพ่นโค้ดออกมาได้เยอะ แต่ก็ยังต้องการวิศวกรที่เข้าใจว่ากำลังเกิดอะไรขึ้นจริง ๆ และนั่นก็เป็นคอขวดมาตลอด
ตำแหน่ง junior อาจหายไป แต่วิศวกรระดับ seniorดูเหมือนยังปลอดภัยไปได้อีกพักหนึ่ง
ผมเองก็หัวแข็งโดยธรรมชาติ นี่เป็นบทเรียนที่เรียนรู้มาอย่างยากลำบาก แต่เมื่อถูกจ้างแล้ว ก็ถูกจ้างมาให้ทำสิ่งที่ผู้บริหารต้องการ
ถ้าจะต่อต้าน ก็ได้แค่หวังว่าพวกเขาจะไม่สังเกตหรือไม่สนใจ และยากมากที่จะสร้างการเปลี่ยนแปลงใหญ่
ไม่รู้ว่ายังจำกันได้ไหมว่า SCO ทำอะไรกับอุตสาหกรรมตอนกำลังล่มสลาย
ผมยังไม่เข้าใจว่าทำไมบริษัทถึงยอมมอบข้อมูลลับภายในอย่างโค้ด กระบวนการ ความต้องการของลูกค้า การเมืองภายใน และภาพในหัวของผู้นำ ให้กับสตาร์ตอัปและบริษัทยักษ์ใหญ่ที่ไม่น่าไว้ใจ
Microsoft เองก็เคยขึ้นชื่อเรื่องสัญญารักษาความลับและการใช้อำนาจทางการค้าในทางมิชอบ
ผมไม่เชื่อหรอกว่าบริษัท LLM ยักษ์ใหญ่จะไม่เอาข้อมูลบริษัทไปฝึกโมเดล และก็ไม่เชื่อว่าจะไม่โกหกว่าตัวเองไม่ทำด้วย
ถ้าพวกเขาเริ่มพังลงมา การตื่นทองรอบนี้อาจทิ้งหางที่ยาวและน่าเกลียดเอาไว้
ในความเป็นจริง คนที่ถูกเลย์ออฟคือคนที่ไม่ยอมรับเทคโนโลยีแบบนี้ และถ้าทำตัวแบบนั้น ก็เท่ากับเอาตัวเองเข้าไปอยู่ในขอบเขตที่จะถูกปลด
ดูแค่กรณี Coinbase วันนี้ก็พอ พวกเขากำลังกำจัดคนที่ไม่ยอมรับอนาคต
คนพวกนั้นไม่ได้ช่วยให้เกิดความก้าวหน้า ไม่ได้ช่วยผลักดันไปข้างหน้า และยังฉุดรั้งคนที่ทำอยู่ด้วย
บทความนี้ชี้จุดmessy middleได้ตรงมาก
นักพัฒนาที่มีทั้งความรับผิดชอบและงานของตัวเองอยู่บนเส้นด้าย แทบไม่มีแรงจูงใจจะสร้างลูปปัญญาแบบนี้
ไม่ว่าผู้บริหารจะขออย่างสวยหรูแค่ไหน ผมก็ไม่คิดจะแชร์การเพิ่มผลิตภาพของตัวเองให้ทั้งบริษัทฟรี ๆ แบบเสียสละ
ถ้าเป็นเครื่องมือที่มีประโยชน์อาจแชร์ได้ แต่ความรู้รู้วิธีใช้ AI หรือวิธีตั้งค่า agent ถ้าไม่มีการยอมรับการแบ่งปันเหล่านั้น ก็ควรเก็บไว้กับตัวมากกว่า
บริษัทเราสร้างรางวัล “prompt ประจำสัปดาห์” กับ lunch session เพื่อช่วยกระจายการใช้งาน และยังมีทีมที่พัฒนา workflow แบบนี้อยู่
แต่หากไม่มีรางวัลทางการเงินจริงหรือความมั่นคงในการจ้างงาน ความเสี่ยงและต้นทุนของการกระจายความรู้ก็ตกอยู่ที่นักพัฒนาเต็ม ๆ
ก่อนที่ AI จะเก่งได้ถึงระดับนี้มาก ผมก็สร้าง CLI ส่วนตัวเพื่อให้งานง่ายขึ้นและเขียนสคริปต์อัตโนมัติได้สะดวกขึ้นแล้ว
เพื่อนร่วมงานเห็นเครื่องมือนั้นแล้วอยากให้แชร์ แต่คำตอบแบบรักษาน้ำใจคือปฏิเสธ
ถ้าแชร์ ผมก็จะมีภาระต้องซัพพอร์ต และทุกคนก็จะทำงานได้มีผลิตภาพเท่าผม ทำให้ข้อได้เปรียบของผมหายไป กลายเป็นผลตอบแทนติดลบ
ยิ่งไปกว่านั้น ฝ่ายบริหารก็ไม่ได้มองความคิดสร้างสรรค์ของผมเป็นทรัพย์สิน จึงไม่ได้เพิ่มความมั่นคงในการจ้างงานให้ผม
ไหน ๆ อาจโดนเลย์ออฟอยู่ดีในอนาคตอันใกล้ ก็ไม่มีเหตุผลจะช่วยบริษัทด้วยความหวังดี
ถ้าตอนนี้นักพัฒนากังวลเรื่องงานในตลาดนี้ workflow ส่วนตัวก็ควรถูกปฏิบัติเหมือนความลับทางการค้า
ตัวอย่างนี้ไม่จำกัดแค่ AI แต่ใช้กับ workflow ของ AI ได้เหมือนกันทุกประการ
ในตลาดแรงงานที่ลูกจ้างมีอำนาจ บางครั้งการแชร์ความรู้แบบนั้นกับองค์กรก็สนุกดี แต่ในตลาดที่นายจ้างมีอำนาจ ถ้าอยากเข้าถึงทางเลือกส่วนตัวของผม ก็ต้องจ่ายเงิน
ผมไม่ใช่คนที่มองที่ทำงานเป็นครอบครัว แต่ก็ดีถ้าเราจะทำงานและแชร์กันได้ โดยไม่ต้องกังวลว่ากำลังขุดหลุมฝังตัวเอง
คนส่วนใหญ่ได้รับค่าจ้างมาเพื่อทำงาน และในเวลางานก็แน่นอนว่าต้องทำงานให้นายจ้าง
จริง ๆ แล้วแทบไม่มีอะไรที่วิเศษจนคนอื่นคิดเองไม่ได้
จากประสบการณ์ของผม ต่อให้แชร์พรอมป์ต์หรือเทคนิค ก็แทบไม่มีใครใช้ หรือไม่ก็มันพื้นฐานเกินไปจนแต่ละคนมีเวอร์ชันของตัวเองอยู่แล้ว
ก่อนยุค AI ถ้าใครไม่สนใจ xyz อยู่แล้ว ต่อให้ยกมาเสิร์ฟใส่พาน หลังยุค AI เขาก็ไม่ได้หันมาสนใจขึ้นมาทันที
งานน่าเบื่อแทบหายไปหมด และบางปัญหาก็แค่ปล่อยค้างไว้ให้มันจัดการ ทำให้ได้เวลากลับคืนมา 1–4 ชั่วโมงต่อวัน
คนคนนั้นจะใช้เวลานั้นอย่างมีเหตุผลเพื่อไปหางานเพิ่มมาทำหรือ? ถ้าไม่ใช่บริษัทของตัวเองหรือไม่มีแรงจูงใจพิเศษ ก็คงเป็นไปได้น้อย
ในฐานะนักวิเคราะห์ระบบที่เกษียณมาแล้ว 3 ปี ผมรู้สึกสงสารเพื่อนร่วมงานรุ่นน้อง
ในปี 2023 ผมเป็นคนค่อนข้างกลุ่มแรก ๆ ในทีมที่ใช้ AI เพื่อแกะโค้ด legacyที่อิงกับ Perl ซึ่งผู้เขียนดั้งเดิมออกจากบริษัทไปนานแล้ว และแทบไม่ทิ้งคอมเมนต์หรือเอกสารไว้เลย
โค้ดนั้นทำงานสำคัญมาก และ AI ก็ช่วยดึงเราออกจากวิกฤต ทำให้ทุกคนทึ่งกับเทคโนโลยีใหม่นี้
แต่ยิ่งนานไป มันยิ่งดูเหมือนไม่ใช่เครื่องมือที่ผมใช้ แต่เป็นสิ่งที่ถูกกระทำกับผม
ไม่มีใครร้องขอสิ่งนี้
ผมไม่รู้ว่าตั้งแต่เมื่อไร แรงบันดาลใจและการใช้ความคิดถึงถูกลดคุณค่าให้ไร้ความหมาย เพียงเพื่ออ้างว่าทุกอย่างต้องทำได้ทันที และงานก็หมดความเป็นมนุษย์ไปแล้ว
AI เพียงอย่างเดียวไม่ได้มีประโยชน์มากนัก
agent ลืมสิ่งต่าง ๆ และทำผิดพลาดมากพอจนต้องตรวจทุกงานอยู่ดี สุดท้ายอาจทำให้ผลิตภาพลดลงด้วยซ้ำ
คุณค่าที่แท้จริงจะปรากฏเมื่อใช้ AI เป็นเครื่องมือสำหรับสร้างเครื่องมืออื่น
เช่น ให้มันสร้างเครื่องมือที่บังคับให้งานเดินหน้าต่อไปจนกว่าจะถึงคุณภาพระดับหนึ่ง หรือรันการตรวจสอบความสอดคล้องของผลลัพธ์แล้วบอกว่าต้องแก้ตรงไหน
ถึงตอนนั้นจึงจะเชื่อถืองานได้
ตอนนี้บทบาทและ workflow ส่วนใหญ่ยังออกแบบมาในโครงสร้างที่ต้องใช้เครื่องมือที่มีอยู่เพื่อให้งานบางอย่างสำเร็จ และในระบบแบบนั้น AI ก็แทรกตัวได้แค่ตรงขอบ ๆ
เป็นบทความที่ดี และส่วนที่ว่าด้วยวิธีที่องค์กรนิยามงานกำลังเปลี่ยนไปนั้นโดดเด่นมาก
ในโมเดลเดิม ผลงานและ OKR ผูกอยู่กับสายงาน ตำแหน่ง และความคาดหวังของแต่ละบทบาท
ในยุค AI เส้นแบ่งเหล่านั้นเริ่มพังลง
ปัญหาที่ลึกกว่านั้นเป็นเรื่องทางจิตวิทยาและองค์กร ผู้คนต้องต่อรองเส้นแบ่งระหว่าง “นี่คืองานของฉัน” กับ “นี่ไม่ใช่ความรับผิดชอบของฉัน” อยู่ตลอด
จึงเกิดปัญหาหลักของการนำไปใช้: การถูกมองเห็นและยอมรับว่าเป็นผู้ใช้ AI ขั้นสูงมีข้อดีอะไร?
ถ้าบริษัทรู้ว่าผมทำงานได้เร็วขึ้น ดีกว่าเดิม และข้ามหลายฟังก์ชันได้มากขึ้น แล้วถ้าไม่มีระบบยอมรับ ให้รางวัล หรือเส้นทางเติบโตในอาชีพที่ชัดเจน ผมจะเปิดเผยเรื่องนั้นไปทำไม?
ในโลกที่ agent ข้ามเส้นแบ่งเหล่านั้นไปมาได้ เรื่องนี้อาจเละเทะพอสมควร
วิศวกร AIที่มีฝูง agent อยู่ข้างกาย จะรับผิดชอบให้ทุกอย่างเดินต่อไปด้วยหรือไม่? ผมค่อนข้างสงสัย แต่คงต้องรอดู
ถ้ามีใครบางคนที่สนใจงานใหม่แบบนั้น เอาคำแนะนำเรื่องบริบทเฉพาะของบริษัทมาผสมกับแนวทางล่าสุดอีกไม่กี่สัปดาห์ สุดท้ายคนคนนั้นก็จะไปอยู่ในบทบาทของผู้เชี่ยวชาญโดเมนที่พร้อมจะถูกแทนที่
คำตอบของคำถามว่า “ผลตอบแทนจากเงิน 2 ล้านยูโรที่จ่ายให้ Anthropic เมื่อปีที่แล้วอยู่ไหน?” ก็คือแผ่นป้ายPlatinum Tokenสไตล์ YouTube ที่แขวนอยู่ในห้อง CEO
อคติในสมมติฐานที่ซ่อนอยู่ในคำถาม “ผลตอบแทนจากเงิน 2 ล้านยูโรที่จ่ายให้ Anthropic เมื่อปีที่แล้วอยู่ไหน?” นั้นเหลือเชื่อจริง ๆ
ปัญหาคือ generative AI ไม่สามารถสร้างผลตอบแทนที่มองเห็นได้
แต่ “ทางแก้” กลับกลายเป็นการจัดโครงสร้างองค์กรพัฒนาทั้งหมดใหม่ให้ยึดเทคโนโลยีนั้นเป็นศูนย์กลาง แล้วประดิษฐ์เครื่องมือใหม่ขึ้นมา
จุดประสงค์ที่แท้จริงของบทความแบบนี้ไม่ได้อยู่ที่เนื้อหาที่พูดถึงตรง ๆ แต่อยู่ที่การทำให้สมมติฐานพื้นฐานเหล่านั้นดูเป็นเรื่องปกติ
การทำงานในสายนี้ตอนนี้แย่มากจริง ๆ
บริษัทที่ผมทำอยู่ ปล่อยให้แม้แต่คนที่ไม่ใช่นักพัฒนาก็ใช้ AI กันหมด
ผมอยากลาออกไปทำงานสายอื่นจริง ๆ แต่ที่ที่ผมอยู่ เงินเดือนเริ่มต้นไม่พอจ่ายค่าเช่า และผมก็อายุมากขึ้นเรื่อย ๆ
การเปรียบเทียบคำสัญญาของ AI กับยุคดอตคอมบูมช่วยให้ผมเข้าใจได้มากขึ้น และมีหลายอย่างที่คล้ายกัน
แต่อินเทอร์เน็ตเป็นแนวคิดที่ง่ายกว่าสำหรับฝั่งองค์กร
โดยพื้นฐานแล้วมันหมายถึงตอนนี้คนสามารถซื้อของจากคอมพิวเตอร์ของตัวเองได้
แล้วคำสัญญาของ AI คืออะไร? คือการประมาณการให้มันใช้เหตุผลกับสิ่งต่าง ๆ ได้หรือ?
นี่เป็นโจทย์การลงมือทำที่ยากกว่ามากจริง ๆ
นอกเหนือจากงานเขียนโค้ดแล้ว ผมยังไม่คิดว่าได้เห็นอะไรที่เป็นรูปธรรมจริง ๆ