Google introduced Gemini 3.7 Flash just 23 days after 3.6 Flash, and 86 days after 3.5 Flash debuted at I/O. That is three workhorse Flash models in less than three months. While 3.5 Pro never arrived, Flash had to step up.
Three Flashes, three distinct jobs
- 3.5 Flash (May 19): The I/O statement. Frontier intelligence with action, outperforming older Pro models at high speeds across platforms.
- 3.6 Flash (July 21): The unit-economics patch. Optimized for tokens, latency, and tool-call waste, reducing output prices.
- 3.7 Flash (August 13): The completion-rate patch. Focused on algorithmic improvements to reasoning foundations, helping agents better adapt to roadblocks and multi-step planning.
The gains are where coding agents actually die
Google's 3.7 updates concentrate heavily on software engineering and multi-step workflows. We saw massive jumps in benchmarks like DeepSWE v1.1 (+16.3 pts) and FrontierCode 1.1 Main (+9.2 pts).
The expensive part of coding isn't the first-pass code that almost compiles—it's the fifth tool call that undoes the third, or the ambiguous instruction the model guessed instead of clarifying. Pull request review lives in this exact failure mode.
What this means for code review
Three Flash models in 12 weeks changes how we should approach AI-generated code review:
- Expect the workhorse to move: Your review stack should switch models as fast as Google ships them.
- Prefer models that finish the job: Look for long-horizon engineering capabilities over chat fluency.
- Watch retries, not list price: The cheaper review is the one that doesn't need a second pass to fix a hallucinated finding.
- Keep a human on the loop: Pair models with repository-level context when the real bug lives outside the diff hunk.
That is the job ThinkReview is built for: an AI code review copilot on GitHub, GitLab, Azure DevOps, and Bitbucket that goes beyond rubber-stamping PRs. Google just showed it can revise a production coding model three times in a summer. Your review workflow should keep up.
Pick your model in Model selection, run it on a real diff, and keep your engineering judgment.
Top comments (0)