Một thảo luận đang nóng trong r/vibecoding có ý rất đáng để anh em làm sản phẩm AI suy nghĩ: một người dùng lâu năm của Claude Code chuyển sang DeepSeek V4 + OpenCode và cảm thấy chất lượng đầu ra đủ tốt, trong khi chi phí thấp hơn rất nhiều. Điểm đáng chú ý không nằm ở việc một model nào đó “thắng” tuyệt đối, mà là áp lực giá trong mảng AI coding đang bước vào giai đoạn mới.
Nếu anh em đang dùng AI để code mỗi ngày, câu hỏi thực tế bây giờ không còn là “model nào mạnh nhất”, mà là “workflow nào cho ra kết quả đủ tốt với chi phí hợp lý”.
Vì sao câu chuyện giá lại quan trọng
AI coding khác chat thông thường ở chỗ nó tiêu token rất nhanh:
- đọc nhiều file trong repo
- viết và sửa nhiều vòng
- chạy test, đọc lỗi, sửa tiếp
- tạo diff lớn hoặc refactor nhiều module
- dùng agent CLI trong phiên dài
Một model đắt hơn một chút trên mỗi triệu token có thể chưa đáng kể nếu chỉ hỏi vài câu. Nhưng khi dùng kiểu agentic coding cả ngày, chênh lệch đó biến thành chi phí vận hành thật.
Vì vậy, khi một cộng đồng bắt đầu nói rằng model rẻ hơn cho kết quả “đủ dùng”, đó là tín hiệu thị trường quan trọng: người dùng đang tối ưu theo tổng chi phí hoàn thành task, không chỉ benchmark.
“Đủ tốt” không có nghĩa là “tốt nhất”
Mình nghĩ đây là điểm dễ bị tranh cãi nhất. Một model có thể chưa bằng model frontier ở các bài khó, nhưng vẫn đủ tốt cho nhiều việc:
- dựng CRUD, dashboard, API endpoint
- sửa bug rõ nguyên nhân
- viết test cơ bản
- chuyển đổi framework hoặc syntax
- tạo prototype nhanh
- đọc log và đề xuất hướng xử lý
- viết script nội bộ
Ngược lại, những việc vẫn nên ưu tiên model mạnh hơn:
- refactor kiến trúc lớn
- thay đổi liên quan bảo mật hoặc dữ liệu người dùng
- debugging lỗi race condition, memory, concurrency
- code review cho production quan trọng
- quyết định thiết kế khó có nhiều trade-off
Nói cách khác, không nên hỏi “model A có hơn model B không” theo kiểu chung chung. Nên hỏi: “task này cần mức tin cậy nào, context dài bao nhiêu, nếu sai thì chi phí sửa là gì”.
Cách chọn model theo tầng công việc
Một setup thực dụng cho anh em vibe coding có thể là chia model theo 3 tầng.
Tầng 1: việc lặp lại, rủi ro thấp
Dùng model rẻ hơn cho các việc dễ kiểm chứng:
- generate boilerplate
- viết utility nhỏ
- đổi tên field
- tạo migration nháp
- viết README hoặc docs
- sinh test case ban đầu
Điều kiện là phải có test, lint hoặc review nhanh trước khi merge.
Tầng 2: việc cần hiểu repo
Dùng model trung bình hoặc model mình tin hơn khi cần đọc nhiều file và giữ consistency:
- thêm feature nhỏ
- sửa bug có nhiều bước
- cập nhật API contract
- tối ưu query
- viết integration test
Ở tầng này, mình thường yêu cầu model giải thích kế hoạch trước, sau đó mới cho sửa code. Như vậy dễ bắt lỗi sớm hơn.
Tầng 3: việc có rủi ro cao
Dùng model mạnh nhất hoặc ít nhất dùng hai model để đối chiếu:
- auth, permission, billing
- data migration nguy hiểm
- security-sensitive code
- thay đổi kiến trúc
- tối ưu performance khó đoán
Chi phí model lúc này thường nhỏ hơn chi phí bug production.
Một checklist trước khi đổi sang model rẻ hơn
Trước khi chuyển hẳn workflow coding sang một model rẻ hơn, anh em nên chạy thử có kiểm soát:
- Chọn 10 task thật trong repo, không dùng benchmark chung chung.
- Chia task thành dễ, trung bình, khó.
- Đo tổng chi phí mỗi task, không chỉ giá token niêm yết.
- Đo số vòng sửa lại sau khi model trả lời.
- Ghi lại lỗi nghiêm trọng: hallucination API, sửa sai file, bỏ sót edge case.
- So sánh thời gian từ prompt đầu tiên đến PR có thể review.
- Luôn chạy test/lint/build để tránh cảm giác “nhìn có vẻ đúng”.
Nếu model rẻ hơn làm tốt 70-80% task thường ngày, anh em có thể dùng nó làm default và chỉ nâng cấp model khi task vượt ngưỡng rủi ro.
Giá rẻ sẽ ép workflow tốt hơn
Điều thú vị là model rẻ không chỉ giúp tiết kiệm. Nó còn khuyến khích anh em thiết kế workflow rõ hơn:
- prompt ngắn, mục tiêu cụ thể hơn
- context đưa vào có chọn lọc hơn
- task nhỏ hơn, dễ verify hơn
- nhiều bước tự động kiểm tra hơn
- tách “generate” và “review” thành hai vai trò khác nhau
Khi workflow đã tốt, model nào cũng phát huy tốt hơn. Khi workflow lỏng, kể cả model đắt cũng có thể tạo ra đống diff khó kiểm soát.
Kết luận thực dụng
Mình không nghĩ câu chuyện này là “DeepSeek thay thế Claude” hay “model Trung Quốc sẽ thắng hết”. Bài học thực tế hơn là: thị trường AI coding đang bị kéo về phía hiệu quả chi phí.
Với anh em làm sản phẩm, lựa chọn khôn ngoan là xây một hệ thống có thể đổi model theo task. Đừng gắn toàn bộ workflow vào một nhà cung cấp, nhưng cũng đừng chạy theo giá rẻ mà bỏ qua kiểm chứng.
Công thức mình thấy hợp lý lúc này là: model rẻ cho việc thường ngày, model mạnh cho việc rủi ro cao, test tự động cho mọi thứ có thể test, và review con người cho phần ảnh hưởng production.
Top comments (0)