Quick answer
In agent validation, the burden of proof falls on the agent. The agent tests its fix on a simulator and brings proof to the pull request: screenshots from before and after the fix, a video of the fix in action, and a link to the build. In human validation, the engineer looks at that proof and decides if it is enough.
Before, an agent's pull request was a wall of code. To see if the fix worked, you opened the build on a phone or a simulator yourself. Now you can go a step further with agentic CI, and have an agent verify the fix on several simulators at once, with different screen sizes.
Then you decide whether the proof is enough to merge the fix, or whether you want to open the link and tap through the build yourself. Either way, nobody has to pull the branch, build the app, and install it before the review starts, so fixes get from pull request to merge faster.
What does it mean to put the burden of proof on the agent?
An agent that writes a fix also shows that the fix works. It runs the app on a simulator, checks the result against the task, and attaches the evidence to the pull request. That is agent validation.
Human validation is the review that comes next. The engineer looks at the evidence, or opens the build and taps through it, and decides whether the change is right and ready to merge. The agent proves that the change works, and the engineer decides if it merges.
Why does review take so long without proof?
An agent can open a pull request quickly. Checking it takes longer. Without proof, the reviewer pulls the branch, builds the app, installs it on a phone or a simulator, and taps through the flow to see if the fix works. Then they do the same for the next pull request.
When agents open more pull requests than people can check this way, review becomes the slowest step. Teams then check less carefully, or merge on the diff alone. Proof on the pull request moves that work to the agent, which can run the app as many times as the task needs.
What proof should an agent attach to a pull request?
Ask for proof that a reviewer can check in a few minutes:
- Screenshots from before and after the fix. Side by side, they show the change at a glance.
- A recording of the fix in action, from the start of the flow to the end. A screenshot shows one moment. A recording shows every step, so the reviewer can see where a flow goes wrong.
- An action log with timestamps, which lists each step the agent took.
- A link that opens the build on a simulator, for a reviewer who wants to tap through it.
Tell the agent that a person will review the proof. Ask it to list each check in the pull request comment. The reviewer then follows the recording step by step.
What can an agent prove on every pull request?
Some proof takes many runs to collect. An agent collects it on every pull request and attaches it, so the reviewer starts with the evidence.
Reproduction. Given a crash report, an agent installs the build and follows the steps to confirm whether the crash happens. Then it applies the fix and confirms whether the crash stops. It attaches a recording of both runs: the crash, then the fix.
Coverage across states. Log in as a new user, an expired user, a user with no payment method, and a user with three. Try each on two screen sizes. That is eight runs. The agent runs all eight and attaches a result for each case. With agentic CI, the runs happen on several simulators at once.
Structural checks. Tools like agent-device read the accessibility tree: the labels, roles, values, and test IDs of each element on screen. That makes checks like "every interactive element has a label" and "the Confirm button exists" easy to write and repeat. Screenshots are evidence and a fallback. You can also ask the agent to report elements with missing labels.
This verification step uses agent-device, an open source CLI from Callstack that coding agents run from the terminal:
The agent reads the snapshot, acts on a reference, reads the next snapshot, and saves a screenshot as evidence.
Timing. If verification runs on every pull request the moment it opens, the reviewer opens a pull request that already has its proof attached. Your team adds that step as a CI job or an EAS Workflows job.
How does proof make review faster?
The reviewer starts from the evidence. They watch the recording, compare the before and after screenshots, and check that what the agent verified is what should have been verified. Then they approve, or send it back with a note.
Pulling a branch, building it, installing it, and clicking through it takes far longer than watching a short recording. When the recording raises a question, the reviewer opens the link and taps through that screen on a simulator.
Designers and product managers can review too. They watch the recording in a browser or open the link, and nobody has to register a phone or wait for a TestFlight build.
What does the reviewer still decide?
Proof shows that the change does what the task said. The reviewer decides the things that the task did not spell out.
Whether it is the right change. An agent can confirm that the success screen appears. The reviewer may know that the flow should go straight back to the order list. Design intent lives in someone's head. Until it is written down as a requirement, the agent cannot check against it.
Whether it is the right implementation. Sometimes the reviewer also decides whether the code takes the right path to the fix.
Whether it feels right. A person can see animation timing, scroll behavior, and slow loading in a recording. A recording can miss frames, so use a profiler for short frame drops. Haptics need a physical phone.
Whether the agent checked the right thing. The reviewer checks that the agent understood the bug. For an ambiguous bug report, let the agent say that it could not reproduce the bug.
Whether to merge and ship. That is a judgment about risk, timing, what else is going out, and who is on call. A person owns that decision.
What makes the proof trustworthy?
Proof is only useful if the agent that wrote the fix does not also grade it. An agent that writes a fix and then writes a test to match it can pass its own test, because it wrote both sides. A person who tests their own code has the same blind spot.
Keep the two jobs apart. One agent fixes the bug. A separate agent reviews the fix and tries to break it, or runs the checks in agentic CI. The action log with timestamps lists each step, so the reviewer can see what each agent tested.
How do you start?
Start with one rule: no agent pull request merges without proof attached. That means a session recording, screenshots from before and after the fix, and a link to the build.
Run that for two weeks. Then look at which recordings reviewers opened, which ones caught something, how many pull requests went back for changes, and how long review took compared to before. That tells you where to ask the agent for more proof, such as more user states and more screen sizes, and where a reviewer still wants to tap through the build.
A few things to expect:
Agents miss elements that lack accessibility labels. If your app has unlabeled buttons, the agent either fails to find them or falls back to screenshots and coordinates, which breaks easily. Adding labels helps the agent and helps your users.
Agents are literal. "Verify the payment flow" gets you a verification of whatever the agent decides the payment flow is. Write the check you want: "Confirm that after tapping Confirm, the success screen shows the order total and a Done button."
Recordings pile up. Decide on retention early. A recording nobody opens after the pull request merges does not need to exist forever.
Where Expo fits
If your agents write code but do not run it, the first step is to give them a simulator. On a Mac, that is the local iOS Simulator or Android Emulator, driven through a tool like agent-device. For agents that run in CI or in the cloud, or for more than one at a time, that means a cloud iOS Simulator or Android Emulator that the agent starts and drives from a command.
Expo Simulators is built for this. The agent starts a session with one command, installs the build, collects the proof, and stops the session when it is done. EAS records the full session screen and keeps the recording, the screenshots, and the activity log on the session page, where anyone who can view the project can open them. A reviewer with the Developer role on the project can open a link that starts a new session with the same build and tap through it. Android support is still in development, so some features that work on iOS may not work on Android yet.
Expo Simulators works for any app built for the iOS Simulator or the Android Emulator. If you build with Expo, it installs the builds you already make with EAS Build. Expo Simulators is in a limited beta release, so check the current limitations before you plan around it.
If an agent sets this up for you, have it load these Expo Skills first:
expo-overview: the entry point that routes the agent to the right Expo skill.eas-simulator: the currenteas simulatorcommands, session types, evidence collection, and cleanup steps.eas-workflows: how to run the verification step on every pull request with EAS Workflows.
Install them:
- Claude Code:
claude plugin install expo@claude-plugins-official - Codex:
codex plugin add expo@openai-curated - Cursor and other agents:
npx skills add expo/skills
The full list is at docs.expo.dev/skills.
Earlier in this series: What to look for when choosing a cloud simulator and Cloud simulators vs local simulators: when each one wins.
Verified on 19 October 2026.