Vetting AI Studio's Native Android Code Before It Reaches Your Live App

Make the pre-merge gate act only on the diff

The first defense is static analysis. But running Detekt over the whole app buries the generated-code issues under existing warnings. So apply a stricter ruleset to only the files in this import.

// detekt-generated.yml — strict profile for imported generated code
complexity:
  LongMethod:
    threshold: 40
  TooManyFunctions:
    thresholdInClasses: 12
potential-bugs:
  Deprecation:
    active: true
performance:
  SpreadOperator:
    active: true
style:
  ForbiddenComment:
    comments: ['TODO', 'FIXME', 'STOPSHIP']

Narrow the run to changed files with a shell wrapper.

#!/usr/bin/env bash
set -euo pipefail
# only the .kt files changed on the import branch
CHANGED=$(git diff --name-only origin/main...HEAD -- '*.kt')
if [ -z "$CHANGED" ]; then echo "nothing to check"; exit 0; fi
 
# run the generated-only profile against changed files only
echo "$CHANGED" | xargs detekt \
  --config detekt-generated.yml \
  --fail-on-issues \
  --report txt:build/detekt-generated.txt
echo "✅ diff-only static analysis passed"

The three-dot origin/main...HEAD gives you only what changed since the branch point. Narrowing to the diff rather than scanning everything is the key; it alone surfaces almost all the noise specific to generated code.

Lifecycle and leaks need more than a machine

Static analysis catches shape-fixed problems like main-thread I/O, but it cannot fully catch the design question of "this way of holding state will not survive recreation." That part assumes a human reviewer, so fix the lens they look through.

The four points I always check:

1. Does state that must survive rotation live somewhere recreation-proof (a ViewModel, etc.)?
2. Is anything I pass a Context to shorter-lived than the screen?
3. Is each coroutine's scope tied to the screen's lifetime and reliably canceled on exit?
4. Does it bypass the existing base class or shared navigation with its own implementation?

Fixing the lens to four points turned generated-code review from "read it and see" into "knock down these four in order," and misses dropped.

Do not land 5,000 lines at once

The thing that helped most was not technique but how I imported. Vibe coding generates groups of screens, but landing them as one big change makes both review and rollback heavy all at once.

1. Split the output along feature boundaries (settings, list, detail...)
2. Branch one feature at a time and pass the pre-merge gate
3. Pass the human four-point review
4. Ship one feature to production; watch crash rate and memory for 2-3 days
5. If nothing's wrong, move to the next feature

In my case I landed the generated settings screen as the first feature, confirmed the crash rate was no different from usual, and only then moved on. Staging it means that if a problem appears, the cause is confined to one feature, so isolation is fast. Land it all at once and destabilize the whole thing, and just figuring out which generated piece is at fault can melt days.

Where to delegate and where a human takes over

Finally, a decision table. Vibe coding is fast, but it blurs where responsibility sits, so drawing the line up front saves hesitation.

Get pulled along by the speed of generation and hand even those last two rows to a machine, and a live app is hard to walk back. Use generation freely; lock down the vetting with a static gate, the four points, and staged rollout. That combination is the approach I actually use in my own indie development now. I hope it helps steady your footing if you want to bring this new generation experience into production.