Mấy ngày gần đây, trong cộng đồng dùng agent code, mình thấy một tranh luận lặp đi lặp lại: liệu Claude Code có đang dở đi thật không. Một bài đang lên ở r/ClaudeCode chốt khá thẳng rằng phần lớn cảm giác “ngu đi” không đến từ model tụt chất lượng, mà đến từ cách anh em đang vận hành công cụ sai cách.
Nhìn kỹ thì đây không phải một câu nói khích bác cho vui. Nó chạm đúng một vấn đề rất thực tế trong môi trường làm việc có agent: khi kết quả không ổn định, đội ngũ thường đổ lỗi cho model trước, trong khi nguyên nhân thật sự lại nằm ở cách đóng gói nhiệm vụ, quản trị context và kiểm soát từng vòng chạy.
Vì sao nhiều người có cảm giác Claude Code thất thường
Tác giả bài viết nhấn mạnh một điều cơ bản nhưng hay bị quên: đầu ra của model luôn có yếu tố xác suất. Cùng một prompt, anh em vẫn có thể nhận các phương án khác nhau. Điều này không có nghĩa là hệ thống suy giảm, mà thường có nghĩa là bài toán chưa được ràng buộc đủ tốt.
Trong thực chiến, có ba nguyên nhân rất dễ tạo ra cảm giác “hôm nay agent dở hơn hôm qua”:
- context bị nhồi quá nhiều tài liệu, rule, skill và lịch sử cũ không còn liên quan
- một prompt ôm quá nhiều mục tiêu cùng lúc nên agent không biết ưu tiên cái nào trước
- người vận hành không tách pha lập kế hoạch với pha thực thi, khiến sai từ đầu rồi kéo sai đến cuối
Khi ba thứ này chồng lên nhau, model vẫn là model đó, nhưng xác suất đi chệch hướng tăng lên rõ rệt.
Luận điểm đáng chú ý nhất: context đầy quá nửa là vùng rủi ro
Điểm đáng đọc ở bài Reddit không nằm ở lời than phiền, mà ở kinh nghiệm vận hành: khi context window đã quá dày, agent dễ bắt đầu lan man, quên mất mục tiêu chính hoặc bám vào những chỉ dẫn cũ không còn phù hợp.
Đây là chuyện rất nhiều team làm AI coding đang gặp. Họ cố “trang bị” cho agent thật nhiều bằng cách nhét vào một đống quy tắc, file hướng dẫn dài và instruction chồng lớp. Ý định là giúp agent thông minh hơn, nhưng kết quả thường ngược lại: tín hiệu quan trọng bị chìm trong nhiễu.
Nếu anh em đang dùng Claude Code cho những việc như refactor, sửa bug nhiều file, hoặc triển khai workflow có nhiều bước, thì quản trị context không còn là tiểu tiết. Nó là một phần của năng lực vận hành.
Cách dùng gọn hơn nhưng thường hiệu quả hơn
Từ góc nhìn vận hành, bài post này gợi lại một bộ nguyên tắc khá đáng tin:
1. Chia việc lớn thành chặng nhỏ, có đầu ra rõ ràng
Thay vì giao một lệnh kiểu “phân tích repo, sửa bug, dọn code, viết test và cập nhật docs”, mình nên chia thành các chặng độc lập:
- chặng 1: xác định lỗi gốc và file liên quan
- chặng 2: đề xuất hướng sửa, nêu rủi ro
- chặng 3: thực thi chỉnh sửa
- chặng 4: viết hoặc cập nhật test
- chặng 5: tóm tắt thay đổi
Lợi ích là mỗi vòng chạy có tiêu chí thành công rõ hơn, đồng thời giảm xác suất agent tự ý mở rộng phạm vi.
2. Dọn context sau khi xong từng mục tiêu
Gợi ý dùng /clear sau mỗi goal nghe đơn giản nhưng lại rất thực dụng. Trong nhiều ca làm việc dài, anh em giữ nguyên context vì sợ mất thông tin. Nhưng cái giá phải trả là agent bị kéo theo cả đống quyết định tạm thời, nhánh suy nghĩ cũ và dữ liệu không còn liên quan.
Nếu nhiệm vụ kế tiếp không cần lịch sử trước đó, dọn sạch rồi nạp lại đúng phần cần thiết thường cho kết quả ổn định hơn.
3. Tách plan mode và execution mode
Một lỗi phổ biến là vừa hỏi agent nghĩ cách làm, vừa bắt nó code ngay trong cùng một luồng. Bài Reddit nhắc đúng điểm này: nên dùng plan mode thường xuyên hơn, đọc lại kế hoạch, rồi mới cho thực thi sau khi đã reset bối cảnh nếu cần.
Cách này giúp anh em phát hiện sớm ba loại lỗi:
- hiểu sai yêu cầu
- chọn sai chiến lược kỹ thuật
- bỏ sót điều kiện biên hoặc tiêu chí nghiệm thu
Phát hiện ở bước plan luôn rẻ hơn sửa ở bước code.
Điều bài viết này đúng, và điều anh em không nên hiểu quá đà
Mình thấy luận điểm “đừng đổ hết lỗi cho tool” là hợp lý. Tuy nhiên, cũng không nên cực đoan theo hướng mọi vấn đề đều do người dùng. Model vẫn có lúc hồi đáp kém, có lúc hệ thống thay đổi hành vi vì tuning, latency, routing hoặc chất lượng ngữ cảnh đầu vào.
Nhưng trong phần lớn tình huống vận hành hằng ngày, thứ anh em kiểm soát được và nên tối ưu trước vẫn là:
- cấu trúc prompt
- độ sạch của context
- cách chia việc
- checkpoint rà soát giữa các bước
Nói ngắn gọn: trước khi kết luận công cụ xuống cấp, hãy kiểm tra xem quy trình sử dụng đã đủ sạch chưa.
Góc nhìn cho đội vận hành và founder
Nếu anh em đang quản lý team dùng AI để code, bài học ở đây không chỉ dành cho cá nhân developer. Nó còn liên quan tới cách tổ chức quy trình làm việc:
- đừng ép mọi người dùng một prompt khổng lồ cho mọi tình huống
- đừng biến file hướng dẫn thành bãi rác instruction
- nên chuẩn hóa các mẫu task nhỏ, dễ kiểm soát, dễ review
- nên định nghĩa lúc nào cần reset context, lúc nào cần chuyển sang phiên mới
Team nào coi agent như một hệ thống cần vận hành, thay vì một “lập trình viên ma thuật”, thường sẽ có kết quả ổn định hơn nhiều.
Kết luận
Bài đang hot trên r/ClaudeCode không có phát hiện kỹ thuật quá mới, nhưng nó nhắc lại đúng một sự thật quan trọng: chất lượng đầu ra của AI coding không chỉ phụ thuộc vào model, mà phụ thuộc mạnh vào cách anh em thiết kế cuộc chơi cho nó.
Nếu gần đây anh em thấy Claude Code chạy kém đi, có lẽ nên kiểm tra lại ba thứ trước tiên: nhiệm vụ có bị gói quá to không, context có quá bẩn không, và mình đã tách plan với execution đủ rõ chưa. Chỉ riêng ba điểm đó thôi cũng có thể kéo chất lượng lên đáng kể.
Top comments (0)