Opus 4.8 và bài học khi vibe coding với model ngày càng mạnh

Opus 4.8 đang tạo ra một kiểu phản ứng rất quen thuộc trong cộng đồng vibe coding: vừa hào hứng vì mô hình mạnh hơn, vừa lo vì mỗi lần mô hình mạnh hơn thì cách mình làm việc cũng dễ bị lệch theo.

Một bài hot trên r/vibecoding chỉ ghi ngắn gọn “POV: Opus 4.8”, nhưng nó chạm đúng tâm lý của nhiều anh em: khi model ngày càng giỏi, mình có xu hướng giao nhiều hơn, kiểm tra ít hơn, và để AI kéo nhịp phát triển nhanh hơn mức hệ thống chịu được.

Tin vui: model mạnh hơn giúp rút ngắn nhiều đoạn rất mệt

Với các mô hình coding đời mới, nhất là nhóm model giỏi đọc context dài và xử lý refactor phức tạp, lợi ích thấy khá rõ:

• hiểu codebase nhanh hơn khi dự án đã có nhiều file
• viết patch dài, ít đứt mạch hơn
• giải thích lỗi tốt hơn khi có log, stack trace, schema, test output
• hỗ trợ thiết kế module hoặc migration có cấu trúc hơn
• biến ý tưởng thô thành prototype nhanh hơn rất nhiều

Nếu trước đây mình mất nửa ngày để gom context, đọc vài file, thử vài hướng rồi mới bắt đầu sửa, thì bây giờ có thể dùng model mạnh như một “người đọc nháp” cực nhanh: đưa nó đi qua vùng code liên quan, nhờ nó lập bản đồ, rồi mình quyết định đường sửa.

Điểm đáng chú ý là model càng mạnh thì tác dụng lớn nhất không chỉ nằm ở tốc độ gõ code. Nó nằm ở tốc độ hiểu hệ thống.

Nhưng rủi ro cũng tăng theo: mình dễ tin quá sớm

Vấn đề của vibe coding không phải là AI viết code. Vấn đề là AI viết code đủ thuyết phục để mình bỏ qua các bước kiểm chứng.

Khi model trả lời mượt, giải thích hợp lý, patch nhìn sạch, mình rất dễ có cảm giác “chắc ổn rồi”. Nhưng trong dự án thật, các lỗi nguy hiểm thường không nằm ở đoạn code vừa sinh ra, mà nằm ở tương tác với phần còn lại:

• một migration chạy được local nhưng phá dữ liệu cũ
• một thay đổi auth làm hở quyền ở route phụ
• một refactor đổi contract ngầm giữa frontend và backend
• một tối ưu query làm sai edge case
• một component mới phá accessibility hoặc trạng thái loading
• một agent sửa đúng file nhưng bỏ qua test quan trọng ở package khác

Model càng mạnh thì lỗi càng khó phát hiện bằng mắt thường, vì code thường “trông có vẻ chuyên nghiệp”.

Cách dùng model mạnh mà không đốt ngân sách

Anh em không cần dùng model đắt nhất cho mọi bước. Một routing đơn giản có thể tiết kiệm rất nhiều:

1. Dùng model rẻ hơn cho việc gom thông tin

   • liệt kê file liên quan
   • tóm tắt log
   • viết checklist kiểm thử
   • tạo skeleton tài liệu

2. Dùng model mạnh cho phần cần suy luận sâu

   • thiết kế kiến trúc
   • phân tích bug nhiều tầng
   • refactor có ảnh hưởng rộng
   • review bảo mật, dữ liệu, concurrency

3. Dùng tool tự động cho phần không cần suy luận

   • formatter
   • lint
   • typecheck
   • unit test
   • snapshot test
   • migration dry-run

4. Cắt context theo nhiệm vụ

   • đừng ném cả repo vào một prompt nếu chỉ sửa một flow
   • tách “hiểu vấn đề”, “đề xuất plan”, “viết patch”, “review patch” thành các lượt riêng
   • lưu lại quyết định kiến trúc để không phải trả tiền đọc lại từ đầu

Một nguyên tắc khá thực dụng: model mạnh nên dùng như kiến trúc sư và reviewer, không phải như autocomplete vô hạn.

Checklist trước khi merge code do AI tạo

Mình thấy checklist này giúp giảm rất nhiều lỗi khi vibe coding với model mạnh:

• Có mô tả rõ thay đổi này chạm vào contract nào không?
• Có test cho đường chính và ít nhất một edge case chưa?
• Có chạy typecheck/lint/build chưa?
• Nếu có database: migration có rollback hoặc backup plan không?
• Nếu có auth/API key: có kiểm tra quyền ở server-side không?
• Nếu có background job: có xử lý retry/idempotency không?
• Nếu có UI: có trạng thái loading, empty, error không?
• Có file nào AI sửa ngoài phạm vi yêu cầu không?
• Có dependency mới nào thật sự cần thiết không?
• Có log hoặc dữ liệu nhạy cảm nào bị lộ không?

Không cần biến mọi prototype thành quy trình enterprise. Nhưng chỉ cần thêm một lớp kiểm chứng mỏng, anh em đã giảm được phần lớn “ảo giác ship được”.

Kết luận thực tế

Opus 4.8 hay bất kỳ model coding mạnh nào tiếp theo đều sẽ làm vibe coding nhanh hơn. Nhưng tốc độ không tự động biến thành chất lượng.

Cách dùng bền hơn là để AI kéo nhanh phần khám phá, dựng nháp và phân tích; còn mình giữ quyền quyết định ở những điểm có rủi ro: dữ liệu, bảo mật, kiến trúc, chi phí và trải nghiệm người dùng.

Nói ngắn gọn: model càng mạnh, kỷ luật kiểm chứng càng phải rõ. Không phải để làm chậm vibe coding, mà để tốc độ đó không biến thành nợ kỹ thuật chỉ sau vài tuần.