AI ไม่ได้ทำให้วิศวกรรมซอฟต์แวร์ง่ายขึ้น: มันแค่ทำให้การทำวิศวกรรมที่แย่เกิดขึ้นได้ง่ายกว่าเดิม

 (robenglander.com)
19 คะแนน โดย GN⁺ 2026-03-15 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • LLM ช่วยให้การเขียนโค้ดเร็วขึ้น แต่ไม่ได้ลด ความซับซ้อนโดยเนื้อแท้ของวิศวกรรมซอฟต์แวร์
  • เมื่อการสร้างโค้ดกลายเป็นเรื่องง่ายขึ้น ก็เกิด ภาพลวงว่าความเชี่ยวชาญไม่จำเป็นอีกต่อไป และบางองค์กรกำลังใช้เหตุผลนี้เพื่อลดจำนวนวิศวกร
  • ความยากที่แท้จริงไม่ใช่การเขียนโค้ด แต่คือ การออกแบบระบบ การกำหนดสเปก การตรวจสอบ และการรักษาความสอดคล้อง ซึ่ง AI กลับยิ่งเร่งภาระในส่วนนี้
  • ความไม่สอดคล้องระหว่างสเปก(specification) การทดสอบ และการนำไปใช้จริง(spec drift) กำลังรุนแรงขึ้นอย่างรวดเร็ว ทำให้ความเสี่ยงที่ความน่าเชื่อถือของระบบจะพังทลายเพิ่มสูงขึ้น
  • นี่เป็นรูปแบบที่ถูกสังเกตซ้ำแล้วซ้ำเล่าจากประสบการณ์กว่า 40 ปี โดยแม้แต่ในยุค Visual Basic ช่วงทศวรรษ 1990 ก็เคยมีคำกล่าวแบบเดียวกันว่า ไม่จำเป็นต้องมีความเชี่ยวชาญ ก่อนที่สุดท้ายจะต้องกลับมายืนยันความจำเป็นของวินัยทางวิศวกรรม
  • LLM เป็นเครื่องมือที่ยอดเยี่ยมสำหรับการสำรวจแนวทางออกแบบและเร่งการพัฒนาในระยะแรก แต่ควรถูกใช้ในทิศทางที่ เสริมวินัยทางวิศวกรรม ไม่ใช่แทนที่มัน

ความเข้าใจผิดอันตรายในอุตสาหกรรม

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

รูปแบบทางประวัติศาสตร์ที่วนซ้ำ

  • ตลอดประสบการณ์กว่า 40 ปี มีการเห็นรูปแบบเดิมซ้ำแล้วซ้ำเล่า: เครื่องมือใหม่ปรากฏขึ้น → มีการประกาศว่าปัญหาที่ยากได้รับการแก้แล้ว → ผลิตภาพพุ่งสูงและมีเดโมที่น่าประทับใจ → ลดคน → ความซับซ้อนของระบบเพิ่มขึ้น → สุดท้ายผลลัพธ์ไม่เป็นไปตามที่คาดหวัง
  • เครื่องมือและคำกล่าวอ้างอาจเปลี่ยนไป แต่ ตัวรูปแบบเองแทบไม่เคยเปลี่ยน

อุปมาเรื่องการซ่อมบำรุงอากาศยาน

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

DIY vs ระบบระดับมืออาชีพ

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

โค้ดไม่เคยเป็นส่วนที่ยากที่สุด

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

รูปแบบที่เคยเห็นแล้ว: ยุค Visual Basic

  • ในทศวรรษ 1990 ก็มีคำสัญญาคล้ายกันกับ Visual Basic: การเขียนโปรแกรมเป็นประชาธิปไตยขึ้น และไม่จำเป็นต้องมีความเชี่ยวชาญอีกต่อไป
  • ในความเป็นจริง Visual Basic ก็ทำให้เกิดแอปจำนวนมากที่คงไม่ถูกสร้างขึ้นหากไม่มีมัน
  • แต่เมื่อระบบมีขนาดใหญ่ขึ้นและเชื่อมต่อถึงกันมากขึ้น ก็มีการค้นพบอีกครั้งว่า การผลิตผลลัพธ์ซอฟต์แวร์กับการทำวิศวกรรมระบบที่เชื่อถือได้ไม่ใช่เรื่องเดียวกัน
  • สิ่งที่เกิดขึ้นตอนนี้คือ เวอร์ชันที่ขยายผลของรูปแบบเดิม: ไม่ได้ลดแค่กำแพงในการสร้างแอป แต่ลดกำแพงของการผลิตโค้ดโดยตรง
  • ตรงนี้เองที่ก่อให้เกิด ความเชื่อที่ชวนให้หลงใหลว่าความเชี่ยวชาญไม่จำเป็นอีกแล้ว

ปัญหาเรื่องการจัดแนว(Alignment)

  • ซอฟต์แวร์ที่เชื่อถือได้ขึ้นอยู่กับ การจัดแนว(alignment) ซึ่งแทบไม่ค่อยถูกพูดถึงนอกวงการวิศวกรรม
  • ระบบเริ่มจากแนวคิดว่าควรทำงานอย่างไร → ถูกบันทึกเป็น สเปก(specification) → วิศวกรแปลงสเปกนั้นเป็นการทดสอบและโค้ดโปรดักชัน
  • เพื่อให้ระบบมีความน่าเชื่อถือในระยะยาว ทั้งสเปก การทดสอบ และการนำไปใช้จริงทั้งสามส่วนต้อง คงสภาพการจัดแนวตรงกันอยู่เสมอ
  • เมื่อทั้งสามส่วนเริ่มคลาดเคลื่อนจากกัน ระบบก็จะค่อย ๆ สูญเสียความสมบูรณ์
    • สเปกอธิบายพฤติกรรมที่ไม่มีการนำไปใช้จริงอีกต่อไป
    • การทดสอบตรวจสอบพฤติกรรมได้เพียงบางส่วนและปล่อยส่วนอื่นตกหล่น
    • วิศวกรที่เข้ามาภายหลังต้องอ่านโค้ดแล้ว เดา ว่าระบบทำงานอย่างไร โดยโค้ดนั้นอาจสะท้อนหรือไม่สะท้อนเจตนาในการออกแบบเดิมก็ได้
  • เมื่อเวลาผ่านไป การคาดเดาจะสะสม จนท้ายที่สุดกลายเป็น ระบบที่ไม่มีใครเข้าใจอย่างแท้จริง
  • ปรากฏการณ์นี้ถูกเรียกว่า "spec drift": คำอธิบายของระบบกับตัวระบบเองค่อย ๆ ห่างออกจากกัน
    • โค้ดเปลี่ยนไปแล้ว แต่สเปกยังเหมือนเดิม
    • สเปกพัฒนาไปแล้ว แต่การทดสอบยังคงเดิม
    • พฤติกรรมค่อย ๆ เปลี่ยนไปจนไม่มีใครมั่นใจได้ว่าเจตนาเดิมคืออะไร
  • เมื่อการจัดแนวพังลง ความน่าเชื่อถือก็จะอยู่ได้ไม่นาน

AI กำลังเร่ง drift

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

พื้นที่ที่ AI ช่วยได้จริง

  • LLM ไม่ใช่ความผิดพลาด และหากใช้อย่างรอบคอบ มันสามารถปรับปรุงวิธีที่วิศวกรสำรวจและออกแบบระบบได้อย่างมาก
  • จุดที่โดดเด่นเป็นพิเศษคือ: การใช้เหตุผลกับปัญหา การสำรวจทางเลือกในการออกแบบ การสรุประบบที่ซับซ้อน และการสร้างร่างเพื่อเร่งขั้นตอนต้นของการพัฒนา
  • จุดที่ยากคือพื้นที่ที่ต้องอาศัย วินัยและความสม่ำเสมออย่างเข้มงวด ตลอดเวลา
  • การรักษาการจัดแนวระหว่างสเปก การทดสอบ และการนำไปใช้จริง ยังคงเป็น ความรับผิดชอบทางวิศวกรรม และไม่มีเครื่องมือใดมาแทนที่ความรับผิดชอบนี้ได้ (แม้จะช่วยสนับสนุนได้ก็ตาม)
  • โอกาสที่แท้จริงคือการใช้ LLM ไม่ใช่เพื่อให้มันค่อย ๆ เข้ามาแทนกระบวนการวิศวกรรม แต่เพื่อ เสริมความแข็งแรง ให้กระบวนการนั้น

วิศวกรรมซอฟต์แวร์แบบสนทนา

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

ความเชี่ยวชาญยังคงสำคัญ

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

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

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

 
GN⁺ 2026-03-15
ความเห็นจาก Hacker News

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

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

  • บางครั้งต่อให้มี unit test เป็นร้อย ก็ยังยากที่จะพิสูจน์ว่ารหัสถูกต้อง นักพัฒนาส่วนใหญ่ไม่รู้ว่าแค่ไหนถึงจะพอ คนที่ใช้ vibe coding หนัก ๆ ถึงขั้นปล่อยให้เครื่องทำเทสต์แทนด้วยซ้ำ พอไปถึงขั้นการออกแบบระบบ ก็ต้องการดีไซน์ที่รับประกัน ความปลอดภัยและความไม่แปรเปลี่ยนเชิงเวลา ของระบบโดยรวมได้ แต่คนส่วนใหญ่กลับแค่วาดกล่องกับลูกศรแล้วอ้าง “best practices” ซอฟต์แวร์คล้ายวิทยาศาสตร์ธรรมชาติมากกว่า ตาม ผลของ Sussman เราเลยใช้เวลากับการสังเกตมากขึ้น การใช้ GenAI เป็นเครื่องมือนั้นมีประโยชน์ได้ แต่การหยุดคิดแล้วพึ่งเครื่องมือคือเรื่องอันตราย

    • ฉันไม่รู้ด้วยซ้ำว่า unit test คืออะไร แต่ด้วย AI ฉันก็สร้างโปรแกรมที่ช่วยงานจริงได้มาก โปรแกรมเมอร์ระดับหัวกะทิ ต่อให้จ่ายเงินก็ยังไม่ยอมตอบอีเมลฉันเลย

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

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

  • ฉันเห็นด้วยกับคำพูดที่ว่า “การเขียนโค้ดไม่เคยเป็นส่วนที่ยากอยู่แล้ว” ผู้เชี่ยวชาญ รู้มาตั้งแต่แรกว่าควรสร้างอะไร สิ่งที่น่ารำคาญมีแค่งานซ้ำ ๆ

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

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

  • ฉันเห็นด้วยได้ยากกับคำกล่าวที่ว่า “การเขียนโค้ดไม่ใช่ส่วนที่ยาก” แน่นอนว่ามันไม่ได้ยากเสมอไป แต่เมื่อมี ข้อจำกัดด้านเวลา การเขียนโค้ดก็กลายเป็นคอขวด AI ทำให้เราลองสิ่งที่เมื่อก่อนเป็นไปไม่ได้ และช่วยให้มี เวลาเชิงวิศวกรรม มากขึ้น

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

  • AI ทำให้งานวิศวกรรมที่ดีง่ายขึ้นด้วย สุดท้ายมันคือ ตัวขยายพฤติกรรม

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

  • ฉันเป็น คนที่สงสัยใน AI แต่ไม่ได้คิดว่ามันจะมาแย่งงานเพื่อนร่วมงาน กลับกัน มันช่วยประหยัดเวลาของฉัน ฉันใช้มันเป็น เครื่องมือวิจัย ที่ดีกว่า Google และมันมีประโยชน์กับการสำรวจโค้ดเบส การสร้าง helper function และการทบทวนข้อผิดพลาด

    • ฉันก็เห็นด้วย คิดว่านี่แหละคือ ปลายทางของการใช้งาน AI ในที่สุด

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

    • LLM สามารถสำรวจ ขอบเขตความรู้ ที่กว้างกว่ามนุษย์ได้ในทันที แต่การตัดสินขั้นสุดท้ายยังขึ้นอยู่กับ รสนิยมและเซนส์ด้านคุณภาพ ของมนุษย์

  • คนแบบนี้ (พวกมองโลกในแง่ร้าย) ต้องเจอโมเดลออกมาอีกกี่รุ่นถึงจะ ยอมแพ้? สอง? สาม?