Vibe Coding tại CLS: Từ "Cơn sốt tốc độ" đến "Vũ khí thực thụ"

Ở bài viết trước, chúng tôi đã chỉ ra mặt trái của "cơn sốt" Vibe Coding — khi tốc độ sinh code khiến cả đội ngũ ngộ nhận rằng mình đã “xong việc chỉ trong một buổi chiều”.

Tuy nhiên, từ chối AI vì sợ hỏng kiến trúc là một bước lùi. Sau vài lần vấp ngã, CLS buộc phải điều chỉnh lại cách hợp tác với công cụ này. Không phải để chậm lại, mà là thiết lập quyền kiểm soát để không phải trả giá bằng nợ kỹ thuật, qua đó thực sự mài giũa AI thành một "vũ khí bứt tốc" sắc bén và an toàn.

Chúng tôi đã thiết lập 3 nguyên tắc nền tảng.

1. Chia nhỏ theo ranh giới kỹ thuật, không theo cảm hứng sản phẩm

AI xử lý rất tốt những bài toán có ranh giới rõ ràng, nhưng không giỏi giữ nhiều tầng context dài hạn trong một hệ thống phức tạp.

Trước đây, khi hưng phấn với AI, chúng tôi thường mô tả cả một flow lớn trong một prompt dài: từ UI đến xử lý dữ liệu, từ validation đến logic nghiệp vụ. Demo chạy rất mượt. Dù vậy, khi review thì vấn đề bắt đầu xuất hiện:

Mã nguồn chắp vá, các thành phần kết nối lộn xộn và thiếu chuẩn mực chung
Các tính năng đứng riêng thì trơn tru, nhưng ghép vào luồng chung lại "đá chân nhau" sinh lỗi
Quy tắc nghiệp vụ (Business rule) bị giản lược quá mức
Nhiều hàm xử lý quan trọng bị gắn mã cứng (hardcode) kiểu tự động trả về "thành công", hoặc bỏ ngỏ giữa chừng với dòng chú thích "TODO" để lách qua bước chạy thử.

Bài học rút ra rất rõ:

AI nên được giao từng “đơn vị kỹ thuật hoàn chỉnh”, không phải cả một tính năng mơ hồ.

Thay vì đưa một prompt chung chung như: “Viết module gợi ý khóa học dựa trên hành vi người dùng”, đội ngũ có thể tiếp cận bằng cách chia nhỏ tính năng lớn thành những "đơn đặt hàng" cho AI:

Lên bản nháp cấu trúc dữ liệu (Database schema)
Xây dựng phần lõi tính toán (Scoring logic)
Xây dựng các API kết nối (API endpoints)
Tích hợp dữ liệu lên giao diện (UI integration)
Viết kịch bản kiểm thử tự động (Unit tests)
...

Với cách chia nhỏ này, tốc độ làm việc không hề giảm đi đáng kể. Bù lại, kỹ sư kiểm soát được từng phần mã nguồn và hiểu rất rõ luồng chạy của hệ thống, thay vì phó mặc cho việc chắp vá mã nguồn tự động.

Tuy nhiên, chia nhỏ đến mức nào lại là một nghệ thuật cân bằng. Nếu chia quá vụn vặt, bạn sẽ rơi vào cái bẫy "quản lý vi mô" với AI: tốn hàng tá thời gian để rặn từng câu lệnh, xắt nhỏ từng đoạn code lẻ tẻ rồi mòn mỏi ngồi chờ AI chạy, review, ghép lại. Nhưng nếu "nhồi" mảng quá to thì lại giẫm ngay vào vết xe đổ mất kiểm soát ban đầu. Tỉ lệ vàng – nơi task đủ nhỏ để làm chủ nhưng vẫn đủ lớn để AI kịp phát huy tốc độ của nó – rõ ràng không có công thức cố định, mà đúc kết hoàn toàn từ kinh nghiệm thực chiến và năng lực kiểm soát của người kỹ sư.

2. Context là tài sản, không phải phần phụ của prompt

Ban đầu, chúng tôi nghĩ prompt càng chi tiết là đủ.

Nhưng thực tế, vấn đề không nằm ở độ dài prompt, mà ở chỗ Context không được chuẩn hóa. AI không “hiểu hệ thống” như con người. Nó chỉ hiểu phần ngữ cảnh được bạn cung cấp tại đúng thời điểm đó. Khi context rơi rớt giữa các phiên làm việc, code AI sinh ra bắt đầu lệch pha với kiến trúc chung.

Từ đó, CLS thay đổi cách làm bằng những hành động thực chiến:

Chuẩn hóa tài liệu kiến trúc: Về bản chất, chúng ta chỉ cần đúc kết luồng hệ thống và chuẩn code thành các file văn bản lưu kèm dự án. Bạn có thể viết các file doc như architecture.md, rules.md,... thông thường hoặc tận dụng cấu hình tự động của công cụ IDE (ví dụ như .cursorrules). Mục đích cuối cùng là tạo ra một mốc tham chiếu cố định để AI luôn đọc và hiểu đúng "luật chơi" trước khi viết code.
Biến các quy tắc nghiệp vụ thành một bộ tài liệu chuẩn duy nhất, thay vì chỉ mô tả rời rạc qua mỗi câu lệnh prompt. Những tài liệu này sẽ được đính kèm (bằng cách dùng @mention vào file file) trực tiếp để AI "đọc hiểu" ngữ cảnh của riêng module đó.
Hạn chế prompt ngẫu hứng: Tránh thói quen "tiện đâu hỏi đó" mà thiếu bối cảnh, bởi nó dễ sinh ra những mã nguồn chệch hướng khỏi tổng thể hệ thống.
Tái sử dụng context có kiểm soát: Khi bắt đầu một phiên làm việc mới (new chat) với AI, luôn phải chủ động nạp lại các tài liệu nền tảng trên thay vì để AI phán đoán lại từ đầu.

Nhờ những công cụ này, chúng tôi không còn “nói chuyện với AI” một cách tùy hứng, mà tương tác với AI như một thành viên mới luôn được "hướng dẫn hội nhập" tự động dựa trên bộ tài liệu chuẩn.

3. Phân vai rõ: AI không thay thế trách nhiệm

Trong quy trình mới, ranh giới được hoạch định rõ ràng:

AI: Triển khai nhanh phần implement (viết code).
Engineering (Kỹ sư): Đóng vai trò người định hướng kiến trúc. Thay vì trực tiếp gõ lệnh, kỹ sư tập trung quy hoạch bộ khung, đặt ra các tiêu chuẩn để AI tuân thủ, đồng thời lùi lại một bước để review và phòng tránh các rủi ro ngầm về bảo mật, hiệu năng hay sự lộn xộn của code sinh tự động.
PO/PM: Đóng vai trò người định hình logic nghiệp vụ. Các yêu cầu không còn viết theo cảm tính chung chung, mà cần được chuẩn hóa thành những quy tắc rõ ràng (Business Rules), giúp đảm bảo AI theo sát quy trình thực tế thay vì tự ý "đoán bừa" hay lấp liếm các bước quan trọng.
QA: Vượt khỏi việc kiểm thử thủ công các luồng cơ bản. Trước tốc độ sinh mã ồ ạt, QA buộc phải thay đổi tư duy sang kiểm định ở quy mô lớn: ứng dụng chính AI để thiết kế các kịch bản kiểm thử (test cases) có độ phức tạp cao, nhằm bóc trần những lỗ hổng logic tinh vi mà máy móc khéo léo ngụy tạo dưới lớp vỏ bọc trơn tru.

Không ai được phép “đẩy” trách nhiệm sang AI. Bởi vì một sự thật rất rõ ràng:

AI có thể viết code. Nhưng AI không chịu trách nhiệm khi hệ thống sập.

Phần chìm của tảng băng: AI đi dời "nút thắt cổ chai"

Những nguyên tắc trên giúp giảm rủi ro, nhưng đó chưa phải là phát hiện lớn nhất của chúng tôi.

Điều đáng nói hơn cả là: Vibe Coding đã làm lộ ra năng lực thực sự của từng người trong đội ngũ.

Tốc độ viết code không còn là thước đo

Trước đây, một kỹ sư giỏi thường được đánh giá qua tốc độ implement. Giờ đây, AI có thể viết nhanh hơn bất kỳ ai. Vậy điều gì phân biệt một kỹ sư thực thụ?

Không còn là tốc độ gõ phím. Mà là khả năng phán đoán.

Đoạn code AI sinh ra này có phá vỡ kiến trúc không?
Nó có gây memory leak khi scale lên hàng triệu record không?
Các lỗ hổng bảo mật (Injection, XSS) có bị bỏ ngỏ không?
Liệu nó có đang tạo ra sự phụ thuộc chéo chằng chịt (coupling) giữa các module hay không?

Viết code cần kỹ năng. Nhưng Review code cần sự am hiểu toàn diện về hệ thống. Khi AI làm tăng sản lượng mã nguồn, năng lực review trở thành yếu tố sống còn.

Review khó hơn viết

Một lập trình viên chưa từng tự tay xử lý bug production lúc 3 giờ sáng sẽ rất khó nhìn ra rủi ro tiềm ẩn trong một đoạn code “đúng chuẩn về mặt cú pháp”.

Bạn không thể review thứ mà bạn chưa từng trải nghiệm. Bạn không thể đánh giá kiến trúc nếu bạn chưa từng tự tay xây và đập một hệ thống thật.

Vibe Coding vì thế không làm công việc của dev dễ hơn. Nó chỉ làm lộ rõ những khoảng trống về nền tảng kỹ thuật.

AI không đào thải nghề Dev. Nó đào thải những Dev không hiểu bản chất.

Nếu chỉ biết prompt và tin rằng “AI lo phần còn lại”, bạn sẽ sớm rơi vào tình thế: Hệ thống có hàng chục nghìn dòng code được generate tự động, nhưng không một ai thực sự hiểu nó hoạt động ra sao. Khi đó, AI không còn là vũ khí, nó biến thành rủi ro lớn nhất.

Ngược lại, với những người hiểu kiến trúc, rành hệ thống, vững logic nghiệp vụ — AI trở thành đòn bẩy khổng lồ. Nó giải phóng họ khỏi phần việc gõ code lặp đi lặp lại, nhưng tuyệt nhiên không bao giờ thay thế được tư duy hệ thống.

Lời kết

Vibe Coding thực chất là một phép thử cho mọi tổ chức công nghệ. Phép thử để phân định xem:

Đội ngũ có thực sự làm chủ sản phẩm không?
Có ai đứng ra chịu trách nhiệm bảo vệ kiến trúc dài hạn không?
Có ai đủ dũng khí và nền tảng để nói “đoạn code này không ổn” dù bản demo đang chạy rất đẹp mắt không?

Việc tạo ra code siêu tốc từ AI chưa bao giờ là thử thách. Vấn đề là năng lực của con người có theo kịp tốc độ sinh code đó hay không. Nếu không, ảo tưởng “xong trong một buổi chiều” sẽ bắt bạn phải trả giá bằng vô số đêm cày ải sửa sai.

Bởi vì cuối cùng, thứ tạo nên lợi thế cạnh tranh cốt lõi không phải là tốc độ khoe demo. Mà là khả năng hệ thống vận hành ổn định khi tất cả mọi người đã ngừng vỗ tay.