Đừng để AI “dọn code” khi chưa có đường quay lui

Một câu chuyện đang được bàn nhiều trong r/vibecoding: một người không phải dev chuyên nghiệp giao cho Claude “dọn code”, xoá nhánh chết và chỉnh lại nhãn. Agent khẳng định vài hàm không còn được gọi ở đâu, xoá chúng, rồi ứng dụng vỡ dây chuyền. Tệ hơn nữa: toàn bộ nằm trong một file index.html không có bản backup.

Điểm đáng nói không phải là “AI dở” hay “người dùng sai”. Bài học thực tế hơn là: vibe coding chỉ hiệu quả khi mình thiết kế được rào chắn cho những thao tác có thể phá sản phẩm.

Vấn đề thật sự: agent tự tin không đồng nghĩa với đúng

Khi mình nhờ AI refactor hoặc xoá code, nó thường sẽ làm ba việc cùng lúc:

• đọc code theo ngữ cảnh chưa chắc đầy đủ
• suy luận luồng gọi hàm dựa trên pattern nhìn thấy
• đề xuất hoặc thực hiện thay đổi với giọng rất chắc

Sai lầm nguy hiểm là xem sự tự tin đó như bằng chứng. Với codebase nhỏ, một hàm có thể được gọi qua HTML inline, callback, string selector, event listener, hoặc một đoạn script sinh động. Agent bỏ sót các đường gọi này là chuyện bình thường.

Vì vậy, câu lệnh “xoá hàm không còn dùng, nhớ double-check” vẫn chưa đủ an toàn. Mình cần quy trình bắt agent chứng minh thay đổi trước khi nó được phép đụng vào code.

Quy trình dọn code an toàn hơn

Nếu anh em đang vibe coding một app cá nhân, tối thiểu nên làm theo checklist này trước mọi lần “dọn rác”, “polish”, “refactor”, hoặc “delete dead code”.

1. Chụp lại trạng thái trước khi sửa

Không cần phức tạp ngay từ đầu. Ít nhất phải có một trong các cách sau:

git init
git add .
git commit -m "working version before cleanup"

Nếu chưa quen Git, cứ copy cả thư mục sang project-backup-YYYY-MM-DD-HHMM trước khi cho agent sửa. Cách thô nhưng còn hơn mất bản chạy được.

2. Bắt agent lập kế hoạch thay vì sửa ngay

Prompt nên tách làm hai bước:

Đừng sửa file ngay. Hãy liệt kê các thay đổi dự kiến, lý do, rủi ro, và cách kiểm chứng từng thay đổi. Với hàm muốn xoá, chỉ ra bằng chứng rằng nó không được gọi ở đâu.

Sau đó mới cho phép sửa từng nhóm nhỏ. Đừng giao một lệnh mơ hồ kiểu “clean up toàn bộ codebase”.

3. Không xoá ngay, hãy vô hiệu hoá có kiểm soát

Với hàm nghi là không dùng, an toàn hơn là:

• đổi tên tạm hoặc comment có đánh dấu
• chạy app qua các luồng chính
• kiểm tra console error
• chỉ xoá thật sau khi mọi thứ ổn

Nếu dự án chưa có test tự động, thao tác xoá code nên được coi là rủi ro cao.

4. Yêu cầu diff nhỏ và dễ đọc

Một lần sửa tốt nên tạo diff đủ nhỏ để mình đọc được. Nếu agent thay 800 dòng chỉ để “polish”, khả năng review gần như bằng không.

Prompt hữu ích:

Chỉ sửa phần cần thiết. Không đổi format toàn file. Sau khi sửa, tóm tắt chính xác file nào đổi, dòng nào đổi, và vì sao.

5. Luôn có bước chạy lại app

Sau mỗi thay đổi, cần một lệnh hoặc thao tác kiểm chứng rõ ràng:

• mở trang và thử luồng chính
• chạy test nếu có
• chạy linter nếu dự án có cấu hình
• kiểm tra console browser
• xác nhận tính năng cũ vẫn hoạt động

Agent có thể hỗ trợ kiểm tra, nhưng mình không nên để nó “tự báo xanh” nếu chưa có bằng chứng cụ thể.

Một prompt mẫu cho người không chuyên

Anh em có thể dùng prompt này trước khi cho AI dọn code:

Bạn là trợ lý code reviewer, không được sửa file cho đến khi tôi duyệt.

Mục tiêu: tìm code chết hoặc phần có thể đơn giản hoá.

Quy tắc:
1. Không xoá hàm, biến, event listener, hoặc CSS class nếu chưa chứng minh được không còn được dùng.
2. Với mỗi đề xuất xoá, hãy liệt kê nơi đã tìm kiếm và kết quả.
3. Nếu có khả năng được gọi động qua HTML, onclick, querySelector, addEventListener, setTimeout, hoặc string name, đánh dấu là rủi ro.
4. Chỉ đề xuất tối đa 5 thay đổi nhỏ trong một lượt.
5. Sau khi tôi duyệt, sửa từng thay đổi riêng và đưa diff.

Prompt này không làm AI hết sai, nhưng giảm đáng kể kiểu tai nạn “nó nói chắc nên mình tin”.

Kết luận thực tế

Vibe coding không nên được hiểu là “để AI tự lái hết”. Nó giống làm việc với một junior rất nhanh, rất chăm, nhưng đôi khi tự tin quá mức. Muốn dùng được, mình cần guardrail:

• có bản quay lui
• sửa theo diff nhỏ
• bắt giải thích trước khi hành động
• kiểm chứng sau mỗi bước
• không giao quyền xoá code hàng loạt khi chưa có test

Tin tốt là sự cố kiểu này thường không phải dấu chấm hết. Nó là tín hiệu để nâng workflow từ “chat với AI” thành “làm việc có kiểm soát với agent”. Khi có quy trình rollback và review, vibe coding vẫn rất mạnh, chỉ bớt cảm giác đánh bạc hơn.