> Where are the interface boundaries? Why are there methods that are 200 lines long? This is not a dis at the author, and it's not really about "code quality" per se, whatever that means. It's just that if someone would like to study the code and be able to improve it or add features, how would one go about it?

Tbh that sounds like quite a lot of codebases from single developers rather than teams I've tried to look at over the years long before LLMs were a thing, and not specifically just for one language (although when it's in a dynamically-typed language it certainly increases the difficulty). Probably quite a lot of training code for LLMs was like this (the people who trained it have access to basically the entire set of code that I did, after all), and the way to avoid it is basically the same: someone has to just care enough to either not write it like this in the first place or take the time to fix it.

As someone who's for a while been a hardline "both developers and users of open source owe each other nothing" advocate (other than the basic human respect that I believe we all owe each other, and that's not specific to open source), I don't really see LLMs as fundamentally changing that calculus. People will create open source, other people will decide to use it or not, maybe to try to contribute back or not, and the maintainers will decide to include those contributions or not, maybe someone decides to fork it, or write a replacement for it because they can't stand the choices or the code of the original, and all of that is basically how things are supposed to work. The system isn't perfect, but I'm not sure what the alternative would be, because putting any further obligations on either side would create worse problems than the ones they solve.

(Some people will choose not to release the source code for their projects instead, and that's fine too, even if in the long run I'm sometimes sad at the result of "this thing that I'd like to run doesn't really support being run in the way I want, and the author is long gone and probably wouldn't even be inconvenienced by my own personal modifications that I don't have any need to distribute". Lots of people will make choices that I wouldn't personally make, but that doesn't inherently make them bad, because other people understanding the rationale is not a particularly good measure of whether something should be allowed or not compared to, like, whether you're actually hurting anyone by doing it).

I think i can handle this code by hand in fact it’s better than code I have handled by hand. (at a cursory glance.)

In my day - I think it was around 2000 – I was handed a 5000 line perl script that both responded to CGI bin requests to run a store and kicked off fulfillment of the orders. Inside that script, it had two 1500 line long subroutines that sometimes navigated internally via goto.

We refactored, and added new features while a profitable business ran on top of the code. You don’t get quite the velocity you do on good code, but it’s manageable.

Honestly I don't know why would you choose ruby for vibecoding.

This is a language that explicitly sacrifices important stuff like the strength of automatic checks possible and performance in lieu of developer ergonomics. Even if you support that particular choice, chosing the language when you won't be writing or reading most of the code is a pretty poor tradeoff.

Well it may not life up to uncle Bob's clean code standards but it does fit the repo's name, doesn't it?

It's especially unfortunate because there are great tools (like rubocop) that coding agents can respond to, and actually generate very readable, maintainable, and contributable code.

I think this will improve, but I also think your comment is important for people using agents to read. Speaking for myself, I want people like you to be able to read/understand/contribute to my projects should you desire, so this is a great reminder for me.