Hot Reload with AI

The workflow is simple: start HotSwan, open an AI tool, and let it edit your code. HotSwan handles the rest.

First, run your app with HotSwan enabled in Android Studio or IntelliJ. The plugin begins watching for file changes. Then use any AI coding tool to modify your Kotlin files. The tool saves the file, and HotSwan detects the change through periodic VFS (Virtual File System) refresh. HotSwan incrementally compiles only the changed classes, pushes them to your device, and triggers recomposition. The UI updates in seconds.

You do not need to configure anything special. HotSwan treats AI-generated file saves the same as manual saves. The only difference is that AI tools tend to save more frequently, which HotSwan handles through its built-in debouncing mechanism.

HotSwan works with any tool that edits and saves files on disk. It does not depend on IDE-specific APIs for change detection, so external tools are fully supported.

Claude Code is Anthropic's CLI tool that edits files directly on disk. HotSwan picks up every save via periodic file system refresh. Cursor's AI edits are saved through the editor, which triggers the IDE's file system events that HotSwan detects immediately. Any other AI tool that writes to your project files will also work: GitHub Copilot, Windsurf, Aider, or custom scripts. As long as the file is saved to disk, HotSwan will detect and reload the change.

Almost anything. This section used to be a list of shapes to avoid, because HotSwan 1.x reloaded by asking the Android runtime to accept a redefined class, and the runtime accepted little more than a changed method body.

HotSwan 2 runs the new code in an interpreter inside the app, so the edits an agent actually produces are the edits it carries. Adding and removing composables, changing how a screen branches, wrapping layout, splitting one composable into three, and replacing a screen outright all apply while the app keeps running.

Two things still need more than a reload. Changing a class's superclass or the interfaces it implements restarts the process, which HotSwan does for you and which is far cheaper than a rebuild. Adding a brand new resource needs a reinstall, because resource IDs are assigned at build time and the one you just invented does not exist on the device. Everything else is a save. See Limitations.

The older advice for AI plus hot reload was to keep prompts small so the change stayed inside an existing function body. That advice is obsolete, and following it now costs you the interesting half of what an agent is good at.

Ask for the change you actually want:

The last one is the shape worth learning. Variants used to be expensive because each one cost a build, so you asked for one and hoped. When each variant is on the device a second after it is written, generating three and choosing is cheaper than describing one precisely.

Watch the device, not the diff. The reason to have the app in front of you is to catch a wrong direction on the second file rather than after the tenth. Reading the code the agent produced tells you what it did; the screen tells you whether it was right.

Get to the screen first. Navigate the running app to whatever you are about to change, including the state that makes it interesting: the error case, the long list, the logged out user. Your state survives the reload, so you set it up once and then iterate against it.

Interrupt early and cheaply. When the screen goes somewhere you did not intend, say so immediately. One sentence at that point is worth more than a careful review of a finished direction you are going to discard.

Let the agent look for itself. Through the HotSwan MCP server an agent can reload, take a screenshot, and read the layout of what is on screen, so it can check its own work before asking for yours.

AI tools often save files rapidly, 5 to 10 times in a few seconds. HotSwan is designed to handle this gracefully through several mechanisms.

When multiple saves arrive in quick succession, HotSwan coalesces them with a short debounce window. Instead of triggering separate reloads for each save, it waits for the burst to finish and compiles all changes together. This prevents cascading class reloads and keeps the device stable.

Unlike IDE keystrokes, external AI tools write directly to disk. HotSwan runs a periodic file system refresh to detect these external changes reliably without relying on IDE document listeners. This is why changes from CLI-based tools like Claude Code are picked up even though they operate outside the IDE.

Rapid AI edits can occasionally produce intermediate states that cause layout crashes. HotSwan installs a crash guard that catches these failures shortly after reload and automatically recovers by restarting the Activity. The deferred change queue is also cleared during recovery to prevent infinite crash loops.

AI tools sometimes make incremental saves that produce identical code, for example saving mid-edit before the change is complete. HotSwan detects when nothing has actually changed and skips the reload entirely, avoiding unnecessary recompositions on the device.