สรุปสั้นก่อนเริ่ม
วันที่ 30 เมษายน 2026 ที่ Sequoia Capital — Andrej Karpathy อดีตหัวหน้า AI ของ Tesla, founding member ของ OpenAI และคนที่บัญญัติคำว่า "vibe coding" เมื่อกุมภาพันธ์ปีก่อน ออกมาบอกตรงๆ ว่า
โค้ดที่ AI เขียนทุกวันนี้ยัง "awkward, gross, bloaty" เต็มไปด้วย copy-paste และ brittle abstractions บางครั้งดูแล้วเขา "heart attack" เลย
มากกว่านั้น Karpathy ยังเปิดเผยว่าโปรเจกต์ใหม่ของเขาที่ Eureka Labs — เขา hand-code เอง ไม่ได้ใช้ vibe coding ตามที่ตัวเขาเองเป็นคนจุดกระแส
นี่ไม่ใช่ข่าวดราม่า — มันคือสัญญาณสำคัญสำหรับทุกคนที่ใช้หรือกำลังจะใช้ AI ในการเขียนโค้ด ทั้ง CTO, tech lead, developer และเจ้าของธุรกิจที่จ้าง software house
บทความนี้สรุปสิ่งที่ Karpathy พูด, mental model ที่เขาแนะนำ ("AI agent = intern entities"), 4 สิ่งที่มนุษย์ยังต้องคุม และวิธีทำ AI-assisted coding ให้ได้ผลจริงในระดับ production — ไม่ใช่แค่ demo
คนที่จุดกระแส "vibe coding" บอกเองว่ามันยังไม่พร้อม
ถ้าจะมีคนหนึ่งที่มีสิทธิ์พูดเรื่อง vibe coding มากที่สุดในโลก คนนั้นคือ Karpathy
เพราะเขาคือคนที่ บัญญัติคำนี้ขึ้นมาเอง เมื่อต้นเดือนกุมภาพันธ์ 2025 ผ่านทวีตที่กลายเป็นไวรัล — บอกว่า "fully give in to the vibes, embrace exponentials, and forget that the code even exists" (ปล่อยใจไปกับ vibe ยอมรับเส้นโค้งเอ็กซ์โพเนนเชียล แล้วลืมไปเลยว่ามีโค้ดอยู่)
นั่นคือทวีตที่ทำให้คำว่า "vibe coding" ระเบิดในวงการ — startup, indie hacker, content creator, แม้แต่ VC พูดกันทุกที่
แต่ปีต่อมา 30 เมษายน 2026 ที่ห้องสัมภาษณ์ของ Sequoia Capital ตัวเขาเองออกมาบอกว่า:
"It's very bloaty, and there's a lot of copy-paste, and there's awkward abstractions that are brittle"
"Sometimes I get a little bit of a heart attack because it's not like super amazing code necessarily all the time"
แปลตรงตัว — โค้ดที่ AI เขียน "อ้วนเทอะทะ, copy-paste เยอะ, abstraction ที่ออกมาแล้วเปราะ" และบางครั้งอ่านแล้วใจหายเพราะมันไม่ใช่โค้ดที่ดีเสมอไป
ทำไมเรื่องนี้สำคัญ? เพราะถ้าคนที่จุดไฟลุกยังออกมาบอกว่ายังไม่พร้อม คนที่ใช้กระแสนี้ในการตัดสินใจทางธุรกิจต้องฟังให้ดี
Karpathy คือใคร — บริบทที่ต้องรู้
ก่อนเข้าเรื่อง สำหรับคนที่ยังไม่รู้จัก Karpathy ผมขอเล่าสั้นๆ ว่าทำไมคำพูดของเขามีน้ำหนัก
- Founding member ของ OpenAI — อยู่ตั้งแต่วันแรกๆ
- อดีตหัวหน้า AI ของ Tesla — คุมทีมที่พัฒนาระบบ Autopilot
- กลับเข้า OpenAI สั้นๆ ก่อนออกมาก่อตั้ง Eureka Labs
- ก่อตั้ง Eureka Labs — แพลตฟอร์มการศึกษาที่ขับเคลื่อนด้วย AI
- บัญญัติคำว่า "Software 3.0" — programming ผ่าน prompt และ context management
สั้นๆ คือ — เขาคือหนึ่งในคนที่อยู่ใกล้ชิดกับ AI มากที่สุดในโลก ทั้งในฐานะนักวิจัย, นักสร้างผลิตภัณฑ์ และนักการศึกษา
เวลาคนแบบนี้ออกมาบอกว่า "AI ยังไม่พร้อมจะปล่อยให้ทำงานคนเดียว" — มันไม่ใช่ความเห็นของคนกลัว AI มันคือ insider report
"Vibe Coding" คืออะไรกันแน่
ปัญหาคือ คนเข้าใจคำว่า vibe coding ผิดมาก
ในทวีตต้นฉบับ Karpathy อธิบายว่า vibe coding คือ workflow ที่เขาใช้ — เขียน prompt สั้นๆ บอกความต้องการ แล้วปล่อยให้ Cursor + Sonnet สร้างโค้ดออกมา ใช้ voice input (SuperWhisper) แทนการพิมพ์ และ "ลืม" ไปเลยว่ามีโค้ดอยู่ — แค่ดูว่ามันรันได้หรือเปล่า
แต่คนนำคำนี้ไปขยายความผิด — กลายเป็นว่า vibe coding = "ไม่ต้องคิด ไม่ต้องดูโค้ด แค่ prompt แล้ว ship"
ความจริงไม่ใช่อย่างนั้น แม้แต่ทวีตเดือนเมษายน 2025 ของ Karpathy เองก็เปลี่ยนนิยามไปแล้ว:
"Adopting a certain rhythm in AI-assisted coding... Stuff everything relevant into context"
แปล — ใน AI-assisted coding ต้อง "ยัด" ทุกอย่างที่เกี่ยวข้องเข้าไปใน context อย่างพิถีพิถัน ไม่ใช่ปล่อยใจ
นี่คือ contradiction ที่ industry ต้องสังเกต — คำว่า vibe coding ถูกใช้ในความหมายที่ creator ของมันเองไม่ได้ตั้งใจ
ทำไม Karpathy บอกว่าโค้ด AI ยัง "gross"
ลองมาดูคำกล่าวของเขาที่ Sequoia แบบละเอียด
"It's very bloaty"
bloaty = อ้วนเกินจำเป็น มี code ที่ไม่ได้ใช้ มี abstraction ที่ไม่ต้องมี มี layer ที่ซ้อนกันโดยไม่จำเป็น
"there's a lot of copy-paste"
AI มักจะ duplicate logic แทนที่จะ extract function เพราะมันเดาว่า user อาจไม่อยากให้ refactor ของเดิม ผลคือมีโค้ดเหมือนกัน 80% กระจายอยู่ 5 ที่
"awkward abstractions that are brittle"
abstraction ที่ออกแบบมาแย่ — แตกง่าย เปลี่ยนนิดเดียวพังหมด เพราะ AI สร้างจาก pattern ที่เห็นบ่อยใน training data ไม่ได้สร้างจากความเข้าใจจริงในปัญหา
"really gross"
คำว่า "gross" ในภาษาวิศวกรรมซอฟต์แวร์ = ดูแล้วรู้สึกผิด ไม่ใช่ wrong (ผิดในเชิงตรรกะ) แต่เป็น "smells bad" — เหมือนเข้าครัวแล้วเจออาหารที่ทำเสร็จแล้ว แต่ดูแล้วไม่อยากกิน
"Sometimes I get a little bit of a heart attack"
นี่คือคำพูดของคนที่อยู่ในวงการ AI ระดับโลก — เปิดใจว่าอ่านโค้ด AI แล้วยังตกใจ เพราะมันไม่ใช่ code ที่เขายินดี ship จริงๆ
ประเด็นสำคัญ — Karpathy บอกชัดว่า "nothing fundamental" ที่ทำให้ AI เขียน clean code ไม่ได้ มันเป็นเพราะ labs ยังไม่ได้โฟกัสปัญหานี้ ในขั้นตอน training ของโมเดล
"Intern Entities" — Mental Model ที่ใช่ที่สุด
หนึ่งใน mental model ที่ผมชอบที่สุดจากการสัมภาษณ์นี้คือคำว่า:
"Right now, the agents are like these intern entities"
AI agent = intern (เด็กฝึกงาน)
ทำไมเปรียบเทียบนี้ใช่?
- intern เก่งบางอย่าง — เร็ว, ขยัน, ทำงาน routine ได้ดี
- intern ใหม่หลายเรื่อง — ไม่รู้ context ของบริษัท, ไม่รู้ legacy decision, ไม่รู้ว่าทำไมต้องทำแบบนั้น
- intern ต้อง mentor — ต้องมีคนสอน, review, อธิบาย
- ปล่อย intern ทำงานสำคัญคนเดียว = หายนะ
ลองคิดดู — ถ้าคุณเป็น senior dev คุณจะปล่อย intern ใหม่เขียน payment system แล้ว merge ขึ้น production โดยไม่ review ไหม?
คำตอบคือ "ไม่" — เพราะ stake สูงเกินไป
แต่ในยุค vibe coding หลายคนทำแบบนี้กับ AI ทุกวัน — ปล่อยให้ AI agent ทำงานสำคัญแล้ว ship เลย โดยไม่อ่าน
ผลที่ตามมา — bug ใน production, security hole, performance issue, technical debt มหาศาล
Karpathy ไม่ได้บอกว่า AI ไม่ดี เขาบอกว่า "ใช้ให้ถูก" — เหมือนใช้ intern ให้ถูก คือมอบงานที่เหมาะสม + ตรวจงานทุกครั้ง
Jagged Intelligence — ทำไม AI เก่งบางอย่าง โง่บางอย่าง
อีกประเด็นที่ Karpathy ย้ำคือ AI intelligence "jagged" (เป็นฟันเลื่อย) — ไม่ smooth ไม่เท่ากันทุกด้าน
โมเดลเดียวกันอาจจะ:
- เก่งสุดๆ ในการเขียน Python script
- แต่ห่วยในการเขียน Rust
- เก่งในการเขียน React component
- แต่ห่วยในการ debug memory leak
- เก่งใน boilerplate code
- แต่ห่วยใน edge case ที่ต้องคิดเอง
Karpathy ยกตัวอย่าง — ความสามารถเล่น chess ของ GPT พุ่งมากระหว่าง GPT-3.5 → GPT-4 เพราะ training data รอบนั้นมี chess data เยอะขึ้น
implication ที่สำคัญ — AI ไม่ได้ "ฉลาดขึ้น" เป็นภาพรวม แต่ฉลาดขึ้นในมิติที่ training data ครอบคลุม
แล้ว code quality ล่ะ?
Karpathy บอกตรงว่า "labs ยังไม่ได้ทำให้ code quality เป็นเป้าหมาย training" — นั่นคือเหตุผลที่ AI generate โค้ดที่ทำงานได้ แต่ไม่สวย ไม่ clean ไม่ maintainable
นี่ไม่ใช่ข้อจำกัดถาวร — มันเป็นเรื่อง prioritization
ที่ "ตลก" ที่สุด: Karpathy เองก็ไม่ใช้ Vibe Coding
ตอนนี้มาถึงส่วนที่ Futurism เปิดเผย — และเป็น twist ที่หลายคนพลาด
Karpathy ยอมรับว่าโปรเจกต์ Eureka Labs (สตาร์ทอัพการศึกษา AI ของเขาเอง) เขา hand-code เอง ไม่ได้ใช้ vibe coding
อ่านอีกครั้ง — คนที่บัญญัติคำว่า vibe coding ไม่ได้ใช้ vibe coding ในงานจริงของตัวเอง
ทำไม?
เพราะ Eureka Labs เป็น production system ที่ต้องสอนคนจริง ไม่ใช่ demo ไม่ใช่ prototype มัน matter ถ้า bug เกิดขึ้น
วิธีของเขาในงานจริง — กลับไปอ่านทวีตเมษายน 2025 — คือ "AI-assisted coding" ไม่ใช่ "vibe coding"
ความต่าง:
- Vibe coding = ปล่อยใจ ลืมโค้ด ดูแค่ output
- AI-assisted coding = AI เป็นเครื่องมือช่วย human ตัดสินใจทุกบรรทัด, ใส่ context อย่างพิถีพิถัน, review ทุก change
นี่คือบทเรียนสำคัญสำหรับทุกคน — vibe coding เป็น demo, AI-assisted coding คือ production
ใครที่ใช้ vibe coding ใน serious work อยู่ ลองถามตัวเองว่า — ผู้บัญญัติคำนี้เองยังเลือกไม่ใช้ในงานจริง คุณทำไมถึงใช้?
4 สิ่งที่มนุษย์ต้องคุม (ตาม Karpathy)
Karpathy พูดชัดในการสัมภาษณ์ว่ามนุษย์ต้อง "be in charge of the aesthetics, the judgment, the taste, and a little bit of oversight"
มาดูทีละข้อ
1. Aesthetics (ความสวยงาม)
นี่ไม่ใช่แค่เรื่อง format หรือ indent ให้สวย
aesthetics ในความหมายของ Karpathy = code ที่อ่านสบาย, structure ชัด, มี flow ที่เข้าใจได้
ทำไมสำคัญ? เพราะโค้ดที่ ship ขึ้น production ส่วนใหญ่จะอยู่ต่ออีก 5-10 ปี มีคนเข้ามาอ่าน แก้ ขยายต่อ
AI ไม่รู้เรื่องนี้ — มันสร้าง code ที่ "ทำงานได้" ตอนนี้ ไม่ได้สร้าง code ที่ "อ่านง่ายในอีก 5 ปี"
มนุษย์ต้องเป็นคน enforce aesthetic standard
2. Judgment (การตัดสินใจ)
ทุกบรรทัดของ code มี trade-off:
- simplicity vs flexibility
- explicit vs concise
- abstraction now vs abstraction later
- library A vs library B
- pattern X vs pattern Y
AI เลือกตามสิ่งที่เห็นใน training data — ซึ่งไม่ได้เหมาะกับ project ของคุณเสมอไป
มนุษย์ต้องตัดสินใจว่า trade-off ไหนเหมาะกับสถานการณ์
3. Taste (รสนิยม)
taste = sense of what fits
Naming convention ที่เข้ากับ team, pattern ที่สอดคล้องกับ codebase เดิม, idiom ที่ใช้อยู่ใน project
AI สร้าง code ที่ "ถูก" แต่ไม่ "เหมาะ" — เช่น เรียกตัวแปรว่า userData ในขณะที่ทั้ง codebase ใช้ account_info
ดูเล็ก แต่สะสมแล้วทำให้ codebase เป็น Frankenstein
4. Oversight (การกำกับดูแล)
review code ก่อน merge — ทุกครั้ง ทุกบรรทัด
test edge case ที่ AI มักลืม:
- empty input
- null values
- extreme numbers (0, -1, MAX_INT)
- race conditions
- error paths
เขียน spec ให้ชัด — Karpathy ย้ำว่า "people still need to define the spec and the plan in detail"
หลักง่ายๆ — spec ห่วย code AI ห่วยกว่า
ผลกระทบต่อ Software Industry — 5 มุม
1. Junior Developer
ข่าวดี — junior dev ไม่ได้ "ตกงาน" ตามที่ headline ขายของ
ข่าวจริง — งานเปลี่ยน
จาก "เขียน code" เป็น "orchestrate AI + review"
ทักษะใหม่ที่ต้องมี:
- prompt engineering
- code review (ที่เคยเป็นงาน senior อย่างเดียว)
- taste และ aesthetic sense
- การเขียน spec ที่ชัดเจน
ใครที่เก่งทั้ง coding + AI orchestration จะมีค่ามาก
2. Senior Developer
senior dev ที่ปรับตัว = เร็วขึ้น 3-5 เท่าใน routine task
เวลาที่ได้คืน → ใช้กับ:
- system design
- architecture decision
- mentor junior + review AI output ของทีม
ใครที่ไม่ปรับตัว = ตามไม่ทันเด็กรุ่นใหม่ที่ใช้ AI คล่อง
3. CTO/Tech Lead
ความรับผิดชอบใหม่:
- Standard — กำหนด process การ review AI code ที่บังคับใช้
- Budget — vendor cost (Cursor, Claude, OpenAI), token cost, internal tooling
- Hiring — เกณฑ์ใหม่ ไม่ใช่แค่ "เขียน code เก่ง" แต่ "ตัดสินใจคุณภาพ AI code ได้"
- Culture — สร้าง culture ที่ AI = tool, human = decision maker
4. Software House
อย่างที่ Enersys เป็น software house — เราเห็นการเปลี่ยนแปลงนี้ชัด
service ใหม่ที่เกิดขึ้น:
- AI-assisted delivery — เร็วกว่า แต่ลูกค้าต้องเข้าใจ trade-off
- AI code audit — review ของที่ทีมอื่นเขียนด้วย AI
- spec writing service — ช่วยลูกค้าเขียน spec ที่ AI ใช้ได้
pricing model อาจเปลี่ยน — จาก hourly เป็น outcome-based เพราะการเขียน code ไม่ใช่ bottleneck อีกต่อไป
5. Education
Eureka Labs ของ Karpathy = สัญญาณ — การสอน programming กำลังเปลี่ยน
ทักษะที่ต้องสอน:
- AI collaboration (ไม่ใช่แค่ใช้ AI)
- prompt design
- code judgment (รู้ว่า code นี้ดีหรือไม่)
- spec writing
- system thinking
มหาวิทยาลัยที่ยังสอนแค่ syntax = สอนทักษะที่ AI ทำได้ดีกว่า
วิธีทำ AI-Assisted Coding ให้ได้ผลจริง (ไม่ใช่ demo)
รวบรวมจากคำพูด Karpathy + ประสบการณ์ทีม Enersys ที่ใช้ AI tool ทุกวัน
1. Spec ก่อน Prompt
ก่อน prompt AI ต้องเขียน intent, constraints, edge cases (อย่างน้อย 5), success criteria ให้ครบ — AI ที่ไม่รู้บริบท = AI ที่เดา
2. Stuff Context (Karpathy method)
ใส่ทุกอย่างที่เกี่ยวข้องเข้า context: existing code, project conventions, requirement, example ของ code ที่ทำแบบเดียวกัน — Context > prompt cleverness เสมอ
3. Review Like You Mean It
อย่า merge AI code โดยไม่อ่าน ทุก. บรรทัด. ถามตัวเองทุก review — code นี้ทำงานยังไง อธิบายได้ไหม, edge case ไหนที่ AI ลืม, มี security issue ไหม (SQL injection, XSS, leak), performance issue ไหม (N+1, loop ใน loop), ถ้า requirement เปลี่ยนนิดเดียวพังไหม
4. Iterate, Don't One-Shot
flow ที่ work: prompt → review → critique → re-prompt → repeat 2-3 รอบ — เหมือนสอน intern ค่อยๆ ปรับ ค่อยๆ ดี
5. Save Patterns
เก็บ pattern ที่ work เป็น internal "AI cookbook" ของทีม — prompt template, context bundle, code example — ทีมที่มี cookbook = ทีมที่ productive ขึ้นเรื่อยๆ ไม่ต้อง reinvent prompt ทุกวัน
สำหรับทีม Enersys
ในฐานะ software house ที่ทำ Odoo, Enterprise AI และ Data Privacy (PDPA) — เราใช้ AI coding tool ทุกวัน
แต่เราไม่ ship pure vibe-coded production system ให้ลูกค้า
process ของเรา = AI as accelerator + human as judge
โดยเฉพาะงานลูกค้าที่เกี่ยวกับ:
- ข้อมูลส่วนบุคคล (PDPA compliance)
- ระบบบัญชี/การเงิน (accuracy ต้องสูงมาก)
- workflow business critical (ERP)
review = ไม่ negotiate ได้
ที่เราเล่าได้ — เราใช้ AI เร่งความเร็วในส่วน routine (boilerplate, test scaffold, refactor) แต่ design decision, security review, และการตัดสินใจสุดท้ายก่อน deploy เป็นของมนุษย์ทั้งหมด
นั่นคือเหตุผลที่ลูกค้าจ้างเรา — ไม่ใช่เพราะเราพิมพ์เก่ง แต่เพราะเรา judge ได้ว่าอะไรควร, อะไรไม่ควร
สรุป — "Awkward and Gross" คือ truth ที่ industry ต้องยอมรับ
Karpathy ไม่ได้ออกมาดิสเครดิต AI ของตัวเอง
เขาออกมา บอกความจริง ที่หลายคนไม่กล้าพูด — เพราะกลัวว่าจะดู "anti-AI" หรือ "ล้าหลัง"
ความจริงคือ:
- AI coding tool = powerful แต่ไม่ perfect
- โค้ดที่ AI เขียนยัง "gross" เพราะ labs ยังไม่ได้ optimize เป้านี้
- AI agent = intern entities ที่ต้อง mentor
- มนุษย์ยังต้องคุม aesthetics, judgment, taste, oversight
- spec ห่วย → code AI ห่วยกว่า
- vibe coding = demo, AI-assisted coding = production
อนาคต = human + AI ทำงานร่วมกัน ไม่ใช่ AI แทน human
ใครที่อ่านสัญญาณนี้เร็ว = ปรับ workflow ให้ถูก, ฝึกทีมให้ถูก, ตั้ง standard ให้ถูก
ใครที่ยังเชื่อ "AI ทำได้ทุกอย่าง" — เตรียมจ่ายค่า technical debt ในอีก 2-3 ปีข้างหน้า
ที่ Enersys เราเลือกข้างแรก — เพราะลูกค้าของเราจ่ายค่าผลลัพธ์ที่ใช้ได้จริง 5 ปี ไม่ใช่ demo ที่สวยใน 5 นาที
แหล่งข้อมูล
