เรากำลังจะกอบโกยเงินก้อนโต

 (rocketpoweredjetpants.com)
1 คะแนน โดย GN⁺ 8 시간 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • ในภาพจำลองระยะเวลาประมาณ 5 ปี การแพร่หลายของ AI สำหรับเขียนโค้ดอาจลดการจ้างงานระดับจูเนียร์และสะสมความซับซ้อนของโค้ดมากขึ้น ทำให้ค่าตัวของนักพัฒนาระดับซีเนียร์ที่มีทักษะในการจัดระเบียบสิ่งเหล่านี้พุ่งสูงขึ้นอย่างมาก
  • บริษัทที่มองว่าโมเดลสำหรับเขียนโค้ดพัฒนาไปไกลพอจะทดแทนนักพัฒนาจูเนียร์ได้ เริ่มซื้อ โทเค็น เพิ่มแทนการเพิ่มคน และโอกาสการจ้างงานจูเนียร์ก็ลดลงจริง
  • LLM มีแนวโน้มจะเพิ่มโค้ดใหม่มากกว่าจัดระเบียบโค้ดเดิม และเมื่อรวมกับ ข้อจำกัดของ context window ที่ไม่สามารถบรรจุทั้งรีโพซิทอรีได้ ก็ยิ่งทำให้โค้ดซ้ำและหนี้ทางเทคนิคเพิ่มขึ้น
  • เมื่อทั้งอัตราข้อบกพร่องของโค้ดที่ AI สร้างและปริมาณโค้ดโดยรวมเพิ่มขึ้น บั๊กก็ยิ่งมากขึ้น และเพราะมีการทำซ้ำที่ไม่ถูกแยกนามธรรมอย่างเหมาะสม จึงต้องแก้ข้อบกพร่องเดียวกันซ้ำในหลายจุด
  • หากการหยุดจ้างจูเนียร์และ ภาวะหมดไฟรุนแรงเพิ่มขึ้น 22% ทำให้อุปทานของบุคลากรที่มีทักษะลดลง นักพัฒนาที่มีประสบการณ์ดูแลโค้ดจากยุคก่อน AI และมีวิจารณญาณที่ดี อาจเผชิญโอกาสหายากแบบเดียวกับนักพัฒนา COBOL ในยุค Y2K

ขนาดและความซับซ้อนของโค้ดที่ AI เป็นตัวเร่ง

  • กระบวนการทั้งหมดกินเวลาราว 5 ปี และตั้งต้นจากสมมติฐานว่าขณะนี้ได้ดำเนินมาแล้วประมาณ 1.5~2 ปี
  • โมเดล AI รุ่นใหม่ แม้ยังไม่สมบูรณ์แบบ ก็ไปถึงระดับที่เทียบเท่าหรือดีกว่านักพัฒนาจูเนียร์ในการเขียนโค้ดแล้ว
    • เกิดแนวคิดแพร่หลายว่า แทนที่จะจ้างนักพัฒนาจูเนียร์ในต้นทุนเท่าเดิม สามารถใช้โทเค็นจำนวนมากเพื่อทำงานได้มากกว่า
    • ประกาศรับนักพัฒนาจูเนียร์ อาจลดลง และตามการวิเคราะห์ของ Stanford Digital Economy Lab การเปลี่ยนแปลงด้านการจ้างงานลักษณะนี้ ได้เริ่มเกิดขึ้นแล้ว
  • LLM สามารถสร้างฟังก์ชันช่วยและเมธอดของไลบรารีภายนอกที่เคยพบในข้อมูลฝึกได้โดยตรง จึงมีแนวโน้มชอบ เพิ่มโค้ดใหม่
    • ผลลัพธ์คือปริมาณโค้ดที่เขียนและขนาดของรีโพซิทอรีเพิ่มขึ้นอย่างต่อเนื่อง และงานวิจัยที่เกี่ยวข้องก็ยืนยันเรื่อง การขยายตัวของขนาดโค้ด
  • AI มีแนวโน้มชัดเจนที่จะต่อเติมฟีเจอร์เข้าไปในโค้ดเดิม มากกว่าจัดระเบียบโค้ด ลบความซ้ำซ้อน หรือเพิ่มความสามารถในการบำรุงรักษา
    • แม้ context window จะใหญ่ขึ้น ก็ยังใส่รีโพซิทอรีสมัยใหม่ได้ไม่ทั้งชุด จึงอาจมองข้าม implementation เดิมที่มีอยู่
    • โค้ดที่ AI เขียนส่วนใหญ่เป็นการเพิ่มเข้าไป และมักซ้ำซ้อน ซึ่งงานวิจัยเรื่อง คุณภาพโค้ดที่มี AI ช่วยเขียน ก็พบปรากฏการณ์เดียวกัน
  • AI สามารถ อ่านโค้ดและ control flow ที่ซับซ้อน ได้เร็วและแม่นยำกว่ามนุษย์
    • ด้วยเหตุนี้ งบประมาณความซับซ้อนและหนี้ทางเทคนิค ที่องค์กรยอมรับก็เพิ่มขึ้นด้วย
    • หลักการที่ว่าการดีบักยากกว่าการเขียนโค้ดสองเท่ายังคงใช้ได้ และหากความซับซ้อนสะสมต่อไป ก็อาจไปถึงจุดที่แม้แต่ AI ก็รับมือไม่ไหว
    • โค้ดเบสบางส่วนได้ก้าวข้ามระดับความซับซ้อนที่มนุษย์จะรับมือได้ไปแล้ว และกรณี วิกฤตหนี้ทางเทคนิคจาก AI ก็แสดงให้เห็นเช่นกัน
  • อัตราข้อบกพร่องของโค้ดที่ AI สร้าง โดยทั่วไปสูงกว่าโค้ดที่มนุษย์เขียน
    • ต่อให้ในอนาคตอัตราข้อบกพร่องจะต่ำกว่ามนุษย์ แต่เพราะปริมาณโค้ดที่ถูกสร้างมีมากขึ้น จำนวนข้อบกพร่องรวมก็อาจยังเพิ่มขึ้น
    • โค้ดไม่ได้ถูกแยกและทำ abstraction อย่างเหมาะสม ทำให้แม้จะแก้บั๊กในจุดหนึ่งแล้ว implementation ซ้ำในจุดอื่นก็ยังคงอยู่ และต้องตามแก้ข้อบกพร่องเดียวกันซ้ำไปมา

ความหายากของนักพัฒนาระดับซีเนียร์ที่มีทักษะ

  • ในโค้ดเบสที่ซับซ้อน โครงสร้างแย่ มีบั๊กและโค้ดซ้ำจำนวนมาก จำเป็นต้องมี นักพัฒนาระดับซีเนียร์ เพื่อตัดสินใจว่าควรลบอะไร abstraction ไหนผิดพลาด หรือควรออกแบบแนวทางใหม่ทั้งระบบหรือไม่
  • บุคลากรที่มีทักษะลดลง ไม่เพียงจากการออกจากอุตสาหกรรมตามธรรมชาติ แต่ยังจากภาระในการจัดการความซับซ้อนที่ AI สร้างขึ้นด้วย
    • ภาวะหมดไฟรุนแรง ของนักพัฒนาซีเนียร์เพิ่มขึ้น 22%
    • หากหยุดจ้างจูเนียร์ จำนวนคนที่จะเติบโตเป็นซีเนียร์รุ่นถัดไปก็จะลดลงด้วย
    • นักพัฒนาที่เริ่มอาชีพหลังยุค AI ก็อาจมีความสามารถ แต่ประสบการณ์ในการเขียนโค้ดที่ดูแลรักษาได้ด้วยวิธีแบบก่อน AI อาจยังน้อย
  • ตอนนี้ วิศวกรซีเนียร์ที่พร้อมทำงานในโปรดักชันได้ทันที ก็เป็นคอขวดสำคัญของตลาดแรงงานอยู่แล้ว ดังนั้นความต้องการนักพัฒนาที่มีประสบการณ์และมีเซนส์เรื่องโค้ดที่ดีจึงน่าจะยิ่งเพิ่มขึ้น
  • เมื่ออุปสงค์เพิ่มและอุปทานลดลง ราคาแรงงานก็ย่อมสูงขึ้น และนักพัฒนาระดับซีเนียร์อาจได้โอกาสคล้ายกับที่ นักพัฒนา COBOL เคยได้รับในช่วงก่อนและหลัง Y2K
  • นักพัฒนาที่มีประสบการณ์ซึ่งผ่านช่วงเลย์ออฟที่ขับเคลื่อนด้วย AI มาได้ อาจได้รับค่าตอบแทนสูงเมื่อภาวะขาดแคลนอุปทานเริ่มชัดเจน

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 8 시간 전
ความคิดเห็นจาก Lobste.rs
  • ภายใน 5 ปีข้างหน้า ฉันคงหาเงินก้อนโตได้จากการไล่แก้ ผลลัพธ์เละเทะที่ AI สร้างออกมา แล้วไปเกษียณนั่งเรือยอชต์อยู่ที่ไหนสักแห่ง
    มองว่าสเกลมันจะหนักกว่างานที่เคยต้องมาเก็บกวาดผลลัพธ์จากเครื่องมือ WYSIWYG หรือทีมเอาต์ซอร์ซต่างประเทศในอดีตมาก
    • ต่อให้จ่ายเงินเยอะแค่ไหน ก็ยังสงสัยว่างาน เก็บกวาดแก้ไข แบบนั้นจะสนุกไหม และถึงจะมีฝีมือก็ไม่มั่นใจว่าจะรับมือไหว
  • โปรเจ็กต์ที่เกี่ยวข้อง: https://odra.dev/slopfix/
  • แทนที่จะพยายามฝืนช่วยบริษัทที่ขาดวิสัยทัศน์ ก็ดูเหมือนว่าจะดีกว่าถ้าปล่อยให้ล้มไปตามเดิม แล้วเริ่ม ธุรกิจใหม่ ขึ้นมา
  • เป็นเรื่องที่ฉันพูดบ่อยมาตลอดปีนี้ คือไม่ใช่แค่การเก็บกวาดโค้ดเละ ๆ เท่านั้น แต่การ เอา LLM ออกจากงานที่เดิมควรถูกประมวลผลแบบกำหนดแน่นอน ก็น่าจะเป็นตลาดใหญ่เช่นกัน
    ถ้ามีคนจ่ายเดือนละ 20,000 ดอลลาร์ให้แชตบอตเพื่อพยายามเดาว่าผู้ใช้เลือกอะไรจาก 4 ตัวเลือก ฉันก็สามารถสร้างโปรแกรมที่ทำงานแบบไม่ขึ้นกับราคาโทเค็นหรือความผิดพลาดเชิงความน่าจะเป็นให้ได้ในเงินเท่ากัน และยังเสนอแพ็กเกจบำรุงรักษารายเดือน 1,000 ดอลลาร์ได้อีก
    ตอนนี้หลายบริษัทเริ่มตระหนักแล้วว่าการเอา LLM มาใช้กับงานจำนวนมากมีต้นทุนแพงกว่าการจ้างคน แต่ในขณะเดียวกันหลายแห่งก็ปลดคนเดิมออกไปแล้ว เลยดูเหมือนว่าช่วงเก็บเกี่ยวจะมาถึง เร็วกว่าภายใน 5 ปีมาก
    • ฉันเคยได้ยินบทสนทนาจริงมาหลายครั้งที่ผู้คนพยายามทำ prompt engineering กับปัญหาที่มี อัลกอริทึมแบบกำหนดแน่นอนและเหมาะที่สุด ที่รู้กันอยู่แล้ว
  • อย่างน้อยในแง่ของโค้ดซ้ำซ้อนและความสามารถในการบำรุงรักษา AI agent ยังมีพื้นที่ให้พัฒนาได้อีกมาก
    ถ้ามี semantic search ที่ยอดเยี่ยมมาก ก็ไม่จำเป็นต้องมี context window ขนาดมหึมาเสมอไป
    หากฝึกโมเดล embedding ให้เชี่ยวชาญเป็นพิเศษเพื่อให้เอเจนต์เขียนโค้ดหาแนวคิดที่ซ้ำกันได้เก่งขึ้น มันก็อาจโหลดทรัพยากรอีก 5 ตัวที่ต่างก็ใช้ priority queue จัดการเวลาหมดอายุเข้ามาไว้ในหน่วยความจำ แล้วรวมเป็นคลาส ExpirationQueue เดียวได้
    แต่ก็มีความเสี่ยงว่า AI แบบนี้จะรีบใช้ abstraction ก่อนเวลาอันควร มากเกินไป