How to test saved changes with your AI agent

You’re building an inventory app with your coding agent. You’ve just added a way to update where an item is kept. You try it: change the location, click Save, and a green message appears. The new location is on screen, so it feels ready.

Before moving on, ask the agent to open that item again. To check that an app really saves a change, follow it through a reload and check the data the app kept. That catches a problem a quick look at the screen can miss: an edit that disappears as soon as you come back.

With Rill, you can ask your agent to record those steps. You get a short replay to watch yourself or share with a teammate, with the save and the return visit in the same clip.

Start with a change your users would make

Let’s call our inventory app Lantern. A workshop uses it to find supplies. When someone moves a kit to another shelf, they update its location in the app so the next person knows where to look.

We’ll use one item, KIT-042, which starts on Shelf B2. Your agent has added a way to update its location to Shelf C7. Lantern and the results below are fictional examples, not a recording of a real app.

Give the agent the whole task:

Change KIT-042 from Shelf B2 to Shelf C7 and save it. Reload the page and open the same item again. It should still say Shelf C7. Check that the app’s saved data shows the new location too.

The last part matters because Lantern is shared. Someone else opening that item needs to see the new shelf as well. A temporary change on your screen would still send them to the wrong place.

Try this with sample data in a test version of your app.

Keep recording after you click Save

Set up Rill with your coding agent, then ask it to record the location change from start to finish. Your agent operates the browser; Rill captures what happens. Start before the edit and keep recording through the reload.

Here’s how the check goes in our Lantern example:

The agent opens KIT-042, changes Shelf B2 to Shelf C7 and clicks Save. The new location appears with a green “Saved” message.

Then it reloads the page and opens the item again. Shelf B2 is back.

That gives you a useful bug to hand back to the agent: “The page said the new location was saved, but reopening the item brought back the old one.” Keep the recording with that note so anyone investigating can watch the same sequence.

Ask your agent to check what the app kept

The recording shows the location changing back. To find out why, ask your agent to inspect the save attempt and the data behind that item.

In Lantern, it finds that the app rejected the update. The saved location is still Shelf B2, even though the page announced success. The page had treated a failed save as a success.

Have your agent look up KIT-042 in the app’s saved data, using access it is allowed to use. It should check the same account and item, then return a short note with the location it found. Leave passwords and unrelated data out of that result.

This check matters even when the new location survives a refresh. Your browser may remember the edit while the data other people use still has the old shelf. If the agent can only check the screen, ask it to make that clear: “Shelf C7 is still showing after refresh, but I couldn’t confirm that the app saved it for other people.”

Check the save again after the fix

Once the agent has made a fix, repeat the same steps with the item back on Shelf B2. Keep the account and sample data the same, and note which version you checked. Our before and after guide shows how to keep the two recordings easy to compare.

In the fixed Lantern example, changing to Shelf C7 works all the way through: Save succeeds, the item still shows Shelf C7 after reload, and the app’s saved data agrees.

Also check what someone sees when saving fails. They need to know their change wasn’t saved and have a way to recover the edit.

In a separate test, the agent simulates a save error. Lantern tells the person their change wasn’t saved and keeps the edit available so they can try again. The saved location stays at Shelf B2.

A simulated error shows how the page reacts. It doesn’t show whether the app would reject that update in a real attempt. Make sure the report says the error was simulated, then turn off the simulation before checking the real save again. If you’ve changed the rules that decide whether a save is allowed, test those rules separately too.

Try it on your next change

Pick a small edit you’ve just built: a project name, a preference or an item’s location. Tell your agent what should happen when someone returns to it. You can adapt this prompt:

Check [the edit] in [test app URL] using sample data. Show the starting value, make the permitted change and save it. Reload and open the same item again. Check that the app’s saved data agrees, using the access already available to you. Tell me if you can’t verify it.

Record the browser steps with Rill using this project’s setup and approval rules. Keep private data out of the capture. Before anonymous recording, explain the upload and who can open the link. Wait for processing and check playback. Send me the recording, which app version you tested, what happened, anything you couldn’t check, and the link’s access and expiry details.

If the isolated test setup allows it, also check one simulated failed save. Show how the page helps someone recover, label the simulation and remove it before testing the real save.

Watch the returned recording before sharing it. Rill doesn’t hide private information in the video, and anyone with an active unlisted link can open the recording and its included diagnostics.

Follow the Rill agent quickstart to record your next edit, and ask your agent to keep recording until it has reopened what it saved.