The X-COM Effect

Declarative coding and when building software with AI feels like playing a game.

Source: Wikipedia

Back in the 1990s, one of my favorite video games was X-COM: UFO Defense (the European title is the one shown in the image above). It was an innovative video game that won accolades and left an impression on me. Every now and then, I feel the urge to play it again. It’s available on Steam, but somehow I never quite get around to revisiting it there.

Rebuilding X-COM With Agentic AI

Then along came agentic AIs.

Suddenly, I found myself, at various times, asking Claude Code to generate versions of X-COM and experimenting with a handful of homegrown reinterpretations. None of them are anywhere near as complete or polished as the original DOS classic. Mostly because I keep abandoning each version as soon as a new idea appears, and I feel compelled to try a different twist.

Which, honestly, is the point.

The agentic AIs make it absurdly easy to generate many kinds of working software, and that changes the psychology of building things. I keep wanting to explore: What if the UI worked like this? What if the mechanics leaned that way? What if X-COM were text-based, procedural, or logic-driven? In this way, building the game becomes part of the game experience.

I usually slot these X-COM experiments into the gaps in my logic-programming sessions (a Claude Code concept). My logic-programming stuff gets priority, but there is always a little time left over at the end. That’s where X-COM lives for me—a creative interlude. Spare cycles? Run experiments.

Recently, I’ve noticed more people articulating something similar: the real advantage of AI isn’t just speed or raw capability. It’s the expansion of what you can afford to try. You can pivot, iterate, and explore ideas that would previously have been too slow, too expensive, or too distracting to pursue.

That’s a qualitative shift, not just a quantitative one.

Ethan’s article (linked below) is one of the more recent pieces I’ve read that explores this idea.

Management as AI superpower

From Imperative Code to Declarative Play

The other big idea helping my X-COM experiments is the move toward declarative, high-level programming (in English) that agentic AIs make possible. If I had to manually specify every detail of the game’s mechanics and tech stack, I wouldn’t bother with this as a side project.

Instead, I can work declaratively: I describe what the system should do and how we’ll know it works, while the AI constructs the internal machinery. Or, as Addy Osmani puts it (The 80% Problem in Agentic Coding):

Don’t tell the AI what to do - give it success criteria and watch it loop. The magic isn’t in the agent writing code, it’s in the agent iterating until it satisfies conditions you specify…

The shift from imperative to declarative development:

Old model (imperative): “Write a function that takes X and returns Y. Use this library. Handle these edge cases. Make sure to...”

New model (declarative): “Here are the requirements. Here are the tests that must pass. Here’s the success criteria. Figure out how.”

Being declarative means I can get a working prototype off the ground in under an hour, then start tinkering, which is a big deal when you are just exploring ideas—and you have a busy schedule.

Anyhow, I’ve included screens (below) of a couple of recent experiments.

Interestingly, the most promising version of the game was the one where I intervened the least (Figure 2). Claude generated it in about forty minutes, and I was almost entirely hands-off. By contrast, the version where I spent an extra hour tuning the rules with Claude featured sophisticated phased movement and squad mechanics—but it was, ironically, less fun (Figure 1).

Which is perhaps a useful lesson when working with agentic AI: sometimes the best move is not to design more, but to let go—while still knowing clearly what works and what doesn’t.

Figure 1. Claude dutifully generated a basic version of the game in about 30 minutes. I, on the other hand, spent far more time tinkering with the rules—mostly to this game’s detriment. It became less fun, not more.

Figure 2. This is a version of the game that Claude generated in forty minutes, ready to go. Unlike the previous version, I didn’t get involved in its design —totally hands-off. And honestly, for a very-alpha game, it was surprisingly fun.

Takeaway

Maybe one of these days I’ll finish one of my game doodles. But that’s not really the point.

As the cost of software creation—time, energy, focus—collapses toward zero, the real value shifts from finished products to the insights you gain along the way. Completion becomes optional. Insight becomes the scarce resource.

So I’ll finish one of these games when finishing it teaches me more than starting over. Until then, rebooting is the rational move.

Learn on!

---

Here is a link describing the original game (1994).