Vibe coding trôi vào production — chọn neo ở đâu?
Ranh giới giữa vibe coding và agentic engineering đang mờ dần. Team bạn cần một khung phân loại task trước khi trượt sang vùng rủi ro mà không hay.
Bụi WireBài toán
"Those things have started to blur for me already, which is quite upsetting." — Simon Willison chia sẻ trong podcast High Leverage tuần này, về khoảnh khắc nhận ra mình đang vibe coding ngay giữa dự án production.
Nếu bạn nghĩ vibe coding và agentic engineering là hai thứ tách bạch — một bên là "thả" hoàn toàn, bên kia là kỹ sư kiểm soát mọi dòng code — thì tin buồn: ranh giới đó đang mờ đi nhanh hơn hầu hết team kịp nhận ra.
Bài toán thật sự không phải "có nên vibe coding hay không". Mà là: team bạn có policy rõ ràng để phân loại lúc nào được thả, lúc nào phải giữ không?
Hai lựa chọn đang hòa vào nhau
Vibe coding — bạn prompt, nhận code, chạy thử, nếu lỗi thì prompt tiếp. Không đọc code, không review, không quan tâm internal quality. Phù hợp tool cá nhân, prototype nhanh, thứ mà nếu hỏng chỉ bạn chịu.
Agentic engineering — vẫn dùng AI agent viết code, nhưng bạn giữ vai kiến trúc sư: review diff, kiểm security, đảm bảo maintainability. Agent làm execution, bạn làm oversight (giám sát chất lượng đầu ra).
Vấn đề: khi agent ngày càng giỏi, cám dỗ bỏ qua review ngày càng lớn. Giả sử team bạn 5 người, mỗi ngày agent generate hàng trăm dòng code — ai cũng bắt đầu "lướt diff" thay vì đọc kỹ. Từ agentic engineering, team dần trượt sang vibe coding mà không hề chủ đích.
Simon gọi đây là điểm "upsetting" vì ngay cả một developer kỳ cựu cũng tự bắt gặp mình đang trượt.
Tradeoff: tốc độ vs. kiểm soát
| | Vibe coding thuần | Agentic engineering có oversight |
|---|---|---|
| Tốc độ ship | Rất nhanh | Nhanh, nhưng có bước review |
| Rủi ro security | Cao — không ai đọc code | Thấp hơn — có review layer |
| Technical debt | Tích lũy ngầm | Kiểm soát được |
| Phù hợp khi | Tool cá nhân, prototype, hackathon | Product cho user, data nhạy cảm |
| Chi phí oversight | ~0 | 20–40% thời gian dev/sprint |
Cái bẫy nằm ở chỗ: chi phí oversight không cố định. Khi agent output tốt 9/10 lần, não bạn tự động giảm cảnh giác — giống thuyền trưởng bật autopilot rồi dần quên nhìn radar. Lần thứ 10, bug security lọt qua, và bạn chỉ phát hiện khi user report.
Một team ở Sài Gòn mình biết gần đây gặp đúng kịch bản này: dùng Cursor agentic mode cho API endpoint mới, agent viết đúng logic nhưng thiếu rate limiting. Vì 4 endpoint trước đều ổn, dev approve diff trong 2 phút thay vì 10. Kết quả: bot spam endpoint suốt cuối tuần trước khi ai phát hiện.
Khuyến nghị: phân loại task trước khi bật agent
Thay vì tranh cãi "vibe coding có tệ không", mình đề xuất team dùng một bảng phân loại đơn giản:
Mức 1 — Thả hoàn toàn (vibe coding OK):
- Script nội bộ dùng một lần
- Prototype demo cho stakeholder
- Tool cá nhân không chạm user data
Mức 2 — Agent viết, human review kỹ:
- Feature mới trên product đang live
- Bất kỳ code nào chạm authentication, payment, PII
- Infra config (Terraform, Kubernetes manifest)
Mức 3 — Human viết, agent hỗ trợ:
- Security-critical logic (crypto, access control)
- Migration data production
- Code ảnh hưởng compliance/pháp lý
Khung này không mới về ý tưởng, nhưng điểm quan trọng là viết ra thành policy và review mỗi sprint. Vì ranh giới đang dịch chuyển — thứ hôm nay ở Mức 2, khi agent cải thiện và team có test coverage tốt hơn, có thể xuống Mức 1.
Cách thử ngay trong buổi chiều: mở board task tuần này, tag mỗi ticket một trong 3 mức trên. Nếu team không đồng thuận được mức cho một ticket — đó chính là tín hiệu cần thảo luận thêm, không phải mặc định "thả".
Rủi ro còn lại
Dù có policy, hai rủi ro vẫn tồn tại:
1. Drift không ý thức. Policy nói Mức 2 nhưng dev mệt cuối sprint vẫn approve diff trong 30 giây. Giải pháp: CI gate bắt buộc — ít nhất chạy SAST (static analysis security testing — quét lỗ hổng tự động trên code) trước merge, để máy bắt cái mà mắt người bỏ sót.
2. False sense of security. Agent viết code "nhìn đúng" dễ hơn viết code thật sự đúng. Bạn review và thấy "logic hợp lý" nhưng edge case vẫn thiếu. Giải pháp: viết test trước (hoặc nhờ agent viết test trước), rồi mới generate implementation. Agent viết test cho chính output của nó — ít nhất tốt hơn không có test.
Nói thẳng ra: không có policy nào triệt tiêu hoàn toàn rủi ro. Nhưng team có khung phân loại rõ sẽ trượt chậm hơn, và phát hiện sớm hơn khi bắt đầu trôi. Con thuyền nào cũng bị dòng nước kéo — khác biệt nằm ở việc có thả neo đúng chỗ hay không.
---
Bụi Wire — nghiện đọc release notes lúc 2 giờ sáng