48 hours, less than 10,000 lines of code, end-to-end working.
I picked up that small box, deployed a model that had been released just two days prior, and watched the inference results come through. The feeling at that moment was strange—not excitement, not a sense of achievement, but more like a dazed realization of "Oh, so it actually works."
By the way, I can't code at all. 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.
This kept me thinking 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 shocked. Not the "wow, this is amazing" kind of shock, but the "wait, what are the limits of this thing?" kind of shock.
A thought popped into my head: Could I get it to help me build a project from scratch?
I roughly described my idea, and it helped me write an architecture document, then started developing. Two days later, we had a prototype. Watching it write code line by line, I had an indescribable feeling—like watching a stranger build a house for me. I didn't know if the house was structurally sound, but there it was, built.
As I continued, I started pondering a question: How can I get AI to work for me 24/7 and actually create value?
I thought of two approaches: First, have it review the architecture documents and code on its own, identify opportunities, and implement them itself; second, do extensive real-world testing, run real operations on real devices, let it observe bugs itself, fix them itself, until the pipeline works.
Looking back now, both approaches were a bit naive. But at the time, I genuinely thought they were feasible.
So I began a crazy experiment. While traveling, I remotely controlled the entire development process via SSH + tmux from my phone. I consumed an absurd number of tokens—I won't say exactly how many, it's a bit painful to admit.
In 10 days, the project accumulated nearly 200,000 lines of Go code plus 100,000 lines of test code.
It became a massive mountain of code.
And the weird part: During those 10 days, I never once actually tried the product hands-on. I just had it write, reviewed it, and had it write more.
Struggling on the Shit Mountain
When I finally stopped and started actually testing, problems emerged.
A fundamental core pipeline simply didn't work.
I was stunned for a moment. 300,000 lines of code, and the basic pipeline didn't work.
I had the AI fix things based on test results. Fix, test, test, fix. Back and forth, finally got the pipeline working. That moment felt quite magical—after all, I'm a technical outsider, and in 10 days had actually gotten a complex platform software running.
But soon, I discovered a deeper problem: Any small change required an absurd number of tokens.
A 200,000-line codebase is incredibly difficult to modify. Like moving earth on a shit mountain—slow, changes often ineffective, and expensive. I watched the token consumption climb rapidly, and started to panic.
I started reflecting: These 200-300K lines were cranked out in 10 days, and it seemed most of the code wasn't actually creating value. I had just been thinking of features and having it implement them, then review, then continue developing and testing.
This wasn't creating value. This was accumulating liabilities.
Tear Down and Rebuild
I made a decision: Start from zero, rebuild the project anew.
This wasn't an easy decision. 300,000 lines of code, deleting them just like that, it hurt a bit. But the more I thought about it, keeping them would be the bigger 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 have?
Honestly, my initial motivation was simple—I just wanted to vibe code something similar to what the company made last year, pull it out to shock everyone, prove that someone with absolutely no coding background could build something decent. A bit of showboating, I admit.
But now my mindset changed. I wanted to do something truly meaningful, solve problems that actually matter to society, to the world.
How did this shift happen? I can't quite say. Maybe because when I deleted those 300,000 lines, I suddenly realized: If what you're doing has no inherent meaning, then no amount of code is anything but self-gratification.
We went back to the core process of building a product: writing MRD documents, PRD documents, 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, making key decisions.
I gradually realized something:
In the Vibe Coding era, implementation becomes fast, so the impact of product design, philosophy, principles, and architectural choices becomes enormous. In 10 days, AI can develop a plausible-looking shit mountain of code. All subsequent investment becomes continuous, massive waste.
This time, I became much more careful.
Every line of code is actually a liability, not an asset.
Because the more code there is, the harder it is for 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 meaning and value.
I documented the problems, innovations, and design philosophy—all written into the project.
During development, at around 5,000 lines, I started doing real testing on the most core functions and components. I brought in heterogeneous hardware, engines, and models early for real validation.
Before every change, I would ask: Does this violate the design principles and philosophy I explicitly wrote down?
Often had to rework and fix.
This process was genuinely painful. I realized that even a powerful model like Claude Opus 4.6 isn't actually all-powerful. Maintaining restraint and simplicity really takes a lot of time, repeatedly laying the foundation. Sometimes fixing one thing took several back-and-forths, and I started wondering if I was being too nitpicky.
But it later proved that this nitpicking was right.
48 hours later, end-to-end working.
One-click model inference deployment on the device. Tested some new capabilities—a model released just two days ago, running on our small box.
That feeling was truly strange. Not excitement, but a grounded sense of "Yes, this path is right."
And at this point, the project's code volume wasn't excessive. AI maintenance, changes, and comprehension were still not expensive, not slow.
I judged: This thing is actually viable now.
More Tiring Than Actually Coding
Throughout the process, I found collaborating with a Coding Agent was actually much more tiring than coding myself.
It's easy to enter flow state—while one Claude Code is waiting, open a new one. Stuck? Open another. Constantly checking back on each one's progress, resolving blockers, correcting course when things go astray, and figuring out the impact on the global picture.
After 5-6 hours, it feels like playing an intense video game, and specifically like multiboxing three characters at once.
Mind is dazed. Body is drained.
I used to think vibe coding was easy—let AI do the work, you kick back. Only after doing it did I realize it's not like that. It's more like going from "the person writing code" to "the person directing five people writing code"—you don't write yourself, but you have to make more judgments, coordination, decisions.
Tired, truly tired. But also addictive.
Postscript
10 days to stack up 300,000 lines of code, then delete them.
48 hours, less than 10,000 lines of code, working.
Vibe Coding is not magic that makes things simple. It's a lever—it can amplify your efficiency, or it can amplify your chaos.
Now I ask myself a question: Before starting, have I clearly thought through what really matters?
This is a question AI cannot answer for me.
Originally published at https://guanjiawei.ai/en/blog/code-is-liability
Top comments (0)