3 ms·
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
by marstall 8mo 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?
- gavmor 8mo agoTo 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.
- marstall 8mo agoyes - 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.
- nickorlow 8mo agoJust run it a 102nd time to fix the error from the 101st time, obviously /j
- DeathArrow 8mo agoIf 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.