สรุปจากคลิป ดูคลิปต้นฉบับ
Running AI Engineer with AI: บทเรียนใช้ Agents ทำงานแทนคน
สิ่งที่น่าสนใจกว่า AI เขียนโค้ดได้เร็วขึ้น คือมันเริ่มกลายเป็น “เพื่อนร่วมงานดิจิทัล” ที่ช่วยขยับทั้งทีมให้ทำงานได้มากขึ้น กล้าลองอะไรใหม่ขึ้น และลดงานจุกจิกที่เคยกินเวลาทั้งวัน นี่คือแก่นของคลิป Running AI Engineer with AI จากช่อง AI Engineer ที่ swyx เล่าว่าเขาใช้ agents อย่าง Devin และเครื่องมือแนว assistant อื่นๆ มาช่วยรันธุรกิจจัดงานคอนเฟอเรนซ์ได้อย่างไร
ประเด็นที่น่าคิดไม่ได้มีแค่ “AI ทำอะไรได้” แต่คือ “องค์กรควรจัด workflow ใหม่ยังไงเมื่อ AI เข้ามาเป็นแรงงานอีกแบบหนึ่ง” โดยเฉพาะสำหรับเจ้าของธุรกิจและทีมงานที่ไม่ได้เป็น developer เลย นี่คือจุดที่คลิปนี้มีมูลค่ามาก เพราะตัวอย่างหลายอย่างไม่ใช่งานเขียนโปรแกรมล้วน แต่เป็นงานออกแบบ เว็บไซต์ ข้อมูลลูกค้า การประสานงาน และแม้แต่การจัดซื้อ
สารบัญ
- Step 1: เริ่มจากมุมมองใหม่ว่า AI ไม่ได้มีไว้แค่เขียนโค้ด
- Step 2: ใช้ agents ตัด “งานยิบย่อย” ก่อน ไม่ใช่เริ่มจากโปรเจกต์ใหญ่
- Step 3: เปลี่ยนงานออกแบบให้กลายเป็นงานส่งมอบได้เร็วขึ้น
- Step 4: เปิดโอกาสให้ทีม non-technical ใช้ AI ด้วยภาษาธรรมดา
- Step 5: ใช้ AI เพื่อเพิ่ม “ความอยากทำงาน” ไม่ใช่แค่ความเร็ว
- Step 6: ย้ายงานจัดการข้อมูลและอัปเดตซ้ำๆ ให้ agent รับไป
- Step 7: มองหา use case นอกเหนือจากงานหลัก เช่น ETL และการจัดซื้อ
- Step 8: ตั้งคำถามกับ SaaS เดิม แต่ไม่ใช่รื้อทุกอย่างในวันเดียว
- Step 9: เตรียมธุรกิจให้พร้อมสำหรับโลกที่ “ผู้ใช้หลัก” อาจเป็น agent
- Actionable Insights
- Troubleshooting
- การต่อยอด
- สรุป Checklist ทั้งหมด
Step 1: เริ่มจากมุมมองใหม่ว่า AI ไม่ได้มีไว้แค่เขียนโค้ด
swyx เล่าภาพใหญ่ของการใช้ AI ต่อเนื่องมาหลายปี ตั้งแต่เรื่อง productivity, ต้นทุน AI ที่ลดลงเร็ว ไปจนถึงแนวคิด Tiny Teams หรือทีมเล็กที่สร้างรายได้ใหญ่ได้ เขายกตัวอย่างบริษัทของตัวเองที่มีพนักงานประจำเพียง 9 คน แต่ดูแลงานที่มีมูลค่ามากกว่า 9 ล้านดอลลาร์
ใจความสำคัญคือ AI ไม่ได้แค่ทำให้ “คนเก่งขึ้น” แต่มันทำให้ “ทีมเล็กทำงานระดับทีมใหญ่ได้” นี่ต่างจากวิธีคิดเดิมที่มักมอง AI เป็นแค่เครื่องมือเพิ่ม output รายบุคคล
สำหรับธุรกิจไทย มุมนี้สำคัญมาก เพราะข้อจำกัดหลักของหลายบริษัทไม่ใช่ไอเดีย แต่คือคนไม่พอ เวลาไม่พอ และงานประสานไม่จบเสียที ถ้าเรายังมอง AI เป็นแค่ chatbot ตอบคำถาม เราจะใช้มันได้ไม่คุ้ม แต่ถ้ามองมันเป็นแรงงานเสริมที่รับงานซ้ำ งานตาม งานอัปเดตข้อมูล และงานค้นคว้าแทนคนได้ โครงสร้างทีมจะเริ่มเปลี่ยนทันที
Step 2: ใช้ agents ตัด “งานยิบย่อย” ก่อน ไม่ใช่เริ่มจากโปรเจกต์ใหญ่
หนึ่งในบทเรียนที่ชัดที่สุดจากคลิปคือ agents เก่งมากกับสิ่งที่คนทำงานส่วนใหญ่รำคาญ นั่นคือ yak shaving หรือชุดงานย่อยๆ ที่ต้องทำก่อนถึงจะเริ่มงานจริงได้ เช่น ติดตั้ง dependency, แก้ error จุกจิก, เชื่อมเครื่องมือเข้าหากัน, ไล่ขั้นตอนที่ซ้อนกันหลายชั้น
นี่เป็นมุมที่หลายทีมมองข้าม เพราะเวลาอธิบาย ROI ของ AI มักชอบวัดกันที่ “มันทำงานหลักได้กี่เปอร์เซ็นต์” แต่ในโลกจริง เวลาของทีมมักหายไปกับงานก่อนเริ่มงานหลักมากกว่า
ถ้าเอามาแปลเป็นภาษาธุรกิจไทย ตัวอย่างจะชัดมาก เช่น
- ทีมขาย เสียเวลาไล่รวมข้อมูลลูกค้าจากหลายไฟล์ก่อนโทร
- ทีมการตลาด เสียเวลาแปลง brief เป็น task ย่อยให้ครบ
- ทีมผู้บริหาร เสียเวลากับอีเมลตามงาน นัดหมาย และเช็กสถานะหลายระบบ
- ทีมแอดมิน เสียเวลากับการคัดลอกข้อมูลจากระบบหนึ่งไปอีกระบบหนึ่ง
Agents ให้ค่ามากตรงนี้ เพราะมันช่วยลด “แรงต้านก่อนเริ่มงาน” พอเริ่มง่ายขึ้น ทีมก็ลงมือทำมากขึ้นด้วย
Step 3: เปลี่ยนงานออกแบบให้กลายเป็นงานส่งมอบได้เร็วขึ้น
ตัวอย่างแรกที่จับต้องได้มากคือการเอา Figma ไปต่อกับ agent แล้วให้มันช่วยแปลงงานออกแบบไปเป็นเว็บไซต์ที่ใช้งานได้จริง swyx บอกว่าก่อนหน้านี้ flow แบบนี้อาจกินเวลาเป็นสัปดาห์หรือเป็นเดือน แต่เมื่อเชื่อม agent เข้ากับงานออกแบบแล้ว ก็สามารถได้เว็บที่ตรงกับดีไซน์แบบ pixel-perfect ในเวลาอันสั้น
จุดที่น่าสนใจกว่าเทคนิค คือผลกระทบกับทีมออกแบบ เดิมทีดีไซเนอร์ต้องรอคนลงมือพัฒนา พอมี agent เป็นตัวกลาง ความคิดที่เคยค้างใน Figma เริ่มออกมาเป็นของจริงเร็วขึ้น ความพึงพอใจของทีมก็เพิ่มขึ้นด้วย
สำหรับธุรกิจไทย นี่แปลว่าเราอาจไม่ต้องเริ่มจากการ “จ้างทีม dev เต็มชุด” เสมอไป ถ้าสิ่งที่ต้องการคือ landing page, หน้าโปรโมชัน, หน้าอีเวนต์, microsite หรือหน้าอัปเดตข้อมูลที่เปลี่ยนบ่อย AI agents อาจช่วยให้ทีมเล็กทำของที่เคยต้องรอคิวงานเทคนิคได้น้อยลงมาก
แต่ก็ต้องระวังข้อจำกัดด้วย งานที่ sensitive เช่น ระบบจ่ายเงิน ข้อมูลส่วนบุคคล หรือฟังก์ชันซับซ้อน ยังต้องมีคนเช็กอย่างรอบคอบ อย่าเพิ่งตีความว่าทุกอย่างให้ AI สร้างแล้วปล่อยขึ้น production ได้ทันที
Step 4: เปิดโอกาสให้ทีม non-technical ใช้ AI ด้วยภาษาธรรมดา
อีกจุดที่คลิปนี้น่าสนใจคือ swyx ไม่ได้ทำงานกับทีมเทคนิคอย่างเดียว เขาเล่าว่าดีไซเนอร์ของทีมที่อยู่คนละประเทศสามารถเข้ามาใช้ agent ต่อจากเขาได้เอง โดยใช้วิธีสื่อสารง่ายๆ แบบที่คุยกับคนจริง เช่น เขียน annotation, ขีดเส้นแดง, บอกจุดที่ต้องแก้
นี่คือบทเรียนสำคัญสำหรับเจ้าของธุรกิจไทยที่อยากเอา AI ไปใช้จริง หากการใช้ AI ต้องผ่านคนเทคนิคทุกครั้ง องค์กรจะตันเร็วมาก แต่ถ้าเราออกแบบ workflow ให้คนในทีมที่ไม่เขียนโค้ดก็สั่งงานได้ AI จะเริ่มกลายเป็นเครื่องมือกลางของทั้งบริษัท ไม่ใช่ของฝ่ายใดฝ่ายหนึ่ง
ข้อสรุปที่ชัดคือ prompt ที่ดีไม่จำเป็นต้องเป็นศัพท์เทคนิคเสมอไป บางครั้งแค่สื่อสารให้ชัดเหมือนบรีฟเพื่อนร่วมงานก็พอแล้ว
Step 5: ใช้ AI เพื่อเพิ่ม “ความอยากทำงาน” ไม่ใช่แค่ความเร็ว
ส่วนที่มีพลังมากที่สุดของคลิปนี้คือช่วงที่ swyx บอกว่าเขาไม่ได้พูดถึงจำนวนบรรทัดโค้ดอีกต่อไป แต่กำลังพูดถึง productivity ของมนุษย์ เขาเห็นว่าทีมเริ่มทำงานที่ไม่เคยทำมาก่อน เช่น ใส่ animation, เก็บรายละเอียด, เพิ่มลูกเล่นบนเว็บไซต์ หรือแม้แต่อีสเตอร์เอ้กเล็กๆ เพียงเพราะตอนนี้การลองทำอะไรใหม่ใช้แรงน้อยลง
ประโยคนี้มีนัยสำคัญมากสำหรับคนบริหารทีม ปัญหาของหลายองค์กรไม่ได้อยู่ที่คนไม่ขยัน แต่เกิดจาก feedback loop ช้า ไอเดียหนึ่งต้องรออีกคน ติดคิวอีกฝ่าย รอเทสต์ รออนุมัติ รอแก้ พอทุกอย่างช้า คนก็เลิกอยากลอง
เมื่อ agent ช่วยให้ไอเดียถูกทดลองได้เร็ว ความสนุกในการทำงานกลับมา งานหลายชิ้นที่เคยถูกมองว่า “ไม่จำเป็น” กลับกลายเป็นสิ่งที่ช่วยปรับแบรนด์และประสบการณ์ลูกค้า
ตรงนี้ผู้เขียนเห็นด้วยมาก แต่ก็มีด้านที่ต้องระวัง หากปล่อยให้ทุกคนทดลองทุกอย่างโดยไม่มีหลักเกณฑ์ ทีมอาจเสียเวลาไปกับของเล่นมากกว่างานที่กระทบธุรกิจจริง ทางออกคือแยกให้ชัดว่าอะไรคือพื้นที่ทดลอง และอะไรคืองานหลักที่ต้องส่งมอบตามเป้า
Step 6: ย้ายงานจัดการข้อมูลและอัปเดตซ้ำๆ ให้ agent รับไป
ธุรกิจจัดงานคอนเฟอเรนซ์คือปัญหาการจัดการข้อมูลขนาดใหญ่ ต้องตาม speaker หลายร้อยคน สปอนเซอร์หลายราย และผู้เข้าร่วมงานจำนวนมาก swyx มองว่าสิ่งนี้เป็นโจทย์ด้าน CMS และ data operations มากกว่าสิ่งอื่นใด
สิ่งที่เขาทำคือไม่ยึดติดกับ SaaS เดิมหรือระบบจัดการเนื้อหาแบบสำเร็จรูปเสมอไป แต่ใช้โค้ดเป็น source of truth แล้วให้ agent ช่วยดูแลการอัปเดต เช่น ตารางงาน การเปลี่ยน speaker หรือข้อมูลหน้าเว็บ เมื่อมีอีเมลเข้ามาเรื่องแก้ไข ก็สามารถ forward ให้ agent จัดการต่อได้
ถ้าแปลให้เข้ากับธุรกิจไทย แนวทางนี้ใช้ได้กับหลายกรณี เช่น
- อัปเดตราคาและโปรโมชันบนหลายช่องทาง
- รวมข้อมูลลูกค้าจากฟอร์ม เว็บ และ LINE OA
- ทำรายงานประจำสัปดาห์จากหลายแหล่งข้อมูล
- ปรับข้อมูลหน้าสินค้าหรือหน้าบริการตามคำขอจากทีมขาย
บทเรียนสำคัญไม่ใช่ว่าต้อง “เขียนระบบเอง” แต่คือเราควรถามก่อนว่า งานไหนเป็นการอัปเดตข้อมูลซ้ำๆ ที่ไม่ควรให้คนมานั่งคัดลอกเองอีกแล้ว
Step 7: มองหา use case นอกเหนือจากงานหลัก เช่น ETL และการจัดซื้อ
คลิปยกตัวอย่างที่น่าสนุกแต่สะท้อนการใช้งานจริงมาก คือ swyx ใช้ agent ช่วยค้นหาว่าจะซื้อล็อบสเตอร์ในลอนดอนได้จากที่ไหน มีเบอร์ติดต่อ อีเมล และเว็บไซต์อะไรบ้าง ก่อนที่เขาจะเลือกดำเนินการต่อเอง
ฟังดูเหมือนเรื่องเล็ก แต่จริงๆ นี่คือภาพของ AI สำหรับงานความรู้ทุกชนิด ไม่ใช่แค่สร้างคอนเทนต์หรือเขียนโค้ด งานค้นหา เปรียบเทียบ ตรวจสอบ และรวบรวมข้อมูล คือเวลาจำนวนมากของคนทำงานระดับผู้จัดการและเจ้าของกิจการ
อีก use case คือ ETL หรือการย้ายและซิงก์ข้อมูลจาก vendor ภายนอกเข้ามาเป็นแหล่งข้อมูลกลาง งานแบบนี้น่าเบื่อและมักโดนดอง แต่เป็นฐานสำคัญของธุรกิจ ถ้าข้อมูลไม่ตรงกัน ทุกทีมก็ทำงานต่อยาก
สำหรับธุรกิจไทย งานแนวนี้มีเยอะมาก เช่น
- ดึงยอดขายจาก marketplace หลายเจ้าไปรวม
- ซิงก์ข้อมูลจากระบบบัญชีกับระบบขาย
- เปรียบเทียบราคาซัพพลายเออร์ก่อนสั่งซื้อ
- สรุปข้อมูลคู่แข่งจากหน้าเว็บหรือข่าวสารประจำสัปดาห์
ข้อได้เปรียบของ agent คือมันทำงานแบบ on-demand ได้ ไม่จำเป็นต้องมีผู้ช่วยประจำหรือพนักงาน junior สำหรับงานแบบนี้ทุกเรื่อง
Step 8: ตั้งคำถามกับ SaaS เดิม แต่ไม่ใช่รื้อทุกอย่างในวันเดียว
swyx พูดตรงๆ ว่าเมื่อใช้ AI มากพอ ก็จะเริ่มคิดถึงการแทนที่ SaaS บางตัวด้วย workflow ที่ทำเองได้ แต่เขาก็ยอมรับว่าจุดนี้มีแรงต้านจากทีม และความกังวลเหล่านั้นก็สมเหตุสมผล เพราะเวลาระบบพัง คนที่ต้องรับภาระคือทีมงาน
นี่เป็นจุดที่หลายองค์กรพลาดง่าย โดยเฉพาะเจ้าของธุรกิจที่ตื่นเต้นกับ AI มากเกินไป แล้วสั่งให้รื้อของเดิมโดยยังไม่มีแผนสำรอง คลิปนี้ให้บทเรียนที่ดีตรงที่เขาเสนอวิธีคิดแบบเป็นระบบ คือระบุ 3 ความกังวลหลัก แล้วค่อยๆ ลดความเสี่ยงทีละข้อ
ผู้เขียนเห็นว่ามุมนี้สำคัญมากสำหรับไทย เพราะหลายองค์กรใช้ SaaS แบบปะติดปะต่อกันอยู่แล้ว ถ้าจะลดจำนวนเครื่องมือ ควรเริ่มจากเกณฑ์เหล่านี้ก่อน
- เครื่องมือนั้นแพงเมื่อเทียบกับงานที่ใช้จริงหรือไม่
- ข้อมูลในระบบนั้นดึงออกยากหรือไม่
- มีงานอะไรที่ทีมทำซ้ำผ่านระบบนั้นทุกวันหรือไม่
- ถ้าระบบนั้นหายไป จะมีผลกระทบต่อรายได้หรือ compliance หรือไม่
อย่าเริ่มจากระบบที่ critical ที่สุด เริ่มจากของที่ทีมบ่นมากที่สุดแต่ความเสี่ยงต่ำก่อนจะปลอดภัยกว่า
Step 9: เตรียมธุรกิจให้พร้อมสำหรับโลกที่ “ผู้ใช้หลัก” อาจเป็น agent
ช่วงท้ายของคลิปมีอีกประเด็นที่กว้างขึ้น นั่นคือสัดส่วนผู้ใช้งานบาง platform เริ่มเป็น bots หรือ agents มากกว่ามนุษย์แล้ว ถ้าแนวโน้มนี้ขยายต่อ ธุรกิจจะต้องคิดใหม่ว่าอะไรสำคัญกว่าเดิม ระหว่าง dashboard สวยๆ กับ API, CLI หรือช่องทางให้ agent เข้ามาใช้งานแทนคนได้
นี่ไม่ใช่เรื่องไกลตัวอย่างที่คิด ถ้าระบบของเราถูกใช้ผ่าน automation มากขึ้น หน้าจอสวยอาจไม่ใช่ข้อได้เปรียบหลักอีกต่อไป ความสามารถในการเชื่อมต่อ การรับคำสั่ง การจัดโครงสร้างข้อมูล และการออกแบบประสบการณ์สำหรับ agent จะมีน้ำหนักมากขึ้น
ธุรกิจไทยอาจยังไม่ต้องรีบทำ MCP หรือ infrastructure ซับซ้อน แต่ควรถามตัวเองได้แล้วว่า ข้อมูลในองค์กรอยู่ในรูปที่ AI หยิบไปใช้ต่อได้หรือยัง ถ้ายังเป็นไฟล์กระจัดกระจาย ชื่อคอลัมน์ไม่สม่ำเสมอ และต้องอาศัยคนจำขั้นตอนเองทั้งหมด การเอา AI มาใช้จะติดเพดานเร็วมาก
Actionable Insights
- เริ่มจากงานที่คนในทีมบ่นบ่อยที่สุด เช่น อัปเดตข้อมูลซ้ำๆ คัดลอกข้ามระบบ หรือค้นหาข้อมูลจัดซื้อ
- เปิดให้ทีม non-technical ใช้ AI ได้เอง ออกแบบ prompt เป็นภาษาคน ไม่ต้องรอฝ่ายเทคนิคทุกครั้ง
- วัดผลจากเวลาที่ทีมประหยัดได้ ไม่ใช่วัดแค่จำนวนงานที่ AI ทำแทนคน
- เลือก use case ที่ทดลองได้ภายใน 1-2 สัปดาห์ เช่น หน้าเว็บแคมเปญ รายงานประจำสัปดาห์ หรือการสรุปอีเมล
- เก็บ source of truth ให้ชัด ต่อให้ใช้ AI เก่งแค่ไหน ถ้าข้อมูลต้นทางมั่ว ผลลัพธ์ก็มั่วตาม
Troubleshooting
- ปัญหา: ทีมไม่กล้าใช้ AI เอง
- สาเหตุ: กลัวสั่งไม่ถูก หรือคิดว่าเป็นเรื่องของ developer
- วิธีแก้: เริ่มจากงานง่าย 1 งาน สร้างตัวอย่าง prompt ที่ใช้ได้จริง 3-5 แบบ แล้วให้ทีมลองจากงานของตัวเองทันที
- ปัญหา: AI ทำงานได้บ้างไม่ได้บ้าง ผลลัพธ์ไม่คงที่
- สาเหตุ: ข้อมูลต้นทางกระจัดกระจาย และคำสั่งไม่ชัด
- วิธีแก้: จัดข้อมูลให้เป็นระเบียบก่อน กำหนด source of truth เพียงจุดเดียว และเขียนคำสั่งเป็นขั้นตอนสั้นๆ
- ปัญหา: เจ้าของธุรกิจอยากแทน SaaS หลายตัวเร็วเกินไป
- สาเหตุ: มองเห็นโอกาสลดต้นทุน แต่ประเมินความเสี่ยงต่ำไป
- วิธีแก้: คัดเฉพาะระบบที่ไม่ critical มาทดลองก่อน ตั้งเกณฑ์ชัดว่าถ้าพังจะย้อนกลับยังไง
- ปัญหา: ทีมใช้ AI ทำของเล่นเยอะ แต่งานหลักไม่เดิน
- สาเหตุ: ไม่มีขอบเขตระหว่างโหมดทดลองกับโหมดส่งมอบงาน
- วิธีแก้: แบ่งเวลาหรือแบ่ง backlog ให้ชัด งานทดลองต้องไม่แย่งทรัพยากรจากงานรายได้หลัก
- ปัญหา: ผู้บริหารคิดว่า AI จะลดคนได้ทันที
- สาเหตุ: โฟกัสเรื่องต้นทุนระยะสั้นมากกว่าการออกแบบ workflow ใหม่
- วิธีแก้: ใช้ AI เพื่อปลดล็อกคอขวดก่อน วัดผลจากความเร็วในการตัดสินใจและปริมาณงานที่ทีมทำได้เพิ่มขึ้น
การต่อยอด
- สร้าง AI assistant ภายในทีม สำหรับงานแอดมิน งานขาย หรืองานติดตามโปรเจกต์ โดยใช้เอกสารและ workflow ของบริษัทเอง
- ทำ AI layer ครอบเครื่องมือเดิม แทนที่จะรีบรื้อระบบทั้งหมด ให้ agent เป็นตัวกลางคอยดึงข้อมูลและอัปเดตข้ามระบบก่อน
- เตรียมข้อมูลให้พร้อมสำหรับ agent experience จัดมาตรฐานชื่อไฟล์ ฟิลด์ข้อมูล และขั้นตอนทำงาน เพื่อให้ต่อยอดสู่ automation ได้ง่ายขึ้น
สรุป Checklist ทั้งหมด
- ☐ ปรับวิธีคิดจาก “AI ไว้ช่วยเขียนโค้ด” เป็น “AI คือแรงงานดิจิทัลของทีม”
- ☐ เลือกงานยิบย่อยที่กินเวลาเยอะมาทดลองก่อน
- ☐ ลองใช้ agent กับงานออกแบบ หน้าเว็บ หรือคอนเทนต์ที่ต้องส่งมอบไว
- ☐ ทำให้คน non-technical ใช้ AI ได้เองด้วยภาษาธรรมดา
- ☐ วัดผลจากความเร็วและแรงจูงใจของทีม ไม่ใช่แค่ output ของ AI
- ☐ ใช้ AI กับงานข้อมูล งานอัปเดตซ้ำ และงานประสานงาน
- ☐ ทดลอง use case ด้านจัดซื้อ ค้นหา เปรียบเทียบ และ ETL
- ☐ ถ้าจะลด SaaS ให้เริ่มจากระบบที่ความเสี่ยงต่ำก่อน
- ☐ จัด source of truth ให้ชัดก่อนขยายการใช้งาน AI
- ☐ มองล่วงหน้าว่าระบบของเราพร้อมสำหรับโลกที่ agent เป็นผู้ใช้หรือยัง
สรุปแล้ว คลิป Running AI Engineer with AI ไม่ได้บอกแค่ว่า agents เก่งขึ้นแค่ไหน แต่มันชี้ให้เห็นว่าองค์กรที่ได้ประโยชน์จริง จะเป็นองค์กรที่ยอมออกแบบงานใหม่ ตั้งแต่การสื่อสาร การเก็บข้อมูล การทดลองไอเดีย ไปจนถึงการลดงานที่คนไม่ควรเสียเวลากับมันอีกต่อไป
สำหรับเจ้าของธุรกิจและคนทำงานในไทย คำถามที่สำคัญอาจไม่ใช่ “AI แทนคนได้หรือยัง” แต่เป็น “มีงานอะไรในทีมที่ควรเลิกทำด้วยมือได้แล้ว” ถ้าตอบคำถามนี้ได้ชัด การใช้ AI จะไม่ใช่เรื่องแฟชั่น แต่มันจะกลายเป็นโครงสร้างการทำงานแบบใหม่ที่คุ้มค่าจริง