13 Claude Models, One Prompt, 14 Months: The Evolution of a 3D Game Website

A developer shared an experiment on Reddit that spanned 14 months: starting in July 2025, he fed every newly released Claude model the exact same prompt, asking it to generate a "3D game-style website with infinite procedural terrain and a camera that always moves forward," and recorded each model's real-time rendering result. The experiment covered 13 model versions, all using a brand-new conversation, zero manual edits, and relying solely on a single one-shot generation.

Experiment Design: One Yardstick Throughout

The value of this experiment lies in how thoroughly the variables were controlled. The same prompt, the same browser environment (real-time capture in Chrome), a brand-new session every time, and no human corrections allowed. The prompt itself carries clear complexity requirements: infinite procedural terrain, a continuously forward-moving camera, rich scene objects, shader rendering, stylized visual effects, and the endlessness of "scrolling forever."

This is effectively testing the model's comprehensive ability on a compound front-end task—it simultaneously involves 3D math, procedural generation algorithms, shader writing, performance optimization, and visual design. If any one link fails, the final image will expose the problem.

Shaders are small programs that run on the GPU and determine the final color and position of each pixel or vertex. In Web 3D scenes, shaders are usually written in GLSL and invoked through libraries such as WebGL or Three.js. Bugs like trees failing to render often stem from incorrect transformation matrices in the vertex shader, abnormal lighting calculations in the fragment shader, or missing geometry attribute bindings. Because shader code relies heavily on the GPU's parallel execution model, once some logic goes wrong, the symptom is usually an entire class of objects disappearing or colors going abnormal rather than a program crash—so these defects are very hard to spot in static code review and must be exposed by actually running the code.

Procedural generation refers to dynamically producing content with algorithms rather than hand-built models. In infinite-terrain scenes, a common approach is to combine noise functions (such as Perlin noise or Simplex noise) to generate a heightmap, then load and unload terrain meshes in chunks according to the camera position. The core challenges of this approach are ensuring seamless stitching between adjacent chunks, maintaining a constant frame rate, and making "infinity" show no sense of repetition visually. The model has to handle noise parameters, chunk scheduling, and LOD (level of detail) strategies all at once in a single generation, which places high demands on code organization ability.

13 Versions, a Visible Evolution Curve

The author attached a comparison chart in the post, with model version numbers on the horizontal axis, showing how the generated results changed across generations. He specifically noted that the tick marks in the chart only represent model numbers and no other metric.

From the experimenter's description, this evolution curve is not monotonically rising. One interesting detail: the version generated by Sonnet 5.5 actually had a shader bug—the trees could not render—but the author chose to keep it as-is without fixing it. This handling itself is more informative than the result: it shows that even newer models can still produce local rendering errors when generating a complex 3D scene in one shot, and that a model's "progress" does not equal "zero defects."

It should be emphasized that, because the original material did not disclose quantitative data such as the specific visual differences between versions, code quality, or runtime frame rates, this article makes no numerical claims about the magnitude of generational improvement. What is certain is that the author covered the complete iteration cycle of the Claude series from early to newer versions over a 14-month span. This kind of longitudinal comparison is not common in AI coding evaluations—most benchmarks are cross-sectional and static, whereas what is recorded here is the real evolution of the same task along a timeline.

Why "Same Prompt, Multiple Generations" Testing Is More Convincing Than Benchmark Scores

Conventional code benchmarks usually give pass rates or similarity scores, but such metrics can hardly reflect a model's actual performance on open-ended creative programming tasks. A model that can write correct syntax but cannot render trees may score high in unit tests, yet be unacceptable in the eyes of users.

The lesson of this experiment is: evaluating generative 3D content requires looking at the final image. Whether the procedural terrain is truly infinite, whether camera motion is smooth, whether shaders take effect, and whether scene density is reasonable can only be verified by actually running it. The author chose to capture each version in real time in Chrome precisely to anchor the evaluation on a "runnable artifact" rather than "code text."

Another noteworthy point is the one-shot constraint. Allowing repeated retries would mask differences in model stability—some models produce usable results on the first try, while others need multiple rounds of patching. Giving only one chance tests first-shot generation quality, which is closer to the experience of real users in the rapid prototyping stage.

One-shot in the context of AI coding means the model directly outputs complete runnable code based on a single prompt, without any follow-up questions, error correction, or iteration. The opposite is multi-turn conversational development, where the user gradually points out errors and asks the model to fix them. The value of one-shot evaluation lies in measuring a model's "first-shot generation quality" and completeness of instruction following, because real users in the rapid prototyping stage often want usable results in one go. But its limitations are also obvious: a single failure may just be random sampling fluctuation rather than the capability ceiling, so it is suitable for qualitative comparison and should not be directly converted into a pass-rate score.

Practical Reference Value for Developers

If you are using Claude series models for 3D or creative front-end development, this experiment provides several actionable criteria for judgment.

First, for complex 3D scenes, step-by-step generation is still recommended. Even newer versions can produce local failures when outputting a complete shader pipeline in one go (such as the tree rendering problem in Sonnet 5.5). Breaking terrain generation, object placement, and shader logic into separate steps is safer than betting on one success.

Second, the benefits of model version upgrades need to be evaluated by task type. This experiment covers only one type of task—procedural 3D websites—and cannot be directly extrapolated to back-end logic or data processing scenarios. The author did not publish specific details of the differences between versions, so it is impossible to determine which capability dimensions improved most noticeably.

Third, keeping failure samples has diagnostic value. The author did not fix the bug in Sonnet 5.5 but showed it as-is. This approach makes the comparison more honest: every point on the evolution curve is the model's real output, not a manually beautified result.

Boundaries of the Experiment

It must be pointed out that this experiment is a single case, a single prompt, and a single evaluator. The differences in results across 13 model versions may be affected by prompt wording, browser environment, or even the service state at generation time. The author did not disclose the specific performance details of each version, so it is better suited as a qualitative reference than as a strict benchmark ranking.

But its direction deserves recognition: using a long-timespan same-prompt test, it turns "model evolution" from an abstract promotional phrase into a sequence of images that can be viewed with one's own eyes. For those following the evolution of AI coding capabilities, this is more intuitive than any leaderboard.

(Music information: the author used Kevin MacLeod's "Raving Energy," under the CC BY 4.0 license.)