cd /news/developer-tools/what-i-learned-switching-between-swi… · home topics developer-tools article
[ARTICLE · art-36310] src=dev.to ↗ pub= topic=developer-tools verified=true sentiment=· neutral

What I Learned Switching Between Swift and AI Studio in the Same Week

A developer who built a Swift tutorial series and a mascot generator app with Google AI Studio in the same week found that each workflow builds a different kind of understanding. Writing Swift line by line sharpens mechanical precision and the ability to explain exactly why code works, while using AI Studio provides a product/systems perspective by generating a fully working app from a single prompt. The developer notes that neither approach replaces the other and plans to adjust their workflow accordingly.

read4 min views1 publishedJun 22, 2026

This past week I did two very different kinds of "building." On one side: continuing my Swift series, writing functions, testing them in the playground, debugging small mistakes one at a time. On the other: describing an app to Google AI Studio in a paragraph and watching it generate a fully working, deployed web app in minutes.

Doing both in the same stretch of days made the differences between them really obvious — and a few things genuinely surprised me.

Writing Swift feels like a conversation with a very precise, very patient teacher who refuses to let you move on until you've gotten the current thing right.

A typical loop looks like:

return

Every single step is small. Every error is specific. And — this is the part that matters — every fix sharpens the explanation you'd give someone else. When I was working through parameter labels for the series and ran into the "extraneous duplicate parameter name" error on a test snippet, it wasn't just "fix this one function." It was a reminder of exactly why external vs internal parameter names trip people up — which is the kind of detail that makes the difference between an article that just states a rule and one that actually shows why the rule exists.

Building MascotCraft Studio with Google AI Studio felt completely different. I wrote one prompt describing what I wanted — a mascot generator using Imagen and Gemini, with style keyword input — and got back:

The entire thing took minutes. There was no step-by-step error-fixing loop — or rather, there was one (I hit a "Fix" button at one point that led to a paid API key prompt I had to dismiss), but it happened behind the scenes, at a scale I couldn't really follow even if I wanted to.

Here's the thing that surprised me most. Going through Swift snippets line by line — testing valid vs invalid examples for the parameter labels article — I could explain exactly what made each one work or fail, down to why Swift treats a single given name as both the external and internal label.

After MascotCraft Studio was done, I could explain what the app did. But I genuinely couldn't tell you why Gemini chose a localStorage-based gallery instead of some other persistence approach, or why it picked those specific color palette names. One of the commenters on my post about it pointed out that the localStorage approach would actually be a problem in a real product — saved mascots disappear if you switch browsers. That's a completely valid critique, and it's something that wasn't obvious from using the app, because the decision was made for me, invisibly, somewhere inside the generation process.

So: working through Swift line by line sharpens the kind of precise, "here's exactly why" understanding that makes for a good technical explanation. AI Studio gave me a different kind of picture entirely — what a finished product looks like, end to end. Those aren't the same kind of understanding, and I don't think one replaces the other.

My first instinct was to frame this as "slow but deep" vs. "fast but shallow," but that's not quite fair either. The AI Studio output wasn't shallow — the app genuinely worked, the bio Gemini wrote for Octo-Byte was creative and well-structured, and the deployment actually succeeded. It's more that the kind of understanding each workflow builds is different.

Working through Swift line by line builds mechanical precision — the kind of detail that lets you explain not just that something works, but exactly why, which matters a lot when the goal is teaching it to someone else.

Using AI Studio builds something more like product/systems perspective — seeing what a finished thing looks like, what kinds of features get bundled together, what a deployed app's structure looks like end-to-end, much faster than building that same picture by hand. A few small changes to how I'm approaching both going forward:

Has anyone else worked across two really different workflows like this in the same stretch of time? Curious whether the "different kind of learning" framing resonates, or if I'm overthinking a pretty fun week of building things. 🌸

── more in #developer-tools 4 stories · sorted by recency
── more on @swift 3 stories trending now
sponsored brought to you by zahid.host 4,200+ EU-deployed projects
reading about agents? ship yours in a single git push.

Run your AI side-project on zahid.host

EU-based hosting, git-push deploys, automatic HTTPS, no cold starts. Free tier with a custom domain — perfect for shipping the agent you just read about.

$git push zahid main
Live at https://your-agent.zahid.host
Get free account → Pricing
from €0/mo · no card required
LIVE [news/what-i-learned-switc…] indexed:0 read:4min 2026-06-22 ·