LUMP Depot
There are a few different ways people mean "vibe coding." It's not one thing.
If you're the kind of person who can actually architect and ship software, you already know the expensive part isn't typing. It's thinking.
Before you write a line of code you pay twice.
You pay to come up with the plan: what the thing is, where state lives, how you deploy it, what breaks first, what you won't build, what can wait, what absolutely cannot.
Then you pay again to decide if it's worth trying at all. You can be right about the architecture and still build a product nobody wants. A lot of investment happens before you have anything to show for it.
Vibe coding deletes the prototype cost. That's the whole appeal. You can get to "does this even feel good" in a night or two.
But the money doesn't disappear. It moves.
What vibe coding really buys you
If you use it as a prototype machine, it's incredible. You can explore ten ideas and throw nine away without feeling like you burned a week of evenings.
If you use it as a production machine, you're taking out a loan. The interest rate is maintenance debt.
And this is where the modes matter, because the debt profile changes depending on what you're doing.
Mode 1: Sketching
Sketching is when the output is disposable by design. You're trying to see the shape of the thing.
You're not committing to an architecture, you're discovering one. You're looking for the "oh that's the problem" moment, not the "this will scale" moment.
This is the cheapest, healthiest vibe coding. Throw it away. Keep the insight.
Mode 2: Prototyping (with intent)
Prototyping is when you have a plan but you want proof before you invest. It works best when you keep the boundaries clean: one feature, one surface area, one demo, one week of reality.
You can decide the prototype is a dead end and stop. Or you can decide it earned the right to become real.
The trap is when you don't decide. The prototype becomes the product by inertia.
Mode 3: Shipping a lottery ticket
This is the spicy one. You ship something that mostly works because shipping is the point. It's not "should I build it?" It's "how fast can I get it out there?"
Honestly, do it. Go bonkers. Building it will take a night or two.
But once you ship, you didn't change the question. You just delegated a mountain of work to your future ability to climb.
Can you support it if it works?
What vibe coding removes is the cost of the first draft. Where it comes due is after people touch it.
Are you willing to throw it out into the world, then fix bugs as they come in?
If you run out of tokens for the week, will you be unable to fix a showstopper error? That sounds silly until it's 2 AM and someone is texting you a screenshot of a blank screen.
These are fundamentally different questions than "should I build it?"
If it goes well, what can go right?
People ask "what can go wrong" because it's the obvious fear.
But success is its own problem. If this gets traction, are you ready for the boring parts?
Logging. Monitoring. Backups. Migrations. Edge cases. The second payment: you reading through all that code and turning it into something long term.
Or are you going to ride on a prototype and hope it becomes somebody else's problem?
Maintenance is the adult part
I think for now, "ship it and pray" can work, if your goal is to sell out to the man. It's like buying scratch-offs and calling it a retirement plan.
But after a while the moltbooks of the world won't be the rule. They'll be the case study.
tl;dr: Vibe coding is great at making prototypes cheap. Just don't confuse "I can build this" with "I can support this." The build is a weekend. The maintenance is the relationship.