Programming

I'm perfectly happy with this.

Why?

Because at the end of the day, the users of the code forge can be broken up into three categories:

1. Traditional coders with human made projects
2. Vibe-coders who slop out 100 throw away projects, each of which is a dead project as soon as that user moves onto the next project
3. Vibe-coders who focus work on only a single project.

Category 1:

• Code forges were already valuable before LLMs, so we already have a proof of value/utility/whatever for hosting projects from users in category 1.

Category 2:

• Projects from the users in category 2 have a half life of a couple of weeks.
• They're so quickly made that most of their contents is going to be rehashes of previous existing content, so there's a reduced value holding on to them as reference when the original sources exist.
• Since they were generated so quickly, a more up-to-date version can be generated in the future if they're ever needed again.
• Since the projects aren't going to be used by others, they don't actually use the features of a code forge, so it's not a great idea to allocate so many resources that aren't going to be utilised to host them on a community code forge. A better place for them would be cloud storage (dropbox, google drive, etc...). Most cloud storage services have a free tier. Anyone with a crazy amount of projects and assets that would exceed free tiers and who just wants to hold onto the projects for the future can use something like S3's glacial deep archive which is about $1.20USD a year to hold onto 100GB of zipped up projects.

Category 3:

• These projects may actually get used by people
• Since they're developed with LLMs, there's so much churn that there's no actual point of reading the code since it's quickly out of date. That means there's no use for using the code forge's source file features
• Issues that reference code will go out of date as soon as the code goes out of date which is far more likely than with category 1 users.
• These projects tend to have so much code churn that their builds are more inefficient than hand coded projects. This means that they'll tend to want more powerful hardware to run their CI/CD pipelines than a community code forge can provide. So from their perspective, they're better off running their own code forge anyway.

Keeping category 1 users on community code forges, saving the code forge's resources from being used by community 2 users, and letting community 3 users tailor their own code forges for their own needs seems like a win for everyone actually using the community code forge, and not those treating it as a file dump.