Deleting files is easy. Decommissioning production services is not. It's too early to say for me, we've only decommissioned one vibe-coded service at my Day Job and it wasn't any worse than decommissioning any other legacy service has been. But it became legacy much faster - a couple of months.
I just delete it and go back to the commit if it matters in the future or generally if the code changed a lot just ask the probs newer smarter model to make the file again
Hmm, hence the issue. It’s like chopping down a tree to make a box of matches. I wish the next generations of models don’t rely too much on markdown documentations which seems to be a human way of not writing code. Sometimes the code is just a little bit more structured to be honest , often times I feel like I might as well just write the code.
Deleting files is easy. Decommissioning production services is not. It's too early to say for me, we've only decommissioned one vibe-coded service at my Day Job and it wasn't any worse than decommissioning any other legacy service has been. But it became legacy much faster - a couple of months.
What does that mean. Taking them down because the project failed or just replacing it?
Replacement. Getting all customer requirements and migrating them to a superior service implementation.
I just delete it and go back to the commit if it matters in the future or generally if the code changed a lot just ask the probs newer smarter model to make the file again
Hmm, hence the issue. It’s like chopping down a tree to make a box of matches. I wish the next generations of models don’t rely too much on markdown documentations which seems to be a human way of not writing code. Sometimes the code is just a little bit more structured to be honest , often times I feel like I might as well just write the code.