"Vibe coding" started as a joke — describing software instead of writing it. This month it showed up inside a Meta consumer app, which is usually how you can tell a joke has graduated into an industry.
Meta has opened Pocket to everyone in the US. You type a description of a small interactive game — Meta calls them "gizmos" — and get something playable back. No programming, no environment to set up, no code to look at unless you go looking.
What it actually is
Think of Pocket as a feed, not a dev tool. You describe a thing, the app builds it, and the result drops into a feed where other people play it, like it and comment on it. You can save gizmos into playlists, the way you'd save songs.
That's the part worth paying attention to. Turning a prompt into a working app isn't rare anymore — plenty of tools do it. What Meta bolted on is distribution: somewhere for the output to go and be seen. Most AI creation tools hand you a thing and leave you to find an audience yourself.
Pocket went live quietly on July 2 as an experiment, then widened this month. Ship small, see if anyone cares, expand — reasonable for a product nobody's sure about yet.
The shift underneath
Pocket itself is minor. What it sits on isn't.
Vibe coding just means using AI to turn plain instructions into working code, and the tool list has gotten long: Replit, Bolt.new, Lovable, Cursor, Base44, and more every month. The practical result is that time-to-prototype has collapsed from days to hours, and people who can't write a line of code are shipping things that work.
Google's coming at it from the developer end. AI Studio now generates native Android apps from plain text prompts — preview in a browser emulator, install onto a real phone, push to Play testing tracks. The distance between "I have an idea" and "there's an app on my phone" is now roughly an afternoon.
Where it holds up, and where it doesn't
Generated code is good at well-worn patterns. Dashboards, storefronts, booking flows, simple games — the shapes that appear ten thousand times in training data come out solid.
Novel things are harder. So is anything with consequences: taking payments, holding personal data, meeting a compliance rule, surviving more than a few dozen users at once. And here's the trap — the generated version almost always looks right. Looking right is exactly the part a non-technical person can assess. Being right is the part they can't. That gap is where the expensive surprises live.
So the rule of thumb: use it freely for things that would be embarrassing to get wrong, cautiously for things that would be costly.
What I'd actually do with it
If you're curious, Pocket is a cheap way to find out what prompt-built software feels like. Worst case, you make a bad mini-game and nobody plays it.
If you have a real idea — an internal tool, a small utility, that thing your team keeps doing by hand in a spreadsheet — skip Pocket and use one of the general builders. Describe it, get a working version, then treat it as a prototype and not a product. Prove the idea's worth having before you worry about whether the code underneath is any good.
Typing was never the bottleneck. The gap between having an idea and being able to test it was, and that gap just got a lot shorter.
One last thing about Pocket in particular. Because gizmos land in a public feed, prompt-writing quietly becomes a performance. The gizmos that do well will be the ones with a sharp idea behind them, not clever engineering, because the engineering happens either way. That's not a programming skill. It's much closer to the one that already decides what wins on short-form video: knowing what will land.
Image: RDNE Stock project, via Pexels
