← all posts
Feb 3, 2026

I Stress-Tested a few AI Coding Tool Building One App (Here’s What Actually Works)

I’m a Java developer. I wanted to test how good AI coding tools really are, so I chose unfamiliar territory: building an iOS app in Swift, a language I’d only touched through Objective-C years ago.

The challenge was personal. I’ve been tracking my finances in Excel for over a decade. Twenty-six sheets per year. Complex formulas, aggregations, charts. I wanted to see if Claude Code could help me convert this entire system into a proper iOS app.

I stuck with Claude Code's default model, Opus 4.5. What followed was three weeks of brilliant coding hamstrung by frustrating limitations, a scramble to free alternatives, and some genuine surprises about which AI models actually deliver when you’re shipping real software.

Here’s what I learned.

The Opus Experience: When It Works, It Really Works

Let me be clear upfront: Claude Opus 4.5 is exceptional at coding.

Starting with an empty repository, I described my Excel system. Monthly expense tracking, category breakdowns, payment method analysis, yearly summaries, recurring expense projections. Claude didn’t just translate requirements into code. It helped me architect the solution properly.

We had real conversations about product decisions. How do you make an app that competes with a decade-old spreadsheet habit? I proposed notification strategies for habit formation, Apple Watch integration for friction removal, offline-first architecture to keep financial data private and local. Claude helped me translate these ideas into working code, only the product vision was mine.

This wasn’t autocomplete on steroids. This was a thought partner that understood both the technical and behavioral aspects of what I was building.

The Swift code it generated was clean, well-structured, and properly tested. As someone learning Swift through this process, I could follow the patterns and understand the decisions. Opus handled view controllers, Core Data persistence, chart rendering, Watch connectivity. Complex stuff, done right.

The first week felt magical. Sessions ran 60–90 minutes. From empty repo to working app with transaction entry, list views, monthly breakdowns, category and payment method analysis.

Then reality hit.

The Quota Wall: When Brilliance Meets Business Model

Week two, my sessions started burning faster. About 40–45 minutes instead of an hour. My weekly Claude Pro quota tapped out on Thursday instead of Saturday.

Week four? The weekly limit was done by day three.

Here’s what happened: as my codebase grew, context grew with it. Claude needed more tokens just to understand what it was working with. And I wasn’t just generating code. I was running a proper development workflow.

Code reviewer agents checking Claude’s work. Test agents writing unit tests and UI tests for every feature. Though it might look wasteful, I thought it is smart engineering when working in an unfamiliar language. Comprehensive tests are my safety net. Code review catches gotchas I don’t have experience to spot.

But token-wise? Expensive.

Here’s the part that still frustrates me: sometimes asking Claude to commit and push code would consume 25% of my session quota. One prompt. “Commit and push the changes.” A quarter of my session burned on Git housekeeping.

I started committing and pushing manually just to conserve quota for actual coding.

Think about that. I’m paying for an AI coding assistant, but I’m rationing its use by handling Git operations myself. I’m optimizing not for productivity, but for token conservation.

Twenty hours of actual coding work stretched across three weeks. If I could have binged it, I’d have finished in a long weekend. Instead, I was losing days waiting for quota resets, losing context, ramping back up, making progress, hitting the wall again.

The tool worked brilliantly. The business model didn’t.

The Scramble: Free Tools to the Rescue

I couldn’t just stop. The app was halfway done, features were working. So during my Claude Pro downtime, I started exploring alternatives.

Antigravity became my regular fallback. Free tier, persistent session memory that kept context across sessions, and I could code for hours without hitting limits. Then I thought, why not build an Android version while I’m waiting for Claude Pro quota to reset?

So I did. The entire Android port using free tools:

I tested models I’d never seriously considered: Haiku, on Github Copilot, GPT-5, GPT-4.1 through Xcode Intelligence, Gemini Flash, Gemini Pro in various configurations.

Here’s what I found.

Model Comparisons: The Good, The Inconsistent, The Surprising

GPT-5: Impressive on paper, but it stumbled at key moments. Good for certain tasks, but I couldn’t rely on it as my primary tool. The inconsistency killed it for serious development.

Claude Opus 4.5: Best at ground-up architecture. When you’re starting from scratch with complex requirements, Opus thinks through the problem space better than anything else I tested. It considers edge cases, suggests patterns, and delivers clean structure. But the quota situation makes it impractical for sustained development.

Gemini Flash: The underdog that surprised me most.

Flash is supposed to be the lightweight model for simple tasks. Nobody takes it seriously for complex work. But I threw financial logic, investment tracking, and cross-platform development at it, and it just kept delivering.

It handled the entire Android port. It helped with iOS development. No drama, no quota walls, no throttling.

Here’s the honest caveat: Opus did the heavy lifting. It took my decade-old Excel system and architected a coherent iOS app from scratch. That’s the hard cognitive work. Flash came in after the problem was solved, replicating the logic in Android.

Porting from iOS to Android is real work (Swift to Kotlin, iOS UI patterns to Android patterns, CoreData to Room), but you’re translating an existing solution, not pioneering one.

Still, Flash proved something important: you don’t always need the premium model. For implementation work where the architecture is established, Flash delivered quality results without the quota drama.

GitHub Copilot: Solid and consistent in Android Studio and pretty much every other IDE out there today. Not as convenient as Claude, but reliable for day-to-day coding tasks. Good autocomplete, decent suggestions, no quota anxiety.

The Real Cost: It’s Not About Money

Here’s what frustrated me most about this experience. It’s not that Claude Pro costs money. It’s that paying for the service gave me worse access than free alternatives.

I was a paying customer who shipped my Android app on free tools while waiting for my paid quota to reset. That’s backwards.

The hidden cost of AI-assisted development isn’t the subscription fee. It’s the loss of flow state. Getting into a coding rhythm, making progress, then hitting an artificial wall that has nothing to do with the AI’s capability or your productivity. It’s about managing tokens instead of managing code.

And here’s the thing: if you’re doing serious development with proper testing and code review, you’re going to hit these walls constantly with Claude Pro. The pricing model seems designed for casual use, not for developers shipping production software.

What I’d Actually Recommend

After three weeks and testing nearly every major AI coding tool available, here’s my honest take:

For ground-up architecture and complex problem solving: Claude Opus is still the best. But be aware you’re getting limited access. Use it for the hard decisions, then switch to something else for implementation.

For sustained development work: Gemini Flash punches way above its weight class. If you have existing architecture and need to implement features, Flash delivers quality without quota drama.

For familiar language development: GitHub Copilot is reliable and consistent. Not as smart as Claude for architecture, but solid for day-to-day coding.

The workflow I arrived at: Plan and architect with Opus. Get the structure right, think through edge cases, establish patterns. Then switch to Sonnet for actual coding. This conserves Opus quota for where it actually matters — the hard thinking — and uses Sonnet for implementation.

I learned to be more deliberate with my sessions. Come in with a clear plan, get the architectural decisions made with Opus, then execute with Sonnet. Stop treating Opus like an always-on coding partner and start treating it like a senior architect you consult strategically.

The workflow I’d use today: Start with Claude Opus (or API access to avoid Pro quotas) for architecture and complex features. Switch to Gemini Flash or Sonnet or Copilot for implementation and iteration. Use proper version control yourself to avoid wasting tokens on Git operations. Cursor, Warp, Trae, Kiro, Kilocode, Windsurf, Void, any of these IDEs, aggregators, tools, choose your models wisely.

The real question: Is Claude Pro worth it for serious development? Not with current quotas. The tool is excellent, but the access model breaks down when you’re actually trying to ship software.

If you’re evaluating AI coding tools, don’t just test them on toy projects. Build something real. Run proper tests. Do code reviews. See what happens when your codebase grows and context accumulates. That’s when you’ll discover whether the tool and its pricing model actually work for how you develop.

The AI coding revolution is real. The business models are still confusing. Dance to the tune until you find your groove.