Over the last year I've shipped more than ninety mobile apps to the App Store and Play Console, almost all of them built with heavy help from AI coding agents (Claude Code, mostly, with a mix of other tools along the way). That number sounds absurd until you understand what most of these apps actually are: small, focused utilities and niche games built by a team of one, not ninety separate startups with ninety roadmaps.
I want to write down what actually changed in my workflow, because most of the "AI coding agent" content I read online is either breathless hype or reflexive skepticism. The reality, at least for me, was messier and more useful than either extreme.
The first thing people assume is that AI agents are valuable because they type code faster than you. That's true, but it's not the interesting part. The interesting part is that a coding agent can hold an entire small app's context in working memory and act on it consistently — rename a variable across twelve files, update a schema and every place that touches it, or run a build, read the error, and fix it without you copy-pasting a stack trace into a chat window.
Once I stopped treating the agent as an autocomplete engine and started treating it as a junior engineer who never gets tired of grunt work, the portfolio approach became possible. A single person cannot manually maintain ninety codebases. A single person plus an agent that can be pointed at a repo and told "the build is broken, fix it" can.
Writing the app was never the bottleneck. App Store Connect and Google Play Console submissions were. Both platforms have dozens of small, easy-to-miss requirements that have nothing to do with whether your code works:
None of this shows up in a tutorial about building your first app. It only shows up after you've been rejected a few dozen times and started keeping a checklist. I eventually had the agent maintain that checklist as a literal pre-submission gate script, because I stopped trusting myself to remember eighteen rules across ninety apps.
The bugs that actually hurt were never the ones in business logic. They were things like: a retired ad SDK dependency left behind after a plugin was removed, causing a crash only on cold start on specific Android versions. Or a locale check that worked on every simulator I tested but returned the wrong result on real Japanese devices because the JS engine's Intl
implementation doesn't localize the way you'd expect.
What made agents genuinely useful here wasn't cleverness — it was persistence and breadth. I could ask an agent to scan all ninety repos for a specific anti-pattern (an unreferenced dependency, a hardcoded staging URL, a duplicate icon mismatch between the launcher and the store listing) and get a real answer in minutes instead of spending a weekend grepping by hand. The value compounds specifically because the portfolio is large — the same technique on three apps would just be "using find-and-replace with extra steps."
I want to be honest about the limits, because overclaiming here helps no one:
The honest summary is that AI coding agents didn't replace the parts of shipping software that require judgment. They replaced the parts that required patience: reading every line of a hundred-line diff, remembering which of ninety apps still uses a deprecated permission, re-running the same fifteen-step submission checklist without skipping step eleven because you're tired.
Two habits mattered more than any specific tool:
If you're exploring this space and want a more structured way to actually practice building with an AI coding agent rather than just reading about it, I've been collecting what I've learned into a small practical resource at AI Craft Campus — it's aimed at people who want to go from "I asked an AI to write some code" to "I run a small, working software portfolio with an AI agent doing the repetitive parts." It's a work in progress, same as the rest of this. Ninety apps is not a finish line, it's just where the counter happens to be right now. The workflow that got me here — small repos, aggressive automation of the boring parts, and a healthy distrust of "it built successfully" as a definition of done — is the part I'd actually recommend adopting, independent of which specific tool you use.