- Vibe Coding
- AI
- Nợ kỹ thuật
- Tái cấu trúc
- B2B
Đầu năm 2025, Andrej Karpathy phổ biến cụm từ “vibe coding”: xây phần mềm bằng cách trò chuyện với AI, chấp nhận đoạn mã sinh ra gần như không đọc lại, thấy chạy được là đi tiếp. Chỉ sau hơn một năm, cách làm này đã lan từ giới nghiệp dư sang cả doanh nghiệp. Là kỹ sư đã theo nghề trên dưới hai mươi năm, tôi không đứng ở phe bảo thủ chê AI. Ngược lại, đội chúng tôi dùng Claude và GPT hàng ngày. Nhưng chính vì dùng hàng ngày, tôi thấy rõ ranh giới giữa chỗ AI tỏa sáng và chỗ nó âm thầm gài mìn. Bài viết này vẽ lại ranh giới đó một cách sòng phẳng.
Trước hết, hãy công bằng: AI làm bản mẫu thử nghiệm rất tốt
Đứng ở góc độ người dùng cuối, vibe coding là một cuộc cách mạng nhỏ. Một nhà sáng lập không biết lập trình có thể dựng bản demo gọi vốn trong một buổi chiều. Một phòng ban có thể tự làm công cụ nội bộ mà trước đây phải xếp hàng chờ bộ phận IT cả quý. Một ý tưởng sản phẩm được kiểm chứng với người dùng thật trong vài ngày thay vì vài tháng.
Với các mục tiêu đó, chất lượng mã nguồn bên dưới gần như không quan trọng. Bản mẫu thử nghiệm (prototype) tồn tại để trả lời một câu hỏi duy nhất: ý tưởng này có đáng theo đuổi không. Trả lời xong, nó đã hoàn thành nhiệm vụ. Vấn đề chỉ bắt đầu khi bản mẫu đó không được vứt đi mà được nối thẳng vào khách hàng thật, dữ liệu thật và doanh thu thật. Lúc này, năm vấn đề dưới đây lần lượt lộ diện.
1. Nợ kỹ thuật chồng chất (Technical Debt Explosion)
Vì sao AI tạo ra nợ kỹ thuật nhanh đến vậy? Bản chất mô hình ngôn ngữ lớn (LLM) tối ưu cho mục tiêu “chạy được ngay trong ngữ cảnh hiện tại”, không phải “dễ sửa sau sáu tháng”. Mỗi lượt ra lệnh là một lần sinh mã gần như độc lập: mô hình không nhớ quy ước của những lần trước, nên cùng một logic được viết lại theo ba bốn kiểu khác nhau rải khắp mã nguồn thay vì được gom thành hàm dùng chung. Người làm theo kiểu vibe coding lại không đọc mã, nên không ai phát hiện sự trùng lặp đó.
Hệ lụy mang tính lãi kép. Sửa một lỗi ở một chỗ, bốn bản sao của logic đó ở chỗ khác vẫn mang lỗi cũ. Không có kiểm thử tự động nên không ai dám xóa phần mã chết. Chi phí cho mỗi thay đổi tăng phi tuyến theo thời gian, đến một điểm mà thêm một tính năng nhỏ tốn nhiều công hơn viết lại cả phân hệ. Trong tài chính, trạng thái này gọi là vỡ nợ.
2. Kiến trúc vô tổ chức (Spaghetti Architecture)
AI sinh mã theo đơn vị “câu trả lời”, không theo đơn vị “hệ thống”. Nó sẽ không tự quyết định ranh giới giữa các phân hệ, không tự tách tầng giao diện khỏi tầng nghiệp vụ, trừ khi người ra lệnh yêu cầu đích danh, mà người vibe coding thì không biết để yêu cầu. Kết quả điển hình: một file utils_final_v3.js dài ba nghìn dòng, mọi thứ gọi chéo mọi thứ, và một chuỗi phụ thuộc vòng tròn (circular dependency) mà chính công cụ phân tích tĩnh cũng phải bó tay.
Hệ lụy nghiêm trọng nhất không nằm ở thẩm mỹ. Khi không có phân lớp, bạn không thể thay một phần mà không đụng toàn bộ: đổi cơ sở dữ liệu là sửa ba mươi file, thêm một kênh thông báo là dò lại toàn bộ luồng xử lý. Kỹ sư mới không thể bắt nhịp công việc vì không có bản đồ nào để đọc. Mã nguồn trở thành hộp đen ngay với chính người tạo ra nó.
3. Sự rập khuôn, mất bản sắc (Cookie-Cutter Applications)
Mô hình AI học từ hàng triệu kho mã công khai và các khuôn mẫu phổ biến nhất, nên đầu ra hội tụ về mẫu số chung: cùng một bố cục trang chủ, cùng một luồng thêm sửa xóa dữ liệu, cùng những thành phần giao diện mặc định của thư viện. Ba doanh nghiệp khác ngành cùng vibe coding sẽ nhận về ba sản phẩm giống nhau đến khó tin, khác mỗi logo.
Với bản demo thì điều này vô hại. Với sản phẩm thương mại, đây là vấn đề chiến lược: phần mềm đáng lẽ phải mã hóa được nghiệp vụ riêng và lợi thế cạnh tranh của doanh nghiệp, cụ thể là những tình huống đặc thù của ngành, những quy tắc vận hành mà đối thủ không có. Nền tảng khuôn mẫu không gánh nổi các tùy biến sâu đó. Khi bạn cần bẻ luồng chuẩn theo nghiệp vụ thật, bạn sẽ thấy mình đang đấu tranh với chính cái khung mà AI đã chọn hộ.
4. Mất khả năng mở rộng (Zero Scalability)
AI luôn chọn lời giải đơn giản nhất chạy được trên máy của lập trình viên: SQLite thay vì cơ sở dữ liệu chịu tải thật, xử lý tuần tự thay vì hàng đợi, đọc ghi trực tiếp thay vì bộ nhớ đệm, và những vòng lặp truy vấn N+1 kinh điển. Không phải mô hình kém, mà vì câu lệnh không nói “hệ thống này sẽ phục vụ mười nghìn người dùng đồng thời”. Người không chuyên không biết phải nói điều đó.
Hệ lụy đến đúng vào lúc tệ nhất: khi sản phẩm bắt đầu có khách. Lượng truy cập tăng gấp đôi, thời gian phản hồi tăng gấp tám. Không thể tách phần nghẽn ra thành dịch vụ riêng vì mọi thứ dính chặt vào nhau. Lối thoát duy nhất là thuê máy chủ lớn hơn, và hóa đơn hạ tầng tăng theo trong khi kiến trúc vẫn nguyên trạng. Chúng tôi từng tiếp nhận một hệ thống bán vé sự kiện dựng bằng AI trong hai tuần: chạy hoàn hảo với 50 người dùng thử nghiệm, sập ngay đêm mở bán đầu tiên ở mức 800 người truy cập đồng thời.
5. Hổng bảo mật nghiêm trọng (Security Vulnerabilities)
Đây là vấn đề tôi coi là nặng nhất, vì nó không hiện ra trên giao diện. Dữ liệu huấn luyện của mô hình có độ trễ, nên AI thường gợi ý thư viện phiên bản cũ kèm lỗ hổng đã công bố (CVE), những cách viết đã bị khuyến cáo ngừng dùng. Nó vẫn có thể sinh ra câu lệnh SQL nối chuỗi, ghi cứng khóa API thẳng vào mã nguồn, quên kiểm tra dữ liệu đầu vào, mở CORS cho mọi nguồn truy cập. Nghiên cứu của nhóm Stanford (“Do Users Write More Insecure Code with AI Assistants?”) còn chỉ ra một điểm đáng lo hơn: người dùng trợ lý AI không những viết mã kém an toàn hơn, mà còn tự tin hơn rằng mã của mình an toàn.
Với vibe coding, không có khâu soát xét mã nào cả, nên mọi lỗ hổng đi thẳng vào hệ thống đang chạy cùng dữ liệu khách hàng. Hệ lụy vượt khỏi phạm vi kỹ thuật: rò rỉ dữ liệu cá nhân kéo theo trách nhiệm pháp lý theo Nghị định 13/2023 về bảo vệ dữ liệu cá nhân tại Việt Nam, hoặc GDPR nếu bạn có khách hàng châu Âu, chưa kể thiệt hại niềm tin không đo được bằng tiền.
Giải pháp: “Vệ sinh phần mềm”, biến bản mẫu thành hệ thống vận hành thật
Tin tốt: trong đa số trường hợp, câu trả lời không phải là vứt đi viết lại từ đầu. Một ứng dụng do AI dựng thường đã chứng minh được giá trị nghiệp vụ, thứ quý nhất của nó. Cái thiếu là phần kỹ thuật nền bên dưới. Tại OKAXI, chúng tôi gọi quy trình bổ khuyết này là Vệ sinh phần mềm (Software Sanitation), triển khai bởi đội ngũ gia công phần mềm theo ba bước có thể đo lường được.
Bước 1: Rà soát và tái cấu trúc mã nguồn (Code Audit & Refactoring)
Nguyên tắc đầu tiên: đo trước, sửa sau. Chúng tôi chạy phân tích tĩnh, dựng sơ đồ phụ thuộc giữa các phân hệ, đo độ phủ kiểm thử và khoanh vùng nợ kỹ thuật theo mức độ rủi ro. Trước khi đụng vào bất kỳ dòng mã nào, đội viết bộ kiểm thử ghi lại hành vi hiện tại của hệ thống (characterization test), đảm bảo việc tái cấu trúc chỉ thay đổi cấu trúc chứ không làm đổi nghiệp vụ. Sau đó mới dọn dần: gộp logic trùng lặp, tách phân hệ theo nguyên tắc mỗi phần một trách nhiệm, đưa toàn bộ vào quy trình tích hợp và triển khai tự động (CI/CD) để chất lượng không tụt trở lại.
Bước 2: Tái thiết kế kiến trúc và mở rộng hệ thống (Architecture Re-design & Scaling)
Song song với việc dọn mã, chúng tôi quy hoạch lại kiến trúc theo ranh giới nghiệp vụ: tách tầng rõ ràng, đưa tác vụ nặng vào hàng đợi xử lý, bổ sung bộ nhớ đệm và quản lý kết nối cơ sở dữ liệu, chuẩn bị đường tách microservices cho những phần thực sự cần co giãn độc lập thay vì tách theo trào lưu. Hạ tầng được chuyển về dạng cấu hình bằng mã (Infrastructure as Code) kèm hệ thống giám sát, để lần tăng tải sau chỉ là thêm máy chủ, không phải viết lại. Với các hệ thống phức tạp, bước này có thể bắt đầu bằng một buổi tư vấn thiết kế hệ thống độc lập trước khi cam kết lộ trình.
Bước 3: Gia cố bảo mật và tối ưu hiệu năng (Security Hardening & Optimization)
Bước cuối xử lý phần chìm của tảng băng: quét toàn bộ thư viện phụ thuộc và nâng cấp phiên bản, chuyển khóa bí mật vào kho lưu trữ an toàn và thay mới những khóa đã lộ, thay SQL nối chuỗi bằng truy vấn tham số hóa, bổ sung kiểm tra dữ liệu đầu vào, giới hạn tần suất truy cập và siết lại phân quyền. Kết thúc bằng một vòng kiểm thử xâm nhập. Phần tối ưu hiệu năng đi kèm ngay trong bước này vì hai việc chồng lấn nhau: xử lý truy vấn N+1, thêm chỉ mục và bộ nhớ đệm thường kéo thời gian phản hồi ở ngưỡng p95 xuống còn một phần mấy con số ban đầu, đồng nghĩa chi phí hạ tầng giảm theo.
Kết luận: AI là công cụ tăng tốc, không phải người thay thế kỹ thuật
Quan điểm của tôi sau tất cả vẫn nhất quán: vibe coding không phải kẻ xấu. Nó là cách rẻ nhất lịch sử để kiểm chứng một ý tưởng, và doanh nghiệp nên tận dụng điều đó. Sai lầm duy nhất là nhầm bản nháp với sản phẩm. AI viết mã rất nhanh, nhưng trách nhiệm kỹ thuật, từ kiến trúc, khả năng chịu tải đến an toàn dữ liệu, vẫn cần bàn tay kỹ sư có kinh nghiệm đứng sau.
Nếu doanh nghiệp của bạn đang vận hành một ứng dụng dựng bằng AI và bắt đầu cảm nhận những triệu chứng kể trên, đừng đợi đến sự cố đầu tiên. Hãy để dịch vụ gia công phần mềm của OKAXI rà soát hệ thống của bạn: chúng tôi trả về một báo cáo hiện trạng rõ ràng kèm lộ trình vệ sinh phần mềm theo từng giai đoạn, để bản mẫu từng giúp bạn thắng ở vòng ý tưởng tiếp tục thắng ở vòng vận hành.