I Let Claude Write a Multiplayer Game. The Code Was Unreadable. And That’s the Point.

Last week, I decided to test the limits of vibe coding. I opened Claude, typed a vague prompt: “Make a simple multiplayer game in one HTML file.” Within seconds, it spat out nearly 4,000 lines of code. The game worked. I could see other players moving, the server syncing, the whole thing alive. But when I opened the file, I couldn’t read a single line. It was formatted like a ransom note—no indentation, inconsistent spacing, variables named a, b, c. Yet it ran flawlessly. That’s when the real realization hit me.

Code is no longer a message to humans. It’s a conversation between machines.

This isn’t a bug. It’s a feature. For years, we’ve been trained to write clean, readable code. We’ve preached that code is for humans first, computers second. But AI doesn’t care about your conventions. It cares about results. And the result is a functional, complex multiplayer game that no human could maintain—but that doesn’t matter, because the AI can regenerate it faster than you can debug it.

You’ve probably felt it too. That moment when you ask an AI assistant to write a function, and it returns something that works, but you stare at it for five minutes and still can’t trace the logic. You think, “I should refactor this.” But you don’t. Because it works. And the next time you need to change it, you’ll just ask the AI again.

This is the new normal. We’re entering an era where the bottleneck isn’t writing code—it’s auditing machine-generated artifacts. Developers are transitioning from craftsmen to system architects, from line-by-line authors to high-level directors. The code itself becomes a black box. And that’s deeply unsettling—and also incredibly powerful.

The developer’s job is no longer to write code. It’s to manage the black box.

Think about the implications. We’re building systems that we can’t fully understand. We’re deploying software that nobody can explain line by line. This is how we got the multiplayer game: a single HTML file, 4,000 lines, completely unreadable, yet fully functional. The game synced players, handled collisions, even had a chat system. All from a prompt that took 30 seconds to write.

But here’s the twist: the game’s code is terrible. It’s not scalable. It’s not maintainable. It’s not even pretty. And it doesn’t need to be. Because the AI can rewrite it in a heartbeat. The only thing that matters is whether the output works for the user. The human reader—the developer—is becoming an optional observer.

This is the moment where we have to decide: do we fight this, or do we embrace it? We can keep insisting on readability, on best practices, on code that a human can parse. Or we can accept that the purpose of code is shifting. It’s no longer a medium for human-to-human communication. It’s a machine-to-machine instruction set. And the humans are just the overseers.

My brother told me to post that game online. He said people would be impressed. And they were—but not for the reason I expected. The comments weren’t about the game’s features. They were about the horror of the code. “Impossible to read,” they said. “Terrible formatting.” But nobody said the game didn’t work. That’s the whole point.

We’re building a world where the code is invisible, but the results are undeniable.

Welcome to the future. It’s unreadable, it’s messy, and it works. And that’s exactly what we asked for.

FAQ

Q: Is unreadable code really acceptable in production?

A: Not yet. For critical systems, you still need human-readable, auditable code. But for prototypes, internal tools, or one-off projects, AI-generated messy code is already being shipped. The line is blurring fast.

Q: What's the practical implication for developers?

A: Learn to audit and test outputs rather than write them. The skill of the future is prompt engineering, system design, and quality assurance—not manual coding. The developer becomes a director, not a writer.

Q: Isn't this just a recipe for technical debt?

A: Yes, but the traditional notion of technical debt assumes code is static. If AI can refactor faster than humans can accumulate debt, the calculus changes. The real risk is losing the ability to understand your own systems—a dangerous trade-off for speed.

📎 Source: View Source