Follow problems, not trends. First, understand the problem — code is simply writing down the answer.
A program is a solution to a problem.
Once you have a clear problem, its solution can be condensed into a set of repeatable actions.
Your program = Requirement → (Abstraction/Decomposition) → Executable steps → Stable results
It doesn’t need to be grand or universal. As long as it steadily turns trouble into calm, it’s a good program.
Programs/Services Are Products
Those who can’t write programs “rent” someone else’s solution by buying software or subscribing to a service.
The supplier is not selling code — they are selling sustainable reliability and ongoing maintenance.
Vibe Coding: Enabling More People to Start Coding
Vibe Coding means:
- Describe your intent in natural language, and the model provides a working prototype.
- Through back-and-forth dialogue, refine the “fuzzy feeling (vibe)” into “clear actions (code)”.
The barrier has been removed:
- Beginners no longer need to first learn syntax, then frameworks, and only afterward build features.
- Now, you can first “explain the problem clearly,” have the model produce a “runnable draft,” and then polish it step by step.
This means more and more people will write their first program to solve their own small problems.
Small-Scale Problems Avoid Many Scale-Related Challenges
When the problem is small in scope (a single person’s workflow, small amounts of data, limited concurrency):
- Architectural complexity: No need for microservices, message buses, or distributed consistency.
- SRE challenges: No need for 99.999% uptime, no need for monitoring.
- Collaboration/governance: No cross-team interface protocols.
- Cost constraints: A single small machine will do.
At this scale, barriers that used to require engineering teams are now much lower.
For example, publishing blog posts: Quaily, as a content platform, must serve thousands of authors and handle growing data through careful architecture. But if you’re running your own standalone site with only your articles, you may have so few that you don’t even need an index.
A Headwind for Tools, a Tailwind for Teaching and Knowledge-Based Services
Tools-based software/services clearly face a headwind. If the core value is simply “stringing together some common steps,” users might rebuild a “good enough” version with half a day of Vibe Coding — or solve it directly in an AI chat box.
As a result, the premium on commoditized features shrinks, and long-tail needs are self-served (e.g., image processing).
On the other hand, teaching, paid knowledge, and methodology benefit. Because now, “explaining the problem clearly” and “nailing down the requirements” become more important.
Good teachers will show you how to describe problems, validate results, and iterate. This directly improves the output quality of Vibe Coding.
Scale Remains a Challenge: Vibe Coding Can’t Replace Software Engineering
When your problem grows beyond a toy scale and you need to serve others:
- Data scale: TB/PB-level data, software quality control, permissions separation
- Traffic scale: Caching, fallback/degradation, cost optimization
- Organizational scale: Backward compatibility, change management, security compliance
- Reliability: SLAs, disaster recovery drills
These things can’t be done “in a few prompt lines.” For now, those without computer engineering capabilities can’t build large-scale systems with Vibe Coding alone.
When Doesn’t Vibe Coding Pose a Threat?
If the commercial value of a program/business is strongly tied to scale effects, network effects, distribution, compliance barriers, data barriers, brand, and trust — or if the value has nothing to do with technology at all (e.g., distribution channels, supply-side resources, IP) — then Vibe Coding is hard to replace.
A few examples:
- Scale-related: Advertising platforms, payment networks, logistics networks, search/recommendation systems
- Tech-independent: Exclusive copyrights, strong channels, strong supplier relationships, franchises, regulatory licenses
Vibe Coding solves the problem of turning ideas into small, elegant, workable prototypes — it’s not a universal key.
Some Strategies for Products and Teams
- Build things that can’t be easily cloned: Place your moat in data, network effects, and brand, not in the three lines of code behind a button.
- Productize the ability to describe problems: If your product naturally helps users clarify problems, you’ll be closer to their real needs.
- Save engineering capacity for truly large-scale needs: Use Vibe Coding for small problems to move fast, and engineers for the big ones.
For Those Writing Their First Program
For your first program, don’t worry about how elegant the architecture is. First, think: What problem can I completely solve today?
Explain the problem clearly, get it running, validate the results.
That is more than good enough.