[moshib]

At my $CORP job, I often see engineers enamored with creating new things. I completely understand the appeal -- it's fun to create something new, without preexisting constraints, with full ownership of the codebase.

However, the real challenge is what happens _later_, when the thing is done. Most people don't really think about maintenance, and move on to other things, making the thing they worked on stale and stagnant.

I think this applies here too: Vibe coding lets us create new _things_ quite easily, but we see value in places other than the sheer the existence of the project. We care about how the project is maintained, if it has a userbase, contributors, longevity. I think this is also part of why it feels so "cheap" and not genuine.

[redfloatplane]

Yes, indeed. I think that's why I haven't published much code in the last years since I vibe-code everything I build now and I have essentially no intention to maintain it once it's 'working'

[teiferer]

As an "AI" skeptic, let me ask an out-of-character question: Could such maintenance be automated or at least heavily simplified with coding agents? Looking over whether something breaks when gcc is upgraded, automatically updating if needed, updating best practices, automatically reproducing reported issues and proposing fixes ... too much of a dream?

[redfloatplane]

Yes, definitely some of it can be simplified or automated. I've been migrating various apps from a docker-compose to a kubernetes environment. Spending a day writing a solid prompt document and running some agent on the repos involved has drastically sped up my workflow.

The integration hell isn't much easier, but I spend _far_ less time actually writing configurations, yaml files, looking up docs, etc, which frees up my time so that I can deal with the workplace politics involved... actually, maybe I want to go back.