กำแพงในการเริ่มต้นสร้าง software พังทลายลงแล้ว แต่กำแพงในการสร้างสิ่งที่ มีความหมายจริงๆ นั้นยังคงสูงเท่าเดิมไม่เปลี่ยนแปลง
การมาของ Claude Code และ Claude Opus 4.5 เหมือนเป็นการเติมเชื้อไฟให้กับการคาดหวังในตัว AI เครื่องมือกลุ่ม LLM มีมานานแล้วก็จริง แต่ตอนนี้พวกมันเก่งขึ้นกว่าเดิมมากจนทำให้ผู้คนหันมาสนใจกันล้นหลาม อย่างไรก็ตาม เราไม่ได้กำลังเข้าสู่ยุคทองของ SaaS แต่เรากำลังก้าวเข้าสู่ยุคของ personal, disposable software(software ส่วนบุคคลที่ใช้แล้วทิ้ง) ซึ่งเป็นยุคที่งานวิศวกรรมเปลี่ยนจากการเขียน code เป็นการออกแบบระบบ และนั่นคือเหตุผลว่าทำไม software engineer ยังคงเป็นที่ต้องการ
THE SHIFT IN MODERN DEVELOPMENT
ตอนนี้ Claude Code กำลังยึดพื้นที่บนหน้า feed ของผม และมันมีเหตุผลที่สมควร สิ่งที่น่าสนใจไม่ใช่แค่การที่เหล่านักพัฒนาหันมาใช้มัน แต่มันคือการที่บรรดา builders และ makers ที่เคยพึ่งพา platform อย่าง Lovable หรือ Replit กำลังย้ายมาใช้งานมันต่างหาก
อย่าเข้าใจผมผิดนะ เครื่องมือเหล่านั้นยังคงใช้งานได้ดีเยี่ยมสำหรับการส่งมอบงานที่รวดเร็ว แต่เรากำลังเห็นการเปลี่ยนแปลงที่ชัดเจนเมื่อผู้คนเริ่มหวนกลับมาค้นพบความสวยงามของ workflow แบบ CLI-first เมื่อคุณย้ายการโต้ตอบเข้าไปอยู่ใน terminal เลเยอร์ของการสรุปย่อ (abstraction layer) จะบางลง คุณไม่ได้แค่เดินตามเส้นทางที่ UI จัดเตรียมไว้ให้ แต่คุณคือคนที่กุมบังเหียนควบคุมมันจริงๆ
THE COLLAPSE OF THE BARRIER TO ENTRY
สิ่งที่ผู้คนสร้างขึ้นด้วยเครื่องมือเหล่านี้คืออะไร? คำตอบคือ: เกือบทุกอย่าง ในความเป็นจริงเรามาถึงจุดที่อิ่มตัวแล้ว ในด้านหนึ่งเรากำลังเห็นการทำให้การสร้าง software เป็นเรื่องของทุกคน (democratisation) กำแพงในการเข้าถึงได้พังทลายลงอย่างสิ้นเชิง เป็นครั้งแรกที่คนที่ไม่ใช่นักพัฒนาไม่ได้เป็นเพียงแค่ผู้ใช้งาน software แต่เป็นผู้ออกแบบเครื่องมือของตัวเอง
ในอดีต หากคุณมีปัญหาเฉพาะด้าน คุณอาจต้องใช้เวลาหลายชั่วโมงในการค้นหาผลิตภัณฑ์ SaaS ที่ตอบโจทย์ได้สัก 80% แต่วันนี้ workflow เปลี่ยนไปแล้ว ผู้คนเปิด CLI หรือใช้ interface เสียงเพื่ออธิบายสิ่งที่ต้องการ เรากำลังเห็นการเติบโตของ personal software(software ส่วนบุคคล):
-
ระบบติดตามการสมัครสมาชิก (
Subscription tracker) ที่ปรับแต่งตามสไตล์budgetเฉพาะตัว *Chrome extensionที่แก้ปัญหาการป้อนข้อมูลที่เฉพาะเจาะจงมากๆ -
แอป
fitnessที่มีหน้าตาตรงตามความต้องการของผู้ใช้เป๊ะๆ
นี่คือการเปลี่ยนแปลงครั้งใหญ่ Software กำลังกลายเป็นสาธารณูปโภคส่วนบุคคลที่คุณสร้างขึ้นมาเอง แทนที่จะเป็นสินค้าโภคภัณฑ์ที่คุณต้องซื้อ
FROM SAAS TO SCRATCHPADS
เรากำลังเข้าสู่ยุคใหม่ของการพัฒนา software ที่เป้าหมายอาจไม่ใช่ความยั่งยืนเสมอไป หลายปีที่ผ่านมา อุตสาหกรรมหมกมุ่นอยู่กับการสร้าง platform และระบบนิเวศ (ecosystem) แต่กระแสกำลังเปลี่ยนไปสู่สิ่งที่ชั่วคราวมากขึ้น เรากำลังย้ายจาก SaaS ไปสู่ scratchpads(สมุดจด)
Software ใหม่ๆ จำนวนมากไม่ได้ถูกสร้างมาเพื่อให้อยู่ตลอดไป ในทางกลับกัน ผู้คนเริ่มสร้างเครื่องมือเพื่อแก้ปัญหาเฉพาะหน้าเพียงครั้งเดียวแล้วก็ทิ้งไป มันคือ software ที่เป็นเหมือนของใช้แล้วทิ้ง ถูกออกแบบมาเพื่อ ปัจจุบัน มากกว่า อนาคต
สิ่งที่ทำให้แนวคิดนี้เป็นไปได้คือปรัชญาทางเทคนิคที่เฉพาะเจาะจง:interface แบบ CLI-first, ข้อมูลจัดเก็บในเครื่อง (local data) และไม่มีขั้นตอนการเริ่มต้นใช้งาน (zero onboarding) เมื่อคุณกำจัดความยุ่งยากในการลงทะเบียน การตั้งค่าฐานข้อมูล หรือการใช้งาน UI ที่ซับซ้อน ต้นทุนในการสร้างเครื่องมือก็จะลดลงจนความ ชั่วคราว กลายเป็น feature ไม่ใช่ bug หากการสร้างโซลูชันสำหรับงานที่ทำครั้งเดียวใช้เวลาเพียงห้านาที คุณก็ไม่จำเป็นต้องเก็บมันไว้ตลอดไป
ซึ่งต่างจาก model SaaS แบบดั้งเดิมอย่างสิ้นเชิง SaaS ถูกสร้างมาเพื่อเพิ่มประสิทธิภาพในการรักษาลูกค้า (retention), การผูกขาด (lock-in) และการขยายตัว มันคือโมเดลธุรกิจที่ออกแบบมาเพื่อให้คุณอยู่ในระบบนิเวศและขยายการใช้งานไปเรื่อยๆ ในขณะที่เครื่องมือเฉพาะกิจ (bespoke tools) เน้นที่ความรวดเร็วและการควบคุม พวกเขาไม่สนใจมูลค่าตลอดช่วงชีวิตของคุณในฐานะลูกค้า (LTV) พวกเขาสนใจแค่การแก้ปัญหาตรงหน้าเท่านั้น
ในหลายๆ แง่ นี่คือการกลับไปสู่จุดเริ่มต้นของการใช้งาน Spreadsheets คุณไม่ได้เปิดสเปรดชีตเพื่อสร้างฐานข้อมูลถาวรหลายปี แต่คุณใช้มันเป็นสมุดจดเพื่อคิดแก้ปัญหา คำนวณผลลัพธ์ แล้วก็ไปทำอย่างอื่นต่อ
ในภูมิทัศน์ใหม่นี้ Claude Code คือ Excel สำหรับนักพัฒนา—เป็นเครื่องมือที่ทรงพลังและยืดหยุ่นสำหรับการแก้ปัญหาเฉพาะหน้า—มากกว่าที่จะเป็น Shopify สำหรับผู้ก่อตั้ง ซึ่งถูกสร้างมาเพื่อเป็นรากฐานถาวรสำหรับธุรกิจ มันคือการทำงานให้เสร็จ แล้วก็ปล่อยเครื่องมือนั้นไป
นี่เป็นเหตุผลว่าทำไมส่วนถัดไปจึงสำคัญ: การสร้าง software อย่างรวดเร็วเป็นเรื่องหนึ่ง การทำให้มันอยู่รอดได้ในโลกแห่งความเป็นจริงก็เป็นอีกเรื่องหนึ่ง
CODE IS CHEAP. SOFTWARE IS STILL EXPENSIVE.
นี่คือความจริงในยุค AI-native: Code กลายเป็นของถูก แต่ software ยังคงแพงมหาศาล
LLM ช่วยลดต้นทุนในการเขียน code จนแทบจะเป็นศูนย์ แต่พวกมันไม่ได้ช่วยลดต้นทุนในการ ทำความเข้าใจปัญหา เลย เราเห็นแอปที่สร้างขึ้นในวันหยุดสุดสัปดาห์ (apps built in a weekend) มากมาย แต่ส่วนใหญ่เป็นเพียงเปลือกบางๆ ที่หุ้มการทำงาน CRUD พื้นฐานและการเรียกใช้ API ภายนอก พวกมันดูน่าประทับใจในเดโมบน Twitter แต่กลับพังทลายทันทีที่ต้องเจอกับอุปสรรคในโลกแห่งความเป็นจริง
ต้นทุนที่แท้จริงของ software ไม่ใช่การเขียนครั้งแรก แต่มันคือการบำรุงรักษา (maintenance), การจัดการเคสแปลกๆ (edge cases), หนี้ทาง UX(UX debt) ที่เพิ่มพูน และความซับซ้อนของการเป็นเจ้าของข้อมูล โซลูชันที่ รวดเร็ว เหล่านี้เปราะบางมาก
ระบบติดตามการสมัครสมาชิกจะพังทันทีที่ธนาคารเปลี่ยนรูปแบบการส่งออกไฟล์ CSV ส่วน Chrome extension จะตายทันทีที่โครงสร้าง DOM ของเว็บไซต์เป้าหมายเปลี่ยนไป และแอป fitness จะใช้งานไม่ได้ทันทีที่ผู้ใช้ต้องการการทำงานแบบออฟไลน์ที่เสถียรหรือการซิงค์ข้อมูลที่เชื่อถือได้
ช่วงนี้ผมเห็นการทำนายถึงวันสิ้นโลกบน Hacker News,Reddit และ Twitter เกี่ยวกับ จุดจบของวิศวกรรมsoftware ซึ่งมันผิดประเด็นอย่างสิ้นเชิง เราไม่ได้กำลังเห็นจุดจบของอาชีพนี้ แต่เรากำลังเข้าสู่ยุคใหม่ของมันต่างหาก
มูลค่าของวิศวกรกำลังเปลี่ยนจาก วิธีการ(how) ในเชิงไวยากรณ์ (syntax) ไปสู่ อะไร(what) และ ทำไม(why) ในเชิงระบบ งานวิศวกรรมที่แท้จริงอยู่ในเรื่องของ Abstractions และ Architecture มันคือการรู้ว่าจะวางโครงสร้างระบบอย่างไรให้อยู่รอด เข้าใจว่าทำไมต้องมีกลยุทธ์ Rate-limiting แบบเฉพาะเจาะจง รู้วิธีจัดการ Distributed cache และรู้ว่าจุดไหนที่ไม่ควรเก็บ Environment variables
AI มักจะดูทรงพลังเพราะมันซ่อนความซับซ้อนไว้ แต่ในฐานะวิศวกร งานของคุณคือการจัดการความซับซ้อนนั้น ไม่ใช่เพิกเฉยต่อมัน เครื่องมือเปลี่ยนไป แต่ข้อกำหนดพื้นฐานสำหรับความเข้มงวดทางวิศวกรรมนั้นไม่เคยสูงเท่านี้มาก่อน
THE DISTRIBUTION ILLUSION
แต่อีกด้านหนึ่ง เมื่อกำแพงในการเข้าถึงหายไป ระดับของเสียงรบกวน (noise) ก็พุ่งสูงขึ้นเป็นประวัติการณ์ ฟีดของผมเต็มไปด้วย AI entrepreneurs ที่อ้างว่ามีรายได้รายเดือน (MRR) หลักหมื่นเหรียญจากแอปที่สร้างขึ้นเพียงช่วงบ่าย
ในหลายๆ กรณี ข้ออ้างเหล่านี้เป็นที่น่าสงสัย เมื่อคุณเห็นนักสร้างที่ไม่มีฐานลูกค้าเดิมและไม่มี คูเมือง(moat) ที่ชัดเจน อ้างรายได้ MRR10,000 เหรียญจากโปรเจกต์วันหยุดสุดสัปดาห์ มักจะเป็นการเรียกร้องความสนใจ (engagement) มากกว่าที่จะสะท้อนความเป็นจริงทางธุรกิจ
บางเรื่องอาจจะเป็นความจริง แต่ในกรณีส่วนใหญ่ สิ่งเหล่านี้ไม่ใช่แผนผังสำหรับนวัตกรรมทางเทคนิค แต่มันคือกรณีศึกษาทางการตลาด บุคคลเหล่านี้ประสบความสำเร็จเพราะพวกเขามีทักษะในการดึงดูดความสนใจในภูมิทัศน์ที่แออัด ไม่ใช่แค่เพราะพวกเขามี AI เป็นผู้ช่วย
เราได้เข้าสู่ยุคที่ความสามารถในการผลิต code ไม่ใช่คอขวดอีกต่อไป ความท้าทายที่แท้จริงได้เปลี่ยนไปสู่การกระจายสินค้า (distribution) และที่สำคัญกว่านั้นคือ การแยกแยะประโยชน์ที่แท้จริงออกจากการโอ้อวดเพื่อ รวยเร็ว ที่แพร่หลายในอุตสาหกรรม
คนเหล่านี้ไม่ได้บังเอิญไปพบทางลัดที่เป็นความลับ แต่พวกเขาเพียงแค่พบวิธีที่จะใช้ความได้เปรียบที่มีอยู่เดิมของพวกเขาให้เร็วขึ้น (และอาจจะปลดล็อกมันได้เป็นครั้งแรก หากการเรียนเขียน code เคยเป็นอุปสรรคที่ใหญ่เกินไปสำหรับไอเดียโปรเจกต์เสริม)
มีการวางโครงร่างที่เป็นประโยชน์สำหรับการเปลี่ยนแปลงนี้:AI ได้ทำลายความได้เปรียบทางวิศวกรรมในฐานะตัวแยกความแตกต่างหลักไปอย่างสิ้นเชิง เมื่อนักพัฒนาคนไหนก็สามารถใช้ LLM เพื่อสร้างและปรับใช้ feature ที่ซับซ้อนได้ในเวลาเพียงเศษเสี้ยวของที่เคยใช้ ความสามารถในการเขียน code จึงไม่ใช่ความได้เปรียบในการแข่งขันอีกต่อไป การเป็นแค่ นักสร้าง นั้นไม่เพียงพออีกแล้ว
ในทางกลับกัน ความสำเร็จในตอนนี้ขึ้นอยู่กับปัจจัยที่เลียนแบบได้ยากด้วยระบบอัตโนมัติ นั่นคือ รสนิยม (Taste), จังหวะเวลา (Timing) และความเข้าใจอย่างลึกซึ้งถึงกลุ่มเป้าหมาย คุณสามารถสร้างผลิตภัณฑ์ได้ในวันหยุดสุดสัปดาห์ แต่มันจะไร้ค่าหากคุณสร้างสิ่งที่ผิด หรือเปิดตัวให้กับกลุ่มคนที่ไม่มีใครฟังคุณอยู่
ในสภาพแวดล้อมใหม่นี้ code กลายเป็นส่วนที่ง่าย ส่วนที่ยากยังคงเหมือนเดิมอย่างที่มันเคยเป็นมาตลอด: นั่นคือการหาวิธีทำให้ผู้คน สนใจ
WHO WINS
อันดับแรก คุณมีผู้เชี่ยวชาญเฉพาะด้าน (domain experts) ที่ติดอยู่กับปัญหาที่น่าเบื่อและซ้ำซาก จากนั้นก็มีทีมภายในที่สร้างเครื่องมือแบบใช้แล้วทิ้ง (throwaway tooling) ซึ่งเป็น script หรือแอปภายในที่ต้องการให้ทำงานได้ทันทีมากกว่าที่จะต้องดูสมบูรณ์แบบ Power users ก็ได้รับประโยชน์มหาศาลเช่นกัน โดยเฉพาะเมื่อพวกเขาต้องการแทนที่ workflow แบบแมนนวลที่เปราะบางด้วยสิ่งที่แข็งแกร่งกว่า และสุดท้าย มันคือชัยชนะของวิศวกรที่ให้ความสำคัญกับการเป็นเจ้าของโซลูชัน (Ownership) มากกว่าความสวยงามภายนอก
และใช่ — เครื่องมืออย่าง Claude Opus 4.5,Claude Code และ Cursor นั้นมีประโยชน์อย่างมากสำหรับวิศวกร พวกมันเก่งมากในการกำจัด Boilerplate, การเพิ่ม feature และการเขียน unit tests หนึ่งใน Use case ที่ผมชอบมากที่สุดในช่วงนี้ โดยเฉพาะตั้งแต่เริ่มงานใหม่ คือการสร้างเอกสารประกอบและคำแนะนำ feature แบบส่วนตัว เพื่อทำความเข้าใจ codebase ของผลิตภัณฑ์และการทำงานที่ละเอียดอ่อน — มันช่วยให้ผมปรับตัวได้เร็วขึ้นมาก
แต่ความจริงคือ:LLM ไม่ได้เขียน code ได้อย่างสมบูรณ์แบบ — แม้ว่ามันจะคอมไพล์ผ่านในครั้งแรกก็ตาม แม้จะมีการ prompt ที่มีคุณภาพและกฎระเบียบที่ชัดเจน โมเดลเหล่านี้ก็ยังคงทำผิดพลาด ในฐานะคนที่ใช้เครื่องมือเหล่านี้ทุกวัน คุณไม่สามารถเชื่อถือผลลัพธ์ของมันได้ทันที คุณยังต้องตรวจสอบ code ราวกับว่ามันเป็น Pull Request จากเพื่อนร่วมทีม คุณต้องอ่านตรรกะ ตรวจสอบสมมติฐาน และมักจะต้องแก้ไขด้วยตัวเองเพื่อให้มันถูกต้อง
ท้ายที่สุดแล้ว คุณก็น่าจะต้องส่งสิ่งนี้ไปให้เพื่อนร่วมทีมรีวิว — มันยุติธรรมไหมที่จะให้พวกเขารีวิวสิ่งที่คุณไม่ได้เขียน หรือแม้แต่ไม่ได้สนใจที่จะตรวจสอบมันเลย?
เครื่องมือเหล่านี้ช่วยให้คุณไปได้เร็วขึ้น แต่มันไม่ได้แทนที่ความจำเป็นของ สายตาที่วิพากษ์ (critical eye) หรือประสบการณ์หลายปีของคุณ และมันไม่ได้เข้าใจพื้นที่ของปัญหาโดยรวมได้ดีไปกว่าคุณ
กระแสการคาดหวังทำให้ดูเหมือนว่าเรากำลังเข้าสู่ยุคทองของ SaaS แต่เราไม่ใช่ เรากำลังเข้าสู่ยุคของ software ส่วนบุคคล: เครื่องมือที่คุณสร้างขึ้นมาเพื่อแก้ปัญหา แล้วก็ไปต่อ
ด้วยเงินเพียงยี่สิบเหรียญ เวลาว่างไม่กี่ชั่วโมง และความอดทนอีกนิดหน่อย ใครๆ ก็สามารถส่งมอบ application ที่ใช้งานได้จริง เรากำลังเข้าสู่ยุคของ personal software ที่ช่องว่างระหว่างไอเดียเริ่มต้นและผลิตภัณฑ์ที่ใช้งานได้นั้นแคบลงอย่างที่ไม่เคยมีมาก่อน
ในความเป็นจริงใหม่นี้ ความเชี่ยวชาญทางวิศวกรรมยังคงมีค่ามหาศาล แต่ลักษณะของบทบาทกำลังเปลี่ยนไป ความสำคัญไม่ได้จางหายไป แต่มันคือการใช้เครื่องมือเหล่านี้เพื่อสร้างในระดับที่สูงกว่าที่เคยเป็นไปได้ ความเชี่ยวชาญที่แท้จริงเป็นสิ่งจำเป็นในการควบคุมระบบเหล่านี้และให้การดูแลทางเทคนิคที่ LLM ยังขาดอยู่ในขณะนี้
ในขณะที่ AI เก่งในการเขียน code อย่างปฏิเสธไม่ได้ แต่มันยังคงอ่อนแอในการออกแบบระบบที่บำรุงรักษาได้ กระจายตัวได้ และขยายขนาดได้ นี่คือจุดที่ผู้นำที่ไม่ใช่สายเทคนิคที่คิดว่าสามารถไล่ทีมพัฒนาออกได้กำลังทำความผิดพลาดครั้งใหญ่ จนกว่าเราจะเห็นการมาถึงของ AI ที่ทำให้การอภิปรายทั้งหมดนี้ไร้ความหมาย การเชื่อว่าความเชี่ยวชาญทางเทคนิคสามารถแทนที่ได้ด้วยแค่การ prompt คือข้อผิดพลาดทางกลยุทธ์ การสร้าง software ที่แข็งแกร่งยังคงต้องการมนุษย์ที่เข้าใจหลักการพื้นฐานของงานฝีมือนี้
บรรทัดสุดท้ายคือ แม้เครื่องมือจะเปลี่ยนไป แต่พื้นฐานของวิศวกรรมที่ดีนั้นไม่เคยเปลี่ยน
แม้ว่ากำแพงในการเข้าถึงจะหายไป — แต่การตัดสินใจ (Judgment), รสนิยม (Taste) และความรับผิดชอบ (Responsibility) ยังคงเป็นหน้าที่ของเรา