The headless CLI is the part I'd steal. Once agents can read app state and trigger actions directly, behavioral checks become assertions on state instead of screenshot parsing, which is much cheaper and less flaky than a computer-use loop. I'm curious how the visual review step worked, though. Was it automated screenshot diffing against the React Native reference, or people comparing by eye? That's the one check the CLI can't cover, and across 300+ screens it seems like where small drift would hide.
Greenfield code still inherits an installed user's data. Alongside Helix's screen checkpoints, I'd keep an upgrade fixture created by the React Native app: saved preferences, an unfinished draft, and a pending background task. Install the native replacement over it and verify those states survive, including an upgrade after the user skipped several releases. A clean-install behavioral pass can miss that boundary completely. This makes the migration's release gate about continuity for existing users, not just parity between two fresh app sessions.
Helix's checkpoints are what make the agent rewrite reviewable, but the behavioural check still has to be the same contract on both sides of the port. The article says an agent can take an iOS feature's actions and error conditions and write the Android equivalent, then a developer checks the result. I would store those actions and expected state transitions with the checkpoint and run them headlessly against both the reference app and the new screen, so a pass means the two implementations agreed rather than that the Kotlin looked native.
The headless CLI is the part I'd steal. Once agents can read app state and trigger actions directly, behavioral checks become assertions on state instead of screenshot parsing, which is much cheaper and less flaky than a computer-use loop. I'm curious how the visual review step worked, though. Was it automated screenshot diffing against the React Native reference, or people comparing by eye? That's the one check the CLI can't cover, and across 300+ screens it seems like where small drift would hide.
Greenfield code still inherits an installed user's data. Alongside Helix's screen checkpoints, I'd keep an upgrade fixture created by the React Native app: saved preferences, an unfinished draft, and a pending background task. Install the native replacement over it and verify those states survive, including an upgrade after the user skipped several releases. A clean-install behavioral pass can miss that boundary completely. This makes the migration's release gate about continuity for existing users, not just parity between two fresh app sessions.
Well, the question is how long would shopify continue being relevant
Helix's checkpoints are what make the agent rewrite reviewable, but the behavioural check still has to be the same contract on both sides of the port. The article says an agent can take an iOS feature's actions and error conditions and write the Android equivalent, then a developer checks the result. I would store those actions and expected state transitions with the checkpoint and run them headlessly against both the reference app and the new screen, so a pass means the two implementations agreed rather than that the Kotlin looked native.