Một meme đang lên trong r/vibecoding có tiêu đề “GitHub if it was vibe coded”. Nội dung chỉ là một ảnh đùa, nhưng nó chạm đúng một vấn đề khá thật: nếu mình để AI “vibe” quá nhiều mà thiếu cấu trúc, repo rất dễ biến thành nơi mọi thứ có vẻ chạy được, nhưng không ai còn biết vì sao nó chạy.
Với anh em dùng AI để code hằng ngày, GitHub không chỉ là chỗ lưu mã nguồn nữa. Nó là nơi giữ lại quyết định kỹ thuật, lịch sử thay đổi, tiêu chuẩn review và mức độ trưởng thành của sản phẩm. Nếu phần này bị làm ẩu, tốc độ ban đầu sẽ quay lại thành nợ kỹ thuật rất nhanh.
Vibe coding không sai, nhưng repo cần kỷ luật hơn
Điểm mạnh của vibe coding là giúp mình đi từ ý tưởng đến prototype nhanh. Nhưng GitHub lại cần một kiểu tư duy khác: chậm hơn một nhịp, rõ ràng hơn, có bằng chứng hơn.
Một repo “vibe coded” thường có vài dấu hiệu:
- commit message chung chung như
fix,update,final,try again - PR quá lớn, gom cả refactor, tính năng và sửa bug vào một lần
- không có issue hoặc task mô tả mục tiêu
- code chạy được trên máy người viết nhưng thiếu hướng dẫn setup
- test bị bỏ qua vì “AI đã kiểm tra rồi”
- README chỉ nói sản phẩm làm gì, không nói cách vận hành và giới hạn hiện tại
Những thứ này ban đầu không làm app hỏng ngay. Nhưng khi có thêm người dùng, thêm bug, hoặc thêm người cùng tham gia, chi phí hiểu lại hệ thống sẽ tăng rất nhanh.
Cách biến AI thành người phụ việc tốt hơn trên GitHub
Mình thấy cách thực tế nhất không phải là cấm AI tạo PR, mà là giới hạn vai trò của nó trong một quy trình rõ ràng.
1. Mỗi việc nên bắt đầu bằng issue ngắn
Trước khi nhờ AI sửa hoặc thêm tính năng, viết một issue thật ngắn:
- vấn đề là gì
- kết quả mong muốn là gì
- phạm vi không làm là gì
- cách kiểm tra là gì
Ví dụ:
Mục tiêu: thêm trang cài đặt API key cho người dùng.
Không làm: chưa cần billing, chưa cần team sharing.
Kiểm tra: user lưu key, refresh trang vẫn thấy trạng thái đã cấu hình, key không bị log ra console.
Prompt cho AI dựa trên issue này sẽ tốt hơn nhiều so với “build settings page”.
2. PR phải nhỏ và có checklist
Nếu AI tạo một PR hơn vài trăm dòng, mình thường yêu cầu tách lại. Một PR tốt nên trả lời được:
- thay đổi chính là gì
- file nào quan trọng nhất
- rủi ro nằm ở đâu
- đã test bằng cách nào
- có migration, config, secret hoặc thay đổi deploy không
Checklist này không cần dài, nhưng nó ép mình nhìn sản phẩm như một hệ thống chứ không chỉ như một đoạn code vừa sinh ra.
3. Bắt AI viết ghi chú review trước khi mình review
Một mẹo hữu ích: yêu cầu AI tự review PR của nó trước.
Prompt mẫu:
Hãy review diff này như một maintainer khó tính.
Tìm bug, case biên, vấn đề bảo mật, test còn thiếu và chỗ code khó bảo trì.
Không khen chung chung. Chỉ liệt kê vấn đề cụ thể và đề xuất sửa.
Kết quả không thay thế review của người thật, nhưng thường bắt được nhiều lỗi hiển nhiên: biến không dùng, thiếu xử lý null, logic trùng lặp, hoặc test chỉ kiểm tra happy path.
4. README phải ghi cả giới hạn hiện tại
Nhiều repo AI-assisted nhìn rất bóng ở phần demo nhưng thiếu phần vận hành. README nên có thêm:
- cách chạy local
- biến môi trường cần thiết
- lệnh test/lint/build
- tính năng đã có
- giới hạn hiện tại
- phần nào đang experimental
Ghi rõ giới hạn không làm dự án yếu đi. Ngược lại, nó giúp người sau không đoán sai trạng thái sản phẩm.
Một quy tắc đơn giản: AI được tăng tốc, không được xóa dấu vết
Nếu dùng AI mà lịch sử GitHub trở nên mờ hơn, đó là tín hiệu xấu. Mỗi commit, PR, issue nên giúp người sau hiểu nhanh hơn: tại sao có thay đổi này, nó xử lý vấn đề gì, và còn rủi ro nào.
Công thức mình thích là:
- AI tạo bản nháp
- người dùng đặt phạm vi
- CI kiểm tra phần máy móc
- PR mô tả quyết định
- maintainer giữ quyền nói “chưa đủ rõ”
Vibe coding sẽ có giá trị nhất khi nó tăng tốc vòng lặp học và thử nghiệm, chứ không biến repo thành một hộp đen khó bảo trì. Meme thì vui, nhưng nếu GitHub của mình bắt đầu giống meme đó, có lẽ đã đến lúc thêm lại một chút kỷ luật kỹ thuật.
Top comments (0)