เหตุผลที่ AI ยังไม่สามารถแทนที่วิศวกรซอฟต์แวร์ได้ และเหตุผลที่ต่อไปก็จะยังแทนที่ไม่ได้
(normaltech.ai)- วิศวกรรมซอฟต์แวร์เป็นอาชีพที่นำ AI มาใช้ได้รวดเร็ว แต่เรื่องเล่าว่าพอ AI ไปถึงระดับความสามารถหนึ่งแล้วจะเกิด การเลย์ออฟครั้งใหญ่ ยังไม่มีหลักฐานรองรับในตอนนี้
- ในกรณีของ Block, Snap และ Intuit มีการหยิบ AI มาเป็นเหตุผลของการเลย์ออฟ แต่เบื้องหลังจริงเชื่อมโยงโดยตรงกับ แรงกดดันทางการเงิน, ความต้องการลดต้นทุน และการลดชั้นการบริหารมากกว่า
- การพัฒนาซอฟต์แวร์มีโครงสร้างแบบ แซนด์วิชของการตัดสินใจ-การลงมือทำ-การส่งมอบ และ AI แม้จะบีบอัดชั้นการลงมือทำได้ แต่ชั้นที่ต้องตัดสินใจว่าจะสร้างอะไร รวมถึงตรวจสอบผลลัพธ์และรับผิดชอบต่อมัน ยังต้านทานการทำให้เป็นอัตโนมัติอย่างมาก
- “vibe coding” คือแนวทางที่ปล่อยให้เอเจนต์ทำงานโดยไม่มีการกำกับหรือรีวิว ขณะที่วิศวกรจริงใช้งานเอเจนต์ในรูปแบบ agentic engineering ที่มนุษย์ยังคงควบคุมและรับผิดชอบ
- หาก AI ทำให้ต้นทุนการผลิตซอฟต์แวร์ต่ำลง ก็อาจทำให้เกิดความต้องการซอฟต์แวร์เพิ่มขึ้น และแม้อาชีพของวิศวกรแต่ละคนอาจสั่นคลอน แต่ความต้องการโดยรวมก็มีแนวโน้มจะยังแข็งแรง
เหตุผลที่ AI ยังไม่สามารถแทนที่วิศวกรซอฟต์แวร์ได้ และเหตุผลที่ต่อไปก็จะยังแทนที่ไม่ได้
-
Coding agents as normal technology
- แม้ความกังวลและความไม่แน่นอนว่า AI จะมาแทนงานมีสูง แต่ถ้าจะมองประเด็นนี้ ต้องดูอาชีพ วิศวกรรมซอฟต์แวร์ ซึ่งเป็นกลุ่มที่ทั้งความสามารถของ AI และการนำไปใช้พัฒนาอย่างรวดเร็ว
- เรื่องเล่าว่าพอความสามารถ AI ถึงจุดวิกฤตหนึ่งแล้วจะเกิดการเลย์ออฟครั้งใหญ่ สามารถปัดตกได้จากหลักฐานที่มีอยู่
- หากแม้แต่ภาคส่วนที่แทบไม่มีอุปสรรคด้านกฎระเบียบก็ยังไม่เข้ากับเรื่องเล่าการเลย์ออฟครั้งใหญ่ ก็เป็นไปได้ว่าอาชีพอื่นจะมีชั้นกันกระแทกมากยิ่งกว่า
- งานใช้ความรู้และการพัฒนาซอฟต์แวร์สามารถมองเป็น decide-execute-deliver sandwich ได้ โดย AI บีบอัดชั้นการลงมือทำ แต่ชั้นการตัดสินใจและการส่งมอบไม่ได้ถูกทำให้เป็นอัตโนมัติได้เพียงเพราะความสามารถดีขึ้น
- อนาคตของความต้องการวิศวกรรมซอฟต์แวร์ยังพอมองในแง่ดีอย่างระมัดระวังได้ แต่ถึงความต้องการรวมจะยังดี เส้นทางอาชีพของวิศวกรรายบุคคลก็ยังอาจไม่มั่นคง
กรณีเลย์ออฟครั้งใหญ่จาก AI ในวงการซอฟต์แวร์ ใกล้เคียงกับ “AI washing” ตามแบบฉบับ
-
กรณีของ Block
- Block ประกาศเลย์ออฟพนักงาน 4,000 คนในเดือนกุมภาพันธ์ และ Jack Dorsey กล่าวว่า AI ทำให้เกิด “ทีมที่เล็กลงและแบนลง” ได้ พร้อมเอ่ยถึงความก้าวหน้าของความสามารถโมเดลภายในปลายปี 2025
- แต่รายงานหลังจากนั้นสะท้อนภาพอีกแบบว่า Block กำลังเผชิญ แรงกดดันทางการเงิน อย่างหนัก หลังจากเพิ่มจำนวนพนักงานมากกว่าสามเท่าในช่วงโรคระบาด
- Naoko Takeda นักวิทยาศาสตร์ข้อมูลในทีม Cash App เขียนว่า Block บังคับใช้ AI กับทุกคน แต่ผลด้านผลิตภาพมีจำกัดมาก และเธอเลือกลาออกหลังปฏิเสธข้อเสนอขึ้นเงินเดือนเพื่อให้อยู่ต่อ 75%
- พนักงานคนอื่นที่ให้สัมภาษณ์มีมุมมองต่างกันมากทั้งเรื่อง AI ทำอะไรได้จริงใน Block และ Dorsey เข้าใจประเด็นสำคัญถูกต้องหรือไม่
- Aaron Levie ชี้ว่า CEO มักสร้างต้นแบบได้เร็ว แต่ไม่เห็นงานอีก 90% ที่ต้องทำเพื่อให้กลายเป็นผลิตภัณฑ์สมบูรณ์ จึงหลงเชื่อประโยชน์ของ AI ได้ง่าย
-
กรณีของ Snap
- Snap เลย์ออฟพนักงานราว 1,000 คนในเดือนเมษายน และ Evan Spiegel ระบุ AI เป็นเหตุผลหลักในบันทึกการเลย์ออฟ
- Spiegel กล่าวว่า 65% ของโค้ดใหม่ถูกสร้างโดย AI
- แต่การเลย์ออฟจริงเกิดขึ้นหลังแคมเปญของนักลงทุนเชิงกิจกรรมที่เรียกร้องการลดต้นทุน
- Snap ขาดทุนสุทธิทุกปีนับตั้งแต่ IPO ในปี 2017 และราคาหุ้นในปี 2026 ก็ลดลงมากกว่า 30%
- ลักษณะของการลดคนคือการตัด 150 ตำแหน่งจากหลายบทบาทในฝ่าย augmented reality ซึ่งไม่สอดคล้องกับภาพการลดพนักงานสายโปรแกรมมิงหรือสายที่เสี่ยงต่อ AI ทั้งองค์กร หาก AI เป็นสาเหตุจริง
-
กรณีของ Intuit
- Intuit ประกาศลดพนักงาน 3,000 คนในเดือนพฤษภาคม และมีข่าวเรื่องสัญญากับ Anthropic และ OpenAI ควบคู่กันไป
- สื่อมวลชนโยงสิ่งนี้เข้ากับการปรับโครงสร้างที่เน้น AI แต่ CEO โต้ว่า การลดคนไม่เกี่ยวกับ AI
- บริษัทระบุว่าผู้ที่ถูกลดจำนวนคือบทบาทที่ “ต้องประสานงานมาก” และชั้นการบริหารที่มากเกินไป
- กรณีของ Block, Snap และ Intuit แสดงให้เห็นว่า AI มักถูกใช้เป็นเหตุผลผิวเผินของการเลย์ออฟ แต่เบื้องหลังโดยตรงกว่าคือสภาพองค์กรและโครงสร้างต้นทุน
-
AI washing เป็นปรากฏการณ์ทั้งระบบเศรษฐกิจ
- ทุกเรื่องเล่าการเลย์ออฟวิศวกรรมซอฟต์แวร์จาก AI ที่นำมาตรวจสอบ ล้วนมีความไม่สอดคล้องของเรื่องเล่าแบบเดียวกัน
- ผู้จัดการฝ่ายจ้างงานในสหรัฐ 59% ยอมรับว่า เวลาอธิบายการหยุดจ้างหรือการเลย์ออฟ การเน้น AI แทนข้อจำกัดทางการเงินจะทำให้ผู้มีส่วนได้ส่วนเสียยอมรับได้ง่ายกว่า
- J. P. Gownder จาก Forrester บอกว่าเมื่อถามบริษัทที่เตรียมเลย์ออฟเพราะ AI ว่ามีแอป AI ที่สุกงอมและผ่านการพิสูจน์แล้วหรือไม่ สิบแห่งมีถึงเก้าแห่งที่ไม่มี และยังไม่เริ่มด้วยซ้ำ
- ในการสำรวจของ HBR จากผู้บริหารกว่า 1,000 คนทั่วโลก 21% ระบุว่าลดคนครั้งใหญ่เพราะ “คาดการณ์ล่วงหน้า” เรื่อง AI และ 39% ลดเชิงรุกในระดับต่ำหรือปานกลาง
- แต่สัดส่วนที่ลดคนครั้งใหญ่จากการใช้งาน AI จริงมีเพียง 2% ซึ่งสะท้อนช่องว่างขนาดใหญ่ระหว่างการลดคนบนฐานความคาดหวังกับบนฐานการนำไปใช้จริง
-
ข้อมูลจาก WARN Act
- WARN Act กำหนดให้มีการเปิดเผยบางอย่างสำหรับการปิดกิจการและการเลย์ออฟครั้งใหญ่ที่กระทบแรงงานเกิน 100 คน
- รัฐนิวยอร์กเพิ่มช่องติ๊กเปิดเผย AI ในแบบฟอร์มยื่น WARN Act เมื่อเดือนมีนาคม 2025 เป็นรัฐแรกในสหรัฐ
- ตลอดปีแรก มีบริษัทมากกว่า 160 แห่งยื่นแจ้ง WARN แต่ไม่มีบริษัทใดติ๊กช่อง AI เลย
- จนถึงปลายเดือนพฤษภาคม ตามการยืนยันของกระทรวงแรงงานนิวยอร์ก มีเพียง Nespresso แห่งเดียวที่เลือกช่องดังกล่าว
- หากเอกสารที่ยื่นมีความถูกต้อง ในช่วงเวลาดังกล่าว จากผู้ถูกเลย์ออฟในรัฐนิวยอร์กราว 25,000 คน มีเพียง 46 คน หรือราว 0.2% ที่ได้รับผลกระทบจาก AI
-
การเลย์ออฟเป็นสัญญาณผิดสำหรับดูผลผลิตจาก AI
- มีงานวิจัยชี้ว่า ผลผลิตจาก AI มักทำงานผ่าน การชะลอการจ้างงาน มากกว่าการเลย์ออฟพนักงานเดิมจำนวนมาก
- หากเลย์ออฟพนักงานเดิม บริษัทจะสูญเสียความรู้ฝังลึกและทุนทางองค์กรที่จำเป็นต่อการใช้ AI อย่างมีประสิทธิภาพ
- การเลย์ออฟยังมีต้นทุนสูง ทั้งค่าชดเชย ขวัญกำลังใจที่ตกต่ำ และความเสี่ยงเมื่อต้องจ้างกลับ
- เพียงอาศัยการลดลงตามธรรมชาติของจำนวนพนักงานก็อาจได้ผลลัพธ์เดียวกันในไม่กี่ปี จึงทำให้การเลย์ออฟครั้งใหญ่มักไม่จำเป็น
-
ข้อมูลแนวโน้มการจ้างงาน
- งานวิจัย ของนักเศรษฐศาสตร์จาก Federal Reserve รวบรวมหลักฐานที่เกี่ยวข้องในบริบทสหรัฐ
- การจ้างงานยังคงเพิ่มขึ้น แต่หลัง ChatGPT อัตราเติบโตช้ากว่าเส้นทางสมมติที่ไม่มี AI อยู่ราว 3 จุดเปอร์เซ็นต์ต่อปี
- วิธีวิจัยนี้จับงานอิสระไม่ได้ จึงเป็นไปได้ว่าส่วนหนึ่งของการชะลอลงถูกดูดซับไปในรูปการก่อตั้งกิจการ
- งานวิจัยอื่นให้หลักฐานว่า AI ทำให้การเริ่มต้นกิจการง่ายขึ้น
- ภาพจริงอาจแข็งแรงกว่าที่งานของ Federal Reserve แสดงไว้
-
การสูญเสียงานจาก AI ที่มีอยู่จริงแต่เป็นคนละแบบ
- งานวิศวกรรมซอฟต์แวร์อาจหายไปได้ หาก AI ไปลดความต้องการของผลิตภัณฑ์นั้นเอง
- Chegg และ Stack Overflow ถูกยกเป็นตัวอย่างที่ AI ลดความต้องการผลิตภัณฑ์ช่วยทำการบ้านหรือช่วยด้านเทคนิค และทั้งสองบริษัทต่างก็มีการเลย์ออฟ
- ในกรณีนี้ AI ไม่ได้ลงมือทำงานของแรงงานโดยตรง แต่ทำให้ความจำเป็นของงานนั้นลดลง
- จาก 270 อาชีพในสำมะโนประชากรสหรัฐปี 1950 อาชีพที่หายไปเพราะระบบอัตโนมัติมีเพียงคนควบคุมลิฟต์อาชีพเดียว แต่มีอีกหลายอาชีพ เช่น พนักงานโทรเลข ที่หมดความจำเป็นเพราะเทคโนโลยีใหม่
- การเลย์ออฟในบริษัทอย่าง IBM หรือ SAP ซึ่งขาย AI มากกว่าซื้อ AI ก็ใกล้เคียงกับการปรับโครงสร้างองค์กรทั่วไปที่ย้ายคนจากฟังก์ชันเดิมไปยังสายผลิตภัณฑ์ที่เติบโตเร็ว มากกว่าการแทนที่แรงงานโดยตรง
เหตุผลที่ coding agents ยังไม่ได้นำไปสู่การแทนที่แรงงาน: decide-execute-deliver sandwich
-
สัดส่วนโค้ดที่ AI เขียนแทบไม่เชื่อมกับการแทนที่แรงงาน
- ผู้นำด้านเทคโนโลยีบางคนมักยกสัดส่วนโค้ดที่ AI เขียนควบคู่ไปกับการเลย์ออฟหรือการคาดการณ์ว่างานจะลดลงในอนาคต
- วิธีคิดนี้เสริมมุมมองง่าย ๆ ว่า ถ้า AI เขียนโค้ดทั้งหมดได้ ก็ไม่ต้องมีโปรแกรมเมอร์อีก
- แต่สัดส่วนโค้ดที่ AI เขียนแทบไม่เกี่ยวกับตัวชี้วัดหลักในการตัดสินการแทนที่แรงงาน
- การเขียนโค้ดไม่ใช่คอขวด และที่ผ่านมาในอดีตก็ไม่เคยเป็นคอขวด
-
การเขียนโค้ดไม่ใช่คอขวด
- งานวิจัยปี 2019 ที่สังเคราะห์งานก่อนหน้า สรุปว่านักพัฒนาใช้เวลาทำโค้ดจริงเพียง 9% ถึง 61% ตามแต่ละการศึกษา ซึ่งน้อยอย่างน่าประหลาดใจ
- ผลนี้สอดคล้องกับข้อมูลภายในของ Microsoft จากนักพัฒนา 6,000 คน
- หลังเริ่มมีการใช้งาน coding agents อย่างจริงจัง มีหลายบทความในปลายปี 2025 ที่ชี้ว่าการเขียนโค้ดไม่ใช่คอขวด
- นักพัฒนาตระหนักว่า แม้ให้เอเจนต์เขียนโค้ดส่วนใหญ่ ผลกระทบต่อผลิตภาพรวมก็ยังเล็ก
-
คอขวดจริงสามอย่าง
- คอขวดจริงคือการตัดสินใจและกำหนดสเปกว่าอะไรควรถูกสร้างขึ้น
- การตรวจสอบผลลัพธ์ที่ส่งมอบและรับผิดชอบต่อมันก็เป็นคอขวดหลักเช่นกัน
- ความเข้าใจเชิงลึกของมนุษย์ ต่อ codebase, ธุรกิจ และสภาพแวดล้อม เป็นสิ่งจำเป็นทั้งในส่วนของการตัดสินใจและการส่งมอบ
- งานของวิศวกรซอฟต์แวร์จึงเป็นแซนด์วิชของการตัดสินใจ-การลงมือทำ-การส่งมอบ และความเข้าใจคือเงื่อนไขล่วงหน้าของทั้งสามชั้น
- AI บีบอัดส่วนกลางของแซนด์วิช แต่ปลายทั้งสองด้านแทบยังคงเดิม
-
หลักฐานจาก “Writing Code vs. Shipping Code”
- Writing Code vs. Shipping Code วิเคราะห์ผลผลิตจาก AI กับนักพัฒนา GitHub จำนวน 100,000 คน
- เอเจนต์ AI ทำให้จำนวนบรรทัดโค้ดที่เขียนเพิ่มขึ้น 8 เท่า ซึ่งสอดคล้องกับคำอธิบายว่าชั้นการลงมือทำถูกบีบอัดอย่างมาก
- แต่การเพิ่มขึ้นของการปล่อยซอฟต์แวร์มีเพียง 30% ซึ่งชี้อย่างชัดเจนว่าคอขวดฝั่งมนุษย์ในชั้นการตัดสินใจและการส่งมอบยังคงอยู่
-
ชั้นการตัดสินใจทำให้บางลงได้ยากกว่า
- ทีมพัฒนาต้องตัดสินใจว่าจะสร้างอะไร
- บทเรียนสำคัญอย่างหนึ่งที่วิศวกรซอฟต์แวร์รุ่นจูเนียร์เรียนรู้คือ การระบุ requirement ใช้เวลานานกว่าที่คิด
- หากบีบขั้นตอนกำหนด requirement ให้สั้นเกินไป ความเจ็บปวดจะไประเบิดในขั้นตอนถัด ๆ ไป
- ชั้นนี้ทำให้เป็นอัตโนมัติได้ยาก เพราะต้องคำนึงถึงความต้องการของผู้ใช้ สัญญาณจากตลาด ลำดับความสำคัญขององค์กร และในบางกรณีก็รวมถึงข้อจำกัดด้านกฎระเบียบ
- เมื่อความสามารถของ AI ดีขึ้น ประเภทของการตัดสินใจที่มอบหมายให้ AI ได้จะเพิ่มขึ้น แต่การตัดสินใจที่มอบหมายได้ก็จะไม่ใช่แหล่งของความได้เปรียบในการแข่งขันอีกต่อไป
- คุณค่าของการตัดสินใจโดยมนุษย์จึงย้ายขึ้นไปในระดับที่สูงกว่า และเพราะความซับซ้อนของซอฟต์แวร์เพิ่มขึ้นตามเวลา กระบวนการนี้จึงไม่มีเพดานที่ชัดเจน
-
ชั้นการส่งมอบยังคงอยู่เพราะความรับผิดชอบและการตรวจสอบ
- ทีมมนุษย์ต้องรับผิดชอบต่อผลลัพธ์ที่ตนส่งมอบ
- ในอนาคตอาจมีช่วงเวลาที่ทีมยอม deploy โค้ดที่มีความสำคัญต่อภารกิจโดยที่ยังทดสอบหรือเข้าใจไม่เพียงพอ
- แต่ในปัจจุบัน AI ยังไม่เสถียรมากพอ ทำให้แนวทางไร้ระเบียบเช่นนั้นเป็นภัยคุกคามระดับอยู่รอดต่อทั้งทีมซอฟต์แวร์และลูกค้า
- ต่อให้กำแพงทางเทคนิคหายไป ก็ไม่ได้แปลว่ามนุษย์จำเป็นต้องยกการควบคุมให้ AI
- เรายังเลือกคงความรับผิดชอบของมนุษย์ไว้ได้ผ่านบรรทัดฐานร่วม กฎหมาย และนโยบาย
- กฎหมายความรับผิดและกฎกำกับเฉพาะภาคส่วนได้ทำหน้าที่เป็นกำแพงด้านความเร็วอยู่แล้ว และอาจเข้มงวดยิ่งขึ้นได้อีก
-
วิศวกรซอฟต์แวร์ในอนาคตจะคล้ายคนคุมเครนมากขึ้น
- ยิ่งมีการมอบหมายชั้นการลงมือทำให้ AI มากขึ้น บทบาทของวิศวกรซอฟต์แวร์ก็จะยิ่งคล้ายคนคุมเครน
- เอเจนต์ AI จะทำงานหนักเชิงความคิดส่วนใหญ่ ขณะที่หน้าที่หลักของมนุษย์คือกำกับและควบคุมเอเจนต์
- บางคนโต้ว่าอนาคตที่มนุษย์ยังควบคุมอยู่จะเป็นไปไม่ได้เพราะต้นทุน
- แต่กรณี coding agents ที่ขาดการกำกับลบฐานข้อมูล production หรือสร้างความเสียหายอื่น ๆ ได้กลายเป็นข่าวฮือฮามาแล้ว
- กรณีเหล่านี้น่าจะเป็นเหตุการณ์ยกเว้นที่ถูกเผยแพร่เพราะความช็อก มากกว่าจะเป็นบรรทัดฐานใหม่ และยังเป็นบทเรียนให้ระวังการพึ่งพา AI มากเกินไป
- การตรวจจับว่าการใช้ AI แบบขาดการกำกับในงานเสี่ยงสูงกำลังเพิ่มขึ้นหรือไม่ เป็นช่องว่างข้อมูลสำคัญ ไม่เฉพาะในวิศวกรรมซอฟต์แวร์แต่รวมถึงทั้งเศรษฐกิจ
-
การหดตัวของงานโปรแกรมมิงไม่ใช่ปรากฏการณ์เฉพาะ AI
- แนวโน้มที่แซนด์วิชถูกบีบอัดนั้นใหม่ก็จริง แต่ไม่ใช่ผลจาก AI เพียงอย่างเดียว
- กว่า 20 ปีก่อน Bureau of Labor Statistics เริ่มแยกติดตามโปรแกรมมิงออกจากวิศวกรรมซอฟต์แวร์
- กล่าวคร่าว ๆ โปรแกรมเมอร์ทำหน้าที่เฉพาะชั้นการลงมือทำ ขณะที่วิศวกรซอฟต์แวร์ดูแลส่วนที่ใหญ่กว่าของแซนด์วิช
- งานโปรแกรมมิงหดตัวลง และถูกมองว่าเป็นงานลงมือทำอย่างเดียว จึงมีค่าตอบแทนต่ำกว่ามาก
- AI กำลังเร่งแนวโน้มเก่านี้ และลดคุณค่าของทักษะเชิงเทคนิคแบบลงมือทำล้วน ๆ ลงอีก
- รูปแบบที่มนุษย์มีส่วนลึกในปลายทั้งสองด้านคือการตัดสินใจและการส่งมอบ ขณะที่ AI ทำให้ชั้นกลางของการลงมือทำเป็นอัตโนมัติ อาจนำไปใช้กว้างขวางกับงานใช้ความรู้โดยรวม
Vibe coding ไม่ใช่ agentic engineering
-
ความสับสนของคำศัพท์
- คำว่า “vibe coding” ถูกใช้อย่างไม่แม่นยำเพื่อหมายถึงแนวปฏิบัติที่กว้างมาก จนทำให้เกิดความสับสนเกี่ยวกับการเปลี่ยนแปลงในวิศวกรรมซอฟต์แวร์
- ใน vibe coding แบบแท้จริง ผู้ใช้เพียงบอกเอเจนต์ว่าต้องการให้ทำอะไร จากนั้นก็ไม่กำกับระหว่างการทำงานและไม่รีวิวโค้ด
- ผู้ใช้นี้อาจไม่มีความสามารถพอจะรีวิวโค้ด และอาจประเมินผลลัพธ์ไม่ได้เลย เว้นแต่จะพังแบบเห็นได้ชัด
- นี่ต่างจากวิธีที่วิศวกรซอฟต์แวร์ส่วนใหญ่ใช้งานเอเจนต์
-
Agentic engineering
- วิศวกรซอฟต์แวร์ส่วนใหญ่ใช้งานเอเจนต์ในฐานะเครื่องมือ โดยที่มนุษย์ยังคงควบคุมและรับผิดชอบต่อผลลัพธ์
- คำว่า agentic engineering กำลังแพร่หลายเพื่อเรียกแนวปฏิบัตินี้
- เมื่อ agentic engineering กลายเป็นมาตรฐาน วิศวกรก็พบว่าการกำกับ coding agents ใช้เวลามากกว่าที่คาด
- Simon Willison กล่าวว่าเพียงกำกับเอเจนต์ไปถึงราว 11 โมงเช้าก็หมดแรงทางสมองแล้ว ซึ่งสอดคล้องกับประสบการณ์จริง
-
ข้อมูล SWE-chat
- SWE-chat เป็นชุดข้อมูลปฏิสัมพันธ์กับ coding agents ของนักพัฒนาโอเพนซอร์สที่เข้าร่วมเครื่องมือล็อกข้อมูลโดยสมัครใจ
- ในงานวิจัยนี้ โค้ดที่เอเจนต์สร้างขึ้นและยังคงอยู่จนถึงขั้น commit ของผู้ใช้มีสัดส่วน 44%
- commit แบบ vibe-coded นำช่องโหว่เข้ามาด้วยอัตราสูงกว่า commit ที่มนุษย์เขียนเองถึง 9 เท่า
- เจตนาของผู้ใช้ที่พบบ่อยที่สุดไม่ใช่การสร้างโค้ดใหม่ แต่คือการทำความเข้าใจโค้ดเดิม โดยมีสัดส่วน 19% เทียบกับ 13%
- ชุดข้อมูลนี้เป็นตัวอย่างแบบสมัครใจเลือกเอง จึงยังใช้สรุปเชิงหนักแน่นจากงานนี้เพียงชิ้นเดียวไม่ได้
- ถึงอย่างนั้น ก็ยังช่วยเสริมหลักฐานอื่นว่า vibe coding และ agentic engineering เป็นคนละรูปแบบกัน
-
ความแตกต่างสำคัญ
- vibe coding กับ agentic engineering ไม่ใช่สองหมวดที่แยกขาดจากกันโดยสมบูรณ์ แต่เป็นปลายสองด้านของสเปกตรัม
- ไม่ใช่ทุกโปรเจกต์จะเป็นแค่โปรเจกต์ใช้ครั้งเดียวหรือโปรเจกต์ที่สำคัญต่อภารกิจ
- ไม่ใช่ทุก workflow จะตรงกับคอลัมน์ซ้ายหรือขวาในตารางได้พอดี
- นัยสำคัญต่อประเด็นเรื่องงานคือ บริษัทไม่สามารถจ้าง vibe coder ที่ยังไม่ผ่านการพิสูจน์มาแทนวิศวกรซอฟต์แวร์ แล้วนำซอฟต์แวร์ production ไปใช้งานจริงได้
ต่อจากนี้จะเกิดอะไรขึ้น
-
เหตุผลที่ภาพการเลย์ออฟครั้งใหญ่จึงเกิดได้ยาก
- ผู้สนับสนุน AI อาจอ้างว่า การเลย์ออฟครั้งใหญ่เพียงแค่ยังมาไม่ถึง
- แต่หากโมเดลแซนด์วิชนี้ถูกต้อง การคาดการณ์แบบนั้นก็จะไม่เกิดขึ้นจริง
- AI ได้บีบอัดชั้นกลางของแซนด์วิชไปมากแล้ว และการบีบอัดนี้จริง ๆ เริ่มมาตั้งแต่หลายสิบปีก่อน
- ต่อให้ชั้นการลงมือทำกลายเป็นสิ่งที่ทันทีและสมบูรณ์แบบ การเปลี่ยนแปลงจากจุดปัจจุบันก็ยังเล็ก
- เหตุผลที่ชั้นการตัดสินใจและการส่งมอบต้านทาน AI ไม่ใช่เพราะข้อจำกัดด้านความสามารถ
-
ความต้องการวิศวกรซอฟต์แวร์อาจเพิ่มขึ้น
- ไม่เพียงแต่งานวิศวกรรมซอฟต์แวร์จะไม่หายไปเพราะ AI แต่ความต้องการอาจเพิ่มขึ้นด้วย
- เมื่อผลิตภาพทางเทคโนโลยีทำให้ต้นทุนการสร้างซอฟต์แวร์ต่ำลง ผู้คนก็จะซื้อซอฟต์แวร์มากขึ้น
- ในเชิงเศรษฐศาสตร์ ซอฟต์แวร์เป็นสินค้าที่มีความยืดหยุ่นต่อราคาสูง
- หาก AI ไม่ได้แทนที่วิศวกรซอฟต์แวร์ ความต้องการซอฟต์แวร์ที่เพิ่มขึ้นก็จะนำไปสู่ความต้องการวิศวกรซอฟต์แวร์ที่เพิ่มตาม
- “Jevons’ paradox” เป็นคำทางเศรษฐศาสตร์ที่มักถูกใช้ในวงถกเถียงเรื่อง AI เพื่ออธิบายแนวคิดนี้
-
รูปแบบทางประวัติศาสตร์
- การจ้างงานโปรแกรมเมอร์ในสหรัฐเคยเกือบเป็นศูนย์ราวปี 1950 แต่วันนี้เพิ่มขึ้นเป็นหลักล้านคน
- สิ่งนี้ต่างอย่างมากจากอาชีพอย่างเกษตรกรรม ที่ความต้องการแรงงานลดลงมากเพราะเครื่องจักรและระบบอัตโนมัติ
- การบริโภคแคลอรีของคนค่อนข้างคงที่ แต่ปริมาณซอฟต์แวร์ที่ผลิตออกมาเพิ่มขึ้นได้เป็นล้านเท่า
- รถยนต์สมัยใหม่มีโค้ดราว 100 ล้านบรรทัด ทำงานอยู่บนคอมพิวเตอร์ออนบอร์ดหลายตัว
- ต่อให้มีเพดานของความต้องการโค้ด ตอนนี้เราก็ยังไม่อยู่ใกล้มัน
- งานทางความคิดแทบทุกประเภทได้รับประโยชน์จากซอฟต์แวร์ และเมื่อ AI ลดต้นทุนการเขียนโค้ด ก็เกิด utility แบบใช้ครั้งเดียวทั้งเพื่อการทำงานและใช้ส่วนตัวมากขึ้น
-
ไม่ได้แปลว่ามีแต่ Big Tech ที่จะใหญ่ขึ้น
- อนาคตอาจมีซอฟต์แวร์มากขึ้นมาก และมีวิศวกรซอฟต์แวร์มากขึ้นด้วย แต่ไม่ได้แปลว่าบริษัทเทคใหญ่จะยิ่งขยายตัวเสมอไป
- ปัจจุบันวิศวกรซอฟต์แวร์ส่วนใหญ่ทำงานอยู่ในองค์กรภายในของบริษัทที่ไม่ใช่บริษัทซอฟต์แวร์อยู่แล้ว
- สัดส่วนนี้อาจยิ่งเพิ่มขึ้นอีกในอนาคต
- “AI rollups” หมายถึงแนวคิดที่ venture capital หรือ private equity ซื้อกิจการธุรกิจ Main street อย่างคลินิกทันตกรรมหรือสำนักงานบัญชี แล้วใส่วิศวกรซอฟต์แวร์หรือวิศวกร AI เข้าไปเพื่อทำให้กลายเป็น AI-native อีกครั้ง
- แนวคิดนี้อาจจบลงเป็นเพียงกระแสเกินจริง และยังเร็วเกินไปที่จะตัดสิน
-
ข้อโต้แย้งต่อการคาดการณ์เรื่องประชาธิปไตยของซอฟต์แวร์
- บางคนคาดว่า AI จะทำให้วิศวกรรมซอฟต์แวร์เป็นของคนทั่วไปมากขึ้น และทำให้ความต้องการวิศวกรรมซอฟต์แวร์ลดลง
- มุมมองนี้เห็นว่าทั้งปริมาณซอฟต์แวร์ที่ผลิตและเวลาของมนุษย์ที่ใช้ผลิตซอฟต์แวร์จะเพิ่มขึ้น แต่ผู้ที่ทำงานนั้นจะไม่ใช่วิศวกรซอฟต์แวร์
- ตัวอย่างเช่น พวกเขาเชื่อว่าซอฟต์แวร์ด้านกฎหมายอาจถูกสร้างโดยคนที่มีพื้นฐานกฎหมายได้ง่ายกว่าคนที่ผ่านการฝึกด้านวิศวกรรมซอฟต์แวร์
- ข้ออ้างเช่นนี้ติดกับดักจากการสับสนระหว่าง vibe coding กับ agentic engineering และระหว่างชั้นการลงมือทำกับแซนด์วิชทั้งก้อน
- ภาษาอย่าง FORTRAN, COBOL และ SQL ในอดีตก็เคยมาพร้อมความหวังว่าจะทำให้การเขียนโปรแกรมเป็นประชาธิปไตยมากขึ้น แต่สิ่งนั้นก็ไม่เกิดขึ้น
- กำแพงที่แท้จริงไม่ใช่การเรียนรู้ไวยากรณ์ แต่คือวิจารณญาณที่ชำนาญในการตัดสินใจที่ดีโดยยังคงความรับผิดชอบไว้ได้
-
เส้นทางอาชีพรายบุคคลอาจเกิดการปรับโครงสร้างครั้งใหญ่
- เมื่อเวลาผ่านไป เวลาที่ผู้คนใช้เพื่อทำให้คอมพิวเตอร์ทำสิ่งใหม่ ๆ มีแนวโน้มเพิ่มขึ้นมาก
- กิจกรรมนี้อาจอยู่ในรูปการสร้างซอฟต์แวร์ การจัดการ workflow ที่ซับซ้อนด้วยเอเจนต์ หรืออยู่ในรูปแบบอื่น
- ความสามารถที่จำเป็นจะเป็นการผสมกันของทักษะซอฟต์แวร์ ทักษะ AI และความเชี่ยวชาญเชิงโดเมน
- ยังไม่ชัดว่าวิศวกรซอฟต์แวร์ในปัจจุบันจะเป็นกลุ่มที่ปรับตัวเข้ากับบทบาทใหม่นี้ได้ดีที่สุดหรือไม่
- แม้ความต้องการแรงงานซอฟต์แวร์โดยรวมจะแข็งแรง ก็ไม่ได้หมายความว่าแรงงานแต่ละคนจะไม่ได้รับผลกระทบ
- AI กำลังก่อให้เกิดการเปลี่ยนแปลงเชิงโครงสร้างครั้งใหญ่ในวิธีการผลิตซอฟต์แวร์ และวิศวกรคนใดจะได้ประโยชน์หรือเสียประโยชน์จะขึ้นอยู่กับประเภทบริษัทที่ทำงาน ภูมิภาค ระดับประสบการณ์ และความเร็วในการปรับตัว
1 ความคิดเห็น
ความคิดเห็นจาก Hacker News
ตลอดประวัติศาสตร์ของอุตสาหกรรมคอมพิวเตอร์ เราพยายามทำ ระบบอัตโนมัติในงานวิศวกรรมซอฟต์แวร์ อย่างจริงจังและต่อเนื่องมาโดยตลอด และทุกครั้งก็ทำให้เราสร้างสิ่งที่ใหญ่ขึ้นและดีขึ้นได้เร็วกว่าเดิม
เมื่อผลิตภาพเพิ่มขึ้น มูลค่าของงานก็เพิ่มขึ้น และความคาดหวังก็สูงขึ้นตามไปด้วย จนถึงตอนนี้ความต้องการซอฟต์แวร์ของโลกก็ยังดูไม่มีที่สิ้นสุด
เหตุผลที่ AI ยังแทนที่วิศวกรซอฟต์แวร์ไม่ได้ คือทุกครั้งที่ผลิตภาพเพิ่มขึ้น เป้าหมายปลายทางก็ขยับออกไปด้วย
มีสองกรณีที่แนวโน้มนี้จะสิ้นสุดลง กรณีแรกคือในที่สุดผลิตภาพสูงพอที่จะตอบสนองความต้องการซอฟต์แวร์ของโลกได้ครบ
ตอนนี้ยังไม่เห็นหลักฐานแบบนั้น และต้องอธิบายให้ชัดว่าทำไมครั้งนี้ถึงต่างจากประวัติศาสตร์ทั้งมวลของอุตสาหกรรมคอมพิวเตอร์
กรณีที่สองคือเมื่อ AI สามารถลงมือทำงานได้ด้วยตัวเองจนกลายเป็น วิศวกรซอฟต์แวร์ที่เก่งกว่ามนุษย์
กล่าวคืออยู่ในสภาพที่ AI+นักพัฒนามนุษย์ไม่ได้ดีกว่า AI ล้วน ๆ แต่หลักฐานเท่าที่มีตอนนี้ชี้ว่า AI เป็นตัวขยายศักยภาพของนักพัฒนา และถ้าจะให้ได้ผลลัพธ์ที่ดี ผู้เชี่ยวชาญยังต้องเป็นคนกำหนดทิศทาง ขณะที่ AI ทำงานได้มากสุดราว 90%
ยังไม่มีหลักฐานหนักแน่นว่าอย่างใดอย่างหนึ่งในสองกรณีนี้จะเกิดขึ้นในอนาคตอันใกล้ ดังนั้นวิศวกรซอฟต์แวร์น่าจะยังปลอดภัยไปอีกพักหนึ่ง
แต่ถ้าทักษะของคุณแคบและเน้นอยู่แค่บางพื้นที่ เช่น งานพัฒนาเว็บฝั่งฟรอนต์เอนด์ ก็น่ากังวลมากกว่า
ต่อให้ AI แทนที่วิศวกรซอฟต์แวร์ทั้งหมดไม่ได้ ก็มีโอกาสสูงทีเดียวที่มันจะกลืนบางโดเมนไปทั้งหมดในรูปแบบที่มีคนสาย generalist เป็นผู้คุมเกม
ตอนนี้โดยรวมแล้วเราสร้างซอฟต์แวร์มากเกินกว่าสิ่งที่ผู้คนต้องการจริง ๆ ไปแล้ว และส่วนไม่น้อยก็มีตั้งแต่ขยะ การหลอกลวงแบบโจ่งแจ้ง ไปจนเกือบจะเป็นมัลแวร์
สุดท้ายแล้วซอฟต์แวร์เล็ก ๆ ที่คนทั่วไปต้องใช้ เช่น การจัดการรายการสิ่งที่ต้องทำหรือการซิงก์ไฟล์ น่าจะถูกเขียนแบบปรับเฉพาะบุคคลโดย AI ของแต่ละคน ส่วนวิศวกรซอฟต์แวร์คงเหลืออยู่กับโครงการใหญ่ขององค์กรเท่านั้น
ตลอดหลายทศวรรษที่ผ่านมา แนวโน้มที่โดดเด่นอย่างท่วมท้นของซอฟต์แวร์เชิงพาณิชย์คือ การไม่ปรับแต่งให้ผู้ใช้อย่างสุดขั้วในแบบต่อต้านผู้ใช้
เหลือไว้แค่เส้นทางการใช้งานแบบเดียว ถ้าไม่ตรงกับความต้องการก็ไปหาทางเอง
ซอฟต์แวร์เชิงพาณิชย์สำหรับคนทั่วไปแทบไม่มีแล้ว และแม้แต่โอเพนซอร์สก็ยิ่งห่างจากผู้ใช้ทั่วไปมากขึ้น
อีกไม่นานคนธรรมดาก็จะสร้างซอฟต์แวร์เพื่อแก้ปัญหาในแบบของตัวเองได้โดยตรง
ในกรณีส่วนใหญ่ คุณภาพและความแม่นยำไม่ได้สำคัญขนาดนั้น สิ่งที่สำคัญกว่าคือมันปรับให้เข้ากับตัวเองได้ ฟรี และไม่ใช่แพลตฟอร์มสอดส่อง/โฆษณาแบบล่วงล้ำ
ในฐานะนักพัฒนาฟรอนต์เอนด์ ผมมองว่าโมเดลล้ำสมัยตอนนี้ทำงาน ท่อประปาด้านหลังบ้าน ที่น่าเบื่อและผมไม่อยากสนใจได้ดี แต่ยังทำงานออกแบบที่ปรับตามความต้องการจริงของลูกค้าได้ไม่เก่งนัก
ไม่ได้หมายความว่าใครถูกหรือผิดอย่างชัดเจน และผมก็เห็นด้วยว่าความกว้างของทักษะแบบทั่วไปน่าจะเป็นวิธีที่ดีที่สุดในการประสบความสำเร็จในยุคใหม่
เพียงแต่ LLM ยังไม่ได้ยึดครองส่วนใดส่วนหนึ่งของสแตกอย่างสมบูรณ์จนผู้เชี่ยวชาญในส่วนนั้นหายไป
จากการวิเคราะห์ล่าสุด จำนวนแอปที่เปิดตัวเพิ่มขึ้นมาก แต่จำนวนรีวิวรวมและยอดดาวน์โหลดยังทรงตัว
หมายความว่าแอปมีมากขึ้นมาก แต่จำนวนผู้ใช้แทบไม่เพิ่ม หรือแทบไม่เพิ่มเลย
ดู p40 / figure 12 ของ "WRITING CODE VS. SHIPPING CODE: PRODUCTIVITY EFFECTS ACROSS GENERATIONS OF AI CODING TOOLS": https://www.nber.org/system/files/working_papers/w35275/w352...
บทวิเคราะห์อยู่ที่หน้า 42~43
จะบอกว่านี่พิสูจน์แล้วว่าขนาดพายคงที่ก็คงไม่ได้ แต่ในทางกลับกันก็พิสูจน์ไม่ได้เหมือนกันว่าพายนั้นไม่มีที่สิ้นสุด
ประเด็นสำคัญที่คนมักมองข้ามเวลาเล่าเรื่องการเติบโตทางเศรษฐกิจของซอฟต์แวร์ คือเงินต้องมาจากที่ไหนสักแห่ง
ถ้าจะเติบโตต่อไป ก็ต้องมีคนที่ตอนนี้ยังไม่จ่ายเงินให้ซอฟต์แวร์เริ่มจ่ายขึ้นมาใหม่ และต้องดูว่าคนเหล่านั้นคือใคร มีเงินอยู่เท่าไร และต้องแข่งขันกับค่าใช้จ่ายอื่นอะไรบ้าง
หลายบริษัทยังพึ่งพา สเปรดชีตที่ปรับแต่งเอง หรือเทคโนโลยีอย่าง Microsoft Access อยู่
เพราะมันทำงานที่ต้องการได้ตรงเป๊ะ ต้นทุนคงที่ และแทบไม่ต้องแก้ไขเพิ่มหรือบำรุงรักษาอะไร
ถ้าออกไปนอกฟองสบู่ที่เราขังตัวเองอยู่ จะเห็นว่าคนจำนวนมากไม่ได้สนใจการอัปเกรด แต่อยากให้ของเก่าที่คุ้นเคยยังทำงานต่อไปได้เฉย ๆ
และผมก็มองไม่ค่อยออกว่าทำไมสัดส่วนนั้นจะไปไม่ถึง 99%
AI จะมาแทนที่วิศวกรซอฟต์แวร์อย่างแน่นอน
ส่วนที่ยังขาดอยู่ตามที่บทความพูดถึงคือ การส่งมอบ·การปฏิบัติการ และนั่นเป็นขอบเขตของ DevOps/SRE/Cloud engineer มากกว่าวิศวกรซอฟต์แวร์
ผมทำงานเป็น cloud engineer และมีเพื่อนที่ไม่ใช่วิศวกรหลายคนติดต่อมาบอกว่าตอนนี้แต่ละคนสามารถสร้าง side project ของตัวเองตั้งแต่ต้นด้วยหลายภาษา และรันได้ทั้งแบบ local, web app, native app
สิ่งที่พวกเขายังขาดคือแพลตฟอร์มที่ช่วย deploy และดูแลรักษาได้ง่ายแบบที่ “นักพัฒนาทั่วไป” ทำกัน
ตอนนี้การสร้างฐานรองรับนี้ยังค่อนข้างยุ่งยาก แต่ด้วย AGENTS.md, skills และการทดสอบแบบบูรณาการที่เข้มงวด ก็ทำได้เพียงพอ
พอสร้างไว้ครั้งเดียว ผู้ใช้ที่ไม่ใช่สายเทคนิคก็สามารถพัฒนาต่อได้เรื่อย ๆ โดยแค่บอกสิ่งที่ต้องการกับ claude/codex โดยไม่ต้องจ้างวิศวกรซอฟต์แวร์
claude/codex สามารถตัดสินใจบนพื้นฐานของสถาปัตยกรรมที่กำหนดไว้ล่วงหน้า และแนะนำผู้ใช้ที่ไม่ใช่สายเทคนิคได้
จากประสบการณ์ส่วนตัวของผม AI ได้แทนที่วิศวกรซอฟต์แวร์ไปแล้วหลายคน
ถ้าฐานรองรับแบบนี้ถูกทำให้เป็นผลิตภัณฑ์ ผมคิดว่า greenfield project จะถูกดูแลจากมุมมองผลิตภัณฑ์อย่างเดียวได้ ผ่าน agent coder และ platform engineering
นี่คือสิ่งที่เกิดขึ้นตอนนี้ และคุณก็แค่นึกภาพต่อไปอีก 5 ปี
การที่คนไม่ใช่วิศวกรเอาแอปที่ตัวเองทำมาให้ดู ไม่ได้แปลว่า AI ได้แทนที่หรือจะมาแทนที่วิศวกรซอฟต์แวร์
คุณอาจค้นหาอาการกับ Dr. Google แล้วลองเปลี่ยนพฤติกรรม ใช้สมุนไพร หรือยาที่ซื้อเองได้ และอาจได้ผลจริง แต่ก็ไม่ได้หมายความว่าแพทย์จะหายไป
คุณอาจใช้ generative AI สร้างเพลงได้โดยไม่มีทั้งทฤษฎีดนตรี ความรู้สึกทางดนตรี หรือความคิดสร้างสรรค์ แต่ก็ไม่ได้แปลว่าคนที่มีพรสวรรค์ทางดนตรีจะหายไป
ต่อให้ใช้ AI ช่วยทำ DIY ในบ้านได้ ก็ไม่ได้หมายความว่าวิศวกรจะหายไป
แล้วใครจะช่วยให้ผู้เชี่ยวชาญโดเมนทำความชัดเจนว่าสิ่งที่ต้องการจริง ๆ คืออะไร ผ่านการวนซ้ำแบบ prototype-ปรับปรุง
แล้วใครจะเป็นคนเขียนและดูแลระบบปฏิบัติการ ภาษา ระบบควบคุมเวอร์ชัน editor กับ terminal emulator ระบบจัดการความรู้·เอกสาร และแพลตฟอร์ม PaaS ที่นักทำซอฟต์แวร์งานอดิเรกเหล่านั้นพึ่งพาอยู่
สิ่งที่พวกเขาสร้าง ถูกทดสอบมาดีพอจะรับประกันได้หรือไม่ว่ามันแข็งแรงทนทาน
พวกเขาเข้าใจเงื่อนไขขอบเขตต่าง ๆ ที่อาจเกิดขึ้นหรือไม่
ความปลอดภัยโอเคไหม
การสร้างอะไรบางอย่างขึ้นมาอย่างรวดเร็วด้วยพรอมป์ต์ ไม่เท่ากับวิศวกรรม
อาจเป็นเพราะคนมองคุณค่าของ software engineering ผิดไป โดยคิดว่าคุณค่าส่วนใหญ่อยู่ที่โค้ดที่ผลิตออกมา หรือก็คือลำดับของบิตนั้นเอง
คุณค่าหลักของโปรเจกต์อยู่ที่กระบวนการสร้างทฤษฎีและนามธรรมขึ้นมา: https://pages.cs.wisc.edu/~remzi/Naur.pdf
อาจมีวิศวกรที่ทำแอปสองสัปดาห์แล้วไม่แตะอีกเลย แต่ผมไม่ค่อยรู้จักคนที่หาเลี้ยงชีพด้วยงานแบบนั้น
งานอย่าง “เว็บไซต์ WordPress สำหรับธุรกิจของคุณ” อาจทำได้
ปัญหาจะเกิดตอนที่มีฟีเจอร์ 432 อย่างอยู่แล้ว และคุณต้องเพิ่มฟีเจอร์ที่ 433 โดยห้ามกระทบของที่เหลือ
บางกรณีผิดพลาดนิดเดียวก็ไม่ได้ และบางครั้งฟีเจอร์เพียงอย่างเดียวก็เพิ่มความซับซ้อนเร็วกว่าที่วิศวกรจะรับมือไหว จนเวลาผ่านไปโปรเจกต์โตจนจัดการไม่ได้
มันเป็นไอเดียแอปเล็ก ๆ ที่เชื่อมกับระบบใหญ่ และภายใน 2~3 วันก็มี proof of concept ออกมาจาก 3~4 commits
มันน่าประทับใจอยู่หรอก แต่คนที่สร้างได้เพิ่มอีก 400 commits ให้โปรเจกต์นั้นในช่วง 3 เดือนที่ผ่านมา และพอมีการแก้ต่อเนื่อง งานสร้างและดูแลแอปนั้นก็กลายเป็นงาน part-time หรือ full-time ไปโดยพฤตินัย
เขากลายเป็น นักพัฒนาซอฟต์แวร์ที่ไม่ได้รับการฝึกฝน และไม่เข้าใจเรื่องความปลอดภัยหรือแนวปฏิบัติที่ดี
ถ้า Claude เก่งขึ้น ภาระอาจลดลงและอาจไม่กินเวลาทั้งวัน แต่ในบริษัทเราตอนนี้ “vibe app” ระยะแรกทั้งหมดแบบนี้กำลังกลายเป็นงานบำรุงรักษาที่กินเวลามากขึ้นเรื่อย ๆ
เห็นได้ชัดว่าผู้คนไม่ได้ต้องการซอฟต์แวร์น้อยลง แต่ต้องการมากขึ้น
software engineering แบบดั้งเดิมอาจหายไปได้ แต่การดูแลแพลตฟอร์มที่ขยายตัว ความปลอดภัย ความซับซ้อน เอกสาร และ business logic ยังอยู่ตรงหน้าบริษัทเราเหมือนเดิม
จะบอกว่าสร้างโปรเจกต์ด้วยข้อความได้ก็จริง แต่ถ้าไม่ใช่ซอฟต์แวร์ที่ง่ายที่สุด ผมรู้สึกว่าไม่เคยมีคำว่า “ตั้งค่าแล้วลืมได้เลย”
ยังไงก็ยังต้องมีใครสักคนคอยดูภาพรวมทั้งหมด
ไม่ว่าคนนั้นจะผ่านการฝึก software engineering มาหรือไม่ก็ตาม
นักพัฒนาที่มีประสบการณ์ก็ยังมีโอกาสทำได้ดีกว่าคนที่ไม่ได้รับการฝึกฝนมาก
แน่นอนว่าคนที่ชอบสร้างของและมีความอยากรู้อยากเห็นจะไล่ตามทันได้เร็ว แต่สำหรับนักพัฒนาแบบดั้งเดิมก็ยังมีข้อได้เปรียบใหญ่
เพราะพวกเราอยากรู้มาตลอดว่าข้างในมันทำงานอย่างไร
ส่วน vibe app ปัจจุบันที่พวกเขาใช้เวลาหลายเดือนสร้าง ถ้าใช้ AI ผมน่าจะทำได้ภายในหนึ่งชั่วโมง
vercelใน terminal แล้ว และถ้าแค่ได้รับคำสั่ง agent ก็ทำได้ไม่มีปัญหาการ deploy ซอฟต์แวร์เดสก์ท็อปยังยากกว่าเล็กน้อยตามแต่ละแพลตฟอร์ม
ถึงอย่างนั้น ช่องว่างระหว่าง side project กับซอฟต์แวร์ชั้นยอด ก็ยังห่างกันมาก และผมก็เชื่อได้ยากว่าวันหนึ่งช่องว่างนั้นจะถูกปิดลง
ผมไม่เข้าใจว่าทำไมสิ่งที่เป็นปัญหาซึ่งถูกแก้ไปแล้วตั้งแต่ก่อนมี AI ถึงจะไม่ถูกแทนที่ก่อน
และก็ยากจะเชื่อว่าโปรเจกต์ส่วนตัวจำเป็นต้องมีโครงสร้างพื้นฐานที่ซับซ้อน
ผมคงไม่สร้างแอปการเงินที่ต้องดูแลไปไม่มีกำหนดด้วย vibe coding
และคงไม่ไปแตะระบบ legacy ด้วย
ชัดเจนว่า AI แทนที่วิศวกรบางส่วนไปแล้ว แต่กรณีเพื่อนที่ไม่ใช่วิศวกรทำ side project ได้นั้นเกี่ยวข้องน้อย
พวกเขาทำเพราะตอนนี้มันทำได้ ไม่ใช่ว่าเดิมทีตั้งใจจะจ้างใครมาสร้างอยู่แล้ว
ก็เหมือนที่ผ่านมา ที่พวกเขาไม่เคยจ้างใครอยู่แล้ว
ฉันทำงานอยู่ในเอเจนซีพัฒนา และลูกค้าส่วนใหญ่เป็นสตาร์ตอัปที่ต้องรีบออกสู่ตลาด
เราใช้ การพัฒนาแบบ agent-based มาประมาณปีครึ่งแล้ว และในช่วงนั้นบทบาทของเราก็เปลี่ยนไปมาก
ปริมาณงานโครงการที่ไหลเข้ามานั้นพูดยากเพราะไม่รู้ตัวเลขที่แน่ชัด แต่สิ่งที่เห็นได้ชัดคือความคาดหวังต่อขอบเขตงานที่ส่งมอบได้เปลี่ยนไป
เมื่อก่อนโปรเจกต์ที่ต้องใช้คน 5 คน ตอนนี้ปกติใช้แค่ 1–2 คน
ในทางปฏิบัติ โปรเจกต์ greenfield ถูกทำให้เป็นอัตโนมัติไปมากแล้ว
งานทำมือจำนวนมาก เช่น การทำซ้ำด้าน UX/UI design, การทำซ้ำด้าน system architecture, การลองหลายแนวทางกับปัญหายากที่ไม่มีตัวชี้วัดชัดเจน ตอนนี้เกิดขึ้นได้ทันที
ถ้าคุณเข้าใจมันได้ในหัว ก็แทบจะเอาออกสู่โลกได้ในเวลาเพียง 1/100
ตลอดช่วงนี้ วิธีทำงานและวิธีคิดเรื่องระบบของฉันก็เปลี่ยนไปมากเช่นกัน
เรากลายเป็นสิ่งที่อยู่ร่วมกับ LLM และตอนนี้ถ้าไม่มีมันก็ลำบากมากจริง ๆ
แต่นั่นไม่ได้แปลว่าฉันไม่เข้าใจโค้ดที่ LLM เขียน ฉันยังตามทุกการเปลี่ยนแปลงอยู่ และเข้าใจ codebase โดยรวมมากกว่า LLM มาก
เพียงแต่ความสามารถในการเขียนโค้ดด้วยมือลดลงไปมาก และฉันคิดว่านั่นก็ไม่เป็นไร
ตอนนี้ฉันรู้สึกเหมือนเป็น ชั้นแปลความ ระหว่างเป้าหมายทางธุรกิจกับเทคโนโลยีที่รองรับมันได้ดีที่สุด
ยังเป็นการแก้ปัญหาเหมือนเดิม แต่เป็นการแก้ปัญหาในระดับที่สูงขึ้นมาก และยังน่าสนใจและสนุกอยู่
สำหรับนักพัฒนา กลยุทธ์ที่ดีที่สุดในยุคนี้ดูเหมือนจะเป็นการรักษาการคิดเชิงวิพากษ์ไว้ และใช้เครื่องมือให้เป็นประโยชน์กับตัวเอง
ตอนนี้ทุกคนมีพลังพิเศษแล้ว
ไม่จำเป็นต้องทำงานในบริษัทเสมอไป และนักพัฒนาเดี่ยวก็สร้างของที่ยิ่งใหญ่ได้ จึงไม่จำเป็นต้องพึ่งคนอื่นมากเท่าเมื่อก่อนอีกแล้ว
อนาคตอาจเป็น เศรษฐกิจผลิตภัณฑ์ระดับมหภาค ที่แต่ละคนต่างมอบบางสิ่งที่เป็นเอกลักษณ์ของตัวเองให้โลกก็ได้
ถ้า agent coding ดีพอที่จะสร้างโปรเจกต์ greenfield ได้จริง มันก็จะส่งผลไม่ใช่แค่นักพัฒนา แต่ต่อทั้งบริษัทและทั้งภาคอุตสาหกรรมด้วย
โมเดลธุรกิจของเอเจนซีพัฒนาเกิดขึ้นเพราะบริษัทที่อ่อนด้านเทคโนโลยีไม่รู้จะจัดการซอฟต์แวร์อย่างไร และในบางกรณีก็มีแรงจูงใจแบบฉวยโอกาสที่จะเอางานเริ่มต้นที่ใช้แรงคนมากไปจ้างคนนอก
แต่ตอนนี้เทคโนโลยีนั้นอยู่แค่ปลายนิ้วของลูกค้าเอเจนซีแล้ว จึงเป็นเพียงเรื่องของเวลาก่อนที่ CEO และผู้จัดการจะเริ่ม vibe coding และตระหนักว่า “ต้องการแค่นักพัฒนาคนเดียวที่พอมีเซนส์ด้านเทคนิค”
สิ่งนี้อาจขยายไปถึงธุรกิจ SaaS จำนวนมากด้วย
ทุกวันนี้ยังมีธุรกิจขนาดเล็กจำนวนมากที่อยากได้ซอฟต์แวร์เฉพาะทางเพื่อลดงานทำมือ แต่การจ้างนักพัฒนาซอฟต์แวร์จริงจังนั้นแพงเกินไปเสมอ
เลยต้องใช้โค้ดง่อนแง่นที่หลานใครสักคนทำไว้ หรือใช้ SaaS ที่พอถูไถใช้งานได้
ตอนนี้แม้จะยังง่อนแง่นอยู่มาก แต่พวกเขาสร้างโซลูชันเฉพาะทางของตัวเองได้และได้มากกว่าเดิม
สิ่งที่ Big Tech ทำอยู่ใกล้เคียงกับการปรับตัวรับภาวะเศรษฐกิจชะลอมากกว่า และสิ่งที่น่ากังวลกว่าคือความปั่นป่วนใน ภาคเทคโนโลยีขนาดเล็กและกลาง
แต่เพราะไม่มี เครือข่ายความสัมพันธ์ สำหรับหาลูกค้า
นักพัฒนาส่วนใหญ่ต้องการให้บริษัทช่วยอย่างน้อยในเรื่องการตลาด เพื่อที่ตัวเองจะได้โฟกัสกับงานที่ถนัด
การสร้างโค้ดกับการตัดสินโค้ดเป็นคนละความสามารถกันในสมอง
การเขียนโปรแกรมเต็มไปด้วยรายละเอียดทางไวยากรณ์เล็ก ๆ น้อย ๆ เป็นหลัก ดังนั้นถึงจะเขียนโค้ดยากขึ้น แต่ก็ยังรีวิวได้ดี
https://xcancel.com/karpathy/status/2015883857489522876
บริษัทที่ประสบความสำเร็จในโลกจริงมีคูเมืองทางธุรกิจจากข้อมูล สิทธิบัตร·ทรัพย์สินทางปัญญา ผลของเครือข่าย และอื่น ๆ
แค่เวลาพัฒนาลดลงเหลือ 1/100 ไม่ได้แปลว่าจะสร้างธุรกิจใหม่ได้ทันที
ถ้ามองไปรอบ ๆ วงการเทคโนโลยีตอนนี้ มีหลายบริษัทที่ดูเหมือนจะถูกผู้สร้างสาย AI ที่คล่องตัวเข้ามาปั่นป่วนได้ แต่ในความเป็นจริงกลับไม่เป็นเช่นนั้นเพราะผลของการล็อกอินหรือการผูกติดกับระบบเดิม
คำกล่าวที่ว่า “ในบรรดา 270 อาชีพของสำมะโนประชากรสหรัฐปี 1950 มีเพียงพนักงานควบคุมลิฟต์อาชีพเดียวที่หายไปเพราะระบบอัตโนมัติ” ชวนให้เข้าใจผิด
ในช่วงเวลาเดียวกัน งานภาคเกษตร ลดลงจาก 15% ของแรงงานเหลือ 2%
เขาบอกว่ามันต่างจากอาชีพแบบเกษตรที่ความต้องการแรงงานลดลงอย่างมากเพราะการใช้เครื่องจักรและระบบอัตโนมัติ
ปริมาณแคลอรีที่ผู้คนบริโภคนั้นค่อนข้างคงที่ และเพิ่มขึ้นเพียง 25% ก็ทำให้เกิดการระบาดของโรคอ้วนได้แล้ว แต่ปริมาณซอฟต์แวร์ที่ผลิตออกมากลับเพิ่มขึ้นเป็นล้านเท่า นี่คือความต่าง
ตัวเลขแบบสัดส่วนทำให้การลดลงดูมากเกินจริง เพราะแรงงานรวมทั้งระบบโตขึ้น
แต่ถ้ามองการจ้างงานใน อุตสาหกรรมอาหาร ที่กว้างกว่า กลับเพิ่มขึ้นมาก
ดังนั้นต่อให้การจ้างงาน “coder” ลดลง การจ้างงานในอุตสาหกรรม “ซอฟต์แวร์/เทคโนโลยี” ที่กว้างกว่านั้นก็อาจเพิ่มขึ้นได้
งานราว 95% ในสายนั้นถูกทำให้เป็นอัตโนมัติไปแล้ว แต่พวกเขามักโทษนกฮูก
โรงงานและสายพานลำเลียงก็เหมือนกัน
ทุกครั้งที่ระบบอัตโนมัติเข้ามา คนก็ยังคงตกงานต่อไป และเราก็ได้แต่ “หวัง” ให้พวกเขาหางานอื่นทำ หรือโยนความหวังแบบสุดโต่งและไม่ค่อยเข้ากันเองทำนองว่า “จงเป็น generalist”, “จงเป็น specialist”, “ไปทำงานบริการ”, “ไปเรียนเขียนโค้ด”, “ไปขุดถ่านหิน”
แค่ฟัง @pmarca ก็เห็นได้แล้วว่าผู้นำทางเทคโนโลยีสับสนและไร้ทิศทางแค่ไหน
หนังสือล่าสุดของ Stripe Press เกี่ยวกับระบบอัตโนมัติในภาคอุตสาหกรรมก็น่าอ่านเช่นกัน: https://press.stripe.com/origins-of-efficiency
คนที่เชื่อ AI แบบไร้เดียงสาที่สุด ส่วนใหญ่เป็นพวก ชอบลองนั่นลองนี่
ก็สมเหตุสมผล เพราะการเขียนโค้ดแบบมี LLM ช่วยทำให้ความเร็วในการลองเล่นกับอะไรบางอย่างเพิ่มขึ้นอย่างน่าทึ่ง
การลองนั่นลองนี่คือกระบวนการ และผู้คนก็ได้รับความสุขอย่างมากจากการลงมือสร้างและปรับแต่ง
ผลลัพธ์เป็นเพียงสิ่งที่คำนึงถึงเป็นลำดับรองหรืออันดับสาม
AI ขยายขีดความสามารถในการลงมือทำ และดังนั้นจึงขยายความสามารถในการลองเล่นของเราอย่างมาก แต่ไม่ได้สร้างผลกระทบที่มีความหมายหรือ “engineering” ขึ้นมาได้ด้วยตัวเอง
ผลกระทบสำคัญกว่ากิจกรรม
การทำ prototype, debugging, testing และอื่น ๆ ไม่ใช่งานปลอมเพียงเพราะมันเกิดขึ้นได้เร็ว
compiler เองก็ไม่ได้สร้างผลกระทบขึ้นมาด้วยตัวมันเอง
CI, IDE, framework และ cloud infra ก็เช่นกัน
สิ่งเหล่านี้เพิ่ม leverage ให้กับคนที่ใช้งานมัน
ภรรยาของผมถูก AI แทนที่ไปแล้วจริง ๆ
เธอเป็นโปรแกรมเมอร์ และบริษัทได้สร้างเอเจนต์ขึ้นมาโดยมีจุดประสงค์อย่างเปิดเผยเพื่อแทนที่ภรรยาของผมกับคนอีกไม่กี่คน แล้วก็เลิกจ้างเธอประมาณหนึ่งเดือนหลังจากมันเริ่มใช้งานได้
ทีมของเราได้หัวหน้าคนใหม่เมื่อ 18 เดือนก่อน และมีการลำเอียงกันอย่างโจ่งแจ้ง โดยคนที่เขาชอบคือคนเดียวที่ไม่ใช่ team player
ตลอด 18 เดือนที่ผ่านมา เขาหาวิธีไล่พนักงานที่ทำงานทางไกลออกทั้งหมด โดยไม่สนใจผลงานที่ผ่านมาเลย
หนึ่งในนั้นเคยได้รับรางวัลหลายครั้งซึ่งมีระดับสูงกว่าหัวหน้าคนนั้นเสียอีก แต่หัวหน้าก็ยกย่องอยู่แต่คนที่เป็นพิษคนนั้นเสมอ
มันไม่ใช่การถูก AI แทนที่ แต่บรรยากาศที่ทำให้คนรู้สึกว่าตัวเองไม่มีคุณค่าก็คงคล้ายกับตอนถูก AI แทนที่
ทุกคนในทีมนั้นรวมถึงหัวหน้าตรงของผมกำลังสมัครงานที่อื่นอยู่
หัวหน้าตรงของผมเป็นออทิสติกชนิดทำงานได้ดี และมักถูกหัวหน้าคนนั้นเยาะเย้ย
ผมหวังจริง ๆ ว่าพวกเขาจะสำเร็จ เพื่อสุขภาพจิตของตัวเอง
ผมเคยยกปัญหานี้ให้ HR หลายครั้ง และยังพบข้อบังคับการทำงานที่หัวหน้าคนนั้นละเมิดด้วย แต่ก็ได้เรียนรู้ว่าอย่างน้อยที่นี่ กฎพวกนั้นเป็นแค่ตัวหนังสือเท่านั้น
กลับกัน มันยิ่งเหมือนวาดเป้าไว้ที่หลังตัวเอง ผมเลยต้องออกมา
คนอื่นอีกหลายคนก็เคยแสดงความกังวล และส่วนใหญ่หลังจากนั้นก็ไปหางานที่อื่นกัน
โชคดีที่ผมได้งานใหม่แล้ว กำลังจะย้ายไปเร็ว ๆ นี้ และก็ตั้งตารออยู่
หวังว่าทุกอย่างจะโอเค
อยากรู้ว่าหลังจากนั้นเป็นอย่างไรบ้าง ได้งานใหม่หรือยัง และยังอยู่สายซอฟต์แวร์เหมือนเดิมไหม
ต่อให้การสื่อสารของบริษัทเรื่องการเลิกจ้างเพราะ AI จะเป็นเรื่องปลอม ก็ไม่ได้ทำให้ความเสี่ยงนั้นหายไป
ถึงสิ่งที่ฝั่งบริษัทพูดจะเป็นเรื่องโกหก ผลกระทบของเทคโนโลยีก็อาจเกิดขึ้นจริงได้ และในบริบทนี้มันเป็นเพียงสัญญาณรบกวน
สมมติฐานแบบแผนภาพเบอร์เกอร์ในบทความที่ว่าขั้นตอนการลงมือทำจะเล็กลง แต่ขั้นตอนอื่นทั้งหมดจะใหญ่ขึ้นจนขนาดเบอร์เกอร์รวมเท่าเดิม ก็ไม่ได้ฟังดูน่าเชื่อเท่าไร
อย่างไรก็ดี ดูเหมือนว่าบางส่วนของวิศวกรรมซอฟต์แวร์ยังห่างไกลมากจากการถูกคุกคาม
โดยเฉพาะ งานที่ความถูกต้องแม่นยำเป็นหัวใจสำคัญ
งานพัฒนาเว็บยังพอถูไถไปได้มากกว่าเยอะ แต่โค้ดนำทางจรวดเป็นอีกเรื่องหนึ่ง
LLM อาจทำได้ทั้งสองแบบ แต่คงยังไม่มีใครทำ vibecoding กับอย่างหลังในเร็ว ๆ นี้
AI ได้แทนที่งานบางส่วนไปแล้วอย่างแท้จริง และต่อจากนี้ก็จะมากขึ้นอีก
มันอาจไม่แทนที่วิศวกรซอฟต์แวร์ทั้งหมด แต่เมื่อกล่องแพนโดราถูกเปิดแล้ว งานประเภท ใช้แรงน้อยและความเสี่ยงต่ำ ก็จะให้ AI ทำ
มีโปรเจกต์ที่ใช้งานจริงจำนวนมากบนบริการอย่าง Lovable และทางเลือกเดิมก็คือให้คนเป็นคนทำ
คนที่แทนที่งานเสมอคือ นายจ้าง
อย่าไปทำให้กลุ่มกราฟิกการ์ดดูเหมือนมีตัวตนเป็นมนุษย์
ผมยังไม่ค่อยมั่นใจกับส่วนนี้ของบทความ
คือข้ออ้างที่ว่า “คอขวดที่แท้จริงคือ (1) การตัดสินใจและกำหนดสเปกว่าเราจะสร้างอะไร, (2) การตรวจสอบและรับผิดชอบต่อสิ่งที่ส่งมอบมา, (3) ความเข้าใจเชิงมนุษย์อย่างลึกซึ้งต่อ codebase, ธุรกิจ, และสภาพแวดล้อม”
อาจเป็นไปได้ว่าเพราะการเขียนโค้ดมีราคาแพงและถูกมองว่าเป็นคอขวด จึงมีความพยายามมากทั้งต้นน้ำและปลายน้ำเพื่อให้แน่ใจว่าอินพุตถูกต้องและผลลัพธ์จะไม่ถูกทิ้ง
ถ้าการเขียนโค้ดถูกมองว่าเป็นขั้นตอนที่เร็วและถูก ผลลัพธ์ก็อาจถูกทิ้งได้ ดังนั้นต้นน้ำอาจไม่จำเป็นต้องมีการกำกับดูแลในระดับเดิม
สิ่งที่แย่กว่ามากคือผลกระทบเมื่อซอฟต์แวร์ทำงานผิดพลาด และการ คงความเข้ากันได้ย้อนหลัง