- ในยุคที่ AI เขียนซอฟต์แวร์ทั้งหมด ซอฟต์แวร์ที่ ประหยัดโทเค็น (ต้นทุนการอนุมาน) จะเป็นผู้รอดผ่าน แรงกดดันจากการคัดเลือกแบบวิวัฒนาการ
- วัดความเหมาะสมของซอฟต์แวร์ด้วยสูตร อัตราการอยู่รอด และจะอยู่รอดได้ก็ต่อเมื่อการประหยัดการรับรู้มากกว่าต้นทุนการรับรู้เท่านั้น (มากกว่า 1)
- เครื่องมืออย่าง Git และ grep เป็นกรณีที่ต้นทุนในการให้ AI สร้างขึ้นมาใหม่เพื่อใช้งานนั้นสูงเกินเหตุ เพราะมี การบีบอัดอินไซต์ และ ประสิทธิภาพของซับสเตรต
- หากเอเจนต์จะยอมรับเครื่องมือ จำเป็นต้องมีทั้ง การรับรู้ (Awareness) และ แรงเสียดทานต่ำสุด (Friction) โดยการออกแบบแบบ Desire Paths มีประสิทธิภาพ
- แม้ในยุคที่ AI เป็นศูนย์กลาง ค่าสัมประสิทธิ์มนุษย์ (Human Coefficient) ก็ยังทำงานอยู่ ทำให้พื้นที่ที่ การแทรกแซงและความชอบของมนุษย์สร้างคุณค่าโดยตรง ยังคงอยู่รอดต่อไป
ภูมิหลัง: การคาดการณ์ซอฟต์แวร์ในยุค AI
- ตั้งแต่เดือนมิถุนายน 2024 ผ่าน Death of the Junior Developer, การคาดการณ์การมาถึงของ orchestrator ล่วงหน้า 10 เดือน, และโปรเจ็กต์ Gas Town ผู้เขียนทำนายเส้นโค้งความก้าวหน้าของ AI ได้อย่างต่อเนื่อง
- พัฒนา Gas Town จากการคาดการณ์ต่อเนื่องของแนวโน้ม: การเติมโค้ดอัตโนมัติในปี 2023 → อินเทอร์เฟซแบบสนทนาในปี 2024 → เอเจนต์ช่วงต้นปี 2025 → การ orchestration ช่วงต้นปี 2026
- รากฐานของการคาดการณ์ทั้งหมดคือ ท่าทีที่เชื่อเส้นโค้งการเติบโตแบบเอ็กซ์โปเนนเชียลตามตรง
- เชื่อมั่นอย่างเต็มที่ในทิศทางที่ Dario Amodei และ Andrej Karpathy พูดถึงเกี่ยวกับอนาคตของซอฟต์แวร์
- Gas Town เป็นตัวอย่างที่แสดงว่าการคาดการณ์ลักษณะนี้ใช้ได้จริง โดยตรวจสอบรูปแบบที่ พอจะตั้งอยู่ได้อย่างหวุดหวิด ล่วงหน้าด้วยโมเดลปลายปี 2025 และตัวช่วยเฉพาะกิจจำนวนมาก
ระบบนิเวศซอฟต์แวร์ที่กำลังถูกคุกคาม
- แรงกดดันต่อบริษัท SaaS เพิ่มขึ้น โครงสร้างต้นทุนระหว่างการซื้อเทียบกับการสร้างเองเปลี่ยนไป จนแผนกธุรกิจเริ่มสร้าง SaaS ของตนเองด้วย vibe coding
- เมื่อเทียบกับเมื่อเพียง 3 ปีก่อนที่ GPT-3.5 ยังลำบากแม้แต่กับการเขียนฟังก์ชันเดียว ตอนนี้สามารถสร้าง SaaS ขนาดเล็กแต่มีคุณค่าจริง ได้โดยตรง
- Stack Overflow และ Chegg เป็นกลุ่มแรกที่ได้รับผลกระทบ จากนั้นแรงกดดันก็กระจายไปยัง ซอฟต์แวร์สนับสนุนลูกค้าระดับ Tier-1, ระบบ low-code/no-code, เครื่องมือสร้างคอนเทนต์ และเครื่องมือเพิ่มประสิทธิภาพหลากหลายประเภท
- ฝั่งผู้ขาย IDE เองก็เริ่มรู้สึกถึงแรงกดดันจากการแข่งขันหลังการมาของ Claude Code
- เมื่อพิจารณาว่าคำทำนายของนักวิจัย AI มี ความแม่นยำสูงต่อเนื่องราว 40 ปี จึงจำเป็นต้องเตรียมพร้อมโดยตั้งสมมติฐานว่า ซอฟต์แวร์ทุกหมวดอาจถูกคุกคาม
โมเดลแรงกดดันจากการคัดเลือก (Selection Argument)
- การอนุมานต้องใช้โทเค็น และการใช้โทเค็นนำไปสู่การใช้พลังงาน ซึ่งพลังงานก็แปลงเป็นต้นทุนได้ทันที
- {โทเค็น, พลังงาน, เงิน} สามารถมองเป็นข้อจำกัดของทรัพยากรชนิดเดียวกัน และล้วนมีอยู่อย่างจำกัดเสมอ
- กฎง่าย ๆ ที่ว่า ซอฟต์แวร์ที่ลดต้นทุนการรับรู้จะอยู่รอด เป็นสิ่งที่กำลังกำหนดรูปแบบของระบบนิเวศซอฟต์แวร์ทั้งหมด
- โครงสร้างนี้เหมือนกับแรงกดดันจากการคัดเลือกแบบวิวัฒนาการ ที่สิ่งมีชีวิตซึ่งใช้ทรัพยากรได้มีประสิทธิภาพกว่าในสภาพแวดล้อมที่ทรัพยากรจำกัด จะเบียดสิ่งที่ด้อยประสิทธิภาพออกไป
สูตรอัตราการอยู่รอด (Survival Ratio)
- Survival(T) ∝ (Savings × Usage × H) / (Awareness_cost + Friction_cost)
- Savings: ต้นทุนการรับรู้ที่ประหยัดได้จากการใช้เครื่องมือ หรือปริมาณโทเค็นที่ลดลงเมื่อเทียบกับการสังเคราะห์ความสามารถเดียวกันขึ้นมาใหม่ตั้งแต่ต้น
- Usage: ความถี่และขอบเขตการใช้งานซ้ำของเครื่องมือในสถานการณ์ที่หลากหลาย
- H (Human Coefficient): ค่าสัมประสิทธิ์ที่สะท้อนความต้องการที่ให้คุณค่ากับสิ่งที่มนุษย์สร้าง โดยไม่ขึ้นกับประสิทธิภาพ
- Awareness_cost: พลังงานที่เอเจนต์ต้องใช้เพื่อรู้ว่าเครื่องมือนี้มีอยู่ จำได้ และเลือกใช้ในเวลาที่เหมาะสม
- Friction_cost: พลังงานที่สูญเสียไประหว่างการใช้งานจริงจากข้อผิดพลาด ความล้มเหลว การลองใหม่ และความเข้าใจคลาดเคลื่อน
- อัตราขั้นต่ำสำหรับการอยู่รอดคือ 1 และในสภาพแวดล้อมที่มีการแข่งขัน ค่านี้ต้องสูงกว่านั้นมาก
- ตัวอย่าง: เครื่องมือที่มีอัตราการอยู่รอด 1.2 อาจถูกเครื่องมือคู่แข่งที่ทำได้ 2.5 เบียดออกจากตลาด
คันโยก 1: การบีบอัดอินไซต์ (Insight Compression)
- อัด ความรู้ที่สะสมมานานในอุตสาหกรรมซอฟต์แวร์และมีต้นทุนสูงเกินไปที่จะค้นพบใหม่ ให้อยู่ในรูปที่นำกลับมาใช้ซ้ำได้
- Git เป็นตัวอย่างชัดเจน โดย commit DAG, ref ในฐานะ pointer, index, reflog ฯลฯ คือโครงสร้างที่บีบรวมการลองผิดลองถูกหลายสิบปี
- หาก AI จะนำสิ่งนี้ไปสร้างใหม่ตั้งแต่ต้น ก็ต้องเดินซ้ำประวัติศาสตร์ทางปัญญาเดิมอีกครั้ง ซึ่ง ไม่สมเหตุสมผลทางเศรษฐกิจเลย
- หลักการเดียวกันนี้ใช้ได้กับฐานข้อมูล, คอมไพเลอร์, ระบบปฏิบัติการ, workflow engine และระบบมอนิเตอร์ริงทั้งหมด
- Kubernetes ซับซ้อนไม่ใช่เพราะออกแบบมาให้ซับซ้อน แต่เพราะ ระบบกระจายตัวนั้นซับซ้อนโดยเนื้อแท้
- Temporal ให้ durable execution แทนการต้องไปสร้าง saga pattern พร้อมการ retry แบบ idempotent ด้วยตัวเอง ซึ่งในทางปฏิบัติแทบใกล้เคียงกับงานวิจัย
- ลักษณะร่วมของซอฟต์แวร์ที่แข็งแรงคือ ความหนาแน่นของอินไซต์สูงจนการพยายามสังเคราะห์มันขึ้นมาใหม่ดูไร้สาระ
- แม้แต่โมเดลบทบาทตัวละครใน Gas Town หรือกริยาอย่าง
gt sling ก็เป็นตัวอย่างของการ บีบแนวคิดซับซ้อนให้เหลือถ้อยคำสั้น จำง่าย
คันโยก 2: ประสิทธิภาพของซับสเตรต (Substrate Efficiency)
- grep เป็นอีกตัวอย่างที่การประดิษฐ์ใหม่แทบเข้าขั้นบ้าบิ่น
- แม้จะเรียบง่ายจน Ken Thompson สร้างได้ในเวลาเพียงครึ่งบ่าย แต่ก็ประหยัดต้นทุนการรับรู้มหาศาลผ่าน การประมวลผลบน CPU
- ในการจับคู่รูปแบบข้อความ CPU เหนือกว่า GPU หลายลำดับขั้น
- วิธีคูณของ LLM เป็นเหมือนการประกอบการจับคู่รูปแบบเพื่อเดา “ประมาณ 94” ก่อน แล้วค่อยปรับหลักตัวเลขด้วยตาราง lookup ที่จดจำไว้
- การคำนวณทั้งหมดนี้เกิดขึ้นบน ซับสเตรตที่ไร้ประสิทธิภาพอย่างยิ่งคือขั้นอนุมานบน GPU
- เครื่องคิดเลข, parser, เครื่องมือแปลงข้อมูลซับซ้อนอย่าง ImageMagick และยูทิลิตี Unix CLI จำนวนมาก ล้วนใช้คันโยกนี้อย่างเต็มที่
- การใช้อัลกอริทึมที่ดี หรือย้ายการคำนวณไปยัง ซับสเตรตที่ถูกกว่า เช่น CPU หรือมนุษย์ ช่วยประหยัดทั้งโทเค็นและพลังงาน
คันโยก 3: ประโยชน์ใช้สอยกว้างขวาง (Broad Utility)
- ตรงกับพจน์ Usage ในโมเดลอัตราการอยู่รอด
- ยิ่งขอบเขตการใช้งานกว้าง ต้นทุนด้านการรับรู้ก็ยิ่งถูกเฉลี่ยออก และเกณฑ์การประหยัดโทเค็นที่ต้องการต่อการใช้งานแต่ละครั้งก็ยิ่งต่ำลง
- สำหรับเครื่องมือประหยัดโทเค็นที่ใช้งานได้ทั่วไปอย่างแท้จริง แม้ AI จะสามารถสร้างใหม่ได้ในทางทฤษฎี แต่ตัวเลือกที่ มีอยู่ทุกที่และถูกใช้อย่างแพร่หลายอยู่แล้ว จะได้เปรียบก่อน
- Temporal แม้มีต้นทุนด้านการรับรู้และแรงเสียดทานค่อนข้างสูง ก็ยังให้โมเดล workflow ที่ใช้งานได้กว้างพอ ๆ กับ PostgreSQL
- ครอบครอง ทั้งสามคันโยกพร้อมกัน ได้แก่ การบีบอัดอินไซต์อย่างเข้มข้น การใช้ซับสเตรตการคำนวณอย่างชาญฉลาด และประโยชน์ใช้สอยกว้างขวาง
- Dolt เป็นฐานข้อมูลที่จัดการเวอร์ชันด้วย Git และเป็นโปรเจ็กต์โอเพนซอร์สที่ดูแลต่อเนื่องมา 8 ปี
- มาค้นพบ killer app ช้ากว่าเพื่อนในเวิร์กโฟลว์ production และ DevOps แบบใช้เอเจนต์
- แม้เอเจนต์จะพลาดใน production ก็ยัง rollback และ rollforward ได้ด้วยความสามารถทั้งหมดของ Git
- เอนจินค้นหาโค้ด มีความสำคัญเพิ่มขึ้นอย่างรวดเร็ว เพราะ LLM สร้างโค้ดได้มากกว่าเดิม 10 ถึง 100 เท่า
- เกิดช่องว่างทั่วไปขนาดใหญ่แบบที่เรียกว่า “ใหญ่เกินกว่า grep จะรับมือได้”
- เพราะแก้ปัญหาที่ไม่เป็นสามัญและมี edge case ค้นพบยากจำนวนมาก ใช้ซับสเตรตคำนวณต้นทุนต่ำ และประยุกต์ใช้ได้กว้าง จึง ครบทั้งสามคันโยก
คันโยก 4: การประชาสัมพันธ์ (Publicity)
- การประหยัดต้นทุนการรับรู้เพียงอย่างเดียวไม่พอ ต้องแก้ ปัญหาการรับรู้ถึงการมีอยู่ของเครื่องมือ ซึ่งเป็นปัญหาในขั้นก่อนการเลือกใช้งาน
- Dolt มีคันโยก 1–3 ครบ แต่ในระยะแรกขาดคันโยก 4 จึงยังไม่ถูกใช้อย่างแพร่หลาย
- มีหลายวิธีในการจ่ายต้นทุนด้านการรับรู้
- สร้างผลิตภัณฑ์ที่ยอดเยี่ยมจนได้รับความนิยม แล้วรอให้ชุมชนช่วยทำให้มัน ถูกรวมอยู่ในข้อมูลฝึกอย่างเป็นธรรมชาติ
- หรือจะลงต้นทุนเพื่อทำ เอกสารสำหรับเอเจนต์ หรือซื้อโฆษณาก็ได้
- วิธีที่ตรงกว่านั้นคือร่วมมือกับผู้รับผิดชอบใน frontier lab อย่าง OpenAI, Anthropic และ Google เพื่อใส่เครื่องมือนั้นเข้าไปในกระบวนการฝึกโมเดล
- ในรูปบริการแบบมีค่าใช้จ่าย โดยสร้าง eval ที่แสดงทั้งการใช้งานที่ถูกต้องและการใช้งานผิด แล้วให้นักวิจัยปรับการฝึก
- แนวคิดเรื่อง SEO สำหรับเอเจนต์ กำลังเกิดขึ้นอย่างจริงจัง
- หากไม่สามารถทุ่มงบประมาณขนาดใหญ่ได้ ก็จำเป็นต้องพึ่ง พลังงานในขั้นหลังการเลือกใช้งาน หรือคันโยก 5 และต้องออกแบบเครื่องมือให้เป็นมิตรกับเอเจนต์ให้มากที่สุด
คันโยก 5: การลดแรงเสียดทานให้ต่ำที่สุด (Minimizing Friction)
- หากการรับรู้เป็นปัญหาในขั้นก่อนเลือกใช้งาน แรงเสียดทานของผลิตภัณฑ์ ก็คือปัญหาในขั้นหลังจากเริ่มใช้แล้ว
- เอเจนต์มักทำตัวเหมือนถูกเวลาไล่ล่าอยู่เสมอ และถ้ามีอะไรติดขัดก็จะ ลองเส้นทางอ้อมทันที
- แรงเสียดทานเพียงเล็กน้อยก็ทำให้การตัดสินใจเปลี่ยน เอเจนต์อาจถอยกลับไปใช้ วิธีที่ด้อยประสิทธิภาพกว่าแต่คุ้นเคยและคาดเดาได้
- ในทางกลับกัน ถ้าเครื่องมือถูกออกแบบมาตรงกับรสนิยมอย่างแม่นยำ เอเจนต์จะ ใช้งานซ้ำอย่างดื้อดึง
- แนวทางแบบเอกสารคือการเลื่อนต้นทุนด้านการรับรู้ออกจากขั้นฝึก ไปไว้ที่ ช่วงเวลาอนุมานจริง
- คือฉีดบริบทเข้าไปโดยตรงว่าเครื่องมือนั้นเก่งเรื่องอะไร ควรใช้เมื่อไรและทำไม พร้อมคู่มือเริ่มต้นแบบเร็วและเส้นทางไปยังเอกสารถัดไป
- แต่ทางออกที่ดีกว่าคือ สร้างเครื่องมือที่ตัวเอเจนต์เองรู้สึกว่าใช้งานได้อย่างเป็นธรรมชาติ
- ตัวอย่างการออกแบบแบบ Desire Paths, Beads ทำให้ CLI ค่อย ๆ วิวัฒน์ตลอด 4 เดือน ผ่าน subcommand กว่า 100 รายการ รวมถึง sub-subcommand, alias และไวยากรณ์ทางเลือกจำนวนมาก
- CLI ที่ซับซ้อนนี้ไม่ได้ออกแบบเพื่อมนุษย์ แต่เพื่อ รูปแบบการใช้งานของเอเจนต์
- สังเกตวิธีที่เอเจนต์พยายามใช้งาน แล้ว เปลี่ยนอาการหลอนให้กลายเป็นฟีเจอร์จริง จนตอนนี้การเดาแทบทุกอย่างใช้งานได้จริง
- Hallucination Squatting คือเทคนิคที่ตามเก็บชื่อโดเมนที่ LLM ชอบหลอนขึ้นมาบ่อย ๆ แล้วจดทะเบียนเสียเอง จากนั้นอัปโหลดอาร์ติแฟกต์ไว้ที่อยู่ดังกล่าวเพื่อให้มีการดาวน์โหลดจริง
- สิ่งนี้เผยให้เห็นว่าแม้แต่กลุ่มแฮ็กเกอร์ระดับรัฐชาติเองก็ยัง เข้าใจและใช้ประโยชน์จาก Agent UX
- Agent UX สำคัญอย่างชี้ขาด แต่ยังถูกมองข้ามในเครื่องมือส่วนใหญ่
- เครื่องมือในอุดมคติควรคล้ายกับเครื่องมืออื่นที่เอเจนต์คุ้นเคยอยู่แล้ว หรือแก้ปัญหาในแบบที่ เอเจนต์อยากคิดกับมันจริง ๆ
คันโยก 6: ค่าสัมประสิทธิ์มนุษย์ (Human Coefficient)
- มีซอฟต์แวร์บางประเภทที่ได้คุณค่าเพียงเพราะ ข้อเท็จจริงที่ว่ามนุษย์มีส่วนร่วม โดยไม่เกี่ยวกับประสิทธิภาพของโทเค็น
- คุณค่าดังกล่าวมาจากองค์ประกอบอย่างการคัดสรรโดยมนุษย์, social proof, ความคิดสร้างสรรค์, การมีตัวตนทางกายภาพ และการรับรอง
- เพลย์ลิสต์ที่มนุษย์เลือก อาจชนะเพลย์ลิสต์ที่ AI สร้างซึ่งมีคุณภาพเท่ากันและประหยัดพลังงานกว่า
- ในโลกเกม สภาพแวดล้อมที่มีมนุษย์จริงมักชนะ และ ไม่ค่อยมีใครอยากเล่นกับ AI ที่เก่งกว่ามนุษย์อย่างชัดเจนเท่านั้น
- โซเชียลเน็ตเวิร์ก ที่กันเอเจนต์ออกไป อาจกลับกลายเป็นสิ่งที่น่าดึงดูดกว่า
- ต่อให้ AI กลายเป็นครูที่ดีที่สุด ก็ยังมีบางคนที่จะ ตั้งใจเลือกครูมนุษย์
- แม้ในพื้นที่ที่มี Human Coefficient สูง การแข่งขันก็ยังเข้มข้น
- ในโลกแบบที่ Karpathy วาดไว้ เอเจนต์สามารถเป็นอะไรก็ได้ให้ใครก็ได้ และมีคุณสมบัติ เสพติดอย่างรุนแรงโดยเนื้อแท้
- ผลลัพธ์คืออาจมี ซอฟต์แวร์จำนวนมากที่ไร้ประสิทธิภาพสุดขั้ว แต่มีค่า H สูงมาก
เหตุผลที่ยังมีความหวัง
- ซอฟต์แวร์ที่ทำหน้าที่เป็นตัวกลางระหว่างมนุษย์กับ AI หรือรับบท “ทำเป็นฉลาด” แทน AI ในสิ่งที่ AI จะทำเองได้โดยตรงในไม่ช้า มีความเสี่ยงเชิงโครงสร้าง
- ถึงอย่างนั้น ปริมาณซอฟต์แวร์ที่ควรถูกเขียนยังแทบไร้ขีดจำกัด
- การรักษาทุกโรค, การสร้างแบบจำลองพฤติกรรมของโปรตีนทุกชนิด, และทุกสถานการณ์การสำรวจดาวเคราะห์ ยังล้วนรออยู่
- ความทะเยอทะยานของมนุษย์สูงเกินกว่าความสามารถด้านการรับรู้ที่มีอยู่เสมอ และแม้ต้นทุนโทเค็นจะลดลง เราก็จะขยับไปสู่แนวหน้าใหม่ที่ไกลกว่าเดิมทันที
- ปัญหาเรื่องการแย่งความสนใจนั้น เรามีประสบการณ์ แก้มาแล้วหลายรอบ ตั้งแต่สื่อสิ่งพิมพ์ อินเทอร์เน็ต โซเชียลมีเดีย โฆษณาเรียลไทม์ ไปจนถึงแพลตฟอร์มรวมข่าว
- การออกแบบแบบ Desire Paths ใช้ได้ผลจริง และต่อให้ไม่มีงบฝึกขนาดใหญ่แบบ OpenAI ก็ยังสร้างเครื่องมือที่เอเจนต์อยากใช้โดยธรรมชาติได้
- ค่าสัมประสิทธิ์มนุษย์มีอยู่จริงอย่างแน่นอน และผู้คนก็เริ่มรู้สึกล้ากับสิ่งที่มีกลิ่นอายเอเจนต์แรงเกินไปแล้ว
- หากออกแบบโดยวางความเชื่อมโยงระหว่างมนุษย์และความคิดสร้างสรรค์ไว้เป็นแกนกลาง สุดท้ายปัญหาก็จะย้อนกลับไปสู่ ขอบเขตของการตลาดและการสร้างแบรนด์แบบดั้งเดิม
- มี เส้นทางการอยู่รอดที่หลากหลาย จากคันโยกทั้งหก
- หากสร้างสิ่งที่แม้แต่ความพยายามจะทำซ้ำก็ยังดูบ้าบิ่น และทำให้ ค้นหาได้ง่าย ใช้งานได้ง่าย ก็ยังมีโอกาสที่แข็งแรงเพียงพอ
ยังไม่มีความคิดเห็น