Tom Greenaway
Tom Greenaway
Hi – my name's Tom and I like making things.
Receive updates on my latest games, experiments and thoughts.
"As tools become cheaper to build, they become more bespoke, more ephemeral, and finally more disposable… but thankfully games are not tools…"
On a recent personal project I needed to do a highly repetitive task in Photoshop involving the magic wand tool and manual operations that would take me 20 minutes and I needed to do it 30~ times over.
I realised that my Photoshop subscription was no longer active and while five years ago I might've paid again for Photoshop or looked for a free tool for this temporary task, I suddenly had a thought – maybe I can actually vibe code this tool.
Better yet, I could vibe code a completely automated version of the tool that had a pipeline which would do what I was going to do 30 times over. Not only would I avoid paying for Photoshop but I'd actually be faster at the work and if I needed to redo any of the graphics/art in the pipeline, the whole process would be instantly repeatable.
So I prompted Antigravity and had an initial version working within 30 minutes. It literally only did a tiny slice of Photoshop's feature set but it actually did it very fast for a single file. I manually ran that tool over each of the 30 files I needed to operate over.
Then a few weeks later I needed to re-run the tool as the art had changed. So I decided to tweak the tool again with a prompt and make it a completely repeatable pipeline. The tool continued to evolve along the way of my project, becoming more and more precise, and saving more and more time.
Another amazing part of this is that… I know this tool will be mostly tossed away at the end of the project. Just as quickly as I generated it, it will be gone again.
I'm noticing it with others around me working the exact same way. Software tools are so cheap to generate they can be both more precise and bespoke than ever, and more ephemeral and disposable than ever.
For most of computing history, software was expensive to make. And because it was expensive to make, it had to last. And because it had to last, it had to be generalised.
If a team spent six months building a tool, they couldn't build it for one person's Tuesday afternoon problem. They had to build it for ten thousand people over five years. That economic reality gave us the modern software product: sprawling settings menus, plugin architectures, role-based permissions, and onboarding tooltips explaining buttons that 90% of users never click.
Every settings screen in a piece of traditional software the developer trying to guess every slightly different way a stranger might want the tool to behave.
Now the cost of spinning up a working tool has dropped to a prompt and ten minutes of steering. When software becomes cheap enough to generate on demand, it stops being an appliance and starts being a scratchpad.
People are building tiny, hyper-specific tools for the exact problem sitting in front of them right now – a custom review tool for a video pipeline, a bespoke converter for a single batch of assets, a one-off dashboard to watch – and then dropping those tools the moment the task is done.
As we get used to software that fits your problem like a glove, off-the-shelf software will start to feel strangely claustrophobic.
The hardest part of building a generalised product today isn't writing the code. It's convincing anyone to live inside your feature set. People don't want to be constrained by what a product manager decided was in scope last quarter. They don't want to file a feature request and wait six months, or stitch three subscription-based tools together just to accomplish a task.
People don't want to adopt a fixed feature set anymore – they want to remix software as they need it.
If a tool doesn't quite fit my pipeline, I don't want a settings toggle. I want tell an agent to optimise the functionality for my task and get back to work.
That makes life genuinely difficult for anyone trying to sell generalised utility software. When the barrier to building a custom tool was high, users tolerated friction because the alternative was writing ten thousand lines of code from scratch. When the alternative is a three-sentence prompt, "almost fits your workflow" isn't good enough.
We have plenty of words for software defined by how it's distributed or monetised: commercial software, open source, shareware, freeware.
We don't really have a good word for software defined by who it's for when that audience is a single person.
While chatting with my colleague Guillaume Laforge, he touched on this phenomena and mentioned the term Selfware, because we were talking about temporary tools that engineers are generating.
But personally I still feel like these tools can be reused (or at least remixed) inside enterprises, and the fact they evolve, or adapt dynamically to our needs, tends me to like another term: Dynamicware.
To me that term emphasises their dynamicism in both features and in time:
Dynamicware isn't replacing foundational infrastructure (yet) – nobody is vibe coding their own browser engine or database kernel before lunch. But the boilerplate, internal tools, and workflow utilities that sit on top? They probably will do so – and more often.
Although I'm an engineer, I'm also a game designer. So I always consider things through the lens of the games industry as well.
If utility software is dissolving into ephemeral, remixable Dynamicware, it leads to an obvious question for anyone who makes games.
Will games go the same way? If anyone can prompt a playable prototype in an afternoon, will players stop buying games and just generate whatever they feel like playing for twenty minutes on a Friday night?
Perhaps there will be a bit of this but I don't think a traditionally 'designed' game will disappear. Because utility software is a means to an end, a game is the end in itself.
When I build a tool to convert audio files or sync draft blog posts, I don't want an experience. I want the task finished so I can move on with my day – it's work. If I can collapse that friction to zero with a piece of disposable Dynamicware, that's all I need.
I remember years ago when discussing game design versus UX design with a colleague Yasmine Evjen that I said to her:
"In UX, the destination is the reward. In a game, the journey is the reward.”
When we play a game – just like when we read a novel, watch a film, or listen to a song – we aren't trying to reduce friction. Quite the opposite: playing a game means voluntarily stepping into a set of unnecessary obstacles because we trust the person who placed them there. Again, the journey is the reward.
One of the lessons I wrote down years ago after shipping Duet was simple: pour your whole self into your product and it will speak a unique and resonant truth.
You can't get that from Dynamicware for a game, because you can't surprise yourself with your own prompt.
When you play a great game, you're having a conversation with another human being. You're feeling their sense of timing in the jump physics, their sense of humour in a throwaway line of dialogue. Part of the magic is knowing that another person cared enough polish (or not polish) those details – and that thousands of other players hit that exact same wall and felt that exact same moment of relief when they finally cleared it.
AI is already changing how we build games. Many game developers I know are spinning up temporary tools inside their own pipeline – custom level-editing scripts, throwaway asset tools, quick prototypes to test whether a mechanic is fun before committing a month to it. That part is wonderful. Anything that gets an idea from head to screen in a few hours gives small builders leverage they never had before.
But the finished game? The thing on the other side of all those disposable tools?
As software becomes more disposable, human point of view becomes the scarce resource. We'll gladly generate our own tools and throw them away by dinner. When it comes to games, though, there will always be a hunger for something we didn't make for ourselves: a human message, from a human being, wrapped in gameplay we didn't see coming.
Article published on: 16 Oct, 2026