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

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

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

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

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

ลองดู 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 convention1

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

input: 0, expected: 0

— test นี้ cover edge case หรือแค่ cover บรรทัด?AI test ได้ถูกต้องตาม function — แต่มัน ไม่รู้ว่า business จริง ๆ คืออะไร

นึกภาพระบบ 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 เดือนถัดมา:

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

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

#
# 
#

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

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

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

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

Vibe coding4 สนุก — แต่พอ 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 อยู่ไหม?"

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

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

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

❌ 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 น้อยกว่า, ผิดพลาดน้อยกว่า, และคุณยังเป็นเจ้าของโค้ด5

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

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

Table-driven test: pattern มาตรฐานใน Go — ประกาศ test case เป็น slice ของ struct แล้ว loop t.Run()

— อ่านง่าย เพิ่ม test case ง่าย ไม่ต้อง copy-paste โค้ด test ↩

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

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

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

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