Ride the models, respect the craft
It started with Texas mosquitoes.
It’s summer in Texas, and they are relentless!
That was the highly sophisticated creative brief behind a little game I started building called Skeeter Eater.
The premise is simple: a frog sits on a lily pad, bugs float down from the sky, and the frog flicks its tongue to snag them. It is whimsical, silly, and very much inspired by the current mosquito situation outside my front door.
At first, I thought it would just be fun to make a tiny mosquito-eating frog game.
But as I kept working on it, the project started to feel like a small example of a much bigger shift. AI tools are changing the shape of creative and technical work. Concepts, prototypes, layouts, copy, code, and music can now be generated much faster than they used to be.
That speed is exciting, but it also changes expectations. When rough concepts and playable prototypes are easier to make, ideas can become tangible much earlier in the process. That creates opportunity, but it also raises the bar for judgment. The work is no longer just about making a first version. It is about knowing what is worth pursuing, what needs refinement, and what it would take to make the idea real.
Because the models behind these tools are changing so quickly, staying close to them becomes part of the work too.
In a recent conversation about his “After Automation” essay, Dan Shipper said, “If you just ride the models, you’re going to be okay.”
In other words, don’t sit still. Try the tools and follow the models as they improve. Learn what they can and can’t do. Let them expand what you are capable of bringing into the room.
But I would add a second half: ride the models, respect the craft.
Because the more I use these tools, the clearer it becomes that moving fast is not the same thing as knowing what good looks like. AI can help you get to a first version faster and it can help a PM bring a more tangible idea to the table, or know enough to be dangerous (as they say).
However, it doesn’t remove the need for human expertise. If anything, this little experiment made me think more about subject matter experts, client expectations, the cost of concepting, and the fact that human judgment becomes critical when the first version gets easier to make.
From prototype to pond creature
Skeeter Eater started as an experiment for a work project.
I was exploring what a concept might look like and whether our team might want to take it further. Now that we have tools that make concepting easier, we can test whether an idea is viable before investing too much time polishing it.
For this experiment, I used a mix of tools across the process. I built the first working version in Claude Cowork using the Opus 4.8 model, partly because usage limits had been extended during a promotion. I used ChatGPT to create and refine the game images, Gemini for the music, and GitHub and Vercel to get the game live.
I had also planned to test the same basic prompt in Fable, since it had just come out earlier that week. But then Fable was pulled from access almost as quickly as it arrived. The timing was a reminder of how fast this landscape is moving. Even the tools we plan to test can change before we get very far.
The first version came from a different concept entirely: a mini-game called “Catch the Sunshine.” The mechanic was intentionally simple. Move an object at the bottom and catch what falls from the top. A progress indicator keeps score, and there’s a celebration at the end.
What I did not realize at first was that I was not really building one game. Once the prototype was working, I saw that the pattern could be reused. The falling objects could be changed. The background scenery could also be switched so the game could take on a totally different look and feel.
That is how Skeeter Eater came to be. AI tools made that exploration faster, but recognizing the pattern and knowing it could become something else still required a human.
The messy middle
Even though I was using AI, the exercise still felt fun and creative. But there was also still work involved in getting it right.
I iterated on the frog and the mosquitoes. And I added a few more bug types for good measure. I needed the lily pad less slanted. I needed the tongue to actually look like it could come out of the frog’s mouth, which sounds obvious until you see a frog tongue floating in space and realize the model does not quite understand what you mean.
Early UI exploration for Skeeter Eater:
I gave ChatGPT a prompt with sample image context and got a surprisingly charming first pass, even if the frog’s tongue had not quite figured out where it was supposed to go yet.
I needed UI buttons that matched the soft watercolor pond world. I needed music without vocals. I needed a background that was pretty enough to set the mood, but subtle enough not to compete with the game graphics.
The first playable version was fine, but making it better took rounds of testing and fixing.
In the process of making the little images for the game, I found out that the transparent PNGs were not actually transparent in the way I needed them to be. ChatGPT may say an image has a transparent background, but in practice, that can be fake news. I still needed Photoshop to export a true transparent PNG.
The music surprised me because I was not sure if I could get instrumental music from a free Gemini model, but I could. And it only took two prompts, which is amazing!
A Gemini music prompt for Skeeter Eater.
The first version came back with vocals, which was charming, but a little too much for the game, so I later stripped it back to keep the focus on the playful arcade feel.
But usable music is not the same thing as a complete sound design system. A working prototype is not the same thing as a production-ready experience. A nice visual is not the same thing as a comprehensive and consistent brand system. A generated game is not the same thing as a tested, accessible, and performant product.
Under the surface, there are still dozens of decisions waiting.
How should the difficulty ramp? How should the frog move? It feels restrictive currently. How should the scoring system work? Does the tongue timing feel satisfying? Is the visual contrast strong enough? Does the UI work on other devices besides an iPhone? Does the game need a stronger reason to play again? Should we add an alligator? Now that I think about it, I’m pretty sure it needs one.
That is the difference between a prototype and a product.
AI can help create the thing you react to. It can compress the distance between “what if?” and “look at this.” That is incredibly useful.
But once the thing exists, someone still has to look at it honestly.
Someone has to know when “good enough for a prototype” becomes “not good enough for production.” Someone has to understand the brand, the audience, the platform, the constraints, and the business goal.
That someone is still a human.
A cute frog, a heavier question
There is something light about building a frog game.
It has lily pads, mosquitoes and a happy little frog. It makes the AI conversation feel less heavy for a moment.
But underneath that lightness is a bigger question: what happens when the expensive parts of knowledge work start to feel commoditized?
As teams are learning these tools, our clients are learning them too. Everyone is starting to see how quickly a rough idea can become something visual, playable, or shareable. That means agencies and internal teams have to be clearer than ever about where the real value sits.
The value is in strategy, taste, technical judgment, performance, brand fit, governance, production polish, and knowing what should happen next.
The opportunity
Skeeter Eater is live. It is charming and it actually works! But it is not finished, which is exactly the point.
My goal was never to make a perfect thing or turn this into a full production project. It was a personal experiment to learn the tools better and see how far I could take an idea to something playable and shareable.
If this were a real project, it would absolutely need the next layer of expertise: creative direction, development polish, sound design, and all the thoughtful details that turn a fun prototype into a finished experience.
That is the opportunity.
PMs like me can bring ideas to the table earlier. Creatives can respond to something more tangible. Developers can see the intended interaction sooner. Clients can react to a prototype instead of trying to imagine one from a paragraph. Teams can decide faster whether an idea is worth more time.
And along the way, everyone gets a little more fluent in what the tools can and cannot do. Dan Shipper’s advice to “ride the models” is right on point. The models are moving quickly, and we should learn to move with them.