Một meme đang nổi trong r/vibecoding nói rằng: vibe coder đi về lúc 12:30 trưa vì đã chạm rate limit ChatGPT. Nghe như chuyện cười, nhưng nó chạm đúng một vấn đề thật: khi workflow phụ thuộc quá nhiều vào một công cụ AI duy nhất, giới hạn quota không còn là chi tiết kỹ thuật nữa, mà trở thành “đồng hồ công sở” mới.
Vì sao meme này đáng để ý
Trước đây, điểm nghẽn của dev thường là:
- thiếu spec rõ ràng
- build/test quá chậm
- thiếu review
- context dự án quá rối
- phải chờ người khác trả lời
Với vibe coding, thêm một điểm nghẽn mới xuất hiện: giới hạn của model. Hết token, hết lượt gọi, server quá tải, hoặc model bị degrade chất lượng là cả nhịp làm việc bị gãy.
Điều đáng nói là nhiều người không nhận ra mình đã thiết kế quy trình quanh AI cho đến khi công cụ dừng lại.
Rate limit là tín hiệu, không chỉ là phiền toái
Nếu hết quota là không làm tiếp được, có thể workflow của mình đang thiếu vài lớp dự phòng:
- Không có checklist kỹ thuật độc lập với AI
- Không có backlog việc “offline” như viết test, đọc log, dọn issue, refactor nhỏ
- Không lưu lại prompt, quyết định, giả định quan trọng sau mỗi phiên làm việc
- Không tách việc cần model mạnh khỏi việc model nhẹ hoặc tool tự động làm được
- Không có cách tự kiểm chứng output ngoài việc hỏi tiếp AI
Nói ngắn gọn: AI đang là accelerator, nhưng vô tình bị biến thành single point of failure.
Một cách làm bền hơn cho anh em vibe coding
Mình thấy nên chia buổi làm việc thành 4 lớp, thay vì mở ChatGPT/Cursor/Claude rồi để model kéo toàn bộ nhịp đi.
1. Pha thiết kế ngắn trước khi gọi AI
Trước mỗi task, viết 5 dòng:
- mục tiêu cụ thể
- file/khu vực liên quan
- điều không được phá
- test hoặc dấu hiệu hoàn thành
- câu hỏi còn chưa rõ
Làm vậy giúp mỗi lượt gọi AI có trọng lượng hơn, đỡ đốt quota vào việc “nghĩ hộ từ đầu”.
2. Pha sinh code có giới hạn
Đừng yêu cầu model làm quá rộng. Thay vì “build feature X”, nên chia thành:
- đề xuất hướng sửa
- liệt kê file cần chạm
- viết patch nhỏ
- tự review patch
- tạo test case
Một lượt gọi nhỏ nhưng rõ thường rẻ hơn nhiều so với một prompt lớn rồi phải sửa đi sửa lại.
3. Pha offline khi hết quota
Nếu rate limit đến, vẫn còn nhiều việc có ích:
- chạy test và ghi lại lỗi thật
- đọc diff để tìm thay đổi nguy hiểm
- viết issue note hoặc changelog
- thêm logging tạm để debug
- gom câu hỏi cho phiên AI kế tiếp
- đơn giản hóa repro case
Đây là phần biến “hết quota” từ mất việc thành thời gian kiểm chứng.
4. Pha tổng kết sau mỗi phiên AI
Cuối mỗi block, lưu lại:
- model đã giúp quyết định gì
- phần nào đã test thật
- phần nào chỉ mới là giả định
- việc tiếp theo không cần AI
- việc tiếp theo cần AI mạnh
Nếu không có lớp này, hôm sau mở lại rất dễ phải dùng thêm token chỉ để khôi phục context.
Checklist chống phụ thuộc rate limit
Anh em có thể thử checklist này cho dự án đang làm:
- Có thể tiếp tục làm ít nhất 30 phút nếu AI ngừng không?
- Có test hoặc script kiểm chứng thay vì chỉ hỏi AI “ổn chưa” không?
- Có lưu prompt/decision quan trọng vào docs hoặc issue không?
- Có phân loại task nào cần model mạnh, task nào dùng model rẻ hơn được không?
- Có giới hạn số file trong mỗi patch AI tạo không?
- Có review thủ công các phần liên quan auth, payment, data, migration không?
Nếu câu trả lời phần lớn là “không”, vấn đề không phải rate limit. Vấn đề là workflow chưa có xương sống.
Kết luận thực tế
Meme “về nhà lúc 12:30 vì hết ChatGPT” buồn cười vì nó đúng một phần. AI giúp mình đi nhanh hơn, nhưng nếu mọi quyết định, mọi bước debug, mọi lần đọc code đều phải đi qua model, thì năng suất của mình sẽ bị khóa vào quota của nhà cung cấp.
Cách tốt hơn không phải là bỏ AI, mà là thiết kế workflow để AI là động cơ tăng tốc, còn người làm vẫn giữ được tay lái: biết cần hỏi gì, biết kiểm chứng ra sao, và vẫn có việc giá trị để làm khi model tạm thời im lặng.
Top comments (0)