Vibe Coding: The Great Trapeze Experiment

11 Jun, 2026

Is it possible to create a game all by yourself with no coding?

Artificial intelligence has become remarkably good at turning ideas into software. A growing movement known as vibe coding attempts to take advantage of that capability by replacing traditional programming with conversation. Rather than writing code line by line, users describe what they want, review the results, and iteratively refine the product through natural language instructions. Advocates argue that this approach democratizes software development by allowing people with little or no programming experience to build applications, games, and websites. Critics counter that software engineering remains more complicated than simply describing a vision. A recent experiment involving Grand Theft Auto 6 illustrates both the promise and the limitations of the approach.

The Grand Theft Auto 6 Challenge

Recently, Futurism reported on a developer who set out to build a Grand Theft Auto style game before Rockstar releases Grand Theft Auto 6. The project relied heavily on AI coding tools, particularly Claude, to generate much of the underlying software. At first glance, the effort appeared to support some of the more ambitious claims made by proponents of vibe coding. Within a relatively short period of time, the developer produced a functioning game environment that could be explored and modified.

The gap between a functioning prototype and a finished game, however, quickly became apparent. Grand Theft Auto is not simply a collection of software systems. It is a carefully constructed world containing narrative, art direction, mission design, animation, sound design, quality assurance, and thousands of creative decisions accumulated over many years. AI tools proved capable of generating code and assembling basic gameplay mechanics, but recreating the depth, coherence, and polish of a major commercial title remained well beyond reach.

Perhaps the most important lesson from the experiment is that implementation and design are not the same thing. Modern AI systems can generate working code at extraordinary speed. They can create menus, physics engines, user interfaces, and game mechanics in seconds. Yet they remain dependent upon human direction to determine what should be built, which features matter, what feels enjoyable, and when a result is good enough to ship. The challenge of software development may be shifting from execution toward direction.

That distinction reminds me of architecture. Few architects today draw entire buildings by hand. They use computer aided design software, structural simulations, rendering engines, and increasingly AI assisted design tools. Nobody concludes that the software designed the building. The architect still establishes the vision, balances tradeoffs, and makes the critical decisions. Vibe coding appears to be pushing software development in a similar direction.

The Great Trapeze demonstrates both the promise and limits of vibe coding. A playable game emerged in hours, but most effort went into tuning, testing, and deciding what felt fun. Elmer Yglesias, 2026.

Building The Great Trapeze: My Experiment

Inspired by these discussions, I decided to conduct a much smaller experiment to understand what is possible with vibe coding - I set out to quickly build a simple arcade game from concept to deployment called The Great Trapeze:

The concept was straightforward. A trapeze artist swings through a circus tent, releasing from one bar and attempting to catch the next. Successful catches increase the score. Missed catches send the performer tumbling into a safety net. The game would run entirely within a web browser and be simple enough to complete in a single afternoon.

What surprised me most was how quickly the project became playable. Working with Claude, I described the game mechanics in plain English. The AI generated the code, assembled the user interface, and produced a working prototype in roughly thirty minutes. A swinging trapeze, a score counter, a game over screen, and basic graphics appeared almost immediately.

At that point I assumed the hard work was finished. In reality, it had barely begun.

Looking back through the development log, the project evolved through more than twenty distinct stages. The sequence reveals something important about vibe coding: generating software was only the beginning. Most of the effort went into refinement.

Total: ~3 hours and roughly 25–30 iterations.

The time allocation tells a revealing story. Creating the first playable version consumed only about thirty minutes. More than twice that amount of time went into tuning the physics of a single jump. A game that works is relatively easy. A game that feels fair is much harder.

The flight of a single jump went through more revisions than anything else. First the swing did not convincingly communicate motion. Then the jump traveled too far. A request for a larger arc made the flight feel overly floaty, which led to another round of adjustments. Trapeze spacing had to be recalibrated repeatedly as the jump mechanics evolved. Later, a bug appeared that caused the performer to launch automatically, requiring a return to the intended rule that every release should be initiated by the player alone.

None of that involved writing code myself. All of it involved making decisions that only a player could make. Claude could generate ten variations in seconds. Determining which variation felt like a circus act rather than a physics demonstration remained a human responsibility.

An additional surprise involved testing. Every major physics adjustment was accompanied by simulation runs that verified the jumps remained catchable across the difficulty curve before the change was accepted. Traditional software development would place those checks inside test suites and development pipelines. In this case, the validation process occurred through conversation, analysis, and repeated verification. The quality assurance process remained; only the interface changed.

Additional features followed. What began as a simple safety net eventually became two clowns holding a circus blanket beneath the trapeze. Circus animals paraded through the background. A ringmaster appeared near the center of the tent. Music, score rankings, and visual polish gradually transformed the prototype into a complete game. By the end of the afternoon, The Great Trapeze had become a finished product rather than a technical demonstration.

The experience changed my perspective on what AI coding tools actually do. The technology dramatically reduced the cost of implementation. Features that once required hours of programming could be created in minutes. Yet responsibility for deciding which features belonged in the game never disappeared. If anything, that responsibility became more important. Before building The Great Trapeze, I assumed the difficult part would be getting a game on screen. Instead, the difficult part was deciding when it felt right. AI made implementation abundant. Human judgment remained scarce.

Supporters of vibe coding sometimes describe AI as replacing programmers. My experience suggests a different interpretation. The technology may be changing the nature of software creation rather than eliminating it. Coding knowledge remains valuable, particularly for large and complex projects. Yet many aspects of development increasingly resemble creative direction. The human role shifts toward defining goals, evaluating alternatives, establishing constraints, and deciding when something feels complete.

Conclusion: Could Vibe Coding Beat Grand Theft Auto 6?

The obvious question raised by both experiments is whether a determined developer armed with AI could actually beat Rockstar to market.

At first glance, the answer appears straightforward. Grand Theft Auto 6 represents one of the largest entertainment projects ever undertaken, involving thousands of developers, artists, writers, designers, and testers working across many years. A single person, even with AI assistance, seems unlikely to compete with that scale.

The Great Trapeze suggests a more complicated answer. Building the first playable version of the game took only about thirty minutes. Most of the remaining time was not spent creating software from scratch. It was spent refining, tuning, integrating, and deciding. Physics needed adjustment. Features needed prioritization. Visual elements needed balance. The challenge was not generating code. The challenge was making thousands of small decisions that collectively produced an enjoyable experience.

A developer attempting to build a GTA-style game today would almost certainly begin by emulating rather than inventing. Driving mechanics already exist. Open-world frameworks already exist. Inventory systems, mission structures, pathfinding, cameras, and physics engines have been built many times before. AI can increasingly assemble and adapt those components instead of requiring each one to be created from first principles.

That reality changes the calculation. The relevant question is no longer whether one person can generate enough code. The relevant question is how much of game development consists of assembling known patterns versus making creative decisions.

The Great Trapeze suggests that AI dramatically reduces the cost of creating the first eighty percent of a game. A playable prototype emerges quickly. The remaining twenty percent, however, contains much of the value. Tuning difficulty, balancing systems, creating memorable experiences, maintaining consistency, and knowing when something feels right remain stubbornly resistant to automation.

Could a single developer using AI beat Rockstar to a playable GTA-like game? Quite possibly. A rough imitation of the mechanics and structure might emerge far faster than many observers expect.

Could that same developer beat Rockstar to a better Grand Theft Auto 6? That is a far more difficult proposition.

The advantage of large studios may no longer be their ability to write code. Increasingly, their advantage may lie in their ability to coordinate millions of small creative decisions into a coherent whole. AI can accelerate implementation. It can accelerate iteration. What it has not yet demonstrated is the ability to replace the accumulated judgment required to transform a collection of features into a world that players remember years later.

The comparison to architecture returns once again. AI can serve as a drafting table, a simulator, and a construction assistant all at once. It can dramatically accelerate the path from idea to artifact. What it does not provide is the vision behind the artifact. Someone must still decide whether a game should feel like a circus, whether a jump is fair, and whether the finished result is worth sharing with others.

The Great Trapeze is a tiny game compared with Grand Theft Auto 6. Yet both point toward the same conclusion. Artificial intelligence is making software creation dramatically more accessible. The bottleneck has not disappeared. It has simply migrated. Increasingly, the scarce resource may not be programming skill, but the ability to recognize when the software in front of us has become something worth playing.

Further Reading

• The Great Trapeze (Game)
• Futurism, "AI Bro Claims He'll Build GTA 6 Before Rockstar"
• Andrej Karpathy, "Software Is Changing (Again)"
• GamesRadar, "GTA 6 Owner Says Generative AI Has Zero Part in What Rockstar Is Building"

--

#AIData #Observations