Loren_SL
21 minutes ago
Have agents write scratch output outside the repo, while anything that matters lives in version control. That way you can purge the scratch files whenever you like.
Item id: 49959703
21 minutes ago
Have agents write scratch output outside the repo, while anything that matters lives in version control. That way you can purge the scratch files whenever you like.
4 hours ago
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.
4 hours ago
What does that mean. Taking them down because the project failed or just replacing it?
4 hours ago
Replacement. Getting all customer requirements and migrating them to a superior service implementation.
4 hours ago
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
4 hours ago
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.