Comment by marstall
14 days ago
Let's take that vibe coded product and iterate what it gave you 100 times, as you tweak it to fit your vision. When you do that 101st iteration, can you prevent it from breaking something else, or changing it in a way you don't like it?
What if it doesn't understand what you're asking it to do and keeps failing and you have to keep rolling back? Can you understand the 20,000 lines it's generated so you can make the change yourself without tearing your hair out? Can you fix bugs in it that it can't, without starting from zero and having to understand the whole codebase?
To guard against this, the best course of action is probably modularization and composition, right? The Unix philosophy, ie building small, focused tools out of small, focused tools.
yes - i've thought that could work. returning to a more protected object oriented programming model (with hard-defined interfaces) could be a way - "make these changes but restrict yourself to this object" etc.
If you take the author's arguments on face value, you just hit YOLO button and have one iteration and publish it to production fast so you are on the market before competition does the same.
Just run it a 102nd time to fix the error from the 101st time, obviously /j