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.
I’m usually trying to find the smallest practical change to accomplish my goal: giving them less to review / consider, and keeping the architecture close to their preferred style.
Maybe that changes in the AI coded future
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).
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.
I actually find, for some reason, that LLMs seem to be able to be more "creative" when it comes to Ruby (having used LLMs across 4-5 languages). I don't mean hallucinating, but crafting solutions I would not have thought of, even if I've ensured that I've inserted my original thinking at the beginning.
I wonder if there is something about the combination of the expressiveness of Ruby and the way LLMs are closely tied to human language that brings that out. Of course, usual caveat: n of 1 on my own experience, and a dose of bias.
There are indeed so many compelling arguments against using Ruby these days (e.g. performance, type safety, an increasingly small user base), & yet I continue to reach for it because of this effortless expressiveness (& the maturity of the ecosystem).
I know the bot's not sophisticated enough to metaprogram anything, it writes straightforward code that's easy enough on the eyes, if not to my standards of style.
The idea is eventually I want to build the tooling to where I can actually start writing code again. That code will be ruby.
Testing anything in Ruby is dead simple, and agents are very good at writing the tests.
The REPL is also a big win for agents. Reproducing a bug, or exploring how to build a feature, agents can get a lot of mileage out of a rails console.
A lot of the developer ergonomics are just as helpful to agents.
The performance of Ruby sucks, though.
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.