Vibe Coding in Practice: A Developer Experiment from Idea to App Store in One Afternoon

From "Let's See If This Works" to a Live App Store Listing

According to a story shared on the Vergecast (sponsored by AWS), a developer described an impulsive experiment he ran after ChatGPT got more capable: "I just wanted to see if this was even possible—could I actually get an app into the App Store?" The answer came in the form of a single Saturday afternoon and an app called Coffee Finder, whose functionality is almost a joke: open the app, grant location access, and it shows nearby coffee shops using the built-in Apple Maps.

The point of this story isn't how useful Coffee Finder is—it's that it validated a new path: when natural-language prompts are enough to drive code generation, the barrier to "shipping an app" collapses to a matter of hours. The developer's reaction was refreshingly honest—"pretty cool, but I probably won't do it again"—and he left the app sitting in the store. That "one-off validation" mindset is exactly the most typical way vibe coding begins.

The Core of Vibe Coding: Telling the Model What You Want, Directly

The developer on the show divides these projects into two motivations: one is a sudden idea where you think, "I wish I could make this real"; the other is when the tool you already use is just a little off, and you want to tweak it yourself. He mentioned he was using the built-in Reminders app and wanted to see "whether I could build something with the tools I already have on hand"—and the answer was yes.

The methodology worth noting here is that he didn't ask the model to "invent" a code structure from scratch. Instead, he provided references. When building the audio-processing app Leveler, he gave Claude two files—one was raw audio exported from Riverside, and the other was a finished track he had carefully edited himself—and simply said, "make it sound like this." The model built an audio engine in 20 to 30 minutes, and it passed on the first listen. This "give an example, give a goal, don't give implementation details" style of interaction is what sets vibe coding apart from traditional prompt engineering: the developer plays the role of the acceptance tester, not the architect.

Vibe coding is a term coined by Andrej Karpathy in early 2025. It refers to developers describing their intent in natural language so a large language model can directly generate runnable code, while the developer mostly plays the role of "checking the result and requesting changes" rather than writing or reviewing the implementation line by line. The difference from traditional prompt engineering is that the latter focuses on writing more precise instructions to control model output, whereas vibe coding accepts the model's autonomy at the implementation level and keeps human attention on goals and acceptance. This also explains why the "give an example, give a goal, don't give implementation details" approach in the original article works—models are good at choosing an architecture on their own when constraints are sparse, and examples happen to provide a denser constraint signal than text descriptions.

Three Projects, Three Forms of Delivery

Coffee Finder: Proving Feasibility

Single-purpose, reliant on built-in mapping capabilities, and going from idea to App Store in one Saturday afternoon. Its value is proving that "an individual developer can complete the entire app-store submission process alone" no longer requires a long-term commitment.

Leveler: Solving Your Own Pain Point

Addressing the problem of mismatched volume between host and guest in podcast recordings, the model used reference audio to generate an audio engine, compressing the development cycle to the half-hour level. The developer's approach was: once it was verified as usable, just "put it on the website and ship it."

Captioner: Open-Sourced Along the Way

He needed to batch-process Reels: import ten videos at once, apply the same subtitles uniformly, and export them back to the source folder. After finishing it, his judgment was "other people could probably use this too," so he open-sourced it for free. This decision matters—tools produced by vibe coding tend to be very narrowly scoped, and only open-sourcing lets their value extend beyond the developer's own workflow.

Reels is the short-video format introduced by Meta on Instagram and Facebook. Its exported files typically come with fixed resolution, duration, and encoding standards. Captioner's "batch-apply the same subtitles" feature is essentially a batch-processing wrapper built on top of those platform standards: read in multiple videos at once, apply a unified subtitle track, and output following the source directory structure. This kind of need is well suited to vibe coding because it has clear boundaries, can be quickly verified by eye, and does not involve server-side logic; once you need to support multilingual subtitles or automatic speech recognition, the complexity rises significantly.

The Boundaries Behind the Efficiency

The "two hours from first prompt to done" mentioned on the show is genuinely exciting, but several preconditions should not be overlooked. First, all of these projects are built on top of mature platform capabilities—Apple Maps, Riverside's export formats, short-video platform export standards—and what the model does is integrate, not create. Second, the developer himself has the ability to judge output quality: he can hear whether the audio "sounds right" and judge whether subtitles are aligned, and this kind of acceptance capability cannot be replaced by prompts. Third, apps like Coffee Finder can be listed easily because they are extremely simple, have no backend, and store no user data. Once account systems, payments, or privacy compliance are involved, the development cycle immediately returns to a different order of magnitude.

Looking at these three points together, what vibe coding truly changes is not "writing code" but the startup cost of "pushing an idea to a deliverable state." In the past, an idea first had to clear hurdles like environment setup, framework selection, and app-store review. Now the first hurdle has been flattened, and the remaining hurdles are exposed more clearly: do you have explicit acceptance criteria, and are you willing to take on the maintenance responsibility for this idea? The developer leaving Coffee Finder in the store and open-sourcing Captioner are essentially different ways of handling the same problem—giving these spur-of-the-moment products a reasonable home.

For content creators and independent developers, the most reusable lesson here may be: find references before making requests, get the smallest loop working before deciding on a release form, and once it's done, think clearly about whether it should stay on your computer, be open-sourced, or actually be published.

One-line Summary

Vibe coding cuts the barrier to app-store release down to hours, but acceptance capability and platform dependence remain hard boundaries.

Paragraph Summary

Through one developer's three projects—Coffee Finder, listed on a Saturday afternoon; Leveler, which generated an audio engine in half an hour; and Captioner, open-sourced along the way—the article shows what vibe coding actually looks like: developers use natural language and reference examples to drive code generation, playing the role of acceptance tester rather than architect. The author points out that this efficiency gain rests on three preconditions: mature platform capabilities, the developer's own quality judgment, and extremely simple projects (no backend, no accounts, no compliance). What vibe coding truly lowers is the startup cost of pushing an idea to a deliverable state, not coding itself; the remaining hurdles are actually clearer: whether there are explicit acceptance criteria, and whether one is willing to bear the subsequent maintenance responsibility.