TỪ “VIBE CODING” ĐẾN “VIBE ENGINEERING”: CÁCH MẠNG NHẬN THỨC TRONG LẬP TRÌNH THỜI AI

Ngày 12/12/2025

Khi trí tuệ nhân tạo bắt đầu tham gia vào quá trình phát triển phần mềm, lập trình không còn đơn giản là hành động tạo ra mã. Nó trở thành một cuộc đối thoại, một tiến trình đòi hỏi kỹ sư phải liên tục đánh giá, phản biện và kiểm chứng. Tuy nhiên, sự tiện lợi mà AI mang lại cũng đi kèm một cạm bẫy: cảm giác “mọi thứ đều đang hoạt động tốt”. Đó là bản chất của Vibe Coding – lập trình dựa vào cảm giác và sự tin tưởng mù quáng vào kết quả sinh ra từ mô hình.

Nhưng ngành phần mềm đang đi theo một hướng khác. Một hướng thận trọng hơn, kỷ luật hơn, và trưởng thành hơn. Đó là Vibe Engineering.

1. Khi tốc độ trở thành ảo giác

AI khiến việc sinh mã trở nên nhanh đến mức gần như không mất chi phí. Tuy nhiên, sự nhanh chóng này dễ khiến con người nhầm lẫn giữa “hoàn thành” và “hoàn hảo”. Một đoạn code xuất hiện ngay lập tức không có nghĩa nó phù hợp với hệ thống, dễ bảo trì, hay tối ưu. Điều nguy hiểm nhất không phải là lỗi, mà là code trông hợp lý nhưng sai về bản chất.

Những phần mã chạy được nhưng gây rối về lâu dài thường hình thành từ sự thiếu vắng của ba yếu tố:

hiểu đúng vấn đề,
đánh giá kiến trúc,
và gu thẩm mỹ kỹ thuật.

Slop không phải sản phẩm của AI. “Slop là sản phẩm của sự buông lỏng tiêu chuẩn của con người.”

Trong môi trường mà một câu lệnh có thể sinh ra cả một module, trách nhiệm quản lý chất lượng thuộc về kỹ sư không phải máy.

2. AI không thông minh hơn khi chúng ta cung cấp nhiều thông tin: Vai trò của RPI và Quản lý ngữ cảnh

Chúng ta thường tin rằng cung cấp càng nhiều ngữ cảnh cho AI thì mô hình càng thông minh – điều này không đúng về mặt hành vi. Khi ngữ cảnh quá tải hoặc không được tổ chức hợp lý, mô hình dễ rơi vào vùng suy luận mơ hồ, tạo ra kết quả trông hợp lý nhưng lệch hoàn toàn với ý định của hệ thống.

Đó là lý do quy trình RPI (Research – Plan – Implement) ra đời.

Research: giảm nhiễu, chắt lọc bản chất

Trước khi yêu cầu AI giải quyết vấn đề, kỹ sư có nhiệm vụ tạo ra môi trường nhận thức đúng: xác định vị trí file liên quan, tóm tắt kiến trúc, giảm thông tin thừa.

Plan: thống nhất tư duy giữa người và máy

Thay vì nhảy ngay vào code, kỹ sư phải dẫn dắt AI bằng kế hoạch: pseudo-code, cấu trúc, interface, ràng buộc. Đây là thời điểm để con người xác nhận rằng cách tiếp cận là đúng, trước khi AI triển khai.

Implement: chỉ thực thi khi đã kiểm soát được rủi ro

Khi mọi thứ đã rõ ràng, AI mới được phép sinh mã.

Điều quan trọng nhất: RPI không làm chậm tiến độ, nó giảm khối lượng sửa sai về sau.

3. Vì sao không nên xây Agent đa năng và vì sao nên chuyển sang “Skill”

Trong nhiều tổ chức, chúng ta cố tạo ra một AI Agent đa năng, có thể đảm nhận mọi tác vụ. Tuy nhiên, mô hình này thường thất bại khi bước vào thực tế. Lý do đơn giản: AI không hiểu bối cảnh vận hành của tổ chức. Nó không biết quy trình nội bộ, tiêu chuẩn chất lượng, quy ước đặt tên, kiến trúc hiện tại hay văn hóa kỹ thuật.

Để AI hoạt động đáng tin cậy, ta không nên để nó “phỏng đoán”, mà phải ràng buộc nó bằng quy trình rõ ràng. Đó là tư duy “Skills”:

mỗi Skill tương ứng với một quy trình,
được đóng gói thành tài liệu, checklist, bước hành động,
để AI thực thi như một nhân viên được đào tạo,
không còn tự suy ra quy trình mới mỗi lần.

Skills tạo ra sự nhất quán, giảm sai sót và biến kiến thức nội bộ thành thứ được máy tái sử dụng được. Skill là tài sản: có thể lưu vào Git, chia sẻ, versioning, review. Khi một Skill mới được viết ra, ví dụ một quy trình xử lý lỗi toàn bộ đội kỹ thuật đều có thể dùng ngay. Tri thức không còn nằm trong đầu một cá nhân, mà trở thành năng lực chung của cả tổ chức.

4. Codebase Agent-Ready: Không phải mô tả mà là kiểm chứng

AI không có trực giác. Nó không nhận ra rủi ro, không cảm thấy lo lắng khi sửa file quan trọng, và không biết rằng một commit có thể gây ra outage. Vì thế, hệ thống phải được thiết kế theo mô hình Verification-Driven:

mọi dòng code AI sinh ra đều phải đi qua một chuỗi kiểm chứng tự động,
linter phải nghiêm ngặt,
typing phải cứng,
test phải tồn tại,
CI/CD phải bắt buộc,
và review phải là hàng rào cuối cùng.

Khi sử dụng AI trong sản xuất, “hy vọng AI làm đúng” là không đủ. Điều cần thiết là buộc AI phải không thể làm sai.

5. Vai trò kỹ sư được nâng từ “người viết code” lên “người kiểm soát hệ thống”

Một sai lầm phổ biến khi tích hợp AI vào quy trình là vẫn giữ tư duy: “viết code = tạo giá trị”. Trong Vibe Engineering, giá trị không nằm ở số dòng code. Giá trị nằm ở Artifacts: