Vibe Coding is So Powerful, Why Haven’t You Built a Decent Product Yet
Powerful AI technology can now accomplish many complex tasks, such as code generation, problem-solving, and text creation. However, AI technology cannot replace human creativity and imagination. How to leverage the power of Vibe Coding to create usable products is a question worth pondering.
Look around you - so many programmers don’t even have their own personal website, let alone building better and stronger products. They’re still stuck in that CRUD work atmosphere, unable to break free. They go on social media like Twitter, Reddit, and Zhihu, talking big about how “AI helped me finish a week’s work in a day,” occasionally dropping lines like “frontend is dead” ~ ~ ????? So, AI programming is so powerful now, but where are your works? Why aren’t there any?
Just a few prompts and you’re done, so why is there nothing? Or has your company’s product become stronger and more competitive because you used AI? On the surface, everyone is using AI to write code with all kinds of efficiency improvements, yet the products produced are still so ordinary ~ This is quite contradictory!
Recently, a new term emerged called “hallucinated productivity.” An organization called METR recruited 16 experienced open-source developers from large open-source repositories (averaging 22K stars), who had contributed to their projects for over 5 years on average, were very familiar with the codebases, and most had extensive experience using AI tools. These developers conducted a test: a total of 246 real tasks from the developers’ own repositories, including bug fixes, feature enhancements, refactoring, etc. - all valuable content from real work, not artificially designed toy tasks. The developers first provided task lists, METR randomly assigned them, with half allowed to use AI and half prohibited from using AI. Completion times were objectively recorded through screen recording. The final results differed from what everyone imagined: the group allowed to use AI took 19% longer to complete tasks than the other group.
There’s a very interesting phenomenon here: before the experiment, the participating developers predicted AI would make them at least 20% faster, and after the experiment, before knowing the data, they still felt they had completed their work faster. This is fascinating. And so, the term “hallucinated productivity” was born. When we raise the standards of production environment coding (not just staying at CRUD level), let’s objectively analyze the conclusions of this experiment:
First, we must acknowledge that AI is indeed powerful enough - even with complete AI usage, all work can still be completed
With higher requirements, developers must invest significant time writing prompts, increasing precision, consciously reducing AI code hallucination rates, and some requirements need to read more context, leading to long wait times and thus lower efficiency
Once a hallucination occurs and the output doesn’t match expectations, repeatedly revising prompts greatly extends the problem-solving time
Because the long waiting process doesn’t consume energy, programming becomes more relaxed - not as tiring as manual coding, so we feel AI is faster, but it may not actually be so. Of course, you can open multiple projects simultaneously and write prompts for other projects while waiting, thereby thoroughly improving development efficiency.
What limits AI from quickly reaching 100 points isn’t insufficient AI programming code output capability - its ability is already powerful enough to write all code. There’s another reason: it needs guidance, and how to guide it is the bottleneck! Because when you want to make a product reach 100 points, you inevitably raise requirements and won’t stay at the level of student projects, practice demos, or crudely made products.
You need more prompts, more precise descriptions, and require more stable AI output - the requirements for prompting themselves aren’t much different from writing code yourself. In many cases, code itself is the most concise input. So in the AI programming era, learning fundamentals isn’t useless as everyone thinks - it’s actually very useful. However, many programmers stay at the 80-point project level and don’t feel it. What you need to do is try to create a decent product, break out of the CRUD dimension, and experience it firsthand. Architectural thinking is so valuable in the AI programming era because it can dramatically reduce prompt input and AI coding output, greatly lowering the difficulty of communicating with AI.
In the AI era, should front-end developers learn back-end? Learning costs will decrease in the AI era, and if you master the right learning methods, your growth speed will be very fast. So learning and trying back-end knowledge is a natural thing to do, not a question of whether to learn or not.
If you’re at a stage where you’re still struggling internally about whether to learn back-end, it shows that subconsciously you treat back-end learning as something with a huge investment cost. At this point, you probably haven’t found a learning method that suits you. What you need to do isn’t struggle with whether to learn back-end, but try to find your own learning method in some direction of front-end study.
The thinking trap here is that you might still feel you’re competing with the front-end cohort, so wouldn’t you become more competitive? Actually, no.
And if you need high output precision in this direction (not just entry-level), the requirements for back-end foundational abilities are extremely high. It’s absolutely not something a front-end developer can easily do by simply switching over.
Finally: Break out of the CRUD cage. Your value never lies in code, but in works.
AI can help you write code, but it can’t help you think clearly about a product’s core value; AI can help you solve technical problems, but it can’t help you polish the details of product experience; AI can help you improve coding efficiency, but it can’t help you have the determination and patience to make good products.
True technical growth has never been about “how much code you can write,” but “how many works you can create”; true industry competitiveness has never been about “how many tools you can use,” but “how well you can leverage tools to create value.”