You’ve probably seen the comments. A developer builds a terminal multiplexer using a 2D game engine and Rust. The purists immediately recoil, calling it a “cursed combination” worse than “Doom on a pregnancy test.” They complain about buzzword bingo and dismiss it as wildly misguided vibe-coding.
But they’re evaluating this software by the standards of a dead era. The creator didn’t build gPTY because the world desperately needed another terminal workspace. They built it because they wanted to learn Godot and Rust. And in the age of AI, that is a perfectly valid, perhaps even superior, reason to build something.
When AI removes the penalty for ambition, the journey itself becomes the product.
Look at the actual trade-offs made in this project. The creator explicitly admitted they could have built this in Electron in a fraction of the time. They acknowledged the steep learning curve, the friction, and the lack of ecosystem maturity. But they chose to lean on LLMs to bridge the gap, actively steering the AI while embracing the philosophy that “it’s not just the end but the journey that matters.” They didn’t want to ship a polished widget; they wanted to explore an unfamiliar stack.
This is the tension defining the new AI-assisted coding era. As LLMs lower the barrier to entry for complex, multi-language stacks, we are going to see a surge of architecturally “cursed” software. It will thrive not because the end product is optimal, but because the AI-assisted process of building it is incredibly fun.
Purists demand efficiency; explorers demand possibility.
You might think this is just a side-project, a novelty that will be abandoned in a few weeks. But it highlights a massive shift in why we write software. For decades, valuable software was defined by its utility—how efficiently it solved a user’s problem. Now, AI is shifting the ‘why’ of development from solving user problems to facilitating personal learning journeys. The friction between purist disdain and joyful exploration is only going to intensify.
We used to code to solve problems. Now, we code to see what’s possible.
The next time you see a developer using a game engine to render text, or using AI to stitch together a wildly inefficient tech stack, don’t dismiss it as buzzword bingo. Recognize it for what it is: the new frontier of creative exploration. The software might be cursed, but the process of building it is the most human thing we can do.
FAQ
Q: Why would anyone use a game engine for a terminal interface?
A: Because the goal wasn't to build the most efficient terminal. The creator wanted to learn Godot and Rust, and AI made it possible to bypass the steep learning curve. The inefficiency is the point—it's a learning playground, not a production tool.
Q: Does this mean we'll see more inefficient software?
A: Yes. As AI lowers the barrier to entry, developers will prioritize personal learning and creative exploration over utilitarian efficiency. We'll see a surge of architecturally 'cursed' software that thrives because the building process is valuable to the creator.
Q: Is 'vibe-coding' actually a good thing?
A: It is if you're exploring. Purists hate it because it sacrifices clean architecture for rapid AI generation. But when the journey of learning is the actual product, vibe-coding is the most efficient way to traverse unfamiliar tech stacks.