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

​

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

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

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

แล้วคำถามคือ — ถ้า 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 จะแทนที่ 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 ↩