[QuantumNoodle]

> Disclaimer: This project was entirely vibe-coded. I've never written Swift before in my life

Something I've wondered - but not had much empirical evidence for - is if entirely vibe-coded projects are difficult to maintain. I, too, don't know swift so I cannot look over the codebase to gauge this. I am curious if any swift savants out there can weigh in.

Furthermore, I will follow the project and keep an eye out for patches/discussions and try to discern any friction and/or loss in momentum because it is difficult to work with (e.g. more bug/feature tickets than PRs, etc.). I am aware it might fizzle out on its own, irrespective of the quality of the codebase. This will be a curious exercise for me. This may be my first empirical data on this topic - sadly on vibe-coded & maintainability, not the project itself.

[hauxir]

They most definitely are.

However this project is so simple it's more akin to a script. Really not that hard to grasp despite not knowing swift.

Also vibe coded an android tv version and used this codebase as input ;)

https://github.com/hauxir/androidtv-live-screensaver

[runjake]

Indeed I was able to read through it's 555 lines in about 4-5 minutes. Nothing seems too ghastly -- it's a pretty good vibe coding job.

[diob]

I think they're just as maintainable as any other legacy app you might encounter. As in, it can be hard. But it's doable. And it depends on the team that made it (AI + the human).

[Someone]

> is if entirely vibe-coded projects are difficult to maintain

Vibe coding is too “Hail Mary” to me, but if you’re into it, I would think the best way to do that is by giving a LLM the git history of the project with each commit contain the prompt that created it and, if a human tweaked things, requiring that human to provide a good commit comment.

Then, you could give a LLM the git repo, instructions on what change you want to see, and have it create the next commit.

[dylan604]

> requiring that human to provide a good commit comment.

Is this enough? Personally, I have a what very well may be a bad habit of mine that doesn't necessarily check git commit messages. When I'm working in a code base, I just never think about scrolling through those hoping to find where this bit of code was changed. I'd much rather have comments in the code itself. It seems better to me to save the maintainer time and effort. Maybe I've just taken too seriously the idea of "assume the maintainer after you will be a serial killer that knows where you live. don't make them angry by being lazy"

[reaperducer]

I wonder if certain languages are easier to vibe code than others.

My supposition is that the better documented a language, the easier it would be for the LLMs.

Or is it the opposite: The more obtuse a language, the more StackOverflow questions, the easier it is for LLMs to work with.

[QuantumNoodle]

I've had success vibe-coding things that, I would imagine, make up more of the training dataset - more common. When I try to do more specific Linux systems programming it is pretty trash, especially with newer languages.

[grimgrin]

this is kinda inline with what you're asking i think?

https://simonwillison.net/2025/Oct/7/vibe-engineering/

for me it's working on a thing, and then linting, type checking, running tests. and even then thoughtfulness still required