การมาถึงของ “นรกแห่ง vibe coding” ที่เข้ามาแทน “นรกแห่งการทำตาม tutorial”

 (blog.boot.dev)
28 คะแนน โดย GN⁺ 2025-10-12 | 3 ความคิดเห็น | แชร์ทาง WhatsApp
  • ในช่วงหลังของวงการ การเรียนเขียนโค้ด ปัญหาใหม่ที่เริ่มเด่นชัดขึ้นแทน “นรกแห่งการทำตาม tutorial” คือ “นรกแห่ง vibe coding”
  • ถ้า “นรกแห่งการทำตาม tutorial” คือสภาวะที่ "ทำอะไรไม่ได้เลยถ้าไม่มี tutorial" นรกแห่ง vibe coding ก็คือสภาวะ "เขียนโค้ดไม่ได้ถ้าไม่มี AI และไม่เข้าใจว่าโค้ดที่ AI สร้างขึ้นทำงานอย่างไร"
  • กำลังเกิดสถานการณ์ย้อนแย้งที่ การใช้เครื่องมือ AI มากเกินไปบั่นทอนแรงจูงใจในการเรียนรู้ และยิ่งคนที่มี AI literacy ต่ำกลับยิ่งใช้งาน AI มาก
  • เครื่องมือ AI หากใช้อย่างเหมาะสมสามารถเป็น ตัวช่วยการเรียนรู้ที่ทรงพลังมาก ได้ แต่การใช้แบบมุ่งแค่ “เอาคำตอบ” ขัดขวางการสร้างความเข้าใจอย่างเป็นระบบ
  • หัวใจสำคัญคือการคิดด้วยตัวเองและพยายามแก้ปัญหาด้วยตนเองระหว่างเรียน ทัศนคติในการสะสมประสบการณ์แก้ปัญหาโดยไม่พึ่ง tutorial หรือ AI ช่วยเหลือมากเกินไปจึงสำคัญ

ฉากหลังของปัญหา: จากนรกแห่ง tutorial สู่นรกแห่ง vibe coding

  • ในปี 2019 ปัญหาหลักของการเรียนเขียนโค้ดคือ "นรกแห่งการทำตาม tutorial"
    • ทำตาม tutorial ได้สำเร็จ แต่พอทำคนเดียวกลับสร้างอะไรเองไม่ได้
    • ใช้เวลา ดูวิดีโอเกี่ยวกับการเขียนโปรแกรมมากกว่าการเขียนโปรแกรมจริง และไม่เข้าใจแนวคิดหลัก
    • สุดท้ายจึงมีเพียงความรู้ผิวเผิน เข้าใจกลไกภายในไม่จริง และเขียนโค้ดเองในสถานการณ์จริงไม่ได้
  • Boot.dev แก้ปัญหานี้โดยโฟกัส 3 เรื่อง
    • หลักสูตรเชิงลึก: เน้นความจำเป็นของการเรียนพื้นฐาน CS แม้อยู่นอกระบบมหาวิทยาลัยแบบดั้งเดิม
    • แนวทางเน้นลงมือปฏิบัติ: ทุกแนวคิดต้องเรียนควบคู่กับการเขียนโค้ดจริง
    • เสริม rich text มากกว่าวิดีโอ: เพราะวิดีโอมีความเสี่ยงที่จะกลายเป็นการเสพแบบ passive
  • ในปี 2019 คอร์สยาวบน YouTube หลายรายการที่เคยมียอดดูหลักล้าน ทุกวันนี้กลับไปไม่ถึง 50,000 วิวได้ยาก
    • ช่องอย่าง FreeCodeCamp, Traversy Media, Web Dev Simplified แสดงให้เห็นแนวโน้มนี้
  • อย่างไรก็ตาม ข้อมูล Google Trends ของคำว่า "learn to code" ยังแสดงให้เห็นว่า ความสนใจยังคงอยู่ในระดับสูง
  • Boot.dev มีผู้ใช้ใหม่สมัครวันละราว 1,300 คน และในช่วง 18 เดือนที่ผ่านมา เสียงบ่นเรื่องนรกแห่ง tutorial ลดลง แต่ ความยากลำบากรูปแบบใหม่กำลังเกิดขึ้น

ความหมายของนรกแห่ง vibe coding

  • ลักษณะของ นรกแห่งการทำตาม tutorial
    • "สร้างอะไรไม่ได้เลยถ้าไม่มี tutorial"
    • "อ่านเอกสารไม่เข้าใจ เลยต้องพึ่งวิดีโอ"
    • "งานง่าย ๆ ก็ยังต้องใช้ framework ซับซ้อน"
  • ลักษณะของ นรกแห่ง vibe coding
    • "ทำอะไรไม่ได้เลยถ้าไม่มีตัวช่วยจาก Cursor"
    • "ผมสร้างเกม tower defense เจ๋ง ๆ ได้แล้ว นี่ลิงก์ครับ http://localhost:3000";
    • "ผมไม่รู้ว่าทำไม Claude ถึงเพิ่มมา 6,379 บรรทัดเพื่อทำ image lazy-load"
  • ตอนนี้ผู้เรียนแบบ self-directed จำนวนมากกำลังสร้างของได้หลายอย่างก็จริง แต่กลับ สร้างโปรเจกต์โดยไม่พัฒนา mental model ว่าซอฟต์แวร์ทำงานอย่างไร
  • พวกเขาต้องสู้กับ hallucination ของ AI และต่อสู้กับบอตที่เอาแต่พยายามให้เทสต์ผ่าน โดย เชื่อโค้ดที่ AI สร้างอย่างมืดบอดมากกว่าจะแก้ปัญหาจริง

อนาคตและความจริงของ AI coding

  • ผู้เขียนมีมุมมองค่อนข้างบวกในระยะสั้นว่า AI จะยังไม่มาแทนนักพัฒนาได้ทั้งหมด
    • ผ่านมา 3 ปีแล้วนับตั้งแต่คำพูดว่า "อีก 6 เดือน AI ก็จะแย่งงานหมด" แต่ทุกวันนี้ก็ยังมีการจ้างนักพัฒนาอยู่
  • แม้ GPT-5 จะเปิดตัวแล้ว แต่ก็ เป็นเพียงการพัฒนาต่อเนื่องจาก GPT-4 แบบค่อยเป็นค่อยไป และถูกมองว่าเป็นหลักฐานว่า AGI ยังไม่มาถึงในเร็ว ๆ นี้
  • แม้ผู้เขียนจะใช้เครื่องมือ AI ทุกวัน แต่ก็ ยังไม่แน่ใจว่ามันเพิ่มผลิตภาพจริงมากแค่ไหน
    • ยังไม่ชัดว่า AI ทำให้ทำงานได้มีประสิทธิภาพขึ้น หรือทำให้ขี้เกียจขึ้นกันแน่
  • ผลวิจัยปี 2025: นักพัฒนาคาดว่า AI จะเพิ่มผลิตภาพ 20-25% แต่ผลจริงกลับช้าลง 19%
    • เป็นผลลัพธ์ที่น่าผิดหวังเมื่อเทียบกับการลงทุน 7 ล้านล้านดอลลาร์

ความเสี่ยงที่ AI จะบั่นทอนแรงจูงใจในการเรียนรู้

  • วัฒนธรรมการใช้ AI อาจส่งผลลบต่อแรงจูงใจของผู้เรียน
  • สิ่งที่น่ากังวลที่สุดในกระแส AI (หรือฟองสบู่?) คือการเกิดขึ้นของคนรุ่นที่มีทัศนคติว่า "จะเรียนไปทำไม ในเมื่อ AI ก็รู้อยู่แล้วทั้งหมด"
  • หาก AI ไม่สามารถแทนงาน white-collar ได้ทั้งหมดจริง ๆ เราอาจต้องเจอกับทั้งฟองสบู่ในตลาดหุ้นและ ภาวะขาดแคลนแรงงานที่มีการศึกษา
  • นักลงทุนที่ไม่มีพื้นฐานทางเทคนิค มักเข้าใจผิดว่า “AI แทนการเขียนโค้ดทั้งหมดได้แล้ว” ขณะที่นักพัฒนาระดับ senior จำนวนมากก็ยัง หาวิธีที่เป็นประโยชน์ในการผสาน AI เข้ากับงานประจำวันไม่ได้
  • เรื่องที่น่ากังวลคือ ยิ่งคนที่มี AI literacy ต่ำกลับยิ่งมีแนวโน้มใช้ AI มากกว่า
    • มันกลายเป็นกับดักแบบ ‘Dunning-Kruger’ ขั้นสุดท้าย คือคนที่รู้น้อยกลับเข้าใจผิดว่าตัวเองรู้มาก
    • ผู้เรียนจึงสรุปว่า "ในเมื่อ AI รู้อยู่แล้ว" การพัฒนาตัวเองก็ไม่มีความหมาย

AI มีประโยชน์ต่อการเรียนจริงหรือไม่?

  • ความสนใจทางสังคมต่อการเรียนเขียนโค้ดยังคงสูงอยู่
  • AI อาจมีประโยชน์ต่อการเรียนรู้ แต่มีปัญหาเชิงโครงสร้างอยู่ 2 ข้อ

  • ข้อแรก: ปัญหาเรื่องการประจบเห็นด้วย (sycophant)

    • แชตบอต AI มักมีแนวโน้มเห็นด้วยกับผู้ถามมากเกินไป
    • หากลองคุยเรื่อง “ROAS(ผลตอบแทนจากค่าโฆษณา)” จะพบว่าแม้จะใช้ข้อมูลชุดเดียวกัน แต่แค่เปลี่ยนทิศทางของคำถามก็สามารถ สรุปผลได้ตรงกันข้ามโดยสิ้นเชิง และตอบอย่างมั่นใจด้วยน้ำเสียงแบบผู้เชี่ยวชาญทั้งคู่
    • สิ่งนี้พรากโอกาสที่ผู้เรียนจะได้ฝึกการตรวจสอบ การคิดเชิงวิพากษ์ และการถูกชี้ข้อผิดพลาด
      • เหตุผลที่เราถามผู้เชี่ยวชาญก็เพื่อให้เขา บอกเราเมื่อเราผิด
      • IRC chat หรือ Stack Overflow เคยทำหน้าที่นี้ได้ดีมาก (อาจจะดีเกินไปด้วยซ้ำ)
      • แชตบอต LLM (large language model) มีแนวโน้มสูงที่จะไม่สามารถแก้ความเข้าใจผิดพื้นฐานของผู้เรียนได้
      • ปัจจุบันนักเรียนจึงคุยกับ LLM อย่างสบายใจ และ ได้ยินสิ่งที่อยากได้ยิน มากกว่าสิ่งที่จำเป็นต้องได้ยิน

  • ปัญหาข้อที่สอง: ผู้เรียนต้องการ ‘ความเห็น’ ที่แท้จริง

    • AI มักเสนอ จุดยืนที่สมดุลเกินไป
      • "บางคนคิดแบบ X และบางคนคิดแบบ Y"
      • ยิ่งทำให้ผู้เรียนตัดสินใจได้ยากขึ้นว่าควรเห็นด้วยกับฝ่ายไหน
    • แม้จะลอง prompt ให้รับบทเป็น "นักทุนนิยม" หรือ "นักปฏิวัติมาร์กซิสต์" ก็ ยังไม่ได้ผลที่น่าพอใจ
    • ผู้เรียนต้องการฟัง ความเห็นและข้อวิจารณ์ที่มาจากประสบการณ์จริง
      • DHH กับ เหตุผลที่ถอด TypeScript ออกจาก Turbo
      • Anders Hejlsberg กับสิ่งที่ TypeScript ช่วยแก้ให้กับนักพัฒนา JavaScript
      • ความเห็นจริงที่เผยให้เห็นอคติและบริบทของผู้เขียนอย่างชัดเจน ช่วยให้ ก่อรูป mental model ที่ละเอียดอ่อนขึ้น
    • คำตอบแบบเป็นกลางและระมัดระวังตามสไตล์ LLM กลับขัดขวางการซึมซับความรู้จริง

กรณีที่ AI ช่วยการเรียนได้จริง

  • AI ถ้าใช้อย่างถูกวิธีคือ เครื่องมือเพื่อการเรียนรู้ที่น่าทึ่ง
  • ไม่เคยมีช่วงเวลาไหนที่เรียนเขียนโค้ดได้ง่ายเท่านี้มาก่อน
  • กรณีของ Boots ตัวช่วยสอน AI ของ Boot.dev
    • นักเรียนใช้ การคุยกับ AI tutor (Boots) มากกว่าการดู instructor solution (เฉลยในอุดมคติ) เกือบ 4 เท่า
    • Boots ต่างจากแชตบอตทั่วไปตรงที่ช่วยการเรียนด้วยวิธีต่อไปนี้
      • ถูก prompt ล่วงหน้าไม่ให้บอกคำตอบตรง ๆ
      • ใช้วิธีแบบ Socratic เพื่อชวนให้นักเรียนคิดลึกขึ้นเกี่ยวกับปัญหา
      • เข้าถึง solution ของผู้สอนได้ จึงมีโอกาส hallucinate เรื่องคำตอบน้อยกว่ามาก
      • มีคาแรกเตอร์ที่สนุกสนาน (หมีพ่อมด)

วิธีหนีออกจากนรกแห่ง vibe coding

  • สรุปแล้ว ไม่ว่าจะเป็น นรกแห่ง tutorial หรือนรกแห่ง vibe สิ่งสำคัญมากคือ ‘อย่าฝากให้คนอื่นทำแทน จงลงมือทำเอง’
    • นรกแห่ง tutorial: ปิดวิดีโอแล้วลงมือเขียนโค้ดเอง
    • นรกแห่ง vibe: ปิด AI autocomplete อย่าง Copilot แล้วสะสมประสบการณ์แก้ปัญหาด้วยตัวเอง
  • สิ่งที่ควรหลีกเลี่ยง:
    • AI autocomplete ใน editor
    • การใช้ agent mode และเครื่องมือ automation ด้วย AI มาจัดการโปรเจกต์
  • สิ่งที่ใช้ประโยชน์ได้:
    • แชตบอตที่ตอบคำถาม อธิบายแนวคิด และยกตัวอย่างได้
    • system prompt ที่กระตุ้นให้ถามแบบ Socratic เพื่อเร่งการคิดเชิงลึก
    • system prompt ที่กำชับให้ยกแหล่งที่มาและลิงก์เอกสารเมื่อมีการอ้างข้ออ้าง เพื่อเพิ่มความน่าเชื่อถือของข้อมูล

หลักการสำคัญ

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

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

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

 
aer0700 2025-10-12

บริบทอาจต่างกันเล็กน้อย แต่ที่เกิด tutorial hell ขึ้นก็เป็นเพราะเฟรมเวิร์กทิวทอเรียลไม่ได้ถูกใช้เป็นสื่อการสอน CS พื้นฐานด้วยเช่นกัน
ผู้เริ่มต้นที่ดู Django tutorial แล้วลองทำ poll app จะไม่สามารถสร้างบล็อกเองได้ ก็เพราะ Django tutorial เป็นบทความที่อธิบาย Django ให้คนที่รู้อยู่แล้วว่า HTTP คืออะไร, template คืออะไร, WS คืออะไร, DB คืออะไร ฯลฯ ไม่ใช่บทความที่อธิบายเว็บเอง มีบริบทจำนวนมากถูกละไว้ใน Django tutorial มาก และผมคิดว่านี่อาจเป็นสาเหตุที่ทำให้เกิด tutorial hell
การลองเขียน Django tutorial ใหม่ให้เป็นฉบับสำหรับคนที่เพิ่งเริ่มเขียนโปรแกรมวันนี้เป็นวันแรกก็ดูจะเป็นโจทย์ที่น่าสนใจเหมือนกัน เช่น อธิบายโครงสร้างของ HTTP ก่อน แล้วค่อยอธิบายว่า Django จัดการแต่ละองค์ประกอบอย่างไร
 
gudrb963 2025-10-15

เป็นความเห็นที่ดีมากเลย!
 
GN⁺ 2025-10-12
ความคิดเห็นจาก Hacker News

  • คำว่า "Tutorial Hell" นี่โดนใจมาก ดูคอร์ส 6 ชั่วโมงแล้วนั่งเขียนตามได้ แต่พอให้สร้างอะไรสักอย่างขึ้นมาตั้งแต่ศูนย์กลับตันไปหมด นี่แหละ Tutorial Hell แบบคลาสสิก เพราะงั้นในทางประวัติศาสตร์ การฝึกงานแบบช่างฝีมือ (apprenticeship) ถึงเป็นวิธีเรียนรู้ที่มีประสิทธิภาพที่สุด จูเนียร์เดินตามซีเนียร์ และมีช่างเอกคอยดึงภาพรวมจากด้านบน เป็นโครงสร้างที่ช่างฝีมือทำทั้งการบริหารโปรเจกต์และการสอนควบคู่กันไป น่าเสียดายที่วงการนักพัฒนาเราไม่ได้ดำเนินกันแบบกิลด์มานานแล้ว คิดว่าตั้งแต่ปลายทศวรรษ 1980 เราไม่ควรเลิกโมเดลนั้นด้วยซ้ำ ถ้ามีกิลด์อยู่ จำนวนนักพัฒนาอาจน้อยกว่านี้มาก และทิศทางการพัฒนาอุตสาหกรรมก็คงต่างออกไป

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

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

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

    • ฉันลาออกจากโรงเรียนเร็วมาก (เพราะความน่าเบื่อและวิธีสอนที่ล้าสมัย) แล้วกระโดดเข้าสู่หน้างานในฐานะลูกมือวิศวกรซอฟต์แวร์ ซึ่งหลักสูตรในโรงเรียนแทบไม่มีประโยชน์เลย ช่วงปลายยุค 90 คือการลองผิดลองถูกต่อเนื่อง ทั้งฉัน อาจารย์ของฉัน และอาจารย์ของเขา ต่างก็เรียนรู้จากการลงมือชนเอง เราเอา Linux มาทำ ISDN router ตั้งค่าเว็บเซิร์ฟเวอร์ ใช้ HTML, Perl, PHP และได้สัมผัส DevOps กับวิศวกรรมจริง ๆ (แม้ตอนนั้นยังไม่มีคำเรียกแบบนี้) เป็นยุคที่แทบไม่มีเอกสาร ต้องอาศัยความคิดสร้างสรรค์และจิตวิญญาณแห่งการลองของเพื่อขยายขอบเขตตัวเอง มันมีบางอย่างที่คล้ายกับ vibe coding ในยุค AI ตอนนี้ แม้แรงกดดันจะสูงกว่ามาก แต่ก็เป็นความทรงจำที่สนุกจริง ๆ

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

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

    • ฉันก็รู้สึกแบบนี้เหมือนกัน เคยอยากได้สภาพแวดล้อมคอมพิวติ้งแบบในหนัง SF ที่พูดว่า "ส่งพลังงานมาด้านหน้า!" แล้วชิ้นส่วนหรือระบบต่าง ๆ ก็เข้ากันและนำกลับมาใช้ใหม่ได้อย่างง่ายดาย แต่ความจริงคือแค่จะเอากล้องจากมือถือ Android ไปใส่ iPhone ก็แทบเป็นภารกิจที่เป็นไปไม่ได้แล้ว

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

    • ปัญหาใหญ่คือการเขียนเอกสารให้ดี การค้นหา และการอ่าน ล้วนทำได้ยากมาก นั่นเลยทำให้การเรียนรู้ลำบาก แต่ AI ก็ช่วยให้เรียนรู้ง่ายขึ้น อย่างเช่น Unreal Engine ที่ AI เข้าใจได้ดีอย่างน่าทึ่ง

    • ปัญหาหลายอย่างที่เราต้องแบกรับคือความซับซ้อนโดยบังเอิญตามที่ Brooks พูดไว้ใน 'No Silver Bullet' และ LLM ก็กำลังช่วยเจาะผ่านความซับซ้อนนี้ รวมถึงทำลายไซโลความรู้ที่ก่อตัวขึ้นตามภาษาและเฟรมเวิร์กต่าง ๆ

    • ถ้าอุตสาหกรรมที่ขับเคลื่อนด้วยการเก็งกำไรแบบตอนนี้ดำเนินต่อไปอีกนิดเดียว เราอาจไปถึงโลกที่การเขียนโปรแกรมหายไปเองเลยก็ได้

  • เดี๋ยวนี้ทุกคนเขียนโค้ดได้ เลยทำให้ในระดับองค์กร ปริมาณโค้ดเพิ่มขึ้นประมาณ 10 เท่า แต่จำนวน reviewer เท่าเดิมจนรับไม่ไหว ถ้ายังใช้ LLM มาช่วย sanity check โค้ดไม่ได้ แล้วจะทำยังไงได้บ้าง เมื่อวานนี้เองมีคนที่ไม่ใช่ผู้เชี่ยวชาญสร้างอัลกอริทึม optimization ด้วย Codex แล้วมาขอให้ฉันช่วยปรับปรุง ปัญหาคือโค้ดนั้นเละเทะมาก (ไล่ brute-force กับชุดจำนวนเต็มหลายพันค่า แถมยังรักษา constraints ได้ไม่ดี ผลลัพธ์จึงไม่น่าเชื่อถือ) สุดท้ายฉันต้องเสียเวลาทั้งวันตรวจโค้ด แล้วไปพรีเซนต์ต่อผู้บริหารว่าสิ่งนี้โดยเนื้อแท้แล้วไม่มีประโยชน์

    • คำตอบของ "LLM code sanity check" คือ unit test LLM สร้างทั้งโค้ดทดสอบและโค้ดที่ทดสอบได้เก่งมากด้วย (ถ้าขอให้ทำ) ถ้าชุดทดสอบเรียกใช้โค้ดจริงและตรวจ edge case ได้ดี มันเร็วกว่าการรีวิวโค้ดมาก และยังรวม performance test ได้ด้วย ต่อไปเราน่าจะทำงานโดยยึด definitions กับ tests เป็นหลัก และความสำคัญของวิธี implement ภายในฟังก์ชันจะลดลงเรื่อย ๆ นี่คือการเปลี่ยนมุมมองครั้งใหญ่

    • ดูกรณี Excel programming ก็พอ ตอนแรกทุกคนเมินมัน พอระเบิดขึ้นมาก็ค่อยยอมจ่ายเงินก้อนโตเพื่อเก็บกวาดก่อนที่บริษัทจะพัง

    • เรื่องที่ว่า 'จำนวน reviewer เท่าเดิม' นั้น LLM ก็ช่วยรีวิวโค้ดได้ GPT-5 เองก็เก่งเรื่องจับข้อผิดพลาดเฉพาะจุดอย่าง off-by-one หรือ return ที่หายไป แต่กับปัญหาที่ต้องเข้าใจโครงสร้างภาพรวมในระดับสูงกว่านี้ก็ยังมีข้อจำกัด อนาคตอาจมีการนำ LLM ไป fine-tune กับโค้ดเบสขนาดใหญ่เป็นประจำ แล้วใช้เป็น reviewer ชั้นแรกสำหรับทุกการเปลี่ยนแปลงก็ได้

    • ปัญหา OR (combinatorial optimization) มักเกิดจากคนที่เขียนแบบสด ๆ ไม่รู้ว่าตัวเองกำลังตกเข้าไปในโลกของอัลกอริทึมเฉพาะทางโดยเนื้อแท้ แม้จะมีคนชี้ให้เห็น หลายคนก็ยังไม่เข้าใจทฤษฎีคณิตศาสตร์พอ และพยายามทำแบบของตัวเองต่อไป

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

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

    • จากประสบการณ์ของฉัน ต่อให้ขอคำวิจารณ์แรง ๆ (scathing critique) AI ก็ยังมีท่าทีอยากทำให้ฉันรู้สึกดีอยู่ดี ไม่ว่าจะ GPT รุ่นเก่าหรือรุ่นใหม่ก็คล้ายกัน มันให้ความรู้สึกแปลก ๆ สุดท้ายแล้วเครื่องมือนี้จะเป็นประโยชน์สูงสุดกับคนที่อยากใช้มันให้เกิดประโยชน์ และตระหนักถึงปัญหาเฉพาะของ LLM เท่านั้น

    • เพื่อกันปัญหาความประจบสอพลอ ฉันจะใส่อคติฝั่งตรงข้ามแล้วถามสองรอบเสมอ แต่ก็ไม่รู้ว่า AI กำลังไปเสริมอคติแฝงที่ฉันมีอยู่หรือเปล่า

  • ฉันไม่ใช่มือใหม่ แต่ยังต้องเรียนรู้เฟรมเวิร์ก ภาษา และอัลกอริทึมใหม่อยู่เรื่อย ๆ เลยไม่คิดว่า AI autocomplete เป็นเรื่องแย่ IntelliSense หรือ ReSharper autocomplete ในอดีตก็ช่วยได้มากเวลาเรียนรู้ไลบรารีใหม่หรือฟีเจอร์ใหม่ของภาษา ReSharper ถึงกับแนะนำฟีเจอร์ใหม่ให้ตอนฉันเขียนแบบเก่า ๆ ซึ่งทำให้ฉันได้เรียนรู้อะไรใหม่เยอะ AI-based autocomplete ให้ความรู้สึกพัฒนาไปกว่านั้นมาก มันเสนอสิ่งต่าง ๆ ได้อย่างเป็นธรรมชาติ จะใช้หรือไม่ใช้ก็ได้ เลยช่วยเรื่องการเรียนรู้ด้วย สุดท้ายถ้ามีความอยากรู้อยากเห็นพอที่จะอ่านและทำความเข้าใจข้อเสนอเหล่านั้น AI ก็ทำให้การเรียนรู้ง่ายขึ้นมาก เมื่อก่อนก็แค่คัดลอกจาก Stack Overflow

    • autocomplete แบบดั้งเดิมจะแสดงเมธอด ตัวแปร ค่าคงที่ต่าง ๆ ในสโคปนั้นทั้งหมด และเชื่อมไปยังเอกสารด้วย ฉันจึงตัดสินเองได้ว่ามีตัวเลือกอะไรบ้าง ซึ่งดีต่อการเรียนรู้จริง ๆ ส่วน AI autocomplete นั้นแทบเหมือนเอาคำตอบจาก Stack Overflow มาแปะโดยไม่มีบริบท ถ้าอยู่ในฐานะคนเรียน การไปค้น Stack Overflow เอง หรือถ้าจำเป็นก็ค่อย prompt แชตบอตให้ช่วยอธิบายว่าเหตุใดโค้ดจึงเป็นแบบนั้น น่าจะดีกว่า

    • ฉันคิดว่ามีความต่างอยู่บ้าง ถ้ามีประสบการณ์ระดับหนึ่งแล้ว การใช้ autocomplete กับภาษาใหม่ก็เป็นเรื่องธรรมชาติ แต่สำหรับมือใหม่ที่ยังไม่มีพื้นฐานแล้วเริ่มเรียนตั้งแต่ for loop แรก มันเป็นอีกเรื่องหนึ่ง

    • ฉันชอบ AI Agentic programming การสร้างของทำให้มีความสุข และเป็นส่วนหนึ่งของการทดลองไอเดีย ฉันไม่ได้ deploy โค้ดเข้าสู่ production เลยไม่สนสายตาคนอื่น ถ้าอยากคุยกับเพื่อนร่วมวงการที่เก่งเทคนิคจริง ๆ ก็ต้องลองทำเองและเรียนรู้ด้วยตัวเอง ฉันชอบเขียนโปรแกรมมาตั้งแต่อายุ 10 ขวบ แต่ไม่ใช่นักพัฒนาอาชีพ พอเข้าสู่ยุค AI ความรักในการเขียนโค้ดและการทดลองก็กลับมาอีกครั้ง ไม่ว่าจะเป็นเทคโนโลยีเว็บอนาคตอย่าง WASM หรือระบบต่าง ๆ การหา bug หรือการลองทำอะไรในแบบของตัวเอง มันสนุกมาก เครื่องมืออย่าง Cursor AI ยังช่วยตั้งค่า git ของฉันให้อัตโนมัติ และ push ผ่าน ssh ได้ง่ายด้วย แน่นอนว่าฉันทำเองได้ แต่เลือกปล่อยให้ AI ทำ สมัยเด็กฉันเริ่มจากไวยากรณ์ C จนกลายเป็นนิสัยติดตัว แต่ตอนนี้ก็สนุกกับ python backend, flask web server, และ JavaScript frontend มาก WASM Python ยังขาดอีกเยอะ แต่ฉันก็ยังทดลองอยู่เรื่อย ๆ ฉันชอบสร้างพื้นฐานให้แน่นและเรียนในแบบของตัวเอง และก็มักรู้สึกว่าวิศวกรมักทำให้สิ่งต่าง ๆ ซับซ้อนเกินจำเป็น

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

  • ฉันไม่ใช่มือใหม่ แต่ Copilot ช่วยให้การเรียน Rust ง่ายขึ้นอย่างชัดเจน พอใช้คู่กับ Intellisense ก็ลดภาระเรื่องไวยากรณ์ ทำให้ไปโฟกัสกับส่วนสำคัญของภาษาได้ ฉันสามารถเริ่มจากเปิดหนังสือ Rust แล้วทำเครื่องมือที่รันได้จริงภายในหนึ่งสัปดาห์ แน่นอนว่านี่ไม่ได้ทำให้กลายเป็นวิศวกรซีเนียร์ แต่ช่วยลดอุปสรรคจาก '0 ไป 1' ได้แน่ ๆ ฉันไม่ได้สั่งให้ Copilot เขียนโค้ด แต่ใช้มันเหมือน autocomplete ที่ฉลาดขึ้น รับข้อเสนอมาแล้วตัดสินใจเองว่าจะยอมรับหรือไม่

    • ประเด็นที่วนกลับมาซ้ำ ๆ ตรงนี้คือ ซีเนียร์ที่มีประสบการณ์สูงแม้ไม่รู้ภาษาใหม่ ก็ยังดึงคุณค่าจากเครื่องมือพวกนี้ได้ เพราะเขารู้ 'วิธีเขียนโค้ด' อยู่แล้ว ต่อให้ภาษาเปลี่ยน code smell ก็ยังเหมือนเดิม แต่มือใหม่จำนวนมากยังไม่เข้าใจแม้แต่แนวคิดเรื่อง 'code smell'

    • ฉันเองก็เคยคิดว่า Copilot ช่วยเรื่องการเรียน Rust ได้มาก แต่พอลองเขียนเองโดยไม่มี AI มันกลับยากมาก ต้องปิด AI แล้วเรียนจริง ๆ ถึงจะหลุดจากภาพลวงตาว่าตัวเองเข้าใจแล้ว

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

  • ถ้า AI ไม่ได้มาแทนงาน white-collar ทั้งหมดภายในไม่กี่ปีจริง ๆ ฉันคิดว่าเราคงต้องเจอไม่ใช่แค่ฟองสบู่ตลาดหุ้น แต่รวมถึงภาวะขาดแคลนแรงงานที่มีการศึกษาด้วย สำหรับฉัน มันให้ความรู้สึกช็อกประมาณว่า 'ฉันกำลังมองดูคนเก่งที่สุดของรุ่นตัวเองกระจัดกระจายหายไป'

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

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