AI for Android development: non-developer's experience

Non-Developer Builds and Maintains Android Apps Using AI: Mid-Project Analysis

A business analyst with zero coding experience launched two Android apps using only AI chat (Claude) and Android Studio. The human's role: defining tasks, testing, integrating changes, and deploying. AI handles code generation, error diagnosis, and architectural suggestions. The goal: test if this approach can sustain a real product with actual users, including bug fixes and new features.

The method evolved: from generating features from scratch to minimal diffs and fixes. AI tasks include context like symptoms, reproduction steps, constraints (no new libraries, data persistence), and error logs.

Tools and Workflow

Key components:

• Claude: code generation, build error analysis, suggestions for persistent storage and activity lifecycle.
• Android Studio: building, emulation, manual change integration.
• RuStore: publishing, gathering feedback, deploying updates.

Bug report format for AI:

• Symptom description and expected behavior.
• Reproduction steps.
• App version and constraints.
• Previous fix attempts with logs.

AI responds with: likely cause, files to check, 2–3 solution options with risks, then patches.

Results After Launch

Published apps:

• "168 Hours" — planner based on a 168-hour weekly budget.
• "F1 Tycoon" — simulator.

After the first article, downloads surged: "168 Hours" from 1 to 71, "F1 Tycoon" from 13 to 45. Real users surfaced bugs in untested scenarios.

Case 1: Timer reset on restart

Symptom: start timer → exit → return → reset to zero. AI solution: switch from storing elapsed time to start timestamp with recalculation. Fix took 2 hours (diagnosis + build + deploy). Issue stemmed from activity lifecycle and lack of persistent storage.

Case 2: Manual activity creation

Added feature: users input custom entities. AI proposed integration into data models, screens, and storage, with edge-case validation (empty fields, list updates).

Gained Understanding of Project Structure

Without deep syntax knowledge, an operational model emerged:

• Classes: separation of screens, models, storage.
• Data models: changes ripple across UI, persistence.
• State: main bug source — lifecycle, restarts, threads.
• Logic vs. data: screens handle UI, storage manages data.

This enables precise AI prompts, targeting system nodes.

Approach Limitations

Project integrity: AI generates local changes but misses dependencies. Humans own architecture.

Debugging: works for reproducible bugs (timers, state). Flaky issues (concurrency, device-specific) need logs and iterations.

UI/UX: functionality achieved, but ergonomics suffers without user metrics.

Maintenance: feedback as requirements, updates as separate processes with backward compatibility.

Boundary: viable for releases and fixes, but requires building baseline skills (lifecycle, state management).

Key Takeaways

• Real users (71+45 installs) exposed bugs, evolving from prototype to product.
• Fixes (timer, features) done in 2 hours with AI assistance.
• Human as integrator: tests, deploys, grasps structure.
• Limits: architecture and complex debugging on human.
• Trajectory: apps live and updating.

Development Plans

• Stabilize "168 Hours": test checklists, predictable timer states.
• Iterative features: within current architecture only.
• Baseline skills: lifecycle, diagnostics, structure.
• Next report on metrics (bugs, updates, trends).

— Editorial Team