ตอนนี้กำลังเกิดอะไรขึ้นกันแน่?

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

---

บทนำ: สภาพแวดล้อมทางวิศวกรรมที่น่ากังวล

• ช่วงหลังมานี้ ปรากฏการณ์ ภาวะหมดไฟ ในหมู่ วิศวกร รุนแรงขึ้นเรื่อย ๆ
• ในองค์กร มีการคาดหวังให้วิศวกรอาวุโสช่วยตรวจสอบและมีส่วนร่วมกับ ฟีเจอร์ที่ขับเคลื่อนด้วยกระแสหรือมีม ซึ่งแทบใช้งานจริงไม่ได้
• จากประสบการณ์ของผู้เขียน วิศวกรที่เก่งที่สุดมักอยากช่วยให้สมาชิกใหม่ในทีมเติบโตอยู่เสมอ

• แต่แทนที่ฟีดแบ็กเหล่านี้จะถูกใช้เป็นโอกาสในการพัฒนา นักพัฒนารุ่นเริ่มต้น กลับนำมันไปใช้เป็นเพียงพรอมป์ต์ถัดไปให้ generative AI
• ผู้เขียนยืนยันว่าเคยพบเห็นด้วยตาตัวเองหลายครั้งที่ วิศวกรจูเนียร์ ใช้เครื่องมือ LLM (large language model) ในระดับที่เรียกได้ว่าเกินพอดี

กรณีจริงในองค์กร: ผลเสียของการใช้ AI เกินพอดี

• เมื่อไม่นานมานี้ ผู้เขียนได้เห็นวิศวกรจูเนียร์สาธิตผลงานใหม่ใน town hall ของบริษัท
• แต่พวกเขากลับดูเหมือนไม่เข้าใจแม้แต่จุดประสงค์หรือวิธีการทำงานของฟีเจอร์นั้นอย่างแท้จริง
• อย่างไรก็ตาม ในองค์กรขนาดใหญ่ มักให้ความสำคัญกับการทำให้มัน “ดูเหมือนสำเร็จ” มากกว่าผลลัพธ์ที่แท้จริง
• เมื่อผู้จัดการอาวุโสคนหนึ่งเปิดเผยกรณีการใช้ AI ของพวกเขา เขากล่าวอย่างภาคภูมิใจว่า “นี่คือโค้ด 4,000 บรรทัดที่ Claude เขียน” และได้รับเสียงปรบมือ

• ผู้เขียนเองก็เคยได้รับคำขอให้ช่วยปรับปรุงฟีเจอร์เดิมเล็กน้อย และระหว่างตรวจโค้ดก็ได้ขอคอนเท็กซ์จาก วิศวกรจูเนียร์ ที่เพิ่งแก้ไขมันล่าสุด
• แม้จะส่ง URL ของคอมมิตบน Github ไปพร้อมคำถาม แต่ก็คาดว่าอีกฝ่ายนำเนื้อหานั้นไปใส่ใน LLM แล้วคัดลอกคำตอบกลับมาส่ง
• กระบวนการนี้ทำให้ผู้เขียนรู้สึกแปลก ๆ และไม่สบายใจอย่างบอกไม่ถูก

ทางลาดลื่นของ AI และข้อจำกัดของ code review

• จากกรณีของเพื่อน ผู้เขียนยืนยันได้ว่าเกิดการสูญเสียเวลาอย่างแท้จริง เมื่อ ตลอดหนึ่งเดือน มีวิศวกรหลายคนต้องช่วยกันรีวิวและพยายามรวม โค้ดที่ LLM สร้างอัตโนมัติ (vibe-coded PR)
• เพื่อนอีกคนหนึ่งก็เล่าว่าตัวเองหมดแรงไปกับการต้องรีวิว “โค้ดหลวม ๆ” ที่ AI สร้างขึ้นซ้ำแล้วซ้ำเล่า
• AI ไม่ได้ช่วยให้คุณภาพโค้ดดีขึ้นหรือทำให้เกิดการเรียนรู้ แต่กลับเพิ่มงานซ้ำซากเท่านั้น

วัฒนธรรมการพัฒนาและคุณค่าที่แท้จริงของการเติบโตแบบมนุษย์

• วิศวกรทุกคนต่างเติบโตขึ้นทีละขั้นด้วยความช่วยเหลือจากเพื่อนร่วมงานและเมนเทอร์
• การสอนกันโดยตรงและช่วยให้กันเติบโตคือแก่นแท้ของวัฒนธรรมวิศวกรรมซอฟต์แวร์
• แต่เมื่อมองว่าการลงทุนเช่นนี้สุดท้ายก็ถูกคัดลอกไปเป็นข้อมูลฝึกของ “โมเดลล่าสุด” แทบจะในทันที ก็อดรู้สึกหมดศรัทธาไม่ได้
• จึงเกิดคำถามพื้นฐานขึ้นมาว่า ถ้าเป็นเช่นนั้น การฝึกโมเดลแทนการพัฒนาวิศวกรจูเนียร์จะดีกว่าหรือไม่

• โลกแบบนั้นคือ ภาพอนาคตที่หม่นหมองอย่างยิ่ง

การทดลองไม่ใช้ AI และบทสรุป

• ผู้เขียนเสนอการทดลองตรงไปตรงมาว่า “ลองหยุดใช้ AI ดู”
• ตัวเขาเองก็เพิ่งหยุดสมัครสมาชิก Claude Pro หลังจากรีเซ็ตคอมพิวเตอร์
• การ ค้นหา ไม่กี่ครั้ง รวมถึงการอ่าน Stack Overflow และเอกสารทางการ กลับช่วยให้ได้ข้อสรุปที่น่าเชื่อถือกว่ามาก
• ผู้เขียนจึงรู้สึกว่าการตัดสินของตนเองเหนือกว่าผลลัพธ์จาก LLM ทั้งในด้านความแม่นยำและความน่าเชื่อถือ

คุณค่าทางเศรษฐกิจของเครื่องมือ generative AI และข้อจำกัดเชิงโครงสร้าง

• ผู้เขียนตั้งคำถามว่า “AI มีประโยชน์จริงหรือ?”
• หากมองอย่างเป็นกลาง สถานการณ์ตอนนี้ทำให้เกิดคำถามใหญ่ต่อคุณค่าของมัน
• วงจรแบบฉบับของสตาร์ตอัป AI มีดังนี้:
  • มีการนำ “AI” ไปใช้กับโดเมนเดิม และมีบริษัทเกิดใหม่เกิดขึ้นภายใต้ข้ออ้างเรื่องประสิทธิภาพ
  • สตาร์ตอัป AI สามารถระดมทุนจาก venture capital ได้สำเร็จ
  • จากนั้นจ่ายค่าบริการให้ผู้ให้บริการ AI (เช่น OpenAI)
  • แต่ตัวสตาร์ตอัป AI เองกลับทำกำไรไม่ได้
• หากมองเฉพาะกระบวนการนี้ อาจดูไม่ต่างจากระบบนิเวศ VC แบบเดิมมากนัก แต่ความต่างสำคัญคือ แม้แต่ผู้ให้บริการเอง (เช่น OpenAI) ก็ยังทำกำไรไม่ได้เช่นกัน
• เทคโนโลยีนี้ ไม่มีประสิทธิภาพโดยเนื้อแท้ และมีโครงสร้างที่ไม่เหมาะกับการขยายในวงกว้าง
• การใช้ พลังงานไฟฟ้าจำนวนมากเกินไป และผลกระทบต่อสิ่งแวดล้อมก็เป็นปัญหาร้ายแรงเช่นกัน

ปัจฉิมบท: ความจำเป็นของการมองความจริง

• เราอาจหวังให้กฎของ Moore กลับมาอีกครั้ง หรือหวังให้ทุกคนร่ำรวยได้ก่อนที่เอกภพจะเย็นดับลง
• แต่หาก มองความจริงตรง ๆ ธุรกิจ generative AI ก็เป็นทั้ง ภาพลวงตา รูปแบบหนึ่ง และปรากฏการณ์แบบ “จักรพรรดิไร้ฉลองพระองค์”

[ahwjdekf]

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

[dicebattle]

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

[GN⁺]

ความคิดเห็นบน Hacker News

• มีการเน้นว่าการนำ AI เข้ามาใช้ในองค์กรไม่ใช่แค่ปัญหาทางเทคนิค แต่เป็นเรื่องของการบริหารการเปลี่ยนแปลง ต้องมีทีมที่มีความสามารถซึ่งตั้งอยู่บนความไว้วางใจและความโปร่งใส เพื่อสร้างกระบวนการที่ผสานความเชี่ยวชาญของมนุษย์กับจุดแข็งของ LLM อย่างสมดุล จึงจะเห็นผลจริง ปัจจุบันก็เริ่มมีตัวอย่างของทีมขนาดเล็กที่สร้างผลงานใหญ่ได้ด้วย AI แต่สำหรับองค์กรส่วนใหญ่ โดยเฉพาะบริษัทใหญ่ ที่ไม่มีวัฒนธรรมองค์กรที่ดีอยู่แล้ว กลับพบว่า AI ยิ่งขยายความเป็นพิษนั้นให้หนักขึ้น ผู้บริหารบางคนถึงขั้นเข้าใจว่า "Story Point" เป็นเพียงหน่วยเวลา และมอง AI เป็นแค่เครื่องมือที่ทำให้ทุกอย่างลดลงครึ่งหนึ่ง โดยพื้นฐานแล้วพวกเขาห่างไกลจากกระบวนการสร้างซอฟต์แวร์ที่บำรุงรักษาได้ และมอง AI เป็นแค่ช่องทางเพิ่มกำไรแบบลวกๆ ผลวิจัยล่าสุดที่บอกว่า 95% ของโครงการนำร่อง AI ไม่สามารถสร้าง ROI ได้ ก็ถูกยกมาเป็นอีกตัวอย่างของความไร้ความสามารถของผู้บริหารยุคใหม่

  • มีคนชี้ว่าอาจเป็นเพียงกรณีที่ AI ถูกประเมินค่าสูงเกินจริง และตั้งคำถามว่า "ทีมเล็กที่ทำผลงานใหญ่ด้วย AI" นั้นหมายถึงทีมไหนกันแน่
  • มีการแสดงความเหนื่อยใจกับท่าทีที่เหมือนยกโทษให้ AI โดยบอกว่า "ก็เป็นปัญหาที่มีอยู่เดิมอยู่แล้ว" ทั้งที่ปัญหาสุขภาพจิตหรือปัญหาวัฒนธรรมองค์กรจาก AI ก็ควรถือว่าเป็นความรับผิดชอบของตัวเครื่องมือด้วย ไม่เห็นด้วยกับแนวคิดที่ว่าทั้งเครื่องมือและระบบไม่มีความรับผิดชอบ เพราะในความเป็นจริง เครื่องมือและสภาพแวดล้อมก็ส่งผลเช่นกัน
  • มีความเห็นว่าน่าเสียดายที่คำกล่าวว่า "ทีมเล็กทำงานใหญ่ได้" มักมีแต่เรื่องเล่าความสำเร็จโดยไม่มีกรณีตัวอย่างที่ชัดเจน
  • มองว่าการนำ AI เข้าไปใช้ในองค์กรที่ฝ่ายบริหารก็พังอยู่แล้ว เปรียบเหมือนยื่นปืนไรเฟิลอัตโนมัติให้ฝูงไวกิ้ง มีแต่จะเร่งให้องค์กรล่มเร็วขึ้น ไม่ใช่ว่าเทคโนโลยีเป็นต้นตอหลัก แต่ความล้มเหลวทางสังคมและจริยธรรมของคนส่วนใหญ่ในองค์กร หรือของผู้บริหารหลักไม่กี่คน ต่างหากที่เป็นสาเหตุแท้จริง
  • มีคนบอกว่าผู้บริหารจำนวนมากเข้าใจ "Story Point" ว่าเป็นเวลา และจากประสบการณ์ก็เห็นความผิดพลาดนี้มาแล้วในทุกบทบาทที่เคยร่วมงานด้วย ไม่ว่าจะเป็นนักพัฒนา QA PM หรือผู้บริหาร

• มีการพูดถึงการเกิดขึ้นของ "Prompstitudes(พนักงานที่พึ่งแต่พรอมป์ต์)" ผู้แสดงความเห็นเคยมีเพื่อนร่วมงานที่โยนแต่คำตอบจาก ChatGPT ซึ่งเดาเอาว่าตนเองน่าจะคิดอะไรมาให้ จนรู้สึกเหมือน "ถูกล้ำเส้น" ตามที่บทความว่าไว้ คนเหล่านี้ไม่ได้ไร้ความสามารถเสียทีเดียว แต่พึ่งพา LLM มากเกินไป จนให้ความรู้สึกเหมือนคนแก่ในคาสิโนที่หมุนสล็อตแมชชีนซ้ำไปเรื่อยๆ

• มีการแชร์ประสบการณ์ว่าเพิ่งคุยกับเพื่อนร่วมงานแล้วรู้สึกขัดใจ เพราะเห็นได้ชัดว่าคำตอบที่ได้รับถูกส่งต่อมาจาก ChatGPT จนรู้สึกว่าโดนเมินยังจะดีกว่า โดยเฉพาะเวลาที่ LLM พูดผิดอย่างมั่นใจยิ่งทำให้ปัญหารุนแรงขึ้น รายละเอียดเล็กๆ น้อยๆ เช่นชื่อในการตั้งค่ากับการ implement ที่ต่างกันเพียงเล็กน้อย ก็สามารถทำให้ LLM สับสนอย่างสิ้นเชิงได้ และต่างจากมนุษย์ตรงที่ LLM ไม่ได้เรียนรู้หรือตระหนักถึงความผิดพลาดของตัวเอง จึงมีแนวโน้มไหลไปในทิศทางผิดซ้ำๆ จนรู้สึกว่าสู้ต้องไปงัดกับโค้ดแย่ๆ ที่มนุษย์เขียนยังสบายใจกว่า

  • มีคนเล่าว่าเคยทำงานกับ PM ที่ใช้ AI เขียน PRD พอถามรายละเอียดเนื้อหาก็ตอบว่า "ไม่รู้เหมือนกัน AI เขียน" สุดท้าย PM เลยเหมือนยอมแพ้เรื่องการสื่อสารไอเดียจริงๆ และเหลือแค่การแสดงผลงานเชิงเอกสาร ทำให้ภาระการทำความเข้าใจและตีความ requirement ตกมาอยู่ที่ตนเองทั้งหมด จนสุดท้ายลาออกจากทีมนั้น
  • มีคนเห็นด้วยกับประเด็นที่ว่า "LLM มั่นใจในสิ่งที่ผิด" และบอกว่ามันเหมือนเพื่อนร่วมงานที่มีคาริสม่าและชอบทำเหมือนรู้ ทั้งที่จริงแล้วพูดผิดบ่อยมาก
  • มีคนเล่าว่าสัปดาห์นี้เพิ่งเจอประสบการณ์ประหลาดมาก ตนให้ Claude ช่วยรีวิวข้อเสนอภายในเกี่ยวกับสเปกเฉพาะทางที่ตัวเองก็ไม่ค่อยมั่นใจนัก แล้วมันก็ชี้ข้อผิดพลาดมาได้เยอะ พอส่งต่อให้ผู้รับผิดชอบสเปกในบริษัทพร้อมบอกว่า "นี่เป็นข้อเสนอจาก LLM อาจจะมั่วก็ได้" อีกฝ่ายกลับเอาข้อความของตนไปป้อนให้ LLM แล้วส่งคำตอบกลับมาถามอีกที สุดท้ายเลยรู้สึกว่าทุกคนกลายเป็นแค่ผู้ช่วยของ AI กันหมดแล้ว และถ้าอนาคตของการพัฒนาซอฟต์แวร์จะเป็นแบบนี้ก็ไม่ค่อยอยากเอาด้วย
  • มีความเห็นว่าโค้ดแย่ๆ จากมนุษย์ยังดีกว่าโค้ดแย่ๆ จาก LLM มาก เพราะอย่างน้อยโค้ดของมนุษย์ยังพอเดาเจตนาหรือบริบทได้ แต่โค้ดที่ LLM สร้างขึ้นอาจพังตั้งแต่ต้นจนจบ หรือถึงขั้นแต่งฟังก์ชันและแนวคิดที่ไม่มีอยู่จริงขึ้นมา มนุษย์ทั่วไปมักไม่เขียนโค้ดที่หลุดจากความจริงขนาดนั้น และการจะเข้าใจโค้ดจาก LLM บางทีก็เหมือนต้องกลับไปเรียนรู้ codebase ทั้งก้อนใหม่อีกครั้ง
  • มีคนทักว่าคำพูดที่ว่า LLM "เชื่อว่าตัวเองไม่เคยผิด" นั้นไม่ตรงนัก เพราะจริงๆ แล้ว LLM ไม่ได้เชื่อ คิด หรือรู้สึกอะไรเลย มันเพียงแค่ต่อโทเคนภาษาที่น่าจะเป็นไปได้มากที่สุดตามสถิติ และเติมความสุ่มเล็กน้อยเพื่อเลียนแบบความสร้างสรรค์เท่านั้น

• สำหรับคำถามว่า "เครื่องมือ AI มีประโยชน์จริงไหม?" มีคนตอบว่าตนใช้งานต่างจากคนอื่นจึงมองว่ามีประโยชน์ ตัวเองเขียนโปรแกรมมาตั้งแต่ปี 1983 และตอนนี้เกษียณแล้วจึงมักทำงานคนเดียว ลองใช้มาหลายเครื่องมือแต่ปัจจุบันใช้แค่ ChatGPT กับ Perplexity ไม่ได้ให้มันเขียนโค้ดแทนโดยตรง แต่ใช้โค้ดที่ LLM เสนอมาเป็นจุดตั้งต้นสำหรับอ้างอิง บางครั้งก็หยิบมาใช้ทั้งดุ้นแต่ส่วนใหญ่ต้องแก้และเขียนใหม่ เมื่อ LLM เริ่มให้ผลลัพธ์แย่ลงเรื่อยๆ ก็จะหยุดแล้วลองแนวทางใหม่ พอคิดถึงวิศวกรมือใหม่ที่คัดลอกโค้ดจาก LLM อย่างเดียวก็รู้สึกน่ากลัว สำหรับตนเอง คุณค่ามากที่สุดคือมันเหมือน StackOverflow ที่ตอบกลับทันที สามารถถามคำถามโง่ๆ ได้โดยไม่ต้องอาย และได้คำตอบที่ดีพออย่างรวดเร็ว ช่วงหลังตอนเรียนรู้การทำ PassKey บน iOS ก็เริ่มจากตัวอย่างโค้ดของ ChatGPT แล้วค่อยๆ ทำความเข้าใจทีละบรรทัด โค้ดแรกที่ได้กับของที่เสร็จสมบูรณ์ตอนนี้ต่างกันโดยสิ้นเชิง และกระบวนการนี้ก็ช่วยให้เข้าใจเทคโนโลยีลึกขึ้นมาก

  • มีคนบอกว่าตนใช้ AI ในแบบเดียวกัน และกำลังจะปิดงานโปรเจกต์ส่วนตัวที่ตอนแรกไม่รู้อะไรเลย แต่ตอนนี้เริ่มเข้าใจ codebase ดีพอสมควรแล้ว
  • อีกคนบอกว่าตนก็ใช้คล้ายกันในงานเล็กๆ หรือโปรเจกต์ส่วนตัว โดยให้ LLM เขียน "โค้ดชุดแรกที่พร้อมทิ้ง" แล้วค่อยสำรวจข้อจำกัดของมันเพื่อเข้าใจ problem domain ให้มากขึ้น สุดท้ายจึงมั่นใจพอที่จะลงมือ implement เอง

• มีความเห็นว่า LLM เก่งมากในการตอบคำถามทางเทคนิคหรือเสนอแนวทางใหม่ๆ แม้แต่มือใหม่ก็ถามได้อย่างอิสระโดยไม่ต้องกลัวถูกตัดสินแบบใน stackoverflow หรือรู้สึกติดกำแพง ส่วน Copilot ก็เด่นเรื่อง autocomplete ที่ช่วยให้เขียนโค้ดเร็วขึ้น รวมถึงเติมคอมเมนต์เอกสารหรือบรรทัดโค้ดให้โดยอัตโนมัติ ความช่วยเหลือเล็กๆ แบบนี้ตรวจทานได้ง่าย แต่ถ้าโยนโค้ดซับซ้อนทั้งก้อนให้ LLM จัดการ มักเกิดความวุ่นวายและสุดท้ายกลับต้องเสียเวลาไปกับการดีบักมากกว่าเดิม จึงมองว่าถ้ามือใหม่พึ่ง LLM มากเกินไป ก็จะพัฒนาทักษะการพัฒนาซอฟต์แวร์ที่แท้จริงได้ยาก

• มีคนบอกว่าส่วนตัวใช้ Zed สำหรับงานเขียนโค้ดเป็นงานอดิเรก เพราะ AI ในนั้นไม่พยายามทำตัวฉลาดเกินเหตุ สามารถเรียกใช้ฟีเจอร์ AI ได้อย่างนุ่มนวลเมื่อจำเป็น และเวลาปกติก็แค่เขียนโค้ดเอง ที่ทำงานกลับรู้สึกว่า VSCode AI รบกวนมากเกินไป ปัญหามีอยู่สองอย่าง อย่างแรกคือ interaction แตกง่ายเกินไป เช่นต้องคอยคลิก popup หรือเผลอแทรก autocomplete ก้อนใหญ่โดยไม่ตั้งใจ อย่างที่สองคือมันตัดจังหวะการทำงาน แม้ autocomplete จาก AI จะมีประโยชน์อยู่บ้างประมาณหนึ่งในสามของเวลา แต่เวลาที่เหลือกลับทำให้กระแสความคิดเดิมขาดตอน และต้องเสียสมาธิไปกับการตรวจดูผลลัพธ์ของ AI ใน Zed กลับไม่เจอปัญหาแบบนี้ จึงรู้สึกว่าได้ความสนุกของการเขียนโปรแกรมกลับคืนมา สุดท้ายแล้วปัญหาไม่ได้อยู่ที่ฟีเจอร์ AI เอง แต่อยู่ที่วิธีออกแบบและนำไปใช้

  • มีคนบอกว่าตนเห็นด้วยกับ Zed มาก ก่อนหน้านี้เล่นกับ JupyterLab หรือ Kate แล้วพอมาใช้ Zed ก็เปลี่ยนไปเลย Zed ให้ความรู้สึกว่า IDE/เอดิเตอร์เป็นตัวหลัก ส่วน AI หรือ Jupyter kernel เป็นฟีเจอร์เสริมที่คอยสนับสนุนอย่างเงียบๆ เมื่อจำเป็น ฟีเจอร์เสริมเหล่านี้ไม่ได้รบกวนงานแก้ไขข้อความหรือการเขียนโค้ดที่เป็นแกนหลัก มองว่าทีม Zed วางสมดุลนี้ไว้ได้ดีมาก

• มีความเห็นว่า AI มีประโยชน์มากในการทำ UX prototype เพราะสามารถสร้างของที่กดคลิกได้ขึ้นมาอย่างรวดเร็วภายในเวลาไม่นาน ทำให้วนซ้ำหลายรอบเพื่อหาทิศทางได้ก่อน แล้วค่อยทิ้งโค้ดนั้นและพัฒนาใหม่ในภายหลัง วิธีนี้ช่วยไม่ให้เสียเวลาจำนวนมากตั้งแต่เนิ่นๆ ไปกับทิศทางที่ผิด อย่างไรก็ตาม ยังมองว่าเรายังห่างไกลจากการให้ AI สร้างแอปที่มีความหมายจริงๆ ได้ทั้งระบบ

  • มีคนบอกว่าตนได้ประโยชน์จาก AI มากเวลาทำงานในพื้นที่ที่ไม่ค่อยถนัด เช่นสคริปต์ PowerShell ครั้งหนึ่งเคยต้องการสคริปต์ทำรายงานการตั้งค่า registry แล้ว Claude ก็เขียนให้ได้สมบูรณ์แบบจนประหยัดเวลาไปหนึ่งชั่วโมง
  • อีกคนบอกว่าตนก็รู้สึกคล้ายกันว่า AI เก่งมากในการอธิบาย error ทั้งช่วยหาทางแก้ที่แม่นขึ้นและช่วยจุดประกายไอเดียใหม่ๆ ได้มาก
  • มีคนชี้ว่าประเด็น "ทำ prototype แล้วทิ้ง เขียนใหม่" นั้นสำคัญมาก แต่ในโลกจริง PM มักลืมส่วนนี้จน prototype ถูกเอาไปใช้จริงอยู่บ่อยๆ ถึงอย่างนั้น ถ้าเจ้าของความเห็นมีวิธีใช้ที่ได้ผลกับตัวเองจริง ก็ถือเป็นเรื่องดี
  • มีคนถามต่อว่าอยากฟังรายละเอียดเพิ่มเติมเกี่ยวกับ use case, process และเครื่องมือ เพราะน่าจะช่วยตนเองและทีมได้จริง

• มีความเห็นว่า AI สำหรับตนเองก็เป็นแค่เครื่องมือชิ้นหนึ่ง ตนไม่ได้เป็นนักพัฒนาระดับสูง แต่เวลาเจอจุดตันในโปรเจกต์ส่วนตัวก็ใช้ AI เพื่อขอไอเดียและ feedback สิ่งสำคัญคือไม่ยกหน้าที่เขียนโค้ดให้ AI ทำแทน ยกเว้น boilerplate ที่ง่ายมากๆ เท่านั้น เพราะความสุขของการเขียนโค้ดด้วยตัวเองอยู่ที่การแก้ปัญหา การสร้างสรรค์ และการเรียนรู้

  • มีอีกคนบอกว่าโปรเจกต์ล่าสุดของตนคงไม่เสร็จแน่ถ้าไม่มี AI ช่วยเขียนโค้ดให้ ตั้งแต่การเซ็ตอัพ repository ทั้งหมดจนถึง PoC แม้จะยังหยาบๆ แต่ก็ทำให้ไปต่อได้ ทั้งที่ก่อนหน้านี้ไม่มีประสบการณ์กับ Django, JS หรือเว็บดีเวลอปเมนต์เลย และตอนนี้ก็กำลังค่อยๆ ปรับปรุงพร้อมเพิ่มความเข้าใจไปทีละขั้น

• มีคนเล่าเหตุการณ์ระหว่างรีวิวโค้ดของเพื่อนร่วมงานไม่นานมานี้ เห็นฟังก์ชันซับซ้อนชื่อ "prepareData" ที่เอาไว้ผสมและกรอง multidimensional array พอถามเจ้าของโค้ดว่า "มันทำหน้าที่อะไร" กลับได้คำตอบว่าให้ไปถาม LLM เองจะได้ประหยัดเวลา จนรู้สึกอึ้งและผิดหวัง เพราะแม้แต่คำถามพื้นฐานที่สุดสำหรับการรีวิวโค้ดก็ยังไม่ยอมตอบ

  • มีคนแซวเชิงขำๆ ว่าก็ให้ถาม LLM แล้วส่งคำตอบกลับไปให้เพื่อนร่วมงานเลย พอทำแบบนี้โต้กันสัก 20 รอบ ถ้าเขายังไม่เข้าใจ ก็ค่อยบอกให้เขาไปถาม LLM เองอีกที

• มีความกังวลว่าในอีก 10 ปีข้างหน้า นักพัฒนาจบใหม่อาจพยายามข้ามไปเป็นซีเนียร์ทันทีโดยไม่เคยผ่านประสบการณ์เขียนโค้ดด้วยตัวเองจริงๆ

  • มีคนเสริมว่าจริงๆ ปรากฏการณ์นี้เริ่มมาตั้งแต่ก่อนมี AI แล้ว เพราะโครงสร้างการจ้างงานที่ไม่ค่อยรับคนที่ประสบการณ์ไม่ถึง 10 ปี และอุตสาหกรรมก็ล้มเหลวในการยกระดับทักษะของคนรุ่นใหม่ ต่อให้บางบริษัทพยายามปั้นคนจบใหม่อย่างต่อเนื่อง พอเกิดวิกฤตก็มักปลดคนกลุ่มนี้ก่อน แล้วค่อยกลับไปเร่งรับแต่ซีเนียร์อีก วนเป็นวงจรซ้ำๆ
  • มีคนพูดติดตลกว่าเดี๋ยวนี้เป็นซีเนียร์ได้ตั้งแต่ปีที่ 3 แล้ว และไม่ต้องรอ 10 ปี แค่ 3 ปีก็กลายเป็น staff developer ได้อย่างรวดเร็วตามบรรยากาศยุคนี้
  • มีความเห็นว่าแนวคิด "Vibe coding" โผล่มาตั้งแต่ 9 เดือนก่อน และอีกไม่ถึง 2 ปีคนอาจเลิกเขียนหรือบำรุงรักษาโค้ดด้วยตัวเองกันแล้ว
  • ถึงอย่างนั้นก็ยังเชื่อว่าซอฟต์แวร์ที่เขียนโดยนักพัฒนาที่มีความเชี่ยวชาญจะยังคงมีอยู่เสมอ และตราบใดที่โค้ดจาก LLM ยังไม่สมบูรณ์ ความต้องการโค้ดคุณภาพสูงก็จะยังคงอยู่
  • มีคนมองว่าตอนนี้นักพัฒนาจูเนียร์มีมากเกินไป ขณะที่ปัญหาที่มีคุณค่าพอให้เก็บประสบการณ์จริงกลับมีไม่มาก ทำให้เติบโตต่อได้ยาก แต่ก่อนยังพอจ้างให้ทำ PoC หรือสคริปต์เล็กๆ ราคาถูกได้ ทว่าตอนนี้ AI พอทำบทบาทนั้นได้ในระดับหนึ่ง โอกาสเหล่านั้นจึงยิ่งลดลง พร้อมเสริมว่าสมัยก่อนเองก็มีจูเนียร์เยอะและตำแหน่งน้อยอยู่แล้ว

[happyiminjay]

ในช่วงเริ่มต้นของการพัฒนา ไม่ว่าจะเป็นการตั้งค่าสภาพแวดล้อมหรือการพัฒนาโมดูลขนาดเล็กในระดับ function นั้น AI มีประสิทธิภาพมาก แต่การทำ vibe coding แบบยัดทั้งโค้ดและพรอมป์ต์เข้าไปนอกจากนั้นถือเป็นหายนะในมุมมองของการบำรุงรักษา แม้ช่วงแรกอาจสำเร็จได้ไม่กี่ครั้ง แต่สุดท้ายทุกครั้งที่เกิดปัญหา ก็ต้องลองซ้ำ N ครั้งจนกว่า AI จะแก้ปัญหาของตัวเองได้ และความหวาดกลัวว่าโซลูชันนั้นจะไปก่อบั๊กอื่นอะไรขึ้นมาอีกก็จะคอยตามหลอกหลอนอยู่ตลอด

[ulsoft]

ขึ้นอยู่กับความสามารถของนักพัฒนา
ถ้าคนที่มีพื้นฐานที่ดีใช้ ก็สามารถใช้ AI เพื่อพัฒนางานคุณภาพสูงได้
แต่ถ้าไม่มีพื้นฐาน ก็จะหลงทางจนงานออกนอกลู่นอกทาง
เหมือนความต่างระหว่างเชฟที่มีพื้นฐานกับไม่มีพื้นฐาน