After GitHub Became Like Xiaohongshu: Building Products Has Become Even More Lonely

Recently, I've had a somewhat different feeling about building products. Let me jot it down.

Likes Take Seconds; Products Don't

Since vibe coding emerged, projects have been skyrocketing on GitHub in no time. Racking up tens of thousands of stars in two days has become common. After Collins Dictionary named vibe coding its 2025 Word of the Year, the pace didn't slow down. Supposedly, a quarter of the projects in Y Combinator's Winter 2025 batch had codebases that were 95% AI-generated. The entire open-source ecosystem is taking on an increasingly strong "note-posting" vibe.

This state increasingly resembles Xiaohongshu (China's lifestyle-sharing platform similar to Instagram). A fun idea, an interesting angle, is enough to draw people in to browse, drop a spark, download, and try it out. The approach has passively turned into "posting notes"—have an idea, post it; if it blows up, great; if not, move on to the next one.

But I've increasingly come to realize one thing: giving an idea a like takes seconds; turning an idea into a product people can actually use still doesn't. The unsexy, hard-to-explain stretch in between—vibe coding hasn't shortened it much.

The Hard Threshold of Infrastructure Products

Our company, Aima, primarily focuses on on-device AI hardware, and we also have some lower-level work around model inference performance, edge devices, and agent runtimes. The demand for "stability" in this kind of product is higher than anything I've worked on before.

The reason is simple. If you build a marketing mini-game and it crashes, users might curse at most. If you build an IM, a gateway, or an inference engine and it crashes, it could mean the entire upstream business is taken down. These things are also the most likely to get slammed against the wall by high concurrency and high-frequency calls—back when Facebook Chat launched and accumulated 175 million active users, the channel server was repeatedly pushed to the breaking point between CPU and bandwidth. That kind of "infrastructure torment" is something every person who builds infra must go through.

Then it has to withstand scrutiny. The novelty has to be novel enough for users to feel it's different from what already exists. Stability and novelty are two completely different capabilities: stability demands obsession with details; novelty demands dissatisfaction with generic solutions. For a product to pass both bars is itself a low-probability event.

Vibe coding can push a demo to a "it runs" state—something that used to take weeks now takes hours. But the gap between "it runs" and "it can withstand daily use and repeated scrutiny"—this wave of tooling upgrades hasn't filled that in for you.

The Invisible Road in the Middle

The part of a product that truly torments people is usually the long stretch after the PoC is validated.

In the early stage, the idea is validated, a few people say "this is interesting"—this is the highlight. You have passion, feedback, and the desire to share. Then you enter the middle stage: making it solid, covering edge cases, feeding it real data, connecting it to real systems, watching stability. There's nothing shareable in this stretch; every day is "plugged another hole"—no social media content, no likes.

You also have to repeatedly explain to people what you're doing. I've tried several times in recent weeks to describe to friends what I'm working on. After I'm done, they say, "Oh, so it's just XXX, right?" XXX is completely different from what I'm building, but their frame of reference has no slot for it, so they just squeeze me into the nearest category. This kind of helplessness is unavoidable.

What's harder is that in the middle stage, you often have to fight with yourself. Go broader or deeper? Add this feature or not? Cut your losses or give it another shot? Many decisions have no clear external signals to guide you; you have to carry them entirely on your own. As long as something is "new," there will be a massive number of problems; you fix one, and you create new ones. This cycle doesn't stop on its own.

Plus the risks: what if someone else builds something similar? What if resources are pulled away? What if the team wavers? Very few people can remain steadfast without faltering. Those who do are often later described as "obsessive."

Looking Back at Those Who Endured

So if you look through history at people who endured to build great products, you'll find one consistent thing: they were all particularly stubborn about something.

Steve Jobs is the easiest to recall. In 1985, he was ousted from the Macintosh division by the CEO he had hired, John Sculley, and the board. That May, he even attempted a boardroom coup while Sculley was on a business trip to China; after Jean-Louis Gassée betrayed him by leaking the plan, he was completely out, resigning officially in September. For the next twelve years, he endured at NeXT and Pixar, returning to Apple only in 1997. During this period, he was repeatedly challenged by outsiders: "You're not an engineer, you can't write code, who are you to call the shots?" The dramatic line delivered by Wozniak in the 2015 film Steve Jobs—"You can't write code, you're not an engineer, you're not a designer"—actually compressed more than a decade of skepticism into a single sentence. Stubborn people can endure this; those who aren't leave early.

Allen Zhang is another. He started with the email client Foxmail; by around 1998, it already had 2 million users, which he sustained largely on his own for many years. In between, he went through an acquisition by Boda, team turbulence, and skepticism that he was "someone who doesn't know how to commercialize." In 2005, he joined Tencent to take over QQ Mail; the first two years were basically a failure—bloated, slow, unused. He endured internally for two years before carving out the "oversized attachment" feature, pulling the email product back from the brink of death. WeChat was the same: inspired by a mobile app called Kik, he sent Pony (Ma Huateng) an email pitching the idea, then repeatedly fought battles inside Tencent with the QQ team and the wireless team to get it built. He himself and those around him acknowledge that his personality is, to some degree, "dictatorial" and reclusive. It is precisely this stubbornness that allowed him to withstand all the voices asking, "Why don't you just make it like XXX?"

Looking at the two together, there is a shared temperament: on a particular matter, they don't listen to advice, refuse to be reasonable, and just keep at it. Outsiders often think, "What hope is there in this?" yet they keep going.

What Vibe Coding Hasn't Changed

The real impact of vibe coding is actually quite clear.

It compresses every stage of the lifecycle. What used to take two weeks for a demo now takes an afternoon; what used to take a sprint for a feature iteration now takes hours; what used to be a stack one person couldn't cover alone, one person can now run across horizontally.

But the "complete product lifecycle" hasn't been replaced. PoC, polishing, stability, user feedback, iteration, quality, persistence—this process is still there; only each stage is shorter. My own feeling is that the fast parts are very fast, but the slow parts haven't changed much.

The most tormenting part of the middle stage is precisely the part where "change is least visible." Polishing a boundary condition isn't something vibe can solve; it requires repeatedly constructing scenarios. Stability isn't something you get in a few hours; it has to run under real traffic. Quality certainly isn't something a single prompt can guarantee. A controlled study by CodeRabbit last year on 470 open-source GitHub PRs showed that AI co-generated code had roughly 75% more bugs in logic and correctness than human-written code. When you do the math, vibe can't help you with this; you can only grind through it slowly.

So during this period, I've become increasingly clear: tools have gotten faster, but the hard parts haven't decreased; they've just been thrown into sharper relief. When everything was slow before, the middle being slow didn't feel particularly slow. Now that the first two stages whiz by, the texture of the middle stage—repeated grinding, repeated wrestling with yourself, repeated absence of feedback—is amplified.

My Own Experience

Something personal. In my past career, I haven't had many opportunities to independently own a product. I started in strategy, later moved to somewhat technical product roles, and then did ecosystem, BD, and sales. After doing these roles for a while, you realize the feedback velocity differs enormously.

Sales has the fastest feedback. You meet a client, chat for two hours, and by the time you walk out, you basically know whether there's a chance, what they care about, and what the next move should be. Bad news also comes fast; if it's a no, it's a no, and it won't drag you out. This rhythm is addictive, but the side effect is: you get accustomed to short feedback loops, and when you go without feedback for a while, you start to get anxious.

When you actually build your own product, you realize this is a completely different lifestyle from sales. The first few days might still have exciting feedback; then you enter a long "silent" phase. During this time, a huge amount of work appears to produce no output—but in reality, you're laying foundations, doing finer breakdowns of user pain points, waiting for round after round of experiments to yield results. No one externally gives you hourly feedback; when family asks what you're busy with, you can't explain it in one sentence.

I previously underestimated how draining this "feedback-scarce" state is for a person. I used to think the loneliness of product people was the exclusive domain of a few "masters"; now I believe more strongly that it's the fundamental nature of this profession. It's just that most people don't survive this stretch, so there aren't many good products to begin with. This also incidentally explains why the term "good product manager" is so scarce: it's not that people lack ideas, but that most people don't endure the middle stage.

So

I think the real benefit vibe coding brings isn't making product building easier; it's making "getting started" easier. In the past, wanting to build something and just setting up the environment was enough to turn away half the people. Now that half is no longer deterred.

But the road from "getting started" to "getting it done"—it hasn't walked that for you. What determines who can make it is still the same old things: whether you have a direction you truly care about, whether you can endure the stretch where others can't see what you're doing, and whether you're willing to repeatedly fix the same thing. These sound clichéd, and they are—because they're right.

I'm not writing this today to encourage people to become obsessive. It's a reminder to myself and to those in the same boat: if the product in your hands is getting no external feedback for a long time, it's not because you're doing it wrong—it's because this stretch is inherently long. If you can keep going, keep going.

After GitHub Became Like Xiaohongshu: Building Products Has Become Even More Lonely

Likes Take Seconds; Products Don't

The Hard Threshold of Infrastructure Products

The Invisible Road in the Middle

Looking Back at Those Who Endured

What Vibe Coding Hasn't Changed

My Own Experience

So

References

Recommended Reading

Subscribe to Updates

Comments