ไม่มีใครรู้ว่าทั้งระบบทำงานอย่างไร

 (surfingcomplexity.blog)
3 คะแนน โดย GN⁺ 2026-02-10 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • ระบบเทคโนโลยีสมัยใหม่ได้พัฒนาไปสู่โครงสร้างที่ ซับซ้อนเกินกว่าที่คนคนเดียวจะเข้าใจทั้งหมดได้
  • เมื่อ การพัฒนาซอฟต์แวร์และการใช้งาน AI เพิ่มขึ้น กรณีที่นักพัฒนาสร้างระบบโดยไม่เข้าใจกลไกภายในก็เพิ่มมากขึ้น
  • Simon Wardley ชี้ถึงความเสี่ยงของการสร้างระบบโดยปราศจากความเข้าใจ, Adam Jacob ชี้ว่า AI กำลังเปลี่ยนวิธีการพัฒนา, และ Bruce Perens ชี้ว่าความซับซ้อนได้ก้าวข้ามขีดจำกัดไปแล้ว
  • Louis Bucciarelli ใช้กรณีศึกษาของระบบโทรศัพท์เพื่อแสดงให้เห็นว่า เทคโนโลยีพันกันอยู่หลายชั้นจนไม่มีใครเข้าถึงความเข้าใจอย่างสมบูรณ์ได้
  • บทความเน้นว่า AI กำลังทำให้ความซับซ้อนนี้รุนแรงขึ้น แต่ในความเป็นจริง มนุษย์ก็จัดการกับเทคโนโลยีภายใต้ความเข้าใจเพียงบางส่วนมาเป็นเวลานานแล้ว

ความซับซ้อนของเทคโนโลยีและขีดจำกัดของความเข้าใจ

  • หลังการเสื่อมถอยของ Twitter ได้มีการถกเถียงเรื่อง ความเข้าใจทางเทคนิคและความซับซ้อน อย่างคึกคักบน LinkedIn
    • มีการกล่าวถึงโพสต์ของ Simon Wardley, Adam Jacob และ Bruce Perens ในฐานะประเด็นที่เชื่อมโยงกัน
  • Wardley เตือนถึง อันตรายของการสร้างระบบโดยไม่รู้หลักการพื้นฐาน
    • คำว่า “Magic” ใช้ในเชิงวิจารณ์เพื่อเรียกเฟรมเวิร์กที่ซ่อนการทำงานภายใน โดยยก Ruby on Rails เป็นตัวอย่างเด่น
  • Jacob ชี้ว่า AI กำลังเปลี่ยนวิธีการพัฒนาซอฟต์แวร์อย่างถึงราก
    • AI ช่วยเพิ่มประสิทธิภาพ แต่ก็มีแนวโน้มทำให้นักพัฒนาทำงานโดยไม่เข้าใจโครงสร้างชั้นล่าง
  • Perens กล่าวถึงว่า สถานการณ์ที่ Wardley กังวลได้กลายเป็นความจริงไปแล้ว
    • ด้วยความซับซ้อนของ CPU และระบบปฏิบัติการยุคใหม่ ทำให้นักพัฒนาจำนวนมากเข้าใจหลักการทำงานจริงอย่างคลาดเคลื่อน

กรณีศึกษา ‘โทรศัพท์’ ของ Louis Bucciarelli

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

การสัมภาษณ์งานสายเทคนิคและ ‘ขีดจำกัดของความรู้’

  • ผู้เขียนย้อนเล่าบทสนทนากับ Brendan Gregg ในช่วงที่ทำงานอยู่ที่ Netflix
    • Gregg บอกว่าในการสัมภาษณ์ เขาจะประเมิน ขอบเขตความรู้ของผู้สมัครและปฏิกิริยาต่อขอบเขตนั้น
    • เขาดำเนินการสัมภาษณ์บนสมมติฐานว่า “ไม่มีใครเข้าใจทั้งระบบทั้งหมดได้อย่างสมบูรณ์”
  • แนวทางนี้แสดงให้เห็นว่า ท่าทีที่ยอมรับในสิ่งที่ตนไม่รู้ สำคัญพอๆ กับความสามารถทางเทคนิค

ธรรมชาติของความซับซ้อนและผลกระทบของ AI

  • มุมมองของ Wardley, Jacob, Perens และ Bucciarelli ต่างเผยให้เห็น ความหลีกเลี่ยงไม่ได้ของความซับซ้อน ในคนละระดับ
    • Wardley: ความเสี่ยงของการสร้างโดยไม่เข้าใจ
    • Jacob: ประสิทธิภาพและความห่างเหินที่ AI นำมา
    • Perens: ความจริงของความซับซ้อนที่มีอยู่แล้ว
    • Bucciarelli: ความเป็นไปไม่ได้ในการเข้าใจทั้งระบบ
  • บทความยอมรับว่า AI จะยิ่งทำให้ปัญหานี้รุนแรงขึ้น แต่ก็เตือนให้ระลึกว่า มนุษย์ใช้ชีวิตกับเทคโนโลยีภายใต้ความเข้าใจเพียงบางส่วนมาโดยตลอด

สรุปการถกเถียงของผู้อ่าน

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

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

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

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

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

    • แม้จะเน้นเรื่อง "ownership" แต่พอจะพยายามมีอำนาจนำจริง ๆ กลับเจอข้อจำกัดด้านการเข้าถึงและข้อมูลไม่เพียงพอ
      โดยเฉพาะบริษัทใหญ่ยิ่งขาดความโปร่งใส ฉันเคยทำโอทีเพื่อให้ทันเดดไลน์ แต่สุดท้ายกำหนดการถูกเลื่อนโดยที่มีแค่ฉันที่ไม่รู้
      ถ้าฉันถูกปฏิบัติเหมือนเป็นแค่เครื่องมือ ฉันก็จะทำแค่บทบาทนั้น แต่ถ้าต้องการ ownership จริง ก็ต้องมีที่นั่งบนโต๊ะตัดสินใจ
    • ในทางกลับกัน ฉันรู้สึกว่า Claude กลับช่วยให้ สมาธิ ดีขึ้น
      เมื่อก่อนเสียเวลาไปกับงานตั้งค่าซ้ำ ๆ แต่ตอนนี้โฟกัสกับฟีเจอร์หลักได้อย่างเดียว ทำให้รักษาภาพรวมของโครงสร้างทั้งระบบไว้ในหัวได้ดีกว่าเดิม
    • ปรากฏการณ์นี้คล้ายกับระบบอัตโนมัติในการเกษตร ทุกวันนี้แค่นั่งอยู่บนรถแทรกเตอร์ เครื่องก็ทำทุกอย่างให้หมดแล้ว สุดท้ายคนก็เป็นแค่ น้ำหนักสำหรับเซ็นเซอร์ที่เบาะนั่ง เท่านั้น
    • ฉันอยากให้ Claude สนับสนุน การแก้โค้ดแบบโต้ตอบที่เน้นการแก้เล็ก ๆ มากกว่าการพัฒนาอัตโนมัติเต็มรูปแบบ
      เช่น เลือกโค้ดไม่กี่บรรทัดใน IDE แล้วพูดด้วยเสียงว่า "แก้ส่วนนี้เป็นแบบนี้ให้หน่อย" แล้วมันสะท้อนผลทันที
      ถ้าเร็วพอ การควบคุมด้วยเมาส์+เสียงก็น่าจะเป็น เครื่องมือการเข้าถึง ที่ยอดเยี่ยมได้ด้วย
    • จริง ๆ แล้วปัญหาแบบนี้มีมานานแล้ว ตัวอย่างชัดคือ dependency hell
      ฉันคิดว่า LLM อาจช่วยลดความซับซ้อนแบบนี้ลงได้ด้วยซ้ำ ฉันชอบ abstraction ที่พอดี แต่ไม่ชอบการไม่รู้อะไรเกี่ยวกับข้างในเลย

  • บทความนี้พูดถึงปรากฏการณ์ที่ผู้คนใช้ abstraction โดยไม่รู้ว่าข้างในทำงานอย่างไร
    แต่นั่นก็เป็นพัฒนาการตามธรรมชาติอยู่แล้ว เพราะมีใครบางคนออกแบบ abstraction นั้นขึ้นมา และทำให้ชั้นบนใช้งานได้
    ตรรกะแบบ "ฉันไม่รู้เรื่อง Wi‑Fi driver ดังนั้นฉันก็ไม่จำเป็นต้องรู้โค้ด" ใช้ไม่ได้

    • ปัญหาคือ ตอนนี้คนส่วนใหญ่อาจเสี่ยงที่จะสูญเสีย ความสามารถในการสร้าง abstraction ใหม่
      เมื่อก่อนเราพัฒนาวิธีคิดด้วยการรับมือกับ "ความซับซ้อนที่จำเป็น" โดยตรง แต่ตอนนี้หลายครั้งกลับกลายเป็นแค่ตัวเชื่อมท่อเท่านั้น
    • โค้ดที่ LLM สร้างมามักยืดยาวเกินไปจนใช้เวลาตรวจทานนานขึ้น
      ทางแก้คือห่อ abstraction ด้วย DSL (ภาษาเฉพาะโดเมน) แทนการใช้ภาษาทั่วไป ถ้าเป็น SaaS ฉันมองว่าแนวทาง DSL-first ดีกว่า API-first
    • จริง ๆ แล้ววัฒนธรรมแบบ Clean Code และ OOP ก็เคยทำให้เกิดการสูญเสียประสิทธิภาพจาก abstraction ที่มากเกินไปมาแล้ว
      ฉันไม่คิดว่า AI จะแย่ไปกว่านั้น สิ่งสำคัญคือการเข้าใจ abstraction ที่ตัวเองใช้เป็นฐาน

  • dependency tree ต่างหากที่สร้างปัญหาใหญ่ที่สุด
    แค่ดูโปรเจกต์ Node.js ก็มีแพ็กเกจที่พึ่งพากันเป็นร้อย ส่วนใหญ่ไม่ต้องรู้ภายในก็ได้ แต่ถ้าอินเทอร์เฟซพังบ่อยก็จะเริ่มอันตราย
    หลายทีมไม่ได้ติดตาม EOL (สิ้นสุดการสนับสนุน) หรือช่องโหว่ด้วยซ้ำ ความจริงคือบ่อยครั้งเราไม่รู้เลยว่า "ของนี้ยังมีการดูแลอยู่ไหม?"

    • ทางที่ดีควรเฝ้าดูปัญหาเหล่านี้ด้วย เครื่องมือ SBOM/SCA
      แต่ถึงก่อนยุค AI ก็มีโปรเจกต์จำนวนมากที่จมอยู่กับ dependency hell จากการชนกันของเวอร์ชันอยู่แล้ว

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

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

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

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

    • ในอดีต แม้ระบบจะซับซ้อน ก็ยังมีคนที่รู้แต่ละส่วนอยู่
      ตอนนี้สิ่งที่อันตรายจริง ๆ คือการมี เศษโค้ดที่ไม่มีใครรู้ว่ามันทำงานอย่างไร

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

    • แต่ LLM ไม่ได้ "รู้" มันแค่ สร้างสิ่งที่ดูน่าเชื่อถือ เท่านั้น
      มันแทนเอกสารจริงไม่ได้ เพียงแต่มีประโยชน์มากในแบบเดียวกับมนุษย์ คือช่วยบอกได้ว่า "ควรไปค้นอะไรต่อ"

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

  • ฉันไม่ได้รู้ภายในของคอมพิวเตอร์ทั้งหมด แต่ฉันแก้ปัญหาด้วย การทำสคริปต์อัตโนมัติในทางปฏิบัติ
    ต่อให้ไม่เคยเรียน x86 assembly ก็ยังบริหารโครงสร้างพื้นฐานด้วย Python ได้
    แต่ฉันคิดว่านักพัฒนาที่มีประสบการณ์มี หน้าที่ต้องถ่ายทอด ความรู้นั้น และฉันเองก็อยากรับช่วงบทบาทนั้นในสักวัน

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

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

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