GDD - ยุคของ "การพัฒนาแบบ Gaslight-driven"

 (tonsky.me)
12 คะแนน โดย GN⁺ 2025-07-21 | 6 ความคิดเห็น | แชร์ทาง WhatsApp
  • ช่วงหลังมานี้ ผู้ใช้คอมพิวเตอร์ต้องทำ งานที่ไร้ความหมาย จำนวนมากซ้ำ ๆ โดยไม่เกี่ยวกับความตั้งใจของตัวเอง และทำตามที่คอมพิวเตอร์สั่ง
  • LLM เริ่ม ส่งอิทธิพลต่อวิธีการออกแบบ API ของนักพัฒนา และมีการคาดการณ์ว่าในไม่ช้า AI จะเป็นผู้เขียนโค้ดส่วนใหญ่ ขณะที่นักพัฒนายอมรับฟีเจอร์ที่ AI เสนอจริง
  • ตัวอย่างเช่น Soundslice ได้เพิ่มฟีเจอร์ที่ ChatGPT แนะนำผิดพลาดเข้าไปจริง
  • นั่นเป็นเพราะ LLM วิเคราะห์ API จำนวนมากและเสนอ การออกแบบที่เข้าใจได้โดยสัญชาตญาณ ซึ่งนักพัฒนาน่าจะนึกถึงเป็นอันดับแรก
  • เมื่อพัฒนาไอเดียใหม่หรือแนวทางที่มีเอกลักษณ์ LLM อาจไม่เหมาะนัก แต่ในกรณีส่วนใหญ่ การทำตาม การออกแบบที่ดูธรรมดาที่สุด อาจมีประสิทธิภาพกว่า
  • ตอนนี้เราได้เข้าสู่ยุคที่ AI ไม่ได้เป็นแค่ผู้นำการใช้เครื่องมือ แต่เริ่มนำวิธีออกแบบเครื่องมือด้วย

Gaslight-driven development

งานไร้ความหมายที่กลายเป็นเรื่องปกติ

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

ความเป็นจริงของการพัฒนาที่ LLM กำลังเปลี่ยน

  • ช่วงหลัง LLM เริ่มออกความเห็นแล้วว่า API หรืออินเทอร์เฟซควรมีหน้าตาอย่างไร
    • ถึงขั้นมีการคาดการณ์ว่าในเดือนกันยายน 2025 โค้ดทั้งหมด 90% จะถูกเขียนโดย AI
  • เช่นกรณีของ Soundslice [ChatGPT เข้าใจผิดว่ามีฟีเจอร์ที่ไม่มีอยู่จริง] และเมื่อมีคำขอจากลูกค้าเข้ามาเรื่อย ๆ สุดท้ายก็เพิ่มฟีเจอร์นั้นเข้าไปจริง](https://th.news.hada.io/topic?id=21873)
  • ที่ Instant ก็มีกรณีคล้ายกัน เดิมทีใช้ tx.update จัดการทั้ง insert และ update แต่เพราะ LLM สร้างโค้ดที่ใช้ tx.create อย่างต่อเนื่อง สุดท้ายจึงต้องเพิ่มเมธอด tx.create ขึ้นมา

ความหมายของปรากฏการณ์นี้

  • ยังตัดสินได้ยากว่าการเปลี่ยนแปลงนี้ เป็นผลดีหรือผลเสีย
  • ในอีกด้านหนึ่ง LLM เรียนรู้ API มาจำนวนมาก จึงมีผลในการเสนอวิธีที่ 'เข้าใจง่ายที่สุด' จากมุมมองของนักพัฒนา
  • นี่อาจเป็นวิธีใหม่ในการ ทดสอบ API จากมุมมองของมือใหม่ (newbie’s POV) ด้วย
    • แต่ก่อนถ้านักพัฒนาพลาด ก็มักจะไปเปิดเอกสารแล้วแก้เอง แต่ตอนนี้ LLM คอยยกตัวอย่างการใช้งานผิด ๆ อย่างต่อเนื่อง ทำให้ นักพัฒนารับรู้ปัญหาได้เร็วขึ้น เช่นกัน

ข้อจำกัดและสิ่งที่ต้องคิดต่อ

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

บทสรุป: จุดเริ่มต้นของยุคใหม่

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

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

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

 
ffdd270 2025-07-21

บางครั้งผมก็รู้สึกเหมือนกับว่า ในแนวคิดใหญ่เรื่องการพึ่งพาเส้นทางเดิม กำลังมีตะปูอันทรงพลังที่ชื่อว่าการพึ่งพา LLM ถูกตอกลงไป ความรู้สึกที่ว่ามันกำลังเปลี่ยนจาก 'เพราะใช้กันมาตั้งแต่ก่อน' ไปเป็น 'เพราะ LLM ชอบ' สุดท้ายแล้วมันจะลงเอยอย่างไรกันนะ...
 
kandk 2025-07-21

สิ่งที่ใช้เขียนมาตั้งแต่ก่อนหน้านี้ LLM ก็ได้เรียนรู้มันไปแล้ว..
 
jujumilk3 2025-07-21

"ตอนนี้คุณสามารถปิดเครื่องคอมพิวเตอร์ได้แล้ว"
 
rosen 2025-07-21

เปรียบเทียบได้เป๊ะมาก!!
 
GN⁺ 2025-07-21
ความเห็นจาก Hacker News
  • ลองจินตนาการดูว่าในสถานการณ์ที่ LLM แนะนำ API endpoint ที่ไม่มีอยู่จริง เราอาจยอมรับมันแล้วอุตส่าห์ไป implement endpoint นั้นขึ้นมา พร้อมตั้งใจให้มันคืนสถานะ 421: Misdirected Request ก็ได้ หรือจะใช้ 501: Not Implemented ตามจริงก็ยังได้เช่นกัน ถ้ารู้สึกว่า 501 ให้อารมณ์ไม่ตรงนัก ก็ขอเสนอ status code ใหม่คือ 513: Your Coding Assistant Is Wrong
    ดูวิกิของ HTTP status code
    • ไอเดีย 513: Your Coding Assistant Is Wrong ตลกมาก ชอบเลย อีกอย่างอยากเสนอ HTTP 407 Hallucination ด้วย หมายถึงเซิร์ฟเวอร์เข้าใจคำขอ แต่ตัดสินว่าไม่สอดคล้องกับความเป็นจริง
    • เรื่องนี้ทำให้นึกถึงป้ายเตือนขำ ๆ ที่บอกว่า GPS ผิดเหมือนกัน
      ตัวอย่าง GPS is wrong
    • ขอร่วมโหวตให้เพิ่ม status code 513 ในเมื่อมี 418 อยู่แล้ว ก็ไม่เห็นเหตุผลว่าทำไม 513 จะมีไม่ได้
    • ถ้าอยากเล่นมุกแบบนี้ ได้โปรดใช้ response 418 เถอะ อยากให้มันถูกใช้งานแพร่หลายกว่านี้
  • การได้เห็นว่ามีผู้ใช้หลายคนกำลังดูหน้าเดียวกันแบบเรียลไทม์ก็สนุกดี แต่สัญลักษณ์ผู้ใช้ที่เข้า ๆ ออก ๆ ตลอดเวลาทำให้อ่านบทความยากมาก
    • มี bookmarklet อยู่บนแถบบุ๊กมาร์กที่ใช้ลบองค์ประกอบแบบ fixed หรือ sticky พวกนี้ออกทีเดียวหมด ใช้แล้วองค์ประกอบที่ตรึงอยู่ด้านบนของหน้าจะหายไปและการเลื่อนหน้าก็กลับมา จึงใช้บ่อยมาก
      (มีโค้ด JavaScript ให้)
    • ฉันก็รำคาญคล้ายกัน เลยคลิกขวาแล้วเลือก Inspect เพื่อเปิด developer tools จากนั้นวางโค้ดด้านล่างลงในคอนโซล ก็จะลบส่วนแสดงผู้ใช้นั้นออกได้ 
      document.getElementById("presence")?.remove();
      ถ้าสงสัยว่าสมองเราทำไมถึงไวต่อการเคลื่อนไหวแบบนี้นัก มันเกี่ยวข้องกับสัญชาตญาณการตรวจจับผู้ล่า
      ลิงก์งานวิจัยวิทยาศาสตร์, ดูวิกิประสาทวิทยา
    • ทำให้นึกถึงเกมชื่อ Chess Royale เคยมีประสบการณ์คล้ายกันกับอวาตาร์และธง แม้จะเป็นเกมที่ทำออกมาดีมาก แต่ Ubisoft ก็ปิดบริการมันไปตามสไตล์ที่ชอบทำบ่อย ๆ น่าเสียดายสำหรับเกมดี ๆ แบบนี้
      ภาพหน้าจอ Chess Royale
    • เหมือนจะเป็นหน้าเว็บที่เมื่อก่อนมีเคอร์เซอร์เต็มพื้นหลังหรือเปล่า ระดับนี้รู้สึกเหมือนเป็นคอนเซปต์การออกแบบที่ตั้งใจทำให้วุ่นวายเพื่อเล่นมุก
    • เคยลองใช้เครื่องมืออย่าง uBlock เพื่อลบองค์ประกอบบนหน้า แต่เจอสถานการณ์ที่ต้องทำซ้ำเร็ว ๆ เหมือนเล่นเกมตีตัวตุ่น
  • ใน Instant นั้นฟังก์ชัน tx.update ถูกทำให้รองรับทั้งการแทรกและการอัปเดต entity แต่ LLM ก็ยังเขียนโค้ด tx.create อยู่เรื่อย ๆ สุดท้ายเลยต้องสร้างฟังก์ชัน tx.create ขึ้นมาด้วย เลยคิดว่าจุดสับสนแบบนี้อาจทำให้ไม่ใช่แค่ LLM แต่รวมถึงนักพัฒนาจริง ๆ เสียเวลาโดยใช่เหตุไปมากแค่ไหน
    • ก็ถ้าเดิมทีไม่มี tx.create อยู่แล้ว จะมีใครเสียเวลาไปกับมันได้อย่างไรล่ะ
  • ถ้าเป็นฟังก์ชันที่รองรับทั้ง insert และ update ก็ควรตั้งชื่อว่า put มากกว่า update เพราะคำว่า update ชวนให้เข้าใจผิดได้
    • ในกรณีนั้นดูเหมือนว่า upsert จะเหมาะกว่า
    • ชื่อ put สื่อถึงการเขียนทับข้อมูลเดิม ขณะที่ upsert หมายถึงทั้ง insert/update ได้ครบกว่า
  • แค่เพราะ LLM พ่นข้อความผิดออกมา ก็เหมือนว่าจักรวาลจะเข้าสู่ภาวะความตายเชิงความร้อนก่อนที่ฉันจะยอมแก้โค้ดแม้แต่บรรทัดเดียว ความคิดที่ว่าต้องเปลี่ยนโค้ดด้วยเหตุผลไร้สาระแบบนี้ สำหรับฉันทั้งขำและรับไม่ได้
  • ไม่เห็นด้วยกับข้ออ้างของโพสต์นี้ ตั้งแต่จุดตั้งต้นที่ถามว่าเราจำเป็นต้องทำตามสิ่งที่คอมพิวเตอร์ต้องการจริงหรือไม่ก็ยังน่าสงสัย
    ฉันคิดว่าเหตุที่ผู้ใช้ต้องยืนยันอีเมลหรือสมัครสมาชิก ก็ไม่ใช่เพราะคอมพิวเตอร์สั่ง แต่เป็นตัวเลือกด้านการออกแบบของมนุษย์ต่างหาก
    • การเรียกสิ่งนี้ว่าเป็น “thesis” ก็ดูตีความกันอย่างใจกว้างเกินไป สำหรับฉันอ่านถึงตรงนั้นก็ปิดหน้าไปเลย
  • ไม่นานมานี้ฉันคุยกับทีมอย่างสนุกเกี่ยวกับหลักการเขียนโค้ดในอนาคต
    ต่อไปนี้ แทนที่จะโฟกัสที่ความอ่านง่ายของโค้ด หลักการ SOLID หรือความซับซ้อน สิ่งที่สำคัญกว่าน่าจะเป็นว่า agentic IDE ที่ฉันใช้สามารถทำดัชนีบริบทของโค้ดได้ดีแค่ไหน และโมเดลสามารถสร้างโค้ดจากฐานนั้นได้ดีเพียงใด
    เมื่อความเร็วในการเปลี่ยนโค้ดสูงขึ้นมาก ความสามารถในการบำรุงรักษาโค้ดอาจกลับกลายเป็นตัวชี้วัดหลัก และเราน่าจะได้เห็นโลกที่ผู้คนสนใจมากขึ้นกับความสอดคล้องระหว่างพรอมป์ต์กับโค้ด รวมถึงประโยชน์ใช้สอยของโค้ดที่บังเอิญเข้าที่เข้าทาง
  • ถ้ามีใครคนหนึ่งคอยกระจายคำแนะนำการพัฒนาชุดใหม่อย่างมั่นใจอยู่เรื่อย ๆ ทั้งที่จริงเป็นข้อมูลเท็จ เกี่ยวกับผลิตภัณฑ์ที่ฉันสร้างขึ้น ในมุมบริษัทก็น่าสงสัยว่าจะเลือกเพิ่มฟีเจอร์ในจินตนาการนั้นเข้าไปเฉย ๆ แล้วเขียนบล็อกโพสต์งง ๆ ออกมาหรือไม่
    • ฉันก็สงสัยเหมือนกันว่า ถ้าฉันทำตัวแบบ LLM แล้วทำพลาดเพี้ยน ๆ แต่ยังยืนยันอย่างมั่นใจ คนอื่นจะเข้าใจให้เฉย ๆ ไหม
    • พอมาคิดดู ผู้เขียน “Clean Code” อย่าง Mr Martin ก็เหมือนจะเป็นสไตล์นี้ไม่ใช่หรือ
    • ถ้าคนคนนั้นมีอิทธิพลต่อ 90% ของลูกค้าฉัน ก็คงเป็นไปได้จริง ๆ ว่าฉันจะใส่ฟีเจอร์ในจินตนาการนั้นเข้าไป
    • บริษัทส่วนใหญ่คงจะยืนกรานอย่างมั่นใจว่าฟีเจอร์ที่ไม่จำเป็นนั้นจำเป็นจริง ๆ
  • มันก็ให้ความรู้สึกเหมือนเป็นจุดเริ่มต้นของมิตรภาพอันงดงามกับ LLM เหมือนกัน ตอนทำงานเป็น fractional CTO สิ่งที่น่าหงุดหงิดที่สุดคือ แม้แต่ naming convention เล็ก ๆ น้อย ๆ อย่างชื่อ environment ก็แตกต่างกันไปในแต่ละลูกค้า
    เช่น ฝั่ง AWS ใช้ “dev” กับ “prod” แต่ฝั่ง Expo ใช้ “test” กับ “production” ทำให้พอต้องสลับไปมาหลายโปรเจกต์ ก็ใช้พลังสมองมากกว่าที่คิด
    คิดว่า LLM เองก็คงเจอปัญหาแบบนี้ในสเกลที่ใหญ่กว่ามาก
    ถ้าเราสามารถเอาไซแนปส์ในสมองที่เดิมต้องเสียไปกับความสับสนไร้ประโยชน์เรื่องชื่อและพฤติกรรมของ API ไปใช้กับสิ่งที่มีความหมายจริง ๆ ได้ ก็คงดีที่สุด
    • มีมุกในวิทยาการคอมพิวเตอร์ที่บอกว่ามีปัญหายากอยู่สามอย่าง—การทำ cache invalidation, การตั้งชื่อ, และ off-by-one error
      ไม่ว่า LLM จะฉลาดในการตั้งชื่อแค่ไหน ปัญหาก็ยังอยู่ เพราะมันตั้งอยู่บน incoherent stochastic process
      แล้วก็อยากถามจริงจังว่าเคยตั้งคำถามไหมว่าทำไมการตั้งชื่อ environment ถึงไม่เป็นมาตรฐานเดียวกัน
      ในฐานะอดีต CTO ฉันมองว่าสิ่งแบบนี้เป็นสัญญาณว่าการสื่อสารในองค์กรหรือมาตรฐานภายในยังต้องปรับปรุง
      เพราะมันเป็นเรื่องที่แก้ได้ไม่ยากและช่วยยกระดับวัฒนธรรมการทำงานรวมถึงความตระหนักของทีมได้จริง จึงอยากบอกว่าเรื่องแบบนี้ไม่ควรโยนให้ LLM จัดการ แต่ควรลงมือดูแลด้วยตัวเองมากกว่า
  • ลิงก์ที่เกี่ยวข้อง
    ดูการถกเถียงก่อนหน้าบน Hacker News
 
dkmin 2025-07-21

ความสำเร็จแบบไวรัลของ Soundslice