Một meme nhỏ đang leo hot trong r/ClaudeCode với tiêu đề “Nothing ever changes”. Không có nhiều chữ, nhưng phản ứng của cộng đồng lại khá quen: mỗi khi có model mới, workflow mới, hoặc một tính năng agent mới, anh em lại kỳ vọng “lần này sẽ khác”. Rồi sau vài ngày sử dụng thật, các vấn đề cũ quay lại dưới hình thức mới.
Đây là một tín hiệu đáng chú ý hơn là một câu đùa. Nó nhắc mình rằng tiến bộ của AI coding không chỉ nằm ở model mạnh hơn, mà nằm ở cách đội dev vận hành model đó.
Chu kỳ quen thuộc của AI coding
Trong cộng đồng Claude Code vài ngày gần đây, các chủ đề nổi bật xoay quanh Opus 4.8, rules, skills, dynamic workflows, hallucination, và việc agent tự kiểm tra quá nhiều hoặc tự tin quá mức.
Nếu nhìn riêng từng bài, mỗi vấn đề có vẻ khác nhau. Nhưng gom lại thì có một mẫu rất rõ:
- model mới xuất hiện, kỳ vọng tăng mạnh;
- người dùng đưa model vào workflow thật;
- model làm tốt vài thứ, nhưng cũng lộ ra thói quen khó chịu;
- cộng đồng bắt đầu viết rules, CLAUDE.md, hooks, checklist, hoặc guardrail để kéo nó về đúng đường;
- sau đó vòng lặp lặp lại với model tiếp theo.
Vì vậy, “nothing ever changes” không hẳn là bi quan. Nó giống một lời nhắc rằng phần thay đổi chậm nhất không phải model, mà là kỷ luật vận hành của chính mình.
Tin đáng chú ý: guardrail vẫn quan trọng dù model mạnh hơn
Điểm mới của các model gần đây là chúng có thể xử lý context dài hơn, gọi tool tốt hơn, chia việc cho sub-agent, và tự kiểm tra nhiều hơn. Nhưng chính các khả năng đó cũng làm lỗi trở nên khó đoán hơn.
Một agent biết tự đọc nhiều file có thể giúp tìm bug sâu hơn. Nhưng nếu không có ranh giới, nó cũng có thể đốt token, sửa nhầm phạm vi, hoặc biến một task nhỏ thành một đợt “đại tu” không ai yêu cầu.
Một model biết cảnh giác prompt injection là điều tốt. Nhưng nếu dùng trong vòng lặp sửa file ngắn, nó có thể tạo cảm giác chậm, nghi ngờ quá mức, hoặc cứ kiểm chứng lại những thứ không cần kiểm chứng.
Một workflow nhiều agent nghe rất mạnh. Nhưng nếu không có trần chi phí, tiêu chí dừng, và bước tổng hợp rõ ràng, nó có thể nhanh chóng biến thành một quy trình đắt đỏ mà khó truy vết.
Nói ngắn gọn: năng lực càng lớn thì guardrail càng phải rõ.
Checklist thực tế cho anh em dùng Claude Code
Nếu đội của anh em đang dùng Claude Code hằng ngày, mình nghĩ có vài nguyên tắc nên được coi như hạ tầng, không phải “mẹo prompt”:
- Ghi rõ phạm vi sửa
Trước khi giao việc, nói rõ file nào được phép đụng, file nào không. Với task nhỏ, càng nên ghi “không refactor ngoài phạm vi”.
- Bắt agent nêu giả định trước khi sửa
Nếu yêu cầu chưa rõ, agent nên hỏi hoặc liệt kê giả định. Đừng để nó âm thầm tự đoán kiến trúc, intent, hoặc tiêu chuẩn nghiệm thu.
- Đặt tiêu chí dừng
Ví dụ: “sau khi test X pass thì dừng”, “không tạo thêm abstraction”, “không sinh sub-agent nếu chưa cần”. Điều này đặc biệt quan trọng với deep research hoặc dynamic workflow.
- Tách chế độ exploration và chế độ edit
Khi đang tìm hiểu codebase, cho phép đọc rộng. Khi đã chuyển sang sửa, thu hẹp phạm vi lại. Rất nhiều lỗi xảy ra vì agent vẫn hành xử như đang exploration trong lúc đã bắt đầu edit.
- Log lại quyết định quan trọng
Những thứ như “vì sao không dùng thư viện A”, “vì sao chọn kiến trúc B”, “module này có constraint gì” nên nằm trong CLAUDE.md hoặc tài liệu gần code. Agent không có trí nhớ dự án nếu mình không cấp cho nó một nguồn sự thật ổn định.
Điều mình rút ra từ meme này
Meme “Nothing ever changes” vui vì nó đúng một phần. Nhưng phần còn lại cũng đáng mừng: cộng đồng đang dần chuyển từ câu hỏi “model nào thông minh hơn” sang “workflow nào làm model bớt gây hại hơn”.
Với AI coding, lợi thế bền hơn không phải luôn chạy theo model mới nhất. Lợi thế là có một hệ vận hành đủ rõ để model mới mạnh hơn mà không kéo theo nhiều rủi ro hơn.
Nếu anh em chưa làm, hãy bắt đầu bằng một file rules ngắn cho repo: phạm vi sửa, cách hỏi khi không chắc, tiêu chí dừng, và nguyên tắc không đụng code ngoài task. Đó là phần “nhàm chán” nhưng thường tạo khác biệt lớn nhất khi dùng coding agent lâu dài.
Top comments (0)