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

A developer argues that while AI tools like GitHub Copilot, Cursor, and Claude can generate code and tests, they lack understanding of business context and intent. The developer warns that AI-generated code may miss critical business flows, increase token costs, and introduce hidden issues like unnecessary dependencies or deleted logic. The developer recommends treating every AI proposal as a PR review and focusing on business requirements rather than just code generation.

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