ANTIGRAVITY LABJP
Articles/App Development
App Development/2026-06-24Advanced

The Day Generation, Device, and Internal-Test Shipping Became One Step — What I Refused to Hand Over

AI Studio now turns a text prompt into a Kotlin/Compose app and carries it through the emulator, a real device, and Google Play's internal test track from one screen. Behind that convenience sits a question: how much of the moment of shipping do you hand to the machine, and what do you keep in your own hands? Here is where I draw the line as a solo developer running several apps, and the implementation that holds that boundary.

AI Studio5Antigravity328Android26Google Play6app-dev49

Premium Article

I still hold my breath at the moment of shipping. Code can be fixed later. A crash, a review note, a clumsy store description — all of those can be rolled back the instant I notice them. But the fact that "this reached tens of thousands of people on the production track" cannot be undone once I press the button. As a solo developer juggling several apps, this is the one point that never feels lighter, no matter how far automation goes.

On June 24, 2026, Google AI Studio began generating Kotlin and Jetpack Compose apps from a text prompt, running them in an embedded emulator, pushing them to a real device over USB, and shipping them to Google Play's internal test track — all from a single screen. The distance between "build it, try it, ship it" collapsed at once. I welcomed the update, and at the same time I set myself one question: when everything connects this smoothly, unless I decide in advance where to stop, I will lose the ability to stop at all.

This article is about that line — where I let the machine carry the work and where I keep my own hands on it as I slot this end-to-end flow into a solo developer's shipping pipeline — and about the implementation that holds the boundary.

What became one step was the chaining of reversible work

The first thing worth seeing clearly is what distance AI Studio actually shortened. Generation, emulator runs, device transfer, internal-test shipping. Every one of those is reversible work. You can regenerate, you can relaunch the emulator endlessly, you can overwrite the install on the device. Even shipping to the internal test track only reaches the people you invited — yourself and a handful of testers — so a mistake stays contained.

In other words, what got chained into one screen was the connection of reversible steps. That is where the real convenience lives: the cost of bouncing back and forth through reversible work dropped to nearly zero. On my own side, redesigning the settings screen of a wallpaper app and then looking at it on a real device — a loop I would repeat — grew to a dozen-plus rounds in a single night. Before, my concentration broke at each step of waiting for a build, plugging in the cable, and waiting for the install.

The catch is that this smoothness makes the irreversible step look continuous with everything before it. After internal testing come closed testing, open testing, and then production. The same screen and the same feel carry through, and only the final push changes its nature. The first thing I decided was to build a deliberate step at that change of nature.

What I automate, and what I keep in my hands

The rule for drawing the line is simple. If it can be redone, give it to the machine; if there is no way back, keep it in your own hands. Applied step by step, the work split out like this.

StepNatureOwnerWhy
Code generation / editsReversibleAI StudioRegenerate anytime; diffs tracked in git
Emulator checkReversibleAutomatedScreenshot diffs of key screens are machine-judgeable
Device transferReversibleAutomatedOverwrite install; damage stays on my device
Pre-ship sanity checkReversibleAutomated (contract)Version, signing, mapping integrity are sure things for a machine
Ship to internal testNearly reversibleAutomated + approvalOnly invitees; but recorded in the ledger
Promote to productionIrreversibleMy own handsReaches the public. This is the one button I do not press from a script

What I want to emphasize is placing "ship to internal test" between automated and approval. Internal testing is nearly reversible in nature, but if I made it fully automatic, the psychological step between it and promotion to production would vanish. I deliberately left a small piece of friction on internal-test shipping: writing a one-line commit message. By leaving, in my own words, what the shipment is for, I can later recall what I actually verified when I move on to closed or production.

Thank you for reading this far.

Continue Reading

What follows includes implementation code, benchmarks, and practical content we hope you'll find useful. This site runs without ads — server and development costs are supported entirely by members like you. If it's been helpful, we'd be truly grateful for your support.

WHAT YOU'LL LEARN
A way to split the pipeline from generation to internal-test shipping into reversible and irreversible steps, and draw the line of automation there
Handing a build to the internal test track via the Play Developer API, plus a contract-style pre-ship sanity check
A release ledger that keeps you owning generated code, and a pattern for running staged rollout safely on your own
Secure payment via Stripe · Cancel anytime

Unlock This Article

Get full access to the rest of this article. Buy once, read anytime. This site is ad-free — your support goes directly toward keeping it running.

or
Unlock all articles with Membership →
Share

Thank You for Reading

Antigravity Lab is ad-free, supported entirely by members like you. We publish practical guides daily with implementation code, benchmarks, and production-ready patterns. If you've found it useful, we'd love to have you on board.

  • Copy-paste ready implementation code
  • New advanced guides published daily
  • $5/mo or $10 for lifetime access
View Membership →

Related Articles

App Dev2026-06-26
Hand Over Generation and Shipping, but Never the Signing Key — Designing Key Custody and Handover for an AI-Driven Pipeline
Even in an era where AI Studio and Antigravity take over everything from generation to internal-test shipping, the app signing key is in a class of its own. Lose it, and that app can never be updated again. As a solo developer who has run several apps for years, here is how I design key custody — separating the upload key from the app signing key, storing it, and planning the handover for the worst case.
App Dev2026-06-26
Green in the Embedded Emulator, Broken on the First Real Device — Putting a Parity Gate on AI-Generated Compose Apps
AI Studio now generates Kotlin/Compose apps from a prompt, runs them in an embedded emulator, and pushes them to a real device over USB — all from one screen. Yet a screen that passed in the emulator can break the first time it lands on a real phone. As a solo developer running several apps, here is how I put a gate that catches device parity issues before they ship.
App Dev2026-06-25
When an AI Studio App Won't Install on My Phone Because the Signatures Don't Match
You generate a Kotlin/Compose app in AI Studio, push it to a real device over USB, and the install dies with INSTALL_FAILED_UPDATE_INCOMPATIBLE. Here is why a debug-signed build can't overwrite your Play release, and how to test it without losing your production app.
📚RECOMMENDED BOOKS
Build a Large Language Model (From Scratch)
Sebastian Raschka
LLM Dev
Prompt Engineering for LLMs
Berryman & Ziegler
Prompting
AI Engineering
Chip Huyen
AI Eng
* Contains affiliate links
See all →