Technology waves swell, crest, break onto shore, and then, some time later, mobile developers show up, board in hand. I committed to using Cursor exclusively for a week as my daily driver editor. A week provides hardly enough time to consider replacing Android Studio, but it's long enough to learn something. And while I do not need to replace Android Studio, these days I find myself looking for alternative ways to work "in-between builds" or "in-between syncs" — familiar phrases working in a large code base.

Vibes are in, and as such, I didn't set any goals for this commitment. But, a few days in, you quickly identify what you gain, what you miss, and what you cannot do without.

Gains

Cursor foremost brings more time back into my hands. There is no syncing, no sluggish context actions, and no time spent wondering why one line of code shows as red even though I know the code compiles. In a week, the time saved was only on the order of seconds and minutes, but I see potential for this to improve with the use of Cursor project rules. Project rules provide a low-overhead way to improve Cursor's usefulness in your code base without needing the overhead of developing an MCP. For example, in a short .mdc file I was able to improve Cursor's ability to find feature flags, and even launch emulators.

---
description: A rule to start, shutdown, and manage Android emulators.
globs: 
alwaysApply: false
---

# Android Emulators

Use this rule to manage Android emulators in Cursor. Read the documentation [here](https://developer.android.com/studio/run/emulator-commandline) to help service requests.

## Example

> Launch my pixel emulator

Natural Language IDE

The emulator project rule is a prime example of why I am motivated to continue using Cursor ­— now, if I need to build a domain-specific workflow that would previously require a bash script, Gradle plugin, lint rule, or perhaps a well-worded document, I can enshrine the behavior in a project rule. The workflow is then available to all developers after a pull request. I see plenty of opportunities for this, ranging from scaling best practices to a large team or generating higher-quality code itself.

Missed

For all the time I had to use Cursor chat and write code, I missed the quick, but safe feedback loop that an IntelliJ IDE provides — namely, being able to write code and see whether I am staying in the bounds of compilable code or not. It is surprising how much this safety improves your confidence. Without it, I found myself building more to avoid fixing dozens of compiler errors when I felt I reached a good stopping point in my task.

Need

You don't know what you have until it's gone, and while I tried to do my best with strategic code searching and logs, here is what I can't do without.

• Find Usages
• Go to Implementation
• Debugging
• Breakpoints and, more specifically, non-suspending breakpoints with logs

Using Cursor was destined to end with me returning to Android Studio—I am just too dependent on the IntelliJ feature set, plugins, and first-class mobile support. However, I see the upside, and I am committed to using Cursor alongside Android Studio for conversational read-only tasks with the code base. And, perhaps more 🚀