Question 1

How would you plan a large XML → Compose migration with an agent?

Accepted Answer

Build the plan along two axes: sequence and safety. Sequence (a human decision): Start with the least risky, most repetitive screens so the agent learns the pattern and the team gets used to the process. Convert shared components (buttons, cards, list items) first — later screens depend on them. Leave the most complex and most critical screens for last. Safety (identical for every screen): 1. Tests for current behaviour. 2. Conversion — no behaviour change, incremental via ComposeView. 3. Tests pass unchanged → behaviour preserved. 4. Cleanup separately. The agent's role: primary executor for steps 1, 2 and 4; assistant on sequencing and decisions. End with risk management: one PR per screen, a feature flag behind it if needed, and the ability to roll back on regression. Converting 20 screens in one PR is the most common way these migrations fail.

Question 2

How do you catch it when the agent changed behaviour during a migration?

Accepted Answer

Answer by listing the gates — and name the most important one. 1. Characterization tests (the key gate). Tests written before the migration must pass unchanged. If the agent "fixed" a test, that is an immediate signal and the first place to look in review. 2. The size and character of the diff. If a conversion PR touches a logic file, that deserves a question. Converting the UI layer shouldn't change the logic layer. 3. Screenshot tests for visual regressions. Differences between the XML and Compose versions can be visible. 4. QA / manual checks for critical flows. 5. Staged rollout — a feature flag or percentage rollout. Call out the strongest point separately: a modified test is the most important signal. The agent tends to change a test to make it pass. So the diff of test files in a migration PR deserves special attention — and that can be enforced as a CI rule.

Question 3

When should a migration not be delegated to the agent?

Accepted Answer

Give a criterion: wherever it can't be verified. Cases I don't delegate: No test coverage and no way to add it — code tightly bound to an external system that can't be isolated. Nothing there catches a behaviour change. Critical logic with undocumented behaviour — payment calculations, discount logic. If nobody knows what "correct" is, the agent can't preserve it. Security-related code — authentication, encryption, key management. Mistakes compile and pass tests while the weakness remains. Real-time or performance-critical code — behaviour can stay identical while the performance profile changes. Ordinary tests don't catch that. But draw the boundary correctly: even here the agent can help — analysis, presenting options, attempting tests. It is the final change that a human makes and a human verifies. A good closing line in an interview: "The question isn't 'can the agent do it' but 'what would catch it if it got it wrong'."

Migration step	Suits the agent	Reason
Planning the sequence	Partly — in plan mode, with human approval	Business priorities are unknown to the agent
Writing tests for current behaviour	Yes — high value	Mechanical, and the result is checkable
Converting one screen	Yes	Narrow scope, guarded by tests
Converting 20 screens at once	No	Review becomes impossible and regression causes get lost
Automatic Java → Kotlin conversion	No — the IDE tool does it better	The agent's value is in the cleanup after conversion
Making converted Kotlin idiomatic	Yes	Nullability, data classes, scope functions

Legacy refactoring: XML → Compose, Java → Kotlin

📚 Sources and documentation