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

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.

Workflow 1: Swift, Line by Line

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:

1. Write a function


2. Try to call it


3. Get an error — maybe a parameter label mismatch, maybe a missing return
   


4. Read the error


5. Fix it


6. Run it again


7. See the output, confirm it's what you expected

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.

Workflow 2: AI Studio, Paragraph In, App Out

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:

• A full UI with a "Character Designer" section


• Color palette options I never asked for


• Multiple art style choices


• A "Studio Gallery Showcase" feature, also not requested


• A deployed, working web app

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.

The Biggest Difference: What You Actually Learn

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.

Speed vs. Understanding Isn't Quite the Right Framing

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.

What I'm Taking Forward

A few small changes to how I'm approaching both going forward:

• When I use AI-generated output (like the AI Studio app), I'm trying to actually read through what it produced, not just check that it works — partly inspired by that localStorage comment. Even if I didn't write it, understanding it seems worth the time, especially before referencing it in something I publish.


• Going through code line by line — even code I already know well — keeps the explanations I write sharp and specific, rather than relying on "this generally works this way."


• I don't think these workflows compete with each other. If anything, having spent a week doing both back to back, the AI Studio experience gave me a much faster sense of what a finished product looks like end-to-end, which is a useful perspective alongside the detail-level precision the Swift series requires.

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. 🌸