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 unlock wasn’t code generation
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.
Store submissions are where the real complexity lives
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:
- A subscription app needs an EULA link in its description, or it gets auto-rejected by a script before a human ever looks at it.
- Free trials that are only configured for some territories will pass review in one region and throw a purchase error in another.
- Deleting an app record on App Store Connect doesn’t free up the bundle ID — it’s reserved permanently, which matters a lot when you’re iterating fast.
- Google Play’s classifier will flag things like “reads Android system logs” language even when the underlying permission usage is completely benign, and the appeal path is not obvious.
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.
Agents are excellent at finding the boring bug you’d never look for
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.”
Where I still don’t trust the agent alone
I want to be honest about the limits, because overclaiming here helps no one:
- Anything involving real money — in-app purchase configuration, subscription pricing, Stripe webhooks — gets a manual review pass every time. Agents are good at pattern-matching prior mistakes, not at catching a wrong price point unless you tell them exactly what to check.
- Destructive operations (force pushes, database migrations, deleting review-blocking records) are never delegated fully. I treat “the agent proposes, I approve” as a hard rule for anything irreversible.
- Long-running or flaky external processes — a build that intermittently fails because of a shared temp directory, or a CDN cache that lies about propagation — still need a human to notice the pattern isn’t random.
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.
What actually made this sustainable
Two habits mattered more than any specific tool:
- Writing down failure modes as I hit them, in plain files the agent could read back later, rather than trusting memory. The second time a submission failed for the same reason, that was a process bug, not a one-off.
- Treating verification as non-negotiable. An agent reporting “build succeeded” is not proof of anything except that a compiler didn’t complain. I learned to require an actual artifact check — did the binary get uploaded, does the store listing reflect it, does the app open — before calling anything done.
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.
답글 남기기