แผนการเรียนรู้
/

ส่วนที่ 2: กลไก AI และกลยุทธ์การบริหารโปรเจกต์

เจาะลึกการทำงานของ Agent และการควบคุม "หนี้ทางเทคนิค" เพื่อความยั่งยืน

09:45 - 10:30 | บรรยายเชิงกลยุทธ์

กลไกเบื้องหลัง: Probabilistic Engine

AI ไม่ได้ "เข้าใจ" โค้ดเหมือนมนุษย์ แต่มันคือ "เครื่องจักรทำนายคำถัดไป" [1]

หลักการทำงาน:

  • ทำนาย Token ถัดไปที่มีความน่าจะเป็นสูงสุดจากข้อมูลที่เคยเรียนรู้มา [1]
  • ความเสี่ยง: AI อาจเลือกคำที่ "ดูดี" แต่ "ใช้งานจริงไม่ได้" (Hallucination) [2]
  • หน้าที่คุณ: ตรวจสอบว่า "ความน่าจะเป็น" นั้นตรงกับ "ความเป็นจริง" หรือไม่

Context Window: "ความจำระยะสั้น"

เปรียบเสมือนขนาดของโต๊ะทำงานที่ AI สามารถวางไฟล์โค้ดเพื่ออ่านพร้อมกันได้ [3]

ความจุสูง (Frontier Models)

สามารถอ่านโค้ดได้ทั้ง Repository ในครั้งเดียว (1M+ Tokens) [3]

ข้อจำกัดของสมาธิ

ยิ่งให้อ่านเยอะ "คุณภาพของความใส่ใจ" (Attention Quality) จะลดลง [3]

ระวัง! เมื่อ AI เริ่ม "สติหลุด"

วงจรการเสื่อมถอยของบริบทในระหว่างการสนทนา [4, 5]

Phase 1 Coherence: ตอบคำถามแม่นยำ ทำตามกฎได้ดี [4]
Phase 2 Drift: เริ่มลืมกฎที่ตั้งไว้ตอนต้น เปลี่ยนชื่อตัวแปรไปมา [4]
Phase 3 Dissolution: สับสนโดยสิ้นเชิง ตอบขัดแย้งกับสิ่งที่เพิ่งพูดไป [5]

ก้าวสู่ยุค Agentic Era ด้วย Antigravity

เปลี่ยนจาก "แชทบอท" เป็น "ผู้ลงมือทำ" (Autonomous Agent) [6]

Agentic Coding: คือการใช้ AI Agent ที่มีความเป็นอิสระสูง สามารถวางแผน (Plan), เขียนโค้ด (Code), ทดสอบ (Test) และแก้ไข (Debug) ได้ด้วยตัวเองโดยมนุษย์เพียงแค่อนุมัติในจุดสำคัญ [6, 7]

กลไก 1: Implementation Plan

"หยุด AI ไม่ให้มั่ว ด้วยแผนงานที่ชัดเจน"

ใน Antigravity ก่อนจะเขียนโค้ดบรรทัดแรก AI จะต้องสร้าง "แผนการดำเนินงาน" ให้คุณตรวจสอบก่อน [8]

  • ช่วยให้เห็นภาพรวมของไฟล์ที่จะถูกสร้าง
  • ลดความเสี่ยงของการเขียนโค้ดผิดโครงสร้าง
  • คุณสามารถแก้ไขแผนได้ก่อน AI ลงมือจริง
📝

กลกล 2: Browser Subagent

AI ที่มี "ตา" และ "มือ" บนโลกอินเทอร์เน็ต [8]

ทำหน้าที่แทนคุณ:

  • อ่าน Documentation ล่าสุดของ Django/React
  • ตรวจสอบสถานะการ Deploy บน Render.com
  • ค้นหาวิธีแก้ปัญหาจาก Error Message จริง

จุดแข็ง:

ก้าวข้ามขีดจำกัดเรื่อง "ข้อมูลล้าสมัย" (Knowledge Cutoff) ของ AI แบบเดิมๆ [9]

Tokens: "น้ำมัน" ของ AI

1 คำ

≈ 1.3 Tokens

เงิน

ทุก Token มีต้นทุน

ขีดจำกัด

Model มีลิมิตต่อครั้ง

การคำนวณ Token Budget คือการวางแผนว่าจะใช้ "งบประมาณ" นี้อย่างไรให้คุ้มค่าที่สุด [10]

กลยุทธ์การประหยัด Token

"ลดรายจ่าย เพิ่มประสิทธิภาพด้วยการบริหาร Context" [10, 11]

💡

Multi-Model Architecture: ใช้ Model เล็ก (ถูก) สำหรับงานคัดแยกประเภท และใช้ Model ใหญ่ (แพง) สำหรับงานเขียน Logic ซับซ้อน [11]

💡

Strict Context Control: เลือกส่งเฉพาะไฟล์ที่เกี่ยวข้องให้ AI อ่าน ไม่ส่งทั้งโปรเจกต์โดยไม่จำเป็น [10, 12]

💡

Caching: บันทึกคำตอบของ AI ไว้ใช้ซ้ำสำหรับคำถามที่เหมือนเดิม [10]

Technical Debt: "ดอกเบี้ย" ที่ต้องจ่าย

คือการเลือกทางลัดเพื่อให้งานเสร็จเร็วในวันนี้ แต่สร้างภาระในการดูแลรักษาในวันหน้า [13]

ความจริงที่น่ากลัว:

AI ช่วยให้เราสร้างโค้ดได้มหาศาลในเวลาอันสั้น...

แต่อาจเป็นการสร้าง "ขยะดิจิทัล" (AI Slop) ที่ไม่มีใครเข้าใจและซ่อมไม่ได้ [14, 15]

สถิติ "หนี้" จากการใช้ AI (2026)

ผลการศึกษาจาก 6,000+ GitHub Repositories [16, 17]

89.1%

ของปัญหาคือ Code Smells (โค้ดที่รันได้แต่ดูแลยาก) [17]

24.2%

ของปัญหาเหล่านี้ จะคงอยู่ตลอดไป หากไม่รีบแก้ทันที [18]

ช่องโหว่ความปลอดภัยที่พบบ่อย

AI มักจะแนะนำโค้ดที่ "สะดวก" แต่ "ไม่ปลอดภัย" [19]

1. SQL Injection

การต่อ String ในฐานข้อมูลโดยตรง ทำให้ Hacker แฮกระบบได้ [20]

2. Insecure Subprocess

การใช้ `shell=True` ที่เปิดช่องให้รันคำสั่งอันตรายใน Server [21]

3. Hardcoded Secrets

การใส่ Password หรือ API Key ลงในโค้ดตรงๆ [22]

4. Broad Exceptions

การดัก Error แบบครอบจักรวาล ทำให้ไม่รู้สาเหตุที่แท้จริง [20]

Human-in-the-loop: หัวใจการคุม AI

"AI คือลูกน้องที่ขยันแต่ประมาท คุณคือหัวหน้างานที่ต้องตรวจทาน" [23, 24]

Trust but Verify

ความเร็วที่ได้จาก AI จะไร้ความหมายหากมันนำไปสู่หายนะใน Production นักพัฒนาต้องอ่านโค้ดทุกบรรทัดก่อนกด "Accept" [25, 26]

🚦

ใช้ Spec ลดหนี้ทางเทคนิค

"โค้ดห่วยเกิดจากคำสั่งที่ไม่ชัดเจน" [27]

การเขียน Spec ที่ดีช่วยลดหนี้ได้อย่างไร?

  1. ลดความคลุมเครือ: AI ไม่ต้องเดาใจคุณเอง [27]
  2. กำหนดขอบเขตชัดเจน: ป้องกัน AI เขียนโค้ดส่วนเกินที่ไม่ได้ใช้ [28]
  3. ระบุมาตรฐานความปลอดภัย: บังคับให้ AI ใช้ Library ที่ปลอดภัยตั้งแต่ต้น [29]

ธรรมาภิบาลข้อมูล (Governance)

"สร้างรั้วกั้นเพื่อความปลอดภัยของโปรเจกต์" [30]

Team Governance

การกำหนดว่าใครมีสิทธิ์เข้าถึง AI รุ่นไหน และใช้ข้อมูลชุดไหนได้บ้าง [31]

Output Validation

ใช้เครื่องมืออัตโนมัติ (Static Analysis) ตรวจสอบโค้ด AI ก่อน Merge [30]

.clinerules: กฎเหล็กประจำทีม

ไฟล์ที่บอกให้ AI รู้ว่า "ในบ้านหลังนี้ เรามีกฎอย่างไร" [32]

# .clinerules Example

- ต้องใช้ Django REST Framework เท่านั้น

- ห้ามใช้ Inline CSS ใน React

- ทุก Function ต้องมี Docstring อธิบายหน้าที่ [22]

- ต้องตรวจสอบ SQL Injection เสมอ [20]

*Antigravity จะอ่านไฟล์นี้ทุกครั้งเพื่อควบคุมพฤติกรรมของ Agent*

Session Architecture

"อย่าคุยกับ AI จนล้า ให้เริ่ม Session ใหม่เสมอเมื่อเปลี่ยนงาน" [12, 33]

❌ มาราธอนแชท

คุยยาว 200 ข้อความ จน AI เริ่มจำอะไรไม่ได้ (Context Dissolution) [5]

✅ ธุรกรรมแชท

จบหนึ่งงาน ล้างแชท สรุปงานเดิม แล้วเริ่มใหม่ด้วยบริบทที่สะอาด (Handoff Pattern) [12, 34]

Keep the Scope Small

"แบ่งงานใหญ่ให้เป็นชิ้นเล็ก เพื่อการตรวจสอบที่แม่นยำ" [28]

BAD

"สร้างระบบจองโรงแรมให้ฉันหน่อย"

➡️

GOOD

"สร้างฟังก์ชันตรวจสอบวันว่างของห้องพัก"

การรีวิวโค้ด 500 บรรทัดในครั้งเดียวเป็นเรื่องยาก แต่การรีวิว 50 บรรทัดให้ถูกต้อง 100% เป็นเรื่องง่าย [35]

ROI: ความคุ้มค่าที่แท้จริง

ความสำเร็จไม่ได้วัดแค่ที่ "ความเร็ว" แต่วัดที่ "ผลลัพธ์ธุรกิจ" [36]

  • ✅ **ประหยัดเงิน:** ลด Token ด้วย Multi-model Routing [11]
  • ✅ **เพิ่มนวัตกรรม:** มนุษย์ไปโฟกัสที่การแก้ปัญหาระดับสูง [37, 38]
  • ✅ **ลดความเสี่ยง:** ตรวจเจอ Security Bug เร็วขึ้น [39, 40]
  • ✅ **ความยั่งยืน:** โค้ดมีคุณภาพพร้อมเติบโต (Scalability) [41]

การวัดผลความสำเร็จ

"ถ้าคุณวัดผลไม่ได้ คุณก็คุมมันไม่ได้" [42]

Cycle Time

เวลาตั้งแต่เริ่มสั่งจน Deploy สำเร็จลดลงกี่ %? [43]

Defect Rate

จำนวนบั๊กที่หลุดไปถึง Production ลดลงหรือไม่? [44]

Cost/Feature

ต้นทุน Token ต่อการสร้าง 1 ฟีเจอร์เป็นเท่าไหร่? [10]

Checklist สำหรับนักพัฒนา 10x

มี Technical Spec 7 องค์ประกอบแล้วหรือยัง?

ไฟล์ .clinerules ตั้งค่าไว้ถูกต้องไหม?

ได้อ่านและรีวิวโค้ด AI ก่อนกด Accept หรือไม่?

ได้ตรวจสอบ SQL Injection และช่องโหว่อื่นๆ แล้ว?

ความหวัง: กรณีศึกษา Amazon

พลังของการใช้ AI ในการปรับปรุงระบบเก่า (Modernization) [45]

4,500 ปีของการทำงาน

Amazon สามารถลดภาระงานของนักพัฒนาลงได้มหาศาลจากการใช้ AI มาช่วยอัปเกรดระบบ Java เก่าๆ ให้ทันสมัย โดยใช้เวลาเพียง 1 ปี แทนที่จะต้องใช้คนทำถึง 4,500 ปี [45, 46]

"นี่คือเหตุผลที่เราต้องเรียนรู้ที่จะเป็น Orchestrator ตั้งแต่วันนี้"

ความรับผิดชอบและจริยธรรม

"AI ทำงาน แต่คุณรับผิดชอบผลลัพธ์ทางกฎหมาย" [30]

Privacy First

ห้ามใส่ข้อมูลลูกค้าหรือข้อมูลลับบริษัทลงใน Prompt [47, 48]

IP Ownership

ตรวจสอบสิทธิ์ความเป็นเจ้าของในโค้ดที่ AI สร้างขึ้น [30, 49]

เป้าหมายสูงสุด: Verified Code

จากความต้องการ (Intent) สู่ซอฟต์แวร์ที่ตรวจสอบความถูกต้องได้จริง [2]

ในเวิร์กชอปนี้ เราจะไม่ได้สอนแค่ให้ AI "เขียนโค้ดที่รันได้" แต่จะสอนให้คุณคุม AI ให้สร้างระบบที่ **ปลอดภัย, ดูแลรักษาง่าย และพร้อมใช้งานบน Cloud จริงๆ**

สรุปประเด็นสำคัญ (ส่วนที่ 2)

  • Agent Mechanisms: Antigravity ใช้แผนงานและการท่องเว็บเพื่อความแม่นยำ [8]
  • Economy: บริหาร Token Budget เหมือนบริหารงบประมาณธุรกิจ [10]
  • Quality: หยุด Technical Debt ด้วย Spec และกฎ .clinerules [13, 32]
  • Security: นักพัฒนาคือด่านสุดท้ายในการตรวจช่องโหว่ (Human-in-the-loop) [23]

พร้อมลงมือปฏิบัติหรือยัง?

ลำดับถัดไป: ภาคปฏิบัติ - การติดตั้งและรากฐาน MVP

🚀