หากจะรวมมุมมองของ Jevons paradox ก่อนอื่นต้องกำหนดให้ได้ว่าอะไรคือทรัพยากร
เมื่อเป็นบทความวิเคราะห์แนวโน้มความต้องการนักพัฒนา ทรัพยากรในบทความนี้ก็ควรเป็นนักพัฒนา

  • อุตสาหกรรมที่ Jevons paradox ใช้อธิบายตามเดิม (เครื่องจักรไอน้ำ <-> ถ่านหิน) กับอุตสาหกรรมซอฟต์แวร์มีความแตกต่างกันมาก
    • สินค้าดิจิทัลเป็นสินค้าที่ไม่แย่งกันบริโภค และเป็นอุตสาหกรรมที่ต้นทุนส่วนเพิ่มแทบเป็น 0 กล่าวคือเป็นอุตสาหกรรมที่มีต้นทุนคงที่เป็นหลัก
    • ในอุตสาหกรรมแบบนี้ การเพิ่มผลิตภาพโดยทั่วไปจะดำเนินไปในทิศทางของการลดหรือคงจำนวนบุคลากรไว้ และเพิ่มการใช้ประโยชน์จากกำลังคนเดิมให้มากขึ้น
  • หาก Jevons paradox จะ成立 ความต้องการต้องไวต่อราคาอย่างมาก และการลดต้นทุนต้องนำไปสู่การพุ่งขึ้นของความต้องการโดยตรง
    • การพัฒนาซอฟต์แวร์ไม่ได้ทำโดยนักพัฒนาเพียงลำพัง คอขวดไม่ใช่ "ต้นทุนการเขียนโค้ด" แต่เป็นต้นทุนด้านการวางแผน ความเสี่ยง การปฏิบัติการ องค์กร และกฎระเบียบ
    • ที่ผ่านมาส่วนใหญ่ไม่ใช่ว่าซอฟต์แวร์แพงเกินไปจนสร้างไม่ได้ แต่เป็นกรณีที่ "ไม่จำเป็น / ROI ไม่คุ้ม / ดูแลปฏิบัติการไม่ได้" เลยไม่ได้ทำ
  • มีภาพลวงของตัวชี้วัดผลิตภาพ
    • ตัวชี้วัดที่ใช้ในบทความ (ปริมาณการสร้างโค้ดที่เพิ่มขึ้น, PR ที่เพิ่มขึ้น, ปริมาณการ deploy ที่เพิ่มขึ้น) ล้วนเป็นตัวชี้วัด "ปริมาณกิจกรรม"
    • ปริมาณโค้ดที่เพิ่มขึ้นไม่ได้หมายความว่ามูลค่าเพิ่มขึ้น PR ที่เพิ่มขึ้นนำไปสู่ต้นทุนการรีวิว/ตรวจสอบที่เพิ่มขึ้น และโค้ดจาก AI ก็เพิ่มความเสี่ยงด้านคุณภาพ/ความปลอดภัย
    • กล่าวคือ โค้ดจาก AI ทำให้ technical debt, ต้นทุนการดีบัก และความซับซ้อนในการปฏิบัติการเพิ่มขึ้น
    • ดังนั้น การเพิ่มผลิตภาพอาจไม่ได้เพิ่มขึ้นอย่างหวือหวาเหมือนตัวชี้วัดปริมาณกิจกรรม
  • การยอมรับว่าเกิด "หน้าผาของจูเนียร์" แต่ยังคงมองโลกในแง่ดีต่อไปนั้นเป็นเรื่องขัดแย้ง
    • นักพัฒนาแตกต่างจากถ่านหินตรงที่มีโครงสร้างการเติบโตจาก junior ไปเป็น senior
    • ถ้าจำนวนนักพัฒนาระดับ junior ลดลง จำนวนนักพัฒนาระดับ senior ในอนาคตก็จะลดลงด้วย ดังนั้นในระยะกลางถึงยาว pool ของนักพัฒนาโดยรวมจะหดตัวลง
  • การเติบโตของขนาดตลาดกับการเติบโตของการจ้างงานไม่ใช่เรื่องเดียวกัน
    • โดยเฉพาะ AI เป็นอุตสาหกรรมที่ใช้เงินทุนเข้มข้น ไม่ใช่ "อุตสาหกรรมที่ใช้คนมากขึ้น" แต่เป็น "อุตสาหกรรมที่สร้างขนาดใหญ่ขึ้นด้วยคนจำนวนน้อยกว่า"
  • นักพัฒนาเป็นคน และค่าจ้างของคนมีลักษณะที่ต่างจากราคาถ่านหิน
    • ในตลาดแรงงาน ค่าจ้างไม่ได้ลดลงอย่างยืดหยุ่นเต็มที่ ดังนั้นการลดต้นทุนจึงไม่ได้ส่งผ่านไปสู่การลดราคาได้มากพอ
    • ค่าจ้างมีความแข็งตัวลงด้านล่างจริง ทั้งจากค่าแรงขั้นต่ำ กฎหมายแรงงาน โครงสร้างสัญญา ความเป็นธรรมภายในองค์กร และความเสี่ยงด้านขวัญกำลังใจ/การลาออก
    • กล่าวคือ เมื่อผลิตภาพเพิ่มขึ้น บริษัทจะไม่ได้ลดค่าจ้าง แต่จะลดการจ้างงาน
 

"ปัญหาคือมันทำให้เราเข้าใจผิดว่าความรู้สึกคลุมเครือ (vibe) เป็นเหมือนการนามธรรมที่แม่นยำ" เห็นด้วยมากครับ การนามธรรมนี่แหละเป็นสิ่งที่มีได้เฉพาะคนที่เข้าใจระดับล่างแบบ Bottom-up เท่านั้น

 

ถ้าสิ่งที่เคยทำได้กลับทำไม่ได้ มันก็ย่อมไม่สะดวกอยู่แล้ว แต่แค่การกวาดพวกสปาเกตตีที่เคยต้องดิ้นรนแก้กันบน x11 ออกไป ก็มีเหตุผลมากพอให้ประเมินมันในทางบวกแล้ว
อย่างไรก็ตาม ถ้าย้อนดูเหตุผลว่าทำไมถึงยังทำไม่ได้ สุดท้ายปัญหาก็คือมันยังไม่ได้ถูกทำให้เป็นมาตรฐาน และก็เป็นความจริงด้วยว่าช่วงเวลานั้นกินเวลานานกว่าที่คิด
คงเป็นไปได้ว่าแม้จะถึงปี 2030 ก็ยังจะมีเสียงบอกว่าอีกไกลกว่าจะสมบูรณ์ แต่การย้อนกลับไปหา x11 คงเป็นไปไม่ได้
แม้จะเป็นช่วงสับสนวุ่นวายที่ระบบนิเวศกําลังเปลี่ยนผ่าน แต่ตัวเลือกทดแทนก็คงจะโดนเสียงวิจารณ์แบบเดิมอีก และการย้อนกลับก็น่าจะก่อให้เกิดแรงต้านจากระบบนิเวศที่ผู้คนคุ้นชินไปแล้ว

 

ก่อนหน้านี้เคยเห็นข้อเสนอที่ไหนสักแห่งว่า ในภาษาเกาหลีแทนที่จะใช้คำว่า “กินอาหารสุนัข” ลองใช้คำว่า “กินข้าวบ้านตัวเอง” ดีไหม ซึ่งคำว่า “กินข้าวบ้านตัวเอง” ก็ให้ความรู้สึกของคำที่ใช้ได้ดีเหมือนกันนะ

 

น่าจะต้องดูว่าสามารถแทนที่ด้วยวิธีการตรวจสอบแบบอื่นได้หรือไม่ ยิ่งใกล้ฝั่งฟรอนต์มากเท่าไร ก็อาจตรวจสอบได้ว่าทำงานได้ดีเพียงแค่ทำ E2E ผ่านพฤติกรรมของเบราว์เซอร์ แต่ยิ่งเป็นโค้ดที่ใกล้กับฝั่งแบ็กเอนด์และอินฟรามากเท่าไร ก็ยิ่งดูเหมือนว่าการรีวิวโค้ดจะเป็นสิ่งจำเป็น เพราะไม่เช่นนั้นก็จะตรวจสอบ side effect อย่างเช่นทรานแซกชันที่เปิดและปิดโดยมองไม่เห็น หรือการยิง API call ได้ยาก

 

หวังว่า WinUI 3 WYSIWYG จะออกมาสักทีเมื่อไหร่นะ

 

สร้างโค้ด 1 ล้านบรรทัดด้วยโทเคน 13 พันล้าน... สุดยอดจริง ๆ
ขอบคุณครับ! จะลองใช้งานให้ดี แล้วไว้จะมาแชร์รีวิวลงบล็อกทีหลังนะครับ ฮ่าๆ

 

ยุคของ Adobe กำลังจะผ่านไปแล้ว แม้แค่มองจากราคาหุ้นในยุค AI คลิกเดียวก็เห็นได้ชัด

 

ปกติใช้แต่ dbeaver คงต้องลองใช้ดูแล้ว ฮ่าๆ

 

ก่อนจะไปถึงเรื่องการแก้ไขร่วมกัน แค่การทำเอดิเตอร์สำหรับใช้งานคนเดียวให้ดีจริง ๆ ก็เต็มไปด้วยความซับซ้อนที่คาดไม่ถึง ทั้งการจัดการเคอร์เซอร์, สแตก undo/redo, การป้อนข้อมูลผ่าน IME ฯลฯ อย่างที่บทความชี้ไว้ ไม่มีซอฟต์แวร์ไหนที่แสดงให้เห็นกับดักของ “สเปกที่ให้ความรู้สึกว่าเข้าใจง่ายแต่ต้องแม่นยำ” ได้ชัดเจนเท่าเอดิเตอร์อีกแล้ว สุดท้ายแล้วสิ่งที่ดูเหมือนง่าย ไม่ได้ง่ายจริง แต่เป็นการซ่อนความซับซ้อนนั้นไว้ด้วยการทำ abstraction ได้ดีต่างหาก

 

แบบนี้ตายกันหมดแน่!

 

จะว่าไปมันก็ดูเป็นกระแสอยู่เหมือนกัน อาจเป็นเพราะมีหลายแง่มุมที่ทำให้รู้สึกว่าต้องคอยดูท่าทีด้วยก็ได้ครับ อย่างที่ท่านด้านล่างบอก หลายคนก็อาจยังไม่รู้จักจริง ๆ นั่นแหละ...

 

โค้ดคือข้อกำหนดที่แม่นยำที่สุดในเชิงตรรกะสำหรับระบบอย่างง่าย
แต่กับโลกความเป็นจริงที่เป็นระบบซับซ้อน นั่นแหละคือกับดัก.. สุดท้ายแล้วมีเพียงข้อมูลเท่านั้นที่ยังพอเป็นข้อกำหนดที่แม่นยำที่สุด

 

iPhone, AlphaGo, Bitcoin และสิ่งเหล่านี้ไต่กำแพงแห่งความสงสัยขึ้นมาได้ แต่ทำไม AI ถึงเร่งความเร็วขึ้นอย่างกะทันหันล่ะ?

 

โปรเจ็กต์นี้น่าสนุกดีนะ

 

ไม่ว่าจะมองยังไง ตอนนี้ก็ดูเหมือนเป็นโอกาสสุดท้ายที่จะประสบความสำเร็จ

 

ตอนที่ผมทำไลบรารีเองก็ยังคงมีการแจกจ่าย cjs build อยู่เหมือนกัน
แต่ก็อยากให้ไลบรารีที่แม้แต่ในปี 2026 ก็ยังไม่มีตัวอย่าง esm และทั้งหมดอิงกับ require ล้วนอัปเดตกันสักหน่อย