Can a single prompt generate a ready to use Android app? I gave Claude Code, running on Opus 5 a detailed prompt outlining the functional spec of a book tracking app. I didn’t mention any libraries or framework to use or provided architecture hints.
TL;DR
In 42 minutes, Claude produced a working app of ~2,900 lines of code (and ~1,200 lines of unit tests) using sound Android MVVM architecture: single-activity, Jetpack Compose, Navigation 3. It compiles, it runs, and it does exactly what I asked. It also made a couple of choices a senior reviewer would flag (more on those below…).
The prompt
I intentionally kept it to a functional spec. I didn’t request specific libraries or architecture patterns (I didn’t mention MVVM), Jetpack Compose, or any specific data layer. I just described what the app should do:
Create an Android app to let me manage my book list. The main screen of the app will display the list of books (with cover thumbnail, title, author and a circled checkmark when read) with a search bar at the top. The user can add new books to the list via title and ISBN text search or via barcode scanning. When the user taps on a book in the list, it will open a book detail screen with the book's basic info, the ratings on Goodreads, a link to the Goodreads webpage, a textfield to add the user's personal notes and a button to toggle the book as read/unread. On the main screen, a settings menu opens a settings screen to import or export the books data as a CSV file.
Six to nine months ago, getting a frontier model to generate an Android app that compiled on the first attempt and followed current best practices was a stretch. Today it's pretty much expected.
What it built
Claude Code started this run by loading its Android CLI skill, then iterated writing code, running the build, fixing compile errors and failing unit tests until everything was green.
The UI is plain but every piece of the spec works:
- search,
- ISBN lookup,
- barcode scanning,
- Goodreads links,
- reading notes,
- read/unread toggle,
- CSV import/export.
The architecture: simple but sound
At a high level, Claude Code made solid technical choices:
- single-activity app
- Jetpack Compose,
- screen-specific ViewModels exposing StateFlow,
- Room as persistent storage,
- Navigation 3 for screen-to-screen navigation.
Room is properly used as the single source of truth. The UI observing changes from the BookRepository via Kotlin Flow.
But Claude still made a couple of choices a senior reviewer would push back on:
No dependency injection: for a project with five screens, a Room database, a network dependency, and file I/O, skipping DI is a borderline call.
A catch-all repository:
BookRepositoryis the only class exposing the data layer. It probably can be broken in 2 or 3 other repositories.Stale library versions: Claud wasn’t able to get the latest version of the libraries used for the project. (e.g:
androidx.navigation3Opus 5 usedv1.0.1instead of the latest version). This can be explained by model the cutoff date but I would expect Claude Code to leverage Android CLI to look up the documentation to retrieve the latest library version.
Conclusion
Opus 5 and Claude Code produced a well-architected running Android app from a single functional prompt with no technical steering and did it using current Jetpack Compose and Android code conventions that human developers would recognize as good practices. So Opus 5 would definitely pass the Architecture/Design step in a Sr Android Developer interview loop.
Note that this is just a fun anecdotal test but for a more accurate evaluation look at Android Bench from the Android team.
Top comments (0)