ตอนนี้ผมเชื่อว่าหลายบริษัทกำลังตกอยู่ในภาวะคลั่งหมู่เรื่อง AI

 (twitter.com/mitchellh)
4 คะแนน โดย GN⁺ 3 시간 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • Mitchell Hashimoto: "ตอนนี้หลายบริษัทกำลังตกอยู่ในภาวะคลั่งหมู่เรื่อง AI อย่างรุนแรง และเป็นไปไม่ได้ที่จะสนทนาอย่างมีเหตุผลกับพวกเขา"
  • ข้อถกเถียงเรื่อง MTBF vs MTTR จากยุคของระบบอัตโนมัติโครงสร้างพื้นฐานบนคลาวด์ กำลังลุกลามมาสู่อุตสาหกรรมพัฒนาซอฟต์แวร์ทั้งหมด และความศรัทธาแบบงมงายใน AI agent ก็กำลังก่อให้เกิดความคลั่งหมู่รูปแบบใหม่
  • แนวคิดแบบยึด MTTR เป็นคำตอบสารพัดประโยชน์กำลังแพร่หลาย เช่น "agent จะแก้บั๊กได้เร็ว งั้น ปล่อยบั๊กออกไปก็ไม่เป็นไร" ซึ่งเป็นวิธีคิดที่พิสูจน์แล้วว่าล้มเหลวตั้งแต่ยุคอินฟราฯ
  • ระบบอาจ ดูเหมือนยังแข็งแรงเมื่อวัดจากตัวชี้วัดเฉพาะจุด แต่ในภาพรวมกลับกลายเป็นสิ่งที่ไม่อาจทำความเข้าใจได้ และการที่รายงานบั๊กลดลงหรือ test coverage เพิ่มขึ้นก็ไม่ได้รับประกันความปลอดภัยจริง
  • เมื่อยกประเด็นนี้ขึ้นมา ก็มักจะถูก โต้กลับทันที ด้วยคำพูดอย่าง "test coverage 100%" หรือ "รายงานบั๊กกำลังลดลง" จนบทสนทนาถูกปิดกั้น และไม่มีใครมองเห็นภาพรวม
  • การเปลี่ยนแปลงเกิดขึ้นเร็วเกินไป จนไม่มีใครสังเกตเห็น การผุกร่อนของสถาปัตยกรรมฐานราก ขณะที่เรากำลังสร้าง "เครื่องจักรหายนะที่ฟื้นตัวได้" แบบอัตโนมัติ

ข้ออ้างหลัก: ภาวะคลั่งหมู่เรื่อง AI (AI Psychosis)

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

บทเรียนจากยุคอินฟราฯ: MTBF vs MTTR

  • ข้อถกเถียงเรื่อง MTBF (เวลาเฉลี่ยระหว่างความขัดข้อง) vs MTTR (เวลาเฉลี่ยในการกู้คืน) ที่เคยเกิดขึ้นในช่วงเปลี่ยนผ่านสู่คลาวด์และระบบอัตโนมัติบนคลาวด์ กำลังหวนกลับมาอีกครั้ง
  • ตอนนั้นประเด็นนี้ยังจำกัดอยู่ในโลกของอินฟราฯ แต่ตอนนี้ได้ขยายไปสู่ อุตสาหกรรมพัฒนาซอฟต์แวร์ทั้งหมด (และกว้างไปถึงทั้งโลก)
  • กลุ่มที่เชื่อ AI แบบสุดโต่งขับเคลื่อนด้วยแนวคิดที่เกือบจะเป็นคำตอบตายตัวว่า "มี MTTR ก็พอแล้ว"
    • ด้วยตรรกะว่า "agent จะแก้บั๊กได้ด้วยความเร็วและขนาดที่มนุษย์ทำไม่ได้ ดังนั้นปล่อยบั๊กออกไปก็ได้"
  • บทเรียนที่ได้จากยุคอินฟราฯ คือ MTTR นั้นยอดเยี่ยมก็จริง แต่ เราไม่อาจทิ้งระบบที่มี resilience ไปทั้งหมดได้

การปิดกั้นบทสนทนาและรูปแบบการโต้กลับ

  • เมื่อยกประเด็นนี้ขึ้นกับคนที่รู้จักเป็นการส่วนตัว ก็มักจบลงด้วยการ เมินเฉยทันที
    • เช่น "ไม่จริง test coverage เราสมบูรณ์แบบ" หรือ "รายงานบั๊กกำลังลดลง"
    • การโต้กลับแบบนี้ ไม่ได้สะท้อนภาพรวมทั้งหมด
  • เขาเคยส่งต่อความกังวลนี้โดยตรงในระดับส่วนตัวแล้ว แต่ไม่มีใครรับฟัง จึงเห็นว่าจำเป็นต้องพูดถึงในวงกว้างกว่าเดิม

เครื่องจักรหายนะแบบอัตโนมัติ

  • นี่คือบทเรียนที่เคยได้จากโลกอินฟราฯ มาแล้วครั้งหนึ่ง: ด้วยระบบอัตโนมัติ เราสามารถสร้าง "เครื่องจักรหายนะที่ฟื้นตัวได้อย่างมาก" ขึ้นมาได้
  • ระบบอาจ ดูสุขภาพดีจากตัวชี้วัดเฉพาะจุด แต่โดยรวมกลับกลายเป็นสิ่งที่ไม่มีใครเข้าใจได้อีกต่อไป
  • รายงานบั๊กลดลง แต่ ความเสี่ยงแฝงกลับพุ่งสูง
  • test coverage เพิ่มขึ้น แต่ ความเข้าใจเชิงความหมายกลับลดลง
  • การเปลี่ยนแปลงเกิดเร็วเกินไปจนไม่มีใครสังเกตเห็น การผุกร่อนของสถาปัตยกรรมฐานราก

ประเด็นจากคำตอบยอดนิยม

  • @adamhjk: "สิ่งแรกที่ vibe coding แบบล้วน ๆ ทำลายคือ ตัวสถาปัตยกรรมเอง" และตั้งแต่แรกก็ต้องมีสถาปัตยกรรมก่อน จึงจะตรวจจับการผุกร่อนได้
  • คำอธิบายเพิ่มเติมจาก Mitchell Hashimoto: ในงานอินฟราฯ เราสามารถอัปเดตระบบออนไลน์และทำให้ MTTR ใช้ได้กับผู้ใช้ทั้งหมดภายในเวลาที่สมเหตุสมผล แต่กับซอฟต์แวร์อย่าง library, desktop software, mobile app ที่คนอื่นต้องนำไป integrate หรือรันเอง วิธีนี้ใช้ไม่ได้
  • @tinygrad: เราเข้าสู่ยุคที่การตัดสินว่า AI พูดผิดทั้งหมดหรือไม่นั้น ไม่ได้ใช้เวลา 10 วินาที แต่เป็น 20 นาที และองค์กรต้องรักษาจุดยึดโยงกับความจริงเอาไว้
  • @beyang: ตอนนี้ UX ของ agent กำลังทำให้ "LGTM (Looks Good To Me)" กลายเป็นเส้นทางที่ต้านทานน้อยที่สุด และความเร็วที่ agent สร้างโค้ดซึ่งดูน่าเชื่อถือได้ กำลังยกระดับปัญหาการตรวจสอบใน code review ให้กลายเป็น ภัยคุกคามฉับพลัน
  • @beh_zod: ฟังก์ชันรางวัล ของการปล่อยของนั้นสั้นมาก ขณะที่เวลาที่ผู้คนต้องใช้เพื่อรับรู้หนี้สะสมกลับยาวเกินกว่าช่วงความสนใจของคนส่วนใหญ่
  • @shipwithjay: เมื่อผู้นำด้านวิศวกรรมไม่สามารถตอบ คำถามเชิงสวนข้อเท็จจริง (ถ้าจะหยุดสิ่งนี้ อะไรบ้างที่ต้องเป็นจริง) และเลือกเงียบ นั่นคืออาการหนึ่ง
  • @chadfowler: กำลังเขียนหนังสือเกี่ยวกับปัญหานี้ โดยแก่นสำคัญคือ ย้ายความเข้มงวด (rigor) ไปไว้ในสถาปัตยกรรมและกรอบการประเมิน และตอนนี้คือโอกาสในการลงมือทำแนวปฏิบัติที่ดีที่สุด ซึ่งที่ผ่านมาไม่เคยทำได้เพราะขาดเวลาและงบประมาณ

คำตอบของ Mitchell Hashimoto ต่อคำถามและความเห็นต่าง ๆ

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

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

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

 
GN⁺ 3 시간 전
ความเห็นจาก Hacker News

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

    • พอเห็นประโยคที่ว่า “ระบบที่ AI เขียนล้วน ๆ อาจขยายไปสู่ระดับความซับซ้อนที่มนุษย์ไม่อาจเข้าใจ...” ก็อดแซวไม่ได้ว่า ดูเหมือน AI กำลังพยายามไปให้ถึงระดับประสิทธิภาพแบบมนุษย์ในระบบซอฟต์แวร์ขนาดใหญ่และซับซ้อนจริง ๆ
    • เพื่อนที่ไม่ใช่สายเทคนิคคนหนึ่งใช้ Claude ทำ โซลูชันจัดการสต็อก แบบ vibe coding จนได้สัญญากับโรงพยาบาล
      ฝั่งโรงพยาบาลถึงขั้นให้สิทธิ์เข้าถึงเซิร์ฟเวอร์ของแผนก IT มาแล้ว แต่เขาดันไม่รู้วิธี deploy เพราะต่อ Claude เข้าไปไม่ได้ เลยติดต่อมาด้วยอาการไปไม่เป็นหนักมาก และดูเหมือนในแอปก็มีปัญหาเรื่องข้อมูล/สถานะที่น่าสนใจอยู่ด้วย
    • ความซับซ้อนแบบนั้นน่าจะเป็น ความซับซ้อนฟุ่มเฟือย ที่ไม่จำเป็น
      มันชวนให้นึกถึงคนที่สั่งของจาก Amazon มาส่งบ้านฟรีแบบไม่จำกัด ตามทฤษฎีเหมือนชีวิตอุดมสมบูรณ์ขึ้น แต่ในความจริงกลับเหมือนถูกฝังอยู่ใต้บางสิ่งที่ไม่ใช่ความรุ่งเรือง
    • ทำให้นึกถึงบทพูดในหนัง Westworld ฉบับดั้งเดิม: “พวกนี้เป็นอุปกรณ์ที่ซับซ้อนมาก... ซับซ้อนแทบพอ ๆ กับสิ่งมีชีวิต ในบางกรณีคอมพิวเตอร์เครื่องอื่นเป็นคนออกแบบมัน เราไม่รู้แน่ชัดว่ามันทำงานอย่างไร”
      และทุกคนก็คงรู้ว่าผลลัพธ์เป็นอย่างไร
    • เพิ่งเจอลูกค้าแนวนี้มาเหมือนกัน ทั้ง อินฟราสตรักเจอร์และ CI/CD ถูกทำแบบ vibe coding หมด
      เขาไปเขียน Kubernetes แบบครึ่ง ๆ กลาง ๆ ไว้ใน Github Actions ยาวหลายพันบรรทัดจนไม่มีทางเข้าใจได้
      ผมไม่ชอบการตลาด AI แต่คิดว่ามันมีประโยชน์ในฐานะเครื่องมือที่ช่วยให้คนมีประสบการณ์เดินได้เร็วขึ้น
      แต่ถ้าไม่ใช่ผู้เชี่ยวชาญ AI ดูจะชอบสร้างวิธีแก้ที่ซับซ้อนให้กับทุกอย่างที่พยายามทำ

  • ดูเหมือนเขากำลังพูดถึงปรากฏการณ์ที่บริษัทและผู้คนเอา การตัดสินใจและการคิด ไปเอาต์ซอร์สให้ AI มากกว่าการใช้ AI เอง
    การใช้ AI เขียนโค้ดไม่ใช่ AI psychosis และไม่ใช่เรื่องแย่ในตัวมันเอง แต่ถ้าแค่ใส่พรอมป์แล้วเชื่อทุกอย่างที่ AI พูด แบบนั้นน่าจะใกล้กับ AI psychosis มากกว่า
    เห็นคนการเงินกับ VC บน Twitter อยู่บ่อย ๆ ที่แทนจะคิดกับหัวข้อสักนิดด้วยตัวเอง กลับเอาสกรีนช็อตจาก ChatGPT มาแทนการคิดและการให้เหตุผล
    เครื่องมือพวกนี้ห่วยมากสำหรับไอเดีย การคิด หรือคำแนะนำ มันแค่โยนแพตเทิร์นที่ดูเหมือนแพตเทิร์นกลับมา พอคุยเรื่องไอเดียจริง ๆ ก็มักพ่นคำพูดซ้ำซากทั่วไปออกมา
    ตรงกันข้าม ในงานอย่างการเขียนโค้ดที่การจับแพตเทิร์นช่วยได้จริง มันค่อนข้างมีประโยชน์ แต่ไม่ควรเอาไปใช้แทนการคิดและการตัดสินใจ

    • เห็นด้วย ผมใช้ AI เยอะมาก และมันทำให้ผมสนุกกับการทำงานในแต่ละวันมากกว่าเดิม
      โดยรวมเพดานสูงขึ้น แต่พื้นก็ต่ำลงด้วย และคำอธิบายข้างบนนั้นแม่นมาก
      เคยเขียนเรื่องนี้ไว้ที่: https://mitchellh.com/writing/my-ai-adoption-journey, https://mitchellh.com/writing/building-block-economy, https://mitchellh.com/writing/simdutf-no-libcxx
      บทความสุดท้ายเป็นการเปลี่ยนแปลงที่ซับซ้อนซึ่งผมทำได้เพราะ AI และยังแสดงให้เห็นด้วยว่าผมเข้าใกล้มันอย่างมีเหตุผลอย่างไร
    • ผมคิดว่า AI ให้ได้ทั้ง “คำตอบที่ถูก” และ “คำตอบที่ผิด”
      มันแทบจะสร้างข้อความที่ดูสมเหตุสมผลได้เสมอ แต่ในข้อความนั้นอาจมีสมมติฐานแฝงและการตัดสินใจที่ผิด ซึ่งไม่เหมาะกับ use case นั้น ๆ
      ถ้าจะให้ได้วิธีแก้ที่ถูกจริง การนิยามปัญหา ต้องถูกต้องก่อน และนั่นอาจยากกว่าการสร้างวิธีแก้เสียอีก
    • สงสัยว่ามันต่างจากตอนที่บริษัทต่าง ๆ เคยเอาการคิดไปฝากนิตยสารอย่าง Fortune หรือ Inc มากแค่ไหน
      หรือจริง ๆ ก็คล้ายกับเอาไปฝากที่ปรึกษาสุ่ม ๆ คนหนึ่ง
      “AI บอกว่าเป็นไอเดียที่ดี” มันแย่กว่า “เราทำตามกระแสของอุตสาหกรรม” จริงหรือ
    • คนรอบตัวผมหลายคนผ่านช่วงนี้ไปแล้ว
      ถ้าเกิดกับคนคนเดียว เพื่อนและครอบครัวมักชี้ให้เห็นพฤติกรรมหรือคำพูดแปลก ๆ จนช่วยเบรกไว้ได้ระดับหนึ่ง
      แต่ถ้านายจ้างเริ่มทำแบบนั้นในระดับผู้นำ มันยากจะจินตนาการเลยว่าจะแย่ได้แค่ไหน
      คุณจะถูกกดดันให้เอาด้วย หรือกลัวว่าจะโดนไล่ออก และคนที่จะช่วยคอยปรับสมดุลความคิดก็จะเหลือแค่เพื่อนร่วมงานที่ไม่เห็นด้วย ซึ่งคนพวกนั้นก็มักมีโอกาสลาออกหรือถูกไล่ออกสูง
      ถ้าอยากรักษางานไว้ คุณก็ต้องทำตัวให้สอดคล้องไปด้วย
    • การเอาการคิดไปเอาต์ซอร์สให้ AI สร้างการเร่งความเร็วแบบมหัศจรรย์
      เพราะเอเจนต์เป็นคนตัดสินใจแทน งานจึงเคลื่อนที่ด้วยความเร็วของเอเจนต์ และบ่อยครั้งมันตัดสินใจเงียบ ๆ ไปเลย ก่อนจะส่งแค่ว่าผลลัพธ์สุดท้ายคือ “นี่คือแผน”
      แต่การจะรีวิวมันอย่างเหมาะสมต้องเข้าใจปัญหาอย่างลึกซึ้ง ซึ่งทำให้คุณต้องกลับไปใช้ความเร็วแบบมนุษย์อีกครั้ง สุดท้ายเลยมักได้แค่กวาดตาดูแล้วอนุมัติ
      ประเด็นสำคัญคือเราต้องเลือกอย่าง มีสติและรอบคอบ ว่าจะเอาต์ซอร์สการตัดสินใจไหน
      และการทำแบบนั้นต้องยอมช้าลง ผลประโยชน์ vibe coding แบบคูณ 10 ที่พูดเกินจริงอาจหายไป แต่คุณจะมีส่วนร่วมมากขึ้นและสะสมหนี้ทางความคิดน้อยลง
      การตัดสินใจน่าเบื่อ ๆ อย่างจะวนลูป array อย่างไร หรือจะต่อ output ของคำสั่งหนึ่งเข้ากับ input ของอีกคำสั่งอย่างไร ปล่อยให้เอเจนต์ทำได้
      แต่การตัดสินใจจริงต้องกำหนดไว้ล่วงหน้าและใส่ไว้ในสเปก: ต้องนิยามขอบเขต, API, โครงสร้างข้อมูลหลัก, ระบบกับความรับผิดชอบ, การจัดการข้อผิดพลาด, รวมถึงข้อจำกัดเข้มงวดด้านความปลอดภัยและความเป็นส่วนตัว
      ถ้าคลุมเครือก็ต้องสั่งเอเจนต์ให้หยุด และถ้าเป็นวิศวกรที่ดี คุณน่าจะได้ ความเร็วเพิ่ม 2~3 เท่า โดยไม่มีผลข้างเคียง

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

  • บทความนี้ชี้ว่าเราเถียงกับคนที่บอกว่า “ปล่อยบั๊กขึ้นโปรดักชันไปก็ได้ เอเจนต์แก้ได้ด้วยความเร็วและสเกลที่มนุษย์ทำไม่ได้” ไม่ค่อยได้
    แต่คอมเมนต์อันดับบนสุดกลับเป็นตัวอย่างของแนวคิด “แต่เอเจนต์มันเร็วมากนะ” พอดี

    • ถ้าเครื่องมือยังไม่ดีหรือเร็วพอจะแก้บั๊กก่อนปล่อยได้ ผมไม่รู้จริง ๆ ว่าทำไมถึงเชื่อว่ามันจะตามไปแก้หลังปล่อยได้ง่ายนัก
      บางทีอาจกำลังสมมติว่าประโยชน์จากการที่ codebase และฟีเจอร์เพิ่มเป็นสองเท่า มีมากกว่าความเสียหายจากจำนวนบั๊กที่เพิ่มเป็นสองเท่า
      อย่างน้อยในจดหมายข่าวถึงนักลงทุนประจำไตรมาสนี้มันก็คงดูดี
    • แล้วจะรู้ได้อย่างไรว่าการแก้ไขนั้นไม่มีบั๊กอีก
      มันอาจกลายเป็นว่าคุณแค่ปล่อยขยะเพิ่มออกไปเรื่อย ๆ โดยมีลูกค้าเป็น feedback loop ก็ได้?
    • ถ้ามันเร็วขนาดนั้น ก็แก้บั๊กให้ไวตั้งแต่ก่อน deploy สิ
    • ตอนกระแส AI บูมช่วงแรก ผมคุยกับเพื่อนว่าการพึ่ง AI มากเกินไปจะนำไปสู่หายนะสารพัด
      คำตอบที่ได้กลับมาคือ “มันคือ game theory ยังไงก็ต้องมีคนทำ และสุดท้ายคุณก็ต้องทำเหมือนกัน มันคงไม่แย่ขนาดนั้นหรอก”
      ตรรกะนั้นมีประโยชน์ แต่การเมินความเสี่ยงเป็นอีกเรื่องหนึ่ง
      การสมมติว่าถ้าเคลื่อนที่ให้เร็วมากพอแล้วพังทุกอย่าง ในที่สุดผลลัพธ์จะออกมาดีเอง เป็นเรื่องอันตราย
      กระแส AI นี้ไปได้ไม่ค่อยสวย และผมไม่ชอบมันเลย
    • ในความเป็นจริง ธุรกิจของผมยังเดินหน้าต่อได้ด้วยประสิทธิภาพที่สูงขึ้น แม้จะมีบั๊กอยู่ก็ตาม
      ผมไม่คิดว่าฝั่งที่มีอาการ psychosis จำเป็นต้องเป็น “ฝั่งเรา” เสมอไป

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

    • นี่มันโครงเรื่องของ Battlestar Galactica แบบตรงตัวเลย
      ชีวิตเลียนแบบศิลปะ
    • ไม่เคยดีใจเท่าตอนนี้เลยที่ได้ทำงานในเยอรมนี
      เมื่อก่อนยังชอบล้อกันว่าเรายังใช้แฟกซ์กันอยู่ แต่ไม่คิดเลยว่าจะโชคดีขนาดนี้ที่ได้ทำงานในวัฒนธรรมที่ไม่หลงกระแสแบบนี้
      เวลาอ่าน HN มันเหมือนหลุดเข้าไปใน Alice's Wonderland ของพวก maximalist โทเค็นและผู้ป่วย AI psychosis
      ที่นี่ผมไม่รู้จักแม้แต่คนเดียวที่ถูกบังคับให้ทำงานแบบนั้น

  • ถ้าคุณชอบฟีลแบบนี้ อาจชอบ CLI tool ใหม่ Burn, Baby, Burn (those tokens): https://github.com/dtnewman/burn-baby-burn/tree/main
    Show HN อยู่ที่นี่: https://news.ycombinator.com/item?id=48151287

  • ทำให้นึกถึง Simple Made Easy ของ Rich Hickey และแนวทางตอนสร้าง Clojure
    แม้ก่อนยุคที่ LLM จะสร้างโปรแกรมทั้งก้อนได้ เฟรมเวิร์กที่ซับซ้อนก็ช่วยให้นักพัฒนาสร้างโปรแกรมเวอร์ชันแรกได้เร็วมากอยู่แล้ว แต่แลกมากับการที่มันเข้าใจยาก และเลย debug กับแก้ไขได้ยากด้วย
    บางคนกำลังเดิมพันว่าไม่ว่า AI จะเขียนโปรแกรมที่พันกันยุ่งเหยิงและซับซ้อนแค่ไหน AI ก็จะฉลาดพอที่จะ debug, ดูแลรักษา และแก้ไขมันได้เสมอ
    ผมยังไม่มั่นใจขนาดนั้น

  • AI psychosis ไม่ได้หมายถึงการต่อต้านการใช้ AI
    ผมใช้เครื่องมือเขียนโค้ดด้วย AI ทุกวัน แต่เครื่องมือ AI ไม่มีแนวคิดเรื่องอนาคต
    การสร้างระบบที่เสถียรที่ผ่านมา เราพึ่งพาความเห็นแก่ตัวของวิศวกรที่คิดว่า “ถ้าสิ่งนี้พังในโปรดักชันฉันคงแก้ไม่ไหว แล้วตีสามคงมีคนโทรปลุกฉันแน่”
    เรายังพึ่งความขี้เกียจแบบทั่วไปที่อยากหาไลบรารีสมบูรณ์แบบจาก CPAN เพื่อจะได้ไม่ต้องลงมือทำเอง และบางครั้งใช้เวลาหาไลบรารีนานกว่าการเขียนเองเสียอีก
    ผมเคยใช้เครื่องมือ AI เขียนโค้ดหลายพันบรรทัดแล้วเอาขึ้นโปรดักชัน ซึ่งโดยรวมก็รู้สึกเป็นธรรมชาติ เพราะตั้งแต่ปี 2017 ผมก็บอกคนอื่นมาตลอดว่าอย่าพิมพ์โค้ดทุกตัวเอง แต่ให้ “เขียน” มัน และวางกับดักในเทสต์ไว้เพื่อจับโค้ดแย่ ๆ
    แต่มีอย่างหนึ่งที่ AI ไม่ทำ คือ เขียนโค้ดให้น้อยลง: https://xcancel.com/t3rmin4t0r/status/2019277780517781522/

    • ไม่รู้ว่าเป็นเพราะพรอมป์หรือเปล่า แต่ coding agent ของผมรันบน Opus 4.7 และมันชอบพูดอะไรทำนอง “นี่คือสิ่งประเภทที่จะระเบิดตอนตี 2 ในอีก 6 เดือน” อยู่บ่อย ๆ

  • รายงานบั๊กก็ลดลงได้เหมือนกัน ถ้าคนเริ่มหมดศรัทธาว่ามันจะถูกแก้
    เพราะการรายงานบั๊กมักต้องลงทุนลงเวลาไม่น้อย
    เวลาความเชื่อใจต่อกลุ่มหรือบริษัทใดพังลง เรื่องแบบนี้เกิดขึ้นค่อนข้างบ่อย

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

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