Next up: July 25th. We’re sitting down with the founders of Prom.dev to talk about what building a platform from scratch with AI looks like in practice. Come with questions. Pre-register now!
And would you like a larger AI / “vibe coding” event here in Seattle? Let us know.
So, someone on the internet told me my koi pond simulator was pointless.
They weren’t wrong, technically. Koi Pond doesn’t solve a business problem. It won’t make you more productive. It doesn’t integrate with anything. It’s a browser tab full of fish that swims around and eats little pellets when you tap the screen.
I’ve thought about why I built it anyway, and the answer fits in a sentence: I wanted to. The koi looked neat in my head and I wanted to see them on my screen. That’s the whole pitch deck.
What’s interesting is that the people who build the most things tend to have the worst reasons. The VIC-20 kids who typed 10 PRINT "HELLO" / 20 GOTO 10 into their televisions weren’t solving problems. They were fooling around. Most of the apps, games, and tools that people love were originally someone’s plaything that happened to outlive the weekend.
The gatekeeper question - “but who is this for?” - is a useful filter if you’re pitching a Series A. It’s not a useful filter for deciding whether to build something. Those are different jobs, and running the second filter through the first kills a lot of things that should exist.
If you’ve been building with AI for any length of time, you’ve heard this one: “You don’t understand the code you’re shipping.” Sometimes the person saying it is a developer with real concerns about security. More often, they’re frustrated that the credential barrier they spent years clearing is now optional.
The argument doesn’t survive its own logic. Human-written software has shipped with bugs since the first line of code went out the door. Every major platform you use has had a breach, a CVE, a data leak, a catastrophic edge case. The software industry’s record on security and quality is not one that earns it the right to hold AI-generated code to a different standard.
That’s not a defense of shipping broken things. Test your work. Get feedback. Fix what’s broken. The discipline matters. But the discipline applies equally to everyone, regardless of whether a human or an AI typed the source code.
That double standard is worth naming because you’ll use it to talk yourself out of building. You’ll think: maybe they’re right, maybe this isn’t valid if I can’t read every function. That’s the trap. A Chrome extension that does what you wanted it to do is a Chrome extension that does what you wanted it to do. Whether you wrote it yourself or directed AI to write it is an implementation detail, not a moral question.
I built GIF Grab - a screen recorder that exports to GIF or MP4, entirely in your browser - in a single day. It works. It does the thing. No, I couldn’t explain to you how the MediaRecorder API handles codec negotiation across browsers. I also couldn’t explain how the alternator in my car works, and I drove here fine.
When you swap “who is this for?” with “does this exist?”, a different set of projects becomes possible.
A wooden block sandbox with no score and no win condition - physics and ASMR-style clacking sounds when the blocks fall. (Blockyard) Does it exist? Now it does.
A procedural wood grain generator that outputs real species - walnut, oak, ash, cherry - as tileable images for design work. (Grainery) Did it exist? Not quite like this. Now it does.
A fireworks simulator that listens to your music and launches shells on the beat, with 43 historically-accurate shell types and a holiday color palette system. (Grand Finale) No one needed this. It’s extraordinary.
None of these passed a market validation test. All of them passed the simpler one: someone - in this case, me - wanted to see them work.
The apps that come from imagination tend to be weirder, more specific, and more memorable than the ones that come from market research. The market research apps converge. They all end up solving roughly the same problems in roughly the same ways because the research points at the same existing demand. The imagination apps go somewhere else.
Directing an AI to build something is a skill. Not the skill people talk about when they talk about coding, but a skill. You have to know what you want clearly enough to describe it. You have to know when what you got isn’t what you asked for. You have to test, iterate, and make decisions about what matters.
Those three things are product management. They’ve always been product management. The only change is that the person implementing your spec is no longer a human developer who needs six weeks and a retainer.
If you’ve been waiting for permission to build the thing in your head, this is it. The fish don’t need to have a business case. The wooden blocks don’t need a monetization strategy. Build it because you want it to exist, see if other people feel the same way, and go from there.
Nobody asked me to build a koi pond. I built it anyway. Several thousand people have visited since it launched, and I’m pretty sure at least a few of them open it, watch the fish, and close the tab feeling slightly better than they did.
That’s enough.
Friday, July 25th | Noon PT | Foundations, 1605 Boylston Ave, Seattle + online
What we’ll learn. about: Prom.dev is a social network where you build shared “houses” and “rooms” to hang out with people - photo walls, trivia, canvases you draw on together. Living spaces, not a feed.
Why it belongs here: The founders built it the way we talk about building here. Come ask them questions.
Streaming: youtube.com/chrispirillo/live and twitch.tv/ChrisPirillo
Cost: Free
Register now - and bring your questions about what vibe-coded products look like at scale.
Everything shipped in the past couple of weeks, linked, with free alternatives where they apply:
Thin Ice - 3D ice-block tapping game. Knock out the blocks without dropping the penguin. Free alternative to Don’t Break the Ice.
Ice Wheels - Snow drift and donut simulator with FWD/RWD/AWD switching, tire tracks, and cone-knocking. Free alternative to Drift Hunters.
GIF Grab - Screen record a tab, window, or webcam, then trim and export as GIF or MP4. Private, on-device. Chrome extension available.
Snack Samurai - 3D fruit slicing game with combos, criticals, bombs, special bananas, and Classic/Arcade/Zen modes. Free alternative to Fruit Ninja.
Seattle Snarlcast - Live Seattle traffic and crowd forecast built on real WSDOT and SDOT data. Ferries, mountain passes, street closures.
Koi Pond - Generative koi pond with tap-to-feed, ripples, caustics, lily pads, and day-night light. Free alternative to My Koi and Pocket Pond.
Grand Finale - 3D fireworks simulator that reacts to your music or live mic. 43 shell types, holiday palettes, MP4/GIF export. Free alternative to FWsim.
Newton’s Cradle - 3D Newton’s cradle with variable ball mass, pendulum-wave mode, material and gravity controls, and shareable URL links.
Timbre Table - Nine tuned mallet instruments in your browser - xylophone, marimba, vibraphone, glockenspiel and more. Record a tune, share a link.
Blockyard - Calming 3D wooden block sandbox. Stack, fling, topple. No score.
Grainery - Procedural wood grain generator in real species - planks, herringbone, end-grain, butcher block. Exports as image.
This one’s for the people asking how to get more consistent results from Claude across sessions - specifically, how to give a model like Opus the kind of context that helps it perform at the same level session after session.
The short version: write your preferences down once in a structured format and have the model read them before starting work. Claude’s skill system (.skill files loaded at session start) is the approach that’s worked here. But the framework transfers to any model that takes a long system prompt or project instructions.
The key move isn’t technical. A model performs better when it has ground truth - your files, your preferences, your constraints - rather than reconstructing context from scratch each time. The skills themselves are structured prompts. What makes them work is specificity: not “write cleanly” but “no em dashes, no three-item lists, no binary contrasts, here are the 12 structural patterns to avoid.”
If you want to build your own version: start with the three things you correct most often. Those are your first three constraints. Write them as rules with examples of what violates them, not style preferences. Constraints are easier to enforce and easier to verify than taste.
A few things I keep coming back to from the past couple of weeks:
The critics who say AI-generated software is buggy have a point that applies to all software. Every platform you use daily has shipped code with security holes, crashed under load, and done something embarrassing in production. The question was never “is it perfect?” The question was always “does it work well enough to be useful?” That bar exists for AI-generated code too. It’s not a higher bar.
My (Gen X!) generation learned to program because that was the only way to make the machine do anything interesting. Kids today don’t have that constraint. They describe what they want in plain sentences and a game appears. That’s not laziness - that’s forty years of abstraction working the way abstraction is supposed to.
AI will not replace managers. It will make clear which managers were contributing and which ones were in the room taking up a chair. That’s going to be uncomfortable for some people and overdue for everyone else.
I built a wooden block sandbox with no win condition and no score. It’s one of my favorite things in the arcade. If I’d asked “who is this for?” before building it, it wouldn’t exist. Sometimes the filter is the problem.
Yours Digitally,
Comments
Nothing yet. Say the first thing.
Sign in to join the conversation.