Deep Dive: Karpathy Agentic Engineering

จาก Vibe Coding สู่ Agentic Engineering: เมื่อ AI เขียนโค้ดได้ แต่คนยังต้องถือพวงมาลัย

Vibe Coding ทำให้คนทั่วไป “สร้างของได้”

แต่ Agentic Engineering คือสิ่งที่ทำให้บริษัท “สร้างของได้โดยไม่พัง” ครับ

นี่คือประเด็นที่ผมว่าน่าสนใจที่สุดจากบทสนทนาของ Andrej Karpathy กับ Stephanie Zhan จาก Sequoia ในหัวข้อ From Vibe Coding to Agentic Engineering

Karpathy เป็นคนที่เคยร่วมก่อตั้ง OpenAI, เคยนำทีม Tesla Autopilot และเป็นหนึ่งในคนที่อธิบาย AI ยาก ๆ ให้คนเข้าใจง่ายที่สุดคนหนึ่งของโลก

ที่สำคัญ เขาเป็นคนที่ทำให้คำว่า vibe coding ดังขึ้นมา

แต่รอบนี้เขาเหมือนกำลังบอกว่า “vibe อย่างเดียวไม่พอแล้ว”

และผมว่าอันนี้สำคัญมาก ไม่ใช่แค่กับ developer แต่กับเจ้าของธุรกิจ ผู้บริหาร และทุกคนที่กำลังคิดเรื่อง 1 Human + 100 AI Agents

เพราะถ้า AI agent เริ่มทำงานแทนคนได้จริง คำถามจะไม่ใช่แค่ว่า “มันทำได้ไหม”

คำถามที่ใหญ่กว่าคือ:

เราจะออกแบบระบบให้มันทำงานเร็วขึ้น โดยไม่ทำให้คุณภาพ ความปลอดภัย และความเข้าใจของมนุษย์หายไปได้อย่างไร

1) Karpathy บอกว่าเขา “ไม่เคยรู้สึกตามหลังในฐานะ programmer เท่านี้มาก่อน”

ประโยคนี้สะดุดมากครับ

เพราะคนพูดไม่ใช่คนเพิ่งเริ่มเขียน code

แต่เป็น Andrej Karpathy

เขาเล่าว่า ก่อนหน้านี้เขาใช้ agentic coding tools มาสักพักแล้ว เครื่องมือกลุ่ม Claude Code, Codex และเครื่องมือใกล้เคียง ช่วยเขียน code เป็นก้อน ๆ ได้ แต่ยังต้องตรวจ ต้องแก้ ต้องคุมเยอะ

จนช่วงปลายปี เขาเริ่มเห็นจุดเปลี่ยน

สิ่งที่ agent สร้างออกมาเริ่ม “ใช้ได้เลย” มากขึ้น

เขาขอเพิ่มอีกก้อน ก็ออกมาดี

ขอเพิ่มอีก ก็ยังออกมาดี

จนเขาเริ่มจำไม่ได้ว่าครั้งสุดท้ายที่ต้องแก้หนัก ๆ คือเมื่อไหร่

นี่คือช่วงที่เขาบอกว่าตัวเองเริ่ม trust system มากขึ้น และไหลเข้าสู่ vibe coding

ฟังดูเหมือนเรื่องสนุกของ programmer ใช่ไหมครับ?

แต่จริง ๆ แล้วนี่คือ signal ใหญ่มาก

เพราะมันแปลว่า AI เริ่มไม่ได้เป็นแค่ autocomplete หรือ chatbot ที่ตอบ code snippet แล้วจบ

มันเริ่มกลายเป็น “worker” ที่ทำงานต่อเนื่องใน context ของ project ได้

2) Software 3.0: เมื่อ prompt กลายเป็นโปรแกรม

Karpathy ใช้กรอบที่น่าสนใจมาก:

• Software 1.0 คือ code ที่มนุษย์เขียนกฎชัด ๆ
• Software 2.0 คือ neural network ที่เรา “program” ผ่าน dataset, objective และ training
• Software 3.0 คือ LLM ที่เรา program ผ่าน prompt และ context window

ประโยคสำคัญคือ ใน Software 3.0, context window กลายเป็น lever ของเรา

พูดแบบง่าย ๆ:

เมื่อก่อนถ้าจะให้คอมพิวเตอร์ทำอะไร เราต้องเขียน code บอกมันทีละขั้น

วันนี้เราเริ่มเขียน “บริบท” ให้ AI เข้าใจ แล้วให้มันใช้ความสามารถของมันจัดการรายละเอียดเอง

Karpathy ยกตัวอย่างการ install software แบบใหม่

ในโลกเดิม เราจะเขียน bash script ยาว ๆ เพื่อรองรับหลาย OS หลาย environment หลาย edge case

แต่ในโลก Software 3.0 บาง tool อาจให้ instruction เป็นข้อความ แล้วบอกว่า “เอาข้อความนี้ไปให้ agent ของคุณ”

จากนั้น agent จะดู environment จริงในเครื่องคุณ ตัดสินใจเองว่าต้องทำอะไร debug เอง และติดตั้งให้เสร็จ

นี่คือการเปลี่ยน mindset ครับ

จาก “เราเขียนทุก step ให้คอมพิวเตอร์ทำ”

เป็น “เราเขียนเจตนาและกรอบงานให้ AI agent เข้าใจ แล้วให้มันปรับกับสถานการณ์จริง”

3) ตัวอย่าง MenuGen: บาง app อาจไม่ต้องมี app แล้ว

ตัวอย่างที่ผมชอบที่สุดในวิดีโอนี้คือเรื่อง MenuGen

Karpathy เล่าว่า เขาเคยสร้าง app ที่ให้ผู้ใช้ถ่ายรูปเมนูร้านอาหาร แล้ว app จะ OCR รายการอาหาร สร้างรูปอาหารประกอบ และ render กลับมาให้ดู

ฟังดูเป็น app ที่ดีมากนะครับ

มี upload มี OCR มี image generation มี UI มี hosting มี integration

แต่ต่อมาเขาเห็นวิธี Software 3.0 ที่ดิบกว่านั้นมาก:

แค่ถ่ายรูปเมนู แล้วให้ Gemini พร้อม Nano Banana ช่วย overlay รูปอาหารลงบนภาพเมนูโดยตรง

จบ

ไม่ต้องมี app ชั้นกลางเยอะเท่าเดิม

อันนี้คือจุดที่เขาบอกว่า app ที่เขาสร้างไว้บางส่วน “ไม่ควรต้องมีอยู่ตั้งแต่แรก”

เพราะ neural network ทำงานดิบ ๆ จาก input ไป output ได้เลย

💡 ในความเห็นของผม นี่คือจุดที่ founder ต้องฟังดี ๆ

AI ไม่ได้ทำให้ software เดิมเร็วขึ้นอย่างเดียว

มันทำให้บาง workflow ไม่ต้องมี software แบบเดิมเลย

บางครั้งสิ่งที่เราคิดว่าเป็น product อาจเป็นแค่ workaround ของยุคก่อน AI

คำถามใหม่จึงไม่ใช่ “จะใช้ AI ช่วย build app นี้เร็วขึ้นได้ไหม”

แต่คือ:

ถ้ามี AI ที่อ่าน input ดิบ ๆ และสร้าง output ดิบ ๆ ได้เลย เราต้องมี app นี้หน้าตาเดิมอยู่ไหม

คำถามนี้โหดครับ

แต่ถ้าตอบได้ จะเจอโอกาสใหม่เยอะมาก

4) Verifiability: งานไหนตรวจได้ งานนั้นจะเร็วขึ้นก่อน

อีกกรอบหนึ่งที่ Karpathy พูดบ่อยคือ verifiability หรือ “ความตรวจได้”

เขาอธิบายว่า software แบบเก่า automate งานที่เรา specify ได้

เช่น งานที่เขียน rule เป็นขั้น ๆ ได้ชัดเจน

แต่ AI รุ่นใหม่ automate งานที่เรา verify ได้

คือถ้าระบบสามารถลองทำหลายครั้ง แล้วมี reward หรือ score บอกได้ว่าแบบไหนถูก แบบไหนดี แบบไหนผ่าน งานนั้นจะถูก optimize ได้เร็วมาก

นี่คือเหตุผลที่ AI เก่งขึ้นเร็วในงานอย่าง math, code, puzzle หรือ domain ที่มีคำตอบตรวจได้

เพราะ model สามารถฝึกกับ environment ที่ reset ได้ ลองซ้ำได้ และให้คะแนนได้

แต่พอเป็นงานที่วัดยาก เช่น strategy, taste, real-world judgment หรือ context ที่ยุ่งเหยิง ความสามารถจะไม่ smooth เท่าเดิม

นี่ทำให้ AI มีลักษณะ “เก่งเป็นหย่อม ๆ”

Karpathy เรียกว่า jagged intelligence

5) Jagged Intelligence: เก่งมาก แต่ยังพลาดแบบเด็กประถมได้

ในวิดีโอ Karpathy ยกตัวอย่างที่ตลกแต่เจ็บมาก

คำถามคือ:

“ผมจะไปร้านล้างรถ ร้านอยู่ห่าง 50 เมตร ควรเดินหรือควรขับรถไป?”

AI รุ่นเก่ง ๆ อาจตอบว่า “เดินสิ ใกล้นิดเดียว”

แต่มนุษย์ฟังแล้วรู้ทันทีว่ามันผิด

เพราะคุณไม่ได้ไป “ร้าน” เฉย ๆ

คุณจะเอา “รถ” ไป “ล้างรถ”

ดังนั้นต้องขับรถไปครับ 555+

นี่คือ jagged intelligence แบบชัดมาก

AI อาจ refactor codebase แสนบรรทัดได้

อาจหาช่องโหว่ security ได้

แต่ก็ยังพลาด common sense ที่มนุษย์รู้จากชีวิตจริง

ประเด็นนี้สำคัญกับธุรกิจมาก

เพราะถ้า AI พลาดในงานเล่น ๆ เราอาจแค่หัวเราะ

แต่ถ้า AI พลาดใน workflow จริง เช่น finance, customer data, security, compliance หรือ production system ความเสียหายไม่ตลกแล้วครับ

6) Vibe Coding vs Agentic Engineering ต่างกันตรงไหน

Karpathy แยกไว้ชัดมาก:

Vibe Coding คือการยกระดับ floor

คนทั่วไปสร้าง software ได้ง่ายขึ้น

คนที่ไม่เคยเขียน code ก็ prototype idea ได้

ทีมเล็กทำของได้เร็วขึ้น

นี่เป็นเรื่องดีมากครับ

แต่ Agentic Engineering คือการรักษา ceiling

โดยเฉพาะในงานมืออาชีพที่ต้องมี quality bar

คุณไม่สามารถพูดว่า “AI เขียนมาแบบนี้ ก็ ship ไปก่อน” ถ้ามันทำให้เกิดช่องโหว่ security หรือระบบพัง

Karpathy พูดตรง ๆ ว่า คุณยังรับผิดชอบ software ของคุณเหมือนเดิม

AI ทำให้คุณเร็วขึ้นได้

แต่ไม่ได้ยกเลิกความรับผิดชอบของคุณ

ผมชอบ framing นี้มาก เพราะมันแยกโลก hobby กับโลก production ออกจากกัน

• ทำ side project: vibe coding ได้ สนุก ลองเร็ว พังได้ไม่เป็นไร
• ทำ product จริง: ต้องมี agentic engineering มี spec, test, review, security, deploy discipline

พูดแบบ Data-Espresso:

Vibe coding คือ “ให้ AI ช่วยสร้างของ”

Agentic engineering คือ “ออกแบบโรงงานที่มี AI เป็นพนักงานหลายคน แล้วคุณยังคุมมาตรฐานได้”

7) Skill ใหม่ของมนุษย์: spec, taste, oversight และ understanding

คำถามสำคัญคือ ถ้า AI เขียน code ได้มากขึ้น มนุษย์ต้องเก่งอะไรแทน?

Karpathy ตอบชัดว่า มนุษย์ยังต้องถือเรื่อง:

• aesthetics
• judgment
• taste
• oversight
• high-level design
• fundamentals

เขาเล่าตัวอย่าง bug หนึ่งที่ดีมาก

ใน project หนึ่ง ผู้ใช้ login ด้วย Google แต่จ่ายเงินผ่าน Stripe

ทั้ง Google และ Stripe มี email

agent เลยพยายามจับคู่ user โดยดู email

ฟังเผิน ๆ เหมือนสมเหตุสมผล

แต่ในโลกจริง คนอาจใช้ email หนึ่งสมัคร Google และอีก email จ่ายเงินผ่าน Stripe

ถ้าไม่มี persistent user ID ระบบอาจผูกเงินกับบัญชีผิดได้

นี่ไม่ใช่ syntax bug

นี่คือ design bug

และเป็น bug แบบที่ AI อาจไม่รู้ว่าตัวเองทำอะไรน่ากลัวอยู่

มนุษย์จึงต้องเข้าใจ business logic และ data model มากพอที่จะถามว่า:

“ทำไมเราเอา email มาเป็น identity หลัก?”

“ถ้าลูกค้าใช้คนละ email จะเกิดอะไรขึ้น?”

“เงินจะผูกกับบัญชีผิดไหม?”

คำถามแบบนี้แหละครับที่ยัง outsource ไม่ได้ง่าย

8) Agent ไม่ใช่สัตว์ แต่เป็น ghost

Karpathy ยังพูดถึง framing ที่เขาเขียนไว้ก่อนหน้านี้ว่า LLM ไม่ใช่ animal intelligence

มันไม่ใช่สัตว์ที่มีแรงขับ มีร่างกาย มี curiosity มี survival instinct หรือเรียนรู้ต่อเนื่องจากโลกเหมือนมนุษย์และสัตว์

เขาเปรียบว่าเรากำลัง “summon ghosts”

คือเรียกผีของความรู้และ pattern จากข้อมูลมหาศาลออกมาใช้งาน

ฟังดู poetic แต่มีผลทางการออกแบบระบบครับ

เพราะถ้าคุณคิดว่า AI เป็นคนหรือสัตว์ คุณอาจเผลอคาดหวังผิด

เช่น คิดว่าดุมันแล้วมันจะทำดีขึ้น

หรือคิดว่ามัน “เข้าใจ” เหมือนมนุษย์

แต่ถ้าคุณมองว่า AI เป็น ghost ที่ถูก shape ด้วย data, reward function และ training distribution คุณจะระวังมากขึ้น

คุณจะถามว่า:

• งานนี้อยู่ใน distribution ที่ model เก่งไหม
• output ตรวจได้ไหม
• มี judge หรือ test ไหม
• ถ้าพลาด จะรู้ได้ยังไง
• มันเห็น context ครบไหม

นี่คือมุมมองที่ practical กว่ามากสำหรับคนทำ AI workflow จริง

9) Agent-native world: ทุกอย่างต้องเขียนใหม่ให้ agent ใช้ได้

ช่วงท้าย Karpathy พูดถึงโลกที่ environment, tool, docs และ infrastructure ต้องกลายเป็น agent-native

วันนี้หลายอย่างยังถูกออกแบบให้ “มนุษย์อ่านแล้วมนุษย์ไปทำ”

เช่น docs บอกให้เราเข้าเว็บ ไปกดปุ่ม ไปตั้งค่า DNS ไป copy ค่าโน่นนี่

แต่ถ้าโลกต่อไปมี agent ทำงานแทนเรา docs ที่ดีอาจต้องตอบคำถามใหม่:

“ข้อความไหนที่ copy ไปให้ agent แล้วมันทำงานให้จบได้?”

นี่ตรงกับ pain ของหลายทีมมากครับ

AI เขียน code เร็วขึ้นแล้ว

แต่ deployment, credential, permission, setting, DNS, API key, environment config ยังเป็นคอขวด

ในโลก agent-native เราอาจต้องออกแบบระบบใหม่ให้ agent อ่านง่าย ทำง่าย และตรวจง่าย

ไม่ใช่แค่คนอ่านง่าย

สำหรับ SME หรือทีมเล็ก บทเรียนคือ:

ถ้าคุณอยากใช้ AI automation จริง ให้เริ่มเก็บ knowledge ของบริษัทให้เป็นระเบียบ

ทำ SOP ที่ชัด

ทำ checklist ที่ agent อ่านได้

ทำ data structure ที่ไม่คลุมเครือ

ทำ permission ให้ชัดว่า agent ทำอะไรได้ ทำอะไรไม่ได้

เพราะ agent ที่เก่งมาก แต่เจอระบบรก ๆ จะกลายเป็นพนักงานเก่งที่หลงทางในห้องเก็บของครับ

10) “Outsource thinking ได้ แต่ outsource understanding ไม่ได้”

ประโยคที่ผมชอบที่สุดอยู่ช่วงท้าย:

You can outsource your thinking, but you can’t outsource your understanding.

แปลแบบง่าย ๆ คือ คุณให้ AI ช่วยคิด ช่วยร่าง ช่วยลอง ช่วยคำนวณ ช่วยเขียน ช่วย simulate ได้

แต่สุดท้ายคุณยังต้องเข้าใจเองว่า:

• เรากำลังสร้างอะไร
• ทำไปทำไม
• output ที่ดีหน้าตาเป็นอย่างไร
• trade-off อยู่ตรงไหน
• ถ้าระบบพัง ความเสียหายคืออะไร
• อะไรที่ไม่ควร delegate

ถ้าคุณไม่เข้าใจ คุณจะไม่ได้เป็นผู้กำกับ AI

คุณจะเป็นแค่คนกด approve งานของ AI

และในโลกที่ AI ทำงานได้เร็วมาก การ approve แบบไม่เข้าใจอาจอันตรายกว่าการทำช้าเสียอีก

💡 ในความเห็นของผม นี่คือ core skill ของ founder และผู้บริหารในยุค AI

ไม่ใช่ต้องเขียน code เองทุกบรรทัด

ไม่ใช่ต้องรู้ API ทุกตัว

แต่ต้องมี enough understanding เพื่อออกแบบงาน ถามคำถามถูก ตรวจ output ได้ และไม่โดน AI พาไปผิดทางเร็วเกินไป

สำหรับธุรกิจไทย ควรเอาไปใช้อย่างไร

ถ้าคุณเป็นเจ้าของธุรกิจหรือผู้บริหาร ผมไม่อยากให้ดูเรื่องนี้เป็นเรื่อง developer ล้วน ๆ

เพราะ pattern เดียวกันจะเกิดกับงานอื่นด้วย

วันนี้อาจเริ่มจาก code

แต่พรุ่งนี้คือ marketing, sales, finance, HR, customer support, operations และ strategy

ถ้าจะใช้ AI agent จริง ให้เริ่มจาก 5 คำถามนี้:

1. งานนี้ตรวจผลลัพธ์ได้ไหม
2. ถ้า AI ทำผิด จะรู้เร็วแค่ไหน
3. AI เห็นข้อมูลอะไรได้บ้าง
4. AI ทำ action อะไรได้บ้าง
5. มนุษย์คนไหนถือภาพใหญ่และเป็นคนตัดสินใจสุดท้าย

ถ้าตอบ 5 ข้อนี้ไม่ได้ อย่าเพิ่ง scale agent เยอะครับ

ไม่ใช่เพราะ AI ไม่ดี

แต่เพราะ operating model ยังไม่พร้อม

#สรุป

ผมมองว่า vibe coding เป็นจุดเริ่มต้นที่ดีมาก

มันทำให้คนจำนวนมากกล้าสร้างของ

แต่ยุคถัดไปจะไม่ได้ชนะกันที่ “ใครปล่อยให้ AI เขียนเยอะกว่า”

จะชนะกันที่ “ใครออกแบบระบบทำงานกับ AI agent ได้ดีกว่า”

Agentic Engineering จึงไม่ใช่คำเท่ ๆ สำหรับ developer เท่านั้น

มันคือวินัยใหม่ของการบริหารงานที่มี AI เป็นแรงงานดิจิทัล

ต้องเร็วขึ้น

แต่ต้องไม่มั่วขึ้น

ต้อง delegate มากขึ้น

แต่ต้องไม่เข้าใจน้อยลง

และถ้าจะสร้างบริษัทแบบ 1 Human + 100 AI Agents จริง ๆ

อย่าเริ่มจากการหา agent เพิ่มอย่างเดียวครับ

เริ่มจากการถามว่า:

เรามี spec, test, permission, review และ understanding พอจะคุม agent เหล่านั้นหรือยัง

เพราะ AI อาจเขียน code ให้เราได้

แต่พวงมาลัยยังควรอยู่ในมือคนที่เข้าใจเส้นทางครับ

ดื่มหนึ่งช็อตความรู้ ย่อยง่าย ใช้ได้เลย ☕