Claude Code ไม่ได้ทำให้ผลิตภัณฑ์ของคุณดีขึ้น

 (ethanding.substack.com)
1 คะแนน โดย GN⁺ 1 시간 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • ผลด้านประสิทธิภาพจากเอเจนต์เขียนโค้ดไม่ได้กระจายอย่างเท่าเทียม แต่แยกออกเป็นรูปแบบ K-shape และตัวชี้วัดสำคัญไม่ใช่จำนวนบรรทัดโค้ดต่อชั่วโมง แต่คือความเร็วในการ ปรับปรุงผลิตภัณฑ์ ต่อวิศวกร 1 คนเพิ่มขึ้นจริงหรือไม่
  • Dax, Karri Saarinen และ David Cramer ไม่ใช่คนที่ต่อต้าน AI แต่ก็ยังไม่มั่นใจว่าเอเจนต์เขียนโค้ดช่วยเพิ่มความเร็วในการพัฒนาผลิตภัณฑ์อย่างชัดเจน และ Cramer มองว่า LLM เพิ่มทั้งความซับซ้อนและ ความเทอะทะของระบบ จนทำให้ความเร็วระยะยาวช้าลง
  • หาก Claude Code ให้ความได้เปรียบแบบผูกขาดภายใน Anthropic มา 7 เดือน ช่องว่างกับคู่แข่งควรขยายตัวแบบทบต้น แต่ Codex, Cursor, Cognition และ Factory ก็ยังแข่งขันได้อยู่ จึงมีความเป็นไปได้สูงว่าคอขวดไม่ใช่การผลิตโค้ด
  • วัฒนธรรมวิศวกรรมที่ดีมองจำนวนบรรทัดโค้ดไม่ใช่ทรัพย์สิน แต่เป็น ต้นทุน และเมื่อฟีเจอร์กับการเชื่อมต่อเพิ่มขึ้น พื้นที่เสี่ยงของบั๊ก การพึ่งพากัน และฟังก์ชันแวดล้อมก็เพิ่มขึ้นตาม ทำให้ความซับซ้อนไม่ได้โตแบบเส้นตรง แต่โตแบบทบต้น
  • ในแนวหน้าของคุณภาพผลิตภัณฑ์ ความสามารถในการตัดสินเรื่อง รสนิยม, การบีบอัด, การลบ และการปฏิเสธ สำคัญกว่าการเขียนโค้ดให้เร็ว โดย Claude Code มีประโยชน์ในการไปจาก 0 ถึงระดับ Camry แต่ไม่ได้ทำให้ช่างฝีมือ Ferrari สร้าง Ferrari ที่เร็วกว่าเดิมได้

เส้นโค้งประสิทธิภาพแบบ K-shape

  • การเพิ่มประสิทธิภาพจากเอเจนต์เขียนโค้ดไม่ได้เกิดขึ้นอย่างเท่าเทียม แต่แยกออกเป็น K-shape
    • วิศวกรอาวุโสมีผลผลิตที่เพิ่มขึ้นอย่างวัดได้หลังจุดเปลี่ยนของ LLM ในปี 2023
    • ผลผลิตของวิศวกรจูเนียร์แทบหยุดนิ่งหรือลดลง
    • ตัวชี้วัดที่สำคัญไม่ใช่จำนวนบรรทัดโค้ดต่อชั่วโมง แต่คือความเร็วในการ ปรับปรุงผลิตภัณฑ์ ต่อวิศวกร 1 คนเพิ่มขึ้นจริงหรือไม่
  • การเขียนโค้ดแบบ agentic ช่วยลดเวลาที่ใช้สร้าง Pull Request สำหรับงานบางประเภท
    • มีการพูดซ้ำๆ ถึงคำกล่าวอย่าง “เคลียร์ backlog 6 ปีได้ภายในไตรมาสเดียว”, “สร้าง backend ด้วย Cursor ใน 3 วัน”, “Claude Code เขียนด้วย Claude ทั้งหมด”
    • แต่ความเร็วในการผลิตโค้ดจะเท่ากับตัวชี้วัดเรื่องคุณภาพผลิตภัณฑ์ที่ดีขึ้นหรือไม่ ยังเป็นอีกประเด็นหนึ่ง

สัญญาณเตือนจากวิศวกรที่สร้างผลิตภัณฑ์เก่ง

  • Dax, Karri Saarinen และ David Cramer ต่างก็ไม่ใช่คนต่อต้าน AI แต่ยังไม่มั่นใจว่าเอเจนต์เขียนโค้ดช่วยเพิ่มความเร็วในการพัฒนาผลิตภัณฑ์อย่างชัดเจน
    • Dax กำลังสร้าง opencode.ai
    • Karri Saarinen คือ CEO ของ Linear
    • David Cramer คือคนที่สร้าง Sentry ตั้งแต่เริ่มต้นจนเติบโตเป็นธุรกิจระดับรายได้ 10 ล้านดอลลาร์ต่อเดือน
  • David Cramer มองว่า LLM ยังไม่สร้างการเพิ่มขึ้นของผลิตภาพสุทธิในปัจจุบัน
    • มันลดกำแพงในการเริ่มต้น แต่สร้างซอฟต์แวร์ที่ซับซ้อนและดูแลรักษายาก
    • และดูเหมือนจะทำให้ความเร็วระยะยาวช้าลง
    • เขาชี้ปัญหาเรื่อง “ความสามารถในการพัฒนาแบบค่อยเป็นค่อยไปท่ามกลางความซับซ้อนที่ยังไม่ดีพอ”, “การขาดความสามารถในการทำให้เรียบง่ายอย่างแท้จริงและสร้างอินเทอร์เฟซที่เป็นสำนวนธรรมชาติ”, และ “เทคนิคการสร้างเทสต์ที่หยาบ” ของ LLM
    • สุดท้ายเขามองว่าส่วนใหญ่แล้วมันคือ ความเทอะทะของระบบ (bloat)
  • Dax ระบุว่ายังหาวิธีที่ชัดเจนที่สุดในการใช้เอเจนต์เขียนโค้ดให้เกิดประโยชน์สูงสุดไม่ได้
    • ขณะที่ภายนอกมีคำกล่าวอย่าง “ทุก PR สร้างโดย AI”, “เร็วอย่างไม่เคยมีมาก่อน”, “จัดการ backlog 6 ปีได้แล้ว” อยู่มากมาย
    • แต่ในความเป็นจริง ทุกคนเหล่านี้ยังเผชิญความยากลำบากในการเร่งความเร็วการปรับปรุงผลิตภัณฑ์จริง

ความได้เปรียบแบบผูกขาดของ Claude Code ไม่ได้สะท้อนออกมาเป็นช่องว่าง

  • หาก Claude Code ถูกเขียนด้วย Claude ทั้งหมด ความเร็วในการปรับปรุงผลิตภัณฑ์ก็ควรเร่งขึ้น
    • ต่อให้การใช้ Claude Code เพิ่มความเร็วการปรับปรุงผลิตภัณฑ์เพียง 1.5 เท่า ทีมที่ใช้มันตั้งแต่แรกก็ควรทิ้งห่างคู่แข่งมากขึ้นเรื่อยๆ เมื่อเวลาผ่านไป
    • เพราะประสิทธิภาพทางวิศวกรรมเป็นฟังก์ชันแบบทบต้น ความแตกต่างจึงควรใหญ่ขึ้นทุกไตรมาส
  • แต่สถานการณ์จริงในตลาดไม่ได้แสดงช่องว่างแบบทบต้นเช่นนั้น
    • Codex เปิดตัวช้ากว่า Claude Code หลายเดือน แต่ตอนนี้ก็แข่งขันกันได้ในเชิงฟีเจอร์แล้ว
    • กระแสดีลของ Cursor ยังแข็งแรง
    • Cognition และ Factory ก็ยังคว้าสัญญาองค์กรสำคัญได้อยู่
    • ผู้คนยังคงถกเถียงกันว่าเครื่องมือไหนดีกว่ากัน
  • ข้อโต้แย้งสำคัญคือ หาก Anthropic มี Claude Code ใช้อย่างผูกขาดอยู่ 7 เดือน แล้วมีความได้เปรียบด้านความเร็วผลิตภัณฑ์จริง ช่องว่างกับคู่แข่งควรขยายจนไล่ไม่ทัน
    • Codex ควรหมดความหมายไปแล้ว แต่ก็ไม่ได้เป็นเช่นนั้น
    • หากไม่เห็นความได้เปรียบแบบทบต้น ก็มีโอกาสสูงว่าคอขวดของคุณภาพผลิตภัณฑ์ไม่ใช่เรื่องโค้ด
  • แม้ข้อโต้แย้งกลับก็ยิ่งตอกย้ำข้อสรุปเดียวกัน
    • ต่อให้มีผลดีอยู่บ้าง ก็อาจถูกต้นทุนหนี้ความซับซ้อนกลืนกินไปแล้ว
    • ทีมวิศวกรรมของ Anthropic อาจใหญ่เกินไปจนประโยชน์ส่วนเพิ่มต่อวิศวกรแต่ละคนถูกเจือจาง
    • แต่แม้ในกรณีนั้น คอขวดก็ยังไม่ใช่การผลิตโค้ด แต่อยู่ที่ปัจจัยอื่นที่ยากกว่า

จำนวนบรรทัดโค้ดไม่ใช่ทรัพย์สิน แต่เป็นต้นทุน

  • วัฒนธรรมวิศวกรรมที่ดีมองจำนวนบรรทัดโค้ดไม่ใช่ผลผลิต แต่เป็น ค่าใช้จ่าย
    • เขียนโค้ดให้กับฟีเจอร์ที่สำคัญ และไม่เขียนให้กับฟีเจอร์ที่ไม่สำคัญ
    • codebase ไม่ใช่สินทรัพย์ในงบดุล แต่ใกล้เคียงกับหนี้สินมากกว่า
  • tinychat บริษัทซอฟต์แวร์ในเครือ comma.ai ตั้งให้มีสัญญาณเตือนเมื่อ codebase โตเกินขนาดที่กำหนด และเฉลิมฉลองเมื่อมีการลบโค้ด
    • ทุกบรรทัดของโค้ดคือพื้นที่เสี่ยงของบั๊ก
    • ทุกฟังก์ชันจะกลายเป็น dependency ของฟังก์ชันถัดไป
    • ทุกฟีเจอร์จะก่อให้เกิดฟีเจอร์รอบข้างตามมา
  • พื้นที่ผิวของผลิตภัณฑ์ขยายตัวแบบแฟร็กทัล
    • เมื่อเพิ่มการเชื่อมต่อกับ Slack ก็จะต้องมีการเชื่อมต่อกับ Teams และเส้นทางสำรองผ่านอีเมล
    • เมื่อเพิ่มการแจ้งเตือน ก็ต้องทำให้รองรับมือถือ, SMS และนโยบาย MDM สำหรับองค์กร
    • เมื่อเพิ่มการรองรับ MFA ก็ต้องเข้ากันได้กับ Duo, Okta และ SAML
    • ความซับซ้อนไม่ได้เพิ่มแบบเส้นตรง แต่เพิ่มแบบทบต้น
  • Linear มีพนักงาน 178 คน ใช้เวลา 6 ปี และมี ARR ระดับ 100 ล้านดอลลาร์
    • Jira มีความพยายามทางวิศวกรรมสะสมมากกว่า Linear ถึง 56 เท่า แต่คะแนนคุณภาพในมุมผู้บริโภคกลับต่ำกว่า 6 คะแนน
    • ประเด็นสำคัญคือคุณภาพกับมวลของ codebase ไม่ใช่สิ่งเดียวกัน
  • ในระดับของ Facebook ความสามารถในการผลิต UI code ได้เร็วไม่ใช่คอขวด
    • วิศวกรที่ชำนาญสามารถทำ mockup ของ Facebook feed ได้ภายในวันเดียว
    • ข้อจำกัดจริงคือการลดจำนวนบรรทัดโค้ดที่จำเป็นต่อการส่งมอบประสบการณ์นั้นให้คนหลายพันล้านคน พร้อมรักษา uptime ภายใต้โหลดและ latency ทุกรูปแบบ
    • ฟังก์ชันรางวัลจึงไม่ใช่การผลิต แต่คือ การบีบอัด
    • ในงานลักษณะนี้ เอเจนต์เขียนโค้ดไม่สามารถประเมิน trade-off ระยะยาว และไม่ได้มีทฤษฎีเกี่ยวกับระบบ

คอขวดที่แท้จริงคือความสามารถในการผลักแนวหน้าของไอเดียผลิตภัณฑ์ที่ดี

  • การยกระดับคุณภาพผลิตภัณฑ์ที่แนวหน้าไม่ได้ถูกจำกัดด้วยการเขียนโค้ดได้เร็วแค่ไหน แต่ถูกจำกัดด้วยการคิดไอเดียที่ดีพอจะผลักแนวหน้าได้เร็วแค่ไหน
  • ความต่างระหว่าง Jira กับ Linear ไม่ใช่ว่าใครวาดกล่องได้ดีกว่า
    • Linear มีวิสัยทัศน์เชิงสร้างสรรค์ที่ชัดเจนว่าซอฟต์แวร์บริหารโครงการควรให้ความรู้สึกอย่างไร และลงมือทำสิ่งนั้นอย่างมีวินัยตลอดหลายปี
    • คุณภาพแบบนี้ไม่ได้มาจาก throughput ของโทเค็น แต่มาจาก รสนิยม และการตัดสินใจที่จะทำน้อยลง
  • คำกล่าวว่า “เคลียร์ backlog 6 ปีได้แล้ว” ไม่ได้น่าประทับใจอย่างที่ฟังดู
    • backlog ที่เต็มไปด้วยฟีเจอร์แบบ CRUD และเครื่องมือภายในเหมาะกับงานที่เอเจนต์เขียนโค้ดเร่งความเร็วได้
    • แต่ในขณะเดียวกัน งานแบบนั้นก็ไม่ใช่งานที่ผลักแนวหน้าของผลิตภัณฑ์
    • การเปิดตัวได้เร็วขึ้นไม่ได้ทำให้ผลิตภัณฑ์ดีขึ้น หากสิ่งที่เปิดตัวไม่ได้ทำให้ผู้ใช้ใส่ใจมากขึ้น
  • เอเจนต์เขียนโค้ด AI ช่วยให้ผลิตภัณฑ์จาก 0 ไป 1 ไปถึงแนวหน้าด้านคุณภาพได้เร็วขึ้น
    • มันลดเวลาที่ต้องใช้เพื่อให้ได้เวอร์ชันแรกที่ใช้งานได้
    • การเพิ่มความเร็วในงานระยะแรกมีอยู่จริง
  • แต่ก็มีต้นทุน
    • codebase โตเร็วกว่าคุณภาพ
    • หนี้ทางเทคนิคสะสมแบบทบต้น
    • ความเร็วที่ได้ตอนนี้คือสิ่งที่ซื้อมาโดยมีต้นทุนให้ต้องชดใช้ในภายหลัง

มอบ Camry ให้ทุกคน แต่ไม่ทำให้ใครได้ Ferrari

  • คอขวดของทีมที่อยู่แนวหน้าไม่ใช่เอเจนต์เขียนโค้ด แต่คือ คนที่มีรสนิยม
    • ความสามารถในการ “ตัดสิ่งที่ไม่จำเป็นออกจนกลายเป็นสิ่งที่ดีที่สุด” แบบ Linear และ Sentry อยู่ในตัวคนบางคนโดยเฉพาะ
    • ยกตัวอย่าง Nan Yu ของ Linear และ Kelly Johnson แห่ง Skunk Works
    • ทีมที่ Kelly Johnson คัดสรรมาสร้าง SR-71 และแม้ผ่านไป 60 ปี SR-71 ก็ยังถูกกล่าวถึงว่าเป็นอากาศยานมีนักบินแบบใช้เครื่องยนต์อากาศหายใจที่เร็วที่สุด
    • Blackbird ไม่ได้เร็วเพราะผลิตแบบพิมพ์เขียวได้มากกว่า แต่เพราะ Johnson มีทฤษฎีว่าควรไม่ใส่อะไรไว้บ้าง
    • รสนิยมในการลบ การบีบอัด และการปฏิเสธ ไม่มีอยู่ใน roadmap ของ frontier model ใด และยิ่งเมื่อระดับพื้นฐานของทุกคนสูงขึ้น มันก็ยิ่งมีคุณค่ามากขึ้น
  • หากคุณอยู่ที่แนวหน้าอยู่แล้ว ก็ยังไม่ชัดเจนว่าการเพิ่มต้นทุน R&D เป็นสองเท่าผ่านค่าใช้จ่ายด้านโทเค็นจะสร้างมูลค่าทางเศรษฐกิจหรือไม่
    • วิศวกรของ Ramp บอกว่าในช่วง 1 ปีที่ผ่านมา พวกเขาเพิ่มค่าใช้จ่ายด้านโทเค็นจนเทียบได้กับการเพิ่มเงินเดือนเป็นสองเท่า
    • แต่ยากที่จะยืนยันว่าผลิตภัณฑ์ของ Ramp ดีขึ้นจริงหรือไม่
    • หากคุณเป็นที่ 1 อยู่แล้ว อัตราการชนะก็แทบคงที่ และการเป็น “ที่ 1 แบบทิ้งห่างกว่าเดิม” ก็วัดได้ยาก
    • หากจะเปลี่ยนข้อสรุปนี้ จำเป็นต้องมีข้อมูลเรื่องอัตราการชนะหรือตัวเลขกำไรขาดทุนของ Ramp
    • ผู้เขียนระบุว่าในฐานะลูกค้าของ Ramp ตนยังไม่รู้สึกถึงความต่างระหว่างตอนนี้กับปีที่แล้ว
  • Claude Code อาจช่วยให้ทุกคนสร้างผลิตภัณฑ์คู่แข่งระดับ Camry ได้ แต่ไม่ได้ช่วยให้ช่างฝีมือ Ferrari สร้าง Ferrari ที่เร็วขึ้น
    • มันมีประโยชน์มากในการไปจาก 0 ถึงระดับ Camry
    • ต้นทุนการผลิตซอฟต์แวร์ที่ไม่ได้อยู่ระดับสูงสุดมีแนวโน้มจะลดลงอย่างมาก
    • แต่ในทางกลับกัน ความสับสนและหนี้ก็จะสะสมเต็มคานโรงงาน และสุดท้ายต้องมีใครสักคนมาจัดการมัน

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

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

 
GN⁺ 1 시간 전
ความเห็นจาก Lobste.rs

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

    • นี่เป็นปัญหาแบบคลาสสิก ถ้าเหตุและผลต่อกันทันที ประโยชน์ระยะสั้นจะมองเห็นได้ง่าย แต่ถ้ามีช่วงเวลาคั่นกลางระหว่างเหตุและผล ผลเสียจะมองเห็นได้ยากกว่ามาก
      http://bastiat.org/en/twisatwins.html
      ต้นทุนของการใช้ code agent ไม่ได้แสดงออกมาตรง ๆ และเหนือสิ่งอื่นใด มันมาจาก การสูญเสียความเข้าใจร่วมกัน ว่าระบบทำงานอย่างไร
    • ถึงอย่างนั้น การจัดระเบียบแบบลำดับชั้น ก็ยังเป็นหนทางในการจัดการความซับซ้อนขนาดใหญ่ได้ เราเห็นในธรรมชาติเหมือนกันว่าโครงสร้างที่ซับซ้อนมหาศาลเกิดขึ้นด้วยวิธีนี้ ระบบสามารถสร้างขึ้นจากหน่วยอิสระที่ประกอบกันเป็นโครงสร้างใหญ่กว่า
      ระบบที่แข็งแรงต้องทนต่อแรงกระแทกและปรับตัวเองได้ ดังนั้นแต่ละส่วนต้องล้มเหลวได้อย่างอิสระและจำกัดความเสียหายไว้เฉพาะจุด หากจัดระบบเป็นชุดของระบบย่อยที่ซ้อนกัน ก็จะได้หน่วยคล้ายเซลล์ที่คุยกันและจัดการงาน หน่วยเหล่านี้ทำงานเหมือนชิ้นส่วนย่อยที่เสถียรโดยไม่จำเป็นต้องรู้กระบวนการภายในของเซลล์อื่น
      แต่ละชั้นจึงไม่ถูกสิ่งที่เกิดขึ้นที่อื่นฉุดรั้ง สามารถจัดระเบียบตัวเองและรักษาความยืดหยุ่นได้ภายในขอบเขตของตัวเอง นี่คือการห่อหุ้มความซับซ้อนส่วนข้างเคียงไว้หลังอินเทอร์เฟซ และสร้าง abstraction ที่อินเทอร์เฟซนั้นมีความหมายอยู่ในตัว ควรมองลำดับชั้นว่าเป็นเนื้อเยื่อเชื่อมที่ประสานองค์ประกอบของระบบขนาดใหญ่เข้าด้วยกัน
      Erlang OTP เป็นตัวอย่างที่ดีของแนวทางนี้ในซอฟต์แวร์ โดยประกอบระบบขนาดใหญ่จากโปรเซสที่แยกขาดจากกันและสื่อสารกันด้วยข้อความ ถึงโปรเซสเดี่ยวจะตายหรือเกิดข้อผิดพลาด ก็ไม่ทำให้ทั้งระบบพังลง
    • ผมมองว่าการ “กดความซับซ้อนไว้” ต้องอาศัยการตัดสินใจ มุมมอง และบางครั้งก็ต้องมีการคัดค้านหรือปะทะกัน
      ถ้าคุณขอให้ใครสักคนไป implement อะไรบางอย่าง เขาอาจตอบได้ว่า “มันซับซ้อนเกินไป” “อีก 1 ปีจะระเบิดแน่” “มันเข้ากันไม่ได้กับสิ่งที่ทีม Y กำลังทำ” หรือ “มีคน implement ไม่พอ” คำพูดสุดท้ายนั้นอาจเป็นเรื่องจริง หรืออาจเป็นวิธีอ้อม ๆ ในการบอกว่า “ไม่ได้”
      โอกาสที่ LLM จะตอบแบบนั้นมีน้อยมาก โดยเฉพาะเพราะมันถูกปรับให้มองโลกในแง่ดีและสุภาพ ยิ่งไปกว่านั้น นิสัยแบบนั้นก็จำเป็นต่อการเพิ่มการมีส่วนร่วมด้วย จึงดูไม่น่าจะถูกปรับไปอีกทาง
      ปัญหานี้ดูคล้ายกับกรณีที่ LLM ช่วยผู้ใช้ฆ่าตัวตาย ซึ่งเป็นเรื่องที่ค่อนข้างชัดเจนแต่ LLM ก็ยังทำกันมามากแล้ว การที่โปรเจกต์ตายเพราะความซับซ้อนที่ไร้การควบคุมนั้นชัดเจนน้อยกว่ามาก จึงยากจะคาดหวังว่า LLM จะทำเรื่องนี้ได้ดีขึ้นในเร็ว ๆ นี้

  • การให้เหตุผลประมาณว่า “ถ้าใช้ Claude Code แล้วเกิดความได้เปรียบด้านความเร็วในการพัฒนาผลิตภัณฑ์จริง และ Anthropic ผูกขาดมันอยู่ 7 เดือน ช่องว่างระหว่าง Claude Code กับคู่แข่งทั้งหมดก็น่าจะปิดไม่ทัน Codex ควรไม่มีความหมาย แต่คนก็ยังถกกันอย่างคึกคักว่าฝั่งไหนดีกว่า” ฟังดูไม่แน่นนัก
    Claude Code เป็นซอฟต์แวร์ที่ดี แต่ไม่ใช่มนตร์ AGI แปลกประหลาดระดับที่ทำให้ไม่มีใครแข่งได้

    • ยิ่งไปกว่านั้น Codex เองก็ถูกสร้างด้วย vibe coding ดังนั้นการเปรียบเทียบนี้ก็ชวนขำในแง่นั้นเหมือนกัน การเริ่มก่อนแค่ไม่กี่เดือนอาจไม่ได้มีความหมายมาก เพราะฟีเจอร์จำนวนมากที่เพิ่มเข้ามาเกิดจากสิ่งที่ผู้ใช้จริงทำกับเครื่องมือ
      ไม่ใช่ว่า Claude Code มีโร้ดแมปที่เสร็จสมบูรณ์มาตั้งแต่แรก และอุปสรรคหลักก็ไม่ใช่ความเร็วในการเขียนโค้ด อุปสรรคสำคัญคือไอเดีย ทุกคนกำลังสร้างมันไปพร้อมกับการลงมือทำ
      ผมแค่อ่านผ่าน ๆ บทความมา จึงพูดลึกมากไม่ได้ แต่ต่อให้ไม่นับปัญหาเรื่องตัวพิมพ์ใหญ่ต้นประโยค มันก็ดูเหมือน ร้อยแก้วที่ LLM เขียน เกือบทั้งหมดจนไม่อยากอ่าน

  • จนถึงตอนนี้ ความผิดพลาดของเอเจนต์มีแนวโน้มจะ สะสมแบบคูณทบ
    ถ้าคุณสร้าง API ที่ในทางเทคนิคใช้ได้ แต่เวลานำไปใช้ต้องมีโค้ดเพิ่มอีกนิด ผลก็คือโค้ดจะมากขึ้น และก็มีที่ให้เกิดการซ้ำ การแตกแขนง และบั๊กมากขึ้น จากนั้นก็จะมีโค้ดที่ไม่ค่อยดีถูกเขียนเพิ่มขึ้นอีกแบบแฟร็กทัล
    ครั้งหนึ่งมีเอเจนต์ตัวหนึ่งออกแบบ struct ที่ฟิลด์ id เป็น optional ทั้งที่จำเป็นเพียงเพราะ constructor ตัวเดียวที่มันเขียนเอง จากนั้นมันก็เขียนโค้ดสองชุดอย่างไม่รู้เหน็ดเหนื่อยสำหรับกรณีที่มี id และไม่มี id และยังสร้างเส้นทาง fallback ที่ดูประหลาดสำหรับกรณีไม่มี id ด้วย ซึ่งแน่นอนว่าเส้นทางเหล่านั้นทั้งซับซ้อนและเปราะบาง มันแพร่ไปเกือบทุกจุดที่ใช้ struct นี้รวมถึงสิ่งที่พึ่งพามัน ทั้งที่จริง constructor แบบไม่มี id ก็ไม่ได้ถูกใช้เลย ครึ่งหนึ่งของโค้ดเบสลบทิ้งได้ง่าย ๆ
    ผมไม่แน่ใจจริง ๆ ว่าถ้าใส่คำสั่งอย่าง “ถ้ากำลังทำเรื่องโง่ ๆ ก็หยุดขุด” มากพอแล้วจะแก้ได้ และการเขียนโค้ดจะเหลือแค่แฮ็กไม่กี่อย่างก่อน “ถูกแก้ปัญหา” หรือว่ามันเป็นปัญหาระยะยาวของ stochastic parrot ที่ยังต้องจ่ายต้นทุนเพิ่มแบบเอ็กซ์โพเนนเชียลต่อไปเพื่อให้ได้การพัฒนาแบบเส้นตรง ตราบใดที่ความผิดพลาดยังสะสมแบบดอกเบี้ยทบต้น การเติบโตแบบดอกเบี้ยทบต้นก็จะย้อนมาฉุดขาในที่สุด

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

  • อยากเห็นเวอร์ชันที่อัปเดตด้วยข้อมูลหลัง จุดเปลี่ยนเดือนพฤศจิกายน 2025