Vite+ và bài học thực tế khi xây dựng ứng dụng cùng AI agent

Khi đưa AI agent vào một dự án frontend, rắc rối thường không nằm ở việc viết code nhanh hay chậm, mà ở chỗ agent không biết đâu là lệnh "đúng" để kiểm tra công việc của mình. Một bài viết trên blog cá nhân của Jan Michalek — đang được bàn luận sôi nổi trên Hacker News — kể lại trải nghiệm ba tuần dùng Vite+ trên bốn dự án, và đúc kết thành một nguyên tắc đơn giản: đưa công cụ này vào ngay prompt đầu tiên giao cho AI.

Vấn đề không phải là linter chậm

Tác giả mô tả một dự án từng có 47 dependency phát triển, bảy file cấu hình và một file Markdown giải thích cho agent cách chạy mọi thứ. Đến 2 giờ sáng, anh vẫn đang gỡ lỗi vì kết quả kiểm tra trên máy local khác với CI. Code đã xong, nhưng hệ sinh thái công cụ quanh nó thì chưa.

Các lệnh bị phân tán khắp ESLint, Prettier, TypeScript, trình chạy test và các script trong package.json. Khi thả agent vào dự án, việc đầu tiên nó phải làm là đoán xem lệnh nào mới là lệnh đúng — và thế là lại sinh thêm một file hướng dẫn nữa để bảo trì.

Quy trình tạo dự án với Vite+

Vite+ gom các tác vụ thường ngày về chung một lệnh vp: Vite cho phát triển và build, Vitest cho test, Oxlint và Oxfmt cho kiểm tra định dạng, tsdown cho thư viện, Vite Task cho tác vụ. Cấu hình có thể đặt trong vite.config.ts, nhưng vẫn giữ package.json, tsconfig và cấu hình framework tùy dự án — tác giả thẳng thắn cho rằng "một file cho tất cả mọi thứ" nghe thì hay nhưng không thực tế.

Đừng để agent tự đoán thế nào là "xong"

Với một ứng dụng React, chuỗi lệnh cơ bản sau khi tạo dự án là:

vp create vite -- --template react-ts
cd project-name
vp install
vp dev
vp check
vp test
vp build

Điểm quan trọng là tác giả không để agent tự diễn giải tiêu chí hoàn thành. Anh viết một prompt cụ thể, yêu cầu agent đọc hướng dẫn vp create, không ghi đè file sẵn có, chọn một phiên bản ổn định và một package manager duy nhất, giữ một lockfile, và không tự thêm linter hay formatter khác nếu không có lý do chính đáng. Cuối cùng, agent phải chạy vp install, vp check, vp test và vp build, rồi báo cáo lại phiên bản, các lệnh đã chạy và kết quả thực tế.

Khi tôi để agent tự do, tôi nhận lại cả Prettier lẫn Oxfmt, ba lockfile và một CI chập chờn. Cấm formatter thứ hai và bắt buộc một lockfile không phải sở thích thẩm mỹ — đó là hai sai lầm tôi không muốn dọn lại lần nữa.

Một chi tiết đáng chú ý: tác giả không bắt buộc cài vp toàn cục bằng curl cho mọi dự án. Với thiết lập dùng một lần, npx [email protected] vp create là đủ; với dự án đã ổn định, agent có thể chạy CLI cục bộ qua package manager đã chọn.

Một lệnh, phản hồi nhanh

Sau khi sửa code, tác giả chỉ chạy vp check — lệnh này kiểm tra định dạng, lint và cả TypeScript khi bật typeAware và typeCheck trong cấu hình. Dự án mới tạo bằng vp create bật sẵn hai tùy chọn này; với dự án cũ, cần kiểm tra lại thay vì mặc định rằng kết quả xanh nghĩa là kiểu dữ liệu đã chuẩn.

Kiểm tra file đã stage bằng vp staged

Tác giả cũng đưa quy tắc kiểm tra vào chính tài liệu hướng dẫn agent trong repo: sau khi sửa code chạy vp check, sau khi đổi hành vi chạy vp test, trước khi bàn giao chạy vp build, đọc lại diff sau khi tự động sửa, và báo cáo kết quả thật thay vì tuyên bố hoàn thành khi lệnh còn lỗi. Lý do rất thực tế: một tuần sau quay lại dự án, agent mới sẽ không nhớ cuộc trò chuyện hôm qua — nhưng repo thì vẫn nhớ các lệnh của nó.

Về hiệu năng, anh ghi nhận trong một monorepo, thời gian CI giảm từ 4 phút xuống 50 giây, còn bước kiểm tra trước commit giảm từ 11 giây xuống dưới 2 giây. Tác giả nhấn mạnh đây là kết quả từ dự án của chính mình, không phải benchmark so sánh công bằng giữa các toolchain, và một phần lợi ích đến từ việc thay đổi phạm vi kiểm tra.

Những chỗ còn "gợn"

Bài viết không tô hồng công cụ. Tác giả chỉ ra ba điểm cần lưu ý:

• Migrate không miễn phí: vp migrate chạy trên một monorepo cũ mất khoảng 4 phút và chuyển đổi được cấu hình ESLint, Prettier, tsup mà không hỏng gì — nhưng đó là trường hợp cụ thể. Vẫn phải so sánh kết quả với lint, test, hook và build cũ, và các plugin hay rule tùy chỉnh có thể cần xử lý thủ công.
• Dễ nhầm lệnh tích hợp với script dự án: vp build là build ứng dụng Vite, còn vp run build chạy script build trong package.json. Trong dự án Next.js, agent tuyệt đối không được mặc định rằng vp build thay thế next build.
• Quản lý phiên bản: vp env có thể quản lý Node.js và package manager (có thể tắt bằng vp env off), nhưng vp upgrade chỉ cập nhật CLI toàn cục, không tự nâng gói vite-plus cục bộ trong từng dự án — điều này cần ghi rõ trong hướng dẫn cho agent.

Ai nên đưa Vite+ vào prompt đầu tiên?

Theo tác giả, công cụ này phù hợp nhất với người khởi tạo ứng dụng Vite mới và để AI lo phần thiết lập: chi phí chuẩn hóa thấp, chỉ cần chọn một toolchain, đặt lệnh kiểm tra vào repo và CI, agent có một lộ trình rõ ràng từ sửa code đến xác minh.

Ngược lại, anh không khuyến khích migrate mù quáng một ứng dụng lớn đang chạy tốt. Với framework có build riêng, cần xác định trước phần nào của Vite+ thực sự muốn dùng. Và nếu đã có một stack nhanh, ổn định, được ghi chép đầy đủ, thì lời hứa "một lệnh duy nhất" chưa đủ sức thuyết phục để thay thế.

Với lập trình viên Việt Nam đang dùng AI để dựng dự án frontend, bài học dễ áp dụng nhất có lẽ không nằm ở công cụ cụ thể nào, mà ở cách đặt tiêu chí: hãy yêu cầu agent đưa ra kết quả của vp check, test và build như một phần của định nghĩa "hoàn thành". Ảnh chụp màn hình ứng dụng đẹp thì tốt, nhưng các bước kiểm tra vượt qua mới nói lên nhiều điều hơn.