Có một kiểu tự tin rất nguy hiểm trong thời AI hỗ trợ viết phần mềm: sản phẩm vẫn chạy, flow vẫn thông, demo vẫn đẹp nên mình nghĩ là đã đủ để ship. Nhưng một thread đang hot trên r/vibecoding lại nhắc anh em một chuyện khá thực tế: đến lúc đem code cho một senior dev xem, người ta vẫn có thể nhận ra ngay đây là code đi qua pipeline AI, và họ cũng chỉ ra đúng chỗ cần siết lại trước khi đưa ra đời thật.
Tác giả bài gốc kể rằng họ không hoàn toàn tin vào việc ship một app mà toàn bộ đầu-cuối đều do AI dẫn dắt, nên đã thuê một senior full stack dev có khoảng 12 năm kinh nghiệm để review. Quy trình làm của họ khá quen thuộc với nhiều anh em hiện nay: dùng ChatGPT để chuẩn hoá ý tưởng thành yêu cầu rõ ràng, dùng Claude Code để dựng logic và schema, rồi đưa tiếp vào Lovable với một số guardrail để hoàn thiện trải nghiệm. Kết quả ban đầu không tệ. Người review nói code là “good”, nhưng vẫn có vài vấn đề bảo mật cần xử lý.
Điểm thú vị nằm ở chỗ khác: chỉ nhìn vào codebase, senior dev đó đoán ra ngay bộ công cụ đã được dùng. Theo mô tả từ bài gốc, ông ấy nhận ra dấu vết của Lovable và có thể cả Claude Code chỉ từ cách thư mục được tổ chức, cách project được dựng, và một số pattern quen mặt. Đây là chi tiết đáng để anh em làm sản phẩm bằng AI suy nghĩ kỹ, vì nó cho thấy AI không chỉ giúp tăng tốc, mà còn để lại “vân tay kỹ thuật” khá rõ.
Vì sao code AI thường bị nhận ra nhanh
Có ba lý do chính.
Thứ nhất là cấu trúc dự án thường mang tính template rất mạnh. Nhiều công cụ AI sinh ra folder layout, naming convention và cách chia module theo những mẫu lặp lại. Với người review nhiều codebase, chỉ cần nhìn vài phút là họ đã thấy phong cách quen thuộc.
Thứ hai là mức độ đồng đều hơi bất thường. Code AI thường tạo ra những đoạn nhìn khá sạch, khá chỉn chu ở bề mặt, nhưng khi đi sâu sẽ thấy sự không đồng nhất về mức ưu tiên. Chỗ thì validate rất kỹ, chỗ thì bỏ trống edge case. Chỗ thì comments kỹ như tài liệu, chỗ khác lại thiếu hẳn reasoning kỹ thuật. Một người già kinh nghiệm sẽ thấy ngay nhịp này không giống cách một team người thật đi từ bài toán đến quyết định kiến trúc.
Thứ ba là AI hay tối ưu cho “đúng yêu cầu hiện tại” hơn là “đúng điều kiện vận hành thực tế”. Nghĩa là nó làm rất tốt những gì prompt yêu cầu, nhưng lại hay để hở các vấn đề kiểu production readiness: phân quyền, logging, rate limiting, xử lý lỗi, secret handling, migration safety, quan sát hệ thống sau khi deploy.
Tin tốt là bị nhận ra không phải vấn đề lớn nhất
Chi tiết đáng chú ý trong câu chuyện này không phải là senior dev đoán được tool nào đã được dùng. Tin tốt hơn là sau khi review, đánh giá tổng thể vẫn tích cực. Code không bị chê là vứt đi. Nó được xem là có nền tảng ổn, chỉ cần xử lý đúng các điểm an toàn và chất lượng trước khi ship.
Đây là góc nhìn mà mình nghĩ cộng đồng nên giữ tỉnh táo. Tranh luận “code AI có đáng xài không” đang dần kém hữu ích. Câu hỏi thực chiến hơn là: code AI tới mức nào thì đủ để một người có nghề review, chịu trách nhiệm, và cho qua ở mức có thể vận hành.
Nếu một senior dev nhìn code rồi nói “ổn đấy, nhưng phải vá mấy chỗ này trước”, thì đó thực ra là tín hiệu tốt. Nó có nghĩa là AI đã giúp đội ngũ đi nhanh hơn ở phần xây dựng ban đầu, còn phần còn lại phải được hoàn thiện bằng kỷ luật kỹ thuật.
Bài học cho anh em đang vibe coding sản phẩm thật
1. Đừng lấy cảm giác hoàn thiện của UI làm thước đo chất lượng
AI cực giỏi tạo cảm giác sản phẩm đã gần xong. Form chạy được, dashboard đẹp, thao tác mượt, nên rất dễ sinh ảo giác là hệ thống phía sau cũng ổn. Trong thực tế, bảo mật và độ bền vận hành thường nằm ở những chỗ mắt thường không thấy ngay.
2. Review ngoài cuộc là khoản chi rất đáng tiền
Trong bài gốc, tác giả nói khoản 1.000 USD bỏ ra là xứng đáng. Mình thấy hợp lý. Nếu anh em đang xây cái gì có liên quan tới dữ liệu người dùng, thanh toán, auth, hoặc quy trình doanh nghiệp, một buổi audit tử tế thường rẻ hơn rất nhiều so với một lỗi production.
Không nhất thiết phải thuê người full-time. Nhưng nên có ít nhất một vòng review bởi người đã từng chịu trách nhiệm cho hệ thống thật ngoài đời.
3. Cần checklist production thay vì chỉ prompt tốt
Prompt tốt giúp tạo code nhanh hơn. Nhưng để ship được, anh em cần một checklist riêng, ví dụ:
- Auth và phân quyền đã kiểm tra theo từng role chưa
- Input validation có nhất quán từ client tới server chưa
- Secret, API key, token có bị lộ trong repo hoặc log không
- Error handling có lộ thông tin nhạy cảm không
- Có rate limit, audit log, backup và rollback plan chưa
- Migration dữ liệu có an toàn nếu deploy nhiều lần không
- Có monitoring tối thiểu để biết hệ thống đang hỏng ở đâu không
Đây là những thứ AI có thể hỗ trợ viết ra, nhưng không nên để AI tự xác nhận là đã làm xong.
4. Chấp nhận rằng AI để lại dấu vết, và quản nó như một phần của quy trình
Việc code “nhìn ra là AI” không nhất thiết làm giảm giá trị sản phẩm. Vấn đề là anh em có kiểm soát được chất lượng đầu ra hay không. Nếu quy trình của mình có bước review, test, security audit và sửa theo phản hồi, thì dấu vết AI chỉ là nguồn gốc sản xuất, không phải bản án về chất lượng.
Ngược lại, nếu mình dùng AI như tấm khiên để né trách nhiệm kỹ thuật, thì lúc đó dấu vết AI chỉ là triệu chứng của một quy trình yếu.
Một góc nhìn đáng chú ý cho giai đoạn sắp tới
Khi thị trường có nhiều sản phẩm được làm bằng AI hơn, khả năng cao sẽ xuất hiện một “mắt nghề” mới trong giới kỹ thuật: nhìn code là đoán được pipeline tạo ra nó, rồi từ đó suy ra những rủi ro phổ biến cần soi kỹ hơn. Điều này khá giống chuyện bảo mật viên nhìn log là đoán ra kiểu tấn công, hoặc người nhiều kinh nghiệm vận hành nhìn dashboard là đoán được lỗi nằm ở tầng nào.
Nói cách khác, tương lai gần có thể không phải là cuộc đua xem ai dùng AI hay không. Nó sẽ là cuộc đua xem ai biết kết hợp AI với review người thật, tiêu chuẩn kỹ thuật thật, và trách nhiệm vận hành thật.
Kết luận
Thread này đáng đọc vì nó không tâng bốc AI cũng không phủ nhận nó. Nó cho thấy một trạng thái trưởng thành hơn: AI có thể giúp anh em dựng sản phẩm nhanh, nhưng để qua cửa production thì vẫn cần một người đủ nghề nhìn vào và nói thẳng đâu là điểm yếu cần vá.
Nếu anh em đang build bằng vibe coding và bắt đầu có người dùng thật, đây là lúc nên tự hỏi một câu đơn giản: code của mình đã từng được một người có kinh nghiệm production review nghiêm túc chưa?
Nếu chưa, có lẽ đó là bước tiếp theo đáng làm hơn là thêm một prompt mới.
Top comments (0)