A product planner with a humanities background—the Korean industry role closest to a product manager—published a running-habit app called Routinist to the App Store without taking a single hour of coding lessons. From the day he first sat down to work until launch, it took five weeks. His tool was an AI coding assistant environment, and his job was to describe what he wanted in plain language and check the results. The code was generated automatically in between.
He summed up the experience as "a fascinating, fun new world." What catches the eye about that remark is that it's phrased in the language of wonder, not achievement. It also means he never expected that building an app himself would be possible. Before that wonder fades, there's good reason to take a closer look at what this case actually contains.
Why This Approach Started Working Now
The term "vibe coding" took off after AI researcher Andrej Karpathy used it in a social media post in early 2025. The idea was to work by accepting the AI's suggestions without trying to fully understand the code. The method was simple: describe what you want, let the AI generate the code, paste any error messages back into the AI when things break, check the results, and shape your next request. The claim was that even without development knowledge, repeating this loop would eventually produce working software.
The developer community at the time was largely skeptical. Is it acceptable to deploy code you don't understand? How do you fix it when something goes wrong? Who's responsible when a security vulnerability surfaces? Those questions remain valid. The debate hasn't been settled.
But while the debate went on, the tools changed. Over the course of 2024 and 2025, AI code-generation tools became markedly better at producing code that actually works. Environments like Cursor, Lovable, and Bolt.new evolved by integrating the code editor with an AI chat window. The workflow of pasting an error message into the AI and getting corrected code back became reliable. That iterative loop started carrying all the way through to finished products, and Choi Cheol-yong's Routinist is one case where that possibility became real.
Where This Story Deserves Caution
It would be a mistake to read this case and jump straight to "I could build an app in five weeks too."
Choi was a product planner. He was someone who could already articulate, in words, what the app should do, how users should move through it, which features were necessary, and which were excessive. In vibe coding, the quality of the description you give the AI determines the quality of what comes out. Specific, consistent descriptions produce consistent code; vague requests produce vague results. Reproducing the same outcome with AI tools alone, without that planning skill, is difficult. Behind his five-week launch is the fact that he could explain precisely what he wanted.
The scope of Routinist matters too. It's a relatively simple app focused on a single purpose: tracking a running habit. The story changes for a service that processes financial transactions or handles large volumes of user data. In situations where code you don't understand can become a security vulnerability or lead to the loss of user data, vibe coding is not a sufficient method. In those contexts, you need a developer to review the code or a separate security audit.
A similar debate played out when 3D printing spread. Suddenly anyone could print physical objects, but safety-critical domains—medical devices, load-bearing structures—still required professional engineering processes. It's the same way that the spread of printing technology didn't mean every publication earned equal trust. That something has become easy to make is a different matter from its being fine to make for any purpose. Vibe coding is no different: the barrier to entry has been lowered, but lowered is not the same as gone.
What a Solo Entrepreneur Can Actually Take From This
So where does this method genuinely make sense?
Internal tools and projects built for yourself are the most realistic starting point. When something won't be released publicly, or its users are limited to you and a handful of others, whether it works matters more than how polished it is. Think automation scripts that eliminate repetitive manual work, simple dashboards that pull data from multiple platforms into one view, or tracking tools tuned to your own working rhythm. Outsourcing tools like these costs anywhere from hundreds of thousands to millions of won (roughly a few hundred to a few thousand dollars), plus a communication cost every time you request a change. Building them yourself changes that cost structure.
It's also valid for early prototypes built to test market response. At the stage where you're quickly assembling a minimum-feature version and putting it in front of real users, speed matters far more than polish. At that stage, vibe coding is a way to move faster than waiting for a developer.
For those who actually want to start, it helps to write scenarios before writing a feature list. Lay out, in story form, what the user sees when they open the app, where they tap, and what they'll want next—it dramatically changes the density of the descriptions you hand to the AI. The feature list can wait until after you're done.
Not fearing errors matters too. In vibe coding, an error isn't an accident to avoid but part of the iteration you work through with the AI. Copy the error message verbatim, give the AI the context, and ask "this error came up—how do I fix it?" and a direction usually emerges. That process is the vibe-coding workflow itself.
Some point to this trend and declare that "everyone is a developer now." I don't think that phrase captures the change accurately. It's not that coding has become universal; rather, a context has emerged in which the person who plans a product no longer has to wait for the person who writes the code. The possibility has opened for anyone who can describe what they want to build to ship the product themselves—and Routinist, which Choi Cheol-yong put on the App Store in five weeks, is confirmation that the possibility actually works.



