- Shopify Engineering says its AI agent River's share of merged mobile pull requests rose from 6% to 61% over time, as it added remote Macs and won over engineers.
- The shift shows that the agent's workplace is infrastructure: a fast, repeatable place to run and prove its work must be bought and maintained.
- Leaders should ask where agents run, what a session can reach, and how changes are proven beyond a passing build.
Writing code was the easy part
Giving an AI agent a task is simple. Giving it a place to run and check its work is harder. Shopify's engineers learned this with mobile apps, and their account shows where the cost of AI-assisted development is moving.
Shopify Engineering published the details on October 22. Its team built agent workflows for mobile development, then found that three or four of them could max out a laptop. Compilers, simulators and emulators competed for the same machine. If someone closed the lid, the work stopped.
The team already had River, its AI agent in Slack. But River ran on Linux. It could edit Swift code for iOS, but it could not build or test the iOS app. In Shopify's words, its ability to delegate had outgrown its ability to run the work.
How Remote Dev works
Shopify's answer is called Remote Dev. Its core is a group of Macs located elsewhere, each ready to build the iOS app and run it on a simulated iPhone. Agents connect to them over SSH, a standard way to control another computer remotely.
Android was harder. The Android emulator needs hardware virtualization. Running it in a cloud virtual machine means one virtual machine inside another, called nested virtualization. Shopify says macOS does not support that out of the box.
The workaround was to link each Mac to a second computer: a Linux virtual machine set up to allow that nesting, where the Android emulator actually runs. An agent can then build for both platforms on a Mac and test on either, in one SSH session.
Speed was the next problem. Shopify says the first app build and code checkout took over 30 minutes. It now keeps a pool of warm Macs, with the code checked out, tools installed and apps already built. An agent claims one, syncs its branch and attaches a prebuilt Android instance. Shopify says the wait is now a few minutes.
The pool is also disposable. Shopify destroys each Mac when a session ends and prepares a replacement. It also replaces idle Macs on a staggered schedule, so the pool stays available with fresh code and warm caches.
The agent had to learn to prove its work
The hardware was not enough. Shopify says River kept claiming an iOS build could not run on Linux, and it forgot the remote Mac existed. Sometimes it went silent while waiting.
The fix was a written skill, meaning instructions that teach the agent how to test and prove its changes. Shopify also built a command-line tool to hide the SSH details. Instead of timeouts, it used tmux panes, which let River watch long tasks in real time.
This answers a question every executive should ask about AI code: does it work? Shopify notes that code compiling does not mean a feature behaves as expected. Its agents navigate the app and capture screenshots or recordings on iOS and Android. For bug fixes, River records the broken behavior, applies the fix and repeats the steps to show before and after.
Shopify also streams the running simulator to a browser over WebSockets, so a designer or product manager can use the live app from a link. The post says no Mac is required.
What the numbers say, and what they do not
Shopify reports that River created 6% of merged mobile pull requests at first. Over time that share rose to 61%. A pull request is a proposed code change. The figures are Shopify's own. The post does not date the 61%, say how many requests that covers, or describe how review quality changed.
The rise is not credited to the Macs alone. Shopify also credits non-technical work. It used storytelling and internal ads to change habits, because some early users had a poor experience and went back to coding locally. It also uses a fast, cheap classifier model called Jev to tag River's mobile conversations. Failed ones feed a model that suggests improvements.
Some workflows now run overnight. They pick up bugs, implement fixes, test them and open pull requests for morning review.
The lesson: the agent's workplace is infrastructure
This shows a shift in where the work sits. When agents do more of the building, the scarce resource is no longer a developer's time. It is a safe, fast, repeatable place for the agent to run and be checked. That place must be bought, secured and maintained.
It also changes who holds access. Agents here connect to machines holding a large company codebase and run builds unattended. The post does not describe the access controls. Replacing Macs after each session limits what one session can leave behind, but that is our observation, not Shopify's stated reason.
Questions for your teams:
First, where do our agents run and test their work? If the answer is a developer laptop, how far can that scale?
Second, what can an agent session reach, and what happens to the machine afterward?
Third, how do we prove an agent's change works beyond a passing build? Recordings and live previews are one answer.
Fourth, who reviews the fixes agents prepare overnight, and what share of merged changes do they now make?
The lesson here is that an agent that can only write code produces drafts. One that can run and show its work is a colleague you still have to supervise.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: Shopify Engineering.
