AI: ความไร้ความสามารถที่ถูกเร่งให้เร็วขึ้น

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

---

บทนำ

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

มุมมองแบบ "LLM คือเพื่อนของฉัน"

วิศวกรที่มองว่า LLM เป็นเครื่องมือชั้นยอดมักให้ ความเร็ว เป็นคุณค่าสูงสุด
แม้ LLM จะสร้างโค้ดจำนวนมากได้อย่างรวดเร็ว แต่สิ่งนี้แฝงไว้ด้วย ความเสี่ยงระยะยาว

ความเสี่ยงของการใช้ LLM

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

ความกังวลว่า "จะตกงานเพราะ AI หรือไม่?"

ความเป็นไปได้นั้นต่ำมาก
มี ความสามารถด้านการพัฒนา อยู่สองอย่างที่ LLM ไม่อาจแทนที่ได้: ทฤษฎีของโปรแกรม และ เอนโทรปีของโปรแกรม

ทฤษฎีของโปรแกรม

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

LLM กับทฤษฎีของโปรแกรม

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

เอนโทรปีของโปรแกรม

• Fred Brooks เรียก ความซับซ้อน (เอนโทรปี) ว่าเป็นโจทย์ยากโดยพื้นฐานของการเขียนโปรแกรม
  • การบำรุงรักษาโปรแกรมทำให้ความซับซ้อนเพิ่มขึ้น และแม้จะดำเนินการได้ดีที่สุดก็ยังพาระบบไปสู่ความเสื่อมสภาพที่ย้อนกลับไม่ได้

LLM กับเอนโทรปีของโปรแกรม

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

บทสรุป

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

เกริ่นถึงบทความถัดไป

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

เอกสารอ้างอิง

• Leading Question: https://en.wikipedia.org/wiki/Leading_question
• The XY Problem: https://en.wikipedia.org/wiki/XY_problem
• ThoughtWorks Technology Radar Volume 32: https://thoughtworks.com/content/dam/…
• Coding as Craft: Going Back to the Old Gym: https://cekrem.github.io/posts/…
• Thoughts on Thinking: https://dcurt.is/thinking
• The Hidden Cost of AI Coding: https://terriblesoftware.org/2025/04/23/the-hidden-cost-of-ai-coding/
• "I wonder if I'll become redundant": https://reddit.com/r/ExperiencedDevs/…
• Programming as Theory Building: https://pablo.rauzy.name/dev/naur1985programming.pdf
• Grug on Complexity: https://grugbrain.dev/#grug-on-complexity
• Gartner Hype Cycle: https://en.wikipedia.org/wiki/Gartner_hype_cycle

[GN⁺]

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

• มีการแชร์ประสบการณ์ว่าบางครั้งการถกเถียงเรื่อง AI สำหรับเขียนโค้ดสะท้อนความต่างระหว่างวิศวกรซอฟต์แวร์กับนักวิทยาศาสตร์ข้อมูล/วิศวกรแมชชีนเลิร์นนิง
  วิศวกรซอฟต์แวร์มักถูกคาดหวังให้สร้างซอฟต์แวร์ที่คาดเดาได้เสมอและผ่านการทดสอบ โดยเครื่องมือก็พัฒนาไปไกลกว่ามาก
  ในทางกลับกัน สำหรับวิศวกรแมชชีนเลิร์นนิง การทำงานกับโมเดลเชิงความน่าจะเป็นเป็นเรื่องปกติในชีวิตประจำวัน และการทดสอบก็มักเน้นการประเมินด้วยตัวชี้วัดมากกว่าผลลัพธ์เฉพาะ
  จึงคุ้นเคยกับความจริงที่ว่า AI ไม่น่าเชื่อถือได้เสมอไปมากกว่า
  แม้แต่ coding assistant ก็ถูกใช้งานด้วยแนวคิดว่า ต่อให้ตอบถูกแค่ 80% อีก 20% ที่เหลือฉันก็จับผิดเองได้
• จากประสบการณ์ของฉันเอง ก็รู้สึกคล้ายกันอยู่ประมาณครึ่งหนึ่ง
  ตอนทำงานที่ Amazon โซลูชันที่ใช้ ML มีประโยชน์มากกับปัญหาที่ไม่มีวิธีแบบดั้งเดิมรองรับ
  แต่ที่สตาร์ทอัพแห่งหนึ่ง มีการดื้อดึงใช้แนวทางแบบเรียนรู้เพียงอย่างเดียวโดยไม่เข้าใจแม้แต่การกรองหรือการแมปพื้นฐาน จนได้ผลลัพธ์น่าขันซ้ำแล้วซ้ำเล่าในการประมาณท่าทางของเครื่องบินที่หยุดนิ่ง
  ช่องว่างระหว่าง ML กับวิศวกรรมซอฟต์แวร์นี้ชัดเจนมาก และหวังว่าจะมีวิธีทำให้มันปรากฏชัดขึ้นในกระบวนการจ้างงาน
• บรรยากาศตอนนี้ให้ความรู้สึกว่าแนวคิดแบบ MLE ถูกยัดเยียดไปใช้กับกลุ่มอื่นด้วย
  ในบริษัทที่ขายผลิตภัณฑ์ซึ่งความแม่นยำและความถูกต้องเป็นหัวใจหลัก ทีมฝั่ง ML กลับยืนยันว่า 80~90% ก็เพียงพอแล้ว และได้เห็นสถาปนิกระบบไม่พอใจกับเรื่องนี้
  ทำให้นึกถึงตัวอย่างการถกเถียงเรื่องอัตราเสียชีวิต 1% ในช่วงโรคระบาด ว่าแม้เป็นเปอร์เซ็นต์เล็กน้อยก็ส่งผลกระทบใหญ่ได้
• มีการกล่าวถึงความต่างระหว่างพฤติกรรมแบบกำหนดแน่นอน (Deterministic) กับแบบเชิงความน่าจะเป็น (Probabilistic)
  บทความนี้โฟกัสกับโจทย์ระดับเมตาของ AI และวิศวกรรมซอฟต์แวร์ นั่นคือการจัดการเอนโทรปี (Entropy) ของโปรแกรม
  การจัดการเอนโทรปีเป็นส่วนใหญ่มากของการสร้างผลิตภัณฑ์ซอฟต์แวร์ และแม้วันหนึ่ง AI อาจทำส่วนนี้ได้ง่าย แต่ตอนนี้กลับมักทำให้เอนโทรปีแย่ลงกว่าเดิม
• ขณะนี้กำลังเรียนปริญญาโทด้าน AI (โดยเฉพาะ ML) และในฐานะ SWE ก็กำลังฝึกกล้ามเนื้อใหม่
  มอง MLE จากมุมมองที่กว้างกว่าของ SWE และจำเป็นต้องเข้าใจภาพรวมทั้งหมด ทั้งการสร้าง pipeline ที่ทนทาน การผสานโมเดล และการ deploy
  แต่ผู้ที่เรียนสาย MLE โดยตรงจำนวนมากขาดมุมมองแบบ SWE และมักเข้าใจแค่ ML โดยไม่มีเซนส์แบบคอมพิวเตอร์
  หากอยากเป็น full-stack ของจริง จำเป็นต้องเข้าใจทั้งระบบระดับล่าง สถาปัตยกรรม การ deploy รวมถึง MLE
  แต่ตลาดงานส่วนใหญ่กลับมองหาแค่ SWE หรือไม่ก็ MLE ระดับปริญญาเอก จนอยากบอกให้เสนอค่าตอบแทนที่เหมาะกับคนอย่างฉันที่รู้ทั้งหมดนี้
• วิศวกรซอฟต์แวร์เองก็ใช้การคิดเชิงความน่าจะเป็นอยู่มากในความเป็นจริง
  เช่น การออกแบบ race condition ใหม่ การคาดการณ์ p99 ของการเรียก DB หรือการทำ A/B test
• โดยรวมเห็นด้วยกับข้อเสนอของบทความ แต่ก็พบการเปลี่ยนแปลงด้านบวกจากการใช้ LLM ด้วย
  ในฐานะนักพัฒนาอาวุโสที่มีประสบการณ์ 30 ปี การต้องอ่านโค้ดที่ AI สร้างขึ้นหมายความว่ากระบวนการพัฒนากำลังเปลี่ยนไปสู่ workflow ที่เน้น code review
  สิ่งนี้ช่วยให้แม้แต่นักพัฒนารายบุคคลก็ได้ฝึกความรับผิดชอบแบบทีมและทักษะการอ่านโค้ด
  อีกทั้งหากจะใช้ LLM ให้ดี ก็จำเป็นต้องเข้าใจโครงสร้างแบบลำดับชั้นของปัญหา
  การออกแบบอย่างละเอียดเป็นส่วน ๆ แล้วค่อยลงมือทำ ยังช่วยให้กำหนด interface และขอบเขตได้เป็นธรรมชาติ
  LLM เป็นตัวเร่งที่ช่วยให้จูเนียร์เติบโตเป็นซีเนียร์เร็วขึ้น และช่วยให้สัมผัสการเรียนรู้แบบนักพัฒนาที่มีประสบการณ์สูง
  AI จะไม่มาแทนที่นักพัฒนา และท้ายที่สุดจะค่อย ๆ กลืนเข้าไปเป็นเครื่องมือ
  • ฉันคิดมาตลอดว่าปริมาณโค้ดที่อ่านควรมากกว่าโค้ดที่เขียน
    โค้ดที่ LLM สร้างอาจซ้ำ ๆ เรียบ ๆ แต่ก็ยังเป็นโอกาสเรียนรู้
    ฉันได้รู้จัก idiom ใหม่ ๆ หรือการเรียกใช้ไลบรารีจากโค้ดที่ LLM สร้างอยู่บ่อยมาก
    ยิ่งเป็นซีเนียร์ก็ยิ่งให้พรอมป์ต์ได้ดีกว่า ทำให้ LLM เป็นตัวเร่งที่ทรงพลังขึ้นอีก
  • AI เหมาะมากสำหรับใช้แบบคัดลอกวางเพื่อทำต้นแบบระดับ prototype ก่อน แต่ใช้แทนการตรวจทานและ commit ไม่ได้
  • ในมุมบริษัท AI ไม่ได้มาเพื่อช่วยจูเนียร์ แต่เป็นข้ออ้างในการไม่รับจูเนียร์และเรียกร้องให้ซีเนียร์ทำงานได้มากขึ้น 10 เท่าด้วย AI
    ไม่ว่าจะ Big Tech, Mid Tech หรือ Small Tech ก็ยังปลดคนต่อเนื่อง
• มีการเปรียบเทียบข้อถกเถียงเรื่อง AI กับความคิดเก่าว่า 3D printing จะมาแทนการผลิตทั้งหมดหรือไม่
  โดยมองว่า AI ใกล้เคียงกับการเปลี่ยนแปลงจริงแบบนั้นมากกว่าการไปสู่ singularity
  • 3D printing เป็นเทคโนโลยีที่เจ๋งและพลิกโฉมมากจริง แต่ injection molding ก็ยังคงอยู่
  • 3D printing ไม่ได้นำไปสู่ singularity แต่ AI ได้สร้างผลกระทบใหญ่ในพื้นที่แรงงานความรู้ เช่น มหาวิทยาลัย ไปแล้ว
    มีการแชร์ความจริงว่ารูปแบบการสอน งานมอบหมาย และชั้นเรียนที่เคยเป็นเรื่องปกติมาแต่เดิม กำลังเปลี่ยนอย่างรวดเร็วทั่วโลกเพราะการมาถึงของ LLM
  • 3D printing เป็นตัวอย่างที่นำมาซึ่งการเปลี่ยนแปลงและนวัตกรรมมหาศาลในหลายอุตสาหกรรม เช่น การบินและอวกาศ
    ถ้าไม่มี SpaceX ก็มีหลายด้านที่คงเป็นไปไม่ได้จริง
  • ยังคล้ายกับความคาดหวังว่า Bitcoin จะมาแทนธนาคาร
    สุดท้ายกลับกลายเป็นว่าธนาคารออกมาขายผลิตภัณฑ์การเงินที่อิง Bitcoin เอง
  • 3D printing กับ AI มีเส้นโค้งการเติบโตที่ต่างกันโดยสิ้นเชิง
    3D printing ไม่ได้ถูกมองว่าเป็นตัวแทนการผลิตเดิม และยังคงจำกัดอยู่กับงาน prototype/mockup/PoC เป็นหลัก
• LLM เก่งมากในการเขียนโค้ด แต่ไม่อาจเป็นผู้รับผิดชอบได้
  โค้ดที่รับมาใช้โดยไม่เข้าใจจะทำให้ต้องจ่ายราคาแพงมากในการบำรุงรักษาภายหลังในรูปของ technical debt
  คล้ายภาพลวงตาของความเร็วฟรี ทั้งที่จริงแล้วเหมือนกำลังก่อ technical debt ด้วยอัตราดอกเบี้ยต่อปีระดับ 40%
  ให้ AI ทำงานด้านการพิมพ์อัตโนมัติได้ แต่การคิดยังต้องเป็นหน้าที่มนุษย์
  • เพราะ LLM ไม่ได้ "เข้าใจ" จริง การจะเกิด comprehension ที่แท้จริงได้ก็ต่อเมื่อมนุษย์เข้าใจบริบทของ codebase และระบบเอง
  • มีข้อเสนอให้ลดอัตราดอกเบี้ยของ technical debt ด้วยการทดสอบและการจัดโครงสร้างเป็น subsystem ที่แยกขาดจากกัน (tdd, microservices เป็นต้น)
    บางคนมองว่า tdd และ microservices ซึ่งอาจไม่จำเป็นในยุคพัฒนาแบบเดิม กลับมีคุณค่ามากขึ้นในยุค LLM
  • ทั้งนี้ขึ้นอยู่กับงานด้วย เพราะสำหรับบางงาน AI เขียนโค้ดได้แย่มากเช่นกัน
• มีการแชร์ว่าความเสี่ยงของอินพุต (Input Risk) คือจุดเจ็บปวดที่ใหญ่ที่สุด
  แค่ความกำกวมเล็กน้อยในพรอมป์ต์ก็อาจทำให้ผลลัพธ์หลุดไปคนละทางโดยสิ้นเชิง และเมื่อรู้ตัวแล้วก็มักแก้ทีหลังได้ยาก
  เพราะความกำกวมของภาษามนุษย์ สุดท้ายจึงเกิดภาษารูปแบบที่ชัดเจนขึ้นมา
  โดยส่วนตัวรู้สึกว่าการใช้เครื่องมือ AI ทำให้ทักษะของตัวเองถดถอยลงอย่างรวดเร็ว และกลับใช้เวลาและพลังงานมากกว่าเดิมเสียอีก
  AI มีประโยชน์ก็จริง แต่ดูเหมือนโลกจะแบ่งเป็นฝ่ายที่เห็นว่าปัญหาซับซ้อนจะพังได้จากความผิดพลาดเล็ก ๆ ที่สะสม กับอีกฝ่ายที่ดูแค่ผลลัพธ์แล้วอ้างว่า "แทนบทบาทได้แล้ว" ซึ่งมักเป็นผู้จัดการหรือคนที่ไม่ใช่สายเทคนิค
  [ประสบการณ์โดยละเอียด: ความเห็นก่อนหน้า]
  • มีคำแนะนำให้ใช้ AI เป็นผู้ช่วยของตัวเอง ในโครงสร้างที่ตัวเรายังต้องรับผิดชอบเรื่องคุณภาพและการบำรุงรักษาโดยตรง
    เหมือนที่เครื่องคิดเลขทำให้คนคำนวณในใจเก่งน้อยลง AI ก็อาจทำให้ทักษะการเขียน การสื่อสาร และการแก้ปัญหาถดถอยลงได้
  • มีการแชร์ประสบการณ์ว่าการป้อนคำที่กำกวมทำให้ LLM ให้ผลลัพธ์ที่ไร้ตรรกะ
    จึงใช้ LLM แค่กับงานเล็ก ชัดเจน หรือปัญหาที่ปกติจะไปหาใน StackOverflow
    และใช้คำตอบเป็นเพียงแนวทาง ไม่ใช่ความจริงสัมบูรณ์
  • AI อาจช่วยแก้บางปัญหาได้เร็วขึ้น แต่ก็แก้ปัญหาที่ถูกทำให้ซับซ้อนเกินจำเป็นไม่ได้
    ความสามารถของมนุษย์ในการเข้าใจแบบแปลนทั้งระบบคือหัวใจของการต้านเอนโทรปี
  • วิธีที่ใช้บ่อยของตัวเองคือสั่ง LLM ก่อนว่า "ช่วยถามคำถามที่ชัดเจน 5 ข้อ เป็นเวลา 3 รอบ"
    แบบนี้จะช่วยขัดเกลาหัวข้อและบริบทให้ชัดขึ้นได้
    หวังว่าเคล็ดลับนี้จะเป็นประโยชน์กับคนอื่นด้วย
  • มีลางสังหรณ์ว่าหลังยุคแห่ง hype นี้ไป ความสำคัญของการควบคุมคุณภาพจะถูกค้นพบอีกครั้ง
    ตัวอย่างเช่นสงคราม Coke vs Pepsi อันยาวนาน
• มีความเห็นว่าไม่ค่อยเห็นด้วยกับคำกล่าวที่ว่า LLM ไม่ทำงานกับไอเดีย ไดอะแกรม และสเปกในระดับแนวคิด
  หากถาม LLM ด้วยเจตนาเชิงออกแบบ เช่น ขอ "โค้ดเวอร์ชันที่ง่ายขึ้น" ก็สามารถได้ second opinion ที่ดีพอสมควร
  ถ้าไม่ถามก็ย่อมไม่ได้คำตอบตั้งแต่แรก และค่า default เองก็เป็นสิ่งที่เราเลือก ดังนั้นจึงมองว่าเป็นข้ออ้างที่ไม่เกี่ยวกับแก่นแท้ของเทคโนโลยีเบื้องหลัง
  • มีกรณีที่แสดงเชิงประจักษ์แล้วหลายแบบว่า LLM ทำงานเชิงแนวคิดได้จริง
    ในโลกจริงไม่มีใครเข้าใจโปรแกรมขนาดมหึมาทั้งหมดได้ในหัวอยู่แล้ว เครื่องมือและภาษาจึงพัฒนามาบนฐานของความเข้าใจเพียงบางส่วนเป็นส่วนใหญ่
    LLM ก็มีข้อจำกัดแบบเดียวกัน ดังนั้นในกรอบนี้มนุษย์กับ LLM จึงมีข้อจำกัดคล้ายกัน
  • เวลารีวิวโค้ดของจูเนียร์ รู้สึกว่าปัญหามักอยู่ที่ทิศทางมากกว่าคุณภาพของโค้ดเอง
    น่าเสียดายที่ LLM ยังยากจะมีความสามารถถามกลับว่า "ทำไมถึงทำแบบนั้น" ต่อทิศทางนั้น
  • มีการถามว่ามีใครใช้เครื่องมือแปลงโค้ดเป็นไดอะแกรมแบบอัตโนมัติหรือไม่ หรือสร้างกันเอง
• มีการพูดถึงความคล้ายกับข้อกล่าวที่ว่าซอฟต์แวร์แผนที่อย่าง Google/Apple Maps ทำให้ทักษะการหาทางของคนเสื่อมลง
  แม้จะมีส่วนจริงอยู่ แต่คนส่วนใหญ่เดิมทีก็ไม่ได้หาทางเก่งอยู่แล้ว และกลับคิดว่าเทคโนโลยีแผนที่ช่วยให้ความสามารถในการเดินทางจาก A→B โดยเฉลี่ยดีขึ้น
  สำหรับคนกลุ่มน้อยที่ชำนาญอยู่แล้ว เทคโนโลยีก็ทำหน้าที่ช่วยเสริมมากกว่าจะมาแทน
  AI เองก็น่าจะนำการเปลี่ยนแปลงคล้ายกันในสเกลที่ใหญ่กว่า และแม้จะมีจุดที่ความสามารถถดถอยหรือสูญเสียไป แต่ก็มีสิ่งที่ได้กลับมาเช่นกัน
  • แผนที่เทียบกับ LLM ไม่ได้ในแง่ความน่าเชื่อถือ
    แผนที่แทบจะให้ค่าที่คาดหวังเกือบตลอด แต่ LLM แม้ใช้พรอมป์ต์เดียวกันผลก็ยังเปลี่ยนได้ จึงยากจะเชื่อถือ
    เหมือนที่มีคนขับรถตกทะเลสาบเพราะเชื่อแผนที่มากเกินไป การเชื่อ LLM แบบไม่คิดก็อาจก่อปัญหาที่ใหญ่กว่าได้
  • ส่วนตัวกลับรู้สึกว่าการใช้ซอฟต์แวร์แผนที่ช่วยเรื่องความจำเชิงพื้นที่
    เพราะสามารถหลงทางได้เต็มที่ แล้วค่อยหาทางกลับเมื่อจำเป็น ทำให้ประสบการณ์ยิ่งถูกขยายออกไป
  • Google Maps แม่นยำกว่าคนขับแท็กซี่มากกว่า 90%
    แต่ AI ในบางกรณีกลับยังแย่กว่าคนทั่วไปที่เพิ่งลองทำเรื่องนั้นแค่ไม่กี่วัน
  • มีการตั้งคำถามว่าข้ออ้างเรื่อง "ยกระดับฝีมือเฉลี่ย" นั้นมีหลักฐานรองรับหรือไม่
• มีความเห็นว่าไม่เห็นด้วยกับคำกล่าวของผู้เขียนที่ว่า "[AI] ทำงานในระดับแนวคิดไม่ได้"
  LLM รุ่นหลัง ๆ สามารถทำงานในระดับแนวคิดได้อย่างชัดเจนแล้ว (เช่น การแปลหรือประยุกต์แนวคิด)
  และยังอ้างว่าสามารถเข้าใจแนวคิดที่มนุษย์เองไม่เคยมีประสบการณ์ตรงมาก่อนได้ด้วย
  • LLM สร้างแบบจำลองแนวคิดผ่านคลัสเตอร์ของโทเค็น
    เช่น บริเวณใกล้คำว่า dog จะมีคำที่เกี่ยวข้องรวมตัวอยู่
    แต่ยังไม่สามารถจำลองการประกอบกัน เจตนา หรือเหตุผลเชิงสถานการณ์สมมุติที่ขัดกับข้อเท็จจริงได้
    มันจึงเก่งกับคำถามที่คล้ายกับข้อมูลฝึก
    และมีประโยชน์ในโดเมนที่การทำให้เป็นแนวคิดถูกนิยามไว้ชัดเจน เช่น วิศวกรรมซอฟต์แวร์
  • มีตัวอย่างเพิ่มเติมว่ามนุษย์เองก็เข้าใจแนวคิดที่ไม่เคยมีประสบการณ์ตรงได้เช่นกัน
• ในความเป็นจริง พนักงานราว 70% ทำงานแบบขอไปทีอยู่แล้ว และบางครั้ง AI ยังทำได้ดีกว่าเสียอีก
  สุดท้ายคนที่ไม่ตั้งใจทำงานก็ยังเหมือนเดิมแม้ใช้ AI ส่วนคนที่เรียนรู้อย่างจริงจังเท่านั้นที่จะเติบโตไปพร้อมกับ AI
  • มีการชี้ข้อจำกัดของ narrative แบบยึดตัวเองเป็นศูนย์กลางว่าตัวเองอยู่ใน 30% นั้น
  • คนที่พยายามใช้ AI เพื่อทำงานแบบขอไปที อาจยิ่งเพิ่มความเสี่ยงที่จะถูกไล่ออก
    เพราะถ้า AI ทำงานได้ดีกว่า ก็ยิ่งสร้างเหตุผลให้แทนที่เจ้าตัวได้
  • มีคนเห็นด้วยว่านี่เป็นข้อสังเกตที่สมจริงที่สุด โดยเฉพาะในบริบทองค์กรใหญ่
    แม้แต่ FSD (ระบบขับขี่อัตโนมัติเต็มรูปแบบ) ก็ยังดีกว่าคนขับธรรมดาที่ไม่ใช่มืออาชีพมาก
• มีการแชร์ว่าเมื่อไม่นานมานี้เริ่มรู้สึกว่าจำเป็นต้องปรับ 90s.dev ให้กลายเป็นคอมมูนิตี้ที่ไม่พึ่ง AI และเป็นพื้นที่ของงานฝีมือซอฟต์แวร์
  กำลังชั่งใจระหว่างรูปแบบ forum, mailing list และ multi-blog
  รายชื่อเมลชั่วคราว
  • มองว่าแทนที่จะเปิดให้ทุกคนสมัครได้ โครงสร้างแบบเชิญเข้าร่วมและมี trust tree ของผู้แนะนำ น่าจะเหมาะกับคอมมูนิตี้ที่ยั่งยืนมากกว่า
    เพราะมีตัวอย่างที่ประสบความสำเร็จมาแล้วในบางคอมมูนิตี้
  • การใช้ซอฟต์แวร์ฟอรั่มแบบคลาสสิกในดีไซน์อารมณ์ย้อนยุคก็เป็นไอเดียที่ดีเช่นกัน