AI เขียนโค้ดแทนเราได้แล้ว — แล้วเราจะเหลืออะไรให้ทำ?

AI เขียนโค้ดแทนเราได้แล้ว — แล้วเราจะเหลืออะไรให้ทำ?

มีประโยคที่ได้ยินบ่อยขึ้นทุกวัน: "เดี๋ยวนี้ใครยังไม่ใช้ AI ช่วยเขียนโค้ดบ้าง?"

คำตอบคือ — แทบไม่มีแล้วครับ

ตั้งแต่ GitHub Copilot, Cursor, Claude, ChatGPT ไปจนถึง agent ที่เขียนโค้ดเองได้ทั้ง project — เราใช้ AI ใน level ที่ต่างกัน:

Level	หน้าตา	ตัวอย่าง
🎵 Vibe Coding	พิมพ์สิ่งที่อยากได้ กด accept อย่างเดียว	"เขียนหน้า login ให้หน่อย" → กด tab tab tab
🧩 Prompt-Guided	คิดก่อน ถามทีละส่วน ตรวจทุกอย่าง	"สร้าง UserService ที่ใช้ bcrypt hash password"
🛠️ Skill/Lint-Guided	ใช้ AI เป็น editor ชั้นสูง — lint, refactor, test	"refactor function นี้ให้เป็น table-driven test"
🏗️ Agent-Based	ให้ AI run ทั้ง project — spawn subagent, PR, deploy	"พอร์ต microservice นี้จาก Express ไป Fastify"

แล้วคำถามคือ — ถ้า AI ทำทั้งหมดนี้ได้ แล้วมนุษย์อย่างเราเหลืออะไร?

---

Unit Test — ตัวอย่างที่เห็นชัดที่สุด

ลองดู unit test ที่ AI เขียนให้:

// 🤖 AI-generated test
func TestCalculateDiscount(t *testing.T) {
    tests := []struct {
        name     string
        input    float64
        expected float64
    }{
        {"zero", 0, 0},
        {"normal", 100, 90},   // 10% discount
        {"max", 1000, 800},     // 20% discount
    }
    for _, tt := range tests {
        t.Run(tt.name, func(t *testing.T) {
            result := CalculateDiscount(tt.input)
            if result != tt.expected {
                t.Errorf("got %v, want %v", result, tt.expected)
            }
        })
    }
}

ดูเผิน ๆ — สวย, table-driven, ถูกต้องตาม Go convention¹

แต่ถามหน่อย — test นี้บอกอะไรเกี่ยวกับ business?

• "ส่วนลด 10% สำหรับยอด 100 บาท" — ทำไมต้อง 100? เป็นกฎจากที่ไหน?
• "ส่วนลด 20% เมื่อยอดถึง 1000" — แล้วถ้าลูกค้าเป็น member ได้เพิ่มอีก 5% ล่ะ?
• input: 0, expected: 0 — test นี้ cover edge case หรือแค่ cover บรรทัด?

AI test ได้ถูกต้องตาม function — แต่มัน ไม่รู้ว่า business จริง ๆ คืออะไร

---

AI ไม่รู้ Business Context — และจะไม่มีวันรู้

นึกภาพระบบ e-commerce:

ลูกค้าซื้อสินค้า → ระบบตัดสต็อก → คำนวณส่วนลด → คิดค่าส่ง → ออกใบเสร็จ

AI แยก test ทีละ function ได้:

• ✅ TestDeductStock — "ตัดสต็อก 1 ชิ้น"
• ✅ TestCalculateDiscount — "ส่วนลด 10%"
• ✅ TestCalculateShipping — "ค่าส่ง 50 บาท"

แต่สิ่งที่ AI ไม่รู้:

"ถ้าลูกค้ากดสั่ง แล้วสต็อกเหลือ 0 พอดี — ระบบต้อง reserve ไว้ 15 นาทีให้ลูกค้าจ่ายเงิน ถ้าไม่จ่ายให้คืนสต็อก และต้องส่ง notification ไปที่ร้านด้วย"

นี่คือ business flow — มันไม่ใช่ unit test ของ function ใด function หนึ่ง แต่มันคือเรื่องราวที่เชื่อม function เข้าด้วยกัน และมีแค่ มนุษย์ เท่านั้นที่รู้ว่ามันควรจะเป็นยังไง

ต่อให้โยน requirement ทั้งก้อนเข้า context window — AI ก็อาจจะเชื่อมเรื่องราวถูก ในวันนี้ แต่อีก 3 เดือนถัดมา:

• มีเงื่อนไขใหม่: "ลดเพิ่ม 5% สำหรับ member"
• มี edge case: "สินค้า pre-order — ห้ามตัดสต็อก"
• มี bug report: "ลูกค้าได้ส่วนลดซ้อน — 10% + 5%"

AI ไม่มี context ว่า "ทำไมโค้ดนี้ถึงถูกเขียนขึ้นมา" — มันเห็นแค่โค้ด ไม่เห็นความตั้งใจ²

---

Token — ต้นทุนที่มองไม่เห็น

อีกเรื่องที่คนไม่ค่อยพูดถึง: Token cost

# AI เสนอ — "refactor test ทั้งหมดเป็น parameterized"
# เพื่อให้ได้ test ที่ดี มันต้องอ่าน:
#   1. function ที่จะ test (200 lines)
#   2. test เดิมทั้งหมด (500 lines)
#   3. business logic ที่เกี่ยวข้อง (300 lines)
#   4. codebase context — import, types, helpers (1000+ lines)
#
# รวม ≈ 10,000-20,000 tokens ต่อรอบ
# ถ้า refactor ครบ project — 200,000+ tokens
# 
# ด้วย Claude Sonnet = ~$0.60 USD (200K tokens)
# ด้วย GPT-4o = ~$1.00 USD
#
# ฟังดูไม่เยอะ — แต่ทำแบบนี้ทุกวัน = $20-30/เดือน
# สำหรับทีม 5 คน = $100-150/เดือน
# สำหรับทีม 50 คน = $1,000-1,500/เดือน

และนี่แค่ test refactor — ยังไม่นับ code review, PR description, document generation

ประเด็นไม่ใช่ "แพง" — แต่คือ "มันคุ้มกับสิ่งที่ได้ไหม?"

• Test ที่ AI เขียน: cover function ครบ → ✅ คุ้ม
• Test ที่ AI เขียน: ไม่ได้ cover business flow → ❌ ไม่คุ้ม

---

แล้วมนุษย์ควรทำอะไร?

1. เป็นคนถือ Business Context

คุณคือคนเดียวที่รู้ว่า:

• "ทำไมฟีเจอร์นี้ถึงเกิด" (ไม่ใช่แค่ "มันทำงานยังไง")
• "ขอบเขตของ requirement คืออะไร" (AI ชอบเขียนเลยขอบ³)
• "แล้วอะไรที่เปลี่ยนได้ / อะไรที่เปลี่ยนไม่ได้"

AI = คนเขียนโค้ด, คุณ = Product Owner ในร่าง developer

2. อ่าน Diff ไม่ใช่แค่กด Accept

Vibe coding⁴ สนุก — แต่พอ project โตขึ้น:

ปัญหาจริง:
- AI เพิ่ม dependency โดยไม่บอก
- AI refactor function แล้วลบ business logic สำคัญออก
- AI duplicate code แทนที่จะ extract shared logic
- AI เลือก pattern ที่ "ถูก" แต่ไม่ใช่ pattern ที่ทีมใช้

กฏส่วนตัวผม: AI proposal ทุกอัน = PR review หนึ่งรอบ — git diff ทุกไฟล์, ถามตัวเองว่า "โค้ดนี้ยังสะท้อน business requirement อยู่ไหม?"

3. เขียน Test แบบ Business-First

แทนที่จะถาม AI ว่า "เขียน test ให้ฟังก์ชันนี้หน่อย" — ลองถามแบบนี้:

"นี่คือ requirement: 'ลูกค้าที่ซื้อครบ 500 บาทได้ส่งฟรี แต่ถ้าเป็น member ได้ส่งฟรีที่ 300 บาท และถ้าสั่ง pre-order ห้ามรวมกับโปรอื่น' — ช่วยเขียน test ที่ cover requirement นี้ โดยไม่ต้องดูโค้ดเดิม"

แบบนี้ AI จะเขียน test จาก business requirement — ไม่ใช่จาก function signature — และคุณจะได้ test ที่พิสูจน์ว่าโค้ดทำงานถูกต้องตาม business จริง ๆ

4. ใช้ AI เป็น Navigator — ไม่ใช่ Pilot

❌ Pilot Mode: AI ขับ → คุณนั่งดู
   "สร้าง API สำหรับ user management"
   → AI ทำทั้งหมด → คุณกด merge

✅ Navigator Mode: คุณขับ → AI นำทาง
   "ผมจะสร้าง handler สำหรับ reset password — 
    ช่วยแนะนำ flow ที่ secure หน่อย, 
    OWASP มีอะไรที่ต้องระวัง, 
    แล้วช่วยร่าง test case ให้"
   → AI แนะนำ → คุณเขียนโค้ด → AI review

Navigator mode ใช้ token น้อยกว่า, ผิดพลาดน้อยกว่า, และคุณยังเป็นเจ้าของโค้ด⁵

---

สรุป

AI ทำได้ดี	มนุษย์ต้องทำ
เขียน boilerplate	ถือ business context
Refactor ตาม pattern	อ่าน diff, ถาม "ทำไม"
Generate test จาก function	เขียน test จาก business requirement
แนะนำ best practice	ตัดสินใจว่าใช้ pattern ไหน
หา bug pattern	เข้าใจว่า bug นี้กระทบ business ยังไง
อธิบายโค้ด	เข้าใจ ความตั้งใจ ของโค้ด

---

คำถามไม่ใช่ "AI จะแทนที่ developer ไหม" — แต่มันคือ:

"Developer ที่ใช้ AI จะแทนที่ developer ที่ไม่ใช้ — และ developer ที่เข้าใจ business จะแทนที่ทั้งคู่"

---

เชิงอรรถ

---

1. Table-driven test: pattern มาตรฐานใน Go — ประกาศ test case เป็น slice ของ struct แล้ว loop t.Run() — อ่านง่าย เพิ่ม test case ง่าย ไม่ต้อง copy-paste โค้ด test ↩

2. Code ≠ Intent: โค้ดคือ "อะไร" (what) — requirement, design doc, commit message คือ "ทำไม" (why) — AI เห็น what แต่ไม่เห็น why นี่คือช่องว่างที่มนุษย์มีค่า ↩

3. AI ชอบเขียนเลยขอบ: AI มักจะ "ช่วย" โดยเพิ่ม edge case handling, validation, error message — ซึ่งดูดีใน diff แต่จริง ๆ แล้วมันกำลังขยาย scope ของงาน — เท่ากับเพิ่ม surface area สำหรับ bug โดยไม่จำเป็น ↩

4. Vibe Coding: คำที่ Andrej Karpathy ใช้เรียกการเขียนโค้ดแบบ "พิมพ์ prompt → accept → ไม่ดู diff" — สนุกและ productive สำหรับ prototype แต่ risk สูงมากสำหรับ production ↩

5. Navigator vs Pilot: analogy จาก aviation — pilot มีอำนาจตัดสินใจสุดท้าย navigator ให้ข้อมูล — ในบริบทโค้ด: คุณคือ pilot เพราะคุณต้องรับผิดชอบโค้ดที่ merge เข้า main ↩