เกริ่นก่อน: ทำไมคุยเรื่อง Software 3.0 ถึงโคตรคุ้มเวลา
ช่วงนี้มีวิดีโอบรรยายเรื่อง AI ที่มาแรงมาก และเนื้อหาก็คมจนต้องหยุดงานมานั่งดูให้จบ แล้วเอามาสรุปแบบย่อยง่ายสไตล์สายเขียนโค้ดด้วย AI เพราะมันช่วยให้เราเห็นภาพอนาคตของการพัฒนา software ชัดขึ้นเยอะว่า โลกของคนเขียนโค้ดกำลังจะเปลี่ยนไปยังไง
หัวใจของการบรรยาย คือมุมมองของ Andrej Karpathy ต่อ Software 3.0, บทบาทของ LLM, แนวคิด partial automation และคำว่า vibe coding ที่เขาเป็นคนจุดกระแสเอง
Karpathy คือใคร และทำไมวงการ AI ถึงต้องฟังเขา
ก่อนจะไปถึง Software 3.0 มารู้จักคนพูดกันสักนิดว่าเขาไม่ใช่คนธรรมดาแน่นอน
ศิษย์เก่าของ Fei-Fei Li ที่ Stanford สายคอมวิชั่นและดีปเลิร์นนิงตัวจริง
หนึ่งในผู้ร่วมก่อตั้ง OpenAI ตั้งแต่ยุคแรกเริ่มของบริษัท
เคยไปคุมทีม Autopilot / รถยนต์ไร้คนขับของ Tesla
ปัจจุบันออกมาทำบริษัทของตัวเองชื่อ Eureka Labs เน้นสอนและสร้างของด้าน AI
เป็นเจ้าของคำยอดฮิตอย่าง “vibe coding” ที่คนวงการเอาไปใช้กันทั่ว
ด้วยประสบการณ์ทั้งสายวิจัย สตาร์ตอัป และของจริงในอุตสาหกรรม คำที่เขาพูดเลยไม่ได้เป็นแค่ทฤษฎีสวยๆ แต่คือสิ่งที่เขาเคยลงมือทำมาแล้ว
1. Software 1.0 → 2.0 → 3.0: วิวัฒนาการของการเขียนโปรแกรม
Karpathy เริ่มจากการเล่า framework ง่ายๆ แต่โคตรเวิร์กในการมองโลกซอฟต์แวร์แบ่งเป็น 3 ยุค
Software 1.0: การเขียนโค้ดแบบคลาสสิก
เราเป็นคนเขียน logic ทีละบรรทัด
คิดทุก if-else, loop, structure ด้วยตัวเอง
Software 2.0: เขียนซอฟต์แวร์ด้วย weight ของ neural network
แทนที่เราจะกำหนดกติกาละเอียดยิบ เราให้ข้อมูล แล้วให้โมเดลเรียนรู้ weight เอง
ตัวอย่างคือยุค image recognition, โมเดล vision ต่างๆ ที่เราเทข้อมูลให้ แล้วใช้การเทรนแทนการเขียน rule
Software 3.0: ยุคของ LLM
เราไม่ได้สั่งเครื่องแบบ low-level แล้ว แต่เราเขียน prompt เป็นภาษาคน
จากนั้นปล่อยให้ LLM ไปเขียนโปรแกรมต่อให้เราอีกที
จากประสบการณ์ตอนทำงานที่ Tesla, Karpathy สังเกตว่า โค้ดแบบ 2.0 กินพื้นที่แทน 1.0 มากขึ้นเรื่อยๆ เพราะฉลาดกว่า ปรับตัวได้มากกว่า และตอนนี้ก็เริ่มเข้าสู่ยุคที่ Software 3.0 กำลังกิน 2.0 ต่ออีกชั้น
พูดง่ายๆ คือ:
เมื่อก่อนเราเขียนโค้ดเอง
ต่อมาเราเทรนโมเดล
ตอนนี้เราเริ่มใช้โมเดลให้มาเขียนโค้ด/ออกแบบระบบแทนเราอีกที
2. LLM คือระบบปฏิบัติการรุ่นใหม่ของโลกซอฟต์แวร์
อีกเปรียบเทียบที่น่าสนใจมากคือ Karpathy มองว่า LLM วันนี้ทำตัวเหมือน Operating System (OS) รุ่นใหม่
LLM ไม่ใช่แค่โมเดลตัวเดียวลอยๆ แต่มันเริ่มมี ecosystem ของตัวเอง
มี “ค่าย” ที่เหมือนแพลตฟอร์มปิด เช่น OpenAI, Gemini
มีฝั่งโอเพนซอร์ส เช่น Llama
มีระบบความจำ, input/output, การเชื่อมต่อกับโลกภายนอก
ในยุคของ OS แบบเดิม เราดาวน์โหลด “แอป” มาติดตั้ง แล้วใช้ได้บนหลายระบบปฏิบัติการเหมือนกัน เช่น โปรแกรมตัวหนึ่งมีทั้งบน Windows, macOS, Linux
ในโลกของ LLM ก็มีอะไรคล้ายกัน เช่น
Cursor, เครื่องมือช่วยเขียนโค้ด
สามารถไปรันบน LLM หลายเจ้า: GPT, Gemini, Claude ฯลฯ
แต่ที่น่าสนใจคือ Karpathy บอกว่า ตอนนี้ LLM ในฐานะ OS ยังอยู่ยุค command-line
เรายังต้อง “พิมพ์ข้อความสั่งงาน” เหมือนใช้ terminal
อินเทอร์เฟซที่ลื่นไหลเท่าหรือดีกว่า GUI ยังแทบไม่เกิดขึ้นเลย
นี่แปลว่า โอกาสยังมหาศาล สำหรับคนที่จะออกแบบ UI/UX รุ่นใหม่สำหรับโลกที่มี LLM เป็นแกน
3. LLM ในฐานะ “วิญญาณของผู้คน” (People Spirits)
Karpathy มีคอนเซปต์ที่ฟังแล้วค่อนข้างหลอน แต่จริงมาก คือ
LLMs are people spirits — simulations of people
เขามองว่า LLM คือการจำลองมนุษย์จำนวนมาก อยู่ใน simulator ที่ชื่อว่า Transformer
ถ้าเรามอง LLM เป็น “คน” หนึ่งคน เราจะเห็นคุณลักษณะประมาณนี้
ความรู้และความจำมหาศาล
รู้ข้อมูลมากกว่ามนุษย์คนเดียวจะจำได้ทั้งชีวิต
คล้ายตัวละครแบบ Rainman ที่จำรายละเอียดได้เยอะเกินปกติ
เห็นภาพหลอน (hallucination)
บางทีตอบผิดมั่นใจสุดๆ
หรือสะดุดในโจทย์ง่ายๆ เช่น นับตัว r ในคำว่า strawberry แล้วงง
หลงเชื่อคนง่าย (gullible)
โดน prompt injection ได้ง่าย ถ้าเราไม่ได้ออกแบบระบบกันดีๆ
ความจำสั้นแบบมีกรอบ (amnesia)
ทำงานภายใต้ context window ที่จำกัด ลืมเรื่องก่อนหน้าได้เหมือนคนเป็นโรคความจำเสื่อมชั่วคราว
Karpathy เทียบกับหนังอย่าง Memento หรือ 50 First Dates
เมื่อเราเข้าใจทั้ง ศักยภาพ และข้อจำกัด ของ LLM มากขึ้น คำถามสำคัญคือ:
แล้วเราจะออกแบบการทำงานร่วมกันระหว่างคนกับ LLM ยังไง ให้มันเวิร์กที่สุด?
4. Partial Automation: ให้ AI สร้าง คนตรวจ แล้ววนลูป
คำตอบของ Karpathy ไม่ใช่ “ให้ AI ทำแทนทุกอย่าง” แต่คือแนวคิดที่เขาเรียกว่า partial automation
เขาเสนอการแบ่งหน้าที่แบบง่าย แต่ทรงพลังมาก:
หน้าที่ของ AI คือ “สร้าง” (generation)
หน้าที่ของมนุษย์คือ “ตรวจสอบ” (verification)
แล้วเราก็ออกแบบให้มันกลายเป็น loop ซ้ำๆ
AI สร้าง
คนตรวจ
ปรับ prompt / ปรับโจทย์
ให้ AI สร้างใหม่
ทุกอย่างจะเวิร์กก็ต่อเมื่อ เราออกแบบเครื่องมือให้มนุษย์สามารถตรวจงานของ AI ได้เร็วและชัด ไม่ใช่ปล่อยให้ AI ทำงานยาว แล้วเรามาไล่เช็กทีเดียวตอนจบแบบม้วนเดียวจบ
ตอนนี้ซอฟต์แวร์หลายตัวเริ่มสะท้อนแนวคิดนี้ชัดเจน เช่น
Cursor
Perplexity
Photoshop เวอร์ชันที่มี AI ช่วย
จะเห็นว่าเครื่องมือเหล่านี้มักจะมีสองโหมดอยู่ในตัวเดียวกัน
GUI แบบเดิม สำหรับมนุษย์คลิก สั่งงาน จัดการ
ช่องแชทคุยกับ AI สำหรับให้โมเดลช่วยทำงานบางส่วน
5. Autonomy Slider และ “สายจูง” ของ AI
Karpathy เสนอคอนเซปต์หนึ่งที่ใครทำ product ด้าน AI ควรจำไว้ให้ดี คือ autonomy slider
ไอเดียคือ มนุษย์ควรจะ ตั้งระดับความอิสระของ AI ได้เอง ว่าอยากให้มันทำได้ไกลแค่ไหน
- งานบางอย่างอยากควบคุมละเอียดมาก
เช่น คุยทีละประโยค ขอทีละก้าว
เราใช้แชท ถาม-ตอบ ถี่ๆ
- งานบางอย่างอยากให้ AI ไปไกลเอง
เช่น deep research, ทำรีพอร์ตใหญ่, เขียนโปรแกรมยาวๆ
เราปล่อย autonomy ให้สูงขึ้น ปรับแค่ตอน checkpoint
Karpathy เปรียบเทียบภาพรวมว่า เราไม่ควรปล่อย AI วิ่งเองแบบไร้สายจูง
สิ่งที่เราควรมีคือ tight leash – สายจูงที่แน่นพอ
กำหนด process / workflow ล่วงหน้า
- โดยเฉพาะงานอย่างใช้ AI ช่วยเขียนโค้ด เราต้องออกแบบให้มี
ขั้นตอนสร้าง
ขั้นตอนตรวจ
ขั้นตอนรันเทสต์ / ตรวจความถูกต้อง
แล้ววนลูปได้เร็ว
ภาพที่ Karpathy ย้ำคือ เราไม่ได้สร้าง “หุ่นยนต์ Iron Man” ที่เดินเองได้ทุกอย่าง
แต่เรากำลังสร้าง “ชุดเกราะ Iron Man” ให้มนุษย์ใส่
AI ไม่ได้มาแทนที่เราแบบเต็มตัว
แต่มันกลายเป็น exoskeleton เสริมพลังให้เราไปได้ไกลกว่าเดิม
6. Vibe Coding: เขียนซอฟต์แวร์ด้วยฟีลลิ่ง + AI
มาถึงคำที่สายเขียนโค้ดด้วย AI ต้องโดนใจคือ vibe coding
Karpathy เล่าว่า จริงๆ เขาเรียกคำนี้แบบเล่นๆ แต่ดันกลายเป็นไวรัลเฉย
เบื้องหลังคำนี้คือแนวคิดว่า:
เราควรทำให้กระบวนการสร้างซอฟต์แวร์ เข้าถึงง่ายที่สุด เท่าที่จะทำได้
ไม่จำเป็นต้องเริ่มจากการวาง system design หนา 30 หน้าเสมอไป แต่เริ่มจากไอเดีย + วิธีคุยกับ AI ให้เข้าใจ “ฟีล” ของสิ่งที่อยากสร้าง แล้วค่อย iterate ไปเรื่อยๆ
เขายังโชว์ตัวอย่างเด็กนักเรียนที่ลองสร้างของต่างๆ ด้วยวิธี vibe coding – ใช้ AI เป็นคู่คิด ช่วยเขียนโปรแกรม ทั้งๆ ที่เด็กยังไม่ได้เรียนวิชาคอมพิวเตอร์แบบจริงจัง
อย่างไรก็ตาม Karpathy ก็ย้ำว่า ต่อให้วันนี้ AI เขียนโค้ดได้ง่าย แต่ยังมี “งานบ้าน” อีกเยอะที่มนุษย์ต้องทำเองเสมอ เช่น
ตั้งค่าระบบพื้นฐาน
จดโดเมนเนม
สมัคร / ล็อกอินบริการต่างๆ
จ่ายเงิน, กรอกบัตร, ยืนยันตัวตน ฯลฯ
เขาบอกตรงๆ ว่า บางทีเวลาโดนกินไปกับเรื่องพวกนี้มากกว่าการเขียนโค้ดอีก
7. งานของ Agent: ให้ระบบไปจัดการโลกจริงแทนมนุษย์
จุดนี้เองที่ Karpathy มองว่าเป็นพื้นที่ของ Agent
LLM แบบเดิมเน้นทำงาน “ในหัว AI” เช่น เขียนโค้ด วางแผน ตอบคำถาม
แต่ Agent ถูกออกแบบมาเพื่อ ลงมือทำงานเดิมๆ ในโลกจริงแทนมนุษย์
ไปเปิดเว็บนั้นเว็บนี้
กรอกฟอร์ม
กดปุ่ม จัดการ task ที่มนุษย์เมื่อก่อนต้องทำเอง
เมื่อเรามี Agent มากขึ้น เราจำเป็นต้อง คิดใหม่เรื่องการออกแบบอินเทอร์เฟซและข้อมูล ให้เหมาะกับ AI ด้วย ไม่ใช่แค่กับมนุษย์
ตัวอย่างเช่น
เอกสารคู่มือที่เดิมเขียนให้คนอ่านเริ่มมีเวอร์ชันใหม่ เช่น `llms.txt` ที่ออกแบบมาให้ LLM อ่านและเข้าใจได้ง่าย
เครื่องมืออย่าง GitIngest ที่ช่วยแปลงหน้าเว็บ GitHub (ที่ออกแบบมาเพื่อมนุษย์) ให้กลายเป็นเวอร์ชันที่ LLM ingest ได้สะดวก
พูดอีกแบบคือ ต่อไปเวลาเราเขียนเอกสาร / API / หน้าเว็บ เราอาจต้องถามตัวเองเพิ่มว่า:
มนุษย์อ่านรู้เรื่องไหม?
LLM / Agent อ่านแล้วใช้งานต่อได้ง่ายไหม?
8. แล้วคนสายเขียนโค้ดด้วย AI ควรเอาอะไรไปใช้
การบรรยายของ Karpathy ไม่ได้ลงหมัดที่เทคนิคจ๋า แต่เปลี่ยน “วิธีมองโลก” ของคนทำซอฟต์แวร์ไปไกลมาก
สิ่งที่เอามาใช้ได้ทันที โดยเฉพาะถ้าเราชอบเขียนโค้ดกับ AI มีอย่างน้อย 4 ข้อ:
คิดเป็น Software 3.0
อย่ามองแค่ “ใช้ AI ช่วยเขียนโค้ด” แต่คิดว่าตัวเองกำลังสร้างระบบที่มนุษย์ + LLM ทำงานร่วมกัน
ออกแบบ loop ระหว่างการสร้างและการตรวจ
ให้ AI generate แล้วเราตรวจ ไม่ใช่ปล่อย AI ยาวๆ แล้วมาหงุดหงิดทีหลัง
ใช้ tight leash กับงานสำคัญ
ยิ่งงานเสี่ยงสูง ยิ่งต้องกำหนดขั้นตอน ตรวจบ่อย ตั้ง autonomy slider ให้ต่ำลง
ฝึก vibe coding ให้คล่อง
อธิบายฟีล, ความต้องการ, ขอบเขต ให้ AI เข้าใจ แล้ว iterate
ใช้มันเป็นชุดเกราะ Iron Man ไม่ใช่หวังจะให้มันมาทำงานแทนทั้งหมด
ท้ายที่สุด มุมมองเรื่อง LLM ในฐานะ “วิญญาณของผู้คน” ทำให้เราไม่หลงเชื่อมันเกินไป ไม่กลัวมันจนเกินไป และรู้ว่าจะใช้มันยังไงให้คุ้มที่สุดในฐานะคนเขียนโค้ดยุคใหม่
ถ้าคุณกำลังเขียนโค้ดด้วย AI อยู่ทุกวัน การเข้าใจ mindset แบบ Software 3.0 อาจเป็นจุดเปลี่ยนของทั้ง workflow และอาชีพของคุณได้เลย