The generated feature I shipped and then rewrote in a weekend
I vibecoded a feature that shipped and worked. Users liked it. I felt great about the speed.
Three weeks later I needed to change one thing about it, and I could not. The code was a knot. It worked, but only from the outside. Every attempt to modify it broke two other things, and I ended up rewriting the whole thing from scratch in a weekend I had not planned to give away.
The math is brutal. Two days to build, two days to rewrite. If I had spent four days building it properly the first time, I would have arrived at the same place with half the work and a fraction of the frustration.
I am not saying generate less. I am saying that speed borrowed from the future is still borrowed. The question is not whether it is fast, but who pays for it later.
Have you ever had to rewrite something you generated? And did it change how you build the next one?
Replies
What I found is that three weeks later the missing piece is usually not clean code but the reasons. Why is this check here, why does this run before that. The agent knew when it wrote it, and nobody wrote it down. So my project keeps one notes file per area of the app, payments, auth, each screen, and the rule for the agent is that a decision and its reason go into the matching file at the moment they are made, not in a commit message. Before touching an area, it reads that file first. The code can still be a knot sometimes, but untying it is much faster when the knot comes with an explanation. And small commits per finished step make it possible to see where the knot started.