For months I’ve had a habit of talking through project ideas with Gemini on my phone — on breaks, walking around, whenever something is rattling around in my head. No code, no stakes, just thinking out loud.
What I started noticing after a while: Gemini would surface options I hadn’t considered — libraries I hadn’t heard of, architectural approaches that weren’t on my radar at all. When I’d later bring the same questions to Claude, it would give me solid answers, but often within a narrower frame. The options Claude presented were good; they just weren’t always the full picture.
That’s what eventually turned into a deliberate workflow. If the models think differently at the research stage, maybe that carries through to the whole development process. Turns out it does.
Why they’re different
Claude Sonnet is good at decisions and structure. Hand it research and ask it to pick an approach and write a plan — it does that well. But ask it to survey options cold and you often get three variations on the same thing at escalating complexity. It’s reasoning from what it already knows, not actually looking things up.
Gemini 3 presents genuinely distinct approaches with tradeoffs rather than variations on one answer. Where it’s weaker is making the call — ask “what should I use?” and you get something hedged and noncommittal. It’s a mapper, not a decider.
This isn’t a knock on either model — it’s just that they have different strengths at the research stage, and pretending otherwise means leaving value on the table.
What this looks like in practice
On a recent project — an open-source Electron app to replace Silhouette’s proprietary cutting machine software — I started with Gemini:
“My wife has a Silhouette Cameo cutting machine. I want to build an open-source Electron app to replace Silhouette’s proprietary software. Research available libraries for canvas/vector editing, USB device communication, and SVG path processing. Document the realistic options for each with tradeoffs. Output all research as markdown files in a docs/ folder.”
Gemini ran web searches, found the relevant libraries, and laid out genuine alternatives — Fabric.js vs. Konva for canvas, node-usb vs. node-hid for hardware communication, different approaches to SVG-to-cut-path conversion. This is what Gemini does well: survey the actual landscape rather than reasoning from what it already knows.
Then I brought that research into Claude Code and asked Claude Sonnet to make the calls:
“Review Gemini’s project research in docs/. Based on this, decide on the technology approach, then write a requirements document: what the app needs to do, user-facing requirements, and acceptance criteria for each feature. Focus on the what, not the how.”
Claude picked Fabric.js and node-usb, scoped the requirements clearly, and wrote acceptance criteria for each feature. That’s what Claude is good at — given a map, it navigates decisively.
Two rules that make this work
Don’t ask Gemini to decide. The moment you ask “what should I use?”, you get a hedged answer that buries the tradeoffs. Ask “what are the realistic options and their tradeoffs?” instead, then let Claude make the call.
Don’t ask Claude Sonnet to research cold. If you ask Claude Sonnet to survey available libraries for something, you often get a reasonable-sounding list that’s actually just variations on one approach. Gemini’s web search gives you the real landscape. Use it.
The division of labor is simple: Gemini maps, Claude decides. Each model doing what it’s actually good at.
I’ve implemented this workflow as a Claude Code skill — view it on GitHub.
This post is part of a series on multi-model AI workflows. The companion post covers how to structure sessions around token costs — cheap models generate, expensive models verify.
Have questions or want to share your own patterns? Find me on GitHub or LinkedIn.