ถ้าเรายังมอง AI เป็นแค่ chatbot ที่ตอบคำถามเก่งขึ้นเรื่อยๆ เราอาจกำลังพลาดของจริงไปแล้ว คลิป Code Mode- Sunil Pai,Cloudflare บนช่อง AI Engineer เสนอภาพที่น่าสนใจกว่านั้นมาก คือ AI อาจกำลังก้าวจาก “ผู้ช่วยตอบ” ไปเป็น “ตัวกลางที่เขียนโค้ดเพื่อสั่งงานระบบแทนมนุษย์”
ประเด็นนี้สำคัญกับเจ้าของธุรกิจและคนทำงานมากกว่าที่คิด เพราะเมื่อ AI เริ่มสั่ง API, วิ่ง workflow, อ่าน state ของระบบ และประกอบหน้าจอให้ตรงโจทย์เฉพาะคนได้เอง สิ่งที่เปลี่ยนไม่ใช่แค่เครื่องมือของ developer แต่คือวิธีที่ธุรกิจจะออกแบบบริการ ประสบการณ์ลูกค้า และงานหลังบ้านในอีก 6-12 เดือน
บทความนี้สรุปและวิเคราะห์แนวคิด “Code Mode” ให้เข้าใจแบบไม่ต้องเป็นโปรแกรมเมอร์ พร้อมชวนคิดว่า ถ้าเอามาใช้กับธุรกิจไทย มันจะหน้าตาแบบไหน และมีข้อควรระวังอะไรบ้าง
Step 1: เข้าใจปัญหาเดิมก่อนว่า ทำไม AI แบบเรียกเครื่องมือทีละอันเริ่มตัน
วิธีทำ AI agent แบบที่นิยมกันช่วงแรกคือ ให้ model เรียกเครื่องมือหรือ tool ผ่านรูปแบบคล้าย JSON จากนั้นระบบค่อยส่งผลกลับมา แล้วให้ model ตัดสินใจต่อว่าจะเรียกอะไรอีก กระบวนการนี้พอใช้กับเครื่องมือไม่กี่ตัวก็ยังพอไหว
แต่พอของจริงในองค์กรเริ่มเข้ามา ทั้ง Google Workspace, Jira, wiki, CRM, ระบบเอกสาร, ระบบบัญชี, ระบบ ticketing และเครื่องมือภายในอีกนับร้อย ปัญหาจะโผล่ทันที
- จำนวน tool มากจนกิน token ใน context มหาศาล
- AI ต้องถามกลับไปกลับมาหลายรอบ กว่าจะจบงานเดียว
- งานที่ควรจบในครั้งเดียว กลับช้าและเปราะ
- การเชื่อมหลายระบบพร้อมกันทำได้ยาก
มุมนี้สำคัญมากสำหรับธุรกิจ เพราะปัญหาของ AI ในองค์กรไม่ได้อยู่ที่ “AI ฉลาดพอไหม” อย่างเดียว แต่อยู่ที่ “AI จะเข้าถึงระบบทั้งหมดได้ยังไงโดยไม่หนัก ช้า และเสี่ยง” ด้วย
ถ้ามองในภาพธุรกิจไทย เราจะเห็นคล้ายกัน เช่น บริษัทหนึ่งอยากให้ AI ช่วยตอบคำถามลูกค้าโดยอิงข้อมูลจาก stock, โปรโมชั่น, ประวัติการซื้อ, สถานะจัดส่ง และนโยบายคืนสินค้า ถ้าต้องยัดทุกระบบเข้าไปเป็น tool แยกกันทั้งหมด สุดท้ายระบบจะทั้งช้าและแพง
Step 2: มอง Code Mode ให้ชัดว่า มันคือการให้ AI “เขียนวิธีทำงาน” แทนการเรียก tool ทีละรอบ
แนวคิดของ Sunil Pai คือเลิกให้ model คุยกับระบบผ่านคำสั่งย่อยไปมา แล้วเปลี่ยนเป็นให้ model สร้างโค้ด ขึ้นมาเลย ส่วนใหญ่เป็น JavaScript แล้วให้โค้ดนั้นไปรันกับ environment ที่เราเตรียมไว้
ข้อดีของวิธีนี้ไม่ได้มีแค่เรื่องความเร็ว แต่เป็นการเปลี่ยนวิธีคิดทั้งก้อน
- โค้ดมีโครงสร้างชัดกว่า มี type, syntax, ตรวจสอบได้
- ทำงานหลายขั้นตอนในครั้งเดียวได้ เช่น loop, sequence, parallel
- เก็บ state ระหว่างงานได้ ไม่ต้องให้ model จำทุกอย่างในข้อความล้วน
- ลดรอบการคุยกลับไปกลับมา ทำให้ latency ต่ำลง
ถ้าแปลเป็นภาษาธุรกิจง่ายๆ เดิมที AI เหมือนพนักงานที่ต้องโทรถามทุกแผนกทีละรอบ แต่ Code Mode คือให้มันเขียนแผนปฏิบัติการขึ้นมา แล้วลงมือประสานงานทั้งหมดภายในครั้งเดียว
จุดนี้น่าสนใจมากเพราะมันขยับ AI จาก “ชั้นสนทนา” ไปสู่ “ชั้นปฏิบัติการ” และนั่นคือพื้นที่ที่มีมูลค่าทางธุรกิจจริง
Step 3: ดูกรณี Cloudflare เพื่อเห็นว่าการลด token ไม่ใช่เรื่องเทคนิคอย่างเดียว
ตัวอย่างที่เล่าในคลิปชัดมาก Cloudflare มี API endpoint ราว 2,600 จุด ถ้าจะเปิดเป็น tool ให้ model ใช้ทุกตัวแบบตรงๆ จะกิน token ระดับ 1.2 ถึง 1.5 ล้านตั้งแต่คำขอแรก ซึ่งแทบใช้งานจริงไม่ได้
ทีมเลยลดทั้งหมดเหลือเพียง 2 คำสั่งหลักคือ search และ execute
- search ให้โค้ดค้นหาใน OpenAPI spec ทั้งหมดว่าควรใช้ endpoint ไหน
- execute ให้โค้ดเรียกฟังก์ชันที่เกี่ยวข้องกับ endpoint เหล่านั้นต่อ
ผลคือจาก token จำนวนมหาศาล ลดเหลือประมาณหลักพัน นี่ไม่ใช่แค่การ optimize แต่คือการเปลี่ยน interface ระหว่าง AI กับระบบใหม่ทั้งชุด
สิ่งที่เจ้าของธุรกิจควรเก็บไปคิดคือ เวลาเราออกแบบ AI ให้ทำงานกับระบบในองค์กร เราไม่จำเป็นต้องเปิดทุกอย่างให้ AI เห็นตรงๆ เราสามารถออกแบบ “ประตูเข้า” ให้เล็กลง แต่ฉลาดขึ้นได้
ตัวอย่างในธุรกิจไทย เช่น แทนที่จะเปิดเมนู ERP ทุกหน้าทุกฟังก์ชันให้ AI เราอาจออกแบบเป็น 2-3 ความสามารถหลัก เช่น
- ค้นหาข้อมูลที่เกี่ยวข้อง
- รันคำสั่งตามสิทธิ์ที่กำหนด
- ขอสรุปสถานะหรือข้อผิดพลาดกลับมา
แนวคิดนี้ช่วยทั้งเรื่องต้นทุน ความเร็ว และการควบคุมความเสี่ยง
Step 4: เข้าใจว่าทำไม Code Mode ถึงมีผลกับงานจริงมากกว่าที่คิด
ในคลิปมีตัวอย่างที่จับต้องได้มาก คือกรณีลูกค้าบอกว่าเว็บกำลังโดน DDoS และอยากให้ระบบหา IP ที่โจมตีอยู่แล้ว block ให้ทันที
ถ้าใช้วิธีเรียก tool แบบปกติ AI ต้องไล่หาว่ามี API ไหนบ้างที่เกี่ยวข้อง จากนั้นเรียกหลาย endpoint ทีละรอบ ตรวจผล แล้วไปขั้นต่อไป งานหนึ่งอาจต้องใช้หลายรอบมาก ทั้งที่สถานการณ์จริงต้องการความเร็ว
แต่พอ model เขียนโค้ดขึ้นมารอบเดียว มันสามารถค้นหา endpoint ที่ต้องใช้ เรียกข้อมูลที่เกี่ยวข้อง และสั่ง block ต่อเนื่องได้ทันทีภายในการรันครั้งเดียว
ประเด็นนี้โยงกับธุรกิจโดยตรง เพราะงานหลายอย่างในองค์กรไม่ใช่งานถามตอบ แต่เป็นงาน “ทำเรื่องให้จบ” เช่น
- ดึงรายการออเดอร์ที่จ่ายเงินแล้วแต่ยังไม่ส่ง
- แยกลูกค้าที่ควร follow-up ตามเงื่อนไขเฉพาะ
- รวบรวมข้อมูลจากหลายระบบเพื่อทำรายงานฉุกเฉิน
- จัดการเหตุการณ์ผิดปกติแบบ real-time
AI ที่ตอบเก่งแต่ทำงานไม่จบ มีมูลค่าน้อยกว่า AI ที่อาจไม่ได้พูดสวยนัก แต่สั่งงานระบบได้ครบ
Step 5: มองให้ไกลกว่า agent เพราะสิ่งใหม่อาจไม่ใช่ “แอป” แบบเดิมอีกแล้ว
ช่วงที่น่าสนใจที่สุดของคลิปคือ Sunil ไม่ได้หยุดแค่เรื่อง API แต่เสนอว่าบางทีเรากำลังเห็นรูปแบบใหม่ของ software ที่ AI ไม่ได้สร้างโปรแกรมแยกขึ้นมาก่อน แล้วให้คนไปกดใช้ทีหลัง
เขายกตัวอย่างจากระบบวาดภาพบน canvas แบบคล้าย whiteboard ผู้ใช้วาดตาราง tic-tac-toe กับเครื่องหมาย X ลงไป แล้วสั่งให้ model “เล่น tic-tac-toe ด้วย”
สิ่งที่ model ทำไม่ใช่สร้างแอปเกมใหม่ แต่ไปดู state ของระบบ ซึ่งในที่นี้คือชุดข้อมูลเส้นที่ถูกวาดอยู่บน canvas จากนั้นมันตีความว่ารูปนี้คือกระดาน tic-tac-toe และวาดวงกลมลงตำแหน่งถัดไปได้เลย
สรุปคือ ไม่มีโค้ดเกม tic-tac-toe อยู่ในระบบแต่แรก แต่ AI สามารถ “เข้าไปอาศัยอยู่ใน state machine” ของระบบนั้น แล้วใช้ความสามารถที่มีอยู่ตอบสนองต่อสถานการณ์ได้
นี่คือจุดที่คนทำธุรกิจควรหันมาสนใจ เพราะมันแปลว่าในอีก 6-12 เดือน เราอาจไม่ต้องสร้างฟีเจอร์ย่อยทุกอย่างไว้ล่วงหน้าเหมือนเดิมเสมอไป ถ้าระบบมี state ที่อ่านได้ และมี action ที่เปิดให้ทำได้ AI อาจสร้างพฤติกรรมใหม่ขึ้นจากของเดิมที่มีอยู่แล้ว
Step 6: วางสถาปัตยกรรมให้ปลอดภัย เพราะ AI ที่ลงมือทำเองต้องไม่ถูกปล่อยอิสระ
ตรงนี้คือส่วนที่ไม่ควรมองข้ามเลย Sunil ย้ำว่าถ้าจะให้ model เขียนโค้ดแล้วรันได้จริง เราต้องมี harness หรือสภาพแวดล้อมที่ปลอดภัยสำหรับการรันโค้ดนั้น
หลักคิดสำคัญคือ ไม่ใช่เริ่มจากระบบที่ทำได้ทุกอย่างแล้วค่อยหาวิธีห้าม แต่ต้องเริ่มจาก ระบบที่ไม่มีความสามารถอะไรเลย แล้วค่อยอนุญาตทีละอย่างตามสิทธิ์ที่ต้องใช้
นี่คือแนวคิดแบบ capability-based security ซึ่งเหมาะกับยุค agent มาก เพราะ AI ไม่ควรเข้าถึง network, file, database หรือ API ภายนอกได้เองทั้งหมดตั้งแต่ต้น
คุณสมบัติของ sandbox ที่ดีตามแนวคิดในคลิปมีประมาณนี้
- เริ่มจากไม่มีสิทธิ์ใดๆ
- เปิดความสามารถเฉพาะงานที่จำเป็น
- ควบคุมการเชื่อมต่อออกภายนอกได้
- รันได้เร็วมาก
- มี observability หรือการติดตามย้อนหลังที่ละเอียด
มุมนี้สำคัญมากสำหรับองค์กรไทย โดยเฉพาะงานที่เกี่ยวกับการเงิน ข้อมูลลูกค้า เอกสารภายใน หรือการอนุมัติใดๆ ถ้าเราคิดจะใช้ AI แบบลงมือทำแทนคน เราต้องตอบคำถามให้ได้ว่า
- AI ทำอะไรได้บ้าง
- AI ทำอะไรไม่ได้แน่ๆ
- ใครตรวจสอบย้อนหลังได้
- เกิดความเสียหายแล้วตามรอยได้หรือไม่
ถ้าตอบ 4 ข้อนี้ไม่ได้ อย่าเพิ่งปล่อย AI ไปแตะระบบจริง
Step 7: เห็นภาพธุรกิจใหม่จาก generative UI และ workflow ระยะยาว
อีกมุมที่ Sunil แตะไว้และน่าคิดต่อคือ เมื่อ AI เขียนโค้ดได้ รันงานได้ และถือ state ระยะยาวได้ ระบบก็ไม่จำเป็นต้องจบที่หน้าจอแบบเดียวสำหรับทุกคนอีกต่อไป
เขาเสนอภาพของ generative UI คือหน้าจอที่ถูกสร้างขึ้นเฉพาะตามโจทย์ของผู้ใช้แต่ละคน รวมถึง workflow ที่อาจรันต่อเนื่องได้เป็นวัน เดือน หรือปี
ยกตัวอย่าง e-commerce
- คนหนึ่งอยากคืนรองเท้าและหาคู่ใหม่ที่คล้ายกันในงบไม่เกิน 100 ดอลลาร์
- อีกคนกังวลเรื่องออเดอร์ล่าช้า
แม้สองคนนี้อยู่ในร้านเดียวกัน แต่สิ่งที่ควรเห็นบนหน้าจออาจต่างกันมาก ระบบแบบเดิมมักบังคับให้ทั้งคู่เดินใน flow เดียวกัน ส่วน AI แบบ Code Mode สามารถประกอบหน้าจอ คำแนะนำ และ action ที่เหมาะกับปัญหาตรงหน้าได้มากกว่า
ถ้าโยงกับธุรกิจไทย ภาพที่น่าสนใจคือ
- หน้า service สำหรับลูกค้าที่ซื้อสินค้าราคาสูง อาจเน้นติดตามงาน นัดหมาย ช่าง และเอกสารรับประกัน
- หน้า service สำหรับลูกค้าที่ถามเรื่องจัดส่ง อาจโฟกัสสถานะพัสดุ ขอคืนเงิน หรือเปลี่ยนที่อยู่
- ระบบหลังบ้านของทีมขาย อาจสร้าง dashboard เฉพาะเคสลูกค้ารายนั้นในขณะคุยสด
อย่างไรก็ดี จุดนี้เราขอเห็นต่างเล็กน้อยจากความตื่นเต้นในคลิป แม้ generative UI จะน่าสนใจมาก แต่ในโลกธุรกิจจริง การปล่อยให้ UI เปลี่ยนตลอดโดยไม่มีกรอบ อาจกระทบความคุ้นเคยของผู้ใช้ ความสม่ำเสมอของแบรนด์ และการวัดผล ดังนั้นทางที่น่าจะใช้งานได้จริงกว่าในระยะสั้นคือ “ให้ AI ประกอบเฉพาะบางส่วน” ไม่ใช่ทั้งระบบในคราวเดียว
Step 8: ปรับวิธีคิดเรื่องผลิตภัณฑ์ใหม่ เพราะลูกค้าของระบบอาจไม่ใช่แค่มนุษย์
ช่วงท้ายของคลิปมีประโยคที่คมมาก คือระบบในอีก 6-12 เดือนจะไม่ได้มีแค่คนใช้ แต่จะมี “หุ่นยนต์ตัวเล็กๆ” หรือ agent ที่เข้ามาโต้ตอบกับระบบของเราด้วย
ความหมายเชิงธุรกิจคือ เราไม่ควรคิดแค่ UX สำหรับคน แต่ต้องคิดถึง DX สำหรับ agent ด้วย เช่น
- เอกสารอ่านง่ายและค้นหาได้
- error message บอกชัดว่าต้องทำอะไรต่อ
- ระบบมี type และ schema ที่แน่นอน
- มีจุดให้ค้นพบความสามารถของระบบได้ง่าย
ฟังดูเหมือนเรื่องเทคนิค แต่จริงๆ กระทบรายได้โดยตรง เพราะถ้า AI ใช้ระบบของเราได้ง่ายกว่า ระบบนั้นก็ถูกนำไปเชื่อมมากกว่า ถูกใช้งานบ่อยกว่า และทำงานแทนคนได้มากกว่า
พูดอีกแบบคือ ในโลกที่ AI เริ่มเป็นผู้ใช้งานระบบด้วย บริษัทที่ “คุยกับ agent รู้เรื่อง” จะได้เปรียบ
Actionable Insights
- เริ่มจากงานที่ต้องประสานหลายระบบ งานพวกนี้ได้ประโยชน์จาก Code Mode มากกว่างานถามตอบธรรมดา
- อย่าเปิดสิทธิ์ให้ AI กว้างเกินไป เริ่มจากสิทธิ์แคบที่สุด แล้วค่อยขยายตาม use case
- ออกแบบระบบให้ AI ใช้ง่าย เอกสาร, ชื่อ action, error message และ schema ต้องชัด
- แยกงาน “แนะนำ” ออกจากงาน “ลงมือทำ” งานที่ AI ลงมือทำจริงควรมี log และตรวจสอบย้อนหลังได้
- ทดสอบกับเคสธุรกิจจริง ไม่ใช่เดโมสวยๆ เช่น เคสคืนสินค้า เคสออเดอร์ค้าง หรือเคสลูกค้าโวยกลางดึก
Troubleshooting
- ปัญหา: AI ตอบเก่ง แต่พอให้ทำงานจริงกลับช้าและหลงทาง- สาเหตุ: เปิด tool เยอะเกินไป ทำให้ context หนักและต้องเรียกหลายรอบ
- วิธีแก้: รวมความสามารถเป็น action ระดับสูงขึ้น เช่น ค้นหา, ตรวจสอบ, ดำเนินการ แทนการเปิด endpoint ย่อยทั้งหมด
- ปัญหา: ทีมกลัวว่า AI จะทำพลาดแล้วกระทบข้อมูลจริง- สาเหตุ: ไม่มี sandbox และไม่มีการจำกัดสิทธิ์ตามงาน
- วิธีแก้: เริ่มจาก environment ที่ไม่มีสิทธิ์ใดๆ แล้วค่อยเปิดเฉพาะ API ที่จำเป็น พร้อมบันทึกทุกการกระทำ
- ปัญหา: ทำเดโมได้ แต่เอาเข้าระบบจริงแล้วควบคุมไม่ได้- สาเหตุ: สนใจความสามารถของ model มากกว่าสถาปัตยกรรมรอบข้าง
- วิธีแก้: ออกแบบ harness, logging, approval flow และจุด rollback ก่อนเชื่อมระบบจริง
- ปัญหา: ผู้ใช้สับสนเมื่อ AI สร้างหน้าจอหรือ flow ไม่เหมือนเดิมทุกครั้ง- สาเหตุ: ปล่อย generative UI กว้างเกินไปโดยไม่มีกรอบประสบการณ์ใช้งาน
- วิธีแก้: จำกัดให้ AI สร้างเฉพาะบางส่วนของ UI และคงองค์ประกอบหลักให้สม่ำเสมอ
- ปัญหา: AI ใช้ระบบภายในไม่ค่อยได้ ทั้งที่มี API ครบ- สาเหตุ: เอกสารไม่ชัด ชื่อ action งง และ error message ไม่บอกทางไปต่อ
- วิธีแก้: ปรับ DX ให้ agent อ่านง่าย ค้นหาได้ และเดาทางถูก
การต่อยอด
- สร้าง AI operator สำหรับงานหลังบ้าน เช่น ตรวจออเดอร์ผิดปกติ เปิดเคส และสรุปให้ทีมในรอบเดียว
- ทดลองทำ service console แบบ dynamic ให้หน้าจอช่วยเหลือลูกค้าปรับตามประเภทปัญหาที่เจอ
- ออกแบบ API ภายในใหม่เพื่อรองรับ agent ไม่ใช่แค่รองรับ developer แบบเดิม
สรุป Checklist ทั้งหมด
- เข้าใจก่อนว่าวิธีเรียก tool ทีละอันเริ่มตันเมื่อระบบในองค์กรซับซ้อนขึ้น
- มอง Code Mode เป็นการให้ AI เขียนโค้ดเพื่อทำงานหลายขั้นตอนในครั้งเดียว
- ออกแบบ action ระดับสูง แทนการเปิด API ย่อยทุกตัวให้ model
- เลือก use case ที่เป็นงานจริง เช่น ประสานหลายระบบหรือจัดการเหตุการณ์ฉุกเฉิน
- สร้าง sandbox ที่เริ่มจากไม่มีสิทธิ์ใดๆ แล้วค่อยอนุญาตเฉพาะที่จำเป็น
- วางระบบ log และการตรวจสอบย้อนหลังให้ครบก่อนเชื่อมข้อมูลจริง
- คิดเรื่อง generative UI แบบมีกรอบ ไม่ปล่อยอิสระทั้งระบบทันที
- ปรับเอกสาร ชื่อ action และ error message ให้ agent ใช้ง่าย
- ทดสอบกับสถานการณ์ธุรกิจจริง ไม่ใช่แค่เดโมในห้องประชุม
สรุปแล้ว Code Mode ไม่ได้เป็นแค่เทคนิคใหม่ของสาย developer แต่เป็นสัญญาณว่า AI กำลังขยับจากผู้ช่วยตอบคำถาม ไปเป็นผู้ช่วยที่ “ลงมือทำ” กับระบบของธุรกิจได้จริง ความท้าทายจึงไม่ใช่แค่เลือก model ไหนเก่งที่สุด แต่คือการออกแบบสิทธิ์ การควบคุม และประสบการณ์ใช้งานใหม่ทั้งหมด
สำหรับเจ้าของธุรกิจและคนทำงาน คำถามที่ควรถามต่อไม่ใช่ “เราจะมี chatbot ไหม” แต่คือ “ถ้า AI เขียนวิธีทำงานเองได้ เราควรเปิดให้มันช่วยงานส่วนไหนก่อน โดยที่ยังควบคุมได้” คำตอบของข้อนี้อาจเป็นจุดเริ่มต้นของผลิตภัณฑ์และ workflow รุ่นถัดไปของเรา
