Nơi nó thất bại
Hãy trung thực về những giới hạn, vì đây là nơi vibe coding không được giám sát sẽ làm hại người dùng:
- Logic sâu, mới lạ. Các thuật toán tinh vi, xử lý đồng thời (concurrency), bất cứ thứ gì mà đúng 95% cũng có nghĩa là hỏng. Mô hình vẫn tự tin ngay cả khi sai.
- Thay đổi trải dài trên nhiều file. Nó mất mạch theo dõi trong một codebase (mã nguồn dự án) lớn và âm thầm phá hỏng những thứ nó không nhìn thấy.
- Bảo mật và tiền bạc. Xác thực (auth), thanh toán, phân quyền, bất cứ điều gì mà một lỗi trông có vẻ hợp lý lại có hậu quả thực sự. Hãy xem xét những thứ này như thể công việc của bạn phụ thuộc vào đó, vì có thể đúng là như vậy.
- Vấn đề chưa được đặc tả rõ ràng. Nếu chính bạn không biết đúng là như thế nào, AI không thể đọc được suy nghĩ của bạn. Đặc tả rác vào, code rác ra.
Kiểu thất bại gần như luôn giống nhau: code trông có vẻ đúng, chạy được trên đường đi thuận lợi (happy path), và sai theo cách mà bạn đáng lẽ đã phát hiện nếu đọc nó. Cách khắc phục là bước xem xét. Không có cách nào để bỏ qua nó.
Hai câu hỏi giúp định vị bất kỳ công việc nào trên bản đồ này — khuôn mẫu có phổ biến không, và kết quả có dễ kiểm tra không:
EASY TO VERIFY HARD TO VERIFY
┌──────────────────┬──────────────────┐
COMMON │ PURE UPSIDE │ go slower, │
PATTERN │ (scaffold, │ demand tests │
│ boilerplate) │ │
├──────────────────┼──────────────────┤
RARE / │ read it, but │ DANGER ZONE │
NOVEL │ doable │ (novel logic, │
│ │ auth, money) │
└──────────────────┴──────────────────┘
Hãy chú ý điều ngược lại của quy tắc trên: đây là những trường hợp hiếm gặp, tinh vi, hoặc tốn kém để xác minh. Khuôn mẫu không phổ biến, nên mô hình đang đoán mò; hoặc lỗi vô hình trên đường đi thuận lợi, nên một kiểm tra nhanh sẽ không bắt được nó. Điều đó không có nghĩa là bạn tránh dùng AI ở đây — nó có nghĩa là bạn đi chậm lại, thu nhỏ các bước, yêu cầu test, và đọc từng dòng như thể nó thù địch.