การตายของโค้ดเป็นคำกล่าวอ้างที่เกินจริง

 (stevekrouse.com)
1 คะแนน โดย GN⁺ 2026-03-23 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • การเขียนโปรแกรมคือ การสร้างสรรค์ที่ค่อย ๆ ขัดเกลาข้อกำหนดที่กำกวมให้แม่นยำ และ AI ช่วยเร่งกระบวนการนี้ด้วยการแปลงข้อกำหนดภาษาอังกฤษให้เป็นโค้ด
  • ‘Vibe coding’ ทำให้การพัฒนาแบบอาศัยความรู้สึกเป็นไปได้ แต่ก็ไม่อาจหลีกเลี่ยง ปัญหาความซับซ้อนและบั๊ก ที่เกิดจากการรั่วไหลของ abstraction ได้
  • มนุษย์ใช้ abstraction และการบีบอัด เพื่อรับมือกับความซับซ้อน และสิ่งนี้ทำงานเป็นคุณค่าหลักของการเขียนโปรแกรม
  • ใน ยุค AGI คาดว่า AI จะช่วยสนับสนุน abstraction ที่ดียิ่งขึ้น ทำให้เกิด การสร้างโค้ดที่ประณีตและมีศิลปะ
  • ตรงกันข้ามกับแนวคิดที่ว่า “โค้ดตายแล้ว” AI ถูกนำเสนอว่าไม่ใช่จุดจบของการเขียนโค้ด แต่เป็นเครื่องมือที่เปิดฉากการเริ่มต้นใหม่

การตายของโค้ดเป็นคำกล่าวอ้างที่เกินจริง

  • ชี้ให้เห็นถึง ความกำกวมของข้อกำหนดภาษาอังกฤษและข้อจำกัดด้านความแม่นยำ โดยมองว่าการเขียนโปรแกรมเป็นการกระทำที่ค่อย ๆ เพิ่มความแม่นยำซ้ำไปซ้ำมาเหมือนการเขียน
    • ผ่านคำกล่าวของ Bertrand Russell ที่เน้นว่า “ทุกสิ่งล้วนกำกวม จนกว่าคุณจะพยายามทำให้มันแม่นยำ”
    • AI สามารถแปลงข้อกำหนดที่เขียนเป็นภาษาอังกฤษให้เป็นโค้ดที่รันได้อย่างรวดเร็ว ทำให้ผู้ใช้ค่อย ๆ ทำให้ผลลัพธ์ที่ต้องการชัดเจนขึ้นได้
  • ‘Vibe coding’ คือวิธีพัฒนาที่ตอบสนองต่อผลลัพธ์ที่ AI สร้างขึ้นอย่างอาศัยความรู้สึก แต่สิ่งนี้อาจสร้าง ภาพลวงของ abstraction ที่แม่นยำ
    • เมื่อ abstraction รั่วไหล ก็จะเกิดบั๊กที่ไม่คาดคิด และปัญหานี้ยิ่งรุนแรงขึ้นเมื่อระบบมีขนาดใหญ่ขึ้น
    • มีการยกกรณีของ Dan Shipper ที่แนะนำประสบการณ์การสร้าง collaborative text editor ด้วย ‘vibe coding’ ซึ่งได้รับความนิยม แต่สุดท้ายล่มเพราะปัญหาความซับซ้อน
    • “การทำงานร่วมกันแบบสด” ดูเหมือนจะเรียบง่ายในเชิงสัญชาตญาณ แต่ในความเป็นจริงเป็นปัญหาที่ยากมาก และแสดงให้เห็นธรรมชาติของความซับซ้อน

การควบคุม abstraction และความซับซ้อน

  • มนุษย์รับรู้สิ่งต่าง ๆ ได้พร้อมกันเพียงประมาณ 7±2 รายการ ดังนั้น วิธีเดียวในการรับมือกับความซับซ้อนคือ ‘การบีบอัด’ หรือก็คือ abstraction
    • ผ่านคำกล่าวของ Edsger Dijkstra ที่ย้ำว่า “จุดประสงค์ของ abstraction ไม่ใช่ความกำกวม แต่คือความแม่นยำในระดับความหมายใหม่”
    • ยกตัวอย่างกรณีที่ Sophie Alpert ทำให้ผังการแจ้งเตือนอันซับซ้อนของ Slack เรียบง่ายลง
  • แก่นสำคัญของการเขียนโปรแกรมคือ การสร้าง abstraction ที่ดีกว่าเพื่อจัดการความซับซ้อน และเราสามารถมองเห็นความงามนั้นได้จากแนวทางอย่าง functional reactive programming
    • แม้แต่ปัญหาที่ซับซ้อนโดยเนื้อแท้อย่าง collaborative text editor ก็ยังสามารถค่อย ๆ พิชิตได้ผ่านเครื่องมือ abstraction อย่าง ReactJS หรือ TailwindCSS

ยุค AGI และบทบาทของโค้ด

  • เมื่อ AI พัฒนาเร็วขึ้นและมีต้นทุนต่ำลงเรื่อย ๆ ในที่สุดมันจะไปถึง สติปัญญาที่แยกไม่ออกจากมนุษย์ (AGI)
    • ในยุค AGI มีแนวโน้มว่าทุกคนจะสามารถใช้สติปัญญาระดับทรงพลังได้ราวกับมี ‘อัจฉริยะระดับ Karpathy 100 คน’ ในราคาถูก
    • แต่สิ่งนี้ไม่ได้มีไว้เพื่อผลิต ‘โค้ดห่วยเพิ่มขึ้นอีก’ หากแต่จะถูกใช้เป็น เครื่องมือสำหรับ abstraction ที่ดีกว่าและความเข้าใจความซับซ้อนที่ลึกขึ้น
  • โค้ดไม่ได้เป็นเพียงวิธีสร้างซอฟต์แวร์ แต่ยังเป็น ผลผลิตเชิงศิลปะที่สำคัญในตัวเอง และโค้ดที่เขียนอย่างดีสามารถเปรียบได้กับบทกวี
    • เช่นเดียวกับที่การเขียนไม่มีสิ่งที่เรียกว่า ‘vibe writing’ การเขียนโค้ดก็ไม่อาจถูกแทนที่ด้วยการกระทำที่อาศัยเพียงความรู้สึก
    • เมื่อ AGI มาถึง เครื่องจักรจะสามารถเขียนโค้ดที่ ‘ไม่ใช่ non-slop’ ได้ และนั่นจะเป็นความก้าวหน้าอันน่ายินดีของมนุษยชาติ

AI และการยกระดับคุณภาพโค้ด

  • ปัจจุบัน AI ยังสร้าง โค้ดที่ไม่สมบูรณ์ อยู่ แต่เหล่านักพัฒนาก็ใช้งานมันโดยคำนึงถึงข้อจำกัดนี้
    • ตามมุมมองของ Simon Willison AI ควรถูกใช้เป็น เครื่องมือในการสร้างโค้ดที่ดีกว่า
    • เมื่อ AGI ปรากฏขึ้น มันจะถูกนำไปใช้แก้ ปัญหา abstraction ที่ยากที่สุด เป็นลำดับแรก เพื่อปรับปรุงระบบซับซ้อนอย่างไลบรารี collaborative editor
  • มีการแนะนำกรณีศึกษาการพัฒนา full-stack React framework (vtrr) สำหรับ Val Town โดยใช้ Opus 4.6
    • มันแก้ปัญหาที่ยังค้างอยู่เกี่ยวกับ React Router 7 ได้ในคราวเดียว และจัดการความซับซ้อนได้อย่างสง่างามด้วยเดโมไฟล์เดียว 50 บรรทัด
    • สิ่งนี้แสดงให้เห็นว่า การสร้างโค้ดที่ประณีตผ่านความร่วมมือระหว่าง AI กับมนุษย์ เป็นไปได้

อนาคตของโค้ดและคุณค่าของรูปแบบนิยม

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

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

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

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

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

    • สำหรับผม LLM มีประโยชน์มากที่สุดตอนต้องเชื่อมหลายระบบเข้าด้วยกัน
      แทนที่จะต้องเสียเวลาหลายชั่วโมงไล่อ่านเอกสารเพื่อตั้งค่าการยืนยันตัวตนที่ซับซ้อนอย่าง OAuth หรือ SAML เอง LLM สามารถสร้าง โค้ดเชื่อมต่อที่ใช้งานได้จริง ให้ได้อย่างรวดเร็ว
      และยังใช้คุยกับ AI เพื่อจัดระเบียบความคิดของตัวเอง คล้าย rubber duck debugging ได้ด้วย
      บทสนทนาแบบนี้มีความซับซ้อนในระดับที่คนที่ไม่มีประสบการณ์พัฒนาซอฟต์แวร์จริงทำได้ยาก
    • ผมคิดว่าคำถามว่า AI จะมาแทนมนุษย์หรือไม่ ไม่ใช่เรื่องแบบ ขาวหรือดำ แต่เป็นเรื่องของสเปกตรัม
      สิ่งที่น่ากังวลจริง ๆ คือ AI จะทำให้อุปสงค์ลดลงจนวงการเกิด ภาวะอุปทานล้นเกิน หรือไม่
      ถ้ายังมีปัญหาทางธุรกิจใหม่ ๆ เกิดขึ้นต่อเนื่อง AI ก็จะเป็นเครื่องมือที่ช่วยได้ แต่ถ้าไม่เป็นเช่นนั้น งานก็จะลดลงอยู่ดีไม่ว่าจะมี AI หรือไม่ก็ตาม
    • คำพูดที่ว่า “AI สร้างคำตอบใกล้ศูนย์กลางของกรอบความคิดเดิม” เกี่ยวข้องกับ ทฤษฎีบทการประมาณค่าเอนกภพ (Universal Approximation Theorem)
      โครงข่ายประสาทเทียมโดยพื้นฐานแล้วทำ interpolation ไม่ใช่ extrapolation
      กล่าวคือ ในขอบเขตที่เคยเรียนรู้มามันทำได้ละเอียดมาก แต่พอออกนอกขอบเขตนั้นไปก็แทบคาดเดาไม่ได้
      บทความ Wikipedia และ ตัวอย่าง SolidGoldMagikarp แสดงเรื่องนี้ได้ชัดเจน
    • ผมคิดว่าการประเมินของ Lattner เป็น การเปรียบเทียบที่ไม่ยุติธรรม
      เป้าหมายของ Claude ไม่ใช่การสร้างนวัตกรรม แต่เป็นการพิสูจน์ว่า “AI สามารถสร้างคอมไพเลอร์ได้หรือไม่”
      ถ้าดูกรณีอย่าง AlphaDev หรือ AlphaEvolve ก็มีความเป็นไปได้มากพอที่ AI จะสร้างนวัตกรรมจริงได้ผ่าน การเรียนรู้เชิงสำรวจและการผสานความรู้
    • เป็นความจริงที่ AI เดินตาม กรอบคิดแบบคุ้นชิน แต่นั่นกลับเป็นจุดแข็งด้วย
      ส่วนใหญ่แล้วเราต้องการเครื่องมือที่คาดเดาได้ ไม่ใช่สิ่งไม่เสถียรที่เรียนรู้เองไปเรื่อย ๆ
      AI มีความสามารถในการจัดระเบียบข้อกำหนดที่ขัดแย้งกันเพื่อสร้าง การนำไปใช้ที่สอดคล้องกัน
      เช่น คำขอที่เป็นไปไม่ได้อย่าง “ช่วยวาดเส้นสีแดง 7 เส้นด้วยหมึกสีน้ำเงิน” มันก็ยังตอบเชิงตรรกะได้
      ที่ Claude ตอบว่า “นั่นเป็นไปไม่ได้ ดังนั้นการวาด 0 เส้นคือคำตอบที่ซื่อสัตย์ที่สุด” ก็ถือเป็น ตัวอย่างของการคิดเชิงวิพากษ์

  • สำหรับคำถามว่า “AI จะสร้างเทคโนโลยีใหม่ได้ไหม?” ผมยังมองด้วยความสงสัย
    AI พึ่งพาข้อมูลเดิมที่มีอยู่ ดังนั้นเมื่อมีภาษาใหม่หรือเฟรมเวิร์กใหม่เกิดขึ้น ข้อมูลฝึกที่ไม่เพียงพออาจทำให้เกิด ความเสี่ยงที่ความเร็วในการพัฒนาจะช้าลง

    • แต่ในโลกซอฟต์แวร์ทุกวันนี้ ความเร็วของการเปลี่ยนแปลงเครื่องมือ ก็เริ่มช้าลงอยู่แล้ว
      AI coding อาจช่วยลดการ “ประดิษฐ์ล้อขึ้นใหม่” และช่วยให้เราเลิกติด อาการ NIH syndrome ก็ได้
    • ผมกำลังใช้โมเดล AI กับ เฟรมเวิร์กใหม่ อยู่
      แม้แทบไม่มีข้อมูลฝึก มันก็ยังอ่านเอกสาร เขียนโค้ด และ ลองแนวทางใหม่ ๆ ได้
    • สมมติฐานที่ว่ามีแต่มนุษย์เท่านั้นที่สร้างสิ่งใหม่ได้ก็ไม่ได้มีหลักฐานรองรับมากนัก
      เราควรเปิดรับความเป็นไปได้ว่า วันหนึ่ง AI ก็อาจทำ การสังเคราะห์เทคโนโลยีเชิงสร้างสรรค์ ได้เช่นกัน
    • ปัญหาที่ใหญ่กว่าคือ เฟรมเวิร์กที่ AI ไม่เคยเรียนรู้อาจถูก ปฏิบัติเหมือนไม่มีอยู่จริง
      ท้ายที่สุดเราอาจเข้าสู่ยุคที่นักพัฒนาต้อง จ่ายเงินเพื่อให้ตัวเองถูกใส่เข้าไปในข้อมูลฝึกของ AI
    • ตอนนี้ก็มีความพยายามแก้ปัญหานี้แล้ว
      เช่นแพลตฟอร์มอย่าง skills.sh ที่มี ระบบสกิล สำหรับสอนเฟรมเวิร์กใหม่ให้ AI
      แค่มีเอกสารและโค้ดตัวอย่าง AI ก็สามารถนำเฟรมเวิร์กนั้นไปใช้ได้ทันที

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

    • แต่บางคนก็บอกว่าอนาคตแบบ Star Trek กับความเป็นจริงตอนนี้กำลังไปกันคนละทิศทางโดยสิ้นเชิง

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

    • แต่อุตสาหกรรมที่ขับเคลื่อนด้วยเป้าหมายแบบนั้นก็คงไม่หายไปง่าย ๆ เพียงเพราะเทคโนโลยีเปลี่ยน

  • ผมกำลังสร้าง CRDT ที่สามารถย้าย ลบ และจัดเรียงได้ในโครงสร้างต้นไม้โดยไม่ต้องมี tombstone
    Claude Code เขียนโค้ดได้ดี แต่พยายามจะเพิ่ม tombstone ตลอด จนผมต้องใช้ การพิสูจน์เชิงตรรกะ เพื่อโน้มน้าวมัน
    ดูเหมือนว่า AI ยังไม่ได้มีความเข้าใจเชิงโครงสร้างที่ละเอียดระดับนี้อย่างสมบูรณ์

    • มีคนแนะนำให้ใช้ Codex กับโปรเจกต์แบบนี้

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

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

    • แน่นอนว่าถ้าวันหนึ่งอัตราการเกิดบั๊กของมนุษย์สูงกว่า LLM จริง ๆ ความผิดพลาดของมนุษย์ ก็อาจกลายเป็นปัญหาใหญ่กว่า อาการหลอนของ AI

  • อย่างที่ Simon Willison พูดไว้ คุณค่าที่แท้จริงของ vibe coding ไม่ใช่การ “เร็วขึ้น” แต่คือการสร้าง “โค้ดที่ดีกว่า”
    เราสามารถสร้างต้นแบบจากโมเดลการออกแบบหลายแบบ แล้วปรับปรุงซ้ำโดยดูจากเกณฑ์เรื่อง ความอ่านง่าย ความน่าเชื่อถือ และความทนทานต่อความผิดพลาด

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

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

    • ก็เหมือนคำพูดของผู้บัญชาการสำนักงานสิทธิบัตรในปี 1899 ที่ว่า “ทุกอย่างที่ประดิษฐ์ได้ถูกประดิษฐ์ไปหมดแล้ว” ทั้งที่จริงแล้ว ความคิดสร้างสรรค์ของมนุษย์ยังคงวิวัฒน์ต่อไป
    • การสร้างคอมไพเลอร์ C ไม่ได้ยากอย่างที่คิด
      ถ้าอ่าน Dragon Book คุณน่าจะสร้างของที่ทำงานได้ภายในไม่กี่เดือน และเข้าใจหลักการทั้งหมดไปพร้อมกัน
    • ความก้าวหน้าทางภาษารูปแบบใหม่ก็จะยังมีต่อไป เหมือนกับ นวัตกรรม ที่ C# เคยแสดงให้เห็นในช่วงต้นยุค 2000
    • จริง ๆ แล้ว C ไม่ได้ซับซ้อนมากนัก ดังนั้นอาจสร้างคอมไพเลอร์ได้ภายในไม่กี่วันด้วยซ้ำ

  • ผมคิดว่าภาษาโปรแกรมคือเครื่องมือสำหรับ บีบอัดเจตนาของมนุษย์ให้อยู่ในรูปที่กระชับ
    แต่บางครั้งภาษาธรรมชาติก็สื่อ เจตนาได้แม่นยำและหนาแน่นกว่า
    abstraction ที่ดีคือสิ่งที่ช่วยลดช่องว่างนี้ลง และ DSL หรือภาษาตระกูล ML/Lisp ก็คือตัวอย่างของสิ่งนั้น
    เช่น บทเรียน Electric Clojure ที่แสดงให้เห็นว่าโค้ดเองก็อาจถ่ายทอดเจตนาได้ดีที่สุด
    ท้ายที่สุดแล้ว อย่างที่ Wittgenstein กล่าวไว้ “ภาพที่คลุมเครือ บางครั้งก็อาจเป็นสิ่งที่เราต้องการพอดี”

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