Revyse has two change engines. Pick one with "engine" in revyse.config.json:
agent: a coding agent that finds its way through your codebase, creates, edits and deletes files, front end and back end, and runs your checks to fix what it broke Opt in now with"engine": "agent"; it becomes the default once it passes Revyse's evaluation suite.classic(the default today): plans and patches a set of files chosen up front, for front-end changes to existing code.
Both run the same lifecycle: a plan you approve, the change written into your files, your checks, a diff you review, and keep, revise or revert. Both work locally and in the cloud loop.
What the agent engine does
Any change to your project's own code, the way a developer on the team would make it:
| Kind | Examples |
|---|---|
| Text, styles and layout | Reword a heading, use the brand colour, two columns on desktop, stack on mobile |
| New components | "Add a Get quote button that opens a modal with a form" |
| Client/server splits | Interactive UI in an App Router page gets its own client component |
| Forms and server work | A form with a route handler or server action behind it |
| Data and library code | Change a price list, add a helper, update a data file |
| Several files at once | Rename a prop across its uses, move a section into its own component |
While it works, the overlay shows each step ("Reading src/app/page.tsx", "Creating src/components/quote-modal.tsx", "Running typecheck") and how long it took.
A request with a part Revyse won't do is not refused whole: the plan does the rest and says what it leaves out. The plan and the result also list:
- Variables to set: environment variables the change reads, by name only (for example
RESEND_API_KEY). You set them where the app runs; Revyse never sees the values. - Sensitive areas: authentication, payments, database schemas or migrations, dependencies, build configuration. These are allowed, but labelled so a reviewer looks closely.
What Revyse never does
Whichever engine runs, and whatever a request or a file in the project says:
- Never reads
.envfiles, private keys, credentials,node_modules,.git, Revyse's own.revyse/folder, or anything in yourexcludelist. Output that looks like a secret is withheld from the model. - Never writes lockfiles,
package.json, CI configuration, environment files, or anything outside yoursourceDirs. (The classic engine also reads onlysourceDirs.) The one exception: the agent engine may add a connected service's SDK (Resend) through your package manager, which updatespackage.jsonand the lockfile as part of the change. - Never runs anything but the scripts named in
revyse.config.json: no shell, no other installs, no migrations, no deployments, no calls to other services. It may write a migration file or code that calls a service; people run it. Changes that send email are covered in connecting services. - Never ships a change your project's release setting doesn't allow. It commits only to its own branches: locally the change is in your working tree (and on your draft's branch once your repository is connected); in the cloud it opens a pull request. Your base branch changes only the way your project chose.
What the classic engine handles
Front-end changes to existing code, with the evaluation suite's results behind them
(docs/evals/: 82 tasks on five fixture apps, 82/82 on the Balanced tier, 80/82 on Fast, as
of 21 October 2026): text, colour and typography, spacing and alignment, simple layout, links
and existing images, buttons and sections built from existing components, and data edits in
source files. It can't create files and refuses back-end work; switch to the agent engine for
those.
What Revyse asks about
A request that can't be done one clear way gets one question (which heading? which of the two identical buttons?). Answer in the overlay or the conversation and it re-plans. Vague wording is fine; the plan shows how it was read before anything is written.