You’ve probably seen it by now. Someone types a prompt, an AI spits out a working app, and the internet collectively loses its mind. “This changes everything.” “Programming is dead.” “My kid built this in ten minutes.”
And then you actually try to use the thing. On your phone. The device you carry everywhere. The device that, statistically, is how most people will ever encounter what you built.
And it falls apart.
There’s a Dutch train map simulator making the rounds right now. It’s genuinely delightful — a real-time visualization of the Netherlands’ rail network, alive and moving, the kind of project that makes you smile when you first load it. You can see trains crawling across the country. It feels like magic. The creator built it as a passion project, and the love is obvious.
But the comments tell a different story than the code does.
The comments aren’t feedback. They’re the real product backlog. And they reveal the gap nobody in AI-assisted building wants to talk about.
One user points out the map is unusable on mobile. The left sidebar won’t collapse. The screen gets eaten alive. Another notes the Betuweroute — a major 25kV freight corridor — is simply missing from a national rail map. Someone else wants filters for specific trajectories, which is table stakes for any transit tool worth its salt.
None of these are code problems. They’re product problems.
And that’s the twist. We’ve been told the AI revolution is about generating code faster. But the bottleneck was never code. Code is the easy part. The hard part — the part that separates a demo from a tool people actually use — is deciding what to build, for whom, on what platform, with what data.
AI can write your function. It cannot decide that your mobile experience matters. That’s still on you.
Think about what happened here. A talented maker built something beautiful. The AI (presumably) helped generate the visualization logic, the map rendering, the real-time data integration. Impressive stuff. But at no point did anyone — human or machine — stop and ask: “Wait, how does this look on a 6-inch screen?” Or: “Is the rail network actually complete?” Or: “What does a returning user need that a first-time visitor doesn’t?”
These are product decisions. They require context, empathy, and lived experience with the problem domain. They require caring about the person on the other side of the screen, not just the screen itself.
This isn’t a takedown of the project. It’s a recognition of where we are. The simulator earns genuine goodwill. People like it. They want it to be better. That’s a gift most projects never receive. But goodwill doesn’t collapse a sidebar. Goodwill doesn’t add a missing freight route. Goodwill doesn’t make a desktop-first tool work on the train you’re riding while looking at a train map.
The modern maker’s struggle isn’t shipping something cool. It’s shipping something complete. And completeness is a thousand small decisions AI can’t make for you.
Every vibe-coded project faces this same cliff. You generate the thing. It works. It’s exciting. And then reality walks in with its boring, specific, unglamorous demands: accessibility, data fidelity, platform coverage, edge cases, the user who holds their phone in portrait mode on a crowded tram.
The differentiator going forward won’t be who can prompt the hardest. It’ll be who can make the unsexy product decisions that turn a spark into a fire. Who remembers mobile. Who checks the data. Who treats the comments section as a roadmap, not a reaction.
Because here’s what nobody tells you about vibe coding: the vibes get you started. The discipline gets you shipped.
FAQ
Q: Isn't this just nitpicking a free passion project?
A: No. The project is genuinely great and people love it. The point isn't that it's bad — it's that even a beloved, AI-assisted project hits the exact same wall: product decisions AI can't make. That's the lesson, not the criticism.
Q: So what should vibe coders actually do differently?
A: Before shipping, ask three questions: Does this work on mobile? Is the data complete? What does a returning user need that a first-time visitor doesn't? AI can help answer these, but only if you prompt for them — and more importantly, only if you care enough to ask.
Q: Doesn't AI eventually solve the product-decision problem too?
A: Unlikely anytime soon. Product decisions require context about users, platforms, and trade-offs that lives outside the codebase. AI can suggest patterns, but choosing which trade-offs to accept is a judgment call — and judgment is still a human deliverable.