Code Mode เมื่อ AI ไม่ได้แค่คุย แต่เริ่มเขียนและลงมือทําแทนเรา

ถ้าเรายังมอง 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 รุ่นถัดไปของเรา