Cập nhật về báo cáo chất lượng gần đây của Claude Code

• Mức suy giảm chất lượng Claude mà một số người cảm nhận trong tháng qua xuất phát từ ba thay đổi riêng biệt trải dài trên Claude Code, Claude Agent SDK, và Claude Cowork, còn API không bị ảnh hưởng
• Sau khi hạ cường độ suy luận mặc định xuống medium, độ trễ và giới hạn sử dụng đã giảm, nhưng Claude Code lại tạo cảm giác kém thông minh hơn, nên mặc định này được hoàn nguyên vào ngày 7/4
• Lỗi tối ưu hóa bộ nhớ đệm được triển khai ngày 26/3 đã tạo ra trạng thái xóa lịch sử suy luận ở mọi lượt trong các phiên vượt ngưỡng nhàn rỗi, dẫn đến tình trạng hay quên, lặp lại, chọn công cụ kỳ lạ và tiêu hao usage limits nhanh hơn
• Một dòng trong system prompt đi cùng Opus 4.7 vào ngày 16/4 là một ràng buộc nhằm giảm độ dài đầu ra, nhưng khi đánh giá trên phạm vi rộng hơn thì hiệu năng của một số mô hình giảm 3%, nên đã bị hoàn nguyên ngày 20/4
• Cả ba vấn đề đều đã được khắc phục và phản ánh trong v2.1.116 phát hành ngày 20/4; việc thu hẹp khác biệt giữa bản dựng nội bộ và bản công khai, siết chặt kiểm soát system prompt, mở rộng đánh giá và rollout dần được xác định là trọng tâm để ngăn tái diễn

---

Phạm vi suy giảm chất lượng gần đây và trạng thái khôi phục

• Mức suy giảm chất lượng Claude mà một số người dùng cảm nhận trong tháng qua bắt nguồn từ ba thay đổi riêng biệt trải dài trên Claude Code, Claude Agent SDK, và Claude Cowork, còn API không bị ảnh hưởng
• Cả ba vấn đề đều đã được giải quyết và được phản ánh trong v2.1.116 phát hành ngày 20/4
• Mỗi thay đổi ảnh hưởng đến lịch trình khác nhau và những phân đoạn lưu lượng khác nhau, nên nhìn tổng thể tạo cảm giác như một sự suy giảm hiệu năng diện rộng nhưng không nhất quán
• Từ đầu tháng 3 đã có điều tra các báo cáo liên quan, nhưng ban đầu rất khó phân biệt với biến động thông thường trong phản hồi người dùng, và trong quá trình sử dụng nội bộ cũng như đánh giá thì lúc đầu không tái hiện được cùng một vấn đề
• Tính đến ngày 23/4, usage limits của mọi thuê bao đã được đặt lại

Thay đổi cường độ suy luận mặc định của Claude Code

• Khi phát hành Opus 4.6 trong Claude Code vào tháng 2, cường độ suy luận mặc định được đặt là high
• Không lâu sau, ở chế độ high đôi khi xuất hiện thời gian suy nghĩ quá dài, khiến UI trông như bị treo, và với một số người dùng thì độ trễ cùng mức sử dụng token tăng quá mức
• Mức effort của Claude Code được dùng như cách điều chỉnh giữa việc để mô hình suy nghĩ lâu hơn hay chọn độ trễ thấp hơn và tiêu hao giới hạn sử dụng ít hơn
  • Ở lớp sản phẩm, một giá trị mặc định được chọn trên đường cong tính toán thời điểm kiểm thử và truyền tới Messages API dưới dạng tham số effort
  • Các lựa chọn khác được cung cấp qua /effort
• Trong đánh giá và thử nghiệm nội bộ, medium cho kết quả độ thông minh thấp hơn một chút nhưng giảm độ trễ đáng kể trên phần lớn tác vụ
  • medium cũng ít gặp vấn đề độ trễ đuôi rất dài hơn
  • Đồng thời có lợi hơn trong việc tối đa hóa usage limits của người dùng
• Dựa trên các kết quả này, effort mặc định được chuyển sang medium, đồng thời một hộp thoại trong sản phẩm cũng thông báo lý do
• Ngay sau khi triển khai, người dùng bắt đầu cảm thấy Claude Code kém thông minh hơn
  • Nhiều thay đổi về thiết kế đã được thêm vào như thông báo khi khởi động, bộ chọn effort nội tuyến, và khôi phục ultrathink để làm cho thiết lập effort hiện tại dễ thấy hơn
  • Nhưng phần lớn người dùng vẫn ở lại với mặc định medium
• Sau khi phản ánh thêm phản hồi từ khách hàng, quyết định này đã được hoàn nguyên vào ngày 7/4
  • Hiện tại, với Opus 4.7 thì mọi người dùng đều có mặc định là xhigh
  • Còn với mọi mô hình khác, mặc định áp dụng là high
• Thay đổi này ảnh hưởng đến Sonnet 4.6 và Opus 4.6

Tối ưu hóa bộ nhớ đệm làm rơi lịch sử suy luận trước đó

• Khi Claude suy luận về một tác vụ, lịch sử suy luận đó được giữ lại trong lịch sử hội thoại, để ở các lượt sau mô hình vẫn có thể tiếp tục tham chiếu những chỉnh sửa và lý do gọi công cụ trước đó
• Vào ngày 26/3, một thay đổi nhằm nâng hiệu quả của tính năng này đã được triển khai
  • Anthropic dùng prompt caching để giúp các lần gọi API liên tiếp rẻ hơn và nhanh hơn
  • Khi có yêu cầu API, Claude ghi input token vào bộ đệm, và sau một khoảng thời gian không hoạt động thì prompt đó bị loại khỏi bộ đệm để nhường chỗ cho prompt khác
  • Mức độ tận dụng bộ đệm được quản lý cẩn thận, và cách tiếp cận liên quan đã được tóm tắt trong approach
• Theo thiết kế, nếu một phiên đã nhàn rỗi hơn một giờ thì các đoạn thinking trước đó sẽ được xóa một lần để giảm chi phí khi tiếp tục phiên
  • Vì yêu cầu đó đằng nào cũng sẽ là cache miss, nên các thông điệp không cần thiết được cắt khỏi yêu cầu để giảm số uncached token gửi tới API
  • Sau đó hệ thống được thiết kế để lại gửi toàn bộ lịch sử suy luận
  • Việc này dùng API header clear_thinking_20251015 và keep:1
• Trong triển khai thực tế đã có lỗi, khiến lịch sử thinking lẽ ra chỉ bị xóa một lần lại bị xóa liên tục ở mọi lượt cho đến khi phiên kết thúc
• Một khi phiên đã vượt qua ngưỡng nhàn rỗi, mọi yêu cầu sau đó của tiến trình đó đều được gửi tới API theo cách chỉ giữ lại khối suy luận gần nhất và loại bỏ các phần trước đó
• Vấn đề này ngày càng tệ theo kiểu tích lũy
  • Nếu Claude gửi thông điệp tiếp theo trong lúc đang dùng công cụ thì bản thân điều đó cũng trở thành một lượt mới dưới cờ bị lỗi
  • Kết quả là ngay cả suy luận của lượt hiện tại cũng có thể bị rơi mất
• Claude vẫn tiếp tục chạy, nhưng ngày càng hành động mà không còn ký ức về lý do mình chọn cách hành xử đó
  • Với người dùng, điều này hiện ra dưới dạng hay quên, lặp lại, và chọn công cụ kỳ lạ
• Vì các khối thinking tiếp tục biến mất ở các yêu cầu sau, những yêu cầu đó cũng dẫn tới cache miss
  • Các báo cáo riêng về việc usage limits bị tiêu hao nhanh hơn dự kiến được cho là bắt nguồn từ hiện tượng này
• Có hai thử nghiệm không liên quan khiến việc tái hiện ban đầu trở nên khó khăn
  • Một thử nghiệm phía máy chủ chỉ dành cho nội bộ liên quan đến message queueing
  • Một thay đổi riêng về cách hiển thị thinking đã che mất lỗi này trong phần lớn các phiên CLI
• Lỗi này nằm tại giao điểm giữa quản lý ngữ cảnh của Claude Code, Anthropic API, và extended thinking
  • Nó đã vượt qua nhiều vòng review mã của con người và review mã tự động
  • Vượt qua kiểm thử đơn vị và kiểm thử đầu cuối
  • Và cả xác minh tự động lẫn dogfooding
• Vấn đề này chỉ xảy ra ở một trường hợp góc là các phiên cũ và rất khó tái hiện, nên mất hơn một tuần mới tìm ra và xác nhận được nguyên nhân gốc rễ
• Trong quá trình điều tra, các pull request gây ra sự cố đã được backtest bằng Code Review với Opus 4.7
  • Khi được cung cấp thêm các kho mã cần thiết để thu thập đầy đủ bối cảnh, Opus 4.7 đã tìm ra lỗi
  • Còn Opus 4.6 thì không tìm ra
• Để tránh lặp lại điều tương tự, hệ thống review mã đang được bổ sung hỗ trợ đưa thêm kho mã làm ngữ cảnh
• Lỗi này đã được sửa trong v2.1.101 ngày 10/4
• Thay đổi này ảnh hưởng đến Sonnet 4.6 và Opus 4.6

Thay đổi system prompt nhằm giảm độ dài đầu ra

• Mô hình mới nhất Claude Opus 4.7 có đặc tính tạo ra đầu ra rất dài dòng hơn các mô hình trước
  • Đặc tính này cũng đã được đề cập trong thông báo phát hành, chi tiết có thể xem trong wrote about
• Sự dài dòng này giúp mô hình thông minh hơn trên các bài toán khó, nhưng cũng làm tăng số token đầu ra
• Từ vài tuần trước khi phát hành Opus 4.7, Claude Code đã tiến hành điều chỉnh để phù hợp với mô hình mới
  • Mỗi mô hình hoạt động hơi khác nhau, nên trước khi phát hành, harness và sản phẩm được tối ưu theo từng mô hình
• Để giảm độ dài đầu ra, nhóm sử dụng kết hợp huấn luyện mô hình, prompting, và cải thiện UX thinking trong sản phẩm
• Trong số đó, một dòng được thêm vào system prompt đã ảnh hưởng quá mức đến trí năng của Claude Code
  • “Length limits: keep text between tool calls to ≤25 words. Keep final responses to ≤100 words unless the task requires more detail.”
• Trong nhiều tuần kiểm thử nội bộ và các bộ đánh giá đã chạy, không thấy hiện tượng hồi quy, nên thay đổi này được tin tưởng và triển khai cùng Opus 4.7 vào ngày 16/4
• Sau đó, trong quá trình điều tra, một phép ablation với bộ đánh giá rộng hơn đã được thực hiện để tách riêng và kiểm tra tác động của từng dòng trong system prompt
• Trong một đánh giá như vậy, đã ghi nhận mức giảm 3% ở cả Opus 4.6 và 4.7
• Prompt này đã được hoàn nguyên ngay như một phần của bản phát hành ngày 20/4
• Thay đổi này ảnh hưởng đến Sonnet 4.6, Opus 4.6, và Opus 4.7

Các thay đổi sắp tới

• Để tránh những vấn đề tương tự, nhiều nhân sự nội bộ hơn sẽ được chuyển sang dùng Claude Code giống hệt bản dựng công khai
  • Đây là biện pháp nhằm thu hẹp khác biệt giữa phiên bản nội bộ để thử tính năng mới và bản dựng công khai thực tế
• Công cụ Code Review đang dùng nội bộ sẽ được cải thiện, và phiên bản cải tiến này cũng sẽ được phát hành cho khách hàng
• Các thay đổi đối với system prompt sẽ có thêm quy trình kiểm soát nghiêm ngặt hơn
  • Mọi thay đổi system prompt của Claude Code sẽ được đánh giá rộng trên từng mô hình
  • Việc thực hiện ablation để hiểu tác động của từng dòng sẽ tiếp tục
  • Các công cụ mới cũng đang được xây dựng để giúp review và audit thay đổi prompt dễ hơn
• Trong CLAUDE.md, sẽ bổ sung hướng dẫn để các thay đổi theo từng mô hình chỉ áp dụng cho chính mô hình đó
• Với mọi thay đổi có thể đánh đổi với trí năng, sẽ áp dụng soak period, bộ đánh giá rộng hơn, và rollout dần để phát hiện vấn đề nhanh hơn
• Để giải thích chi tiết hơn về các quyết định sản phẩm và bối cảnh của chúng, tài khoản X @ClaudeDevs đã được tạo, và cùng các cập nhật đó cũng sẽ được chia sẻ trong một thread tập trung trên GitHub
• Thông tin được gửi qua lệnh /feedback hoặc các ví dụ cụ thể, có thể tái hiện trên mạng đã giúp dẫn tới việc xác định và sửa lỗi
• Việc đặt lại usage limits cho mọi thuê bao cũng được áp dụng lại trong ngày hôm đó

[GN⁺]

Ý kiến trên Hacker News

• Tôi không thực sự bị thuyết phục bởi lời giải thích rằng việc xóa thinking cũ trong các phiên nhàn rỗi hơn 1 giờ đã giúp giảm độ trễ
  Tôi thường để phiên đó không dùng trong nhiều giờ, thậm chí nhiều ngày, rồi quay lại tiếp tục với toàn bộ ngữ cảnh được giữ nguyên, nên tính năng này từng là cốt lõi
  Việc hạ mức thinking mặc định thì tôi còn phần nào hiểu được, nhưng chuyện system prompt cứ liên tục thay đổi thì có lẽ tôi phải tìm hiểu để có thể chủ động chọn chu kỳ refresh theo ý mình

  • Trong Claude Code, nếu một cuộc trò chuyện có N tin nhắn thì thông thường N-1 tin nhắn, trừ tin nhắn mới nhất, sẽ nằm trong prompt cache
    Vấn đề là nếu để phiên ở trạng thái idle quá 1 giờ thì khi gửi prompt lại, cả N tin nhắn đều sẽ cache miss
    Corner case này đã làm chi phí token của người dùng tăng quá mức, và trong trường hợp cực đoan với ngữ cảnh 900k tokens thì mỗi lần quay lại phải ghi lại hơn 900k token vào cache, đặc biệt làm bào mòn rate limit của người dùng Pro
    Vì vậy họ đã thử hướng dẫn người dùng ở những nơi như X, nhiều lần thêm tip ngay trong sản phẩm để khuyên dùng /clear khi quay lại các cuộc trò chuyện cũ, và cũng thử cách lược bỏ kết quả tool cũ, tin nhắn cũ, cùng một phần thinking sau thời gian idle, nhưng trong số đó thì việc bỏ thinking cho hiệu năng tốt nhất
    Trong quá trình triển khai, bug được nhắc trong blog đã vô tình lọt vào, và họ nói sẽ trả lời thêm nếu có câu hỏi
  • Thật đáng ngạc nhiên khi một công ty trị giá hàng chục tỷ đô lại đưa ra quyết định như thế
    Hoặc là họ thực sự tin rằng giảm độ trễ cho các phiên idle đáng giá đến mức phải hy sinh chất lượng đầu ra, hoặc mục tiêu thật sự là cắt giảm chi phí còn bài blog chỉ dùng latency như một lý do nghe hợp lý hơn
    Có lẽ sẽ tự nhiên hơn nhiều nếu chỉ hiển thị rõ ràng hơn trạng thái đang tải trong lúc ngữ cảnh được nạp lại
  • Cái này khá sốc
    Trước đây tôi dùng CC như một đồng nghiệp: để nó cùng suy nghĩ về vấn đề, cập nhật kế hoạch, rồi tôi đi tắm suy nghĩ thêm và quay lại đưa lời khuyên mới, và ít nhất tôi luôn xem đó là một cuộc trò chuyện tĩnh trong khoảng một ngày
    Nhưng nếu ngưỡng chỉ là 1 giờ thì quá ngắn, đến mức khiến tôi phải cân nhắc lại việc có tiếp tục giữ gói anthropic hay không
  • Lý do giải thích về việc xóa token sau 1 giờ lại càng đáng ngờ hơn vì mốc thời gian đó trùng khớp đúng với giới hạn cache của họ
    Có vẻ đây khó là ngẫu nhiên mà nhiều khả năng là một thay đổi nhằm cắt giảm chi phí đáng kể
  • Việc này có lẽ còn tương tác tệ nhất với kiểu reset mức sử dụng theo thời gian
    Nếu nhiều người dùng thường để phiên nghỉ sau khi đã dùng hết hạn mức rồi mới quay lại, thì đây không phải ngoại lệ mà gần như là một mẫu hành vi mặc định

• Tôi khá bất ngờ khi nó bị chỉ trích dữ vậy
  Bản thân bài viết tương đối rõ ràng và thẳng thắn, đọc lên cũng khá hợp lý
  Việc hiệu năng giảm là có thật và gây khó chịu, nhưng đồng thời nó cũng cho thấy sự thiếu minh bạch về chuyện chính xác điều gì đang diễn ra phía sau, cùng cơ chế tính phí token có phần tùy tiện
  Với ai từng trực tiếp làm việc với LLM API thì việc nối lại một cuộc trò chuyện bị bỏ lâu sẽ phát sinh thêm chi phí và độ trễ là điều hiển nhiên, nhưng trong TUI thì có lẽ nên hiển thị điểm này rõ hơn nữa

  • Lý do mọi người bực là vì họ đã công khai phủ nhận đây là vấn đề suốt nhiều tháng
    Vì vậy đến giờ dù có giải thích thì phản cảm vẫn rất lớn

• Tôi nghĩ một phần cảm giác chất lượng đi xuống có thể không phải vì mô hình thực sự tệ hơn mà do tính không xác định
  Vài tuần trước tôi bảo Claude làm một ứng dụng năng suất cá nhân, mô tả rất dài về hành vi mong muốn rồi yêu cầu nó viết kế hoạch triển khai, và kết quả đầu tiên thật sự rất tốt, chỉ trừ một phần mơ hồ
  Sau khi sửa chỗ mơ hồ đó, tôi mở một chat mới và yêu cầu làm lại từ đầu mà không bắt nó chỉnh sửa kế hoạch cũ; cấu hình mô hình vẫn y hệt nhưng kết quả tệ hơn rất nhiều, hai lần sau cũng hỏng, và phải đến lần thử thứ tư mới quay lại mức như ban đầu
  Nên tôi có cảm giác việc đơn giản là yêu cầu làm lại cùng một tác vụ đôi khi lại là cách để có đầu ra tốt hơn, chỉ có điều nếu trả tiền bằng token của chính mình thì sẽ rất nhanh trở nên đắt đỏ

  • Tôi cũng nhìn nhận tương tự
    Có một kiểu mẫu khiến người ta cảm thấy mô hình định kỳ trở nên tệ đi, nhưng thực tế có thể chỉ là thời điểm nó đụng trần hạn chế đến muộn hơn mà thôi
    Và một khi đã gặp phải một đầu ra xui xẻo, từ sau đó bạn sẽ cứ thấy đúng điều đó mãi
  • Thế thì có phải rồi sẽ phải làm như tạo ảnh, tức là từ một prompt sinh ra 50 phiên bản rồi để con người chọn thủ công bản tốt nhất không
    Với Anthropic thì đây cũng là kiểu sử dụng đáng mừng vì nó làm tăng tiêu thụ token
  • Với một ứng dụng năng suất low-stakes cỡ đó, rất có thể tự làm còn nhanh hơn thời gian bạn đã bỏ ra ở đây
  • Có thể lần này ta học được rằng LLM không xác định hơn nhiều so với tưởng tượng, nhưng việc gắn thẳng điều đó với đợt suy giảm hiệu năng gần đây có thể là sai
    Tính không xác định vốn luôn tồn tại, còn sự xuống cấp chất lượng gần đây được báo cáo rộng rãi có thể là hiện tượng khác hẳn

• Tôi đã hết hứng từ thời Opus 4.7 rồi
  OpenAI đang cực kỳ quyết liệt tiếp cận phía enterprise của chúng tôi, và còn đề nghị token không giới hạn cho đến mùa hè
  Vì thế tôi đã dùng GPT5.4 ở chế độ extra high effort trong 30 ngày qua, và không biết có phải do được ưu ái không nhưng tôi gần như không thấy nó mắc lỗi
  Reasoning trace đôi khi còn tốt đến mức buồn cười, và nó tự đi trước cả những chỗ tôi quên dặn để đảm bảo đủ mọi yếu tố cần thiết nhằm giữ toàn vẹn dữ liệu ở mức 100%

  • Tôi cũng cảm thấy tương tự
    Những thay đổi kiểu mẹo mực như thế này có thể là do Anthropic bị bó buộc compute nặng, nên phải cố gắng cắt giảm bằng các nước đi miễn cưỡng
  • GPT-5.4 đã tốt hơn Opus 4.6 ở nhiều lĩnh vực, đặc biệt về độ chính xác và logic khó
    Nên tôi rất mong xem 5.5 sẽ còn tiến xa tới đâu
  • extra high đốt token quá nhiều
    90% công việc chỉ cần chạy 5.4 ở medium, và chỉ khi medium có vẻ đuối thì mới tăng lên high; như vậy tập trung hơn nhiều và thay đổi cũng được giữ ở mức tối thiểu
  • Chuẩn
  • Tôi đã quay lại 4.5 và không hề hối hận
    Hơn nữa còn rẻ hơn một chút

• Gần đây Claude thường tạo ra các đầu ra kiểu đang trả lời prompt nội bộ của chính nó
  Ví dụ như bảo rằng câu trong ngoặc là một nỗ lực prompt injection nên sẽ bị bỏ qua, hoặc có vẻ là một nỗ lực che giấu guideline chung của nó nên nó sẽ không làm theo, hay nói rằng cách đó vốn luôn được áp dụng nên không cần thiết
  Tôi hoàn toàn không làm các kiểu đó mà nó vẫn thường gắn những câu như vậy vào cuối phản hồi
  Có vẻ đâu đó trong guideline nội bộ có phần viết rất vụng và nó không phân biệt được phần đó với câu hỏi của tôi

  • Tôi có dùng stop hook scripts để ép chạy test mỗi khi thay đổi code, nhưng từ sau 4.7 thì Claude dù vẫn chạy script lại định kỳ phớt lờ quy tắc
    Khi hỏi lý do thì nó trả lời là nó nghĩ không cần thiết
  • Tôi cũng thấy ở OpenAI kiểu tự nói rồi tự trả lời như vậy khá nhiều
    Trông cũng giống một cách dễ dàng để các công ty tăng token churn
  • Tôi cũng thường thấy nó tự đưa ra các điểm nào đó vào memory, rồi sau này tham chiếu lại như thể đó là ý của tôi
    Khi đó mô hình khẳng định điều gì đó, lưu nó vào memory, rồi lại nhìn chính memory đó để bồi thêm thành một vòng lặp tự củng cố, và đôi khi vẫn tiếp tục dù tôi đã nói rõ là phải dừng
  • Tôi tò mò về mức effort và prompt thực tế
    Cảm giác này có thể là do để reasoning effort quá cao, nên với prompt đó biết đâu chỉ cần giảm nhẹ cường độ suy luận là sẽ đỡ hơn
  • Tôi thường để Claude lo cả commit lẫn PR, và tuần trước tôi đã nhiều lần thấy nó tự ý làm thêm việc không cần thiết trong quá trình commit
    Nó vấp ở bước git add, nhưng trong auto mode thì có lần suýt nữa đã lọt qua

• Việc họ nói lý do hạ reasoning effort mặc định từ high xuống medium là vì độ trễ quá dài đến mức UI trông như bị treo, lại càng đáng ngờ
  Điều đó có nghĩa là họ đã hạ cường độ suy luận mặc định thay vì sửa UI, và vì thế lời giải thích rằng họ đang nghiêm túc theo dõi các báo cáo suy giảm hiệu năng nghe khá khó tin

  • Đội ngũ nói rằng họ đã làm cả hai
    Họ nhiều lần chỉnh cả UI, như cải thiện trạng thái loading cho thinking và hiển thị rõ hơn số token đang được tải xuống
    Dù vậy, sau eval và dogfooding, họ vẫn hạ effort mặc định; đó là quyết định sai và giờ đã hoàn tác
    Họ cũng thừa nhận đáng lẽ phải dự đoán trước rằng nhiều người không thực sự hiểu mình cần dùng /effort để tăng trí tuệ lên, nên cứ ở lại với mặc định

• Câu nói rằng phiên idle quá 1 giờ là corner case hoàn toàn không khớp với cách tôi dùng
  Khi làm việc cá nhân, tôi thường giao nhiều tác vụ 10–15 phút cho Claude Code, rồi trước khi chạy sẽ trao đổi qua lại với mô hình khá lâu để lên kế hoạch
  Một khi việc thực thi bắt đầu, tôi hay đi lấy cà phê hoặc sang làm dự án khác với Codex, nên khả năng tôi quay lại Claude sau hơn 1 giờ là rất cao

  • Chắc đó chỉ là corner case theo góc nhìn của các developer mà thôi
    Việc nhầm thói quen sử dụng của chính mình thành hành vi của toàn bộ người dùng là một cái bẫy rất thường gặp trong phát triển sản phẩm
  • Câu đó còn khiến tôi thấy như họ đã không kiểm chứng đầy đủ chính edge case này dù đang triển khai một thay đổi lớn đến thế, nên cũng dấy lên nghi ngờ về độ nghiêm ngặt của việc kiểm thử

• Cách tiếp cận hộp đen mà các frontier lab lớn đang dùng rốt cuộc sẽ khiến mọi người rời bỏ họ
  Nếu cứ thay đổi hành vi cốt lõi như vậy mà không báo trước, rồi chỉ giải thích sau, thì cuối cùng người dùng sẽ không còn lựa chọn nào ngoài việc chuyển sang mô hình tự host
  Không thể ổn định xây dựng pipeline, workflow hay sản phẩm trên một nền tảng mà mặt đất cứ rung lắc liên tục như thế

• Có vẻ những người phụ trách Claude Code bên Anthropic đang đọc bình luận, nên tôi muốn nhắc là mấy hôm trước tôi xem video của theo t3.gg nói về việc Claude có phải đã ngu đi không
  Giọng điệu thì khá gắt và có nhiều lời nặng nề, nhưng riêng phần chỉ ra vấn đề harness bloat thì tôi thấy khá chính xác
  Giờ có lẽ nên tạm dừng thêm tính năng mới và đẩy mạnh thật quyết liệt việc mài giũa và tối ưu hóa
  Nếu không, sẽ ngày càng nhiều người đi tìm các lựa chọn thay thế nhẹ và tối ưu hơn, và cốt lõi là phải làm harness tốt hơn đồng thời giảm mức tiêu thụ token
  https://youtu.be/KFisvc-AMII?is=NskPZ21BAe6eyGTh

  • Bỏ qua mọi chuyện khác, chỉ riêng việc họ từng thử nghiệm loại bỏ hỗ trợ CC khỏi gói Pro cũng đủ khiến tôi nghiêm túc nghĩ tới phương án thay thế
    Tôi vốn đã luôn cảnh giác với vendor lock-in, nhưng vụ đó là một lời cảnh báo rất tốt, và có lẽ tôi sẽ xem opencode+openrouter trước
  • Tuyệt đối đừng quên video thổi phồng GPT 5 của theo và việc sau đó anh ta rút lại
    Rõ ràng có gì đó đang được trao đổi ngầm giữa một số nhà sáng tạo nội dung và OpenAI, dù là tiền bạc hay ảnh hưởng
  • Thành thật mà nói, chuyện này trông như kiểu chỉ cần git reset --hard là xong

• Có vẻ đây là hệ quả của việc ám ảnh thêm tính năng hơn là độ hoàn thiện của sản phẩm cốt lõi
  Tôi thường nghĩ Anthropic sẽ tốt hơn nếu có thêm vài lãnh đạo sản phẩm cấp cao, và họ thực sự cần một góc nhìn kiểu “Escaping the Build Trap”
  Hiện tại, chỉ vì có thể gắn tính năng vào thật nhanh không có nghĩa là nhất định phải làm thế
  Tôi nhắc đến cuốn sách nổi tiếng đó không phải để lặp lại mấy luận điểm sáo mòn về tổ chức sản phẩm, mà vì cảm quan sản phẩm tốt là một năng lực khác với kỹ nghệ tốt, và gần đây Anthropic có vẻ đang thiếu đúng phần đó

  • Họ phải theo kịp nhu cầu nhưng rõ ràng đang thiếu tài nguyên compute
    Vì thế nếu không thêm những tính năng kiểu này thì hệ thống sẽ hỏng hoặc họ sẽ không nhận được khách hàng mới, mà cả hai đều khó chấp nhận, nên có lẽ họ không có nhiều lựa chọn
  • Đây từng là nơi có cỡ 100 developer nhận 600 nghìn USD một năm, nên thiếu nhân tài chắc không phải vấn đề
    Có lẽ vấn đề là họ đang đẩy quá mạnh câu chuyện vibe coding, đến mức nghe nói có ứng viên còn từ chối lời mời phỏng vấn vì vậy
  • Có vẻ họ đã sa rất sâu vào bẫy phức tạp
    Bản chất xác suất của mô hình đã là vấn đề, nhưng giờ có cảm giác họ cũng không còn tự suy luận nổi về chính phần mềm của mình
    Có quá nhiều cần gạt và núm chỉnh, và có lẽ không còn ai hiểu được toàn bộ code nữa
    Tệ hơn, nhìn vào các phát biểu của Dario và những người khác thì có vẻ ban lãnh đạo cũng không thật sự đồng cảm với những lo ngại về chất lượng này
    Trong bối cảnh họ xem SWE là thứ có thể bị thay thế, cảm giác như các yêu cầu thêm guard rail cho công cụ либо bị phớt lờ либо thậm chí bị kìm lại, và rốt cuộc Claude Code ngay từ đầu đã giống một thí nghiệm khoa học hơn là một sản phẩm trưởng thành có best practice vững vàng