---
title: "Vite+ changed how I build applications with AI agents"
slug: vite-changed-how-i-build-applications-with-ai-agents
url: https://listedarticles.com/articles/vite-changed-how-i-build-applications-with-ai-agents
canonical_url: https://janmichalek.com/blog/vite-plus-agentni-vyvoj?lang=en
content_type: blog_post
language: en
published_at: 2026-10-20T08:09:59.091Z
updated_at: 2026-10-20T08:09:59.091Z
author: "Jan Michálek"
authored_by: human
publisher: "Jan Michálek"
publisher_url: https://janmichalek.com/
topics: ["JavaScript", "Developer Tools", "AI Agents", "Web Development"]
license: all-rights-reserved
word_count: 1598
reading_minutes: 7
citation: "Jan Michálek, Jan Michálek. \"Vite+ changed how I build applications with AI agents.\" 20 Oct 2026. https://janmichalek.com/blog/vite-plus-agentni-vyvoj?lang=en (all-rights-reserved)"
# The full text follows. The web page shows an extract and sends readers
# to the source above; quote the citation and link the canonical URL.
---

# Vite+ changed how I build applications with AI agents

> Jan Michálek reports on three weeks using Vite+ across four projects with AI coding agents: bringing dev server, builds, Vitest, Oxlint, Oxfmt and tsdown under one vp command gave the agent, the developer and CI a single workflow, plus what he measured, where vp migrate needs review and when not to switch.

# Vite+ changed how I build applications with AI agents

Jan Michálek

One project had 47 development dependencies, seven config files, and a Markdown file explaining to the agent how to run everything. At 2 a.m., I was debugging a difference between local checks and CI. The code was done; the tooling around it wasn't. After three weeks with Vite+ across four projects, I have a simple rule for new Vite apps: put it in the first prompt I give the AI.

## The short version

- For a new Vite app, I have the agent create the project with `vp create`, then verify its work with `vp check`, `vp test`, and `vp build`.
- Speed is nice, but the bigger win for me is one clear workflow for the agent, me, and CI.
- For an existing project, I treat `vp migrate` as the start of a migration. I still review the diff, tests, and build behavior.

## A slow linter wasn't the problem

My commands were spread across ESLint, Prettier, TypeScript, a test runner, and `package.json` scripts. When I let an agent into the project, its first job was figuring out which command was the right one. I wrote instructions to explain that. Now I had another file to maintain. Excellent time saver, right?

It wasn't just the number of files. Once, my local setup and CI checked a generated file differently. The agent saw one result; the pipeline saw another. Faster component generation doesn't fix that.

Vite+ brings everyday tasks under `vp`: Vite for development and builds, Vitest for tests, Oxlint and Oxfmt for checks, tsdown for libraries, and Vite Task for tasks. You can keep their configuration in `vite.config.ts`. You still have `package.json`, `tsconfig`, and, depending on the project, framework configuration. “One file for absolutely everything” would look good on a banner and bad in a real repo.

For a React app, these are the commands I need after creating the project:

Shell

`1vp create vite -- --template react-ts
2cd project-name
3vp install
4vp dev
5vp check
6vp test
7vp build`

The commands above assume `vp` is available globally. A global install is optional; you can also run Vite+ as a local dependency through a package manager. `vp install` uses the package manager selected for the project, so Vite+ doesn't replace npm or pnpm.

[![vp create terminal output while setting up a project](https://janmichalek.com/_next/image?url=%2F_next%2Fstatic%2Fimmutable%2Fmedia%2Fvp-create.18kdug08_k747.webp&w=3840&q=75)](https://janmichalek.com/_next/static/immutable/media/vp-create.18kdug08_k747.webp)

Creating a project with vp create.

## I don't let the agent guess what “done” means

The Vite+ docs include a prompt for AI assistants. It's a useful starting point, but I adapt it to the project. My goal is concrete: the agent should use Vite+ to set up the app and not quietly abandon it after generating the first page.

Text

`` Create a new React + TypeScript app on Vite using Vite+.
First read the current `vp create` guide and run `vp help create`.
Inspect the target directory and do not overwrite existing files.
Choose the current stable Vite+ release and one package manager.
Create the project with `vp create` using the React + TypeScript template.
Keep its single lockfile. Do not add another linter or formatter
unless there is a specific reason.
After setup, run `vp install`, `vp check`, and relevant tests
with `vp test`, and run a production `vp build`. Add a test for the
behavior you implemented. If a check fails, fix the cause and rerun it.
In your final report, list the Vite+ version, commands, and actual results. ``

I don't require a global install via `curl` in every project. For a one-off setup, something like `npx --package=vite-plus@1.3.0 vp create` is enough; in an established project, the agent can run the local CLI through the selected package manager. I don't ban `create-vite`, either: `vp create vite` uses that template. What matters is that the agent follows the intended setup and keeps one consistent toolchain.

When I gave an agent free rein, I ended up with both Prettier and Oxfmt, three lockfiles, and unreliable CI. Banning a second formatter and requiring one lockfile aren't aesthetic preferences. They're two mistakes I don't want to clean up again.

## One command gives me fast feedback

After changing code, I run `vp check`. It checks formatting and lint; it checks TypeScript when both `typeAware` and `typeCheck` are enabled in the configuration. A new project created with `vp create` enables them by default. In an existing project, I verify that setting instead of assuming a green result also means the types are sound.

Here's the difference from my old workflow:

Shell

`1# Before: it depended on each project's scripts.
2npm run format:check
3npm run lint
4npm run typecheck
5
6# Now, in a project with the corresponding Vite+ configuration.
7vp check`

`vp check --fix` can repair some findings automatically. After that, I read the diff and run the check again. A green lint result still doesn't tell me whether the app does the right thing. I need `vp test` for behavior and `vp build` to verify the application builds.

I also put that rule in the repo's agent instructions. When I return to a project a week later, a new agent won't remember yesterday's chat. The repo still knows its commands.

Markdown

`` 1## Checks before completing a task
2
3- After changing code, run `vp check` and fix any errors.
4- After changing behavior, run the relevant tests with `vp test`.
5- Before handing off a Vite app, run `vp build`.
6- Review the diff after automatic fixes.
7- Report the actual results; don't call a failed run complete. ``

Local instructions and Git hooks help, but they can be bypassed or disabled. I run the same checks in CI. On an experiment where I let an agent work unattended, human review before merging was still my responsibility.

## What I measured

In a monorepo, CI went from 4 minutes to 50 seconds after I changed the workflow. A pre-commit check dropped from 11 seconds to under 2. Those are results from my projects, not a benchmark comparing Vite+ with another toolchain under identical conditions. Part of the gain comes from what runs and which files it checks; you won't automatically get those CI times with a different configuration.

[![GitHub Actions benchmark output: classic toolchain, 10.441 seconds](https://janmichalek.com/_next/image?url=%2F_next%2Fstatic%2Fimmutable%2Fmedia%2Fclassic.1ga5hgr103r0d.webp&w=3840&q=75)](https://janmichalek.com/_next/static/immutable/media/classic.1ga5hgr103r0d.webp)

GitHub Actions: the classic toolchain benchmark took 10.441 s.

[![GitHub Actions benchmark output: Vite+, 1.356 seconds](https://janmichalek.com/_next/image?url=%2F_next%2Fstatic%2Fimmutable%2Fmedia%2Fviteplus.2-ywjv-drgop4.webp&w=3840&q=75)](https://janmichalek.com/_next/static/immutable/media/viteplus.2-ywjv-drgop4.webp)

GitHub Actions: the Vite+ benchmark took 1.356 s.

For quick checks of changed files, I use `vp staged` and Git hooks managed with `vp hooks`. When different projects behave differently, `vp toolchain` shows me their active versions. `vp toolchain --global` shows the global installation. That's more useful for debugging than my old method: “I definitely updated it.”

[![vp staged --verbose terminal output](https://janmichalek.com/_next/image?url=%2F_next%2Fstatic%2Fimmutable%2Fmedia%2Fvp-staged.2x_40n-pgog9_.webp&w=3840&q=75)](https://janmichalek.com/_next/static/immutable/media/vp-staged.2x_40n-pgog9_.webp)

Checking the staged file with vp staged.

[![vp toolchain terminal output showing Vite+ tool versions](https://janmichalek.com/_next/image?url=%2F_next%2Fstatic%2Fimmutable%2Fmedia%2Fvp-toolchain.1x699rowz2mdw.webp&w=3840&q=75)](https://janmichalek.com/_next/static/immutable/media/vp-toolchain.1x699rowz2mdw.webp)

vp toolchain shows the active tool versions in the project.

There are two things to distinguish in a monorepo. `vp run` executes a `package.json` script or a task defined in `vite.config.ts`, and it can order work according to workspace dependencies. **Caching is not enabled automatically for `package.json` scripts.** You can enable it with, for example, `vp run --cache build`. Tasks defined in `vite.config.ts` are cached by default. I won't turn my CI timing into a promise that `vp run` alone makes every build faster.

## Where it got awkward

`vp migrate` ran on an older monorepo for about 4 minutes. It converted my ESLint, Prettier, and original tsup build setup, and nothing broke in my case. That doesn't mean every migration takes four minutes. You have to compare the result with the old lint, tests, hooks, and build output. Plugins and custom rules may still need manual work.

Another trap is the difference between a built-in command and a project script. `vp build` runs a Vite app build. `vp run build` runs the `build` script from `package.json` or a task with that name. In a Next.js project, the agent must not assume `vp build` replaces `next build`. The same distinction applies to `vp dev` and `vp run dev`. Vite+ can work with other templates, but that doesn't change what those commands do.

The third issue is version management. The global `vp env` can manage Node.js and package managers. I have three projects on three Node versions, and it made switching easier for me; if you don't want that, you can turn it off with `vp env off`. `vp upgrade` updates the global CLI, **not the local `vite-plus` package in every project automatically**. I wrote that explicitly in my agent instructions because the command name invites the opposite assumption.

## Who gets Vite+ in my first prompt

Anyone starting a new Vite app with AI doing the setup. The cost of standardizing is small here: choose one toolchain, put the check commands in the repo and CI, and the agent has a clear path from a code change to verification. Across three weeks and four projects, the main benefit for me was that I stopped explaining the basic commands over and over.

I wouldn't blindly migrate a large existing app with a working build and test suite. For a framework with its own build, I'd first decide which parts of Vite+ I actually want to use. And if I already had a well documented, fast, stable stack, the promise of “one command” alone wouldn't convince me to replace it.

Next time you start a Vite project, put `vp create` in the first prompt and ask for the outputs of `vp check`, tests, and the build as part of the definition of done. A screenshot of the finished app is nice. Passing checks tell you more.