Claude Code ใช้ Bun ที่เขียนใหม่ด้วย Rust

• ตั้งแต่ Claude Code v2.1.181 ได้ฝัง Bun ที่พอร์ตมาเป็น Rust ทำให้ความเร็วเริ่มต้นบน Linux เร็วขึ้น 10% แต่ผู้ใช้ส่วนใหญ่แทบไม่สังเกตเห็นความเปลี่ยนแปลง
• เมื่อตรวจสอบสตริงในไฟล์รัน จะพบว่าเป็น Bun v1.4.0 ที่ยังไม่มีแท็กทางการ และยังเห็นพาธไฟล์ซอร์สของ Rust ได้ด้วย
• พบ ชื่อไฟล์ .rs จำนวน 563 ไฟล์ ใน ~/.local/bin/claude รวมถึง src/runtime/bake/dev_server/mod.rs เป็นต้น
• สามารถตรวจสอบได้อีกทางว่าเวอร์ชันที่ฝังอยู่คือ 1.4.0 โดยใช้ BUN_OPTIONS พรีโหลดไฟล์ TypeScript แล้วพิมพ์ Bun.version
• เวอร์ชัน Rust ถูกเผยแพร่ในรูปแบบ Bun canary และตอนนี้รันใช้งานจริงผ่าน Claude Code บนอุปกรณ์ หลายล้านเครื่อง แล้ว

---

Bun บน Rust ที่ฝังอยู่ใน Claude Code

• ตาม Rewriting Bun in Rust ระบุว่า ตั้งแต่ Claude Code v2.1.181 ที่ออกเมื่อวันที่ 17 มิถุนายน ได้เปลี่ยนมาใช้ Rust port
  • ความเร็วเริ่มต้นบน Linux ดีขึ้น 10%
  • นอกเหนือจากนั้น ผู้ใช้แทบไม่สังเกตเห็นความแตกต่าง และ Jarred Sumner ประเมินเรื่องนี้ว่า “Boring is good”
  • ตอนนี้รันใช้งานจริงผ่าน Claude Code บนอุปกรณ์หลายล้านเครื่องแล้ว
• สามารถหา เวอร์ชัน Bun ที่ฝังอยู่ ได้จากสตริงในไฟล์รันของ Claude

strings ~/.local/bin/claude | grep -m1 'Bun v1'

• บน macOS arm64 จะได้ผลลัพธ์ Bun v1.4.0 (macOS arm64)
• ขณะนั้นรีลีสทางการล่าสุดบน GitHub คือ Bun v1.3.14 เมื่อวันที่ 12 พฤษภาคม ดังนั้น Claude Code จึงเท่ากับฝัง พรีวิว v1.4.0 ที่ยังไม่ออกตัวจริงไว้
• เวอร์ชัน Rust ถูกเผยแพร่เป็น Bun canary และติดตั้งได้ด้วย bun upgrade --canary

การตรวจสอบซอร์ส Rust และเวอร์ชัน

• หากดึงพาธซอร์ส Rust ออกจากไฟล์รัน จะพบ ชื่อไฟล์ 563 รายการ

strings ~/.local/bin/claude | grep -Eo 'src/[[:alnum:]_./-]+\.rs'

• ในรายการมีพาธต่อไปนี้

src/runtime/bake/dev_server/mod.rs
src/runtime/bake/production.rs
src/bundler/bundle_v2.rs

• วิธีที่ Ajan Raj แชร์ไว้คือใช้ BUN_OPTIONS พรีโหลดไฟล์ TypeScript เพื่อพิมพ์ค่า Bun.version ที่ฝังอยู่ใน Claude Code ออกมาโดยตรง

cat > /tmp/bun-version.ts <<'EOF'
console.log("embedded bun:", Bun.version);
process.exit(0);
EOF
BUN_OPTIONS="--preload=/tmp/bun-version.ts" claude --version

• คำสั่งนี้ก็แสดง 1.4.0 เช่นกัน
• ใน คอมมิตวันที่ 17 พฤษภาคม ได้มีการเปลี่ยนเวอร์ชัน package.json เป็น 1.4.0 และคงไว้เช่นนั้นตั้งแต่นั้นมา แต่ยังไม่ถูกรวมอยู่ในแท็กรีลีสนอกจาก canary

[GN⁺]

ความคิดเห็นจาก Hacker News

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

  • นี่เป็นธุรกิจที่ทำงานได้ดีอยู่แล้วและสร้างรายได้มหาศาล ดังนั้นคำถามว่า “ทำไมต้องเทคโนโลยีนี้?” จึงใกล้เคียงกับ การตัดสินใจทางธุรกิจ มากกว่าเรื่องเทคนิค เทคโนโลยีที่เลือกตั้งแต่แรกยังทำหน้าที่ได้ จึงมีเหตุผลน้อยที่จะเปลี่ยน แม้สถาปัตยกรรมจะไม่สมบูรณ์แบบก็ตาม
    การเขียนใหม่ไม่ใช่เรื่องง่ายแม้แต่สำหรับ Bun และเครื่องมือพัฒนาที่ไม่ใช่ UI ซึ่งมีสัญญา API และการทดสอบชัดเจน ก็ยังเชื่อถือได้หลังเขียนใหม่ง่ายกว่าเครื่องมือ UI ที่ฟีเจอร์คลุมเครือและมีการทดสอบไม่เพียงพอ
  • ถ้าใช้ Claude, OpenCode และ Ghostty ร่วมกัน โปรแกรมเทอร์มินัลแบบโต้ตอบจะกิน CPU และแบตเตอรี่ หนักมาก แม้แต่แล็ปท็อปที่อยู่ในโหมด sleep ทั้งคืนก็ยังร้อน ทั้งที่มีตัวอย่างก่อนหน้ามากว่า 40 ปี ตั้งแต่ curses/ncurses, Emacs, Vim ไปจนถึง MS-DOS ก็ยังสงสัยว่าทำไมต้องฝืนยัดเทคโนโลยีเว็บเข้าไป
  • เคยเห็นบทความว่าบริษัท Haskell ชื่อดังย้ายไป Python เพราะความเร็วในการพัฒนาแบบวนซ้ำโดยใช้ LLM ข้อมูลฝึกของ React มีอยู่มาก และเวลา compile ของ TypeScript ก็สั้นกว่า Rust และภาษาอื่น ๆ มาก
    โค้ดฝั่งที่ผู้ใช้สัมผัสและเลเยอร์ UX ที่เปลี่ยนเร็ว มีแนวโน้มจะไปอยู่ในระบบ dynamic ที่รองรับ การพัฒนาแบบวนซ้ำได้รวดเร็ว ส่วนเลเยอร์โครงสร้างพื้นฐานมีแนวโน้มย้ายไปสภาพแวดล้อมระบบที่ปลอดภัยอย่าง Rust Java/C# อยู่กึ่งกลาง แต่ต่อไปสำหรับ UX ใช้ TypeScript/Python ก็พอแล้ว ส่วนงานระบบ Rust เหมาะกว่า ทำให้พื้นที่ของ Java/C# น่าจะลดลง
    https://avi.press/posts/2026-07-10-after-7-years-in-producti...
  • ถ้ามองว่า Anthropic ใช้ AI เขียน Claude Code แล้ว JavaScript ก็ไม่ใช่ตัวเลือกที่แย่ ข้อมูลฝึกมีมาก และยังหลีกเลี่ยงปัญหา มัลติเธรดกับการจัดการหน่วยความจำ ที่อาจทำให้ AI สับสนในภาษาประสิทธิภาพสูงอื่น ๆ จึงเหมาะกับการใช้ AI สร้างซอฟต์แวร์อย่างรวดเร็ว
  • OpenAI ตัดสินใจ เขียน Codex ใหม่ด้วย Rust เมื่อประมาณ 1 ปีก่อน ถ้าการเขียนใหม่ง่ายจริง ก็ควรถามด้วยว่าทำไมต้องมี Bun และทำไมไม่ย้ายโค้ด JavaScript ทั้งหมดไป Rust
    https://github.com/openai/codex/discussions/1174

• ถ้าดูต้นฉบับของ Jarred เหตุผลในการย้ายดูชัดเจนว่า ส่วนที่ต้องทำเองด้วยมือใน Zig ถูกทำให้เป็นอัตโนมัติใน Rust ทั้งมนุษย์และ agent ต่างก็ไม่ deterministic ดังนั้นถ้าต้องติดตาม lifetime ของหน่วยความจำและการ free แบบ explicit ใน Zig ด้วยมือ บั๊กตกหล่นจะสะสมยาว แต่ Rust กำจัดบั๊กประเภทนี้ได้ จึงเป็นจุดประนีประนอมที่ดีในแง่การจัดการงานวิศวกรรม
  โดยเฉพาะ ข้อผิดพลาดจาก compiler คือราวกันตกแบบ deterministic ที่จำเป็นสำหรับ coding agent และถ้าให้ Claude มีวิธีทดสอบความถูกต้องพร้อมเป้าหมายว่า “ทำให้ compile ได้” ก็จะทำงานได้ดี แนวทางทั่วไปที่เปลี่ยนผลลัพธ์เชิงความน่าจะเป็นให้เป็นการรับประกันที่แน่นอนด้วยการทดสอบแบบ deterministic ผมสรุปไว้ที่ https://michael.roth.rocks/blog/verification-surface/

  • Zig และ C ไม่เหมาะเมื่อสร้าง allocation ขนาดเล็กจำนวนมากที่ lifetime ไม่เกี่ยวข้องกัน หากต้องการใช้ให้ทนทาน ต้อง จัดการ lifetime เอง เช่น ผูก allocation ไว้กับ arena หรือใช้ buffer คงที่
    ถ้าทำแบบนั้น Zig ก็ทนทานได้พอ ๆ กับ Rust แต่ถ้าต้องการรูปแบบ allocation แบบภาษา managed ที่ LLM ชอบ Zig ก็ไม่เหมาะ
  • สิ่งที่จัดการให้อัตโนมัติจริง ๆ คือภาษาที่มี garbage collection ใน Rust ก็ยังต้องคิดและติดตาม lifetime ของหน่วยความจำ แต่ borrow checker จะกันการจัดการที่ผิดและให้ feedback เพื่อแก้ทันที จึงเหมาะให้ LLM ใช้ พารามิเตอร์แบบ immutable reference โดยค่าเริ่มต้นยังช่วยป้องกันปัญหาประสิทธิภาพใหญ่ ๆ ด้วย
  • ตอนนี้ Bun มี Rust แบบ unsafe อยู่มาก ยังน่าสงสัยว่าจะพูดได้ไหมว่ากำจัดบั๊กประเภทนั้นโดยอัตโนมัติ: https://news.ycombinator.com/item?id=48967630
  • จากประสบการณ์ของผม LLM จับบั๊กหน่วยความจำได้ค่อนข้างง่าย เรื่องนี้ดูเป็นแค่ งานการตลาด ที่ประสบความสำเร็จของ Anthropic เท่านั้น
  • เท่าที่จำได้ การเขียนใหม่ด้วย Rust ครั้งนี้เป็น unsafe ทั้งหมด ดังนั้นมีความเป็นไปได้สูงว่าจะไม่ได้กำจัดปัญหาดังกล่าวโดยอัตโนมัติ

• ไม่ว่าการประเมินของ Jarred หรือ Simon Willison จะเป็นอย่างไร ผมมองเรื่องนี้ค่อนข้างลบ ปัญหาที่ใหญ่กว่าการที่ Anthropic ซื้อ Bun หรือการเขียนใหม่ด้วย AI คือวิธีดำเนินการที่ยังไม่เป็นผู้ใหญ่ เริ่มจากท่าทีว่า “ก็แค่ branch ของฉันเอง และคนอื่น overreact” แล้ว merge PR กว่า 1 ล้านบรรทัด ภายในไม่ถึงเดือน
  การสื่อสารทำได้แย่มากจนบั่นทอนความเชื่อมั่นและเพิ่มความแตกแยก และก็สงสัยว่าการทำตามแนวทางที่ทีม TypeScript ใช้ใน 7.0 มันยากขนาดนั้นเลยหรือ

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

• Bun v1.4.0 ที่รวมอยู่ใน Claude ดูเหมือนจะเป็นเวอร์ชัน preview ที่ยังไม่เผยแพร่ ถ้าอย่างนั้นก็เหมือนโปรเจกต์ FOSS อย่าง Bun ถูกเปลี่ยนเป็นอีกสิ่งหนึ่งอย่างเงียบ ๆ ดีแล้วที่ตอนนั้นแค่ทิ้ง TODO ไว้ว่าจะตรวจสอบและยังไม่ได้นำมาใช้
  หาเอกสาร governance ของ Bun ไม่เจอ เลยสงสัยว่าตอนนี้ในทางปฏิบัติ Anthropic เป็นผู้ตัดสินใจทั้งงานที่จะทำและว่าจะ merge หรือไม่ใช่หรือเปล่า

  • ไม่ค่อยเข้าใจข้อสรุปที่ว่าการเปลี่ยนเป็น Rust จะทำให้โปรเจกต์ตาย
  • PR เปิดเป็นสาธารณะ ทุกคน build ใช้เองได้ เพียงแต่ทีม Anthropic เลือกใช้ก่อนเท่านั้น
  • เท่าที่รู้ โครงสร้างในทางปฏิบัติขึ้นอยู่กับว่า Jarred ยินดีรับในสัปดาห์นั้นหรือไม่ ใน changelog ของ Claude Code มีการระบุการเปลี่ยนเวอร์ชันเป็น Bun 1.4.0 มาตั้งแต่เกือบหนึ่งเดือนก่อนแล้ว แต่เพราะเป็นบันทึกที่ AI เขียน จึงไม่น่าแปลกใจถ้าคนส่วนใหญ่ไม่ได้อ่าน
  • ผมเองก็เคยตรวจสอบการนำ Bun มาใช้ แต่ตัดสินใจไม่ใช้เพราะ ความไม่เสถียร และเมื่อดูเรื่องนี้แล้วก็น่าจะเป็นการตัดสินใจที่ถูกต้อง

• ไม่เข้าใจว่าทำไมต้องจัดการเรื่อง Bun ให้ซับซ้อนขนาดนี้ ถ้าเอเจนต์สามารถย้าย Zig ไปเป็น Rust ได้ Claude Code ก็น่าจะ เขียนใหม่เป็น Rust โดยตรง จาก JavaScript เพื่อกำจัดการพึ่งพารันไทม์และเพิ่มประสิทธิภาพได้

  • ถ้ามองว่าการเขียน Bun ใหม่ด้วย Rust แทบไม่เกี่ยวกับกลยุทธ์ผลิตภัณฑ์ของ Anthropic ก็ไม่มีเหตุผลให้สับสน
  • ถ้ามองเฉพาะ Claude Code การเขียนใหม่ด้วย Rust โดยตรงน่าจะดีกว่า แต่ถ้าทำแบบนั้น มูลค่าการเข้าซื้อ Bun/oven.sh จะลดลงอย่างมาก
    Bun น่าจะมีผู้ใช้ทั้งภายนอกและภายใน Anthropic นอกเหนือจาก Claude Code และช่วยให้มี JavaScript runtime กับระบบนิเวศเครื่องมือที่โมเดลเขียนโค้ดอาจชอบใช้ได้ ในอนาคต Anthropic อาจให้บริการคลาวด์ที่เชี่ยวชาญด้านการรันและจัดการแอปแบบนี้ได้ด้วย และแค่ได้ชุมชนนักพัฒนามา ก็สร้างอิทธิพลได้มากกว่าการย้าย Claude Code ตัวเดียวไปเป็น Rust อย่างมาก
  • ยังสงสัยด้วยว่า Claude Code มีคอขวดด้านประสิทธิภาพจริงหรือไม่ JavaScript runtime มีระบบนิเวศเครื่องมือขนาดใหญ่และ พัฒนาปลั๊กอิน ได้ง่าย จึงถือว่าเหมาะสมเพียงพอ

• ถ้าตัดการคาดเดาและอารมณ์ออกไป สิ่งที่อยากรู้คือคุณภาพการรันจริง ต้องตรวจสอบไม่ใช่แค่ความเร็วตอนเริ่มต้น แต่รวมถึงการใช้ RAM·CPU และปัญหา loop ไม่รู้จบหรือ deadlock ด้วย หากเท่าเดิมหรือดีกว่าเดิมก็น่าประทับใจมาก
  ในฐานะนักพัฒนา ผมไม่ชอบความเป็นไปได้ที่ AI จะมาแย่งงาน แต่ถ้าใครๆ ก็สามารถสร้างซอฟต์แวร์ที่ต้องการได้ด้วยความต้องการง่ายๆ โลกก็อาจดีขึ้นได้ ถ้าไม่ชอบการเก็บข้อมูลของ Microsoft ก็ให้ AI สร้างระบบปฏิบัติการให้ ถ้าไม่ชอบการดักฟังของ Google ก็ให้ AI สร้างโทรศัพท์มือถือให้ การ พึ่งพาตนเองทางเทคโนโลยี แบบนี้อาจเป็นไปได้ และเมื่อเทียบกับสิ่งนั้น ความมั่นคงในงานของปัจเจกบุคคลก็ดูเป็นเรื่องเล็ก
  ดังนั้นการทำให้เทคโนโลยียังคงเป็นโอเพนซอร์สจึงยิ่งสำคัญ ไม่เช่นนั้นเราจะทำซ้ำโครงสร้างผูกขาดเดิม พร้อมกับสูญเสียงานไปด้วย

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

• ช่วงหลังผมใช้ Claude Code ในแท็บ Kitty แล้วเจอ segmentation fault จากนั้นทั้งแท็บก็ไม่ตอบสนองต่ออินพุตอีก มีลิงก์รายงานปรากฏขึ้น แต่คลิกไม่ได้และถูกเข้ารหัสไว้ จึงตรวจสอบไม่ได้ว่าจะส่งข้อมูลอะไรไปบ้าง

  • ในแง่ไอเดียและฟีเจอร์ Bun ดีกว่า JavaScript runtime อื่นๆ อย่างท่วมท้น แต่เสถียรภาพแย่มาก และมี segmentation fault มากกว่า Node ประมาณ 20 เท่า ตัวเลขนี้อ้างอิงจากข้อมูล telemetry ของ New Relic
  • ถ้าเชลล์ไม่ได้แสดง Segmentation fault ก็มีโอกาสสูงว่าไม่ใช่ segmentation fault แต่เป็นอาการค้าง หากเป็นข้อผิดพลาดจริง หลังกลับมาที่เชลล์แล้ว แม้จะมองไม่เห็นบนหน้าจอ ก็พิมพ์ reset เพื่อกู้แท็บกลับมาได้
  • ผมใช้ Ghostty กับ Claude Code บน MacBook สำหรับงาน แต่ยังไม่เคยเจอปัญหานี้ ก่อนหน้านี้เคยมี memory leak ที่พุ่งจนระบบค้างและต้องรีบูต แต่ช่วงไม่กี่สัปดาห์ล่าสุดหายไปแล้ว แม้ยังสรุปไม่ได้ แต่เป็นไปได้ว่า การพอร์ตไป Rust ช่วยลด memory leak
  • ตอนใช้ interface คำถามแบบโต้ตอบของ Claude ใน Ghostty ก็เคยค้างคล้ายๆ กัน โดยนอกจากการเลื่อนแล้ว ไม่รับอินพุตใดๆ รวมถึงการเลือกหรือยกเลิกด้วย แต่ไม่ได้มองว่าเกี่ยวกับ Bun
  • เวอร์ชัน Zig ก็มี segmentation fault เช่นกัน และถ้าย้ายมันไปเป็น unsafe Rust ทีละบรรทัด โค้ดที่เป็นสาเหตุก็จะยังคงอยู่เหมือนเดิม ปัญหาคงไม่หายจนกว่าจะ refactor เป็น Rust ที่เป็น idiomatic และ ปลอดภัยด้านหน่วยความจำ

• คนเหล่านี้ดูเหมือนวิศวกรที่อธิบายปัญหาเก่งและมีงบ token ไม่จำกัด ประสบความสำเร็จอย่างมากแต่ฝีมือวิศวกรรมแย่ ถ้าต้องจ่ายค่า token เอง ก็น่าจะมีแรงจูงใจทางการเงินให้เพิ่มประสิทธิภาพซอฟต์แวร์
  ความจริงที่ซ่อนอยู่ของศูนย์ข้อมูล AI คือแม้ประสิทธิภาพคลัสเตอร์ GPU จะมีแค่ 40~60% ก็ใช้เงินซื้ออุปกรณ์เพิ่มมาชดเชยได้ เหตุผลที่กลัวคู่แข่งจีนอาจเป็นเพราะพวกเขาไม่มีเงินเหลือพอให้สิ้นเปลืองแบบนั้น

• งานครั้งนี้คือ transpile และคุณภาพก็ไม่ดี โค้ดที่สร้างออกมาห่างไกลจาก Rust แบบ idiomatic จนเรียกได้ว่าอัปลักษณ์

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

• ช่วงหลัง Claude Code ไม่เสถียรกว่าเดิมมาก และมักเกิด ข้อผิดพลาดการเรนเดอร์ TUI จนประวัติการสนทนาเสียหาย

  • ผมจำใจใช้ Claude มาตั้งแต่เดือนกุมภาพันธ์ และตั้งแต่แรกก็มีข้อบกพร่องด้านการเรนเดอร์ ปัญหาการรับอินพุตคีย์บอร์ด ฯลฯ จนเป็น TUI ที่แย่ที่สุดเท่าที่เคยใช้มา แต่ในสัปดาห์ล่าสุดกลับแย่ลงไปอีก เริ่มทำให้ terminal session พัง เช่น อักขระบางตัวที่พิมพ์ไม่แสดงผล
    ถ้าส่งไปทำงานเบื้องหลัง แล้วรัน reset จากนั้นดึงกลับมา foreground ก็จะหาย พอขอให้ Claude ช่วยวินิจฉัย มันบอกว่าตัวเองไม่มีบั๊กแบบนั้นและเป็นความผิดของโปรแกรมอื่น แต่ตอนนั้นรันอยู่แค่ tmux กับ Claude หากเพิ่งใช้เวอร์ชัน Rust ก็สอดคล้องคร่าวๆ กับช่วงเวลาที่คุณภาพแย่ลง
  • บน Windows ทุกครั้งที่ปรับขนาดหน้าต่าง เอาต์พุตจะเละทั้งหมดจนต้องขอคำตอบล่าสุดใหม่อีกครั้ง ไม่ใช่ปัญหาใหม่ แต่รู้สึกว่าช่วงหลังแย่ลง
  • ไม่ได้ต่อต้าน AI เอง แต่ Anthropic ไปไกลเกินไปจนปล่อย โค้ดคุณภาพต่ำที่ AI สร้าง ออกมา วิศวกรจริงควรยังคงเข้ามาเกี่ยวข้องและกำกับเครื่องมือต่อไป แต่ดูเหมือน Anthropic จะพยายามฝากโค้ด 100% ไว้กับ AI