Gemini 3.5 Flash: A coding workflow that survives the demo
Fine, but none of that tells you what happens once the model has to open a file it's never seen and fix something broken. Gemini 3.5 Flash is unremarkable in the way that matters: a stable model per Google, pointed at the general-availability Interactions API, fast and multimodal for high-volume tool work. Recheck the docs before shipping gemini-3.5-flash; aliases and prices move. None of that decides anything: what matters is the outcome on the repositories your team maintains.
Greenfield prompts lie to you
Decide what counts as a win before the first prompt: a schema-valid record for extraction, a patch that passes tests and survives review for coding, a claim set traceable to a source for research. Fluency isn't on that list. Build a fixture set from the bug fixes, refactors, tests, and unfamiliar-code questions your team handles, run it under identical tool permissions, and keep the whole request intact: instructions, tool schemas, files, sampling settings. Hand one harness native tools, another pasted terminal output, and the same model produces two winners: the gap is the harness.
The costly mistake is judging coding ability from an isolated greenfield prompt that never opens a codebase or repairs a broken test. Frontier output reads fluently enough that this is hard to catch. Measure what code can verify, get reviewers to name the defect, and keep the wrong answers: they're worth more than a folder of wins. Long context deserves more suspicion, not less: capacity doesn't erase prefill time, retrieval noise, or the need to separate your instructions from a document's. Put a stable prefix first for caching, keep volatile metadata off the boundary, and send a checkpoint instead of full history when one will do; that same restraint applies to the output, more in long-context workflows.
Config, not vibes, picks the model
Better function selection from the provider doesn't change what your application owes you: validated arguments, an authorized caller, capped side effects, deduped requests, a record of what happened, because a tool result is data, not an instruction, and a sharper model is no substitute for a narrower interface. Put the rule in configuration, not in memory of what's fashionable this month: route by the recorded repository outcome, require tests plus a human-readable diff, and log model identity, phase timings, token categories, and eval results, without keeping sensitive prompt content. Keep a cheap lane for routine work and a real escalation trigger for hard cases: the strongest model earns its keep where needed, and a bargain tier stops paying once retries eat the savings.
Treat migration as ordinary operations: pin dated versions where stability matters, watch deprecation notices, canary an alias before it takes all your traffic, keep a known-good fallback, and re-run the evaluation set whenever the model or tool contract changes under you, a discipline I'd apply to anything on the coding-tools list.
None of this crowns a winner. It tells you what the model does reliably, what that costs, and when the router should reach for something else, assuming your fixture set looks like the work you do, not just the bugs easy enough to test.