หอคอยที่เต็มไปด้วยข้อบกพร่อง อาการเมาไวบ์ และไวบ์บ็อบสเลด

• เมื่อวิธีพัฒนาที่ให้ LLM ตีความโค้ดซ้ำอีกทีแพร่หลายขึ้น แม้มนุษย์จะไม่เข้าใจโค้ดที่ LLM สร้างขึ้นก็ตาม เส้นแบ่งระหว่าง agentic engineering กับ vibe coding ที่เคยแยกกันก็พร่าเลือนอย่างรวดเร็ว
• vibe bobsled หมายถึงเส้นทางที่ถูกกำหนดไว้แล้ว ตั้งแต่ autocomplete ไปสู่การสร้างโค้ด การเลิกรีวิว และการเลิกเขียนพรอมป์ ยิ่งใช้ประโยชน์จากความเร็วในการสร้างมากเท่าไร ก็ยิ่งห่างจากบทบาทหลักของโปรแกรมเมอร์อย่างการสร้างทฤษฎีและการตรวจทานมากขึ้นเท่านั้น
• ในการทดลอง Pvote ผู้เชี่ยวชาญด้านความปลอดภัยรู้ตำแหน่งล่วงหน้าและใช้เวลาตรวจทาน โค้ด 100 บรรทัด ราว 20 ชั่วโมง แต่ก็ยังไม่พบบั๊กที่ยากในบรรดาบั๊กสามตัว แสดงให้เห็นว่าสมมติฐานที่ว่ามนุษย์จะตรวจทานเอาต์พุตปริมาณมหาศาลของ LLM ได้ครบถ้วนนั้นไม่สมจริง
• vibe sickness กำลังแพร่กระจาย เมื่อโค้ดและผลงานที่ไม่มีใครเข้าใจแทรกซึมไปถึงโปสเตอร์ร้านอาหาร แชตบอตฝ่ายสนับสนุนลูกค้า โค้ดยืนยันอายุ ไปจนถึง issue และ PR ของโอเพนซอร์ส และแม้แต่คนที่ไม่ใช้เครื่องมือเหล่านี้ก็ได้รับผลกระทบเพราะต้องตรวจทานผลงานที่คนอื่นสร้างขึ้น
• Generative AI อาจมีประโยชน์ในการค้นหาปัญหา แต่เปราะบางเป็นพิเศษเมื่อนำไปใช้สร้างสิ่งต่าง ๆ และแม้โลกกำลังถูกแทนที่ด้วยระบบที่เข้าใจไม่ได้ มนุษย์ก็ไม่ควรยอมละทิ้งความสามารถในการสร้างสภาพแวดล้อมที่ดีกว่าด้วยตนเอง

---

หอคอยของโค้ดที่เข้าใจไม่ได้

• The Tower Keeps Rising สังเกตเห็นสภาพที่แม้ในสถานการณ์ซึ่งในอดีตต้องคุยกันในทีมถึงจะแก้ได้ ตอนนี้ก็ยังเดินหน้าต่อได้ด้วยการใช้เอเจนต์
  • Armin ไม่ได้ตัดสินว่านี่เป็นเรื่องดีหรือไม่ดี และไม่ได้ปกป้องว่ามันเป็นสภาพที่ยั่งยืน
  • เพียงแต่เขาอยู่ในตำแหน่งที่ขับเคลื่อนกระแสนี้ในฐานะผู้ดำเนินบริษัทด้าน vibe coding
• ระบบ vibe coding อาจค่อย ๆ ซ้อนโค้ดและ abstraction ขึ้นไปเรื่อย ๆ จนท้ายที่สุดไปถึงสภาพที่ ไม่มีมนุษย์คนใดเข้าใจ codebase ได้
  • เกิดวิธีปฏิบัติงานแบบใหม่ที่ยังพัฒนาต่อได้ เพราะแม้ส่วนที่มนุษย์ไม่เข้าใจ LLM ก็จะช่วยตีความให้อีกครั้ง
• แม้ฝ่ายที่สนับสนุนก็ยอมรับจุดหมายปลายทางที่มนุษย์ไม่เข้าใจระบบ และเริ่มมีการเปลี่ยนแปลงที่ยอมรับสภาพนั้นเป็นวิธีพัฒนาในอนาคต

การพังทลายของเส้นแบ่งระหว่าง agentic engineering กับ vibe coding

• Simon Willison แยก agentic engineering ออกจาก vibe coding อย่างชัดเจนในตอนแรก
  • ในบทความเดือนมีนาคม 2025 เขาวางหลักการไว้ว่า หากเป็นการเขียนโปรแกรมด้วย AI ช่วยในระดับคุณภาพ production ก็ต้องอ่านโค้ดทุกชิ้นที่ commit เข้า repository และอธิบายให้ผู้อื่นเข้าใจได้อย่างถูกต้อง
  • เขาแยกแยะว่า แม้เป็นโค้ดที่ LLM เขียน หากมนุษย์ตรวจทาน ทดสอบอย่างถี่ถ้วน และอธิบายวิธีทำงานได้ นั่นไม่ใช่ vibe coding แต่คือการพัฒนาซอฟต์แวร์
• ราวหนึ่งปีต่อมา ใน Vibe coding and agentic engineering are getting closer than I’d like เขาระบุว่าเมื่อความน่าเชื่อถือของ coding agent สูงขึ้น แม้แต่โค้ด production ก็ไม่ได้ตรวจทานทุกบรรทัดแล้ว
  • เขาเชื่อว่า Claude Code จะสร้าง API endpoint ที่รัน SQL query และส่งคืน JSON ได้ถูกต้อง รวมถึงเพิ่มเทสต์และเอกสารให้ด้วย
  • ขณะเดียวกันก็รู้สึกผิดและตั้งคำถามว่า การใช้โค้ดที่ไม่ได้ตรวจทานใน production นั้นรับผิดชอบพอหรือไม่
• ช่องว่างระหว่างสองจุดยืนนี้มีเพียง มากกว่าหนึ่งปีเล็กน้อย เท่านั้น
• แม้ความรับรู้ว่า agentic engineering คือวิธีใช้งานที่พึงประสงค์จะแพร่หลาย แต่ผู้ใช้จริง รวมถึง Simon เอง กลับมีแนวโน้มถูกดึงไปทาง vibe coding

vibe bobsled

• บ็อบสเลดเป็นกีฬาที่ไหลลงลู่แข็งด้วยความเร็วสูง แต่ทิศทางที่จะไปได้นั้นแทบมีเพียงทางเดียว
  • ผู้เล่นอาจแข่งทักษะกันและรู้สึกตื่นเต้นได้ แต่ผู้โดยสารมีพื้นที่เลือกเส้นทางเองไม่มากนัก
• ใน vibe bobsled นั้น LLM คือพาหนะ ส่วนผู้ใช้คือผู้โดยสาร
  • อำนาจควบคุมจริงมีน้อยกว่าที่ผู้ใช้รู้สึกมาก และมันใกล้เคียงกับเส้นทางที่ถูกสร้างไว้ล่วงหน้ามากกว่าจะเป็นแค่ทางลาดลื่น ๆ
• นักพัฒนาค่อย ๆ เอาตัวเองออกจากกระบวนการผลิตโค้ดผ่านขั้นตอนต่อไปนี้
  • ตอนแรกคิดว่าใช้เป็นแค่ autocomplete ขั้นสูง
  • ต่อมารันเอเจนต์เพื่อสำรวจไอเดีย แต่บอกว่าจะเขียนโค้ดเอง
  • ถัดมาปล่อยให้เอเจนต์สร้างโค้ด แต่ตั้งใจว่าจะตรวจทานผลลัพธ์ทั้งหมด
  • ไม่นานก็แทบไม่ตรวจทานโค้ด และเริ่มเชื่อว่าเอเจนต์อาจเป็นนักพัฒนาที่ดีกว่าตนเอง
  • สุดท้ายอาจมุ่งไปสู่ขั้นที่ไม่ใช่แค่ “ไม่เขียนโค้ดอีกแล้ว” แต่ถึงขั้น “ไม่เขียนพรอมป์อีกแล้ว”
• แต่ละขั้นคือกระบวนการย้ายไปสู่ การผลิตโค้ดบนฐานความเชื่อใจ ว่า LLM เข้าใจงานของตนและจัดการได้ดี

ความเร็วในการสร้างปะทะกับการตรวจทาน

• ส่วนที่ช้าในการเขียนโค้ดไม่ใช่การสร้าง แต่คือ การสร้างทฤษฎีและการตรวจทาน และผลลัพธ์ที่ดูน่าเชื่อแต่ผิดนั้น debug และทำความเข้าใจได้ยากมาก
• คุณสมบัติที่ทรงพลังที่สุดของ LLM คือความเร็วในการสร้าง ดังนั้นหากมนุษย์ตรวจทานผลลัพธ์ทั้งหมด ก็ยากจะใช้ประโยชน์จากความเร็วนั้นได้เต็มที่
• ในทางกลับกัน การสร้างทฤษฎีและการตรวจทานคือบทบาทที่สำคัญที่สุดของโปรแกรมเมอร์ จึงเกิดความขัดแย้งว่า ยิ่งเพิ่มข้อดีของ LLM ให้ถึงขีดสุด ก็ยิ่งห่างจากบทบาทหลักมากขึ้น
• งานวิจัยของ Ka-Ping Yee เรื่อง Building Reliable Voting Machine Software ระบุปัจจัยสี่ข้อที่ทำให้การตรวจสอบซอฟต์แวร์ทำได้ยาก
  • จำนวนขององค์ประกอบ
  • ปฏิสัมพันธ์ที่ซับซ้อน
  • ผลกระทบที่กว้างขวาง
  • ความไม่เป็นเชิงเส้น
• ปัญหาทั้งสี่ข้อนี้อาจรุนแรงขึ้นจากวิธีที่ LLM สร้างโค้ด

การทดลองตรวจทานบั๊กของ Pvote

• Ka-Ping Yee และ David Wagner ใส่บั๊กระดับง่าย กลาง และยากอย่างละหนึ่งตัวลงในเครื่องลงคะแนนต้นแบบ Pvote ซึ่งอาจถูกใช้ในทางที่ผิดเพื่อเปลี่ยนผลการเลือกตั้งได้
• บั๊กทั้งสามถูกวางไว้ใน ช่วง 100 บรรทัด คือบรรทัดที่ 11–109 ของ Navigator.py
  • เป็นส่วนที่น่าสนใจในเชิงตรรกะของโปรแกรม และเป็นการเลือกโดยคำนึงถึงเวลาตรวจทานที่จำกัดของผู้ตรวจ
  • ผู้ตรวจทานได้รับแจ้งว่าควรดูบริเวณใด แต่ไม่ได้บอกว่ามีบั๊กกี่ตัว
• ผลการตรวจทานในวันที่สามเป็นดังนี้
  • Dan Sandler ซึ่งคุ้นเคยกับ Python มาก พบทั้งบั๊กง่ายและบั๊กระดับกลางภายในราว 70 นาที
  • Yoshi Kohno และ Mark Miller พบบั๊กง่ายหลังจากราว 4 ชั่วโมง
  • ไม่มีใครพบบั๊กยาก
• วันที่สี่ Ian Goldberg พบบั๊กง่ายภายในราว 2 ชั่วโมง แต่ไม่พบบั๊กอื่น
• ผู้เชี่ยวชาญด้านความปลอดภัยที่มีทักษะสูงรู้แม้กระทั่งตำแหน่ง แต่แม้ทุ่มเวลาไปทั้งหมด ราว 20 ชั่วโมง-ผู้ตรวจทาน ก็ยังไม่พบบั๊กครบทั้งสามตัว
• Mark S. Miller รู้สึกประหลาดใจในภายหลังเมื่อได้ดูบั๊กแล้ว ทุกคนเห็นตรงกันว่าบั๊กทั้งหมดชัดเจนและพวกเขาควรจะหาเจอ
• หากแม้แต่โปรแกรมเมอร์ระดับสูงสุดยังพลาดบั๊กที่รู้แน่ว่ามีอยู่ภายใน 100 บรรทัด วิธีให้มนุษย์ตรวจทานเอาต์พุตมหาศาลของ LLM ก็เป็นสิ่งที่รับมือได้ยาก
  • สุดท้ายผู้ใช้จะเลิกตรวจทาน และค่อย ๆ เอาตัวเองออกจากกระบวนการผลิตโค้ดทีละขั้น

AI psychosis และ vibe sickness

• “AI psychosis” ถูกใช้กว้าง ๆ เพื่อหมายถึงพฤติกรรมหรือผลลัพธ์แย่ ๆ โดยรวมที่เกิดจาก generative AI แต่เดิมทีใกล้เคียงกับภาวะที่ผู้ใช้ประสบกับโรคจิตจริงและการหลุดจากความเป็นจริงแบบหลงผิด หลังมีปฏิสัมพันธ์กับแชตบอตที่ยืนยันเห็นด้วยกับผู้ใช้มากเกินไป
• สำหรับความไม่สบายใจในวงกว้างที่เกิดจาก generative AI แต่ไม่ใช่โรคจิตทางคลินิก คำว่า vibe sickness เหมาะสมกว่า
• ในบันทึกหลังงาน PyCon US 2026 ของ Glyph มีสถานการณ์ต่อไปนี้ปรากฏพร้อมกัน
  • vibe sickness ในวงกว้าง
  • วิกฤตความยั่งยืนขนาดใหญ่ของโอเพนซอร์ส
  • PR ด้านความปลอดภัยคุณภาพต่ำที่ทะลักเข้ามา
  • ความหวัง พลังงาน และความพยายามเพื่อความเข้าใจร่วมกัน รวมถึงความขอบคุณต่องานที่ทำ

ผลงานที่แพร่ไปในชีวิตประจำวันและโอเพนซอร์ส

• ผู้คนบ่นถึง slop หรือผลงานคุณภาพต่ำที่สร้างขึ้นมา แต่ผู้ใช้ generative AI ไม่เรียกผลลัพธ์ของตนเองว่า slop
• ผลงานที่ดูน่าเชื่อแต่เข้าใจไม่ได้ปรากฏอยู่ทั่วชีวิตประจำวัน
  • โปสเตอร์ร้านอาหารท้องถิ่นที่ออกแบบเข้าใจยาก
  • แชตบอตฝ่ายสนับสนุนลูกค้าที่ทำให้ผู้ใช้หงุดหงิด
  • โค้ดยืนยันอายุ
  • issue และ PR คุณภาพต่ำที่ส่งเข้าโปรเจกต์โอเพนซอร์ส
• เครื่องมือเหล่านี้มีประโยชน์กับงานบางอย่าง และสำหรับ การค้นหาปัญหา ก็อาจมีพื้นที่ให้ประเมินต่างออกไป
• แต่การสร้าง ซึ่งถูกเน้นอยู่ในชื่อ “genAI” กลับเป็นส่วนที่เครื่องมือทำได้แย่ที่สุด
  • ไม่ใช่แค่คุณภาพของผลงานเท่านั้น แต่ยังเกิดปัญหาที่ไม่มีใครเข้าใจวิธีสร้าง โครงสร้าง และการบำรุงรักษาระบบด้วย

สภาพแวดล้อมที่หลีกหนี generative AI ไม่ได้

• แม้จะไม่ได้ใช้ generative AI โดยตรง เพื่อนร่วมงานหรือผู้มีส่วนร่วมในโอเพนซอร์สก็อาจส่งผลงานที่ตัวเองยังไม่เข้าใจมาในฐานะ “contribution”
  • ผู้ตรวจทานต้องลังเลว่าการถามว่าเป็นผลงานจาก LLM หรือไม่นั้นเสียมารยาทหรือเปล่า
  • ระหว่างตอบ issue หรือ PR ก็จะมีปฏิสัมพันธ์กับเอเจนต์ทางอ้อม และเข้าไปมีส่วนร่วมใน workflow แบบ vibe coding โดยไม่ตั้งใจ
• Glyph เปรียบการปฏิเสธซอฟต์แวร์ทั้งหมดที่มี LLM อยู่ในนั้นกับการกลั้นหายใจเพื่อประท้วงการนำเชื้อเพลิงผสมเอทานอลมาใช้กับรถยนต์ จนกว่าทุกคนจะหยุดใช้
  • ในทางปฏิบัติอาจจำเป็นต้องยอมรับในระดับหนึ่งและกำหนดเส้นจริยธรรมส่วนตัว แต่ไม่ได้หมายความว่านั่นคือความคาดหวังหรือความตื่นเต้นต่อสภาพแวดล้อมของ generative AI
• uncanny valley กำลังยึดครองโลกจริง และระบบที่ไม่มีใครเข้าใจกำลังแทนที่โลกเดิม
• ยังไม่รู้ว่าต้นทุนที่ต้องจ่ายเมื่อฟื้นตัวจากสภาพนี้จะเป็นเท่าไร และโปรเจกต์ที่เลือกไม่เข้าร่วมกับ generative AI ในปัจจุบันก็ควรได้รับความเคารพ

ทางเลือกในการสร้างภูมิประเทศที่ดีกว่า

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

[GN⁺]

ความคิดเห็นจาก Lobste.rs

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

• เมื่อราว 1 ปีก่อน วิศวกรรมแบบ agentic ยังถูกมองว่าเป็นทิศทางที่พึงประสงค์ แต่ดูเหมือนว่าผู้ใช้เครื่องมือจริงส่วนใหญ่ แม้จะไม่ค่อยอยากยอมรับ ก็เอนเอียงไปทาง vibe coding กันมากกว่า ความกลัวว่า LLM อาจทำให้ทักษะและความผูกพันของผมไร้ค่าลดลงมาก หลังจากตั้งหลักไว้ 2 ข้อ
  ข้อแรก ในเวลาว่างจะไม่ใช้ LLM หรือ coding agent และปฏิเสธฟีเจอร์ AI ในการค้นหาด้วย จะยอมรับความเสี่ยงเรื่อง hallucination และใช้มันก็ต่อเมื่อจนปัญญาจริง ๆ และจำเป็นมากเท่านั้น การเมินเทคโนโลยีไม่ได้ทำให้โลกแก้ปัญหาเองได้ แต่ในเมื่อเราทำอะไรกับการโจมตีนักพัฒนารายบุคคลหรือเปลี่ยนบริษัทยักษ์ใหญ่ไม่ได้ การไม่ให้มันล้ำเข้ามาถึงเวลาว่างก็เป็นทางเลือกที่พอทำได้ในทางปฏิบัติ
  ข้อสอง แม้ในที่ทำงานที่สนับสนุนให้ใช้ AI อย่างมาก ก็จะใช้มันแค่กับ code review และงานจิปาถะ เท่านั้น คือถามเรื่องที่หาได้จาก codebase โดยตรงแต่ค้นเองยุ่งยาก ส่วนโค้ดทั้งหมดเขียนเอง แบบนั้นถึงจะเข้าใจกลไกการทำงานได้จากสัญชาตญาณ และทำงานได้ในระดับที่ตัวเองกับเพื่อนร่วมงานคาดหวัง
  LLM พอใช้เป็นเครื่องมือเสริมในการจับข้อผิดพลาดเชิงรูปแบบที่ linter แบบ deterministic หาไม่เจอได้ มันก็ยังตอบมั่วเหมือนกัน แต่เพราะผมเขียนและเข้าใจโค้ดเองจึงไม่เชื่อมันแบบสนิทใจ ถ้ามันช่วยกรองตรรกะผิดชัด ๆ และสมมติฐานที่ผิดออกไปก่อนถึงการรีวิวโดยคน เพื่อนร่วมงานก็จะเอาเวลาไปโฟกัสส่วนที่ซับซ้อนกว่าได้ และยังเลี่ยงความเสียมารยาทแบบปล่อยให้เครื่องคุยกับเครื่องแทนคนในช่องทางสาธารณะได้ด้วย
  ช่วงหลังบริษัทเริ่มจำกัดการใช้โทเคนอย่างเข้มงวด แต่ workflow นี้มีค่าใช้จ่ายแค่วันละ 1–2 ยูโร เลยไม่ได้กังวลอะไร คนที่เคยพึ่งสัญชาตญาณล้วน ๆ อาจรู้สึกไม่มั่นคงเมื่อพบว่าต้องกลับมาใช้การให้เหตุผลของมนุษย์อีกครั้ง แต่ที่เหลือก็แค่ทำมันร่วมกับเพื่อนร่วมงานโดยตรง

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

• ติดใจมากเกินไปที่ตรงนี้สะกด Fawlty ผิด

  • น่าจะจงใจเขียนแบบนั้นเพื่อเล่นคำกับหอคอยบาเบลที่ “ก่อปัญหา” ซึ่งเป็น มุกเล่นคำ

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

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

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

• “อุปมาแบบบ็อบสเลด” เป็นที่รู้จักกันดีกว่าในชื่อข้อผิดพลาดทางตรรกะแบบ slippery slope เมื่อ 1 ปีก่อน สัดส่วนของ vibe coding ยังเป็น 0% และ Simon Willison ก็เผยแพร่บทความหลายชิ้นเกี่ยวกับกระบวนการค่อย ๆ นำ coding agent มาใช้ด้วยความระมัดระวัง พร้อมเพิ่มระดับความเชื่อถือทีละน้อย
  แต่กลับใช้สิ่งนั้นเป็นหลักฐานเพื่อฟันธงว่า “มีทางไปอยู่ทางเดียว” ผมคิดว่าการมองว่า Willison และผู้ใช้อีกหลายคนก็มีรสนิยมและวิจารณญาณของตัวเองด้วย น่าจะสมเหตุสมผลกว่า