I'm Masaki Hirokawa — an artist and solo app developer, and the person running Gemini Lab.
It's been about three weeks since Gemini 3.2 became available, and I've been using it as my primary model for most daily work. Every time a new model drops, I feel two things at once: genuine curiosity to try it, and mild dread about having to rewire my workflow again. This time, the dread turned out to be mostly unwarranted — and that surprised me.
Benchmarks and detailed API guides are already well-covered elsewhere on this site. Today I want to write something different: an honest log from someone who uses this model every single day to build iOS and Android apps.
The Biggest Surprise: The Weight Shifted
The first thing that genuinely caught me off guard was how code review responses changed.
With previous models, asking "what should I improve in this Swift code?" would typically return 10–15 bullet points. Accurate, sure — but the sheer volume meant I had to do a second round of prioritization myself. The model gave me knowledge; it didn't reduce my decision-making load.
Gemini 3.2 started doing something different with the same prompt: "Fix this one thing first. The rest can wait." My instinct was to think it was being lazy. But when I followed the instruction and made that single change, the code got cleaner, and the next issue became obvious on its own. The volume didn't change — the weight of the response shifted. That's the best way I can describe it.
I should note this isn't consistent. When I'm in a "show me everything, I'll sort it out" mode, getting a focused response can feel incomplete. It depends a lot on where my head is that day.
Asking "Why" Started Feeling Different
As a solo developer, I'm often less interested in the finished code than in understanding why it should be written a certain way. "What does this do" is easy. "Why not the other way?" is harder to get a useful answer to.
With earlier models, I'd often get responses like "this is the recommended approach" or "it's better for performance." Accurate, but general — I'd feel like I was reading documentation rather than talking about my code. Pushing further would get me a list of alternatives, which is useful but still generic.
With 3.2, I've noticed more responses that start from my specific code: "The reason this approach fits is that in your implementation, you have X constraint, and this design accounts for that by..." It feels less like a reference lookup and more like a conversation about the thing I actually built.
I say "more" deliberately, not "always." When I paste a long file, the responses can drift back toward general best practices. How 3.2 handles long context still doesn't feel fully settled to me.
What I Still Can't Quite Figure Out
After three weeks, there are a few things I genuinely don't have answers to yet.
Temperature behavior feels slightly different
With temperature=0.3, some recurring tasks I'd been running on 3.1 seem to have a bit more variance on 3.2. Not dramatically — and honestly it might just be noise, since I haven't run enough samples to say anything statistical. I'd need 50+ runs to confirm or deny it. If you've noticed something similar, I'd genuinely like to hear about it.
When to use 3.1 Pro vs. 3.2
Three weeks in, I still haven't fully settled on when to use which. My rough sense is that 3.1 Pro is more predictable — especially when I need structured output in a fixed format. 3.2 has what I'd call a "creative interpretation" tendency: it sometimes produces something better than what I described, and sometimes something that's technically different from what I asked for. I don't know yet which situations reliably produce which outcome.
How I'm Using Models Right Now (May 2026 Edition)
For context, here's my current setup. This will probably look different in a month.
Morning info triage → Gemini 2.5 Flash Speed-first. I dump 3–5 bookmarked articles, ask for 3-line summaries each, and skim while coffee is still hot. My brain isn't really online yet, and Flash matches that pace.
Main implementation sessions → Gemini 3.2 New features, refactoring, design decisions. It works best when context is fresh — I get better results in focused 1–2 hour sessions than marathon conversations.
Debugging and reading existing code → Gemini 3.1 Pro Long files, "explain this function's intent," "trace why this behaves this way" — 3.1 Pro still feels more reliable here. It's like taking a road I know rather than a shortcut I haven't fully mapped yet.
Writing: docs, notes, release text → 3.2 or 2.5 Pro Japanese long-form feels noticeably better in 3.2. For English README files and release notes, 2.5 Pro still works fine and I haven't switched it.
Heading into Google I/O 2026
We're a few weeks away from Google I/O, which I'll be watching live as always. But I find myself feeling something slightly different this year.
More than raw capability improvements, what I actually want is predictability — a stable enough mental model of what to expect from 3.2 in different situations. Right now, I've only been using it for three weeks. I'd like to settle in before the next model arrives and asks me to start over.
That said: I'll be watching the keynote, and whatever they announce, I'll write about it here afterward. Some things don't change.
If your experience with Gemini 3.2 looks different from mine, I'd genuinely love to hear it. The way people use these models varies enormously, and reading someone else's honest observations is usually more useful to me than any benchmark. Find me on X (@dolice) or leave a comment — I read everything.