โค้ดนั้นราคาถูก ตอนนี้ต้อง ‘แสดงคำพูด’

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

---

บทนำ: คำคมของ Linus Torvalds และการกลับด้านของมัน

"Talk is cheap. Show me the code"

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

25 ปีต่อมา: LLM พลิกทุกอย่าง

• ในปี 2025 Linus Torvalds ได้ merge โค้ดที่ AI สร้างเข้าไปในโปรเจ็กต์งานอดิเรกของตน พร้อมกล่าวว่า “มันดีกว่าสิ่งที่ผมเขียนด้วยมือตัวเองไหม? แน่นอน”
• จากมุมมองของผู้เขียนที่สร้างซอฟต์แวร์มาหลายทศวรรษ เขายืนยันว่าการพัฒนาซอฟต์แวร์ในแบบที่เรารู้จักนั้นได้จบลงแล้ว
• ในฐานะคนรุ่นที่ผ่านช่วงเปลี่ยนผ่านมามากมาย ตั้งแต่ dial-up สู่กิกะบิต จาก Basic สู่ Node.js และจาก SourceForge สู่ GitHub ผู้เขียนตระหนักชัดว่าการเปลี่ยนแปลงครั้งนี้ไม่ใช่กระแสชั่วคราว แต่เป็นการขาดตอนเชิงคุณภาพ

การพังทลายของเกณฑ์ประเมินคุณภาพโค้ด

• ในอดีต เวลาประเมินโปรเจ็กต์ FOSS นั้น อายุของโปรเจ็กต์ ความถี่ของ commit ความสม่ำเสมอของโครงสร้างโค้ด คุณภาพของ README และเอกสาร ล้วนเป็นเกณฑ์สำคัญ
• คอมเมนต์ที่กระชับและเอกสารที่จัดระเบียบดี ถูกมองเป็นสัญญาณของความรอบคอบของนักพัฒนาและความใส่ใจต่อผู้พัฒนาคนอื่น
• แต่เมื่อ LLM สามารถสร้างหน้าเอกสารที่สมบูรณ์ README ที่ละเอียดเกินจำเป็น UI ที่เรียบร้อย และแพตเทิร์นกับคอมเมนต์ที่เป็นระเบียบได้ในคราวเดียว สัญญาณเหล่านี้ก็ไม่ใช่เกณฑ์ที่ใช้ได้อีกต่อไป
• ผลคือยากที่จะตัดสินจากรูปลักษณ์ภายนอกเพียงอย่างเดียวว่ารีโพซิทอรีนั้นเป็นสิ่งที่คนไม่ใช่สายเทคนิคสร้างขึ้นด้วย vibe coding หรือเป็นผลงานที่นักพัฒนาชำนาญการออกแบบมา
• ยิ่งไปกว่านั้น หากมันดูสมบูรณ์แบบเกินไป ก็ยิ่งต้องสงสัยอย่างย้อนแย้งว่าอาจเป็นงานสร้างแบบ one-shot ที่ใช้แรงน้อย
• หากไม่มีการตรวจทานและวิเคราะห์อย่างละเอียดในระดับผู้เชี่ยวชาญ ก็ยิ่งยากขึ้นเรื่อย ๆ ที่จะแยก wheat ออกจาก slop
• ดังนั้น สิ่งที่สำคัญกว่าตัวโค้ดจึงกลายเป็นใครเป็นคนสร้าง ทำไปทำไม มีประวัติแบบไหน และมีธรรมาภิบาลกับแผนบำรุงรักษาหรือไม่ หรือก็คือแหล่งที่มา (provenance)

การเปลี่ยนแปลงของคุณค่าของความพยายาม

• ในอดีต นักพัฒนาที่มีทักษะต้องใช้เวลานานกับการจดจ่อและการปรับปรุงซ้ำ ๆ เพื่อสร้างโค้ดคุณภาพสูง 10,000 บรรทัดที่ให้ผลลัพธ์มีความหมาย
• จำนวนบรรทัดโค้ดไม่ใช่มาตรวัดคุณภาพในตัวมันเอง แต่โค้ด 10,000 บรรทัดที่ผ่านการขัดเกลาอย่างดี บ่งบอกว่าได้ทุ่มเวลา สมาธิ ความอดทน ความเชี่ยวชาญ และความสามารถในการจัดการโปรเจ็กต์ในระดับหนึ่งลงไป
• LLM สามารถสร้างผลลัพธ์เช่นนี้ได้ในเวลาเพียงไม่กี่วินาที และยังจัดการเวิร์กโฟลว์ทางเทคนิคได้ทั้งกระบวนการ ตั้งแต่การทดสอบ การตั้งค่าระบบ ไปจนถึงการ deploy
• เมื่อมีความเชี่ยวชาญและการตัดสินใจของมนุษย์เข้ามาร่วมด้วย ผลลัพธ์ก็สามารถไปถึงคุณภาพสูงที่พร้อมใช้งานจริงได้เพียงพอ
• ผู้เขียนเองก็ประสบกับเหตุการณ์ซ้ำ ๆ ที่ว่างานซึ่งเคยใช้เวลาหลายสัปดาห์หรือหลายเดือน เสร็จได้ภายในไม่กี่วัน หรือบางครั้งไม่กี่ชั่วโมง
• ทั้งหมดนี้เป็นไปได้ด้วยเพียง LLM agent CLI แบบเรียบง่าย โดยไม่ต้องมี AGENT.md หรือการ orchestration แบบ multi-agent ที่ซับซ้อน
• ต้นทุนทางสรีรวิทยา ทางปัญญา และทางอารมณ์ที่เคยต้องจ่ายเพื่อให้ได้ผลลัพธ์ซอฟต์แวร์ลดลงไปหลายลำดับขั้น
• เวลาและพื้นที่ทางความคิดที่ได้คืนมานี้ ถูกนำไปลงทุนใหม่กับการคิดเชิงวิศวกรรม การออกแบบสถาปัตยกรรม การถกเถียง การทดลอง และการขยายจินตนาการ
• คำกล่าวเก่าว่า “การเขียนโปรแกรมคือการคิด 90% และการพิมพ์ 10%” ไม่ใช่อุปมาอีกต่อไป แต่กลายเป็นความจริงแล้ว

นิยามของ Slop และคุณค่าของโค้ด

• เมื่อแม้แต่คนที่ไม่เคยเขียนโค้ดเลยสักบรรทัดก็ยังสามารถสร้างโค้ดในระดับอุตสาหกรรมได้ภายในไม่กี่วินาที คุณค่าของตัวผลลัพธ์ที่เรียกว่าโค้ดจะเหลืออะไร?
• คำกล่าวว่า “ฉันต้องการเฉพาะโค้ดที่มนุษย์เขียนล้วน ๆ ไม่เอาโค้ด AI” หากมองตามความเป็นจริงแล้ว ก็แทบเป็นมุกตลกเชิงประชด
  • ตัวอย่างอุบัติเหตุใหญ่จากโค้ดที่มนุษย์เขียนมีอยู่มากพอแล้ว เช่น เหตุ IT ล่มของ CrowdStrike (2024), การหยุดบินของ Boeing 737 MAX, คดีอื้อฉาวของไปรษณีย์อังกฤษ, การรั่วไหลข้อมูลขนาดใหญ่ในอินเดีย และการรั่วไหลข้อมูลของ Equifax
• โค้ดที่มนุษย์ทั่วโลกเขียนในแต่ละวันนั้น ส่วนสำคัญจำนวนมากอยู่ในสภาพก้ำกึ่งด้านคุณภาพ
• การพัฒนาซอฟต์แวร์ยังคงเป็นสาขาที่ยากจะบอกว่าได้บรรลุความเป็นวิชาชีพที่มีวุฒิภาวะเชิงวัตถุวิสัยแล้ว
  • แพทย์หรือวิศวกรโยธาต้องมีการศึกษา การออกใบอนุญาต และความรับผิดชอบต่อผลลัพธ์การทำงานอย่างเข้มงวด แต่การพัฒนาซอฟต์แวร์แทบไม่มีระบบเช่นนั้น
• สังคมปัจจุบันกำลังขับเคลื่อนอยู่บนระบบโค้ดที่ออกแบบหลวม ๆ ประกอบเข้าด้วยกันแบบลวก ๆ และพองตัวเกินจริง
• หากจะพูดในแบบกระตุ้นอารมณ์ ก็อาจบอกได้ว่า slop ที่ AI สร้างอย่างน้อยก็ดูเรียบร้อย เอกสารถูกจัดไว้ดี และมีความสม่ำเสมอทางไวยากรณ์ในหลายกรณี
• การอ่านข้อความและข้อความสื่อสารที่ LLM สร้างอย่างไร้วิญญาณ ซึ่งท่วมอินเทอร์เน็ตอยู่ทุกวันนี้ กำลังถูกมองแพร่หลายขึ้นว่าแทบเป็นการสิ้นเปลืองการทำงานของเซลล์ประสาทใน amygdala ตามตัวอักษร
• หากกระบวนการสร้างสรรค์ของมนุษย์ รวมถึงทั้งความสมบูรณ์และข้อบกพร่องที่อยู่ในนั้นหายไป ภาษา วรรณกรรม ศิลปะ และดนตรีก็จะกลายเป็นสิ่งที่โดยแก่นแท้แล้วไม่อาจเพลิดเพลินได้
• สิ่งที่สามารถสร้างได้อย่างไร้ขีดจำกัดและทันทีโดยไม่ต้องใช้ความพยายาม จะกลายเป็นสิ่งที่มนุษย์ตัดสินคุณค่าได้ยากอย่างยิ่ง

โค้ดไม่เหมือนศิลปะ

• โดยแก่นแท้แล้ว โค้ดเป็นเพียงเครื่องมือเพื่อไปสู่เป้าหมายมาโดยตลอด ไม่เคยเป็นเป้าหมายในตัวเอง
• ผู้ใช้ปลายทางไม่อ่านโค้ด ไม่จำเป็นต้องอ่าน และไม่ได้สนใจตัวโค้ดเอง
• สำหรับผู้ใช้แล้ว ระบบหลายร้อยตัวที่ทำงานอยู่หลังพอร์ทัลจะถูกสร้างด้วยภาษา เฟรมเวิร์ก หรือสถาปัตยกรรมแบบใดก็ไม่มีความหมาย
• โค้ดเป็นสิ่งที่ถูกซ่อนไว้อย่างมิดชิด และผู้ใช้รับรู้เพียงผลลัพธ์และผลกระทบที่โค้ดสร้างขึ้นผ่าน UX
• เกณฑ์ที่แบ่งว่าโค้ด AI ที่ทำงานได้เหมือนกันนั้นเป็น slop หรือไม่ อยู่ที่โครงสร้างของความรับผิดชอบ (accountability) และการมีส่วนร่วมของความเป็นมนุษย์ (humanness)
• PR ที่มนุษย์เขียนและส่งขึ้นไปยังรีโพซิทอรีโอเพนซอร์ส มักได้รับความเห็นอกเห็นใจและคุณค่าโดยธรรมชาติที่ตั้งอยู่บนเวลาและแรงงานของมนุษย์ที่ใส่ลงไป ไม่ว่าคุณภาพโค้ดจะเป็นอย่างไร
• ในทางกลับกัน PR ที่ LLM สร้าง มักได้รับปฏิกิริยาแรกว่า “slop!” ไม่ว่าจะมีคุณภาพอย่างไร เพราะเราไม่อาจกะระดับความพยายามของมนุษย์ที่อยู่ในนั้นได้ทันที
• ขณะเดียวกัน ภาระในการอ่านและตรวจสอบโค้ดนั้นก็เติบโตแบบไม่สมดุลและเกือบเป็นทวีคูณเมื่อเทียบกับต้นทุนการสร้าง
• ท้ายที่สุด มันก็เป็นเพียงหนึ่งในความแปรผันไร้ขีดจำกัดที่ถูกสร้างขึ้นโดยแทบไม่ต้องใช้ความพยายาม และขาดแหล่งที่มาหรือบริบทที่มีความหมาย
• ณ จุดนี้ ความเป็นจริงของเรากำลังเข้าใกล้**‘หอสมุดแห่งบาเบล’ ที่ Borges บรรยายไว้**มากขึ้นเรื่อย ๆ

อนาคตของ FOSS

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

สองขั้วที่เห็นแต่ต้นไม้ไม่เห็นป่า

• แม้ในยุคที่ยังไม่มี syntax highlighting, IDE หรือเครื่องมือต่าง ๆ มนุษย์ก็ยังสร้างซอฟต์แวร์ที่น่าทึ่งในระดับสูงได้แล้ว
• ในทางกลับกัน แม้ทุกวันนี้จะมีเครื่องมือและทรัพยากรมากมายล้นเหลือ ซอฟต์แวร์แย่ ๆ ก็ยังคงถูกสร้างขึ้นต่อไป
• นักพัฒนาที่มีความสามารถในการสื่อสารสูงและใส่ใจคุณภาพ ไม่ว่าจะใช้ LLM หรือเครื่องมือใด ก็จะนำมันไปใช้ในแบบของตนเพื่อสร้างผลลัพธ์ที่ดี
• ตรงกันข้าม นักพัฒนาที่อธิบายปัญหาไม่ได้และไม่ใส่ใจคุณภาพ ก็จะผลิตผลงานแย่ ๆ ไม่ว่าจะใช้ LLM หรือไม่ก็ตาม
• ทั้งพวกที่หลงใหลใน vibe coding แบบ ‘agentic’ สุดโต่ง และพวกที่ปฏิเสธ LLM โดยสิ้นเชิง ต่างก็มองไม่เห็นป่าและหมกมุ่นอยู่กับต้นไม้
• มีจุดกึ่งกลางเชิงปฏิบัติที่ชัดเจนอยู่ นั่นคือคนที่มีประสบการณ์ ความเชี่ยวชาญ ความคิดวิเคราะห์ และความสามารถในการสื่อสาร เลือก trade-off ที่เหมาะสมเพื่อให้ได้ผลลัพธ์ที่ต้องการ
• vibe coding ยังเป็นจุดเริ่มต้นสำคัญที่ทำให้คนไม่ใช่สายเทคนิคได้แตะซอฟต์แวร์ ทดลอง สนุกกับมัน และพัฒนาความสามารถของตนเองเป็นครั้งแรก
• แต่ผู้ที่เชื่อใน vibe coding อย่างสุดโต่งกำลังมองข้ามองค์ประกอบสำคัญที่ทำให้มนุษย์ยอมรับผลลัพธ์ใดอย่างจริงจัง นั่นคือ ความมีขอบเขตจำกัด (finitude)
• ผลลัพธ์คือพวกเขากำลังก่อหอสมุดแบบ Borges ขนาดมหึมา ที่ตัวเองก็หลงทางได้ง่ายท่ามกลางทะเลแห่ง slop ที่ถูกสร้างโดยเอเจนต์ผู้ช่างประจบ
• ผลลัพธ์ที่ถูกสร้างได้อย่างไร้ขีดจำกัดโดยไม่ต้องใช้ความพยายาม และไม่มีแหล่งที่มาที่มีความหมาย เป็นสิ่งที่ยากอย่างยิ่งทั้งในการมอบคุณค่าและในการรับเอาอย่างจริงจัง
• โดยพื้นฐานแล้ว มนุษย์เป็นสิ่งมีชีวิตที่รับมือกับอุปทานไร้ขีดจำกัด โดยเฉพาะความไร้ขีดจำกัดของตัวเลือก ได้ไม่ดีนัก
• ขณะเดียวกัน พวกต่อต้าน LLM มักไปไม่พ้นข้อโต้แย้งจากความไม่เชื่อ (argument from incredulity)
• เพียงเพราะไม่ชอบเป็นการส่วนตัว ไม่ได้ผลลัพธ์ที่ต้องการ ความคาดหวังไม่ตรง หรือแค่เบื่อ จึงปฏิเสธตัวเทคโนโลยีไปเลย
• แต่ท่าทีเช่นนั้นสูญเสียพลังในการโน้มน้าว เมื่อเผชิญกับข้อเท็จจริงว่ามีคนจำนวนมากที่ใช้เครื่องมือเดียวกันนี้ได้อย่างมีประสิทธิภาพและมีประสบการณ์ตรงกันข้ามโดยสิ้นเชิง
• การนำไปใช้ที่โง่เขลาและเป็นอันตรายซึ่งถูกผลักดันด้วยกระแส hype ความคลั่งไคล้ และความโลภนั้นมีอยู่จริง และเป็นเรื่องน่ากังวลอย่างยิ่ง
• ฟองสบู่ธุรกิจ AI อาจกลายเป็นหนึ่งในฟองสบู่ที่ใหญ่ที่สุดในประวัติศาสตร์
• ถึงกระนั้น การแพร่กระจายของเทคโนโลยี FOSS AI ก็ยังเป็นสัญญาณที่น่ามีความหวังอย่างชัดเจน
• การเหมารวมว่าผู้เล่นไม่ดี เกมตัวเลข หรือการนำไปใช้แบบเหลวไหล เป็นสิ่งเดียวกับความสามารถพื้นฐานเชิงกายภาพที่แท้จริงของเทคโนโลยีเหล่านี้ เป็นเรื่องไร้เหตุผล

ต้นทุนความเป็นมนุษย์

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

บทสรุป: ตอนนี้คำพูดมีค่ามากกว่าโค้ด

• แม้แต่นักพัฒนาที่เคยสร้างซอฟต์แวร์ด้วยมือตัวเองมาโดยตลอด ตอนนี้ก็ต้องให้ความสำคัญกับความสามารถในการอ่านและประเมินโค้ดอย่างมีวิจารณญาณ มากกว่าความสามารถในการเรียนรู้ไวยากรณ์และพิมพ์ทีละบรรทัด
• แน่นอน อย่างหลังยังคงเป็นทักษะสำคัญ และความสามารถในการอ่านโค้ดอย่างมีประสิทธิภาพก็ย่อมสร้างขึ้นบนฐานนั้น
• ถึงกระนั้นก็ตาม เวิร์กโฟลว์การพัฒนาซอฟต์แวร์ในชีวิตประจำวันได้ถูกพลิกกลับไปแล้วโดยสิ้นเชิง
• นักพัฒนาที่มีทักษะและพูดได้ดี กล่าวคือผู้ที่สามารถจินตนาการ อธิบาย นิยามปัญหา ออกแบบสถาปัตยกรรม และทำวิศวกรรมได้ ย่อมมีข้อได้เปรียบที่มากอย่างไม่สมส่วนยิ่งกว่าครั้งใด เมื่อเทียบกับคนที่ทำไม่ได้
• ความรู้เกี่ยวกับภาษา ไวยากรณ์ หรือเฟรมเวิร์กเฉพาะทาง ไม่ใช่คอขวดหลักอีกต่อไป
• ข้อจำกัดทางสรีรวิทยาและทางกายภาพที่เคยมัดนักพัฒนาไว้ในอดีต ก็ไม่ใช่อุปสรรคชี้ขาดอีกแล้ว
• เครื่องจักรที่สร้างโค้ดปริมาณมากได้ทันทีได้กลายเป็นเครื่องมือเชิงสินค้าโภคภัณฑ์ไปแล้ว และทุกคนเข้าถึงได้ในระดับ pip install
• ความจำเป็นในการฝึกเฉพาะทางเพิ่มเติม หรือการเรียนภาษาและเฟรมเวิร์กใหม่ ๆ ก็แทบหายไป
• สิ่งที่จำเป็นมีเพียงทักษะการคิดเชิงวิพากษ์แบบดั้งเดิม ความสามารถพื้นฐานของมนุษย์ และทักษะการใช้งานเครื่องจักรนี้ในระดับขั้นต่ำ
• ด้วยเหตุนี้ วิธีวิทยาการพัฒนาซอฟต์แวร์แบบเดิมและการแบ่งบทบาท—Waterfall กับ Agile, นักพัฒนากับผู้ทดสอบ, ซีเนียร์กับจูเนียร์—จึงกำลังเผชิญการเปลี่ยนแปลงในระดับรากฐาน
• เส้นแบ่งแบบดั้งเดิมกำลังถูกรวมเข้าเป็นลูป ‘agentic’ แบบทำซ้ำที่รวดเร็วอย่างนึกไม่ถึง ถูกบีบอัด และพร่าเลือน
• ด้วยเหตุนี้ พลวัตของผู้คน องค์กร และชุมชนสาธารณะที่รายล้อมการพัฒนาซอฟต์แวร์ รวมถึงแรงจูงใจแบบมนุษย์ที่เคยค้ำจุนการแบ่งปันและการร่วมมือ ก็กำลังเปลี่ยนไปอย่างรวดเร็ว
  • ตัวอย่างเช่น การยุติ bug bounty ของ curl, การนำแนวทางการใช้ AI ของ Zulip มาใช้ และนโยบาย AI แบบชัดเจนของ Ghostty
• เป็นครั้งแรกในประวัติศาสตร์ที่ คำพูดที่ดี (talk) กลายเป็นสิ่งที่มีมูลค่าสูงกว่าโค้ดที่ดีแบบทวีคูณ
• ผลกระทบเป็นลูกโซ่ที่การเปลี่ยนแปลงนี้จะนำมานั้นสำคัญอย่างยิ่ง และในขณะเดียวกันก็ทำลายล้างอย่างมาก

[orange]

"แม้แต่คนที่ไม่เคยเขียนโค้ดสักบรรทัด ก็สามารถสร้างโค้ดในระดับอุตสาหกรรมได้ภายในไม่กี่วินาที"
-> ถ้าสร้างอพาร์ตเมนต์ด้วยหลอดดูด แบบนั้นเรียกว่าระดับอุตสาหกรรมด้วยเหรอ

[goathead]

ผมชอบคำพูดนั้นของทอร์วัลดส์นะ... แต่ยุคสมัยเปลี่ยนไปอย่างสิ้นเชิงแล้ว

[kuthia]

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

[tested]

ในความเป็นจริง การจ้างงานส่วนใหญ่ยังคงต้องการประสบการณ์หลายปีขึ้นไปในภาษาอย่าง Java อยู่เสมอ

[allinux]

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

[pencil6962]

🐎🐎🐎🐎🐎

[skageektp]

คิมิโนะ ไอบะกะ ซึกยุงโดคยุง~

[koreacglee]

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

[GN⁺]

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

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

  • ฉันเองก็พูดมาตลอดว่า “โค้ดแม้แต่บรรทัดเดียวก็เป็นหนี้” งานของเราคือทำให้หนี้นี้น้อยที่สุด แต่ช่วงนี้เหมือนหลักการนี้แทบหายไปแล้ว
  • ฉันเป็นหนึ่งในผู้ดูแลหลักของ Redux อยากรู้จริง ๆ ว่าโค้ดที่ถูกสร้างออกมาเป็นแบบไหน
    ไม่แน่ใจว่าเราจะช่วยมีอิทธิพลอะไรได้ไหม แต่ก็อยากเห็นว่าเกิดอะไรขึ้น
    สำหรับข้อมูลอ้างอิง แนวทางการทดสอบของ Redux สรุปไว้ในเอกสารทางการ
  • การบอกว่า “ช่วยเขียน unit test ให้ Redux” เป็นคำขอที่กำกวมพอ ๆ กับ “ช่วยวาดหมาให้หน่อย”
    คุณควรกำหนด methodology ในการเทสต์ให้ชัดก่อน แล้วค่อยใช้สิ่งนั้นเป็นฐานในการสั่งโมเดล
    AI จะ ตั้งสมมติฐานเอง ในส่วนที่ไม่ได้ระบุไว้ จึงต้องระวัง
    โดยพื้นฐานแล้วการทดสอบคือหัวใจสำคัญ อย่าตัดสินโค้ดจากความรู้สึกกับโค้ด AI แต่ต้องตรวจสอบด้วยเทสต์
    คุณค่าของโค้ดแปรผันตามระดับของการทดสอบ ถ้าปล่อยผ่านแบบ “LGTM” ลวก ๆ ก็เหมือนขี่มอเตอร์ไซค์หลับตา
  • ณ ตอนนี้การให้ LLM เขียนเทสต์ มักจะเสี่ยงอันตราย
    บางกรณีก็ทำได้ดี แต่บางกรณีก็พังแบบดูไม่ได้เลย
    ตัวอย่างเช่น ให้ use case ที่ถูกต้องไปแล้วแต่โค้ดกลับผิด พอเทสต์ล้ม AI ก็เขียนเทสต์ใหม่แทน
    พูดอีกอย่างคือ มีความเสี่ยงที่มันจะนิยามความสำเร็จตามมาตรฐานของตัวเอง
    เมื่อก่อนฉันเคยเปิด Claude สองอินสแตนซ์ ให้ตัวหนึ่งดูแลเทสต์ อีกตัวดูแล implementation แต่การตั้งค่ายุ่งยากเกินไป
  • การสร้างโค้ดเดิมทีก็รู้สึกว่าถูกอยู่แล้ว
    เลยคิดว่านี่เป็นหนึ่งในเหตุผลที่เทคโนโลยีนี้ ถูกยัดเยียดให้ทีมใช้งาน
    คล้ายกับการย้ายขึ้นคลาวด์ ต้นทุนที่แท้จริงจะไปโผล่ตอนหลัง แค่ครั้งนี้น่าจะเร็วกว่าเยอะ

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

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

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

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

• เวลามีคนบอกว่า “วิศวกรรมจบแล้ว” ก็มักจะมีแรงต้านเยอะเสมอ
  แต่ในมุมของฉัน สำหรับผลิตภัณฑ์ขนาดใหญ่ การเขียนโค้ดคิดเป็นแค่ราว 10~20% ของทั้งหมด
  ที่เหลือคือการออกแบบ การทดลอง การวิเคราะห์ การสื่อสาร ฯลฯ ซึ่ง LLM แทนที่ส่วนนี้ได้ยาก
  ตรงกันข้าม การทำงานร่วมกันและการประสานงานยิ่งซับซ้อนขึ้น และหลายครั้ง LLM ก็ทำให้แย่ลง
  เพราะงั้นจึงควรมอง AI เป็น เครื่องมือ ไม่ใช่สิ่งทดแทน

  • ที่จริงแล้วเราอาจไม่ได้เห็นต่างจากผู้เขียนแบบสุดขั้วก็ได้
    เขาพูดว่า “แนวทางการพัฒนาที่ใช้มาหลายสิบปีจบลงแล้ว” ไม่ได้บอกว่าวิศวกรรมจบลง
    ถ้าการเขียนโค้ดมีแค่ 10~20% ก็แปลว่า ‘การพูดคุย’ ที่เหลือสำคัญขึ้นกว่าเดิม
  • ความหมายแท้จริงของ “Code is cheap” คือ แก่นแท้ของวิศวกรรมสำคัญขึ้นกว่าเดิม
    อย่างที่ Linus พูดไว้ว่า “ต้องแสดงให้เห็นว่าโค้ดทำงานตามที่ตั้งใจ”
    การเขียนไม่กี่บรรทัดด้วย LLM นั้นง่าย แต่การแก้ไขอย่างปลอดภัยยังยากอยู่เหมือนเดิม
    ได้ยินมาว่า Liz Fong-Jones จาก Honeycomb ก็เคยพลาดแบบนี้เหมือนกัน
  • ฉันเห็นด้วยว่าในความเป็นจริง การโค้ดกินสัดส่วนไม่ถึง 10% ของทั้งหมดด้วยซ้ำ
    เมื่อบริษัทต่าง ๆ ติดตาม ROI ของ LLM มากขึ้น พวกเขาจะเริ่มเห็นความจริง
    ตอนนี้เราอยู่บนยอดของ hype cycle ของ Gartner และอีกไม่นานน่าจะลงไปสู่หุบเขาแห่งความผิดหวัง
  • ฉันก็มีประสบการณ์คล้ายกัน
    รีแฟกเตอร์ได้เร็วมากด้วย Claude จนถึงจุดหนึ่งแล้วไปต่อไม่ได้เลย
    สาเหตุก็คือฉัน ไม่รู้ว่าตัวเองต้องการอะไร
    ถ้าโมเดลข้อมูลยังไม่ชัด แล้วสั่งว่า “เขียนต่อไปเรื่อย ๆ” ผลลัพธ์ที่ได้จะแย่มาก
  • อย่างที่หนังสือ 『Software Engineering at Google』 บอกไว้
    การเขียนโปรแกรมเป็นกิจกรรมระยะสั้น แต่ วิศวกรรมซอฟต์แวร์เป็นกระบวนการระยะยาว
    AI เร่งอย่างแรกได้ แต่แทนที่อย่างหลังไม่ได้

• สมมติฐานเรื่อง “มีแผนพัฒนาที่ชัดเจนและมี know-how ในการลงมือทำ” นั้นไม่สมจริง
  เพราะการเขียนโปรแกรมเองก็คือ การวางแผน และภาษาเป็นเครื่องมือคิดที่ยอดเยี่ยม
  เพราะงั้นมุมมองต่อ LLM จึงแตกออกเป็นสองทาง — คนที่มองภาษาว่าเป็นเครื่องมือคิด กับคนที่มองว่าเป็นแค่เครื่องมือสั่งงาน
  แบบแรกเห็นคุณค่าของการเขียนโปรแกรมในตัวมันเอง ส่วนแบบหลังพยายามซ่อนโค้ดไว้
  สุดท้ายมันคือเรื่องของการเลือก: จะสร้าง conceptual model ให้ดีตั้งแต่ต้น หรือจะไปเจอ นรกแห่งการดีบัก ในภายหลัง
  เครื่องมือในตอนนี้ไม่ได้ออกแบบมาเพื่อฝั่งแรก ช่องว่างด้าน tooling ยังใหญ่มาก

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

• ความหมายดั้งเดิมของ “Talk is cheap” คือ “คำพูดมันง่ายและไม่มีค่า”
  แต่ “Code is cheap. Show me the talk.” กลับให้ความรู้สึกเหมือนบอกว่าสิ่งนั้นไร้ค่ายิ่งกว่า เลยทำให้ฉันรู้สึกขุ่นเคืองตั้งแต่แรก
  พออ่านบทความจริงก็พบว่าที่คาดไว้ก็ถูกต้อง

  • ดูเหมือนคุณจะยึดติดกับชื่อเรื่องมากเกินไป มันก็แค่ มุกตลก
    ผู้เขียนไม่ได้ไม่รู้อะไรเรื่องโค้ด เขาทำโอเพนซอร์สค่อนข้างเยอะด้วย
    ใจความนั้นง่ายมาก — เมื่อก่อนการเอาดีไซน์ที่ดีมาเขียนเป็นโค้ดมีต้นทุนสูง
    แต่ตอนนี้มันถูกลงแล้ว เพราะงั้น คุณภาพของการออกแบบจึงสำคัญกว่าเดิม
  • ที่จริงวลีนี้เป็น การล้อกลับแบบพลิกด้าน ของคำพูดของ Linus
    “Talk is cheap, show me the code”
  • ถ้ามองอีกบริบทหนึ่ง “การพูด” อาจสำคัญกว่าก็ได้
    สิ่งสำคัญไม่ใช่โค้ด แต่คือ โมเดลในหัวของนักพัฒนา
    โค้ดเป็นเพียงผลพลอยได้ของโมเดลนั้น และไม่มีความหมายหากไม่มีมนุษย์คอยตีความ
    มุมมองนี้ส่งผลอย่างมากต่อการใช้ LLM ด้วย

• ยากที่จะเห็นด้วยกับคำพูดที่ว่า “วิธีที่เราทำกันมาหลายสิบปีจบลงแล้ว”
  วิธีพัฒนาในปี 2005, 2015 และ 2025 ต่างกันชัดเจน
  การเปลี่ยนแปลงมีมาตลอด และสมมติฐานที่ว่า “หลายสิบปีเหมือนเดิม” นั้นผิด

  • แต่ในช่วง 20 ปีที่ผ่านมา workflow หลัก ๆ ไม่ได้เปลี่ยนมากนัก
    เครื่องมือพัฒนาขึ้นก็จริง แต่รูปแบบการทำงานของนักพัฒนายังคล้ายเดิม
  • ถ้านึกถึงฟีเจอร์ คอมไพล์ทันที ของ Visual Age for Java
    neovim ทุกวันนี้ก็ทรงพลังกว่าสมัยนั้นมาก
    มีแนวโน้มจะประเมินค่าความก้าวหน้าแบบค่อยเป็นค่อยไปในรอบ 30 ปีต่ำเกินไป
  • ความต่างระหว่างปี 1995 กับ 2005 นั้นใหญ่กว่ามาก
    ตอนนั้นข้อมูลส่วนใหญ่ได้มาจาก หนังสือกระดาษหรือการ reverse engineering

• ฉันรู้สึกอินกับประโยค “Talk is even cheaper, still show me the code” มากกว่า
  AI สัญญาว่าจะเพิ่มผลิตภาพ 10 เท่า แต่แทบไม่เคยเห็นผลลัพธ์แบบนั้นจริง
  AI ทำให้ความซับซ้อนพอทนได้มากขึ้นก็จริง แต่ถึงอย่างนั้น การเขียนแอป React ก็ยังทรมาน
  การรับมือกับ API ที่ไม่ deterministic ก็ยังลำบาก
  ถึงอย่างนั้น ข้อดีคือใช้เวลาน้อยลงกับการหาคำสะกดหรือค้นหาตัวอย่าง
  แต่เพราะ ข้อจำกัดด้านการให้เหตุผลและขอบเขตความรู้ การเขียนโค้ดก็ยังน่าเบื่อเหมือนเดิม

  • ตัวอย่างเช่น โปรแกรมเทอร์มินัลของ Claude เรนเดอร์ React ที่ 60fps แล้ว
    แปลงมันเป็นตัวอักษร ANSI ก่อนจะวาดทับลงบนเทอร์มินัล —
    ซึ่งจริง ๆ แล้วคือการทำสิ่งที่ ทำง่าย ๆ ด้วย curses ได้อยู่แล้ว ให้ซับซ้อนเกินจำเป็น

• วลีอย่าง “Code is cheap. Show me the talk.” ตอนนี้ถูกใช้เกินขนาดเป็น เหยื่อล่อคลิก ไปแล้ว
  ตัวบทความเองไม่ได้แย่ แต่ก็ไม่มีอะไรใหม่
  คนที่อาศัยกระแส AI ไม่ได้มีแค่บริษัท แต่รวมถึงบล็อกเกอร์และอินฟลูเอนเซอร์ด้วย
  แค่เอาชื่อเรื่องแรง ๆ ไปติดกับบทความ AI ไม่ว่าจะเชิงบวกหรือลบ ก็กลายเป็นกระแสใน HN หรือ Reddit ได้แล้ว
  สำหรับอ้างอิง ต้นทางของวลีนี้คือทวีตนี้ กับ
  หน้านี้ของมีม

• ในที่สุดก็มีคนอธิบาย พื้นที่ตรงกลางที่สมจริงระหว่างสองขั้วสุดโต่ง ได้ดีสักที
  LLM ไม่ใช่พระเจ้า และไม่ใช่หายนะ มันคือ เครื่องมือ
  คุณสามารถวิจารณ์การ รีดค่าเช่า ของบริษัทอย่าง OpenAI, Google, Microsoft ได้ พร้อมกับใช้ โมเดลรันในเครื่อง อย่าง Qwen หรือ Mistral ไปด้วยก็ยังได้
  LLM บนคลาวด์ไม่สามารถทำ E2EE ได้ในเชิงความปลอดภัย จึงไม่เหมาะกับสภาพแวดล้อมองค์กร
  แต่ด้วย local LLM ตอนนี้เราจึงสามารถทำ งานระดับ enterprise ได้คนเดียว
  ใช้แค่ Mac Mini เครื่องเดียวก็จัดการได้ทั้ง query ฐานข้อมูล การรวม API และงาน automation
  ถ้าไม่ใช่องค์กรขนาดใหญ่ senior generalist คนเดียวก็แทน mid-level ได้สามคน
  แน่นอนว่าฉันยังไม่พอใจกับเรื่องงานที่จะหายไปหรือประเด็นลิขสิทธิ์อีกมาก
  แต่ local LLM ก็กลายเป็นส่วนหนึ่งของ ชุดเครื่องมือหลัก ของฉันไปแล้ว

[xfile284]

ดูเหมือนจะเป็นบทความที่อยากให้คนที่กำลังมี "ความศรัทธา" ได้อ่านนะ