Game Collection: Vibecoding an Android App with Cursor

I recently put together a new Android project called Game Collection, built using Cursor and its agentic AI workflow capabilities.

 

This started as a simple idea: build a lightweight app to browse video games using the IGDB (Internet Game Database). But more importantly, it became an experiment—how far can modern AI tools go if you give them a well-structured plan?

💡 The Idea

At its core, Game Collection is a simple app:

• Users can browse games by platform, view detailed information (cover art, summaries, screenshots), and save titles to a personal collection stored locally on-device.

 

Nothing too crazy from a product standpoint, but that wasn’t really the point.

The real goal was to explore whether an AI-assisted workflow could produce something that feels closer to a structured production-style Android app, not just a quick prototype with “spaghetti code”.

🤖 Vibecoding with a Plan

For this project, I used Cursor’s Plan mode with the Composer 2 Fast model.

Instead of jumping straight into prompts, I took a step back and approached this like I would any real project. I defined:

• The architecture (Clean Architecture + MVI)

• The tech stack (Compose, Room, Hilt, Retrofit, Coroutines, StateFlow)

• The modular structure

• The user flows and navigation

• Expectations around testability and separation of concerns

 

In other words, I didn’t just ask AI to “build an app”, I gave it a detailed blueprint.

🧱 Building on AndroidBooster

To get things going, I used my Android Booster project as the foundation:

🔗 https://github.com/huhx0015/AndroidBooster

This already includes a modular setup, shared architecture patterns, and a set of “Claude skills” that help guide AI toward consistent implementations.

From there, Game Collection was essentially layered on top, focused purely on the feature set.

⚡ 30 Minutes Later…

After feeding the full plan into Cursor and reviewing its execution strategy, I let it run.

About 30 minutes later, the app was… basically there.

• Navigation flows were wired up

• IGDB integration (including Twitch auth) was working

• Compose screens were generated

• Room database was hooked up

• State and data flow followed MVI-style patterns

 

Not perfect, but surprisingly complete.

I’d estimate about 95% of the intended functionality was implemented in that first pass.

There were a few rough edges that needed follow-up prompts and some manual fixes, but nothing major.

Honestly, this was the most surprising part.

This is the kind of scaffolding + feature work that would normally take several hours (5+ easily) to get into a solid state. Seeing it come together in under an hour, while still respecting architectural constraints, was pretty wild.

🏗️ What I Found Interesting

A few things stood out while working on this:

1. Structure matters more than ever
AI is only as good as the constraints you give it. Because the plan was explicit about architecture, modularization, and patterns, the output actually followed those guidelines surprisingly well.

2. This isn’t just “code generation”
It felt less like autocomplete and more like collaborating with an engineer who:

• understands high-level direction

• executes quickly

• occasionally needs correction

 

3. The role of the developer is shifting
Instead of writing everything line-by-line, the focus becomes:

• defining systems

• reviewing implementations

• fixing edge cases

• guiding iteration

 

🧩 Architecture at a Glance

Even though this was an experiment, I still wanted the app to follow a production-style structure:

• app → Compose UI, navigation, ViewModels

• core → Entities, use cases, repository interfaces

• core → IGDB + Twitch integration, repositories

• core → Room + DAOs

• core → Shared MVI contracts

• core → Shared utilities and bindings

 

The goal wasn’t just to make it work, but to make it scalable and maintainable.

🔐 Getting It Running

If you want to try it out, you’ll need IGDB access via Twitch:

1. Create a Twitch developer application

2. Add your credentials to a keys.properties file:

twitch.client.id=<YOUR_CLIENT_ID>
twitch.client.secret=<YOUR_CLIENT_SECRET>

More details here:
🔗 https://api-docs.igdb.com/#getting-started

🚀 Final Thoughts

This project ended up being less about the app itself and more about the process.

What stood out most was how effective AI can be when paired with:

• clear architecture

• strong constraints

• and a well-defined plan

 

It’s not replacing the developer, but it’s definitely changing how we build.

And honestly, it makes experimenting with new ideas a lot faster.

🔗 Check It Out

If you’re interested, you can find the project here:

https://github.com/huhx0015/GameCollection