Claude Code dậy sóng vì báo cáo nói độ sâu suy luận giảm 67%

Một tranh luận khá lớn đang nổi lên quanh Claude Code sau khi một báo cáo cộng đồng tổng hợp dữ liệu phiên làm việc từ cuối tháng 1 tới đầu tháng 4 và cho rằng chất lượng cho các tác vụ kỹ thuật phức tạp đã giảm rõ rệt từ giai đoạn tháng 2. Điểm khiến anh em chú ý nhất là con số ước tính “độ sâu suy luận” giảm khoảng 67%, đi kèm thay đổi hành vi như đọc ít hơn trước khi sửa mã và tăng các lần dừng sớm hoặc né trách nhiệm sửa lỗi.

Chuyện gì đang xảy ra?

Nguồn tranh luận bắt đầu từ một issue trên GitHub của Claude Code, sau đó lan sang Hacker News và Reddit. Tác giả issue nói họ đã phân tích:

• 6.852 file session JSONL
• 17.871 khối thinking
• 234.760 lần gọi tool
• hơn 18.000 prompt người dùng

Từ đó họ rút ra mấy kết luận chính:

• thinking bị ẩn dần theo rollout trong tháng 3
• độ sâu thinking ước tính đã giảm mạnh từ cuối tháng 2
• tỉ lệ đọc file trước khi edit giảm đáng kể
• stop hook violation và các dấu hiệu bực bội của người dùng tăng lên

Nếu nhìn theo góc độ vận hành, đây không còn là cảm giác “model dạo này cùn hơn” nữa, mà là một nỗ lực biến cảm giác đó thành số liệu để tranh luận.

Báo cáo cộng đồng đang tố điều gì?

Phần đáng chú ý nhất của báo cáo không phải chỉ là than phiền, mà là họ cố gắng nối ba lớp bằng chứng lại với nhau:

1. Thời điểm rollout trùng với lúc người dùng bắt đầu kêu nhiều

Báo cáo nói cơ chế redact-thinking-2026-02-12 được rollout theo từng đợt trong tháng 3. Cùng giai đoạn đó, các phản hồi về việc Claude Code kém ổn định hơn với workflow kỹ thuật dài hơi cũng tăng mạnh.

2. Hành vi tool chuyển từ nghiên cứu trước sang sửa trước

Theo issue, read/edit ratio tụt từ khoảng 6,6 xuống còn 2,0. Nói ngắn gọn: model ít chịu đọc bối cảnh hơn trước khi động vào code. Với anh em làm codebase lớn, đây là kiểu thay đổi rất dễ gây khó chịu vì nó tạo ra mấy lỗi quen thuộc:

• sửa đúng file nhưng sai ngữ cảnh
• vá nhanh chỗ nhìn thấy trước mắt nhưng phá convention xung quanh
• viết lại nhiều hơn thay vì sửa gọn
• dừng khi việc chưa thật sự xong

3. Người dùng mất khả năng quan sát chất lượng thật

Ngay cả khi chưa chắc mọi kết luận trong issue đều đúng 100%, cộng đồng vẫn chạm vào một vấn đề quan trọng: khi thinking bị ẩn, người dùng khó kiểm chứng model đang nghĩ nông đi hay chỉ thay đổi cách hiển thị.

Anthropic phản hồi ra sao?

Theo phản hồi được cross-post trên Hacker News, phía Claude Code cho biết có hai thay đổi chính:

• redact-thinking chỉ là thay đổi ở lớp hiển thị, không tự nó làm giảm khả năng suy luận
• Opus 4.6 chuyển sang adaptive thinking và sau đó default effort được đặt ở mức medium để cân bằng chất lượng, chi phí và độ trễ

Họ cũng nói người dùng có thể tăng effort lên high hoặc max, hoặc bật lại showThinkingSummaries: true nếu muốn quan sát tốt hơn.

Nói cách khác, phía nhà cung cấp đang giải thích rằng vấn đề có thể đến từ thay đổi mặc định về effort và trải nghiệm hiển thị, chứ không phải họ âm thầm “cắt não” model như cộng đồng đang suy đoán.

Điều gì thực sự đáng lo với anh em dùng agent code?

Ở đây có 2 lớp cần tách bạch.

Lớp 1: Báo cáo cộng đồng chưa phải bằng chứng cuối cùng

Issue đó rất chi tiết, nhưng vẫn là nghiên cứu do người dùng tự tổng hợp. Nó hữu ích vì đưa ra số liệu, nhưng chưa phải kết luận chính thức hay peer review.

Lớp 2: Nỗi đau vận hành là có thật

Dù nguyên nhân cuối cùng là gì, phần nhiều bình luận đồng ý ở một điểm: với workflow code phức tạp, chỉ cần default effort thay đổi hoặc model ít chịu đào sâu hơn là chất lượng rơi thấy rất rõ. Đặc biệt nếu anh em đang dùng Claude Code để:

• sửa nhiều file liên quan nhau
• refactor dài hơi
• làm việc trên codebase có convention chặt
• chạy agent tự trị trong thời gian dài

thì việc model chuyển từ “nghiên cứu trước rồi mới sửa” sang “sửa thử trước” sẽ làm chi phí giám sát tăng lên ngay.

4 việc nên làm ngay nếu team đang phụ thuộc Claude Code

1. Chuẩn hóa effort thay vì để mặc định

Nếu team đang làm việc khó, đừng để từng máy hoặc từng người trôi theo mặc định mới. Chọn rõ:

• task nào dùng medium
• task nào bắt buộc high
• khi nào mới cần max

Việc này nghe nhỏ nhưng rất đáng làm vì nó biến “cảm giác xuống chất lượng” thành thứ có thể kiểm soát phần nào.

2. Theo dõi hành vi tool, không chỉ nhìn output cuối

Nếu có thể, anh em nên log thêm mấy chỉ số như:

• read trước edit
• số lần model dừng sớm
• số lần tự mâu thuẫn hoặc đổi hướng liên tục
• số lần phải nhắc lại yêu cầu nền tảng

Đây là lớp tín hiệu sớm tốt hơn việc đợi tới lúc code sai mới phát hiện.

3. Tách tác vụ nặng khỏi tác vụ thường

Không phải job nào cũng cần thinking sâu. Nếu trộn hết vào một cấu hình mặc định, team rất dễ tranh cãi kiểu “máy tao thấy vẫn ổn” trong khi nhóm làm việc khó đang chịu chất lượng tệ hơn hẳn.

4. Chuẩn bị phương án dự phòng

Nếu agent code là mắt xích vận hành quan trọng, nên có sẵn fallback:

• đổi model cho tác vụ khó
• giảm mức tự trị ở các bước rủi ro cao
• chèn checkpoint bắt model đọc thêm trước khi edit
• yêu cầu test hoặc diff review chặt hơn trước khi chấp nhận

Góc nhìn của mình

Tin tức này đáng theo dõi vì nó phản ánh một vấn đề lớn hơn: các công cụ AI cho lập trình giờ đã đi vào lớp vận hành thực tế, nơi chỉ một thay đổi nhỏ về mặc định cũng có thể làm quy trình của cả team chao đảo. Khi đó, tranh luận không còn là “model này thông minh hay không”, mà là:

• nó có ổn định không
• có đo được không
• khi chất lượng đổi thì người dùng có biết ngay không

Nếu Anthropic muốn giữ niềm tin từ nhóm power user, thứ họ cần không chỉ là phủ nhận nghi ngờ, mà là cho người dùng nhiều tín hiệu quan sát hơn về effort, thinking và chất lượng hành vi.

Với anh em đang dùng Claude Code hàng ngày, bài học thực tế là đừng tin hoàn toàn vào cảm giác cũng đừng tin hoàn toàn vào mặc định. Hãy đo, khóa cấu hình quan trọng, và coi agent code như một hệ thống cần quan sát chứ không phải một “lập trình viên thần kỳ” chạy mãi không cần giám sát.