Make your Android UI easier for AI to change

A useful case study, not a rewrite mandate.

On 30 September 2026, Google and Meta published a case study of Instagram Direct’s move to Jetpack Compose. The team redesigned UI boundaries alongside the migration, then compared internal AI coding sessions on Compose and Android Views. The post reports lower agent resource use in that setting.

It does not establish what your team will save. The public post does not supply the session sample size, collection dates or full model setup needed to reproduce its comparison. Framework choice, architecture and migration work also travel together here.

For a small Android team, the useful question is narrower: can an agent change one screen without needing to understand the whole app? The pilot below is our suggested way to investigate that question, not a reported Instagram experiment.

Give each piece of state a clear owner.

Imagine a hypothetical reading app with a list of saved articles. An agent adds a bookmark button, but stores its selected state in a reusable row object. After scrolling, another row inherits that value. The code may compile while the wrong article appears saved.

Give the row its current bookmark value and a callback for the requested change. Let the appropriate state owner update that value and handle persistence. Keep a failed save visible instead of treating a tap as a successful database write.

Android’s state-hoisting guidance recommends exposing immutable state and events from the owner, placing shared state at the lowest common ancestor that needs it. Simple local UI state can stay local. The goal is a visible ownership rule, not moving every animation or expanded flag into a global store.

For your pilot, write down who reads the state, who changes it, and what happens when saving fails. Review the agent’s diff against those three answers.

Give the agent a small, complete contract.

Choose one frequently edited screen with a clear entry and exit. Provide its state model, reusable components, a working example and the expected behavior. Avoid starting with a navigation rewrite, SDK upgrade and visual redesign in the same change.

A useful task brief for the reading app could be:

• Change: add a bookmark action to each article row using the existing button component.
• State: render the supplied saved value; send the article identifier to the existing save handler.
• Outcomes: show pending, saved and failed states; preserve the right article’s state after scrolling and reopening.
• Boundary: keep purchase, account and navigation behavior unchanged.

Make the component interface and checks support that brief. A long instruction file cannot compensate for two competing places that both appear to own the same state. Keep a short example beside the relevant code so future changes start from a working pattern.

Check what people experience.

Compose’s testing APIs can find interface elements, perform actions and verify their properties. For the bookmark example, check the selected article, the saved result and the error path. A screenshot of a filled icon alone cannot prove persistence works.

Exercise fast repeated taps, list reordering, leaving and returning to the screen, and a failed save. Check accessibility labels and large text on the devices you support. Run the same scenarios on the current screen before judging the replacement.

If you also adopt Compose, Android recommends an incremental migration, with Views and Compose coexisting while screens move over. Choose an understandable boundary and retain a working fallback. Measure responsiveness and scrolling in the actual mixed app; one isolated component cannot settle the performance of an entire migration.

Measure accepted work, including review.

Pick a small set of representative UI tasks and agree on acceptance checks before starting. Keep the model, agent settings and task scope as consistent as possible. Record agent runtime and token charges, but also reviewer time, correction rounds and defects found before or after acceptance.

Use accepted tasks as the denominator when comparing effort. Include abandoned attempts in total effort; report them separately too. Do not treat extra generated lines as extra value. If you repeat the same task after restructuring, record that the engineer has already learned from the first attempt.

Keep the change when reviewers can understand and accept the work with less effort, while behavior and device performance hold up. If the agent writes faster but leaves more repair work, narrow the task or fix the state boundary before expanding the pilot.

This is about the tools used to build an app. For AI that runs inside the product itself, use the separate in-app workflow guide. In either case, verify the completed outcome rather than counting attempts.