การโต้กลับของนักพัฒนารุ่นจูเนียร์

 (sourcegraph.com)
36 คะแนน โดย GN⁺ 2025-04-01 | 23 ความคิดเห็น | แชร์ทาง WhatsApp

Part 1: คลื่น AI สำหรับการเขียนโค้ดทั้งหกลูก

  • Vibe coding คือชื่อเล่นแบบขำ ๆ ของวิธีเขียนโค้ดผ่านบทสนทนา โดยสั่งให้ LLM เขียนโค้ด จากนั้นให้ฟีดแบ็กกับผลลัพธ์และวนซ้ำไปเรื่อย ๆ
  • นี่เป็นแนวคิดที่แตกต่างจากการเขียนโค้ดแบบเดิมหรือการเขียนโค้ดที่เน้น autocomplete อย่างมาก เดิมทีถูกใช้โดยไม่มีคำนิยามชัดเจน แต่หลังจาก Andrej Karpathy ตั้งชื่อมันว่า "vibe coding" ก็แพร่กระจายอย่างรวดเร็ว
  • ปัจจุบัน vibe coding มีอยู่พร้อมกันในสามสถานะดังนี้:
    • 80% ของคนในอุตสาหกรรมยังไม่รู้ด้วยซ้ำว่า Vibe coding มีอยู่, หลายคนยังไม่เคยได้ยินคำว่า "coding agent" ด้วยซ้ำ
    • กำลังแพร่กระจายอย่างรุนแรงผ่านสื่อและ SNS, แม้จะมีทั้งข้อถกเถียงและความเห็นทั้งเห็นด้วยและไม่เห็นด้วย แต่นักพัฒนาจำนวนมากก็มองว่านี่คือเทคโนโลยีแห่งอนาคต
    • การเขียนโค้ดแบบ Chat เดิมถูกมองว่าเป็นเทคโนโลยียุคเก่าไปแล้ว, นักพัฒนาบางส่วนที่คลั่งไคล้วิธีใหม่ที่เร็วกว่า ไม่สนใจ chat อีกต่อไป
  • บทความนี้อธิบายพัฒนาการของการเขียนโค้ดด้วย AI เป็นทั้งหมดหกคลื่น:
    • การเขียนโค้ดแบบดั้งเดิม (2022)
    • การเขียนโค้ดแบบอิง autocomplete (2023)
    • การเขียนโค้ดแบบสนทนา (2024)
    • coding agent (ครึ่งแรกของปี 2025)
    • agent cluster (ครึ่งหลังของปี 2025)
    • agent fleet (2026)
  • ในบรรดาวิธีเหล่านี้ การเขียนโค้ดแบบดั้งเดิมและแบบอิง autocomplete กำลังค่อย ๆ เสื่อมถอยลง ส่วนวิธีที่เกิดขึ้นภายหลังต่างแพร่กระจายเร็วขึ้นเรื่อย ๆ
  • vibe coding ปรากฏแยกจากคลื่นเหล่านี้ในลักษณะเส้นประ
    • vibe coding อยู่ร่วมกับทุกวิธีข้างต้น และไม่ใช่วิธีเฉพาะแบบใดแบบหนึ่ง แต่เป็น แนวคิดที่ครอบคลุมทุกสถานการณ์ที่ AI เป็นผู้เขียนโค้ดส่วนใหญ่
  • "agent cluster" ที่กำลังจะมาถึงคือแนวคิดในการจัดการ agent หลายตัวแบบขนาน และ "agent fleet" คือการขยายไปสู่โครงสร้างที่ AI manager คอยกำกับ agent ชั้นล่าง
    • แผนผังองค์กร FY26 แสดงภาพนี้ไว้ โดยนักพัฒนาหนึ่งคนจะดูแลหลายกลุ่ม agent ซึ่งแต่ละกลุ่มทำหน้าที่ต่างกัน เช่น แก้บั๊ก พัฒนาฟีเจอร์ใหม่ และรีแฟกเตอร์สถาปัตยกรรม
  • ตอนนี้เมื่อ agent หยุดทำงานหรือเดินผิดทาง มนุษย์ยังต้องเข้าไปแทรกแซงเอง แต่ในไม่ช้า supervisor agent จะเข้ามารับบทบาทนี้แทน
  • สุดท้ายแล้วจะสามารถจัดการ agent พร้อมกันได้หลายสิบตัวขึ้นไป และมันจะกลายเป็นระบบอัตโนมัติสำหรับจัดการโค้ด legacy จำนวนมหาศาล
  • คาดว่า agent fleet แบบนี้จะ เกิดขึ้นแน่นอนภายในต้นปี 2026 และเทคโนโลยีสำหรับจัดงานแบบขนานอย่างมีประสิทธิภาพก็พร้อมอยู่แล้ว

Part 2: ตอนนี้คุณอยู่ตรงไหน?

  • หากคุณยังใช้ AI เป็นเพียงเครื่องมือ autocomplete สำหรับโค้ด หรือยังให้ความสำคัญกับ Completion Acceptance Rate (CAR) อยู่ คุณก็อยู่บน เส้นโค้งการเขียนโปรแกรมแบบดั้งเดิม ใน Figure 1
    • คาดว่าเส้นโค้งนี้จะหายไปอย่างสมบูรณ์ราวปี 2027
    • autocomplete เคยได้รับความนิยมเมื่อเพียงปีที่แล้ว แต่ตอนนี้ไม่ใช่เทคโนโลยีหลักอีกต่อไป
  • หากคุณอยู่ในจุดที่ก้าวหน้ากว่า คุณอาจกำลังใช้ เครื่องมือเขียนโค้ดแบบ chat ภายใน IDE เช่น Copilot, Cursor, Sourcegraph, Windsurf
    • กรณีนี้ถือว่าอยู่ในตำแหน่งที่โอเค เพราะคุณได้นำวิธีที่มีประสิทธิภาพกว่าการ autocomplete มาใช้แล้วมาก
    • การเขียนโค้ดแบบ chat ยังมีผู้ใช้จำนวนมาก แต่ ไม่ใช่มาตรฐานของเทคโนโลยีล่าสุดอีกแล้ว
  • coding agent ที่เพิ่งเกิดขึ้นไม่นานนี้ (Aider.chat, Claude Code เป็นต้น) กำลังแสดงศักยภาพว่าจะเหนือกว่าวิธีทั้งหมดนี้
    • มันจะถูกรวมเข้ากับ IDE อย่างเป็นธรรมชาติ และเร็วกับมีประสิทธิภาพกว่าวิธีแบบสนทนาเดิมมาก
    • พอได้ลองใช้ agent สักครั้งแล้ว ก็ยากมากที่จะกลับไปใช้วิธีเดิมอีก
  • การเขียนโค้ดแบบอิง agent ก็เป็น vibe coding ชนิดหนึ่งเช่นกัน
    • vibe coding หมายถึง "ทุกวิธีที่ AI เป็นคนเขียนโค้ด" และไม่ใช่ modality ทางเทคนิคแบบใดแบบหนึ่งโดยเฉพาะ
    • ความแตกต่างคือ agent สามารถ ทำงานต่อเองได้โดยไม่ต้องสนทนาบ่อย ๆ
  • การเปลี่ยนแปลงของแต่ละวิธีการเขียนโค้ดมีรูปแบบเป็น ตัวคูณด้านประสิทธิภาพการทำงาน ดังนี้:
    • การเขียนโค้ดแบบ Chat มีประสิทธิภาพมากกว่าการทำมือราว 5 เท่า
    • แบบอิง agent อาจมีประสิทธิภาพมากกว่า chat ได้อีก 5 เท่า
    • เมื่อเวลาผ่านไป แต่ละคลื่นอาจไปถึงระดับเพิ่มประสิทธิภาพ 10 เท่าได้ แต่ เส้นโค้งกลับแบนลงเพราะเทคโนโลยีใหม่เกิดขึ้นเร็วกว่า
  • ตอนนี้เราอยู่กลางมหาสมุทร AI ขนาดใหญ่ และต้องขี่คลื่นที่ยิ่งทรงพลังขึ้นเรื่อย ๆ ไปข้างหน้า
    • ทุกบริษัทล้วนอยู่บนเส้นโค้งการยอมรับอย่างน้อยหนึ่งเส้นใน Figure 1
    • จำเป็นต้องถามตัวเองว่าตอนนี้เราอยู่บนเส้นโค้งไหน
  • vibe coding ไม่ใช่วิธีทางเทคนิคเฉพาะ แต่คือปรัชญาและความจริงใหม่ของการพัฒนา
    • แก่นสำคัญคือไม่ได้เขียนโค้ดด้วยมือต่อไปอีกแล้ว
    • การเขียนโค้ดกำลังถูกส่งต่อให้ AI ส่วนมนุษย์ย้ายไปทำหน้าที่ตรวจทานและประสานผลลัพธ์แทน
  • ในพาร์ตถัดไปจะดูว่า การเปลี่ยนแปลงทางเทคโนโลยีนี้ ส่งผลทางการเงินอย่างไร
    • coding agent ไม่ใช่เวทมนตร์ แต่เป็น โครงสร้างที่ยิ่งเผาต้นทุนก็ยิ่งฉลาดขึ้น
    • หากยังไม่เคยลอง สิ่งสำคัญคือต้องลองใช้เดี๋ยวนี้ หรืออย่างน้อยสังเกตคนที่กำลังใช้อยู่

Part 3: คู่มือการใช้อูฐแบบใหม่

  • coding agent รุ่นล่าสุดเป็น เทคโนโลยีใหม่มากที่เพิ่งปรากฏเมื่อไม่กี่สัปดาห์ก่อน และส่วนใหญ่ทำงาน บนพื้นฐานของเทอร์มินัล
    • ถ้าจะเปรียบเทียบก็เหมือนคุณเดินมาตลอดชีวิตแล้วจู่ ๆ มีคนยกอูฐมาให้ สะดวกก็จริงแต่ควบคุมยากและกินเงินมาก
    • แค่มี "หนึ่งตัว" ก็เร็วกว่าเดินมากแล้ว แต่ก็อาจถ่มน้ำลาย กัด หรือวิ่งหนีได้เหมือนกัน
  • นักพัฒนาจำนวนมากยังคงสงสัยต่อ AI coding และยังคง อยากเขียนโค้ดด้วยมือเอง
    • บางคนถึงขั้นยืนยันชัดเจนว่า "ฉันคือคนเขียนโค้ด!"
    • แต่ความคิดแบบนี้กำลังตามความจริงไม่ทันแล้ว
  • ยิ่งเป็นคนที่สงสัยมากเท่าไร ก็ยิ่งควรลองดาวน์โหลดและใช้ coding agent รุ่นล่าสุด (ที่ออกหลังวันที่ 1 มีนาคม) เดี๋ยวนี้
    • เมื่อไม่กี่สัปดาห์ก่อน ผู้เขียนเองก็ได้เห็นพัฒนาการที่ก้าวหน้าจนน่าตกใจด้วยตาตัวเอง
  • หลักการของ agent เหมือนกับ vibe coding แต่ มนุษย์ไม่จำเป็นต้องคอยส่ง prompt ไปมาเอง
    • มันทำงานที่ซับซ้อนด้วยตัวเอง และจะกลับมาติดต่อผู้ใช้อีกครั้งเมื่อเสร็จงานหรือเจอปัญหา
    • เพราะมันทำงานทั้งหมดได้อัตโนมัติ 90~99% มนุษย์จึงหลุดจากคอขวด
  • สิ่งที่ต่างจากวิธีแบบ chat:
    • agent สามารถจัดการ หน่วยงานที่ใหญ่กว่า ได้ในครั้งเดียว
    • ระหว่างนั้นนักพัฒนาก็ไปทำอย่างอื่นได้อย่างอิสระ (เช่น หาอะไรกิน ดู Hacker News)
  • ตัวอย่าง: แค่บอกว่า "ช่วยแก้ JIRA ticket นี้ให้หน่อย"
    • มันจะไปหา JIRA CLI และถ้าจำเป็นก็ขอติดตั้ง
    • เขียนโปรแกรมชั่วคราวเพื่ออ่าน field ของ ticket
    • วิเคราะห์โค้ด → พบบั๊ก → เสนอแนวทางแก้ → เขียนและรันเทสต์ → วนลูปซ้ำ
  • ผลลัพธ์คือ agent เป็นเสมือน นักพัฒนามนุษย์ที่ทำงานเร็วอย่างตื่นตา แต่มีปัญหาเรื่องจับทิศทางเล็กน้อย
  • ข้อเสีย:
    • ตอนนี้ยัง จัดการงานขนาดเล็กได้อย่างเสถียรเท่านั้น
    • ความคาดหวังที่สูงเกินไปนำไปสู่ความล้มเหลว และทักษะ การแยกงาน (task decomposition) เป็นสิ่งจำเป็น
    • ถ้างานใหญ่เกินไป มันจะทำได้ไม่ดีและหลงทาง
  • เพราะฉะนั้นตอนนี้จึงยังต้อง เลือกปัญหาอย่างละเอียดและคอยกำกับดูแล และต้องปฏิบัติกับ agent เหมือนสัตว์ดื้อ
  • แต่สถานการณ์นี้กำลังจะเปลี่ยนในไม่ช้า:
    • agent จะถูกรวมเข้ากับ IDE อย่างเป็นธรรมชาติมากขึ้น และพัฒนาเป็น เครื่องมือที่ใช้ง่ายและคุ้นเคยกว่าเดิม
    • จากอูฐจะกลายเป็นม้าที่มีอาน และอีกไม่นานก็จะพัฒนาเป็น รถศึก (chariot)
  • สรุปคือ ตอนนี้คือ จังหวะที่ดีที่สุด ในการเรียนรู้วิธีทำงานร่วมกับ agent
    • และในไม่ช้าจะตามมาด้วยฟังก์ชันที่มากขึ้น อินเทอร์เฟซที่ดีขึ้น และการเพิ่มขึ้นของประสิทธิภาพที่มากกว่าเดิม

Part 4: ไหนบอกว่าไม่มีคณิตศาสตร์

  • ส่วนนี้เขียนสำหรับ CIO และผู้รับผิดชอบด้านการเงิน
  • ตอนนี้ที่เพิ่งสรุปงบ FY26 เสร็จ คุณตั้ง ต้นทุนการใช้ LLM ต่อหนึ่งนักพัฒนาไว้เท่าไร?
    • วันละ $25 อาจดูค่อนข้างกล้า แต่จริง ๆ แล้วใกล้เคียงกับระดับที่เหมาะสม
  • ความจริงรุนแรงกว่านั้น:
    • coding agent แพงมาก — ใช้โทเคนในระดับ $10~12 ต่อชั่วโมง
    • ถ้าไลเซนส์ coding assistant แบบเดิมมีราคาเดือนละราว $30 นี่หมายถึง ส่วนต่างด้านต้นทุนที่สูงกว่าหลายสิบเท่า
  • แต่เมื่อลองคำนวณดู หากใช้ coding agent วันละ 8~10 ชั่วโมง มันก็มี ประสิทธิภาพใกล้เคียงกับการจ้างนักพัฒนาจูเนียร์ 1 คน
    • ถ้าชั่วโมงละ $10 ก็ถือว่าถูกมาก และนักพัฒนาหนึ่งคนสามารถรัน agent พร้อมกันสองตัวได้
    • หากใช้จ่ายกับ LLM วันละประมาณ $100 ก็มีโอกาส เพิ่มประสิทธิภาพของนักพัฒนาได้มากกว่า 2 เท่า
  • แต่การเปลี่ยนแปลงจริง ๆ คือ agent cluster (คาดว่าใน Q3 ปี 2025) ที่กำลังจะมาถึง
    • นักพัฒนาหนึ่งคนจะสามารถ รัน agent หลายตัวแบบขนาน ได้
    • แต่ละ agent จะทำงานต่าง ๆ อย่างอิสระ ไม่ว่าจะเป็นแก้บั๊ก พัฒนาฟีเจอร์ใหม่ หรือเขียนเอกสาร
  • ผลที่ตามมาคือ นักพัฒนาหนึ่งคนจะเหมือนทำหน้าที่เป็น นักพัฒนาหลายคน
    • แน่นอนว่าคนที่ชำนาญยิ่งได้ผลมากกว่า
  • การมาถึงของ agent cluster จะเป็นจุดเปลี่ยนที่ทำให้ สภาพแวดล้อมการพัฒนาซอฟต์แวร์ย้ายขึ้นคลาวด์
    • การจัดการ agent หลักสิบถึงหลักร้อยบนเดสก์ท็อปเครื่องเดียวแทบเป็นไปไม่ได้
    • สภาพแวดล้อมการพัฒนาแบบคลาวด์จะกลายเป็นมาตรฐานโดยพฤตินัย
  • ดังนั้น ต้องจัดงบคลาวด์เพิ่มด้วย
  • ตัวอย่างเช่น หากนักพัฒนาหนึ่งคนรัน agent 5 ตัว:
    • ชั่วโมงละ $50 → คิดเป็นค่าใช้จ่ายราว $100,000 ต่อปี (ยังไม่รวมค่า cloud)
    • นี่ไม่ใช่ "การลงทุนราคาถูก" อีกต่อไป แต่เป็นรายจ่ายก้อนใหญ่
    • อย่างไรก็ตาม เนื่องจาก ประสิทธิภาพอาจเพิ่มขึ้นได้มากกว่า 5 เท่า จึงยังคาดหวัง ROI สูงในระยะยาวได้
  • ปัญหาคือ บริษัทส่วนใหญ่น่าจะ ยังไม่ได้ใส่ค่าใช้จ่าย LLM แบบนี้ไว้ในงบดำเนินงานปี 2026
    • สิ่งนี้จะทำให้ช่องว่างระหว่างบริษัทกว้างขึ้น: บริษัทที่มีงบจะได้เปรียบทางเทคโนโลยี ส่วนบริษัทที่ไม่มีงบก็เสี่ยงถูกทิ้งไว้ข้างหลัง
  • สรุป:
    • การพัฒนาซอฟต์แวร์ตอนนี้คือ รถไฟความเร็วสูงแบบ pay-to-play
    • หากไม่มีตั๋ว (งบประมาณ) ก็มีความเสี่ยงสูงที่จะหลุดออกจากขบวน

Part 5: agent fleet กำลังมา

  • จากตรงนี้ไปจะพูดถึงความจริงที่ค่อนข้างอึดอัดใจ
    • หากคุณยังไม่พร้อมทางใจ แนะนำให้พักสักครู่แล้วค่อยกลับมาอ่านต่อ
  • ขั้นถัดไปของ agent cluster คือ “agent fleet” ซึ่งหมายถึงสภาพแวดล้อมที่นักพัฒนาสามารถ ควบคุม agent มากกว่า 100 ตัวพร้อมกัน
    • ในช่วงนี้จะมี supervisor agent ชั้นบนเข้ามาควบคุมและดูแลกลุ่ม agent ชั้นล่าง และมนุษย์จะเข้าไปแทรกแซงเมื่อเกิดปัญหาเท่านั้น
  • บทบาทของนักพัฒนาในอนาคต จะไม่ใช่คนเขียนโค้ดอีกต่อไป แต่จะกลายเป็น
    • ผู้ที่คอยดูแลและกำกับ แดชบอร์ดที่แสดง agent และ AI manager
    • บางคนอาจประชดเรียกมันว่า "การเลี้ยงเด็ก AI" แต่สิ่งนี้แหละคือภาพของ การพัฒนาซอฟต์แวร์แบบใหม่ ที่กำลังจะมาถึง
  • สำหรับ CIO ในยุค agent fleet นั้น ค่าใช้จ่าย LLM ต่อหนึ่งนักพัฒนาอาจสูงถึงหลายพันดอลลาร์ต่อวัน
    • ต่อให้ต้นทุนการ inference ลดลง ตาม Jevons paradox แล้ว การใช้งานที่เพิ่มขึ้นจะไปหักล้างการประหยัดต้นทุน
    • ตัวอย่างเช่น ลองนึกถึง backlog ของบั๊กที่ไม่มีวันหมดของคุณ
  • แต่นี่ไม่ใช่ความสิ้นเปลือง มันคือ การลงทุนที่มีมูลค่ามหาศาล
    • ในที่สุดองค์กรวิศวกรรมก็จะขยับได้เร็วในระดับที่ผู้บริหารต้องการ
    • เรากำลังเข้าสู่ยุคที่สามารถสร้างความประหลาดใจและความพึงพอใจให้ลูกค้าได้อย่างคล่องตัวราวกับสตาร์ตอัป
  • ข้อเสียคือ ต้องใช้งบประมาณจำนวนมากมาก
    • บริษัทใหญ่บางแห่งจัดงบทดลอง LLM ไว้แล้วในรูปแบบ slush fund แต่
      • หลายบริษัทมีความเป็นไปได้สูงว่า ไม่ได้คำนึงถึงเรื่องนี้เลย ในรอบการจัดงบครั้งนี้
  • หากภายในสิ้นปีไม่สามารถจัดหา งบเพิ่ม $50,000 ต่อหนึ่งนักพัฒนา ได้ ก็อาจแทบไม่มีทางเลือกอื่นนอกจากการปรับโครงสร้าง
    • การเปลี่ยนแปลงนี้อาจกลับกลายเป็นผลดีต่อ สตาร์ตอัป ที่คล่องตัว
    • เรากำลังก้าวเข้าสู่ยุคที่ การมีหรือไม่มีงบประมาณ จะเป็นตัวตัดสินความสามารถในการแข่งขันของบริษัท มากกว่าช่องว่างด้านเทคโนโลยี
  • และถ้าคุณหาเงินงบก้อนนั้นไม่ได้ ก็ ชัดเจนอยู่แล้วว่าแผนกเดียวที่ลดคนได้คือที่ไหน
    • คำตอบนั้นขอให้ผู้อ่านตัดสินเอง
  • โชคดีที่ การคาดการณ์นี้อาจจะพูดเกินจริงไปเล็กน้อย
    • หลังจากคุยกับ Claude (LLM) ผู้เขียนมองว่า ถ้า เลื่อนกรอบเวลาคาดการณ์ออกไปราว 6 เดือน ก็อาจสมจริงกว่า
  • ข่าวดีคือ ตอนนี้คือจุดเริ่มต้น
    • ข่าวร้ายผ่านไปแล้ว และตอนนี้เหลือเพียงอย่างเดียว: การโต้กลับอันหอมหวาน

Part 6: การล้างแค้นของนักพัฒนารุ่นจูเนียร์

  • อนาคตไม่ได้มืดมน ตรงกันข้าม อุตสาหกรรมซอฟต์แวร์ยังคงมีงานอีกมาก
    • เพียงแต่ บทบาทนักพัฒนาแบบดั้งเดิมที่เขียนโค้ดด้วยมือตรง ๆ จะหายไป
  • หนึ่งในรูปแบบที่สังเกตเห็นตลอดปีที่ผ่านมา คือ นักพัฒนารุ่นจูเนียร์เปิดรับ AI มากกว่าซีเนียร์อย่างชัดเจน
    • บางคนก็กังวลว่า AI จะมาแย่งงาน แต่ส่วนใหญ่กำลังปรับตัวเข้ากับการเปลี่ยนแปลงอย่างรวดเร็ว
    • พวกเขาศึกษาหนังสือ AI Engineering ของ O’Reilly และใช้ chat coding กับ coding agent ได้อย่างชำนาญ
  • ในทางกลับกัน นักพัฒนาซีเนียร์จำนวนมาก แทบไม่เคยใช้งาน LLM จริงจังเลย หรือมีเพียงประสบการณ์ทางอ้อมเท่านั้น
    • ยังมีกรณีที่แสดง การต่อต้านเทคโนโลยี AI อย่างเปิดเผย ด้วย
    • ตัวอย่าง: นักพัฒนาจากบริษัทชื่อดังรายหนึ่งส่งสไลด์ PDF ในหัวข้อ “เลิกใช้ AI แล้วกลับไปเขียนโค้ดแบบดั้งเดิมกันเถอะ”
  • ปฏิกิริยาเช่นนี้เกิดจาก ความกังวลต่อเทคโนโลยีใหม่ และ ความสูญเสียจากการลงทุนกับความรู้เดิม
    • การเรียนรู้ภาษาใหม่หรือเครื่องมือใหม่โดยเนื้อแท้แล้วมาพร้อมกับ ความกลัวว่า 'ต้องกลับไปเริ่มต้นใหม่ทั้งหมด'
  • แต่ความจริงชัดเจนมาก:
    • คนที่เมิน AI ถูกทิ้งออกจากเกมไปแล้ว
    • นักพัฒนาจูเนียร์ถูกกว่า ปรับตัวเก่งกว่า และเรียนรู้เร็วกว่า
    • เมื่อบริษัทต้องปรับกำลังคนฝั่งนักพัฒนา ก็ชัดเจนว่าจะเลือกเก็บนักพัฒนาแบบไหนไว้

"AI ไม่จำเป็นต้องพิสูจน์ว่ามันเก่งกว่าคุณ คุณต่างหากที่ต้องรู้วิธีใช้ AI ให้เก่งกว่าเดิม"

  • กล่าวคือ ตอนนี้นักพัฒนาจูเนียร์อยู่ในจุดที่ ยืนอยู่บนเนินพร้อมถือดาบแห่งแสง
    • และกำลังตะโกนบอกนักพัฒนาซีเนียร์ให้ปรับตัวรับการเปลี่ยนแปลง
  • บทเรียนที่ได้จากสถานการณ์ทั้งหมดนี้คือ:
    • ไม่ว่าคุณจะเป็นใคร จะเป็นบริษัทหรือบุคคล — จงทำตัวเหมือนจูเนียร์
    • ตอนนี้คือเวลา ยอมรับและปรับตัวเข้ากับเทคโนโลยี AI
  • Sourcegraph วิเคราะห์กระแสวิวัฒนาการทางเทคโนโลยีนี้ทุกวัน
    • และการ เชื่อม coding agent เข้ากับทรัพย์สินโค้ดระดับองค์กร คือกลยุทธ์แกนหลักของยุคถัดไป
  • เมื่อมองภาพรวม ยิ่งมีการนำ AI มาใช้มากขึ้น งานที่เกี่ยวข้องกับซอฟต์แวร์ก็จะยิ่งเพิ่มขึ้นด้วยซ้ำ
    • ที่ตอนนี้การจ้างงานชะลอตัว เป็นเพียงเพราะบริษัทต่าง ๆ ยังไม่รู้ว่าจะตอบสนองต่อการเปลี่ยนแปลงนี้อย่างไร จึงยังระมัดระวังอยู่
    • ตามประวัติศาสตร์ ทุกช่วงเปลี่ยนผ่านทางเทคโนโลยีมักมาพร้อมกับประสิทธิภาพที่พุ่งสูงและ GDP ที่เติบโตขึ้น
  • ดังนั้น สิ่งที่ต้องทำตอนนี้คือ:
    • เรียนรู้และฝึกใช้ coding agent
    • PM และสายงานเทคนิคอื่นก็ไม่ใช่ข้อยกเว้น
    • การพัฒนาแบบอิง LLM ไม่ใช่แค่การเขียน prompt แต่จะเปลี่ยนงานพัฒนาจริงทั้งหมด ไม่ว่าจะเป็น การตรวจสอบ การทดสอบ และการประสานงาน
  • คำเตือน:
    • coding agent ทรงพลัง แต่ก็เป็น เครื่องมือแบบเครื่องเจาะอุโมงค์
    • มันแพง มันหยุดได้ และมันหลงทางได้
    • จำเป็นต้องมี การชี้นำอย่างต่อเนื่องและการตั้งความคาดหวังที่สมจริง
  • vibe coding ก็เหมือนชื่อของมัน คือ วิธีทำงานที่สนุก
    • การไม่ต้องเขียนโค้ดเองกลับให้ความรู้สึกปลดปล่อยอย่างน่าประหลาด
  • ความคิดที่ว่า “อีก 6 เดือนมันจะดีขึ้นกว่านี้ งั้นตอนนี้รอไปก่อน” เป็นความคิดที่อันตราย
    • สุดท้ายแล้วคุณจะ เริ่มช้า และไปถึงช้าที่สุด
  • agent กำลังมา และไม่ได้มีแค่ coding agent เท่านั้น
    • แต่ยังรวมถึง task agent อีกหลายร้อยตัวที่กำลังถูกนำมาใช้แล้วในงานทั้งองค์กร
  • แนวทางปฏิบัติโดยสรุป:
    • เปลี่ยนไปใช้ chat
    • ทิ้ง autocomplete
    • ลดการเขียนโค้ดด้วยมือลง
    • เรียนรู้การตรวจสอบ/รีวิว/การลงมือทำ ให้เข้ากับสภาพแวดล้อมที่ขับเคลื่อนด้วย AI
    • ทดลองและนำไปใช้ต่อเนื่อง ให้ทันกับกระแสเทคโนโลยีล่าสุด
  • แม้ตอนนี้ coding agent อาจยังดูยากและไม่สมบูรณ์ แต่ อีกไม่นานมันจะกลายเป็นเรื่องปกติ
    • มันคือเครื่องจักรเพิ่มประสิทธิภาพที่ถูกกว่ามนุษย์มาก และทางเลือกของบริษัทก็ชัดเจน
  • ภายในปลายปี 2025 ตำแหน่ง “software engineer” แทบจะไม่ได้เขียนโค้ดด้วยมือตรง ๆ แล้ว
    • แต่จะมุ่งไปที่ การปฏิบัติการ agent การประสานงาน และการกำกับการตรวจสอบความถูกต้อง แทน
  • ท้ายที่สุด หากตอนนี้คุณยังไม่รู้ว่าควรทำอะไร ให้ไปขอความช่วยเหลือจากนักพัฒนาจูเนียร์

ผ่านไปแล้วสองปีนับจากที่เขียน 'Cheating is all you need' และในช่วงนั้นทุกอย่างก็เปลี่ยนไปหมด
ตอนนี้เรากำลังอยู่กลางการเปลี่ยนแปลงพอดี และถึงเวลาที่ต้องขึ้นขี่กระแสนี้แล้ว

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

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

 
iwi19 2025-04-06

เรื่องนี้น่าอึดอัดตรงที่
แบบเดิม: คิด => โค้ด (ช้า) => ดีบัก
AI: คิด => เขียนพรอมป์ต์อย่างประณีต => โค้ด (พริบตาเดียว) => ดีบัก
แต่ปกติแล้ว การเขียนความคิดของตัวเองออกมาเป็นโค้ดมันเร็วกว่าการเอาไปเขียนเป็นพรอมป์ต์ไม่ใช่เหรอ? ยกเว้นเวลาที่ทำเรื่องที่เป็นที่รู้จักกันดีมากอยู่แล้ว.. ในส่วนที่ความน่าเชื่อถือสำคัญ ยังไงสุดท้ายพอเขียนเสร็จก็ต้องไล่ดูตรรกะด้วยตาอยู่ดี เลยฝากให้ทำแทนทั้งหมดก็ไม่ได้ และพอฝากไปก็เหมือนขาดจิตสำนึกในวิชาชีพด้วย
 
fudiso 2025-04-04

แม้จะเป็นผู้จัดการที่เคยเป็นนักพัฒนามาก่อนและไม่ได้เขียนโค้ดแล้ว แต่ช่วงนี้ผมกำลังกลับมาลองทำนั่นทำนี่ด้วยตัวเองอีกครั้ง รู้สึกเหมือนตัวเองกลายเป็นจูเนียร์อีกครั้ง พอสิ่งที่เคยสั่งให้ทีมทำ ตอนนี้ผมได้ลองทำเอง ความเร็วก็เพิ่มขึ้นมากจนแอบตกใจอยู่เหมือนกัน เลยทำให้คิดว่าแม้จะเป็นทีมขนาดเล็ก ก็น่าจะลองทำอะไรได้มากกว่านี้นะครับ ขอบคุณสำหรับเครื่องมือและคำอธิบายดี ๆ ครับ!
 
ifmkl 2025-04-04

ตอนนี้ผมกำลังพัฒนาไคลเอนต์ เซิร์ฟเวอร์ และแอดมินของเว็บเกมด้วย vibe coding เป็นงานอดิเรกอยู่ (แทบไม่ได้แก้เองเลย แค่คัดส่วนที่ต้องแก้ไปขอให้แก้ แล้วก็เอาโค้ดที่ได้มาใช้ตรง ๆ ตรง ๆ) ตอนนี้รวม ๆ ก็ประมาณ 20,000 บรรทัดแล้วครับ บางทีก็หัวร้อนบ้าง แต่ถ้าถามแบบหัวเสียไป ตอนนี้มันก็ยังเขียนโค้ดออกมาได้โอเคอยู่ครับ
 
csbzero 2025-04-03

ผมเห็นด้วยกับบทความข้างบนนี้มากกว่า 90%

ตอนนี้ดูเหมือนว่าจะเป็นช่วงเวลาที่ทั้งขีดความสามารถและกระบวนทัศน์ของการพัฒนากำลังเปลี่ยนไปอย่างแน่นอน

จากนี้ไป ผมคิดว่าเราต้องใส่ใจกับรูปแบบการออกแบบที่มากขึ้น วิธีการสร้างแอปพลิเคชันแบบทั่วไป และระเบียบวิธีในการแก้ปัญหา มากขึ้นในมุมของความสามารถด้านการกำกับดูแล

การพัฒนาอัลกอริทึมได้ก้าวข้ามขีดจำกัดของมนุษย์ไปนานแล้ว และเหมือนกับที่ AI กำลังทำการเพิ่มประสิทธิภาพอัลกอริทึมที่มนุษย์ไม่อาจเข้าใจได้ ตอนนี้คือเวลาที่นักพัฒนาในอนาคตต้องโฟกัสกับภาพที่กว้างขึ้นและเทรนด์ที่หลากหลายมากขึ้น
 
geek12356 2025-04-03

การเรียนรู้ AI เป็นเรื่องสำคัญ แต่ผมคิดว่าไม่จำเป็นต้องตอบสนองเกินเหตุทุกครั้งที่มีเทคโนโลยีใหม่ออกมา การทุ่มเวลาให้กับแนวคิดแกนหลักที่ไม่เปลี่ยนแปลงจะมีประสิทธิภาพมากกว่า และเพราะ AI เป็นสิ่งที่เรียนรู้ได้ค่อนข้างง่าย จึงค่อย ๆ ศึกษาไปอย่างช้า ๆ ก็ได้ ผมคิดว่าสิ่งสำคัญคือการพัฒนาขีดความสามารถที่เป็นแก่นแท้ แทนที่จะคอยวิ่งตามทุกกระแสอยู่ตลอดเวลา
 
zkata 2025-04-03

ตอนนี้ก็ยังทำได้ดีกว่าคนส่วนใหญ่อยู่แล้วครับ พอได้ศึกษาโค้ดของเหล่ากูรูโอเพนซอร์ส พอถามคำถามให้ดี คุณภาพของผลลัพธ์ก็ออกมาดีเลยครับ 555
 
rrockp 2025-04-02

ไม่มีใครรู้ว่าเทคโนโลยี AI ในแก่นแท้จะพัฒนาไปได้ถึงระดับไหน
แต่ในระดับตอนนี้ยังห่างไกลมาก
 
rom0203 2025-04-02

ในแง่ที่มูลค่าของความรู้หรือประสบการณ์ที่สะสมมาอาจลดลง ดูเหมือนว่าเส้นแบ่งระหว่างซีเนียร์กับจูเนียร์เองก็คงจะยิ่งเลือนรางลง

และน่าจะกลายเป็นตลาดที่คนส่วนน้อยกินรวบด้วย ต่อจากนี้การจ้างนักพัฒนาน่าจะเปลี่ยนไปในทิศทางของการคัดเลือก AI pilot ที่มีความสามารถด้านการคิดและการอนุมานโดยกำเนิดโดดเด่น มากกว่าดูจากความพยายามที่ลงไปหรือมีประสบการณ์ทำงานหรือไม่
 
raykim 2025-04-02

เอเจนต์กำกับดูแลงั้นเหรอ..

ถ้าขั้นตอนการพัฒนามีอยู่ราว ๆ 4 ขั้น (พัฒนา, ดีบัก, QA และดีบัก, รีแฟกเตอร์ริง) จะจับ hallucination ที่เกิดขึ้นในทั้ง 4 เลเยอร์ได้หมดไหม..

ตอนนี้ต่อให้เขียนความต้องการเรื่องดีบักและการทดสอบไว้ในพรอมป์ต์อย่างละเอียด บางทีก็ยังมีคำพูดเพ้อเจ้อประมาณว่าไม่รู้ว่าปัญหาคืออะไรโผล่มาอยู่ดีนะครับ (Sonnet 3.7).

เว้นแต่ว่าสถาปัตยกรรม Transformer เองจะเปลี่ยนไปนั่นแหละ.
 
chickendreamtree 2025-04-01

เหตุผลที่ผมเห็นด้วยกับ vibe coding ได้ยาก เป็นเพราะ AI agent ยังแก้ปัญหาความจริงที่ว่าเรายังต้องทำงานบนพื้นฐานของโค้ดไม่ได้ หากเป็นสภาพแวดล้อมที่ agent ทำงานได้อย่างอิสระจริง ๆ แล้ว ทำไมเรายังต้องมีโค้ดที่เครื่องเข้าใจได้ยากอยู่ด้วยล่ะ?

ผมคิดว่าช่วงเวลาที่ AI agent จะเปลี่ยนโฉมการพัฒนาซอฟต์แวร์อย่างแท้จริง ก็คือช่วงที่มันทำให้ชั้นของ "โค้ด" ถูกนามธรรมออกไปอย่างสิ้นเชิงสำหรับผู้ใช้ที่คอยสั่งการมัน ตอนนี้มันยังเป็นเพียงระดับของการสร้างเศษชิ้นส่วนโค้ดได้อย่างรวดเร็วเท่านั้น (ซึ่งแน่นอนว่านี่ก็ยอดเยี่ยมมากแล้ว)

ตราบใดที่ช่วงเวลาที่ AI agent จะปลดปล่อยพวกเราออกจากโค้ดยังมาไม่ถึง แม้ความเปลี่ยนแปลงจะน่าทึ่งแค่ไหน ผมก็ยังเห็นด้วยได้ยากกับคำกล่าวอ้างที่ว่าสิ่งนี้จะเปลี่ยนวิธีการทำงานของอุตสาหกรรมซอฟต์แวร์อย่างพลิกหน้ามือเป็นหลังมือ
 
halfenif 2025-04-01

ผมคิดว่ามันคล้ายกับการนำเมกะแฟกทอรีของ Hyundai Motor มาใช้

แรงงานแบบดั้งเดิมก็คงจะเปลี่ยนไปทำงานด้านการเซ็ตอัปและเมนเทนแนนซ์กันมากขึ้น (ส่วนนี้ผมเข้าใจได้มากกว่า)

แต่ส่วนที่ว่ามันจะเป็นแบบนั้นไปถึงขอบเขตของการจัดการเรื่องเชิงนามธรรมด้วยหรือเปล่า?

โดยส่วนตัวผมคิดว่าเป็นไปได้ครับ
 
bichi 2025-04-01

ยังสับสนอยู่บ้างเป็นครั้งคราวแม้แต่กับการเขียนคู่ของกลุ่มแพตเทิร์นที่ค่อนข้างซับซ้อนเรียงตามลำดับตัวอักษร.. (ได้โปรด !!) ไม่อยากพิมพ์คีย์บอร์ดเลยง่า
 
dlfldhkfk 2025-04-01

ถ้าไม่นับแค่ส่วนท้ายที่พูดถึงนักพัฒนารุ่นจูเนียร์ ก็ค่อนข้างเห็นด้วยอยู่พอสมควรครับ
รู้สึกว่าถ้าจะพูดให้แม่นกว่านี้ น่าจะเป็นว่าซีเนียร์หรือบริษัทเดิม ๆ ที่ไม่ยอมรับ AI จะถูกแทนที่ตามการเปลี่ยนผ่านของคนรุ่นใหม่ครับ
 
ahwjdekf 2025-04-01

ผลงานการพัฒนาสำคัญของบริษัทแทบจะร้อยเปอร์เซ็นต์ไม่เปิดเผยบนอินเทอร์เน็ต ด้วยระดับของ AI ตอนนี้ยังสร้างงานคุณภาพระดับนั้นไม่ได้ ไร้สาระสิ้นดี
 
alpharoom 2025-04-02

ถ้ามีความรู้และฝีมือใกล้เคียงกัน อยู่ในสภาพแวดล้อมที่เหมาะสมก็น่าจะได้ผลลัพธ์ที่ใกล้เคียงกันครับ

งานพัฒนาไม่ได้มีแค่เว็บแอปพลิเคชันที่มีข้อมูลเปิดเผยค่อนข้างมากเท่านั้น แต่ยังหลากหลายมากตั้งแต่กราฟิกเอนจินไปจนถึงระบบฝังตัวและการออกแบบชิประดับล่าง หลายสาขาเริ่มต้นจากศูนย์หรือแทบจะศูนย์เลยครับ สำหรับสายงานของผมเอง ทั้ง GitHub เอกสาร หรืออินเทอร์เน็ต ก็แทบไม่มีอะไรที่ใช้อ้างอิงได้อย่างเหมาะสมอยู่แล้ว แน่นอนว่าไม่ว่าจะเป็น Grok หรือ Claude ก็ให้ผลลัพธ์ที่ดีไม่ได้เช่นกัน ไม่นับกรณีที่ป้อนโค้ดทั้งหมดให้โมเดลหรือทำ fine-tuning นะครับ

ดูเหมือนว่าคุณอาจไม่ได้ทำงานพัฒนาที่ต้องใช้ความเชี่ยวชาญลักษณะนี้ หรือไม่มีทรัพย์สินภายในบริษัทที่ห้ามเปิดเผย ดังนั้นอย่ามั่นใจเกินไปว่าตัวเองเข้าใจสถานการณ์ได้อย่างถูกต้องครับ
 
roxie 2025-04-02

ข้อโต้แย้งที่ว่าถ้าไม่มีอยู่บนอินเทอร์เน็ต AI ก็จะไม่สามารถรุกล้ำได้ ดูแปลกไปหน่อยไหม? ผมคิดว่ายิ่งมีการวิจัยเกี่ยวกับวิธีการเรียนรู้ต่อเนื่องมากขึ้น AI ภายในองค์กรก็จะเข้ามาแทนที่ตำแหน่งของนักพัฒนาภายในองค์กรมากขึ้น
 
alpharoom 2025-04-05

มันไม่ได้หมายความว่าอินเทอร์เน็ตเป็นปัญหา แต่หมายความว่าไม่มีข้อมูลที่สามารถใช้ฝึกเพื่อสร้างโมเดล AI ได้ต่างหากนี่ครับ.. แล้วทำไมถึงมีงานวิจัยเกี่ยวกับวิธีการฝึกออกมาล่ะ? ผมกำลังพูดถึงความเป็นจริงที่จับต้องได้อยู่ตอนนี้นะครับ AI ที่จะมาแทนนักพัฒนาทุกคนภายในปลายปี 2025 สร้างไม่ได้เด็ดขาด ตั้งแต่แรกแล้วมันไม่ใช่ปัญหาเรื่องประสิทธิภาพครับ
 
roxie 2025-04-05

ผมคิดว่าคุณน่าจะเข้าใจที่ผมพูดผิดไปนะครับ ผมกำลังสมมติถึงสถานการณ์ที่บริษัทนำโค้ดของบริษัทไปฝึก AI แล้วนำมันมาใช้สร้างโค้ดภายในบริษัทครับ
 
iolothebard 2025-04-01

หัวหน้าก็ต้องรู้อะไรบ้างสิ… ว่ากำลังอู้หรือทำงาน กำลังทำเรื่องไร้สาระหรือกำลังทำได้ดี… นึกว่าหน้าที่หัวหน้าคือคนคอยปิด ๆ เปิด ๆ สวิตช์ไฟเสียอีก…
ถ้างานของหัวหน้าคือการปิด ๆ เปิด ๆ ไฟจริง… คนที่เหมาะจะถูกแทนที่ด้วย AI ที่สุดก็คือหัวหน้านั่นแหละ
 
dbs0829 2025-04-01

โดยส่วนตัวแล้วผมไม่ค่อยเห็นด้วยเท่าไร ถ้าซีเนียร์คนไหนถูกจูเนียร์ที่ทำงานร่วมกับ AI แซงได้ ผมมองว่าแต่แรกก็คงไม่ใช่ซีเนียร์จริง ๆ อยู่แล้ว
 
vwjdalsgkv 2025-04-01

น่าเสียดายที่ดูเหมือนจะมีหลักฐานสนับสนุนข้อกล่าวอ้างไม่เพียงพอ
 
carnoxen 2025-04-01

ชื่อของ Neo เปลี่ยนไปแล้วหรือครับ?
 
xguru 2025-04-01

ไม่ได้เปลี่ยนชื่อนะครับ แค่ดูเหมือนว่าเครื่องหมาย GN+ กับ neo ซ้ำกันเลยรวมให้เหลืออันเดียว คลิกแล้วจะไปที่ neo ครับ