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:
- Write a function
- Try to call it
- Get an error — maybe a parameter label mismatch, maybe a missing
return - Read the error
- Fix it
- Run it again
- 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. 🌸
Top comments (10)
Using both approaches side by side really highlights how AI is changing the development process. Rapid prototyping is impressive, but understanding the underlying logic through coding and debugging is still what helps build reliable, scalable products.
Exactly — rapid prototyping gets you to a working shape fast, but the "why does this work and where will it break" questions still need that deeper understanding to answer. The two approaches really do serve different purposes rather than one replacing the other. 🌸
This feels like the real AI coding skill: not prompting harder, but learning how to inspect the decisions the tool made while you weren’t looking.
The code running is step one. Knowing why it works is still the developer’s job.
"Inspect the decisions the tool made while you weren't looking" — that's such a precise way to put it. The gap between "it runs" and "I understand why it runs" is exactly where the risk lives, and closing that gap is still entirely on the developer. Really glad that came through in the post!
Hello
My Dear Gamya
I hope you are doing well
This comparison between Swift’s step-by-step debugging workflow and AI Studio’s rapid app generation is very insightful and highlights two very different but complementary ways of building software.
The Swift approach clearly strengthens deep technical understanding by forcing you to engage with every detail, error, and decision in a very explicit way.
In contrast, AI Studio offers a fast, end to end product perspective that helps you quickly see how full systems come together, even if some internal design choices remain abstract.
The reflection on understanding versus speed is particularly well balanced, since it shows that both workflows produce meaningful but different types of learning rather than one being superior to the other. Overall, it’s a thoughtful breakdown of how combining both approaches can lead to a more complete and practical development mindset.
Thank you! 😊 Hope you're doing well too! Really glad the "different types of learning rather than one being superior" framing came through — that was the core point I wanted to land, so it's great to hear it read that way. The two workflows genuinely do complement each other in a way I didn't expect until I'd done both back to back. Thanks as always!
The localStorage example is the perfect illustration of your whole point. It works, the demo looks finished, and the flaw only shows up when a real user switches browsers and their saved mascots vanish, which is exactly the kind of quiet decision that building line by line forces into the open. I like that you landed on reading through the generated code instead of just checking that it runs, because that habit is what lets you keep the speed without losing the "why." The two workflows aren't really speed versus depth, they're more like seeing the finished shape versus knowing why each piece holds.
"Seeing the finished shape versus knowing why each piece holds" — that's a much cleaner way to put the distinction than anything I landed on in the post itself. The localStorage example really is the whole argument in one concrete case: it passed every surface check, looked finished, and the flaw was completely invisible until you thought about what a real user would actually do with it. Reading through rather than just running it is the only way to catch that kind of quiet decision — and you're right that it's what lets you keep the speed without losing the understanding.
I've definitely run into similar problems. And I've intentionally pushed hard in the agentic direction. Not because I think that it's better today, but because I really do believe that it's the future. I've also learned that having the traditional coder skillset does not mean that you are automatically good at agentic coding. As you found from your experiment, Agents are not mind readers. And they struggle with understanding intent. From your prompt, the agent did not know that you wanted the persistence to move between browsers. However, if this had been part of the original prompt or design documentation, then you could have had that result. And this is one of the biggest things with agentic coding. You have to be explicit. Anytime you leave a detail up in the air, the agent will choose for you. It's like a coin flip. Sometimes the result is what you imagined, and sometimes the agent makes an equally viable choice, but it wasn't what you pictured in your head. Prompt Engineering is a skillset that today's devs have to master. And I think that when you combine that with all that a dev already knows about coding, then that's something special. Devs really are setup to be the strongest in this new future that we are all walking into. But they shouldn't assume that they are automatically great at agentic coding. It's a completely separate skillset.
"Anytime you leave a detail up in the air, the agent will choose for you — it's like a coin flip" is such a precise way to describe it. The localStorage example is exactly that: I never specified persistence requirements, so Gemini made a reasonable-sounding choice that happened to not fit the actual use case. The agent wasn't wrong, it just filled a gap I didn't know I'd left open.
The point about traditional coding skills not automatically translating to agentic coding is one I think gets underestimated — it's easy to assume fluency in one transfers to the other, but prompting for intent is genuinely a different muscle than writing implementation. Really appreciate this perspective!