Name: Agentic Engineering ระดับทีม: ความปลอดภัย ต้นทุน และการวัดผล · หลักสูตร AI Coding อย่างมืออาชีพ
Author: จักริน นพรุจนธาดา

3.1

โมดูล 3.1

ออกแบบ Agentic Engineering Workflow ทั้งทีม

จากคนคุมวง AI หลายตัว สู่ระบบที่มีคนกำกับดูแล

👋 สำหรับผู้เริ่มต้น — อ่านตรงนี้ก่อน

💡

เปรียบง่าย ๆ: เหมือนหัวหน้าครัวในร้านอาหารที่ไม่ได้ลงมือทำอาหารทุกจานเอง แต่คอยสั่งงานและตรวจจานก่อนเสิร์ฟ ส่วน AI ก็เหมือนลูกครัวหลายคนที่ช่วยกันทำ

🎯

ทำไมต้องรู้: จะทำให้ทั้งทีมเร็วขึ้นแบบเป็นระบบ ไม่ใช่ต่างคนต่างใช้ AI ของตัวเองมั่ว ๆ แถมยังรู้ด้วยว่างานไหนปล่อยให้ AI ทำเองได้ งานไหนต้องมีคนคอยคุมใกล้ ๆ

🎯 สิ่งที่คุณจะทำได้หลังเรียนโมดูลนี้

ออกแบบวิธีทำงานที่คนคอยกำกับดูแล ไม่ใช่นั่งเขียนโค้ดเองทุกบรรทัด
เลือกระดับการปล่อยให้ AI ทำเองให้พอดีกับความเสี่ยงและความชัดของงาน
วางมาตรฐานทั้งเอกสารสเปก กติกา และการรีวิว ให้ทั้งทีมใช้เหมือนกัน

เนื้อหา

พอมาถึงระดับสูง เราต้องเลิกมองแค่ว่า "ตัวเองใช้เครื่องมืออะไร" แล้วหันมาออกแบบระบบให้ทั้งทีมใช้ร่วมกันแทน แนวคิด agentic engineering ของ Karpathy พูดง่าย ๆ คือ คนเปลี่ยนบทบาทมาเป็นคนคุมวง AI (agent) หลายตัว แล้วคอยดูแลตรวจงานให้ ไม่ได้ลงมือพิมพ์โค้ดเองทุกบรรทัด โมดูลนี้จะพาออกแบบวิธีทำงานของทีมโดยยึด "ห้าระดับของการปล่อยให้ AI ทำเอง" (จาก Swarmia) แล้วเลือกระดับตามความเสี่ยงของงาน งานไหนโจทย์ชัดและมีด่านตรวจโค้ดอัตโนมัติ (CI) ที่แข็งแรงอยู่แล้ว ก็ปล่อยให้ AI ทำเองมากขึ้นได้ ส่วนงานที่กำกวมหรือกระทบระบบที่ใช้งานจริง (production) ต้องคุมให้แน่นหน่อย จากนั้นวางมาตรฐานกลางที่ทุกคนใช้เหมือนกัน ได้แก่ ไฟล์ AGENTS.md ประจำโปรเจกต์ (repo) ที่เราเขียนเองด้วยมือ, เอกสารสเปกของตัวสินค้าที่คอยอัปเดตให้ทันสมัยเสมอ และขั้นตอนการรีวิวงานที่เป็นแบบแผนเดียวกัน ที่ต้องย้ำคือ "ปล่อยให้ AI ทำเองมากขึ้น ไม่ได้แปลว่าดีขึ้นเสมอไป" มันคือการได้อย่างเสียอย่างที่ต้องชั่งน้ำหนักให้เข้ากับทีมและโค้ดของเราเอง

📖 คำศัพท์ในโมดูลนี้ (อธิบายง่าย ๆ)

Agentic Engineeringการให้ AI ทำงานเป็นตัวช่วยที่ลงมือทำเองได้หลายขั้น โดยมีคนคอยสั่งและตรวจ ไม่ใช่แค่ถาม-ตอบทีละครั้ง

Orchestrateการเป็นเหมือนวาทยกร คอยสั่งและจัดจังหวะให้ AI หลายตัวทำงานเข้าขากัน

Oversightการที่คนคอยดูแลและตรวจงานที่ AI ทำ ก่อนเอาไปใช้จริง

Autonomyระดับความเป็นอิสระของ AI ว่าปล่อยให้มันตัดสินใจและทำเองได้มากแค่ไหนโดยไม่ต้องถามคน

CIระบบตรวจโค้ดอัตโนมัติที่คอยเช็กว่าโค้ดใหม่ไม่พังของเดิม เหมือนด่านตรวจก่อนปล่อยงานผ่าน

🧪 ตัวอย่างจริง + ผลลัพธ์ที่ได้

นโยบายเลือกระดับ autonomy ของทีม

ร่างนโยบาย: งานประเภทใดอนุญาต 'cloud agent เปิด PR เองได้' และงานประเภทใดต้อง 'human ขับทีละ task เท่านั้น'

✅ ผลลัพธ์ที่ได้

ตัวอย่างนโยบายที่ได้ออกมา เช่น การอัปเวอร์ชันของชิ้นส่วนโปรแกรม (dependency bump) ที่มีชุดทดสอบ (test) ครอบไว้ครบ หรือบั๊กที่มีขั้นตอนทำให้เกิดซ้ำ (repro) ชัดเจน แบบนี้อนุญาตให้ AI บนคลาวด์ (cloud agent) เปิดคำขอรวมโค้ด (PR) ได้เอง แต่ก็ยังต้องผ่านการรีวิวและด่านตรวจอัตโนมัติ (CI) อยู่ดี ส่วนงานที่ไปแตะระบบล็อกอิน การจ่ายเงิน หรือการย้ายฐานข้อมูล (DB migration) พวกนี้ต้องให้คนขับเองทีละงานเท่านั้น ห้ามปล่อยให้ AI รันเองเด็ดขาด

💡 จุดสอน

ระดับความอิสระที่ให้ AI (autonomy) ควรผูกกับความเสี่ยงและความชัดของคำว่า "เสร็จ" ไม่ใช่ผูกกับว่าเครื่องมือมันเก่งแค่ไหน พอนโยบายชัด ทีมก็ได้ความเร็วมาโดยไม่ต้องเอาระบบที่ใช้งานจริงไปเสี่ยง

แบบฝึกหัดท้ายโมดูล

ลองร่าง "ห้าระดับความอิสระของ AI" ในเวอร์ชันของทีมคุณเอง พร้อมยกตัวอย่างงานจริงในแต่ละระดับ และกำหนดกรอบกันพลาด (guardrail) ไว้ด้วย
ออกแบบชุดมาตรฐานกลางของทีม (ไฟล์ AGENTS.md ประจำโปรเจกต์, เอกสารสเปกของสินค้า, ขั้นตอนการรีวิว) แล้วอธิบายว่าจะบังคับให้ทุกคนทำตามได้ยังไง

3.2

โมดูล 3.2

Security ของโค้ด AI: ภัยและการตั้งรับ

โค้ด AI เสี่ยงกว่าจริง วางเกราะหลายชั้นให้เป็น

👋 สำหรับผู้เริ่มต้น — อ่านตรงนี้ก่อน

💡

เปรียบง่าย ๆ: เหมือนบ้านที่ต้องมีทั้งรั้ว ประตูล็อก และกล้องวงจรปิดหลายชั้น เพราะโค้ดที่ AI เขียนก็เหมือนช่างที่ทำงานเร็วแต่บางทีลืมล็อกหน้าต่างทิ้งไว้

🎯

ทำไมต้องรู้: โค้ดที่ AI เขียนมักมีช่องให้โจรงัดเข้ามาได้ง่ายกว่าที่เราคิด ถ้าไม่ตรวจให้ดี ข้อมูลลูกค้าหรือทั้งระบบอาจโดนเจาะได้เลย

🎯 สิ่งที่คุณจะทำได้หลังเรียนโมดูลนี้

เห็นข้อมูลจริงว่าโค้ด AI เสี่ยงกว่าโค้ดคน และรู้จักช่องโหว่ยอดฮิต
เข้าใจอาการยิ่งสั่งแก้ยิ่งพัง (security degradation paradox) และการแอบยัดคำสั่ง (prompt injection)
วางเกราะป้องกันหลายชั้น ทั้งสแกนโค้ดตอนยังไม่รัน (SAST) ทดสอบตอนรันจริง (DAST) ตรวจชิ้นส่วนที่หยิบมาใช้ (SCA/package-firewall) และให้คนช่วยหาช่องโจมตี

เนื้อหา

เรื่องความปลอดภัยคือความเสี่ยงหัวข้อใหญ่ที่สุดเลย ลองดูตัวเลขจากปี 2026 (แต่ละงานวิจัยได้เลขต่างกันตามวิธีวัด แต่ทิศทางไปทางเดียวกัน) บางงานพบว่าคำตอบของ AI ปลอดภัยจริง ๆ แค่ประมาณ 10.5% เท่านั้น และราว 45% ตกมาตรฐานช่องโหว่ยอดฮิต (OWASP Top-10) อย่างน้อยหนึ่งข้อ อีกงานหนึ่งเอาโค้ดจาก 6 โมเดล (LLM) มาตรวจ 534 ตัวอย่าง เจอว่า 25.1% มีช่องโหว่ยืนยันได้จริง โดยกลุ่มการหลอกยัดคำสั่งอันตราย (injection) คิดเป็นถึง 33.1% ของปัญหาทั้งหมด ฝั่ง CodeRabbit เจอว่าโค้ดภาษา Java 7 ใน 10 ตัวอย่างมีช่องโหว่ และโดยรวมโค้ด AI เสี่ยงกว่าโค้ดคนประมาณ 1.7 เท่า ส่วนรายงาน Black Duck OSSRA 2026 เจอช่องโหว่เฉลี่ยถึง 581 จุดต่อโปรเจกต์ (เพิ่มขึ้น 107% จากปีก่อน) ช่องโหว่ที่เจอบ่อยและเห็นภาพง่าย ๆ เช่น เอาข้อมูลไปแสดงบนหน้าเว็บโดยไม่กรองก่อน (เปิดช่องให้ฝังสคริปต์อันตราย หรือ XSS), การต่อคำสั่งฐานข้อมูล SQL ด้วยการเอาข้อความมาเชื่อมกันตรง ๆ (เปิดช่อง injection), การเผลอฝังกุญแจลับ API ไว้ในฝั่งที่ผู้ใช้มองเห็น และการลืมเช็กค่าว่าง แถมยังมีอาการแปลก ๆ ที่เรียกว่า security degradation paradox คือยิ่งสั่งให้ AI แก้ซ้ำ ๆ ช่องโหว่กลับยิ่งเพิ่มขึ้น ส่วนการแอบยัดคำสั่ง (prompt injection) ซึ่งคือการแอบสอดคำสั่งอันตรายผ่านข้อความที่ป้อนเข้ามา พบว่าราว 73% ของระบบที่ลองทดสอบมีช่องให้เจาะได้ บางเคสโจมตีสำเร็จถึง 50-84% เลย ทางแก้คือต้องตั้งรับหลายชั้นพร้อมกัน ทั้งสแกนโค้ดตอนยังไม่รัน (SAST), ทดสอบตอนรันจริง (DAST), ตรวจชิ้นส่วนที่หยิบมาใช้ (SCA/package-firewall) และให้คนช่วยรีวิวแบบสวมบทเป็นคนร้ายคอยหาช่องโจมตี

📖 คำศัพท์ในโมดูลนี้ (อธิบายง่าย ๆ)

Securityความปลอดภัยของระบบ การป้องกันไม่ให้คนร้ายเจาะเข้ามาขโมยหรือทำลายข้อมูล

OWASP Top-10รายการช่องโหว่ยอดฮิต 10 อันดับที่โปรแกรมมักโดนโจมตี ใช้เป็นเช็กลิสต์มาตรฐานของวงการ

Injectionการหลอกป้อนคำสั่งอันตรายแฝงเข้าไปในช่องกรอกข้อมูล เหมือนสอดจดหมายปลอมให้ระบบทำตามโดยไม่รู้ตัว

Vulnerabilityจุดอ่อนหรือช่องโหว่ในโค้ดที่เปิดโอกาสให้ถูกโจมตีได้

AppSecงานด้านความปลอดภัยของแอปพลิเคชันโดยเฉพาะ การหาและอุดช่องโหว่ในตัวโปรแกรม

🧪 ตัวอย่างจริง + ผลลัพธ์ที่ได้

prompt ตรวจ security เจาะจงตาม OWASP

รีวิว diff นี้เป็น security audit เทียบ OWASP Top-10 โดยเฉพาะ: (1) injection (SQL/command) (2) XSS จาก innerHTML/dangerouslySetInnerHTML (3) hardcoded secret (4) missing authz check — สำหรับแต่ละข้อ ถ้าพบให้ชี้บรรทัดและเสนอแพตช์ อย่าตอบว่า 'ปลอดภัย' ถ้ายังไม่ได้ตรวจครบทุกข้อ

✅ ผลลัพธ์ที่ได้

AI จะไล่ตรวจทีละหมวด แล้วชี้จุดจริง เช่น คำสั่งฐานข้อมูลที่เอาข้อความมาต่อกันตรง ๆ หรือกุญแจลับที่ฝังปนไปในไฟล์ที่ส่งขึ้นเว็บ ทำให้ได้รายการที่ลงมือแก้ได้จริง แทนที่จะได้แค่คำรับรองลอย ๆ ว่า "ปลอดภัย"

💡 จุดสอน

อย่าถามลอย ๆ ว่า "ปลอดภัยไหม" เพราะโมเดลมักตอบว่าปลอดภัยไว้ก่อน ให้สั่งตรวจเป็นหมวดเฉพาะเจาะจง แล้วบังคับให้ชี้หลักฐานเป็นรายบรรทัด มองว่านี่เป็นแค่การตรวจรอบแรกด้วย AI ซึ่งยังต้องตามด้วยเครื่องมือสแกน (SAST/DAST) และคนตรวจซ้ำอีกที

แบบฝึกหัดท้ายโมดูล

ลองเอาเครื่องมือสแกนโค้ดและตรวจชิ้นส่วน (SAST + SCA) มารันกับโค้ดที่ AI สร้างจริง แล้วจัดหมวดช่องโหว่ที่เจอตามมาตรฐาน OWASP Top-10 พร้อมวางแผนแก้
ลองทดสอบอาการยิ่งแก้ยิ่งพัง (security degradation) โดยสั่งให้ AI "ปรับปรุง" โค้ดชิ้นเดิมซ้ำหลายรอบ แล้วดูว่าช่องโหว่เพิ่มขึ้นไหม แล้วจดผลไว้

3.3

โมดูล 3.3

Slopsquatting และความปลอดภัย Supply Chain

ชิ้นส่วนโปรแกรม (package) ที่ AI แต่งชื่อขึ้นมา คือช่องโจมตีที่โตเร็วที่สุด

👋 สำหรับผู้เริ่มต้น — อ่านตรงนี้ก่อน

💡

เปรียบง่าย ๆ: เหมือน AI แนะนำร้านค้าที่ไม่มีอยู่จริงให้เราไปซื้อของ แล้วมิจฉาชีพแอบไปเปิดร้านชื่อนั้นดักไว้ก่อน พอเราหลงไปซื้อก็โดนหลอกทันที

🎯

ทำไมต้องรู้: ถ้าเผลอลงชิ้นส่วนโปรแกรมปลอมที่ AI แต่งชื่อขึ้นมา คนร้ายอาจแอบฝังโค้ดอันตรายเข้าระบบเราได้ทันที แถมภัยแบบนี้ก็กำลังโตเร็วมากด้วย

🎯 สิ่งที่คุณจะทำได้หลังเรียนโมดูลนี้

เข้าใจ slopsquatting คือการที่ AI อ้างชิ้นส่วนโปรแกรม (package) ที่ไม่มีจริง แล้วโดนคนร้ายเอาไปใช้โจมตี
รู้สถิติจริงและเคสจริงของชื่อชิ้นส่วนที่ AI มั่วขึ้นมาเอง
วางวิธีป้องกัน ทั้งตรวจทุกชิ้นส่วนให้แน่ใจว่ามีจริง ใช้ไฟล์ล็อกเวอร์ชัน (lockfile) และตัวกรองชิ้นส่วน (package firewall)

เนื้อหา

Slopsquatting คือภัยในห่วงโซ่ชิ้นส่วนโปรแกรม (supply chain) ที่กำลังโตเร็วมาก มีงานวิจัยจาก USENIX เอาข้อมูล 576,000 ตัวอย่างจาก 16 โมเดล (LLM) มาวิเคราะห์ เจอว่าราว 19.7% ของชื่อชิ้นส่วนที่ AI อ้างถึงเป็นชื่อที่ไม่มีอยู่จริง โดยโมเดลแบบเปิดมั่วชื่อประมาณ 21.7% ส่วนโมเดลเชิงพาณิชย์อยู่ที่ราว 5.2% ที่น่ากลัวคือ 43% ของชื่อที่มั่วขึ้นมานั้น "ซ้ำเดิม" ทุกครั้งที่ป้อนคำสั่งเหมือนกัน คนไม่หวังดีเลยไปจดชื่อพวกนี้ดักไว้ล่วงหน้า แล้วยัดโปรแกรมอันตราย (malware) ไว้ให้ติดตั้งตั้งแต่ครั้งแรกที่เราลง เคสจริงที่เคยเกิด เช่น ของปลอมบน npm ที่ตั้งชื่อเลียนแบบ unused-imports และชื่อที่ AI มั่วขึ้นมาอย่าง react-codeshift ที่แพร่ไปไกลถึง 237 โปรเจกต์บน GitHub ผ่านไฟล์ทักษะ (skill) ของ AI ที่ AI สร้างเอง กว่าจะจับได้ วิธีป้องกันคือ ตรวจทุกชิ้นส่วน (dependency) ให้แน่ใจว่ามีจริงและเป็นตัวที่เราตั้งใจจะใช้ก่อนลง ใช้ไฟล์ล็อกเวอร์ชัน (lockfile) คู่กับตัวกรองชิ้นส่วน (package firewall) และระวังเป็นพิเศษกับ AI ที่ชอบลงชิ้นส่วนเองอัตโนมัติ

📖 คำศัพท์ในโมดูลนี้ (อธิบายง่าย ๆ)

Slopsquattingการที่คนร้ายไปจดชื่อชิ้นส่วนโปรแกรมปลอมที่ AI ชอบมั่วขึ้นมา เพื่อดักคนที่หลงเชื่อ AI แล้วไปติดตั้ง

Supply Chainห่วงโซ่ชิ้นส่วนต่างๆ ที่โปรแกรมเราหยิบมาใช้ ถ้าชิ้นใดชิ้นหนึ่งมีพิษก็ลามมาถึงเราได้

Packageชิ้นส่วนโค้ดสำเร็จรูปที่คนอื่นทำไว้ให้ดาวน์โหลดมาใช้ต่อ ไม่ต้องเขียนเองใหม่ทั้งหมด

Hallucinateอาการที่ AI มั่วหรือแต่งข้อมูลขึ้นมาเองอย่างมั่นใจ ทั้งที่จริงๆ ไม่มีอยู่

LLMโมเดล AI ภาษาขนาดใหญ่ที่คุยและเขียนโค้ดได้ เช่น ChatGPT หรือ Claude

🧪 ตัวอย่างจริง + ผลลัพธ์ที่ได้

guardrail กัน package ปลอมใน AGENTS.md

# ใน AGENTS.md เพิ่มกฎ: ## Dependencies (ห้ามพลาด) - ห้ามเพิ่ม dependency ใด ๆ โดยไม่ยืนยันก่อนว่ามีอยู่จริงบน npm registry (ตรวจ URL จริง + จำนวน download + วันที่ publish) - ห้ามรัน install อัตโนมัติ ต้องเสนอชื่อ package + เวอร์ชันให้มนุษย์อนุมัติก่อน - ทุกการเพิ่ม dependency ต้องอัปเดต lockfile และผ่าน package firewall

✅ ผลลัพธ์ที่ได้

AI จะเสนอชื่อชิ้นส่วนพร้อมหลักฐานว่ามีจริง แล้วรอให้เราอนุมัติก่อน แทนที่จะลงทันที ช่วยลดโอกาสเผลอติดตั้งชิ้นส่วนที่ AI มั่วขึ้นมาเอง (hallucinate)

💡 จุดสอน

เพราะชื่อที่ AI มั่วขึ้นมามัก "ซ้ำเดิม" คนร้ายเลยไปดักไว้ก่อนได้ การบังคับให้ตรวจสอบก่อนและห้ามลงชิ้นส่วนเองอัตโนมัติ จึงเป็นกรอบกันพลาด (guardrail) ที่คุ้มค่าที่สุดข้อหนึ่งสำหรับ AI ยุคนี้

แบบฝึกหัดท้ายโมดูล

ลองตั้งตัวกรองชิ้นส่วน (package firewall) หรือกติกาที่บล็อกการลงชิ้นส่วนที่ยังไม่ผ่านการตรวจสอบในโปรเจกต์ตัวอย่าง แล้วลองทดสอบด้วยชื่อปลอมดู
ไล่ตรวจชิ้นส่วน (dependency) ทั้งหมดในโปรเจกต์ระดับกลางของคุณว่ามีตัวไหนที่ AI เสนอมาโดยยังไม่ได้ตรวจสอบบ้าง แล้วสรุปมาตรการแก้

3.4

โมดูล 3.4

คุมต้นทุน Multi-Agent และ Token

กันบิลบานปลายจาก AI หลายตัวที่ปล่อยทำงานพร้อมกันทิ้งไว้

👋 สำหรับผู้เริ่มต้น — อ่านตรงนี้ก่อน

💡

เปรียบง่าย ๆ: เหมือนเปิดก๊อกน้ำหลายตัวทิ้งไว้พร้อมกันแล้วลืมปิด พอสิ้นเดือนบิลค่าน้ำก็พุ่งจนตกใจ AI หลายตัวที่ปล่อยทำงานทิ้งไว้ก็กินเงินแบบนั้น

🎯

ทำไมต้องรู้: ถ้าไม่คุมให้ดี ค่าใช้จ่าย AI บานปลายได้ถึงหลักหลายแสนบาทในไม่กี่วัน พอเข้าใจว่ามันกินเงินยังไง เราก็ตั้งเพดานและเหยียบเบรกได้ทันก่อนบิลจะระเบิด

🎯 สิ่งที่คุณจะทำได้หลังเรียนโมดูลนี้

เข้าใจว่าต้นทุนมาจากไหน ทั้ง AI ตัวลูก (subagent) การรันหลายตัวพร้อมกัน และตัวเชื่อมเครื่องมือ (MCP)
ตั้งเพดานค่าใช้จ่าย และวางแผนใช้โทเคน (token) ให้คุ้มที่สุด
ใช้เทคนิคเรียกเครื่องมือผ่านโค้ด (code execution with MCP) และจัดการข้อมูลรอบตัวให้ประหยัดขึ้น

เนื้อหา

ค่าใช้จ่ายเป็นความเสี่ยงระดับทีมที่จับต้องได้จริง มีเคสบิลก้อนเดียว 8,000-15,000 ดอลลาร์ และมีทีมหนึ่งโดนไปถึง 47,000 ดอลลาร์ใน 3 วัน จาก AI ตัวลูก (subagent) 23 ตัวที่ปล่อยทำงานทิ้งไว้ ที่มันแพงเพราะกลไกแบบนี้ พอให้ AI ตัวลูกหลายตัวทำงานพร้อมกัน แต่ละตัวเผาโทเคน (token) เต็มอัตราและมีพื้นที่ข้อมูลของตัวเองแยกกัน, ตัวเชื่อมเครื่องมือแต่ละตัว (MCP server) เพิ่มค่าใช้จ่ายได้ถึงราว 18,000 โทเคนต่อรอบ เพราะมันโหลดรายละเอียดเครื่องมือเข้ามาใหม่ทุกรอบ, แถมการยัดข้อมูลเข้าไปเยอะเกินก็ทั้งแพงและทำให้คุณภาพตกจากอาการข้อมูลเน่า (context rot) เมื่อเกิน 100,000-120,000 โทเคน วิธีลดค่าใช้จ่ายคือ ตั้งเพดานค่าใช้จ่ายไว้เสมอ, ต่อตัวเชื่อมเครื่องมือ (MCP) เท่าที่จำเป็นจริง ๆ และใช้แบบเรียกเครื่องมือผ่านโค้ด (code execution with MCP) ซึ่งจะโหลดเครื่องมือเท่าที่ต้องใช้และกรองข้อมูลก่อนส่งให้โมเดล, เลือกโมเดลให้เหมาะกับงาน (เช่น Claude Haiku 4.5 ถูกที่สุดสำหรับงานชิ้นเดียวที่ทำจบได้ในตัว) และอย่าปล่อยให้ AI หลายตัวทำงานพร้อมกันโดยไม่คอยดูผ่านหน้าจอคุมงาน เช่น Agent view ของ Claude Code

📖 คำศัพท์ในโมดูลนี้ (อธิบายง่าย ๆ)

Multi-Agentการใช้ AI หลายตัวช่วยกันทำงานพร้อมกัน แต่ยิ่งหลายตัวก็ยิ่งกินเงินหลายเท่า

Tokenหน่วยนับคำที่ AI อ่านและเขียน ใช้คิดเงิน ยิ่งคุยยาวก็ยิ่งเปลืองโทเคนและเสียเงินมาก

SubagentAI ตัวลูกที่ถูกสั่งให้แยกไปทำงานย่อยของตัวเอง แต่ละตัวก็เผาเงินของมันเอง

Parallelการทำงานหลายอย่างพร้อมกันในเวลาเดียว เร็วขึ้นก็จริงแต่ค่าใช้จ่ายก็คูณตามจำนวน

Context Windowความจำในรอบสนทนาของ AI ว่ารับข้อมูลได้มากแค่ไหน ยิ่งใส่เยอะยิ่งเปลืองโทเคน

MCP Serverตัวเชื่อมที่เปิดให้ AI ใช้เครื่องมือเสริมได้ แต่แต่ละตัวก็แอบกินโทเคนเพิ่มทุกครั้งที่ทำงาน

🧪 ตัวอย่างจริง + ผลลัพธ์ที่ได้

ประเมินต้นทุนก่อนเปิด parallel subagents

คำนวณคร่าว: จะเปิด 5 subagent พร้อมกัน แต่ละตัวมี context ~80k tokens ต่อ MCP 2 server (แต่ละ server ~18k tokens/turn) รันคนละ ~10 turn — ประมาณการ token และตั้ง spend limit เท่าไรจึงปลอดภัย

✅ ผลลัพธ์ที่ได้

จะเห็นชัดเลยว่าพอมีพื้นที่ข้อมูลแยกกัน 5 ชุด บวกกับตัวเชื่อมเครื่องมือที่กินเพิ่มราว 36,000 โทเคนต่อรอบต่อตัว คูณด้วยหลายรอบ โทเคนก็พุ่งเร็วมาก เลยควรตั้งเพดานค่าใช้จ่ายไว้ต่ำ ๆ แล้วลดจำนวน AI ตัวลูกหรือตัวเชื่อมเครื่องมือลง หรือสลับมาทำทีละตัวเรียงกันแทน

💡 จุดสอน

การใช้ AI หลายตัวไม่ได้ฟรี ต้นทุนเพิ่มขึ้นตามจำนวน AI และตัวเชื่อมเครื่องมือที่เปิดไว้ การประเมินคร่าว ๆ ก่อนเปิดแล้วตั้งเพดานค่าใช้จ่ายไว้ คือวินัยที่กัน "บิลสยอง" ได้จริง เริ่มจากน้อย ๆ ก่อน แล้วค่อยเพิ่มเมื่อพิสูจน์แล้วว่ามันคุ้ม

แบบฝึกหัดท้ายโมดูล

ลองตั้งเพดานค่าใช้จ่ายและคอยดูการใช้โทเคนของงานจริงหนึ่งงาน แล้วเทียบต้นทุนระหว่างการรัน AI ตัวลูกแบบพร้อมกันหลายตัว กับแบบทำทีละตัวเรียงกัน
ปรับวิธีทำงานสักอันให้ใช้แบบเรียกเครื่องมือผ่านโค้ด (code execution with MCP) หรือลดจำนวนตัวเชื่อมเครื่องมือ (MCP server) ลง แล้ววัดว่าโทเคนต่อรอบลดลงเท่าไร

3.5

โมดูล 3.5

อ่านหลักฐานเรื่องผลิตภาพแบบไม่หลงเชื่อง่าย

อย่าเชื่อคะแนนวัดผลมาตรฐาน (benchmark) และอย่าอวดเกินจริงเรื่องความเร็ว

👋 สำหรับผู้เริ่มต้น — อ่านตรงนี้ก่อน

💡

เปรียบง่าย ๆ: เหมือนโฆษณาอาหารเสริมที่อวดว่ากินแล้วผอมเร็ว แต่พอดูงานวิจัยจริงกลับไม่เป็นอย่างที่คุย เราต้องอ่านตัวเลขให้เป็นก่อนเชื่อ

🎯

ทำไมต้องรู้: หัวหน้าทีมที่ตัดสินใจตามกระแสหรือความรู้สึกอาจซื้อเครื่องมือผิดหรือคาดหวังผิด การอ่านหลักฐานเป็นช่วยตัดสินใจบนความจริง ไม่ใช่ภาพลวงตา

🎯 สิ่งที่คุณจะทำได้หลังเรียนโมดูลนี้

เข้าใจผลการทดลองของ METR และที่ METR กลับมาทบทวนผลตัวเอง (ปี 2025 เทียบ 2026)
รู้ว่างานแบบไหน AI ช่วยได้น้อย (โปรเจกต์เก่าที่โตเต็มที่ คนเขียนเชี่ยวชาญ) และแบบไหนช่วยได้มาก (งานสร้างใหม่จากศูนย์)
เข้าใจว่าคะแนนวัดผลมาตรฐาน (benchmark) เอามาเทียบข้ามชุดทดสอบที่ต่างกันไม่ได้ อย่าเลือกเครื่องมือจากเลข SWE-bench

เนื้อหา

หัวหน้าทีมต้องตัดสินใจบนหลักฐาน ไม่ใช่ตามกระแส งานทดลองแบบสุ่มแบ่งกลุ่ม (RCT) ของ METR ในปี 2025 เจอผลที่น่าตกใจว่า นักพัฒนาสายโอเพนซอร์สที่มีประสบการณ์กลับทำงาน "ช้าลงราว 19%" เมื่อใช้เครื่องมือ AI ช่วงต้นปี 2025 บนโค้ดก้อนใหญ่ที่ตัวเองคุ้นเคยมาก ทั้ง ๆ ที่พวกเขา "เชื่อว่าตัวเองเร็วขึ้นราว 20%" (ความรู้สึกกับความจริงห่างกันตั้ง 39 จุด) แต่พอถึงเดือน ก.พ. 2026 METR ออกมาทบทวนเองว่ากลุ่มตัวอย่างชุดเดิมเลือกมาไม่สมดุล (มีอคติจากการคัดเลือก หรือ selection bias) พอลองใหม่กับกลุ่มที่ใหญ่กว่า (57 คน กว่า 800 งาน) กลับได้ผลราว -4% (ช่วงความเชื่อมั่นอยู่ที่ -15% ถึง +9%) แล้วสรุปว่า "AI น่าจะช่วยเพิ่มผลิตภาพได้แล้วในต้นปี 2026" ประเด็นสำคัญที่ต้องจำคือ งานยาก ๆ (โปรเจกต์ใหญ่ที่โตเต็มที่แล้ว คนเขียนเชี่ยวชาญ มาตรฐานคุณภาพเข้มงวด) คือจุดที่ AI ช่วยได้น้อยที่สุด ส่วนงานสร้างใหม่จากศูนย์ (greenfield) โค้ดที่เราไม่คุ้น และการทำต้นแบบเร็ว ๆ มักได้ประโยชน์เยอะกว่ามาก และถึงคนจะใช้ AI กันแล้วราว 93% แต่ผลิตภาพเฉลี่ยกลับขยับไม่มาก เพราะมันขึ้นอยู่กับวิธีทำงานเป็นหลัก อีกกับดักคือตัวเลขคะแนนวัดผลอย่าง SWE-bench เพราะแค่โครงที่ครอบ AI ไว้ต่างกัน (scaffolding) ผลก็แกว่งได้ 4-10 จุดแล้ว ตัวเลขที่เจ้าของเครื่องมือรายงานเองจึงเอาไปเทียบกับตารางอันดับมาตรฐานไม่ได้ อย่าเลือกเครื่องมือจากตัวเลขพาดหัวเด็ดขาด

📖 คำศัพท์ในโมดูลนี้ (อธิบายง่าย ๆ)

Benchmarkการวัดผลเปรียบเทียบตามมาตรฐาน แต่บางทีเลขสวยในห้องทดลองก็ไม่ตรงกับงานจริง

RCTการทดลองแบบสุ่มแบ่งกลุ่ม เป็นวิธีวิจัยที่น่าเชื่อถือที่สุดในการหาว่าอะไรได้ผลจริง

Selection Biasความเอนเอียงจากการเลือกกลุ่มตัวอย่างไม่สมดุล ทำให้ผลวิจัยเพี้ยนไปจากความจริง

Overclaimการอวดอ้างเกินจริง พูดว่าดีกว่าที่มันเป็นจริงๆ

Productivityผลิตภาพ คือทำงานได้มากและดีขึ้นแค่ไหนในเวลาเท่าเดิม

🧪 ตัวอย่างจริง + ผลลัพธ์ที่ได้

ตัดสินใจนำร่องบนหลักฐาน ไม่ใช่ benchmark

ผู้บริหารเสนอ: 'โมเดล X เคลม SWE-bench 88.7% สูงกว่า Y ที่ 88.6% เปลี่ยนทั้งทีมมาใช้ X เลย' — คุณควรตอบอย่างไร

✅ ผลลัพธ์ที่ได้

คำตอบที่ควรตอบคือ ต่างกันแค่ 0.1 จุดถือว่าไม่มีนัยสำคัญ แถมตัวเลขที่เจ้าของเครื่องมือรายงานเองก็เอามาเทียบข้ามชุดทดสอบกันไม่ได้ (แค่โครงที่ครอบต่างกันก็แกว่งได้ 4-10 จุดแล้ว) ทางที่ดีควรเอามาลองนำร่องกับงานจริงของทีม วัดผลบนงานของเราเอง แล้วแยกดูงานสร้างใหม่กับโปรเจกต์เก่าที่โตเต็มที่แล้ว ก่อนตัดสินใจ

💡 จุดสอน

คะแนนวัดผลมาตรฐาน (benchmark) ใช้คัดกรองหยาบ ๆ ได้ แต่ห้ามใช้เป็นเหตุผลเดียว ให้ตัดสินด้วยการเอามาลองนำร่องกับงานจริงของทีมแล้ววัดผลตามบริบทของเรา เพราะ AI จะช่วยมากหรือน้อยขึ้นอยู่กับชนิดของงานอย่างชัดเจน

แบบฝึกหัดท้ายโมดูล

ออกแบบการทดลองวัดผลิตภาพเล็ก ๆ ในทีม โดยแยกงานสร้างใหม่จากศูนย์ (greenfield) ออกจากโปรเจกต์เก่าที่โตเต็มที่แล้ว แล้ววัดเวลาที่งานจบจริง ไม่ใช่วัดจากความรู้สึก
ลองอ่านผลของ METR ทั้งปี 2025 และฉบับอัปเดต 2026 แล้วสรุปให้ผู้บริหารฟังในย่อหน้าเดียวว่าจะ "ไม่พูดเกินจริง" และจะตัดสินใจบนหลักฐานยังไง

3.6

โมดูล 3.6

สถาปัตยกรรม Hybrid สำหรับทีมไทย

โมเดลตัวท็อป (frontier model) เขียนโค้ด + ThaiLLM สำหรับงานไทย

👋 สำหรับผู้เริ่มต้น — อ่านตรงนี้ก่อน

💡

เปรียบง่าย ๆ: เหมือนจ้างเชฟฝรั่งมือหนึ่งมาทำอาหารหลัก แต่ใช้แม่ครัวไทยชำนาญมาปรุงรสให้ถูกปากคนไทย ใช้คนที่เก่งแต่ละด้านมาเสริมกัน

🎯

ทำไมต้องรู้: ทีมไทยจะได้ทั้งโค้ดคุณภาพสูงและงานภาษาไทยที่แม่นยำ ในราคาที่คุมได้ ไม่ต้องจ่ายแพงกับทุกงาน

🎯 สิ่งที่คุณจะทำได้หลังเรียนโมดูลนี้

ออกแบบระบบแบบผสม (hybrid) ให้โมเดลตัวท็อป (frontier model) เขียนโค้ด ส่วน ThaiLLM ทำงานภาษาไทย
ดูแลเรื่องเก็บข้อมูลไว้ในประเทศให้ถูกกฎหมาย ด้วย ThaiLLM ที่รันบน ThaiSC
วางแนวปฏิบัติเรื่องภาษา ให้เอกสารสเปกและกติกาเป็นอังกฤษ ส่วนเนื้อหาที่ผู้ใช้เห็นเป็นไทย

เนื้อหา

ปิดท้ายหลักสูตรด้วยการออกแบบในระดับโครงสร้างของทั้งระบบสำหรับทีมไทย แนวทางที่แนะนำคือแบบผสม (hybrid) คือใช้โมเดลตัวท็อป (frontier model อย่าง Claude/GPT/Gemini) เขียนตัวโค้ดจริง เพราะเป็นจุดที่โมเดลพวกนี้ทำได้ดีที่สุด แล้วใช้ ThaiLLM (เช่น OpenThaiGPT, Pathumma, Typhoon, THaLLE) สำหรับงานภาษาไทยตอนใช้งานจริง โดยเฉพาะงานไทยที่ต้องคุมค่าใช้จ่าย ข้อดีของ ThaiLLM คือมันรันบน ThaiSC ทำให้ข้อมูลอยู่ในประเทศ ช่วยให้เก็บข้อมูลในไทยได้ถูกกฎหมาย และยังต่อผ่าน OpenAI SDK ได้ เลยเชื่อมกับเครื่องมือเดิมของเราได้ง่าย แนวปฏิบัติเรื่องภาษาที่สำคัญคือ คำสั่ง เอกสารสเปก และกติกาที่เขียนให้ AI เขียนโค้ด ควรเขียนเป็นภาษาอังกฤษ (เพราะเป็นภาษาที่โมเดลทำงานได้แม่นที่สุด) ส่วนเนื้อหาที่ผู้ใช้มองเห็นให้เป็นภาษาไทย ตอนนี้วงการไทยเองก็มีการอบรมคนที่รัฐสนับสนุน (กว่า 700 คนตั้งแต่ปลายปี 2025) และมีการนำไปใช้ในองค์กรด้านการเงิน เทคโนโลยี และการแพทย์ที่กำลังโตขึ้นเรื่อย ๆ หมายเหตุ ตอนนี้ยังไม่มีข้อมูลราคาและการใช้งานเฉพาะในไทยที่เชื่อถือได้สำหรับ Cursor/Copilot ให้ถือว่าใช้ราคาสากลไปก่อน และเงื่อนไขตัวแทนขายหรือแพ็กเกจองค์กรในประเทศก็ยังไม่แน่นอน

📖 คำศัพท์ในโมดูลนี้ (อธิบายง่าย ๆ)

Hybridการผสมสองแบบเข้าด้วยกันให้ได้จุดเด่นของทั้งคู่ ในที่นี้คือใช้ AI คนละตัวกับงานคนละแบบ

Frontier ModelAI รุ่นท็อปที่เก่งที่สุดในตลาด เช่น Claude, GPT, Gemini เหมาะกับงานหนักอย่างเขียนโค้ด

ThaiLLMAI ภาษาที่ฝึกมาเพื่อภาษาไทยโดยเฉพาะ เข้าใจบริบทไทยได้ดีและราคาถูกกว่า

Runtimeช่วงที่โปรแกรมกำลังทำงานจริงและมีคนใช้งานอยู่ ต่างจากตอนนั่งเขียนโค้ด

NLPงานให้คอมพิวเตอร์เข้าใจและประมวลผลภาษามนุษย์ เช่น อ่าน แปล สรุป จับใจความ

🧪 ตัวอย่างจริง + ผลลัพธ์ที่ได้

แผนผังสถาปัตยกรรม hybrid ของแอปไทย

ออกแบบสถาปัตยกรรม: แอป CRM ภาษาไทย ต้องมี (1) โค้ด backend/frontend คุณภาพสูง (2) ระบบสรุปบทสนทนาลูกค้าเป็นภาษาไทย (3) เก็บข้อมูลลูกค้าในประเทศตาม PDPA — จัดวางโมเดลอย่างไร

✅ ผลลัพธ์ที่ได้

ตอนเขียนโค้ด (build-time) ใช้ Claude/GPT ผ่าน Cursor หรือ Claude Code เขียนโค้ด โดยเอกสารสเปกและกติกาเป็นอังกฤษ ตอนใช้งานจริง (run-time) ต่อ ThaiLLM ผ่าน OpenAI SDK มาช่วยสรุปบทสนทนาภาษาไทย เพื่อให้ได้ทั้งคุณภาพภาษาและประหยัดค่าใช้จ่าย ส่วนข้อมูลลูกค้าให้เก็บและประมวลผลไว้ในไทย (บน ThaiSC หรือในประเทศ) เพื่อให้ทำตามกฎหมายได้

💡 จุดสอน

พอแยกชั้นตอนเขียนโค้ดกับตอนใช้งานจริงให้ชัด แล้วแบ่งหน้าที่ของแต่ละโมเดลให้ลงตัว เราก็จะได้ทั้งคุณภาพโค้ด คุณภาพภาษาไทย และทำตามกฎหมายได้ครบ โดยไม่ต้องยอมลดอย่างใดอย่างหนึ่ง ThaiLLM ไม่ได้มาแทนโมเดลเขียนโค้ด แต่มาเสริมงานภาษาไทยตอนใช้งานจริงต่างหาก

แบบฝึกหัดท้ายโมดูล

ออกแบบแผนผังระบบแบบผสม (hybrid) สำหรับสินค้าจริงของทีม ระบุให้ชัดว่าโมเดลไหนทำหน้าที่อะไรตอนเขียนโค้ดและตอนใช้งานจริง
เขียนแนวปฏิบัติเรื่องภาษาของทีม (เอกสารสเปกและกติกาเป็นอังกฤษ เนื้อหาที่ผู้ใช้เห็นเป็นไทย) พร้อมเหตุผลที่อิงจากประสิทธิภาพของโมเดลและการทำตามกฎหมาย

🏆 งานใหญ่ปิดคอร์ส (Capstone): ส่งมอบฟีเจอร์ที่พร้อมใช้งานจริง (production-ready) ด้วยวิธีทำงานแบบ Agentic Engineering ทั้งระบบ

เลือกฟีเจอร์จริงที่มีความเสี่ยง (แตะข้อมูลผู้ใช้/ระบบล็อกอิน หรือมีเนื้อหาภาษาไทย) บนโค้ดจริงของทีม (codebase)
ออกแบบวิธีทำงานของทั้งทีม (workflow) ได้แก่ เลือกระดับการปล่อยให้ AI ทำเอง (autonomy) ตามความเสี่ยง, ไฟล์ AGENTS.md ประจำโปรเจกต์ (repo), เอกสารสเปกของสินค้าที่คอยอัปเดตให้ทันสมัยเสมอ และการทำงานแบบเขียนสเปกนำสี่ขั้น (SDD) พร้อมจุดตรวจ (checkpoint)
ลงมือทำจริงด้วยโหมดที่ให้ AI ทำเองทีละงาน (agent mode) บังคับให้แสดงผลการทดสอบ (test) ตั้งเพดานค่าใช้จ่าย (spend limit) และประเมินโทเคน (token) ก่อนเปิดให้ AI ทำงานพร้อมกันหลายตัว (parallel) หรือต่อตัวเชื่อมเครื่องมือ (MCP) ใด ๆ
วางด่านตรวจความปลอดภัยหลายชั้นจริง ให้ AI ช่วยรีวิวก่อน (เน้นตามมาตรฐาน OWASP) → สแกนโค้ดตอนยังไม่รัน (SAST) + ทดสอบตอนรันจริง (DAST) + ตรวจชิ้นส่วนที่หยิบมาใช้ (SCA/package-firewall เพื่อกัน slopsquatting) → ให้คนรีวิวแบบสวมบทเป็นคนร้ายหาช่องโจมตี → ด่านตรวจอัตโนมัติ (CI/CD) และทดสอบใช้งานคร่าว ๆ (smoke test)
ถ้ามีส่วนภาษาไทย ออกแบบระบบแบบผสม (hybrid) ใช้โมเดลตัวท็อป (frontier model) เขียนโค้ด ส่วน ThaiLLM ทำงานภาษาไทยตอนใช้งานจริง (runtime) พร้อมพิจารณาเรื่องเก็บข้อมูลไว้ในประเทศ (data residency)
วัดผลบนงานจริง (เวลาที่งานจบต่อรอบ, ค่าใช้จ่าย, ช่องโหว่ที่จับได้) แยกมุมมองงานสร้างใหม่จากศูนย์ (greenfield) กับโปรเจกต์เก่าที่โตเต็มที่แล้ว (repo) และเขียนสรุปแบบ 'ไม่พูดเกินจริง' อิงหลักฐาน
ส่งมอบ ได้แก่ ฟีเจอร์ที่รวมเข้าโค้ดหลักแล้ว (merge) + เอกสารวิธีทำงาน + รายงานความปลอดภัยหลายชั้น + รายงานค่าใช้จ่าย + แผนผังระบบแบบผสม (hybrid ถ้ามี) + บทวิเคราะห์ผลิตภาพแบบไม่หลงเชื่อง่าย

🎓

จบหลักสูตรการใช้งาน AI Coding อย่างมืออาชีพ

เครื่องมือ →เวิร์กโฟลว์ →จริยธรรม →