Một câu chuyện khá nhỏ trên r/vibecoding lại chạm đúng một vấn đề rất lớn của thời AI code: khi AI có thể sinh ra code chạy được rất nhanh, người giữ chất lượng hệ thống rốt cuộc phải chịu trách nhiệm cho phần nào.
Case lần này đến từ một bài post có tiêu đề khá gắt: PR Rejected, Vibe coding just cost a junior dev 50OKB of fonts he didn't need. Nội dung không xoay quanh mô hình mới hay framework mới, mà là một tình huống rất đời thường trong team dev: một bạn junior build tính năng tạo PDF cho app Android, mọi thứ chạy ổn, nhưng phần implementation lại bundle luôn font Roboto vào source code dù Android vốn đã có sẵn font này ở hệ thống.
Nghe có vẻ là chuyện nhỏ. Nhưng chính những chuyện nhỏ như vậy mới cho thấy rất rõ mặt trái của vibe coding khi anh em dùng AI mà không còn kiểm tra đủ kỹ môi trường thực thi thật.
Câu chuyện gốc: code chạy được, nhưng quyết định kỹ thuật lại sai
Theo bài chia sẻ, junior dev đã nhúng Roboto-Regular.ttf và Roboto-Bold.ttf trực tiếp vào project để đảm bảo PDF render đúng định dạng. Khi reviewer nhắc rằng Roboto là font mặc định đã có sẵn trên Android và không cần ship lại, phản ứng đầu tiên của bạn ấy là hoảng: nếu xóa đi thì code sẽ hỏng.
Sau đó reviewer xóa hẳn font asset, chỉnh lại phần load font sang đường dẫn hệ thống, và kết quả là:
- app vẫn compile bình thường
- PDF vẫn render đúng
- phần asset dư thừa biến mất
Khoảnh khắc gây chú ý nhất là câu nói của bạn junior: vì đoạn đó do ChatGPT viết nên bạn ấy mặc định tin là nó cần thiết.
Chính chỗ này làm bài post lan mạnh. Nó không phải câu chuyện về một bug khó hay một màn tối ưu phức tạp. Nó là ví dụ rất rõ cho việc AI có thể sinh ra lời giải trông hợp lý, chạy được, nhưng vẫn cài vào hệ thống những phần dư thừa mà người viết không thật sự hiểu.
Vì sao bài này đáng đọc với anh em làm vibe coding
Mình nghĩ bài này hot vì nó chạm đúng ba nỗi lo thật.
1. AI đã kéo chi phí viết cú pháp xuống gần bằng 0
Ngày trước, chỉ riêng việc tra API, viết boilerplate hay nối vài bước xử lý đã tốn đáng kể thời gian. Giờ thì chỉ cần mô tả tương đối rõ là AI có thể sinh ra một bản chạy được rất nhanh.
Điều đó làm năng suất tăng thật. Nhưng nó cũng tạo ra ảo giác rằng nếu code chạy thì quyết định kỹ thuật bên dưới chắc cũng ổn.
Thực tế không phải vậy. Một hệ thống có thể chạy tốt trong demo nhưng vẫn sai ở các tầng như:
- dùng sai tài nguyên có sẵn của nền tảng
- lặp dependency không cần thiết
- tăng dung lượng app vô ích
- che khuất logic gốc dưới một lớp boilerplate dư thừa
- tạo tiền lệ review lỏng tay cho cả team
2. Giá trị của architectural judgment đang tăng lên rất nhanh
Câu mạnh nhất trong bài gốc là: AI làm cho chi phí syntax về gần 0, nhưng lại đẩy giá trị của architectural judgment lên mức rất cao.
Đây là nhận định khá chuẩn. Trong môi trường có AI hỗ trợ, khác biệt giữa một người chỉ biết prompt và một người thật sự làm chủ hệ thống thường nằm ở các câu hỏi như:
- môi trường này đã có sẵn gì
- đâu là abstraction nên tái dùng thay vì nhúng thêm
- chỗ nào là logic nghiệp vụ thật, chỗ nào chỉ là phần AI đoán ra cho đủ bài
- thứ đang được thêm vào có làm tăng chi phí bảo trì hay không
Junior trong bài không sai vì dùng AI. Sai nằm ở việc tin output như một chân lý kỹ thuật mà không đối chiếu với thực tế của Android.
3. Vibe coding rất dễ đẩy team vào trạng thái “ship nhanh nhưng phình to”
Một file font thêm vào hôm nay có vẻ không đáng kể. Nhưng kiểu quyết định này nếu lặp lại nhiều lần sẽ tạo ra những hệ quả tích lũy:
- app ngày càng nặng
- repo ngày càng rối
- dependency khó kiểm soát hơn
- reviewer mất nhiều thời gian hơn để dọn hậu quả
- người mới học được thói quen tin AI trước, hiểu platform sau
Đó mới là vấn đề vận hành thực sự. Không phải 500KB font, mà là hướng tư duy phía sau nó.
Bài học thực chiến cho team đang dùng AI để code
Nếu chuyển câu chuyện này thành checklist vận hành, mình nghĩ có mấy điểm rất đáng giữ.
Luôn kiểm tra môi trường trước khi chấp nhận code sinh bởi AI
Khi AI đề xuất cách làm, anh em nên hỏi thêm:
- nền tảng này đã có sẵn thư viện, font, component hay API tương đương chưa
- có cách native nào đơn giản hơn không
- phần được thêm vào có đang duplicate thứ hệ điều hành hoặc framework đã cung cấp không
Rất nhiều output của AI đúng ở mức cú pháp nhưng sai ở mức bối cảnh.
Review nên tập trung vào “có cần tồn tại không”, không chỉ “có chạy không”
Đây là thay đổi mindset khá quan trọng. Trước kia nhiều review dừng ở việc code đúng và pass build. Bây giờ, với AI-generated code, reviewer nên hỏi thêm:
- đoạn này có thật sự cần không
- có cách ít thành phần hơn không
- nếu xóa nó đi thì hệ thống còn hoạt động không
- nó dựa trên tri thức thật của platform hay chỉ là phỏng đoán hợp lý của model
Chỉ riêng câu hỏi “nếu bỏ phần này đi thì sao” đã cứu được rất nhiều PR thừa.
Dạy junior cách nghi ngờ output đẹp
Một trong những kỹ năng mới quan trọng nhất không phải là prompt hay hơn, mà là biết nghi ngờ đúng chỗ. Junior cần được rèn thói quen:
- không mặc định AI đúng
- đọc tài liệu nền tảng thật
- thử bỏ bớt những phần nghi ngờ là boilerplate vô ích
- hiểu vì sao code hoạt động thay vì chỉ xác nhận là nó hoạt động
Nếu không, AI sẽ biến người mới thành người giao hàng nhanh cho đống kỹ thuật nợ.
Đo chất lượng bằng mức độ tối giản có chủ đích
Trong thời AI, sự tối giản có chủ đích trở thành chỉ báo chất lượng rất mạnh. Một implementation tốt không chỉ là implementation chạy được, mà là implementation:
- ít phần thừa
- tận dụng đúng capability có sẵn
- dễ giải thích cho người khác
- dễ bảo trì sau vài tháng
Nói ngắn gọn: đơn giản không còn là “nice to have”. Nó là hàng rào chống hallucination ở cấp hệ thống.
Từ một bài post nhỏ đến một xu hướng lớn hơn
Điểm hay của bài này là nó không nói về AI bằng ngôn ngữ quá hàn lâm. Nó chỉ kể một cảnh rất thật trong team: AI viết ra thứ nhìn ổn, junior tin, reviewer phải dọn.
Nhưng phía sau là một xu hướng ngày càng rõ trong cộng đồng vibe coding:
- AI tăng tốc độ viết code
- con người vẫn phải chịu trách nhiệm cho tính phù hợp với môi trường
- review tốt ngày nay không chỉ bắt lỗi logic, mà còn phải bóc các phần dư do AI sinh ra
Vì vậy, nếu anh em đang build app, agent hay bất kỳ sản phẩm nào có AI hỗ trợ lập trình, case này là lời nhắc khá thẳng:
Đừng tự hào quá sớm vì code chạy. Hãy hỏi thêm xem hệ thống có đang gọn hơn, đúng hơn và bền hơn sau thay đổi đó hay không.
Kết lại
Mình nghĩ đây là một bài post rất đúng chất chia sẻ và tin tức: không quá lớn, nhưng chạm đúng mạch thời sự của nghề. Khi AI làm cho việc sinh code trở nên quá dễ, năng lực phân biệt giữa “cần thiết” và “dư thừa” sẽ trở thành lợi thế thật của người làm kỹ thuật.
Ship nhanh vẫn quan trọng. Nhưng trong thời vibe coding, người giữ được hệ thống sạch và đúng mới là người tạo ra giá trị bền hơn cho team.
Top comments (0)