Waste Tokens, Save Time: Naval มอง AI Coding อย่างไรในวันที่ซอฟต์แวร์เปลี่ยนเกม
Naval และผู้ก่อตั้งสาย frontier technology แลกเปลี่ยนมุมมองเรื่อง AI coding, การวัดผลวิศวกร และอนาคตของซอฟต์แวร์ โดยประเด็นที่เด่นที่สุดคือแนวคิด “เสีย token เพื่อประหยัดเวลา” และคำถามว่าซอฟต์แวร์แบบเดิมกำลังหมดความได้เปรียบหรือไม่
AI, Software Engineering, Naval, Startups, LLM
ในตอนนี้ของรายการ Naval Podcast, Naval ชวนผู้ก่อตั้ง 3 บริษัทแนว frontier technology มาคุยกัน ไม่ใช่เพื่อเล่าว่าบริษัทของแต่ละคนสร้างอะไร แต่เพื่อถามว่า พวกเขาเรียนรู้อะไรจากการสร้างสิ่งใหม่ โดยช่วงที่น่าสนใจที่สุดอยู่ที่บทสนทนาเรื่อง AI software factories, วิธีใช้โมเดลเขียนโค้ดให้คุ้มค่า และคำถามใหญ่ต่ออนาคตของธุรกิจซอฟต์แวร์ เมื่อ AI เริ่มเปลี่ยนทั้งวิธีสร้างผลิตภัณฑ์และนิยามของงานวิศวกรรมเอง
https://www.youtube.com/watch?v=aiyf-5jmYf0
เกิดอะไรขึ้น
บทสนทนาเริ่มจากการตั้งโจทย์ว่า งานของวิศวกรกำลังเปลี่ยนจากการ “ส่งมอบผลงานโดยตรง” ไปเป็นการสร้าง “โรงงานซอฟต์แวร์” ที่ผลิตผลลัพธ์ได้แบบทวีคูณ แนวคิดนี้สะท้อนว่าความสามารถของวิศวกรในยุค AI อาจไม่ได้วัดจากจำนวนงานที่ทำได้ด้วยตัวเองอีกต่อไป แต่เป็นการออกแบบระบบที่ขยายผลงานได้มากกว่าเดิมหลายเท่า
> “The job of the engineer being something that you just show up to work... now what's happening is the way that I'm judging you as an engineer is like are you producing the factory that will produce multiplicative outputs.”
ในบทสนทนา ยังมีการชี้ว่าแนวคิดเรื่องวิศวกร 10x อาจเล็กเกินไปสำหรับยุคนี้ เพราะเมื่อรวม AI leverage เข้าไป ความต่างของผลลัพธ์อาจขยับไปถึง 100x หรือ 1000x ได้ โดยเฉพาะในงานเชิงความคิดและงานดิจิทัล
อย่างไรก็ดี ผู้ร่วมสนทนายังเห็นตรงกันว่า การวัดผลด้วย token consumption เพียงอย่างเดียวอาจผิดทิศทาง ไม่ต่างจากการวัด productivity ด้วย lines of code ในอดีต เพราะสิ่งสำคัญจริงอาจอยู่ที่คุณภาพของ judgment และผลลัพธ์สุดท้ายมากกว่า
ทำไม “Waste Tokens, Save Time” ถึงสำคัญ
ช่วงที่ชัดที่สุดของวิดีโอนี้คือ Naval อธิบายวิธีใช้งานโมเดลของตัวเองอย่างตรงไปตรงมา เขาระบุว่าเขาแทบไม่ได้พยายามเรียนรู้เทคนิคพรอมป์ติงที่ซับซ้อน แต่เลือกเชื่อว่าโมเดลจะพัฒนาเร็วกว่าอัตราที่มนุษย์จะเรียนรู้ทริกทั้งหมดได้ทัน
> Naval: “I just assumed the model's just going to get better faster than I would figure out how to use it.”
> Naval: “I'll throw Codex Claw and Gemini at the same problem over and over and just waste tokens to save time.”
แกนของแนวคิดนี้คือ อย่าหมกมุ่นกับ token ทั้งฝั่ง input และ output มากเกินไป แต่ให้ดูว่าเวลาของมนุษย์ถูกใช้ไปอย่างไร และผลลัพธ์สุดท้ายตอบโจทย์หรือไม่ หากโค้ดที่ได้ยังไม่ดีพอ ก็สามารถ “ทุ่ม token เพิ่ม” เพื่อให้โมเดลช่วยตรวจ แก้ และเขียนใหม่ได้ในภายหลัง
> Naval: “Don't look at the tokens either as inputs or outputs. Just look at your time and look at the final output.”
มุมมองนี้สำคัญเพราะสะท้อนการเปลี่ยนวิธีคิดจาก “ประหยัดค่าใช้จ่ายของโมเดล” ไปเป็น “เพิ่มประสิทธิภาพเวลาของคน” โดยเฉพาะในบริบทที่ตามที่กล่าวในวิดีโอ โมเดลยังมีต้นทุนต่ำกว่าการใช้แรงงานมนุษย์ในหลายกรณี
โมเดลกำลังเปลี่ยนจากผู้ช่วยเป็นคู่คิด
อีกประเด็นสำคัญคือ ผู้ร่วมสนทนามองว่าโมเดลรุ่นใหม่เริ่มมีพฤติกรรมแบบ “principal engineer” มากกว่า “junior engineer” เพราะไม่ได้เพียงทำตามคำสั่งตรงๆ แต่เริ่มสะท้อนทางเลือก กลยุทธ์ และ trade-off กลับมาหามนุษย์
> “They used to be junior engineers now they're principal engineers because they come back to you with a set of tradeoffs.”
ตัวอย่างที่ถูกยกขึ้นมาคือ เมื่อผู้ใช้สั่งให้ระบบทำบางอย่างที่อาจไม่เหมาะกับสถาปัตยกรรม โมเดลสามารถโต้แย้งกลับได้ว่าเทคโนโลยีที่เลือกอาจไม่เหมาะ และเสนอทางเลือกที่ดีกว่า นี่ทำให้บทบาทของคนเริ่มขยับจากผู้สั่งงานแบบละเอียด ไปเป็นผู้ตัดสินใจในระดับรสนิยม สถาปัตยกรรม และ judgment
> “Taste and judgment.”
อย่างไรก็ตาม บทสนทนายังย้ำว่า ณ จุดนี้ คนที่มีประสบการณ์สูงยังดึงประโยชน์จากโมเดลได้มากกว่า เพราะสามารถให้ feedback ที่เฉียบคมกว่า และเลือกเทคโนโลยีหรือแนวทางที่เหมาะสมกว่าได้
ผลกระทบต่อทีมวิศวกรรมและธุรกิจซอฟต์แวร์
ผลกระทบแรกคือ เส้นทางการเติบโตของวิศวกรอาจเปลี่ยนไป จากเดิมที่เน้นการเขียน implementation ไปสู่การเลือกเครื่องมือ วางสถาปัตยกรรม และประเมิน trade-off ของระบบ เพราะสิ่งเหล่านี้ยังเป็นพื้นที่ที่ feedback ของมนุษย์มีผลมากต่อคุณภาพงานที่ได้จาก AI
ผลกระทบถัดมาคือ หากโมเดลสามารถเขียนและเข้าใจซอฟต์แวร์ด้วยภาษามนุษย์ได้ดีขึ้นเรื่อยๆ คำถามใหญ่จะเกิดกับ “pure software” ว่ายังเป็น moat ที่แข็งแรงเหมือนเดิมหรือไม่
> “Is pure software dead? Is pure software engineering like an obsolete thing?”
Naval ตั้งข้อสังเกตว่า ถ้าการเขียนโค้ดไม่ใช่อุปสรรคหลักอีกต่อไป ธุรกิจที่ได้ประโยชน์อาจเป็นฝั่ง hardware หรือผู้เล่นที่มีข้อได้เปรียบอื่น เช่น การสร้างโมเดลเอง การฝึกจูนโมเดล หรือการมี building blocks ที่ reusable และทรงพลังพอให้ agent ใช้งานต่อได้
มุมมองและสิ่งที่ต้องจับตา
สิ่งที่บทสัมภาษณ์นี้ชี้ให้เห็นคือ งานซอฟต์แวร์ไม่ได้หายไปทันที แต่กำลังถูกย้ายจุดศูนย์ถ่วง จาก “การลงมือเขียน” ไปสู่ “การออกแบบ การตัดสินใจ และการประกอบระบบ” มากขึ้น
อีกด้านหนึ่ง Naval ยังมองไปไกลกว่านั้นว่า ในอนาคต โมเดลอาจไม่เพียงรับคำสั่งจากคน แต่จะเริ่ม “สั่งงานคน” บางส่วน เช่น ขอ API key หรือเข้าถึงทรัพยากรที่ตัวมันยังทำเองไม่ได้ ขณะที่โครงสร้างพื้นฐานของซอฟต์แวร์และบริการต่างๆ จะต้องเปิดทางให้ agent ทำงานได้โดยตรงมากขึ้น
แม้หลายข้อสรุปในวิดีโอนี้ยังอยู่ในระดับคำถามมากกว่าคำตอบ แต่ประเด็นหลักชัดเจนว่า ทีมเทคและผู้ก่อตั้งควรเลิกยึดติดกับตัวชี้วัดแบบเก่า และเริ่มประเมิน AI จากผลลัพธ์จริง เวลา และ leverage ที่มันสร้างได้