AI & Automation (vnROM)

Cover image for Khi vibe coding gặp biến động: xây workflow AI chịu lỗi thay vì chỉ chạy nhanh
quynhtruong
quynhtruong

Posted on • Originally published at reddit.com

Khi vibe coding gặp biến động: xây workflow AI chịu lỗi thay vì chỉ chạy nhanh

Một meme ngắn trên r/vibecoding nói kiểu “we are cooked”, rồi đùa rằng nếu có thêm một đợt Covid nữa thì đúng là “cherry on the cake”. Nghe như một câu than vui, nhưng nó chạm đúng cảm giác chung của nhiều anh em đang làm sản phẩm với AI: công cụ thay đổi quá nhanh, thị trường việc làm khó đoán, quy trình dev bị đảo lộn, và đôi khi chỉ cần thêm một cú sốc bên ngoài là mọi kế hoạch lại phải viết lại.

Điểm đáng chú ý không phải là nỗi sợ, mà là cách mình thiết kế workflow để vẫn chạy được khi mọi thứ nhiễu.

Vibe coding không nên phụ thuộc vào một điều kiện lý tưởng

Một lỗi phổ biến khi mới dùng AI coding là xây workflow như thể lúc nào cũng có:

  • model mạnh nhất đang hoạt động ổn định
  • mạng tốt, API không nghẽn
  • yêu cầu sản phẩm rõ ràng ngay từ đầu
  • người review đủ tỉnh táo để đọc hết code AI sinh ra
  • lịch làm việc không bị gián đoạn

Thực tế thì ngược lại. Model có thể đổi hành vi sau một bản cập nhật. Tool có thể rate limit. Context có thể quá dài. Người dùng có thể đổi yêu cầu. Và nếu có biến động lớn hơn như dịch bệnh, cắt giảm ngân sách, hoặc team phải làm remote hoàn toàn, những workflow quá mong manh sẽ gãy rất nhanh.

Vì vậy, thay vì hỏi “AI có giúp mình code nhanh hơn không?”, câu hỏi thực dụng hơn là: “Nếu điều kiện xấu đi 30%, workflow này có còn chạy được không?”

Ba lớp dự phòng nên có trong một workflow AI coding

1. Dự phòng về ngữ cảnh

AI làm tốt hơn nhiều khi hiểu bối cảnh, nhưng bối cảnh không nên chỉ nằm trong đầu một người. Với mỗi feature, mình nên có một file ngắn ghi lại:

  • mục tiêu của feature
  • hành vi không được phá vỡ
  • các rule nghiệp vụ quan trọng
  • cách test hoặc kiểm chứng tối thiểu
  • quyết định kỹ thuật đã chốt và lý do

Không cần viết tài liệu dài. Một spec 10-20 dòng thường đã đủ để tránh kiểu “code nhìn sạch nhưng sai ý”. Khi mọi người bị gián đoạn hoặc phải bàn giao nhanh, file này giúp workflow không phụ thuộc vào trí nhớ cá nhân.

2. Dự phòng về công cụ

Đừng để toàn bộ dự án phụ thuộc vào một model, một extension, hoặc một SaaS duy nhất. Với những việc quan trọng, nên tách rõ:

  • model chính để sinh code
  • cách chạy test độc lập với model
  • script build/deploy không phụ thuộc UI
  • checklist review thủ công
  • log quyết định để có thể quay lại khi AI đề xuất sai

Điều này không có nghĩa là lúc nào cũng phải dùng nhiều model. Ý chính là output của AI phải đi qua những cổng kiểm chứng mà mình kiểm soát được: test, lint, typecheck, review diff, staging, rollback.

3. Dự phòng về con người

Vibe coding dễ tạo cảm giác một người có thể làm việc của cả team. Nhưng nếu người đó là điểm nghẽn duy nhất cho prompt, review, deploy và debug, hệ thống vẫn rủi ro.

Một workflow khỏe hơn nên có:

  • task nhỏ, dễ review
  • PR hoặc patch có mô tả rõ AI đã làm gì
  • convention đặt tên và cấu trúc repo nhất quán
  • phần “known risks” trong mỗi thay đổi lớn
  • giới hạn thời gian review để tránh mệt mỏi kéo dài

AI có thể tăng tốc phần gõ code, nhưng chưa tự động xóa được trách nhiệm thiết kế và kiểm chứng.

Checklist nhanh: workflow này có chịu được biến động không?

Trước khi để AI xử lý một phần quan trọng, mình có thể tự hỏi:

  • Nếu model sinh code sai nhưng trông rất hợp lý, mình phát hiện bằng gì?
  • Nếu ngày mai đổi model, prompt/spec hiện tại có còn dùng được không?
  • Nếu người đang giữ context nghỉ 3 ngày, người khác có tiếp tục được không?
  • Nếu API hoặc tool AI bị nghẽn, team có đường làm thủ công tối thiểu không?
  • Nếu phải rollback, mình có biết thay đổi nào là do AI tạo và vì sao không?

Nếu trả lời “không” quá nhiều, vấn đề không nằm ở AI mạnh hay yếu, mà nằm ở hệ thống làm việc quanh AI.

Kết luận

Cảm giác “we are cooked” thường xuất hiện khi mình nhìn AI, thị trường và thế giới như một chuỗi biến động không kiểm soát được. Nhưng với anh em làm sản phẩm, cách phản ứng tốt nhất không phải là hoảng, cũng không phải là tin mù quáng rằng model mới sẽ giải quyết hết.

Cách thực tế hơn là xây workflow có khả năng chịu lỗi: context được ghi lại, output được kiểm chứng, công cụ có đường dự phòng, và con người vẫn giữ vai trò quyết định. Vibe coding lúc đó không chỉ là code nhanh hơn, mà là ship được trong điều kiện không hoàn hảo.

Top comments (0)