48 hours. Less than 10,000 lines of code. End-to-end, it worked.
I picked up that small device, deployed a model that had been released just two days prior, and watched the inference results roll in. The feeling in that moment was strange—not excitement, not a sense of accomplishment, but more of a dazed, "Oh, so this actually works" kind of feeling.
By the way, I don't know how to code at all. I've never done software development.
And before this 48-hour sprint, I had gone through another 10-day marathon—producing nearly 300,000 lines of code, then deleting almost all of it.
That experience has stayed with me for a long time.
How It All Started
It all started with the release of Claude Opus 4.6.
The first time I used it, I was genuinely shaken. Not the "wow, this is amazing" kind of shaken, but the "wait, just how far can this thing go?" kind.
An idea popped into my head: could I get it to help me build a project from scratch?
I roughly explained my idea, and it wrote up an architecture document for me, then started developing. Two days later, we had a prototype. Watching it write code line by line, I felt something indescribable—like watching a stranger build a house for me. I had no idea if the house was structurally sound, but there it was, standing.
As we kept going, I started pondering a question: how could I get an AI working for me 24/7, actually creating value?
I saw two paths: first, letting it compare the architecture doc against the code, find opportunities on its own, and implement them; second, running massive amounts of real-world tests on actual devices with real operations, letting it observe bugs, fix them itself, until the entire pipeline was running.
In retrospect, both paths were a bit naive. But at the time, I genuinely thought they were feasible.
So I began a wild experiment. I was traveling, so I orchestrated the entire development process remotely via SSH + tmux from my phone. I burned through an absurd number of tokens—I won't say exactly how many, because it still stings a little.
Over 10 days, the project accumulated nearly 200,000 lines of Go code plus 100,000 lines of test code.
It had become a massive mountain of code.
And the strangest part: during those 10 days, I never once actually tried the product hands-on. I just had it write code, reviewed it, and had it write more.
Is More Code Better?
When I finally stopped to actually test it, the problems emerged.
The most basic primary pipeline simply didn't work.
I was stunned for a moment. 300,000 lines of code, and the basic pipeline was broken.
I had the AI fix things based on the test results. Fix, test, test, fix. Back and forth, and finally the pipeline ran through. That moment felt pretty magical—after all, I'm a technical outsider, and in 10 days I had actually gotten a complex platform software to run.
But soon, I discovered a deeper problem: even the smallest change required an absurd number of tokens.
Making changes in a 200,000-line codebase was incredibly difficult. It was like trying to move dirt on a mountain of shit code—slow, often ineffective, and expensive. I watched the token costs climb rapidly and started to feel uneasy.
I started to reflect: these 200,000 to 300,000 lines of code were cranked out in 10 days, and it seemed like most of them weren't actually creating value. I had been coming up with features on the fly, having the AI implement them, reviewing them, and then moving on to more development and testing.
This wasn't creating value. This was piling up liabilities.
Tear It Down and Start Over
I made a decision: start a new project from zero.
It wasn't an easy decision. Deleting 300,000 lines of code hurts a little. But the more I thought about it, the more I realized keeping them would be the real waste.
This time, I spent a long time having deep conversations with Claude Code.
I asked it: what core problem am I actually trying to solve? What social value does solving this problem create?
To be honest, my initial motivation was simple—I just wanted to vibe code something similar to what my company built last year, show it off to surprise people, and prove that someone with absolutely no coding background could still build something decent. A bit of a show-off mentality, I admit.
But now my mindset had changed. I wanted to do something truly meaningful, solve problems that actually matter to society and the world.
How did this shift happen? I can't quite say. Maybe it was the moment I deleted those 300,000 lines of code that I suddenly realized: if what you're doing is meaningless, then no amount of code is anything more than self-indulgence.
We went back to the core process of building a product: writing the MRD, writing the PRD, and only then architecture design.
During the architecture design phase, I spent a lot of time doing deep research—selecting architectural components, understanding what could be used and what shouldn't be, making critical decisions.
I gradually came to realize something:
In the era of Vibe Coding, implementation has become incredibly fast, so the impact of product design, philosophy, principles, and architectural choices has become enormous. In just 10 days, an AI can grow a plausible-looking mountain of shit code. Every subsequent investment then becomes a continuous, massive waste.
This time, I became much more deliberate.
Every line of code is actually a liability, not an asset.
Because the more code you have, the harder it becomes for an AI to maintain.
48 Hours of Restraint
Later, I spent half a day plus a night building an architecture and product that I felt had real meaning and value.
I documented the problem, the innovation, and the design philosophy—all written down inside the project.
During development, at around 5,000 lines of code, I started doing real testing on the most core functions and components. I brought in heterogeneous hardware, engines, and models early for real-world validation.
Before every change, I would ask: does this violate the design principles and philosophy I explicitly wrote down?
I often had to rework things.
The process was genuinely painful. I realized that even a powerful model like Claude Opus 4.6 isn't all-powerful. Maintaining restraint and simplicity really takes a lot of time—laying the foundation over and over again. Sometimes I'd revise something back and forth so many times that I started to wonder if I was being too exacting.
But it turned out that this rigor was exactly what was needed.
48 hours later, end-to-end, it worked.
One-click model inference deployment on the device. We tested some new capabilities—a model that had just been released two days ago, running on our little box.
The feeling was truly strange. Not excitement, but a grounded sense of "Yes, this is the right path."
And at this point, the project's codebase wasn't exaggerated at all. For the AI to maintain, change, and understand it was still reasonably cheap and fast.
I concluded: this thing is actually viable.
Is Vibe Coding Really Easy?
Throughout the process, I found that collaborating with a coding agent was actually much more exhausting than coding myself.
It's easy to enter a flow state—when one Claude Code session is waiting, you open another. Stuck? Open another. Constantly cycling back to check each session's progress, clearing blockages, correcting course when things drift off track, and thinking through the impact on the overall system.
After five or six hours, it feels like you've played an intense video game while triple-boxing it solo.
Brain fogged. Body drained.
I used to think vibe coding was easy—let the AI do the work while you relax. Only after doing it did I realize it's not like that at all. It's more like transforming from "the person writing code" to "the person managing five people writing code simultaneously"—you don't write it yourself, but you have to do far more judging, coordinating, and decision-making.
It really is exhausting. But also addictive. Later, when I wrote about the bottleneck in AI startups, I mentioned that physical stamina might be the most underestimated bottleneck.
Epilogue
10 days to pile up 300,000 lines of code, then delete them.
48 hours, less than 10,000 lines of code, and it worked.
Vibe Coding isn't magic that makes things easier. It's a lever—it can amplify your efficiency, but it can also amplify your chaos. More lessons from failure later convinced me of this even more.
Now I ask myself one question: before I start, have I figured out what truly matters?
This is a question the AI cannot answer for me.