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

> Source: <https://dev.to/gophernment/ai-ekhiiynokhdaethneraaaidaelw-aelweraacchaehluueaairaihtham-2kca>
> Published: 2026-06-30 00:40:07+00:00

มีประโยคที่ได้ยินบ่อยขึ้นทุกวัน: "เดี๋ยวนี้ใครยังไม่ใช้ 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 ที่ 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**

```
# 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

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

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

**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 ทำได้ดี | มนุษย์ต้องทำ |
|---|---|
| เขียน 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 จะแทนที่ทั้งคู่"

**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 ↩