- ช่องว่างด้านผลิตภาพระหว่างผู้ใช้ AI กำลังกว้างขึ้นอย่างรวดเร็ว โดย “ผู้ใช้ระดับพาวเวอร์” ใช้ เครื่องมือ AI ขั้นสูงอย่าง Claude Code, MCPs อย่างจริงจัง ขณะที่คนส่วนใหญ่ยังคง อยู่ในระดับการใช้งานแบบสนทนาเทียบเท่า ChatGPT
- องค์กรขนาดใหญ่มีความยากในการนำเครื่องมือ AI รุ่นใหม่มาใช้เนื่องจาก นโยบายความปลอดภัย, สภาพแวดล้อม IT แบบปิด, ระบบเลกาซี ขณะที่ บริษัทขนาดเล็กกำลังฝัง AI เข้าไปในงานได้อย่างรวดเร็ว และเพิ่มประสิทธิภาพได้มาก
- ช่องว่างนี้กำลังนำไปสู่ ยุคที่ทีมเล็กสามารถสร้างผลิตภาพได้สูงกว่าบริษัทใหญ่แบบมาก ๆ และ การสร้าง API ภายในกับสภาพแวดล้อมรันโค้ดที่ปลอดภัย กำลังกลายเป็นหัวใจของความสามารถในการแข่งขันในอนาคต
- เมื่อนำเอเจนต์มาผสานกับ bash sandbox ที่เข้าถึงภาษาโปรแกรมและ API ได้ แม้แต่ผู้ใช้ที่ไม่ใช่สายเทคนิคก็สามารถแทนที่แอปสายผลิตภาพได้เกือบทั้งหมด และนี่คือรูปแบบของ อนาคตของงานความรู้
ผู้ใช้ AI สองประเภท
- ช่องว่างด้านผลิตภาพระหว่างผู้ใช้ AI กำลังขยายตัวอย่างรวดเร็ว
- ฝั่งหนึ่งใช้ Claude Code, MCPs และเวิร์กโฟลว์แบบอิงสกิล โดย แม้แต่คนที่ไม่ใช่สายเทคนิคก็ใช้ AI ผ่านเทอร์มินัลอย่างจริงจัง
- โดยเฉพาะใน สายงานการเงิน มีหลายกรณีที่ใช้ระบบอัตโนมัติด้วย Python เพื่อ ก้าวข้ามข้อจำกัดของ Excel
- อีกฝั่งหนึ่งยังคง อยู่กับการใช้งานแบบถาม-ตอบอย่างง่ายในระดับ ChatGPT
- พนักงานออฟฟิศจำนวนมากยังอยู่ในกลุ่มนี้ และยังใช้ศักยภาพของ AI ได้ไม่เต็มที่
ข้อจำกัดของ Microsoft Copilot
- M365 Copilot มาพร้อมเป็นบันเดิลกับการสมัครใช้ Office 365 จึงมีส่วนแบ่งสูงในตลาดองค์กร แต่ อินเทอร์เฟซอยู่ในระดับเหมือน ChatGPT เวอร์ชันด้อยกว่า
- ฟีเจอร์ "agent" นั้น หากเทียบกับเอเจนต์เขียนโค้ดแบบ CLI (รวมถึง GitHub Copilot CLI ของ Microsoft เอง) ก็แทบจะน่าขำ
มักล้มเหลวกับไฟล์ขนาดใหญ่ และมี ข้อจำกัดด้านหน่วยความจำและ CPU ที่มากเกินไป
- แม้แต่ภายใน Microsoft เองก็ยัง นำ Claude Code มาใช้ในทีมภายใน
- นี่เป็นตัวอย่างที่ชี้ว่า Copilot ตามหลังในเชิงเทคนิค
- ในสภาพแวดล้อมองค์กร Copilot มักเป็นเครื่องมือ AI เพียงตัวเดียวที่ได้รับอนุญาต ทำให้พนักงานต้องยอมเสี่ยงต่อการถูกไล่ออกหรือทุ่มแรงอย่างมากหากต้องการใช้เครื่องมืออื่น
— ผู้บริหารระดับสูงจำนวนหนึ่งได้ ผลลัพธ์ที่ย่ำแย่จากเครื่องมือเหล่านี้จนเหมารวมดูแคลน AI ทั้งหมด หรือไม่ก็ จ่ายเงินมหาศาลให้บริษัทที่ปรึกษารายใหญ่ แต่ก็ยังไม่เห็นผลลัพธ์
ความเสี่ยงเชิงโครงสร้างที่องค์กรขนาดใหญ่กำลังเผชิญ
- นโยบาย IT แบบปิดที่ยึดความปลอดภัยเป็นศูนย์กลาง กำลังขัดขวางนวัตกรรม
- สภาพแวดล้อมที่ล็อกแน่นมาก: แม้แต่ตัวแปลสคริปต์พื้นฐานก็ยังรันบนเครื่องโลคัลไม่ได้ (ถ้าโชคดีก็อาจใช้ VBA ได้ แต่ก็ยังมักถูกจำกัดด้วย Group Policy)
- ซอฟต์แวร์เลกาซี: เวิร์กโฟลว์หลักไม่มี API ภายใน ทำให้เอเจนต์ไม่มีอะไรให้เชื่อมต่อ
- ฝ่ายวิศวกรรมที่แยกเป็นไซโล: หลายแห่งเอาต์ซอร์ซทั้งหมด จึง ไม่มีบุคลากรภายในที่จะสร้างโครงสร้างพื้นฐานสำหรับรันเอเจนต์แบบ sandbox อย่างปลอดภัย
- แน่นอนว่าความกังวลด้านความปลอดภัยนั้นมีอยู่จริง — การปล่อยเอเจนต์เขียนโค้ดไปรันกับฐานข้อมูล production โดยไร้การควบคุมเป็นเรื่องอันตราย
- แต่การทำ sandboxing เป็น งานที่ยาก และ ปัญหาหลักคือไม่มีทีมวิศวกรรมที่สามารถสร้างสิ่งนี้ได้อย่างปลอดภัย
การเติบโตอย่างรวดเร็วของบริษัทขนาดเล็ก
- บริษัทขนาดกลางและเล็กที่ไม่มีข้อจำกัดแบบเลกาซี กำลังนำ AI มาใช้ได้อย่างรวดเร็วและดันผลิตภาพขึ้นแบบก้าวกระโดด
- ฝั่งหนึ่งมีผู้อำนวยการฝ่ายการเงินที่ลองใช้ Copilot for Excel ของ Microsoft (รวมถึงการเชื่อม Gemini กับ Google Sheets ที่ก็แย่พอกัน) แล้วพบว่าแม้งานง่าย ๆ ก็ยังออกมาเละ จึงไม่กลับไปใช้อีกเลย ขณะที่
- อีกฝั่งหนึ่งมี ผู้บริหารสายงานที่ไม่ใช่เทคนิคแต่เรียนรู้ Claude Code และรัน Python บนเครื่องโลคัลได้
- งานแปลงโมเดลการเงินบน Excel ที่ซับซ้อนมากซึ่งมี 30 ชีต ให้กลายเป็น Python ด้วย Claude Code แทบเสร็จได้ด้วย เพียง 2~3 พรอมป์ต์
- เมื่อโมเดลถูกย้ายมาอยู่บน Python แล้ว ก็สามารถใช้ Claude Code เพื่อให้มี ความสามารถในระดับทีมดาต้าไซเอนซ์ ได้
- สามารถรัน Monte Carlo simulation, เชื่อมต่อแหล่งข้อมูลภายนอก, สร้างเว็บแดชบอร์ด และช่วยวิเคราะห์จุดอ่อนของโมเดล (หรือของธุรกิจ) ได้ทั้งหมด
- ในอดีต พนักงานบริษัทเล็กมักอิจฉาทรัพยากรและทีมงานของบริษัทใหญ่
แต่ในสภาพแวดล้อมแบบนี้ ทีมเล็กกลับทำงานได้มีประสิทธิภาพสูงกว่าบริษัทใหญ่มาก และ แนวโน้มด้านผลิตภาพกำลังพลิกกลับ
โครงสร้างการทำงานในอนาคต
- การเพิ่มผลิตภาพด้วย AI เกิดขึ้นจากล่างขึ้นบน (bottom-up)
- ทีมเล็กพยายามสร้างเวิร์กโฟลว์ที่มี AI สนับสนุนสำหรับกระบวนการเฉพาะ และเพราะพวกเขาเข้าใจกระบวนการนั้นอย่างลึกซึ้ง จึงได้ผลลัพธ์ที่ดี
- สิ่งนี้ตัดกันชัดเจนกับทีมวิศวกรรมซอฟต์แวร์จากภายนอกที่ไม่มีประสบการณ์กับกระบวนการเลย
- เป็นภาพที่ตรงกันข้ามกับโปรเจกต์ 'digital transformation' แบบเดิม ๆ แทบทั้งหมด
- บริษัทที่มี API สำหรับระบบภายใน จะทำอะไรได้มากกว่ามาก
- ตั้งแต่ data warehouse แบบอ่านอย่างเดียวที่พนักงานเพียงเชื่อมต่อเข้าไปแล้วรัน query แทนผู้ใช้ ไปจนถึง การทำให้กระบวนการธุรกิจหลักกลายเป็น API
- การรัน code agent ในสภาพแวดล้อม VM ที่ควบคุมความปลอดภัยได้ เป็นทางเลือกที่ใช้งานได้จริง
- เหมาะกับงานรายงานแบบอ่านอย่างเดียว แต่ยังมีข้อจำกัดกับการแก้ไขข้อมูล
- ผู้ให้บริการ enterprise SaaS แบบเลกาซี อยู่ในสถานะที่มี lock-in สูงมาก หรือถ้ามองอีกมุมก็เปราะบางอย่างยิ่ง
- ส่วนใหญ่ไม่ใช่ผลิตภัณฑ์แบบ "API-first" และ API ที่มีอยู่เดิมถูกออกแบบมาสำหรับนักพัฒนา จึง ไม่ได้เหมาะกับสถานการณ์ที่พนักงานหลายพันคนเรียกใช้แบบไม่มีประสิทธิภาพ
- แต่หากมันเป็นแหล่งข้อมูลจริงหนึ่งเดียวของบริษัท (source of truth) การย้ายออกก็ทำได้ยากมาก และมันจะกลายเป็น คอขวดของการเพิ่มผลิตภาพ
- บริษัทขนาดเล็กมักมีแนวโน้มใช้ ผลิตภัณฑ์ที่ใหม่กว่าและออกแบบ API ได้ดีกว่า
- ผลิตภัณฑ์ SaaS รุ่นใหม่เหล่านี้ ออกแบบโดยยึด API เป็นศูนย์กลาง จึงเอื้อต่อการผสานกับ AI
รูปแบบใหม่ของงานความรู้
- การผสานกันของ bash sandbox ที่เข้าถึงภาษาโปรแกรมและ system API ได้ กับ agent framework กลายเป็น เครื่องมือเพิ่มผลิตภาพทรงพลังแม้สำหรับคนที่ไม่ใช่สายเทคนิค
- ผู้ใช้ป้อนพรอมป์ต์ และเอเจนต์จะสร้างผลลัพธ์ผ่าน API
- ไม่ว่าจะเป็นการเขียนรายงาน วิเคราะห์ข้อมูล หรือสร้างเอกสาร ก็สามารถส่งออกได้ในรูปแบบที่ผู้ใช้ต้องการ จน แทนที่แอปออฟฟิศเดิมได้เกือบทั้งหมด
- รูปแบบที่ผู้ใช้เพียงป้อนพรอมป์ต์ แล้วเอเจนต์เชื่อมต่อ API และสร้างผลลัพธ์ตามคำขอ คือ อนาคตของงานความรู้
- ภาวะสองขั้วนี้มีอยู่จริงและกำลังเร่งตัวขึ้นอย่างรวดเร็ว
- การเปลี่ยนแปลงนี้กำลังเปิดยุคที่ ทีมเล็กสามารถสร้างความได้เปรียบในการแข่งขันได้เร็วกว่าบริษัทใหญ่
- ช่องว่างในการใช้ AI มีอยู่จริง และ ความเร็วของมันกำลังเพิ่มขึ้นเรื่อย ๆ
- ในประวัติศาสตร์ไม่เคยมีช่วงเวลาไหนที่ ทีมเล็กจะนำหน้าบริษัทที่ใหญ่กว่าตัวเองพันเท่าได้ง่ายขนาดนี้
4 ความคิดเห็น
ความเห็นจาก Hacker News
ฉันคิดว่าสามารถแบ่งผู้ใช้ออกเป็นสองประเภทได้
ประเภทหนึ่งคือคนที่ ใช้ AI เป็นเครื่องมือ โดยตระหนักถึงข้อจำกัดของมัน และใช้มอบหมายงานซ้ำๆ หรืองานน่าเบื่อ หรือใช้เพื่อสรุปข้อมูล
อีกประเภทคือคนที่ จ้างความคิดออกไป แทบไม่มีความเข้าใจในหัวข้อนั้นๆ ต้องการแค่ผลลัพธ์ และไม่มีความตั้งใจจะเรียนรู้
กลุ่มหลังคือพวกที่เชื่อว่าแชตบอตสามารถแทนที่นักพัฒนาระดับซีเนียร์ได้
สิ่งสำคัญมีแค่ส่งงานให้เร็ว และกว่าจะได้ฟีดแบ็กจากลูกค้าก็ครึ่งปีให้หลัง เลยไม่มีความหมายอะไร
ตอนนี้ก็แค่ประคองตัว รับเงินเดือนด้วยความพยายามให้น้อยที่สุด
ฉันทำแอปฝึกฟังภาษาเยอรมันด้วย Claude Code และ ElevenLabs ซึ่งได้ผลดีจนแม้แต่ครูก็ยังประหลาดใจ
ฉันไม่ได้สนใจเรียนโค้ด จุดประสงค์คือ พัฒนาทักษะภาษาเยอรมัน
กล่าวคือใช้เป็น คู่สนทนาแบบโต้ตอบ ที่มากกว่าเครื่องมือธรรมดา
ถ้าใช้ AI กับ โปรเจ็กต์ greenfield และ โปรเจ็กต์ brownfield จะเห็นความต่างด้านประสิทธิภาพอย่างมาก
ในวันแรกของโปรเจ็กต์ใหม่ มันทำงานได้เท่ากับหนึ่งสัปดาห์ แต่ในระบบเดิมดีขึ้นแค่ราว 20%
สุดท้ายมันจึงเหมือน AI กำลังเร่งให้ “innovator’s dilemma” เกิดซ้ำเร็วขึ้น
คำถามคือ AI จะมีบทบาทได้มากแค่ไหนในช่วงที่ต้องทำให้ระบบซับซ้อนเติบโตจนสุกงอม
ฉันทำไฟล์ build ของ Hashicorp Packer จนเกือบเสร็จด้วย AI โดย AI แบบรันในเครื่อง ช่วยได้มาก
แต่กับอินฟราที่เก่า ความคาดเดาไม่ได้สูงมากจน LLM อาจยิ่งทำให้พังได้
ช่วงแรกมันเร็ว แต่หลังจากนั้น ข้อจำกัดของสถาปัตยกรรม จะเริ่มโผล่ออกมา
และยังช่วยลดการออกแบบเกินความจำเป็นได้ด้วย
ถ้าโปรเจ็กต์เกิน 200k โทเค็น ผลิตภาพจะกลายเป็นศูนย์
สุดท้ายองค์กรที่ชนะคือองค์กรที่มีกระบวนการซึ่งไม่ต้องพึ่งความทรงจำ
ฉันแทบคลื่นไส้เมื่อได้ยินเรื่องผู้บริหารคนหนึ่งใช้ Claude Code แปลงโมเดลการเงิน Excel ที่ซับซ้อน 30 ชีตเป็น Python
ในฐานะคนที่มีพื้นฐานคณิตศาสตร์กับธรณีฟิสิกส์ ฉันมองว่าโมเดล Excel แบบนั้นเป็นฝันร้ายอยู่แล้ว
ถึงอย่างนั้นก็ยอมรับว่าฉบับแปลงเป็น Python อาจไม่ได้แย่กว่าต้นฉบับมากนัก
ใครจะเป็นคนจับได้ว่าโมเดลผิด? แทบไม่มีใครเลย
ซิมูเลชันที่ LLM สร้างขึ้นยิ่งขาดขั้นตอนการตรวจสอบมากกว่าเดิม
ตอนแรกใช้เพื่อทดลองอย่างรวดเร็ว แต่ถ้าทำเงินได้มาก ทีมเทคนิคก็จะเปลี่ยนเป็นแอปจริงอย่างเป็นทางการ
Excel ต้นฉบับถูกแก้มาหลายปี ขณะที่ฉบับแปลงเป็นเพียง ของปลอมที่ลอกเลียนมา เท่านั้น
การที่มี คนที่ไม่ใช่ผู้เชี่ยวชาญสร้างโมเดลการเงินด้วย AI ฟังดูน่ากลัว
ตอนนี้คือ ยุคกำเนิดของ Shadow AI
เหมือนกับ Shadow IT ในยุค 2000s ที่พนักงานแอบรัน Claude Code ในเทอร์มินัล
เพราะ Copilot อย่างเป็นทางการจัดการ CSV ยังไม่ได้เรื่อง
พวก CISO กำลังหวาดผวา แต่ถ้าห้าม คนเก่งๆ ก็จะลาออก
ถ้าพูดแบบยุค 1980 นวัตกรรมที่แท้จริงมาจาก เวิร์กโฟลว์ที่พนักงานหน้างานสร้างขึ้นเองโดยสมัครใจ
เพราะพวกเขารู้กระบวนการดีที่สุด
แล้วหลังจากนั้นค่อยมีแพ็กเกจซอฟต์แวร์ที่เป็นมิตรกับ CIO ตามมา
ในช่วงไม่กี่เดือนที่ผ่านมา เอเจนต์เริ่มใช้งานได้จริงขึ้น ทุกคนเลยเพิ่งเริ่มใช้กัน
พวก MCP, LangChain, vector DB เคยเป็นกระแสช่วงหนึ่ง แต่ตอนนี้เงียบลงแล้ว
ตอนนี้ยัง เร็วเกินไปที่จะพูดถึงเทรนด์
ฉันลองใช้เซิร์ฟเวอร์ MCP ของ context7 กับ playwright แล้ว พบว่ามันมีประสิทธิภาพมากสำหรับการวางแผนและฟีดแบ็กลูป
การผสาน Excel ของ Microsoft Copilot แย่มาก
เพราะตลอด 30 ปีที่ผ่านมา Microsoft สร้างฟอร์แมต XML ที่ซับซ้อนจน LLM เข้าใจไม่ได้
เลยทำให้บริษัทเรากำลัง ย้ายเอกสาร Word ไปเป็น Markdown อยู่ ซึ่งเหมือนเป็นกรรมตามสนองอย่างหนึ่ง
แต่เวลาที่ต้องใช้เพื่อทำให้เอกสารเป็นมิตรกับ AI ก็เพิ่มขึ้นเรื่อยๆ
Copilot แม้แต่คำสั่งให้แปลงเป็น CSV ก็ยังเมินแล้วล้มเหลว
ฉันเคยได้ยินคำพูดหนึ่งว่า — “ทุกวันนี้ไม่ใช่บริษัทใหญ่ที่ชนะบริษัทเล็ก แต่เป็น บริษัทที่เร็วที่ชนะบริษัทที่ช้า”
ในยุค AI ตอนนี้ ประโยคนี้ยิ่งฟังดูจริงเข้าไปอีก ปัญหาคือ จะรักษาความเร็วไว้ได้อย่างไร
Copilot ก็ยังโดนด่าอยู่เหมือนเดิม MS จะปรับปรุงเมื่อไหร่กันนะ
ผมกำลังเขียนเป็น คนรับใช้1, 2, 3 อยู่ครับ
ตรงกลางมีการวิจารณ์ Copilot ค่อนข้างมาก แต่จริง ๆ แล้ว
Claude Code กำลังแพร่หลายอย่างรวดเร็วภายใน Microsoft
ดูเหมือนว่าน่าจะเป็นสถานการณ์ที่ใช้ได้กับบริษัทยักษ์ใหญ่ในประเทศด้วยเช่นกัน
เพราะบริษัทบอกให้ใช้ก็เลยต้องใช้ แต่ก็น่าจะมีที่ที่ชัดเจนว่าใช้ ChatGPT/Claude ไม่ได้ และใช้ได้แค่ Copilot เท่านั้น