Taking a vibe-coded prototype into production

Write down the behavior worth keeping

Start with the part of the prototype people already use. Suppose an internal booking tool lets a colleague choose a room and reserve a time. A screenshot of the form explains its appearance, but it leaves several decisions open: whether overlapping reservations are allowed, which timezone applies, and who can cancel someone else's booking.

Record those decisions before asking an agent to reorganize the application. A short acceptance note might say:

• A confirmed reservation blocks the same room for that interval.
• The interface shows the timezone beside the selected time.
• Only the creator or an authorized administrator can cancel a reservation.
• Two simultaneous requests for the same interval cannot both succeed.

This is an illustrative specification, not a claim that a particular booking app already passes these checks. Use the same approach with your own app: write the behavior that would make a user report a bug if it changed. Keep unresolved questions visible so the agent does not settle them by accident.

Make the app work from a fresh checkout

Have a teammate follow the setup instructions in an empty environment. They should be able to install dependencies, supply development configuration, start the required services, and open the app. Anything you need to explain during that attempt belongs in the setup instructions or configuration.

Separate secret values from the configuration contract. A checked-in example can name a required database connection without containing a real credential. Use development data that the team can reset. Copying a production database into a test environment introduces access and privacy questions that a convenient setup script cannot resolve.

A cloud coding environment can give the agent a place to reproduce this setup. You still have to describe how the app starts and which external services it needs. Saving an environment image alone does not make a remote database reproducible.

Give the agent one change with a checkable result

A request to “make this production ready” leaves the agent to guess the scope. For the booking example, begin with overlapping reservations. Ask it to identify the current write path, propose the constraint, add the relevant check, and explain what happens when two requests arrive together.

Prevent two confirmed bookings for the same room and time interval.
Keep the existing form and public response shape.
Add a regression check for simultaneous conflicting requests.
Explain any database change and how existing rows affect it.
Return a pull request with the commands run and their results.

The prompt is a worked example. Adapt it to the repository's tests and data model. If the change needs a product decision, answer it before expanding the patch. If it needs a migration, include that migration in the review and decide its deployment order explicitly.

Follow with a separate task for timezone behavior or permissions. Small changes leave a reviewer with a specific question to answer, and make it easier to identify which change caused a regression.

Check the running result and the release path

Run the changed behavior from the revision you intend to ship. Inspect both the success case and a rejected request. For a web app, also check the error state on a narrow screen: an accurate server response is little help if the user never sees its message.

Keep the checks with the proposed change. A useful handoff names the tested revision, lists the commands, shows any browser evidence, and identifies work that could not be verified. Our guide to verifying coding-agent work gives a fuller review procedure.

Before releasing, assign ownership for the deployment and for checking the app afterward. Decide how you will recognize a failed release, where errors will appear, and how you would restore service. A database change may make an old application version incompatible, so review rollback assumptions with the schema change.

In Uno, the session keeps the agent's work and outputs together, and a published app preview can help with inspection. Use your normal repository review and release checks to decide whether to accept the result. The first-session guide walks through starting a bounded task.

Leave instructions the next person can use

After the first reviewed change, update the repository with the setup command, important decisions, and required checks. Write instructions at the level of the task. “Run the booking integration suite after changing reservation writes” helps an agent choose a check. “Always produce high-quality code” leaves the same choice unanswered.

Put reusable conventions in shared repository context and keep task-specific observations with the task. Include a reason when a restriction is easy to misunderstand. For example, explain that a development service uses synthetic data rather than silently relying on a developer's private account.

You can then delegate another bounded change and repeat the process with a second teammate. If they can start from the written context, inspect the result, and decide what to ship, the prototype has a workflow the team can maintain.