There's a thread going around where people ask various models for a random number between 1 and 30, and a suspicious number of them answer 17. DeepSeek, Doubao, Qwen, and the foreign models too, all landing on the same handful of "random-feeling" primes. It reads like a magic trick until one commenter pastes the actual explanation: they asked Gemini what happened, and it admitted it never ran anything. No Python sandbox configured, so it just imagined a plausible example output and handed back 17.
That one detail is the whole story, and it's worth more than the meme.
The model is pattern-matching, not computing
When a language model "generates a random number" without tools, it isn't sampling from a uniform distribution. It's predicting the token a human would most likely write after "a random number between 1 and 30," and human text is lopsided. Someone in the thread laid it out well: small numbers feel non-random, multiplication-table numbers feel too familiar, so the model drifts toward mid-range primes like 17, 19, 23. It's the same reason people reliably pick 37 when asked for a number under 100. The exact frequency of 17 across models is anecdotal and unverified, but the mechanism behind it is not mysterious at all.
The practical lesson for anyone building on top of these models: any task with a correct, computable answer must not be left to the model's imagination. Random numbers are the harmless demo. The dangerous version is the model confidently "calculating" a tax figure, a date difference, a sort order, or a spreadsheet total in its head and returning something that looks right.
You can see the same seam in the other threads. One person is trying to get a local agent to process xlsx files and running into format limits. Another is asking whether test-driven development is the better way to work with AI, writing the test cases first and letting the model fill in behavior. Both are circling the same instinct: stop trusting the narration, verify against something real.
What "real execution" actually means for a builder
The fix isn't a smarter model. It's architecture. You give the model a way to call out to code that genuinely runs, then you make it use that path instead of guessing. If the answer needs computing, compute it. If it needs a fact from a file, read the file. The model's job shrinks to deciding what to call and explaining the result, which is what it's actually good at.
This is squarely inside what VicroCode supports, and it's the kind of thing you can stand up as a small delivery rather than a platform project. The pieces map cleanly:
- Online Python execution handles the deterministic work. A `random.randint(1, 30)` call in real Python is genuinely uniform. A date diff is a date diff. A CSV rollup is arithmetic, not a vibe.
- API Endpoint Hosting and in-platform tool calls give the model a callable surface. You expose your Python function as an endpoint or a tool, and the agent invokes it instead of hallucinating the output.
- A hosted front end ties it together for whoever actually uses the thing.
So a concrete build looks like this. Write a handful of Python functions for the operations you refuse to let the model fake: generate a real random value, parse and total a CSV, compute a schedule. Publish those as tool-callable endpoints. Then do your AI agent development so the agent's system prompt is explicit: for anything numeric, dated, or countable, call the tool and report what came back, never invent it. Test-driven development fits naturally here, exactly like the thread suggested. Write the expected input/output pairs for each tool first, run them against the real Python, and you've got a regression net before the model is even in the loop.
A thin, honest demo you can actually ship
If you want to make the point vividly, build the anti-17 tool. A single-page app where a user asks for a random number, or a small calculation, and the app routes it through hosted Python and shows both the result and the fact that code executed. You can run HTML online for the interface and back it with the Python endpoint, so the whole thing lives in one place instead of being stitched across a laptop, a local agent, and a model that can't open a file.
Store the call log in a SQLite database if you want to show the distribution over many requests. Now you have a live counterexample: ask it a thousand times and you get an actual spread, not a thousand 17s. That's a demo that teaches the failure mode instead of just mocking it, and it doubles as a template for the real work, which is almost never "pick a number" and almost always "process this file correctly, every time."
Where the boundary sits
Be honest about scope with yourself and with whoever you're building for. The determinism you gain applies to whatever runs inside Python and the tools you actually wire up. The DeepSeek-and-Excel person wanting rich xlsx and multimodal handling, or the folks chasing specific hosted model entry points and relay endpoints, are describing needs outside this setup. Model availability here is whatever the Model Center already exposes, and the execution guarantee covers your Python and tool calls, not the model's reasoning quality on top of them. State that plainly rather than implying the architecture fixes everything.
But the core move holds. The "17" phenomenon isn't a bug in any one model; it's what you get when you ask a text predictor to do a computer's job. Give it a computer to call, insist that it call it, and test the calls. The magic trick stops being spooky and starts being a system you can trust.