เหตุผลที่ยกเลิก Claude: ปัญหาโทเค็น คุณภาพลดลง และการซัพพอร์ตที่ย่ำแย่

 (nickyreinert.de)
9 คะแนน โดย GN⁺ 5 일 전 | 10 ความคิดเห็น | แชร์ทาง WhatsApp
  • ในช่วงไม่กี่สัปดาห์แรกพึงพอใจมากทั้งความเร็ว, โควตาโทเค็นที่รู้สึกว่ายุติธรรม, และคุณภาพของผลลัพธ์ แต่ราว 3 สัปดาห์ก่อนความรู้สึกนี้เปลี่ยนไปอย่างชัดเจน
  • หลังพักไป 10 ชั่วโมงแล้วกลับมา ส่งคำถามสั้น ๆ เพียงสองข้อไปยัง Claude Haiku แต่การใช้งานกลับพุ่งถึง 100% ขณะที่ช่องทางซัพพอร์ตตอบกลับแบบอัตโนมัติที่ไม่ได้แตะประเด็นคำถาม และแทบปิดช่องทางติดต่อไปเลย
  • ช่วงหลัง แม้แต่โปรเจ็กต์เดียวก็ใช้เวลาทำงานได้เพียงสองชั่วโมงก่อน ขีดจำกัดโทเค็นจะหมด จากเดิมที่เคยทำหลายโปรเจ็กต์พร้อมกันได้ และระหว่างรีแฟกเตอร์ยังต้องเสียเวลาเกือบครึ่งหนึ่งของหน้าต่าง 5 ชั่วโมงไปกับการแก้ทางลัดราคาถูก
  • เมื่อเวลาผ่านไป แคชบทสนทนา ก็หายไป ทำให้ต้องเสียค่าอ่าน codebase ซ้ำอีก ขณะเดียวกันยังมีทั้งการเปลี่ยนจุดอ้างอิงรายสัปดาห์และคำเตือนเรื่องขีดจำกัดรายเดือนที่ไม่มีคำอธิบาย จนระบบขีดจำกัดดูไม่สอดคล้องกัน
  • แม้จะยอมรับอย่างมากว่าช่วยเพิ่มผลิตภาพและเห็นศักยภาพของผลิตภัณฑ์ แต่เมื่อการซัพพอร์ตที่ย่ำแย่ คุณภาพที่ลดลง และความสับสนเรื่องข้อจำกัดการใช้งานสะสมขึ้น สุดท้ายจึงยกเลิกบัญชี Anthropic

ความพึงพอใจช่วงแรกและการเปลี่ยนแปลงหลังจากนั้น

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

ปัญหาคุณภาพการซัพพอร์ต

  • หลังพักไปราว 10 ชั่วโมงและคิดว่าโทเค็นน่าจะรีเฟรชแล้ว จึงเริ่มงานตอนเช้า แต่ทันทีที่ส่งคำถามสั้น ๆ สองข้อไปยัง Claude Haiku ซึ่งไม่ได้เกี่ยวกับรีโพซิทอรีเลย การใช้โทเค็นก็พุ่งถึง 100%
    • คำถามนั้นง่ายและมีขนาดเล็กมาก
    • การรีเฟรชโทเค็นที่คาดหวังไว้ไม่สอดคล้องกับการใช้งานจริงที่เพิ่มขึ้น
  • ได้สอบถามไปยัง บอตซัพพอร์ต AI แต่ได้รับเพียงคำแนะนำพื้นฐาน และตัวบอตก็ไม่เข้าใจปัญหาจริงอย่างถูกต้อง
    • หลังจากนั้นจึงขอให้มีเจ้าหน้าที่เข้ามาช่วย
    • แต่คำตอบที่มาถึงในอีกไม่กี่วันต่อมาก็ดูเป็นคำตอบคนละเรื่องกับปัญหาจริง
  • คำตอบที่ได้รับเริ่มต้นด้วยข้อความว่า “ระบบตรวจพบว่าเป็นคำถามเกี่ยวกับขีดจำกัดการใช้งานของแพ็กเกจ Pro หรือ Max” แต่ในความเป็นจริงขณะนั้นใช้งาน Pro plan อยู่แล้ว และสาระสำคัญของคำถามก็ยังไม่ถูกแตะต้อง
    • จากนั้นยังตามมาด้วยเนื้อหาเชิงเอกสารยาว ๆ ที่อธิบายขีดจำกัดรายวันและรายสัปดาห์
    • ไม่เห็นกระบวนการที่จะช่วยแก้หรือรับมือกับปัญหาที่ถามไปโดยตรงเลย
  • ตอนท้ายอีเมลยังมีข้อความว่าคำตอบเพิ่มเติมอาจไม่ได้รับการติดตาม และให้ไปที่หน้าช่วยเหลือแทน ทำให้ช่องทางติดต่อแทบถูกปิดลง
    • เท่ากับว่าได้รับคำตอบอัตโนมัติที่ไม่สะท้อนปัญหาจริง แล้วช่องทางขอความช่วยเหลือก็ถูกตัดไปด้วย
    • ความผิดหวังต่อคุณภาพการซัพพอร์ตจึงเริ่มเพิ่มขึ้นอย่างจริงจัง

คุณภาพที่ลดลง

  • ตลอดหลายวันและหลายสัปดาห์หลังจากนั้น คุณภาพของผลลัพธ์ก็ไม่น่าพอใจเท่าประสบการณ์ช่วงแรก และเวลาที่ใช้งานได้จริงก็ลดลงมาก
    • เมื่อก่อนสามารถทำงานพร้อมกันได้ถึงสามโปรเจ็กต์ แต่ตอนนี้แม้แต่โปรเจ็กต์เดียวก็ทำได้เพียงสองชั่วโมงก่อน ขีดจำกัดโทเค็นจะหมด
    • ทั้งปริมาณที่ใช้งานได้และผลิตภาพที่รับรู้ได้แย่ลงพร้อมกัน
  • มีการชี้ไว้ด้วยว่าการประเมินคุณภาพอาจเป็นเรื่องอัตวิสัย และประสิทธิภาพของเอเจนต์ก็ขึ้นกับผู้ใช้มาก
    • พร้อมกันนั้นยังบอกด้วยว่าใช้งาน GitHub Copilot, OpenAI Codex, OMLX, Continue, Qwen3.5-9B ควบคู่กันอยู่ จึงสะท้อนว่ามีประสบการณ์จากการใช้งานเปรียบเทียบหลายเครื่องมือ
    • ไม่ได้อ้างว่าตนเองมีความเชี่ยวชาญแบบสัมบูรณ์ แต่เมื่อมองจากคนที่เคยใช้หลายเครื่องมือ ก็รู้สึกได้ถึงการถดถอยนี้
  • ในกรณีที่มอบหมายให้ Claude Opus รีแฟกเตอร์โปรเจ็กต์ บันทึกการคิดของโมเดลแสดงแนวทางว่าจะไม่แก้ทุก slider ใน JSX โดยตรง แต่จะเพิ่มตัว initializer แบบทั่วไปใน ui-events.js เพื่อฉีดการแสดงค่าเข้าไปโดยอัตโนมัติ
    • แนวทางนี้เป็นวิธีอ้อมที่ถ้า range input ใดไม่มีการแสดงค่า ก็จะถูกแทรกให้อัตโนมัติ
    • ทำให้ต้องคอยเปิดดูบันทึกเหล่านี้บ่อยขึ้น ไม่ใช่แค่นาน ๆ ครั้ง
  • วิธีนี้ถูกมองว่าไม่ใช่แนวปฏิบัติที่ดี แต่เป็นทางลัดราคาถูก และเมื่อชี้ตรง ๆ Opus ก็ยอมรับว่าเป็นแนวทางที่ขี้เกียจ ก่อนจะเปลี่ยนไปใส่ label ลงใน JSX โดยตรงและเชื่อมโยงอย่างชัดเจนแทน
    • แค่การแก้ทิศทางที่ผิดตั้งแต่แรกก็ใช้ไปประมาณ 50% ของโควตาโทเค็นในหน้าต่าง 5 ชั่วโมงแล้ว
    • จึงไม่ใช่แค่ความรู้สึกว่าคุณภาพลดลง แต่กลายเป็นต้นทุนที่สูญเปล่าจริง

ความสับสนเรื่องแคชและการแสดงขีดจำกัด

  • ปัญหาเรื่องแคชบทสนทนาก็โผล่ขึ้นมาใหม่เช่นกัน โดยมีลิงก์ไปยัง postmortem ของ Anthropic และ การสนทนาใน Hacker News
    • การที่บริษัทพูดถึงปัญหานี้อย่างเปิดเผยถือเป็นเรื่องที่น่าชื่นชม
    • แต่ภาระในแง่ประสบการณ์ผู้ใช้ก็ยังคงอยู่เหมือนเดิม
  • เมื่อเวลาผ่านไปแล้วกลับมาทำงานอีกครั้ง แคชบทสนทนา จะหายไป ทำให้โมเดลเริ่มอ่าน codebase ใหม่ตั้งแต่ต้น
    • ในเชิงต้นทุนอาจเป็นทางเลือกที่คุ้มค่า แต่สำหรับผู้ใช้หมายความว่าเสียโทเค็นไปกับการโหลดครั้งแรกแล้ว พอถูกบังคับให้พักก็ต้องจ่ายต้นทุนโหลดเดิมซ้ำอีก
    • โดยเฉพาะเมื่อเจอข้อจำกัดหน้าต่างโทเค็น 5 ชั่วโมง พอกลับมาทำงานอีกครั้งก็ต้องจ่ายค่าเดิมซ้ำ
  • ยังมีเหตุการณ์ที่หน้าต่างรายสัปดาห์เปลี่ยนจากอิงวันปัจจุบันไปเป็นอิงวันจันทร์แบบกะทันหัน และการใช้งานก็ถูกรีเซ็ตเป็น 0 พร้อมกัน
    • แม้ตัวการรีเซ็ตจะเป็นเรื่องน่ายินดี แต่ก็ไม่รู้ว่าเหตุใดการเปลี่ยนแปลงนี้จึงเกิดขึ้น
    • ทำให้ระบบขีดจำกัดดูขาดความสม่ำเสมอ
  • ระหว่างทำโปรเจ็กต์และคอยดูการใช้โทเค็นอยู่ตลอด ก็มีคำเตือนโผล่มาอย่างกะทันหันว่าต้องกังวลเรื่อง ขีดจำกัดการใช้งานรายเดือน ทั้งที่ไม่ได้เป็นผู้ใช้องค์กร
    • ตอนนั้นก็ยังไม่ได้เกินทั้งขีดจำกัดรายชั่วโมงหรือรายสัปดาห์
    • และบนหน้าจอก็ไม่มีคำอธิบายว่าคำเตือนนั้นอิงจากอะไร
  • คำเตือนดังกล่าวหายไปหลังจากนั้นราวสองชั่วโมง และก็กลับมาทำงานต่อได้
    • แม้แต่ในเอกสาร ก็ไม่ได้พูดถึงขีดจำกัดการใช้งานรายเดือน
    • หน้า settings เองก็ระบุว่าแสดงเพียงเซสชันปัจจุบันและขีดจำกัดรายสัปดาห์เท่านั้น ทำให้ตัวตนของขีดจำกัดรายเดือนยังคงไม่ชัดเจนจนจบ

ผลต่อผลิตภาพและการยกเลิกในท้ายที่สุด

  • ผู้เขียนยังคงชอบตัวผลิตภัณฑ์มาก และมองว่าในทางทฤษฎีทุกอย่างทำงานได้ดีมากพร้อมมีโอกาสอีกมาก
    • ได้สร้าง harness ของตนเองบน Claude และยังชื่นชม Claude Caude ที่จัดการ GitHub issue อยู่เบื้องหลังได้ดี
    • อีกทั้งยังใช้ Claude Cowork เขียน Nerd Enzyklopädie ต่อเนื่องอยู่ด้วย
  • ผลิตภาพไม่ได้เพิ่มขึ้นแค่หลักหน่วยเท่า แต่เพิ่มขึ้นถึงระดับ หนึ่งลำดับขั้น ทำให้สามารถนำไอเดียในหัวไปสร้างจริงได้เร็วและง่ายกว่าหลายปีก่อนมาก
    • ศักยภาพของผลิตภัณฑ์และประโยชน์ที่ใช้งานได้จริงจึงเห็นได้ชัด
    • พร้อมกับมีคำชื่นชมว่าองค์ประกอบของฟีเจอร์ต่าง ๆ ถูกออกแบบมาอย่างใส่ใจ
  • ในขณะเดียวกันก็เข้าใจถึงความยากทั้งเชิงเทคนิคและเชิงองค์กรของการให้บริการผลิตภัณฑ์แบบนี้ และการขายงานอนุมานก็มีโครงสร้างต้นทุนแบบ incremental cost ที่ต้องใช้ทรัพยากรประมวลผลเพิ่มในระดับใกล้เคียงกันทุกครั้งที่มีเวลาใช้งานเพิ่มหรือมีลูกค้าใหม่
    • จึงเป็นโครงสร้างที่อาศัย economies of scale ได้ยาก
    • ไม่ได้ปฏิเสธว่าความยากในการให้บริการนั้นมีอยู่จริง
  • สุดท้ายมองว่า Anthropic ดูเหมือนจะรับลูกค้าใหม่จำนวนมากพร้อมกันไม่ไหว จึงตัดสินใจยกเลิกบัญชีพร้อมกับพูดในเชิงว่าช่วยแบ่งเบาภาระให้บริษัท
    • ช่องว่างระหว่างความรักต่อผลิตภัณฑ์กับปัญหาในการใช้งานจริงนำไปสู่การตัดสินใจยกเลิก
    • สรุปได้ว่าเป็นผลสะสมจากการซัพพอร์ตที่ย่ำแย่ คุณภาพที่ลดลง และความสับสนเรื่องขีดจำกัด

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

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

 
iolothebard 4 일 전

“ในช่วงไม่กี่สัปดาห์แรก ความเร็วก็เร็วและโควตาโทเคนก็ดูยุติธรรม”??
ใครเป็นคนกำหนดว่ายุติธรรมล่ะ?
 
savvykang 5 일 전

บริการราคา 220 ดอลลาร์ต่อเดือนยังทำเวลาใช้งานได้ไม่ถึง 99.5% แบบนี้ก็ชวนให้คิดว่าผู้ใช้ถูกมองเป็นหมูในอวยหรือเปล่า ส่วน Claude.ai นั้นยังทำได้ไม่ถึง 99% ด้วยซ้ำ
 
geralt 5 일 전

ตอนนี้คุณใช้บริการอะไรแทนอยู่ครับ? Codex เหรอ? ผมยังใช้อยู่ต่อเพราะมองไม่เห็นทางเลือกอื่น...
 
vndk2234 4 일 전

ก็จริงที่ว่าไม่มีทางเลือกอื่น แต่ผมเพิ่งเคยใช้บริการที่ยังรักษา uptime 99% ไว้ไม่ได้เป็นครั้งแรกในชีวิตนี่แหละ..
 
lamanus 4 일 전

GitHub คงไม่ใช่แค่ต้องสู้กับ 99 แล้ว น่าจะต้องสู้กับ 95 ด้วย
 
savvykang 4 일 전

Claude ai มีปัญหาเรื่องการซิงก์ข้อมูลโปรเจกต์ เลยย้ายออกได้ไม่ง่าย และในช่วงนี้ผมน่าจะใช้ Claude Code, Codex และ Gemini CLI ควบคู่กันไปก่อน
 
savvykang 4 일 전

ถ้ามีทางเลือกอื่น ผมก็อยากรู้เหมือนกัน
 
picopress 5 일 전

ขีดจำกัดการใช้งานรายเดือน
ขีดจำกัดการใช้งานรายปี
ฮ่าๆๆ...
 
emptybynature 4 일 전

ถ้า Claude กับ ChatGPT แข่งกัน ผู้บริโภคก็ได้ประโยชน์ครับ 555 หวังว่า Gemini จะเข้ามาร่วมวงเร็ว ๆ ด้วย แล้วโมเดลจากจีนก็กำลังพัฒนาแบบก้าวกระโดดมาก ๆ หวังว่าทุกเจ้าจะสู้กันอย่างดุเดือดนะครับ
 
GN⁺ 5 일 전
ความคิดเห็นจาก Hacker News

  • ต่อให้เขียนเอกสารสเปกละเอียดเป็นหลายไฟล์พร้อม Markdown และโค้ดตัวอย่างแล้วส่งให้ Claude Sonnet ก็ยังมีกรณีที่มันตกหล่นข้อกำหนด สร้างโค้ดซ้ำ หรือใส่การแปลงข้อมูลที่ไม่จำเป็นเข้ามา
    ยังเห็นลักษณะเหมือนฝืนแต่งให้แค่เทสต์ผ่านเท่านั้น สุดท้ายเลยกลายเป็นต้องอ่านโค้ดจำนวนมหาศาลแทนที่จะได้เขียนโค้ด
    เดิมทีพอลงมือทำจริงก็รู้แล้วว่า การอ่านโค้ดและการสร้าง mental model ยากกว่าการเขียนโค้ดมาก และพอใช้ Gen AI ภาระส่วนนั้นยิ่งหนักขึ้น
    เลยมองว่าในระดับราคาของ Anthropic ตอนนี้ ขาดทุนสุทธิ
    เพราะไม่ได้ทำ vibe coding แต่กำลังสร้างซอฟต์แวร์ที่ผู้ใช้จริงต้องพึ่งพาอยู่ จึงคิดว่าจะยกเลิกการสมัครเร็ว ๆ นี้

    • อย่าให้ AI เขียนโค้ดแทนทั้งหมด แต่ใช้มันเหมือน ผู้ช่วยรีวิวโค้ด จะดีกว่า
      ให้มันช่วยตรวจในวงจรเทสต์·ลินต์ตามปกติ ประเมินไลบรารีจาก third-party ได้เร็วขึ้น ค้นคว้าหัวข้อใหม่ ร่าง RFC·เอกสารออกแบบ หรือใช้เป็นคู่สนทนาเวลาติดปัญหายาก ๆ วิธีนี้เหมาะกว่า
      โดยรวมยังไม่ค่อยชอบบริษัท AI และยังรู้สึกติดใจกับเรื่องที่มันตั้งอยู่บนการละเมิดลิขสิทธิ์ แต่โมเดลรุ่นล่าสุดก็ฉลาดจนน่าเหลือเชื่อในบางด้าน
      ไม่จำเป็นต้องรับเอา vibecoding hype แบบเกินจริง แค่ใช้เป็นเครื่องมือเพิ่มประสิทธิภาพก็มีคุณค่ามากพอแล้ว
      จะไม่ใช้เลยก็ได้ และไม่ได้มีหน้าที่ต้องจ่ายเงินให้บริษัทไหน แต่ก็มองว่าไม่ควรปัดเทคโนโลยีนี้ทิ้งทั้งก้อนเพียงเพราะดูจาก vibe coding
    • ควรเลิกโยนทุกอย่างให้ทีเดียว แล้วหันมา ซอยงานและ micromanage แทน
      อย่ามอบสเปกระบบทั้งหมดให้มัน ออกแบบเอง แล้วถ้าจำเป็นค่อยให้ช่วยด้านการออกแบบ ส่วนการ implement ก็สั่งทีละอย่างจะได้ความแม่นยำสูงกว่า
      ถ้าตรวจและให้แก้ในแต่ละขั้นก่อนค่อยไปต่อ ก็ยังเร็วกว่าเขียนเองทั้งหมด และควบคุมได้มากกว่ามาก
    • วิธีเขียนสเปกละเอียดแล้วโยนให้ AI ทำทั้งก้อน ไม่ใช่วิธีที่เหมาะที่สุด
      มันใกล้เคียงกับ vibecoding ที่มีขั้นเอกสารเพิ่มเข้ามาอีกชั้นหนึ่ง และถ้าอยากลดงานจัดระเบียบ ก็ควรใช้โมเดลที่ดีที่สุดของช่วงนั้นมากกว่า Sonnet
      ถึงอย่างนั้น ไม่ว่าโมเดลไหนก็ไม่ได้จัดการทุกอย่างได้สมบูรณ์แบบอยู่ดี จึงไม่ควรใช้แบบทั้งหมดหรือไม่ใช้เลย
      ทางที่เป็นจริงกว่าคือยังตัดสินใจด้วยตัวเองต่อไป และใช้ AI เฉพาะช่วงที่มันช่วยเร่งงานได้
      วิศวกรที่ไม่ใช่ระดับจูเนียร์ส่วนใหญ่ก็มักลงตัวแบบนั้น และควรมองข้ามคำโฆษณาเรื่องการสร้างแอปอัตโนมัติบน LinkedIn หรือ SNS ไปเสีย
    • ปัญหาที่หลายคนเจอน่าจะมาจาก ความคาดหวังที่ไม่สมจริง
      แม้ใช้ในลักษณะคล้ายกันก็ยังเขียนโค้ดได้เร็วขึ้นและคุณภาพดีขึ้น แถมภาระที่ข้อมือก็ลดลงมาก
      ความต่างน่าจะอยู่ที่มอบหมายแค่ส่วนที่ AI ทำได้ และควบคุมขอบเขตให้แคบและค่อยเป็นค่อยไป
      การเปลี่ยนแปลงเล็ก ๆ ที่ชัดเจนนั้นรีวิวได้ง่าย แต่ถ้าต้องรับ กองโค้ด 10,000 บรรทัด ทุกวันก็ประเมินยาก
      อาจกำลังกดมันหนักเกินไป เร็วเกินไป และเร็วเกินจังหวะที่ควร
      ถ้าจูนสมดุลได้ก็จะเห็นคุณค่า แม้อาจไม่เร็วแบบก้าวกระโดดเท่าที่คาดหวัง แต่ก็น่าจะยังเร็วกว่า ทำคนเดียว
    • ดูเหมือนจะใช้ไม่เหมือนคนอื่น แต่ถ้าเขียนสิ่งที่ต้องการและวิธีที่ต้องการให้ชัด Opus 4.7 จะช่วยวางแผนให้ แล้วก็ค่อยตรวจมันอย่างละเอียด
      ยังต้องตรวจสอบและยืนยันบ่อย และแผนก็ต้องแก้หลายรอบ แต่ตอน implement ก็ยังใช้ Opus ต่อ
      ตอนนี้โมเดลเหมือนจับแคชไว้ จนมีคำเตือนว่าอย่า implement ด้วย Sonnet
      แม้ต้องใช้เวลาอ่านทำความเข้าใจและแก้มือเองบ่อย แต่โดยรวมก็ยังจัดการได้ภายใน Pro subscription

  • ใช้ Claude Opus ได้ค่อนข้างมีประสิทธิภาพ และในแพ็กเกจระดับกลางก็ไม่ได้ชนลิมิตบ่อยนัก
    วิธีทำงานใกล้กับ copilot มากกว่า autopilot คือโยนให้แค่งานขอบเขตจำกัดผ่านพรอมป์ต์ แล้วตรวจแทบทั้งหมด
    สำหรับการใช้งานแบบนี้ รู้สึกว่าโมเดลแถวหน้าตอนนี้เกือบจะ ดีพอใช้งานจริง แล้ว
    อยากให้มีโมเดลโอเพนซอร์สที่เทรนบนโค้ดที่มีไลเซนส์ถูกต้อง เพื่อให้ LLM-assisted coding กลายเป็นของทั่วไป

    • ฉันก็ใช้แบบ copilot คล้ายกันและโดยรวมพอใจ แต่รู้สึกแรงมากว่าผู้ให้บริการอยากผลักเราไปสู่โหมด autopilot
      ทั้งอยากให้ใช้โทเคนมากขึ้นเพื่อจะได้เก็บเงินเพิ่ม และในขณะเดียวกันก็ดูเหมือนผู้ใช้ใช้เกินคาดจนโครงสร้างราคาปัจจุบันทนไม่ไหว
      ถ้าทางออกสุดท้ายคือให้ขยับไปแพ็กเกจแพงขึ้น มันก็ไม่ได้ขัดกันเสียทีเดียว
    • รู้สึกว่า การทำให้ LLM-assisted coding กลายเป็นสินค้าโภคภัณฑ์ มันเกิดขึ้นแล้วหรือเปล่า
      เดือนละ 100 ดอลลาร์ก็พอ และในประเทศพัฒนาแล้วก็ไม่ใช่ว่าจะหาบ้านที่ค่าไฟถูกกว่านี้ได้ง่าย
      สำหรับฉัน LLM-assisted coding คือการเข้าใจทุกการเปลี่ยนแปลงและทุกบรรทัดอย่างครบถ้วน ถ้าไม่ใช่ก็เป็น vibe coding
      ถ้ายึดหลักนี้จริงจัง ก็มองว่าใช้โควตา $100 tier ให้หมดได้ยาก
    • ฉันก็เป็น copilot ไม่ใช่ autopilot
      ในหลายโมเดลนี่คืออันที่ดีที่สุดเท่าที่รู้สึก และไม่ได้ใช้ให้มันทำงานจริงเป็นหลัก แต่ใช้เป็น ตัวแทน search engine เป็นครั้งคราวมากกว่า
      ไม่เคยรู้สึกว่า LLM มีประสิทธิภาพในการทำงานแทนจริง ๆ และคิดถึงยุคที่เอกสารเทคนิคยังใช้งานได้ดี
      ท้ายที่สุด Claude ดูใกล้เคียงกับ ไม้ค้ำที่คอยอุดช่องว่างของ developer experience มากกว่า
    • ใช้เฉพาะ Claude Opus บน Max 5x แบบ xhigh และไม่ใช้ agent หรือ MCP ใช้แค่ Claude Code เท่านั้น
      ใช้ให้หมดโควตานี่ยากมาก และแม้จะโยนงานจริงให้เยอะ โดยเฉลี่ยต่อสัปดาห์ก็จบที่ราว 30%
      แต่ตอนอยู่ Pro กลับชนลิมิตบ่อยแบบน่าขำ และบางทีคำขอเดียวก็เกิน 100% ของเซสชันจนต้องจ่ายเพิ่ม
      Max 5x ให้ความรู้สึกมากกว่า 5 เท่าค่อนข้างเยอะ แต่ Anthropic จัดการเรื่องอย่าง surge rate ไว้คลุมเครือมาก เลยไม่มั่นใจ
      พวกโพสต์แนว Opus พังแล้ว ไป Codex กันเถอะ ที่ล้น HN ช่วงนี้ ฉันมองอย่างระแวงพอสมควร
      บางอันอาจเป็นแค่การระบายอารมณ์ แต่บางส่วนก็มีกลิ่น astroturfing
    • ฉันก็คล้ายกัน
      ใช้กับงานจริงเยอะมากแต่ไม่เคยชนลิมิตเลย
      การปล่อย LLM วิ่งเป็นชั่วโมง ๆ ดูเหมือนสูตรสำเร็จในการเสียเวลาตัวเองไปกับการไล่ว่ามันทำอะไรและทำไมถึงทำแบบนั้น

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

    • ถึงอย่างนั้น ผลิตภัณฑ์เหล่านี้ก็ ทดแทนกันได้ สูง
      ช่วงหลัง rate limit ค่อนข้างน่ารำคาญ เลยชอบ Codex มากกว่า CC แต่รูปแบบการทำงานแทบไม่ต้องเปลี่ยน
    • อย่างน้อยนักลงทุนบางส่วนก็หวัง สถานะผูกขาด จากตรงนี้
      อยากทุ่มเงินให้เหนือคู่แข่งจนเกิดช่องว่างที่ไล่ไม่ทัน แล้วค่อยตั้งราคาได้ตามใจ
      แต่ตอนนี้การแข่งขันยังดุเดือด และในฐานะเครื่องมือเขียนโค้ด Anthropic ยังดีที่สุดก็จริง แต่ความได้เปรียบนี้เล็กลงกว่าเดิม
      พูดตรง ๆ แค่ Opus 4.5 ก็ไปถึงระดับที่ใช้งานได้ดีพอแล้ว และตอนนี้มีหลายโมเดลที่อยู่ระดับนั้น
      Gemini Pro 3.1 ก็คล้ายกัน และ Codex ตอนนี้ก็ดีกว่า Opus 4.5 และใกล้ 4.7
      ฉันเองก็สลับโมเดลและเอเจนต์บ่อยในโปรเจกต์เดียวกัน โดยแทบไม่มีต้นทุนการย้ายเลย
      แค่รัน claude แทนด้วย gemini, copilot, hermes ก็พอ จึงไม่ได้ผูกกับโมเดลใดลึกมาก
      ผู้ให้บริการคงพยายามใส่ฟีเจอร์เพื่อสร้างการผูกติด แต่โมเดลชั้นนำฉลาดมากจนหลายครั้งแค่บอกสิ่งที่ต้องการก็พอ
      ตอนนี้ moat ที่สม่ำเสมอเพียงอย่างเดียว น่าจะเป็นความสามารถในการสร้างโมเดลที่ดีที่สุด และแม้กระทั่งสิ่งนั้นก็ยังตื้นพอที่ถ้า Claude Code หายไปพรุ่งนี้ก็ไม่ถึงกับร้ายแรง
      โมเดลโอเพนที่โฮสต์เองได้ก็ใกล้มากแล้วเช่นกัน
    • โชคดีที่ AI แบบโลคัล กำลังกลายเป็นจริงขึ้นทุกวัน
    • เพราะแบบนี้จึงมองว่า โมเดลโอเพนซอร์ส·โมเดลอธิปไตย ที่ทุกคนเข้าถึงได้และเปิดไว้ได้ตลอดเวลาคือแกนสำคัญ
      การแข่งขันระหว่าง OpenAI กับ Anthropic ก็น่าสนใจ และถ้ากระแสโอเพนซอร์สเสริมเข้ามาด้วย ก็น่าจะไปถึงจุดนั้นในไม่ช้า
    • นึกภาพสถานการณ์ที่เจ้าของทำ rug pull เอง หรือ Broadcom เข้าซื้อแล้วเริ่มรีดได้ชัดเจนเลย

  • Claude ใช้ลิมิตเซสชัน 100% พร้อมค่าใช้จ่ายเพิ่มไปกับ Sonnet medium effort แล้วนั่งคิดอยู่ 53 นาที ก่อนจะตอบแค่ว่า
    API Error: Claude's response exceeded the 32000 output token maximum...

    • แล้วมุกที่ว่าแม้แต่วันที่เจ็ดก็ยังเป็น API Error: Claude's response exceeded the 32000 output token maximum ก็เข้ากันเป๊ะ
    • คงไม่ปล่อยให้มันคิดเกิน 5 นาทีแล้ว
    • พอเกิดสถานการณ์แบบนี้ก็อดสงสัยไม่ได้ว่าเหล่า agentic/vibe coder จะบอกหัวหน้าว่า "พรุ่งนี้ก็ยังทำงานไม่ได้" หรือเปล่า
    • ถ้าเอาข้อความ error นั้นไปแปะกลับเข้า Claude ตรง ๆ มันมักจะทำต่อได้
      เห็นแบบนี้มาหลายครั้งในช่วงหลายเดือนที่ผ่านมา ตอนแรกคิดว่าเป็นปัญหา AWS Bedrock แต่ดูเหมือนจะไม่ใช่แค่นั้น
    • อยากรู้ว่าใช้แพ็กเกจ Max 5x หรือ 20x กันแน่

  • ฉันกับเพื่อนร่วมงานหลายคนเจอ ความสามารถด้านการรับรู้ลดลง ของ Claude อย่างชัดเจนในช่วงสองเดือนที่ผ่านมา
    4.5 ใช้ได้ 4.6 ดีมากจริง ๆ และถ้าวัดจาก benchmark ส่วนตัว 4.5 แทบจะตามแค่ 2-way pointer merge loop ได้ ส่วน 4.6 ได้ถึง 3-way และ 1M context ไปถึง k-way
    ความสามารถในการไล่ตามแบบนี้ทำให้มันมีประโยชน์กับการเข้าใจและแก้โค้ด production จริง
    แต่ตั้งแต่สองเดือนก่อน 4.6 เริ่มลืมง่ายและตัดสินใจโง่ ๆ บ่อยขึ้น และพอเทียบกันแล้วก็พบว่าไม่ได้เป็นแค่ฉันคนเดียว
    4.7 ก็ไม่ได้ดีขึ้นมาก และช่วงไม่กี่สัปดาห์หลังเหมือนกำลังสู้กับ auto level of effort downgrade ตลอดเวลา
    เวลาเริ่มรู้สึกว่ามันโง่ พอไปดูการตั้งค่าก็พบว่ามันถูกลดลงเงียบ ๆ เลยสร้างแรงเสียดทานมาก
    เรารู้แล้วว่าโมเดลที่ดีแบบช่วงแรกของ 4.6 นั้นเป็นไปได้ ปัญหาคือระหว่างเอาไปปล่อยสู่ตลาดมวลชน Anthropic ไป throttle และ downgrade จนใช้งานจริงได้น้อยลง
    ฉันคิดว่าอีกไม่นานถ้า DeepSeek ไปถึงระดับ more-than-good-enough แบบ 4.6+ ได้ ผู้คนก็คงหนีจากแนวทางของ Claude ที่จ่ายมากขึ้นแต่ได้กลับมาน้อยลง
    ไม่ได้ต้องการอะไรที่ยิ่งใหญ่กว่าเดิม แค่อยากใช้สิ่งที่ทำได้อยู่แล้วอย่างเสถียร ควบคุมได้ และเป็นแบบ provisioned ไม่ใช่แบบ meter

    • ปัญหานี้เกิดขึ้นจริง และ Anthropic ก็ยอมรับเองใน https://www.anthropic.com/engineering/april-23-postmortem
      เวลาบริษัทพลาดแบบนี้ก็แน่นอนว่าน่าหงุดหงิด แต่เขาก็ผ่อนข้อจำกัดอยู่ช่วงหนึ่งจนแทบเป็นการชดเชย และที่สำคัญคือรับมือค่อนข้างโปร่งใส
      ไม่แน่ใจว่าบริษัท AI รายใหญ่อื่นจะโปร่งใสได้ระดับนี้หรือเปล่า เลยถึงจะหงุดหงิดกับ Claude ก็ยังเคารพวิธีจัดการของเขา
    • ถ้าไม่ได้ตั้ง 4.7 เป็น xhigh หรือ max effort ก็แทบจะเสียเวลาเปล่า

  • การสมัคร max20 ของฉันแทบไม่ได้ใช้งานเลยตั้งแต่เดือนเมษายน และ Codex 5.4 รวมถึง 5.5 ตอนนี้ให้ความรู้สึกต่างกันสุดขั้วแม้ใช้ fast mode
    Opus ล้มเหลวแบบดูน่าเชื่อถือ ลืมรายละเอียดสำคัญไปครึ่งหนึ่ง หรือแอบแปะพลาสเตอร์หนี้เทคนิคในนามของ pragmatic แล้วอ้างว่าสำเร็จ
    ทั้งที่จริงระบบพังหลังแก้ และพอชี้ข้อผิดพลาดมันก็ยิ่งทำให้เละกว่าเดิม
    Opus ดีสำหรับทำของขอบเขต greenfield แบบวันช็อต แต่ถ้าต้องแก้ซ้ำภายหลังหรือทำงาน integration ที่ซับซ้อน มัน แย่จนเป็นโทษ
    ในทางกลับกัน GPT 5.4+ จะยอมใช้เวลาเพื่อคิด edge case ก่อน และมันมักถูกจริง จึงลดจำนวนรอบ debug ต่อเนื่องแล้วค่อยส่งผลลัพธ์ที่ถูกต้อง
    ไม่มีอาการหลุดเข้า loop คิดอย่าง "ไม่น่าใช่มัลแวร์" หรือ "เดี๋ยวก่อน" เป็นหลายนาที แม้แค่แก้สคริปต์บรรทัดเดียว

    • mental model ของฉันต่อ LLM คือ ไม่ได้คาดหวังให้เคี้ยวหมากฝรั่งไปเดินไปได้พร้อมกัน
      การเก็บกวาดโค้ดกับการทำฟีเจอร์ใหม่เป็นคนละงาน และพวกตระกูล GLM ถึงจะดูฉลาดกว่าบนผิวหน้า แต่พอรีวิวโค้ดจริงก็ยังต้องมี build/prune cycle อยู่ดี
    • มีมุกได้เลยว่าถ้าไม่ใช้ max20 จะยกให้ฉันได้ไหม
    • เวิร์กโฟลว์ที่มีประสิทธิภาพที่สุดคือสมัครทั้งคู่ไว้ แล้วให้ Claude รับบท ยัดฟีเจอร์เข้าไปให้ก่อน ส่วน Codex ก็ใช้รีวิวว่า
      "นี่มันเต็มไปด้วย race condition ไม่ใช่เหรอ"
      ตอนนี้ใช้แค่ Codex เพราะ Claude เชื่อถือยาก และชอบปล่อย data race หรือเงื่อนไขปฏิเสธที่ตกหล่นไว้บ่อยเกินไป

  • ตอนนี้ใช้ Aider อยู่ และเพราะนโยบายการเทรนใหม่ก็คงจะยกเลิก Github multi AI bundle subscription ด้วย
    การใช้ Aider คู่กับโมเดลโอเพนใหม่ ๆ และคุย requirement กันด้วย Open Spec ก่อนส่งต่อ ช่วยได้มากทีเดียว

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

    • ตอน AWS ก็มีคนพูดว่า "ทำไมเขาต้องช่วยประหยัดเงินให้คุณ" แต่ในความจริงยิ่งลดราคาก็ยิ่งมีผู้ใช้มากขึ้นจนทำเงินได้มากกว่าเดิม
      บริษัท AI ก็มีแรงจูงใจแบบเดียวกัน
      ถ้าถูกลงคนก็จะใช้มากขึ้น และตราบใดที่ราคายังสูงกว่าต้นทุน สุดท้ายรายได้รวมก็อาจเพิ่มขึ้น
      แน่นอนว่าพวกเขาก็มีเหตุผลมากพอที่จะลดต้นทุนตัวเองเช่นกัน
    • ก็จริงอยู่ระดับหนึ่ง แต่เมื่อมี ข้อจำกัดด้าน capacity จริง และ Anthropic ไม่ได้ผูกขาดจึงต้องรับแรงกดดันจากการแข่งขัน แรงจูงใจทางเศรษฐกิจก็จะเปลี่ยนไป
    • ฉันมองว่าผู้คนจะเหนื่อยกับ closed-agent lock-in มากขึ้นเรื่อย ๆ
      เพราะแบบนั้นจึงสร้าง https://github.com/dirac-run/dirac ซึ่งเป็นโอเพนซอร์ส (cline fork) โดยตั้งเป้าเรื่อง ประสิทธิภาพด้านโทเคน เพียงอย่างเดียว
      คาดว่าผู้ให้บริการแบบปิดที่สร้าง lock-in จะทำให้ผู้ใช้หงุดหงิดพอในท้ายที่สุด และตอนนี้ก็กำลังหาผู้ร่วมพัฒนาอยู่ด้วย
    • ถึงจุดหนึ่งอาจมีแรงจูงใจแบบนั้นอยู่ แต่พอ รองรับผู้ใช้ไม่ไหว จนลูกค้าเริ่มหนี เรื่องก็จะเปลี่ยน
    • ฉันก็คิดแบบนั้น
      ฟังดูเหมือนทฤษฎีสมคบคิด แต่บริษัทอย่าง Anthropic ได้ประโยชน์แม้ตอนที่โมเดลทำงานไม่เสร็จ
      เพิ่งอ่านเรื่อง over editing phenomenon มาเหมือนกัน และดูเหมือนเครื่องจักรไม่เคยอยากทำให้จบจริง ๆ
      คล้ายกับแอปหาคู่ที่ไม่อยากจับคู่ให้ดีนัก
      เพราะถ้าสำเร็จ ผู้ใช้ก็จะยกเลิกการสมัคร

  • เมื่อวานเป็นช่วงที่ทำให้ตาสว่าง
    ลองให้ Claude Code ที่ต่อกับ local LLM ทำงาน extract ง่าย ๆ แต่มันกลับนั่งครางอยู่ 10 นาที
    พอเอาข้อมูลและพรอมป์ต์ชุดเดียวกันไปใส่โมเดลโดยตรงผ่าน UI แชตของ llama_cpp กลับจบแบบ single-shot ได้ในไม่ถึง 1 นาที
    เพราะงั้นคงต้องมีอะไรผิดสักอย่างทั้งในตัว coding agent เอง หรือในวิธีพูดคุยกับ LLM
    ตอนนี้กำลังหา coding agent โอเพนซอร์สที่เรียบง่ายมาก ๆ อยู่ Nanocoder ติดตั้งบน Mac ก็ไม่ค่อยได้ แถม node-modules ก็ใหญ่เกินจนไม่ชอบ ส่วน Opencode ก็ดูไม่โอเพนซอร์สเต็มที่
    ช่วงนี้เลยเล่นบท coding agent เอง พร้อมใช้เว็บ UI ของ llama_cpp แล้วมันก็ไปได้ดีพอสมควร

    • https://pi.dev/ ดูเหมือนจะได้รับความนิยม และก็สงสัยว่า Opencode ตรงไหนที่ไม่โอเพนซอร์ส
      ใน repository มี MIT License อยู่
    • อาจฟังแปลกหน่อย แต่ให้ AI ที่ใช้อยู่ตอนนี้ สร้างเอเจนต์ที่ต้องการขึ้นมาเอง ก็ได้
      ถ้าอยากได้ coding agent ที่ "เรียบง่ายสุด ๆ" แบบเฉพาะทาง นี่กลับยิ่งเหมาะ
      สัปดาห์นี้ฉันก็ทำแบบนั้นจริงเพราะหงุดหงิดกับพฤติกรรมแปลก ๆ ของ Anthropic และใช้เวลาไม่กี่วันก็ได้ของที่พอใช้
      ในกรณีของฉัน Claude Code ไม่มีบน BeOS หรือ Mac เก่า ๆ อยู่แล้ว การ bootstrap เองแล้วเอามาต่อกันจึงง่ายกว่า
      ผ่านกระบวนการนี้แล้วจะได้เรียนรู้เยอะมากว่าโมเดลทำงานจริงอย่างไร และใน Claude Code มี แพตช์พลาสเตอร์สุดเหลือเชื่อ วิ่งอยู่มากแค่ไหน
      แน่นอนว่าก็ทำให้เข้าใจความยากที่เอเจนต์หรือ harness ต้องแก้ด้วยในระดับหนึ่ง
      และเรื่องที่ Claude Code ช้ากว่า llama_cpp ฉันก็เจอเหมือนกัน เดาว่า ทราฟฟิก API น่าจะได้ลำดับความสำคัญสูงกว่าทราฟฟิกจาก subscription
      API รู้สึกเร็วกว่าเยอะ แต่ก็แพงกว่าเยอะตามไปด้วย
    • เผื่อยังไม่ได้นึกถึง ก็แค่ สร้าง coding agent แบบที่ต้องการขึ้นมาเอง
      โครงสร้างจริง ๆ เรียบง่ายกว่าที่คิดมาก
    • ถึงตอนนี้น่าจะมีเครื่องมือที่อยู่ ระหว่าง TUI กับ IDE สักตัวได้แล้ว
    • สามารถรัน CC คู่กับโมเดลโลคัล ได้ และไม่ได้ยากขนาดนั้น
      เคยลองจริงโดยเอา shim บาง ๆ ไปครอบ vLLM ให้เปลี่ยนแค่รูปแบบ endpoint

  • บางครั้ง Claude โมเดลเดียวกันก็มีรอบที่ทำพลาดด้านตรรกะ และมีรอบที่ไม่พลาด
    ดูเหมือนว่า ประสิทธิภาพของ Claude ขึ้นกับเวลา ค่อนข้างมาก และมีกราฟที่แสดงเรื่องนี้อยู่
    https://marginlab.ai/trackers/claude-code/
    อีกเรื่องที่ไม่ค่อยมีใครพูดกันในที่สาธารณะคือ แม้เป็นโมเดลเดียวกัน ผลลัพธ์ก็เหมือนต่างกันพอสมควรตาม quantization
    4-bit กับ 8-bit ใช้ทรัพยากรคำนวณต่างกัน และคุณภาพเอาต์พุตก็ต่างกัน
    https://newsletter.maartengrootendorst.com/p/a-visual-guide-to-quantization
    รู้ดีว่า frontier model ไม่ได้ทำงานเหมือนกันเป๊ะอยู่แล้ว แต่ช่วงพีก ๆ ก็อดสงสัยไม่ได้ว่ามี fidelity dial อยู่ที่ไหนสักแห่งเพื่อกดใช้หน่วยความจำหรือทรัพยากรให้น้อยลงแล้วทำให้ประสิทธิภาพลดลงหรือเปล่า

    • ไม่แน่ใจว่ากราฟนั้นแสดง ความสัมพันธ์ตามเวลา จริงหรือไม่
      เส้น 60% ยังอยู่ในช่วงความเชื่อมั่น 95% ถ้าอย่างนั้นมันอาจเป็นแค่ noise จากการวัดก็ได้