Stage 0 (full control & no trust) - I started with VS Code + Android Studio. Yes, Claude created something, however compilation and error correction was an old-style pain. Initially googled, then asked AI "check and correct the error". Then I realised that I don't need neither VS Code nor Android Studio. When I need to review a code, i can do it in project folder directly.
Stage 1 (building the trust) - moved to Claude Code CLI. Jointly with Claude we defined the processes and the team structure (agents responsible for core framework, games, QA tests, and the tech lead performing the code review), and then Claude set up the environment (bye-bye VS Code). At this stage, I still reviewed some code but started to build trust into overriding reviews by tech lead.
Stage 2 (direction and supervision of the AI team) - I realised that it's more valuable to have a proper planning to define the requirements (concept, high-level architecture and design), and then allow agents to develop the game, add automated QA tests, and then tech lead to do a code review.
Some rules on the road and helpful processes that we defined on this journey: - Key architectural decisions are fixed during the initial planning. AI is not allowed to circumvent them and must ask my approval, and in most cases, we found better ways within the initial boundaries. The same applies to the core app framework that was frozen after the initial implementation and QA. - Hard module ownership - prevents agents to make quiet changes to each other's code. Technical lead still flags such cases during review, but these are rare exceptions now. - UI design - Claude can do UI, but it's not the strongest area, and initially it was a pain... We established a workflow when all UI changes are first shown on local web server. It still takes multiple iterations to get to appropriate level, but much easier now. - Device testing matrix - it allows to see how it looks like on different screens (resolution, density, aspect). We ended up in 12 types from low-end to high-end phones and tablets. One script runs app on emulator and takes screenshots. Another script identifies issues in app screens. The last presents all screenshots (by devices, layouts based on portrait/landscape, touch/buttons, dark/light theme) on local web server. Once all ok, the screenshots are promoted as golden and used in later QA tests. - Triage flag - helpful when I'm away and have some ideas or thoughts. I simply raise an issue on Github mobile, add a triage flag, and Claude picks it in our next session. - Detailed test plans for manual testing on live devices. - For marketing materials, AI's focus is shifted towards low-level details. It's helpful to propose some points or do a sense check of human-written draft. But if you want a story with a correct focus - do it manually...
Key controls in the process are: - peer review by tech lead agent for all changes; - automated QA tests and UI tests based on the device matrix; - standardised release process (validation of QA tests, final testing of AAB release, updates to Play Store listing and website, and some other steps); - Play Store upload is still a manual step, done by me when happy with all release process checks and steps.
And a little about the application itself - it's free, offline, currently contains 2 games (easy classic games where you don't need to learn how to play), and more games are coming :) Web-page: https://playdowntime.com