Using opencode for Kotlin and Android development

opencode is a terminal coding agent that you start in a Kotlin/Android project folder with opencode. It reads AGENTS.md for project instructions and can edit Kotlin, Compose, Gradle, and test code. See opencode for the core agent reference. This guide shows how to set up a project, run a tight verify loop, and use it with JUnit and Espresso.

How opencode helps on an Android codebase

Android projects mix many moving parts: Gradle module graphs, Kotlin compiler settings, XML resources, Compose functions, coroutine threading, and test source sets. opencode can inspect all of these through the file tree and shell commands, so it sees the same failures you would in the terminal. Because it runs locally with opencode, you can review every diff with git before merging. It is especially useful for repetitive tasks like moving code between ViewModel and repository, updating tests after API changes, and fixing lint warnings that span many files. The AGENTS.md file keeps project-specific rules in front of the agent so it does not need to guess your conventions.

Configuring AGENTS.md for Kotlin and Android

Put an AGENTS.md file in the repository root. opencode reads it at startup, so keep it short and factual. For a Kotlin/Android project the file should list the exact Gradle tasks you use, where source sets live, and the rules that matter for Compose and coroutines. Avoid long prose; commands and paths are enough. Example:

# AGENTS.md

## Build and verify
- ./gradlew testDebugUnitTest
- ./gradlew lintDebug
- ./gradlew assembleDebug

## Source layout
- Single module: app/
- Main sources: app/src/main/java/<package>/
- Unit tests: app/src/test/java/<package>/
- Instrumented tests: app/src/androidTest/java/<package>/

## Kotlin and Android conventions
- Use Jetpack Compose for UI; no XML layouts for new screens.
- Use ViewModel + StateFlow for screen state; expose StateFlow, not LiveData.
- Use viewModelScope for coroutines; never use GlobalScope.
- Keep repository interfaces in data/ and implementations in data/impl/.
- Before editing a file, check whether a matching test already exists.

Keep the file under about 30 lines. If your project has multiple modules, add a short block per module with its own test and lint commands. For a team, commit AGENTS.md so every developer gets the same agent behavior. A full walkthrough of the basic opencode loop is available in How to use opencode: a step-by-step guide.

A small-step workflow with Gradle checks

Work with opencode in small, verifiable steps. Start by describing the behavior change, not the implementation. Ask the agent to first read the relevant files and state a plan, then make the change, then run a specific Gradle task, and finally show git diff. Review the diff before you accept it, because Android changes often touch several files: a Composable, a ViewModel, a repository, and tests. If a step fails, paste the compiler or test output back and ask for a fix. Typical prompts:

• Read HomeViewModel and HomeScreen. Add a pull-to-refresh action that updates a StateFlow. Keep the existing unit tests passing.
• Run ./gradlew testDebugUnitTest. For each failing test, explain why it fails and fix the production code or the test if the test is wrong.
• Refactor UserRepository to use Kotlin Result instead of throwing exceptions. Update the ViewModel, remove all try/catch in callers, and adjust unit tests.
• Add an Espresso test for the login screen that checks a wrong password shows an error message. Use the existing test setup in app/src/androidTest.
• Run ./gradlew lintDebug and fix all Android lint issues in the new feature code. Do not change existing suppression files.

After each step, run the test command yourself or ask the agent to do it. A good prompt always names the Gradle task, because Android builds have many variants and a generic ‘run tests’ can pick the wrong source set. For deeper background, see How to use opencode: a step-by-step guide.

Strengths and risky areas in Android work

opencode is strongest on well-defined refactors and bug fixes that have tests. Moving state from a Composable into a ViewModel, replacing a callback flow with StateFlow, extracting a repository interface, or updating Compose previews are all good tasks. It also handles Gradle version catalog changes and resource string extraction well when you give exact package and file paths.

Watch it closely on these areas:

• Compose recomposition and state: the agent can create code that compiles but recomposes too often or captures stale lambdas. Check for remember, derivedStateOf, and key parameters.
• Coroutine threading: it may call suspend functions from the main thread or use runBlocking in production code. Require viewModelScope or injected dispatchers and verify with unit tests.
• Gradle configuration: changes to plugins, Kotlin compiler options, or dependencies can break the build in ways that only appear on a clean sync. Always run ./gradlew assembleDebug after dependency changes and review the full diff.
• Android resources and manifests: the agent may add a permission or activity but not update the manifest merge rules, or create a string resource with wrong formatting. Check generated resource names and plural rules.
• Test source sets: it can put instrumented tests under src/test or unit tests that need Android classes under src/androidTest. Verify the test source set before running.

Testing Kotlin and Compose code with opencode

Use Gradle as the single source of truth. Tell opencode the exact task instead of letting it choose. A compact verification matrix:

After the agent makes a change, ask it to run the relevant row. For example: ‘Run ./gradlew testDebugUnitTest and fix any failures in the new ViewModel test.’ For UI changes, connected tests require a running emulator; if none is available, ask for unit tests around the ViewModel state and a manual Compose preview check. Keep lint in the loop because opencode may write code that compiles but triggers Android lint errors such as missing contentDescription or hardcoded text.

Parallel agents on Android with AgentVera

AgentVera runs opencode and other CLI agents side by side in separate terminal panels. For Kotlin and Android work, the most useful features are parallel agents in their own git worktrees, automatic code review that links findings to file:line, checkpoints that let you undo any turn, and token budgets that stop runaway sessions. With git worktrees, one agent can work on a Compose screen while another refactors a repository without overwriting files; the code review catches coroutine and recomposition mistakes after each turn, and checkpoints let you replay a Gradle fix step by step.

Wrapping up

Use opencode as a fast editor that respects AGENTS.md and Gradle verification. Keep tasks small, require a specific Gradle task after every change, and review the diff before moving on. With a tight loop and clear project instructions, it handles the repetitive parts of Kotlin and Android development without hiding the build system from you.