แถลงการณ์ปฏิวัติซอฟต์แวร์ของ Andrej Karpathy
บทความนี้วิเคราะห์เชิงลึกการบรรยายฉบับเต็มของ Andrej Karpathy ใน Sequoia AI Ascent 2026 Karpathy เสนอแนวคิด Software 3.0 -- LLM ไม่ใช่เครื่องมือที่เร็วขึ้น แต่เป็นคอมพิวเตอร์ชนิดใหม่ทั้งหมด การเขียนโปรแกรมเปลี่ยนจาก "เขียนโค้ด" เป็น "เขียน context" เขาเล่าประสบการณ์ตรงที่แอป Menu Gen ถูก prompt Gemini คำเดียวแทนที่ -- พิสูจน์ว่าชั้น application ทั้งหมดอาจไม่จำเป็นต้องมี เขาแยกความแตกต่างระหว่าง Vibe Coding (ยกพื้น ให้ทุกคนเขียนโปรแกรมได้) กับ Agentic Engineering (ดันเพดาน ให้วิศวกรมืออาชีพเร่ง 10 เท่าขึ้นไป) และเสนอ "กรอบความสามารถในการตรวจสอบ" อธิบายว่าทำไม AI ถึงรุดหน้าในคณิตศาสตร์และโค้ด แต่กลับบอกให้คุณเดินไปร้านล้างรถ 50 เมตร ข้อมูลเชิงลึกที่ลึกซึ้งที่สุด: ความเข้าใจ outsource ไม่ได้ นี่คือป้อมปราการสุดท้ายของมนุษย์ในยุค AI
เพื่อเข้าใจสิ่งที่ Karpathy พูด คุณต้องเข้าใจการเปลี่ยนแปลงพื้นฐาน 3 ครั้งของซอฟต์แวร์ก่อน นี่ไม่ใช่การอัพเกรดเวอร์ชัน แต่เป็นการเปลี่ยนธรรมชาติของแนวคิดการคำนวณ
ตั้งแต่ทศวรรษ 1950 จนถึงปัจจุบันยังเป็นหลัก วิศวกรใช้ C, Python, Java เขียนคำสั่งที่แม่นยำทีละบรรทัด คอมพิวเตอร์ทำตามอย่างเคร่งครัด ไม่มี "ความเข้าใจ" คุณต้องบอกมันทุกขั้นตอนอย่างแม่นยำ
Karpathy เสนอแนวคิดนี้ในปี 2017 การเปลี่ยนแปลงหลัก: การเขียนโปรแกรมไม่ใช่การเขียนโค้ดอีกต่อไป แต่เป็นการจัดเรียงชุดข้อมูลและออกแบบเป้าหมายการฝึก คุณไม่ต้องบอกคอมพิวเตอร์ว่าจะรู้จำแมวอย่างไร คุณให้รูปแมว 1 ล้านรูป แล้วให้โครงข่ายประสาทเรียนรู้เอง โปรแกรมเมอร์กลายเป็นภัณฑารักษ์ข้อมูลและสถาปนิกโครงข่ายประสาท
นี่คือสิ่งที่กำลังเกิดขึ้นในปี 2025-2026 Karpathy พูดตรงๆ:
เขาใช้ขั้นตอนติดตั้ง OpenClaw (เครื่องมือ AI coding) เป็นตัวอย่าง: ในความคิดแบบเดิม คุณจะคาดหวัง shell script ในการติดตั้ง แต่ shell script จะซับซ้อนมากเมื่อเจอแพลตฟอร์มและการตั้งค่าเครื่องที่ต่างกัน ในแนวคิด Software 3.0 วิธีติดตั้งกลายเป็นข้อความอธิบาย คุณคัดลอกวางให้ AI agent แล้ว agent จะติดตั้ง แก้ไขข้อผิดพลาด จนทุกอย่างทำงานได้ตามสภาพแวดล้อมของคุณ
ความแตกต่างหลักของ 3 ยุคไม่ใช่ความเร็ว แต่เป็นการกระโดดของระดับ abstraction
ทุกครั้งที่กระโดด รายละเอียดที่มนุษย์ต้องควบคุมลดลงหนึ่ง order of magnitude แต่วิจารณญาณและความเข้าใจที่ต้องการเพิ่มขึ้นหนึ่ง order of magnitude
Karpathy เล่าตัวอย่างที่ทำให้ตัวเขาเองตกใจ เขาใช้เวลามาก vibe code แอป Menu Gen -- ถ่ายรูปเมนูร้านอาหาร OCR อ่านชื่อเมนู ใช้ image generator สร้างรูปอาหารแต่ละจาน deploy บน Vercel แอป Software 1.0 + 2.0 ผสมกันอย่างสมบูรณ์
แล้วเขาเห็น Software 3.0 version: โยนรูปเมนูให้ Gemini สั่งคำเดียว AI ก็ render รูปอาหารบนรูปเมนูต้นฉบับทันที ไม่ต้องมีแอป ไม่ต้องมี backend ไม่ต้อง deploy
Software 3.0 ไม่ใช่ทำให้คุณเขียนโปรแกรมเร็วขึ้น แต่ทำให้บางโปรแกรมไม่ต้องมีเลย นี่คือคำเตือนระดับเอาตัวรอดสำหรับผู้สร้าง SaaS ทุกคน: แอปของคุณเป็นแค่กาวเชื่อมระหว่างความสามารถของ LLM สองอย่างหรือเปล่า? ถ้าใช่ คูน้ำป้อมปราการของคุณเท่ากับศูนย์
Karpathy สร้างคำว่า "Vibe Coding" ขึ้นในต้นปี 2025 และบนเวที Sequoia ปี 2026 เขาทบทวนวิวัฒนาการของแนวคิดนี้
เขาเล่าประสบการณ์ตรง: ธันวาคม 2025 คือจุดหักเหที่ชัดเจน ก่อนหน้านี้ AI coding tools เขียนโค้ดที่ "บางทีผิด ต้องแก้" แต่พอถึงธันวาคม กับโมเดลล่าสุด "โค้ดถูกต้อง ฉันขอเพิ่ม มันก็ยังถูกต้อง จำไม่ได้ว่าแก้ครั้งสุดท้ายเมื่อไหร่"
แล้วเขาก็เริ่ม vibe coding -- ทั้งห้องหัวเราะ
คีย์เวิร์ด: พื้น Vibe coding ให้คนที่ไม่รู้เรื่องการเขียนโปรแกรมเลยสร้างแอปซอฟต์แวร์ได้ นักการตลาดทำ dashboard ข้อมูลได้ นักออกแบบทำ interactive prototype ได้ ครูเกษียณทำ knowledge base ส่วนตัวได้ นี่คือประชาธิปไตย คือการทำให้แพร่หลาย คือการยกพื้นทั้งหมด
แต่ Karpathy พลิกมุม ชี้ด้านมืดของ vibe coding:
Vibe Coding ปลดปล่อยอุปสรรคของ "การทำ" แต่ไม่ได้ลดอุปสรรคของ "การทำให้ดี" ใครก็ใช้ AI เขียนเว็บที่ทำงานได้ แต่การเขียนระบบที่ปลอดภัย มีประสิทธิภาพ บำรุงรักษาได้ ยังต้องการความเข้าใจเชิงวิศวกรรมที่ลึกซึ้ง นี่คือเหตุผลที่ต้องมี Agentic Engineering
ถ้า Vibe Coding ยกพื้น Agentic Engineering ก็ดันเพดาน Karpathy แยกสองสิ่งนี้ชัดเจน:
วงการซอฟต์แวร์มีคำว่า "10x engineer" มานาน -- วิศวกรระดับท็อปมีผลิตภาพ 10 เท่าของวิศวกรธรรมดา Karpathy เชื่อว่าในยุค agentic ช่องว่างนี้ถูกขยายใหญ่ขึ้นไปอีก:
Karpathy อธิบายภาพ agentic engineer ในอุดมคติ:
Karpathy พูดตรงๆ ว่ากระบวนการสรรหาของบริษัทส่วนใหญ่ยังอยู่ในแนวคิดเก่า:
มิติใหม่ของช่องว่างความสามารถ ในยุค agentic ช่องว่างระหว่างวิศวกรไม่ใช่ "ความเร็วในการเขียนโค้ด" อีกต่อไป แต่เป็น "ความสามารถในการสั่งการ AI" ใช้ Claude Code เหมือนกัน คนหนึ่งอาจแค่ให้ AI เขียนฟังก์ชันเดียว อีกคนอาจสั่งการ 15 สายงานแบบขนานพร้อมกันจนระบบทั้งหมดเสร็จ คนหลังอาจมีผลิตภาพ 100 เท่าของคนแรก นี่คือความท้าทายพื้นฐานต่อการออกแบบองค์กร โครงสร้างเงินเดือน การประเมินผลงาน
นี่คือส่วนที่มีความลึกเชิงวิเคราะห์มากที่สุดของการบรรยาย Karpathy เสนอกรอบที่กระชับแต่ทรงพลังเพื่อเข้าใจการกระจายตัวที่ไม่สม่ำเสมอของความสามารถ AI:
คอมพิวเตอร์แบบเดิมทำให้ "สิ่งที่คุณกำหนดด้วยโค้ดได้" เป็นอัตโนมัติได้ง่าย LLM ทำให้ "สิ่งที่คุณตรวจสอบผลลัพธ์ได้" เป็นอัตโนมัติได้ง่าย
ความเร็วออโตเมชัน = f(ความสามารถในการตรวจสอบ + ความสนใจของห้องปฏิบัติการ)
Karpathy ใช้ตัวอย่างที่ทำให้ทั้งห้องหัวเราะ:
ทำไมถึงเป็นแบบนี้? Karpathy อธิบายว่ามีสองปัจจัย:
ห้องปฏิบัติการ AI ชั้นนำฝึก LLM ด้วย reinforcement learning (RL) ขนาดใหญ่ RL ต้องการ "reward ในการตรวจสอบ" -- ทำถูกได้ feedback บวก ทำผิดได้ feedback ลบ ในด้านโค้ด การตรวจสอบเป็นธรรมชาติ: test ผ่าน = ถูก compile ไม่ผ่าน = ผิด ในคณิตศาสตร์ก็เหมือนกัน: คำตอบถูก = ถูก ผิด = ผิด
แต่ "ร้านล้างรถ 50 เมตรควรขับรถหรือเดินไป?" ตรวจสอบได้อย่างไร? ไม่มี test ให้รัน ไม่มีถูกผิดชัดเจน -- มีแต่สามัญสำนึก และสามัญสำนึกไม่อยู่ในการกระจายของการฝึก RL
Karpathy เปิดเผยข้อเท็จจริงที่สำคัญแต่น้อยคนจะพูดถึง: การกระจายความสามารถของ AI ไม่ได้ขึ้นกับเทคโนโลยีเพียงอย่างเดียว แต่ยังขึ้นกับห้องปฏิบัติการเลือกจะให้ความสนใจอะไร เขายกตัวอย่าง GPT-3.5 ถึง GPT-4 ที่ความสามารถหมากรุกดีขึ้นอย่างมาก -- ไม่ใช่เพราะโมเดลเก่งขึ้นโดยรวม แต่เพราะ "มีคนที่ OpenAI ตัดสินใจใส่ข้อมูลหมากรุกจำนวนมากในชุดข้อมูล pre-training"
| สาขา | ความสามารถในการตรวจสอบ | ความเร็วออโตเมชัน AI | เหตุผล |
|---|---|---|---|
| โค้ด | สูงมาก | เร็วมาก | test ผ่าน / compile สำเร็จ |
| การพิสูจน์ทางคณิตศาสตร์ | สูงมาก | เร็วมาก | การตรวจสอบเชิงรูปนัย |
| เอกสารกฎหมาย | ค่อนข้างสูง | เร็ว | อ้างอิงคำพิพากษาและกฎหมายได้ |
| งานเขียน | ปานกลาง | ปานกลาง | ใช้คณะกรรมการ LLM ได้ แต่เชิงอัตนัยสูง |
| สุนทรียะการออกแบบ | ต่ำ | ช้า | ไม่มี reward function สำหรับสุนทรียะ |
| วิจารณญาณเชิงสามัญสำนึก | ต่ำมาก | ช้ามาก | "เดิน 50 เมตรไปล้างรถ" ตรวจสอบไม่ได้ |
ถ้าคุณสร้างสภาพแวดล้อม RL ที่ตรวจสอบได้สำหรับสาขาของคุณ คุณก็มี leverage ทางเทคโนโลยี แม้ห้องปฏิบัติการชั้นนำไม่สนใจสาขาของคุณ คุณก็ยัง fine-tune และสร้าง RL environment ของคุณเองให้ AI ถึงระดับผู้เชี่ยวชาญในสาขาเฉพาะได้ Karpathy บอกเป็นนัยว่าเขารู้ว่าโอกาสแบบนี้มีอยู่ แต่ไม่อยากเปิดเผยบนเวที -- "I don't want to vague post" แต่ทั้งห้องหัวเราะ
การบรรยายของ Karpathy เน้นกรอบแนวคิด แต่ในงาน Sequoia AI Ascent 2026 เดียวกัน Boris Cherny ผู้สร้าง Claude Code มีกรณีศึกษาเชิงปฏิบัติที่พิสูจน์ทฤษฎีของ Karpathy อย่างสมบูรณ์
Boris Cherny แชร์วิธีทำงานของเขา: วิศวกรคนเดียวสั่งการ 10 ถึง 15 สาย AI workflow แบบขนานพร้อมกัน นี่ไม่ใช่ทฤษฎี แต่คือสภาพการทำงานจริงทุกวัน
การปฏิบัติจริงของ Karpathy และ Cherny ชี้ไปที่ข้อสรุปเดียวกัน: context คือโค้ดของยุค Software 3.0
ในอดีต วิศวกรลงทุนเวลาในการเชี่ยวชาญ syntax และ framework ของภาษาโปรแกรม ตอนนี้การลงทุนที่ให้ผลตอบแทนสูงสุดคือ:
Karpathy ยังบอกว่า ความหงุดหงิดที่สุดในการใช้ library ของคนอื่นไม่ใช่โค้ดซับซ้อน แต่คือ "เอกสารยังเขียนให้คนอ่าน":
เมื่อกลุ่มเป้าหมายของเอกสารเปลี่ยนจาก "นักพัฒนามนุษย์" เป็น "AI agent" เครื่องมือพัฒนาทั้งหมดต้องเขียนใหม่ นี่คือโอกาสระดับล้านล้านในการสร้าง DevTools ecosystem ใหม่ -- จาก CLI ไปถึง API docs ไปถึง deployment flow ทุกอย่างต้องเป็น "agent-native"
ช่วงเวลาที่ลึกซึ้งที่สุดของการบรรยาย เกิดขึ้นตอนคำถามสุดท้ายเรื่องการศึกษา พิธีกรถาม: เมื่อปัญญาราคาถูก อะไรยังคุ้มค่าที่จะเรียนรู้เชิงลึก?
Karpathy อ้างทวีตที่ทำให้เขา "คิดถึงทุกๆ วันเว้นวัน":
จากนั้นเขาอธิบายเชิงลึก:
นี่ไม่ใช่เล่นคำ Karpathy แยกกิจกรรมทางปัญญา 2 ประเภท:
Karpathy ยังพูดถึงบทความที่เขาเขียน -- "เราไม่ได้เลี้ยงสัตว์ เรากำลังเรียกผีปีศาจ" สัตว์ (ปัญญาชีวภาพ) ถูกหล่อหลอมโดยวิวัฒนาการ -- มีความอยากรู้ มีแรงจูงใจ มีสัญชาตญาณเอาตัวรอด AI (ปัญญาผีปีศาจ) ถูกหล่อหลอมโดยข้อมูลและ reward function -- ไม่มีแรงจูงใจภายใน ไม่มีความอยากรู้ ไม่มีความเห็นอกเห็นใจ
เขายอมรับว่ากรอบนี้ "อาจเป็นแค่ปรัชญา" แต่ข้อความหลักเป็นเชิงปฏิบัติ: อย่าปฏิบัติกับ AI เหมือนสัตว์ ตะโกนใส่มันไม่ทำให้มันทำงานดีขึ้นหรือแย่ลง พวกมันเป็นวงจรจำลองทางสถิติ -- pre-training เป็นฐานสถิติ RL เป็นส่วนที่ยื่นออกมา
ความเข้าใจคือป้อมปราการสุดท้ายของมนุษย์ในยุค AI เพราะความเข้าใจตรวจสอบไม่ได้
RL สามารถปรับปรุงได้เฉพาะความสามารถที่ตรวจสอบได้ ความเข้าใจ -- อะไรคือความงาม อะไรคุ้มค่าทำ อะไรคือทิศทางที่ถูกต้อง -- ไม่มี verification function ง่ายๆ นี่คือผลสรุปสุดท้ายของกรอบความสามารถในการตรวจสอบของ Karpathy: AI ปรับตัวเร็วที่สุดในจุดที่มนุษย์ต้องการน้อยที่สุด (เพราะ AI ดีพอแล้ว) AI ปรับตัวช้าที่สุดในจุดที่มนุษย์ต้องการมากที่สุด
แท่นพิมพ์ Gutenberg ทำให้นักคัดลอกตกงาน แต่มันไม่ได้แทนที่ผู้แต่ง -- มันแทนที่คนที่คัดลอกเนื้อหา ไม่ใช่คนที่สร้างเนื้อหา มูลค่าของผู้แต่งกลับเพิ่มขึ้นเพราะต้นทุนการเผยแพร่ลดลง
VisiCalc และ Lotus 1-2-3 กำจัดงานเอกสารบัญชีจำนวนมาก แต่ความต้องการ CFO กลับเพิ่ม -- เพราะเมื่อการคำนวณเสร็จในพริบตา คุณค่าของการตัดสินใจก็เด่นชัดขึ้น
CAD แทนที่ช่างเขียนแบบมือ สถาปนิกไม่ได้หายไป -- ความสามารถด้านการออกแบบถูกขยาย 10 เท่า คนที่หายไปคือ "คนที่แปลงร่างของนักออกแบบเป็นแบบแม่นยำ"
Kodak ล้มละลายปี 2012 ช่างล้างฟิล์ม ช่างห้องมืดหายหมด แต่ช่างภาพไม่เพียงไม่หาย ยังเข้าสู่ยุคทองด้วย Instagram คนที่หายไปคือสื่อกลาง ไม่ใช่สายตา
AI กำลังแทนที่ "คนเขียนโค้ด" แต่เหมือนทุกครั้งที่เครื่องมือปฏิวัติ -- สิ่งที่หายไปคือชั้นลงมือทำ สิ่งที่เหลือคือชั้นความเข้าใจ
สูตรของทุกการปฏิวัติเครื่องมือเหมือนกัน: ต้นทุนการทำ -> เข้าใกล้ศูนย์ มูลค่าวิจารณญาณ -> เข้าใกล้อนันต์ ในยุคแท่นพิมพ์ วิจารณญาณคือ "เขียนอะไร" ในยุค spreadsheet วิจารณญาณคือ "คำนวณแล้วตัดสินใจอย่างไร" ในยุค Software 3.0 วิจารณญาณคือ "ให้ AI ทำอะไร" และ "สิ่งที่ AI ทำออกมาถูกต้องไหม คุ้มค่าไหม" "ความเข้าใจ outsource ไม่ได้" ของ Karpathy คือการแสดงออกล่าสุดของกฎประวัติศาสตร์นี้ในยุค AI
ถ้า agentic engineer มีผลิตภาพเกิน 10 เท่า ทีม agentic 5 คนอาจเท่ากับทีม 50-100 คนในอดีต นี่ไม่ใช่อนาคตไกล -- Boris Cherny ปฏิบัติทุกวันแล้ว ผู้ประกอบการต้องถามตัวเอง: ฉันต้องการ coder 50 คน หรือ agentic engineer 5 คน?
Karpathy พูดชัด: ออกโจทย์ปริศนาเล็กๆ คืออดีต การสรรหาใหม่ควรเป็น: ให้โปรเจกต์ใหญ่ ดูว่าผู้สมัครสั่งการ AI ทำเสร็จอย่างไร สิ่งที่ประเมินเปลี่ยนจาก "คุณแก้ปัญหานี้ได้ไหม" เป็น "คุณสั่ง AI ให้แก้ปัญหาอย่างปลอดภัย มีประสิทธิภาพ บำรุงรักษาได้ไหม" สิ่งที่ตรวจสอบหลักคือวิจารณญาณ รสนิยม และความสามารถในการออกแบบระบบ -- ไม่ใช่ความสามารถในการท่อง API
ปฏิทรรศน์ Menu Gen คือการตบหน้าผู้สร้าง SaaS ทุกคน ถามตัวเอง: ผลิตภัณฑ์ของฉันเป็นแค่กาวเชื่อมระหว่างความสามารถ AI สองอย่างหรือไม่? ถ้า AI ทำจากอินพุตถึงเอาต์พุตโดยตรงได้ ชั้น application ตรงกลางก็ไม่จำเป็นต้องมี คูน้ำป้อมปราการที่แท้จริงคือ:
วิสัยทัศน์ของ Karpathy ชัดเจน: อนาคตเอกสาร API เครื่องมือทั้งหมดควรเป็น "agent-first" -- ออกแบบให้ AI ก่อน แล้วค่อยออกแบบให้มนุษย์ นี่คือโอกาสมหาศาลในการสร้างโครงสร้างพื้นฐานใหม่ อุดมคติของ Karpathy: "ให้ LLM prompt คำเดียวว่า 'สร้าง Menu Gen' แล้วไม่ต้องแตะอะไรเลย มัน deploy ขึ้นเว็บเอง" ยังห่างจากอุดมคตินี้มาก แต่ทิศทางชัดแล้ว
ถ้า Karpathy ถูก -- "ทุกอย่างในท้ายที่สุดจะถูกทำให้เป็นอัตโนมัติ" -- หน้าต่างสำหรับผู้ประกอบการคือช่วงที่ AI ยังไม่เก่งในสาขาของคุณ ใช้ช่วงเวลานี้:
การบรรยายของ Karpathy ไม่ใช่คำทำนาย แต่เป็นการบรรยาย เขาไม่ได้บอกว่า "จะเกิดอะไรขึ้นในอนาคต" แต่บอกว่า "กำลังเกิดอะไรขึ้น"
มาทบทวนภาพชัดเจนที่เขาวาดในการบรรยายนี้:
สุดท้าย Karpathy ก่อนออกจากเวทีในวินาทีสุดท้าย ให้มุมมองเรื่องการศึกษา -- เครื่องมือที่เสริมความเข้าใจคือทิศทางที่น่าสนใจและน่าตื่นเต้นที่สุด โปรเจกต์ LLM knowledge base ของเขาเป็นการปฏิบัติในทิศทางนี้: ไม่ใช่ให้ AI เข้าใจแทนคุณ แต่ให้ AI ช่วย "ฉาย" ข้อมูลจากมุมต่างๆ เพื่อให้คุณได้ข้อมูลเชิงลึกที่ลึกซึ้งขึ้น
ในยุค Software 3.0 สูตรชนะเปลี่ยนแล้ว
สูตรเก่า: วิศวกรที่ดีที่สุด + โค้ดที่ดีที่สุด = ชนะ
สูตรใหม่: ความเข้าใจที่ลึกที่สุด + ความสามารถในการสั่งการ AI ที่ดีที่สุด + การออกแบบความสามารถในการตรวจสอบที่แข็งแกร่งที่สุด = ชนะ
Karpathy ไม่ได้บอกว่าโปรแกรมเมอร์จะหายไป เขาบอกว่า: "การเขียนโค้ด" ในฐานะกิจกรรมจะหายไป แต่ "การเข้าใจระบบ" ในฐานะความสามารถจะมีค่ามากกว่าที่เคยเป็นมา
คุณ outsource ความคิดได้ แต่ outsource ความเข้าใจไม่ได้
แล้ววันนี้ คุณเข้าใจอะไรบ้าง?
ธีมซีรีส์: AGI ไม่ใช่อนาคต แต่คือปัจจุบัน -- และคุณเหลือเวลาแค่ 18 เดือน