Google Scrapped Gemini 3.5 Pro and Rebuilt It From Scratch — Here's Why That Matters for Every No-Code Builder
Google scrapped the original Gemini 3.5 Pro base model after enterprise testers found it couldn't handle recursive tool-calling, SVG generation, or maths — then rebuilt it from scratch with native computer use baked into the architecture. Here's what that means for no-code builders and why the platform layer matters more than ever.

Table of Contents
Tomorrow, Google DeepMind is expected to launch Gemini 3.5 Pro, a model so troubled during testing that the team scrapped the original architecture entirely and restarted pre-training from zero. Labs do not throw away completed base models lightly. But the three failure modes that triggered the rebuild — recursive tool-calling instability, broken SVG generation, and weak mathematical reasoning — happen to be exactly the capabilities no-code platforms and ops teams rely on when they stitch AI into internal tools.
The July 17 date comes from TechTimes reporting that traces the target to internal timelines. Google has not confirmed it. No model card exists. No pricing page is live. The Gemini API still lists 3.1 Pro Preview as the current Pro tier. Everything you are about to read about specs is reported, not official. That caveat matters, because this launch, if it lands, reshapes a field that has already absorbed four frontier model drops this month.
TL;DR: Google rebuilt Gemini 3.5 Pro from scratch after enterprise testers found it could not handle multi-step tool calls, complex visuals, or maths reliably. The rebuilt model reportedly packs a 2M-token context window and native computer-use baked into the architecture rather than bolted on afterwards. If the numbers hold, it is the largest production context window on the market and the first frontier model where agentic capability is part of the base model's DNA. For no-code builders and ops teams, that changes what is possible, and it makes the platform layer more important, not less.
What broke, and why Google started over
Vertex AI enterprise customers flagged three specific failures in the original 3.5 Pro, according to reporting from AIToolsRecap, HackerNoon, and Geeky Gadgets citing unnamed internal sources. The model could not maintain stability across recursive tool-calling chains. It could not generate complex SVG scenes reliably. And it underperformed on mathematical reasoning benchmarks.
The first one is the one that matters. Recursive tool-call stability is table stakes for any model calling itself agentic. If your AI gets lost three steps into a multi-tool workflow, you do not have an agent. You have a demo that breaks during the pitch meeting.
Sundar Pichai told developers at I/O 2026 in May to "give us until next month." June came and went. The rebuild explanation, scrapping the 2.5 Pro base and running a fresh pre-training cycle, is what filled the gap. This is not 2.5 Pro with a bigger context window. It is a different model, trained differently, with different priorities.
The rebuilt version, from leaked test information, has made particular progress on front-end generation: UI design taste, concise code output, and SVG vector construction. In game dev scenarios, it handles complex logic interactions stably. These are the things no-code builders actually care about. Not abstract reasoning benchmarks, but whether the model can generate a usable interface and keep its head through a multi-step workflow.
Native computer use: baked in, not bolted on
In June, Google shipped computer use as a built-in tool in Gemini 3.5 Flash. The model can click, type, scroll, and navigate desktop and web interfaces natively. It scored 78.4% on OSWorld, the agentic computer-use benchmark, ahead of Anthropic's Claude computer-use implementation and competitive with what OpenAI ships through Operator.
Now shift that capability to the Pro tier. Flash is fast but shallower, good for quick loops, not sustained reasoning. Pro should bring heavier compute to the same native computer-use primitives. That means an agent that can not only navigate your browser but reason about what it is seeing there, across a context window that holds the full history of everything it has done.
Compare this to how the other labs do it. Claude Computer Use runs inside a sandboxed VM and accesses the screen through screenshots. OpenAI Operator uses vision-based screen reading and is the slowest of the three for actual automation. Google built the capability into the model itself during pre-training rather than wrapping it in a runtime. That is not a feature. It is a design philosophy.
For no-code platforms that sit on top of these APIs, the implications are pretty clear. A model that natively understands UI interaction will be more reliable at filling forms, navigating dashboards, and interacting with the web apps your team builds. It reduces the translation tax, the gap between "I need this task done" and "the model understands how to do it in a browser."
The 2M-token context window
At 2 million tokens, Gemini 3.5 Pro would process roughly 1.5 million words in a single prompt: a full large codebase, a year of meeting transcripts, or a multi-volume research dataset. If it works reliably, it nearly doubles the next largest production window. GPT-5.6 Sol supports 1.05M tokens. Claude Fable 5 around 200K.
Context windows get exaggerated in leaks all the time. The honest question is not whether Google can advertise 2M tokens. It is whether the model reasons reliably across the full span. Long-context benchmarks like needle-in-a-haystack retrieval have historically flattered these numbers: models find a planted fact but degrade on tasks that require synthesis across the whole range. Gemini 2.5 Flash users reported token efficiency issues in extended workflows. That is the bar the Pro rebuild needs to clear.
For ops teams, a working 2M context window is not a gimmick. It means feeding an entire company wiki, a full database schema, and a year of customer support transcripts into a single prompt and getting coherent answers back. That turns an AI assistant from "helpful for quick questions" into actually useful for running operations.
Why the platform layer matters more, not less
Here is where I think platforms like Stacker, which abstract the model layer behind a permissions-aware, portal-based interface, get it right.
Every model launch produces the same dynamic: builders scramble to test the new thing, benchmark it against whatever they were using, and decide whether to migrate their workflows. Then another model drops a week later. In July alone we have had GPT-5.6 Sol, Terra, and Luna, then Grok 4.5, potentially Gemini 3.5 Pro and DeepSeek within eight days of each other. Nobody can properly evaluate a model in the time it takes for the next one to arrive.
Platforms that sit between the builder and the model absorb this churn. You do not need to care whether Gemini 3.5 Pro beats Fable 5 on SWE-bench Pro if your platform handles model selection for you. The platform's job becomes picking the right model for the right task: fast and cheap for simple operations, heavy reasoning for complex workflows, long-context for document-heavy use cases, and swapping them out as the frontier moves.
The value for most ops teams is not in chasing benchmark charts. It is in having a platform that translates "we need an approval workflow for purchase orders" into something that works, regardless of which lab had the best quarter.
What to watch on launch day
If Gemini 3.5 Pro lands tomorrow, here is what I will be checking.
First, the model card. Until Google publishes official benchmarks, every leaked number is noise. The SWE-bench Pro score tells you whether this competes with Sonnet 5 at 63.2% or approaches Fable 5 at 80.4% on agentic coding.
Second, recursive tool-calling. This was the failure that caused the rebuild. Build a five-step tool chain and run it ten times. If it loops or fails on any run, the rebuild did not fully solve the problem.
Third, long-context reasoning at 500K and 1M tokens. Not whether the API accepts a 2M prompt but whether reasoning quality holds at distance. Performance at 500K is more informative than the headline number.
Fourth, and the one I think matters most for no-code builders: how the model handles real UI interaction. Not benchmarks. Actual form-filling. Actual dashboard navigation. The gap between "scores well on OSWorld" and "can reliably fill in a 12-field customer onboarding form" is where most AI demos go to die.
If the date slips again, it is not a disaster. Every lab is shipping simultaneously right now. But a second delay after a full architecture rebuild would raise harder questions about whether Google DeepMind can execute at frontier pace, especially after four senior researchers left for Anthropic in late June.
Either way, the no-code builder's job does not change: build on platforms that abstract the model layer, test everything before you trust it, and never mistake a benchmark chart for a working product.
Want to read
more articles
like these?
Become a NoCode Member and get access to our community, discounts and - of course - our latest articles delivered straight to your inbox twice a month!



