I'm recently seeing more and more Ruby projects that are at least partly vibe-coded, and I'm kind of torn. On the one hand I appreciate that this allows people to create stuff that they maybe wouldn't have the time to do otherwise. On the other, the code itself makes it harder for people to contribute, especially those, like me, who don't use coding agents.
A random example:
https://github.com/amatsuda/rubish/blob/master/lib/rubish/pa...
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? Does this mean you have to use a coding agent in order to contribute? I felt the same about the recent Ruby compiler from matz [1]. The code looks impenetrable. What does this bode for the future of OSS?
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.
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.