Modernize an Android app with AI orchestration

Process study · proposed method

Modernize a slice. Reuse what the team learns.

Explore a migration process that reuses codebase discovery, separates implementation from regression checks and evaluates one bounded journey first.

Establish the baseline

Existing Android repository
Representative user journeys
Target devices and build access

Evidence to retain

Reusable application and state map
Bounded implementation comparison
Device evidence and review decisions

Why work this way?

The process, and what it could improve.

Proposed method · no measured savings claim

Cost

Pay for one discovery pass and one bounded slice.

Record the screen, state and dependency map for later agents. Prove the migration on one journey before repeating the approach across the app.

What to compare: Discovery, model and review effort per accepted screen, including regressions and repeated repository exploration.
The tradeoff: An unrepresentative first screen can make the later migration look cheaper than it is.

Compare the same scope and acceptance criteria. Include setup, coordination, failed attempts and human review alongside the successful model call.

Design the work

One problem. A coordinated agent team.

Proposed task plan

A model reasons. A harness runs its agent session and tool loop. Orchard coordinates the work, context and handoffs across them.

Orchard orchestratorScopes work · delegates · synthesizes evidence

CONTROL

Implementation lead

Example session

Model familyClaudeHarnessClaude Code

Trace the Java/XML app and implement a Compose screen at an existing navigation seam.

Bounded task assigned

Counterproposal agent

Example session

Model familyGPTHarnessCodex CLI

Argue for isolating state and data boundaries before migrating UI. Probe lifecycle and offline edge cases.

Opposing assumption assigned

Independent reviewer

Example session

Model familyGeminiHarnessGemini CLI

Compare navigation, persisted state, accessibility, and device behavior against the baseline.

Evidence criteria assigned

Shared project contract

Rules · skills · hooks · MCP configuration

Adapted to each harness

01 / 04 · Dispatch

Split the work. Preserve the question.

One objective, distinct responsibilities

Modernize one Android journey while making behavioral differences visible before release.

Existing backend and saved-data contracts remain the reference for the selected slice.

Implementation leadscreen-migration branch + state contract

Counterproposal agentarchitecture-counterproposal.md + regression fixtures

Independent reviewerdevice-comparison report + review findings

Illustrative execution planAssignment Evidence Review

Model families and pairings are illustrative. Assignments here are manual examples, not measured model comparisons or automatic cost optimization.

Trellis / shared knowledge

Application map

Screens, Gradle dependencies, persistence and API contracts.

Migration decisions

Accepted interoperability patterns, rejected assumptions and baseline screenshots.

BEAM / coordination

Bounded tasks, ownership notices, findings and handoffs between sessions. A queued message and a processed receipt are distinct states.

Recall → work → retain decisions

Tools / execution

Gradle + repositoryEmulator / device matrixUI tests + screenshot comparison

Access follows the configured harness, credentials and approved scope.

Inspect the example work orderJSON

An illustrative work-order format for this scenario. Changing an example session updates this document; no agents run from this page.

{
  "example": "android-modernization",
  "objective": "Modernize one Android journey while making behavioral differences visible before release.",
  "boundary": "Existing backend and saved-data contracts remain the reference for the selected slice.",
  "sessions": [
    {
      "role": "proposer",
      "model_family": "Claude",
      "harness": "Claude Code",
      "task": "Trace the Java/XML app and implement a Compose screen at an existing navigation seam.",
      "expected_artifact": "screen-migration branch + state contract"
    },
    {
      "role": "challenger",
      "model_family": "GPT",
      "harness": "Codex CLI",
      "task": "Argue for isolating state and data boundaries before migrating UI. Probe lifecycle and offline edge cases.",
      "expected_artifact": "architecture-counterproposal.md + regression fixtures"
    },
    {
      "role": "reviewer",
      "model_family": "Gemini",
      "harness": "Gemini CLI",
      "task": "Compare navigation, persisted state, accessibility, and device behavior against the baseline.",
      "expected_artifact": "device-comparison report + review findings"
    }
  ],
  "project_contract": [
    "Rules",
    "Skills",
    "Hooks",
    "Tool configuration"
  ],
  "shared_context": [
    "Application map",
    "Migration decisions"
  ],
  "evidence_required": [
    {
      "label": "Behavior preserved",
      "evidence": "Run identical journeys through the baseline and candidate builds."
    },
    {
      "label": "Lifecycle handled",
      "evidence": "Exercise process recreation, offline recovery, permissions, and saved state."
    },
    {
      "label": "Scope stays bounded",
      "evidence": "Review the diff and dependency graph for changes outside the selected journey."
    }
  ],
  "release_owner_gate": "The app owner accepts behavior differences and signs off the release candidate; signing and store rollout remain explicit steps."
}

The process principle

Reuse discovery. Keep regressions visible.

Scope of this exampleThe route depends on the app and device requirements. Signing, store publication, and rollout remain separate release decisions.

A modernization scenario, not a claim that a particular app has been migrated or published. Android migration guidance

Modernize an Android app

Different tools.
Shared project context.

Where the work changes.
How to judge the difference.

Outlook listener