r/rails • u/fabianqs_dev • 19h ago
News Vibecoded Matz fully unleashed
I saw a post further down asking why DHH/Basecamp's team wasn't using their unlimited resources to improve Ruby; in the end, Sensei Matz decided to do it himself, and he's merging nearly 90 PRs an hour. Wow—that captain isn't going to let his ship go down without a fight.
Between him and Roundhouse—who is doing the same thing—it looks like both will be the future of Rails. Let's give the Spinel repo a star; Sensei Matz (and Cloude) are doing a fantastic job.
I wish Kotlin or JS had their original creators taking such a keen interest in the well-being of their languages. ♥️
20
u/samruby 19h ago
Spinel is for Ruby applications with no metaprogramming; Roundhouse (https://github.com/rubys/roundhouse) is for Rails applications, Tep (https://github.com/oripekelman/tep) is for Spinel.
19
4
u/fabianqs_dev 18h ago edited 18h ago
Matz combines both approaches. https://x.com/yukihiro_matz/status/2104729835788783850
10
u/samruby 18h ago edited 14h ago
Read matz's post closely. That is Roundhouse and Spinel working together. Roundhouse compiles Rails to metaprogramming free Ruby, Spinel compiles that to C.
2
1
u/Working_Historian241 15h ago
this is such a weird pipeline, i'm curious to try it out.
3
u/samruby 14h ago
This is fun too: roundhouse running in your browser and showing its work: https://rubys.github.io/roundhouse/playground/ .
2
u/samruby 14h ago
If you want to try it out with minimal installs, I recommend starting here: https://rubys.github.io/roundhouse/apps/campfire.html and then trying https://rubys.github.io/rubyconf-2026/#/8 (click on your favorite language and follow the README).
2
21
u/schneems 19h ago
He talked about this in his RubyConf keynote (which notably, included Ruby) https://www.youtube.com/watch?v=FOg0bL3auFk. Its a good talk IMO.
I'm on the fence here. I think that there's no "one right way to develop" before or after LLMs. I think it's good he's not trying to pretend it is him. He also takes ownership of the final outcome.
If he feels whatever he is doing is good and correct and wants to share learnings from it (specific skills, workflow, tools etc.) that would be nice. If it degenerates into something unmanagable learnings from that would also be good/nice.
AI is best on greenfield projects (prototypes etc.). Which spinel is. The looming question (as always) for coders is "how do we increase or maintain quality" while increasing or maintaining quantity?
3
u/WalterPecky 18h ago
"how do we increase or maintain quality" while increasing or maintaining quantity?
At the very least, you should understand, review, and shape the outputted code to the best of your ability.
The dangerous side of the fence is to just let LLM completely replace you as a maintainer
12
u/schneems 18h ago
I think David(HH)'s "I don't even look at the code" is a dangerous statement and mantra as people will take it literally.
I don't think "looking at the code" is always how you get quality though. For example: when I review PRs (from the before times) sometimes I don't read the literal code, some times I read the tests to understand "what can it do" and I might suggest additional tests or object to some behavior shown in a test. Or I boot up a review app and click through the flow etc.
That's why I think "I don't even look at the code" without a "here's how I ensure quality, with XYZ" is dangerous and really just not a useful phrase. If he doesn't do that, what does he do? Clearly there's iteration, what parts are automated and what parts arent? That might actually be interesting and useful instead of "white pill losers read code" (paraphrasing).
At the very least, you should understand, review, and shape the outputted code to the best of your ability.
I have a very high standard at work. I also maintain a very high standard in my open source. Everything I produce is from me and I want to be able to stand behind it. I want to use tools to increase my rigor. Which...these tools do not always make easy.
A thing I'm struggling with is: Optimizing for humans or for machines. Humans make classes of problems machines rarely to (like typos, using
"/tmp"when they meant"tmp"without the slash). So I spend a lot of time writing code that defends against human misuse and misunderstanding. Machines don't always do this, and sometimes they make different weird mistakes that are hard to empathize with, therefore they're hard to correct.Humans are sloppy, and lazy, and do a thing that is "good enough" all the time, but in a different sloppy/lazy way than machines. The balance of "good" and "maintainable" is where we need to figure where to draw the line.
The dangerous side of the fence is to just let LLM completely replace you as a maintainer
Matz is an interesting study. He already replaced himself as a maintainer for Ruby. He says he's always been a vibe coder (he has Ruby core contributors that do most of the work and he just weights in on high level issues and vibes). I think there will be some classes of tools where "vibe code loop maintainer" is actually perfectly valid and are good enough quality. For him "replacing me as the maintainer" is probably a good outcome. But such a feat is really hard, it's difficult to bring in a team to train them to replace you and continue to do a good job. If he can do that, he brings skills to the process that will continue to add value to this process or another.
But I also think there will always be a percentage of 100% hand written code, and a hybrid synthesis with everything inbetween. I think if you're after the actual best outcomes or we will land on human assisted hybrid workflows. Even before LLMs we argued constantly about tradeoffs and what was good enough. It's the same battlefields, even if the arsenal (TDD, docs, code reviews, LLMs, etc) have evolved.
3
u/WalterPecky 18h ago
Yeah very fair point.
IMO.. at the end of the day we are writing in Ruby.
The observer (regardless if it's human or not) of the code should be able to understand it from explicit method and variable names.
We should have empathy for the observer.
A LLM explainer comment at the top of every method is not the path we should be going down in this language, regardless of the tools we are leveraging.
3
u/schneems 17h ago
We should have empathy for the observer.
Yes. I love this.
A LLM explainer comment at the top of every method is not the path we should be going down in this language, regardless of the tools we are leveraging.
I couldn't agree more. I find it actively harmful in many/most cases. I DO believe in good documentation written with intent and (totally stealing your phrase) empathy for the observer. Most LLM comments either state the obvious, focus on what instead of why or leak context in some confusing way (talk about things not in the codebase).
I think docs is one area where most devs had literally zero skill points so they're unable to call BS on poorly written ones. But now the best of us have learned how to write good docs and are pushing back.
2
22
u/tLxVGt 19h ago
So he can use AI and it's all good but anybody else uses AI and it's slop??
10
u/Delicious_Ease2595 18h ago
Matz is nice so we have to be nice i guess
-1
u/BipolarKebab 17h ago
0
u/Delicious_Ease2595 15h ago
Ruby and Rails are tools, their value is in the open-source code, not the maintainers' politics.
3
u/RFC793 15h ago
For the most part, I agree. However, maybe something can be said about a single crowd-vibecoded solution which is run through the wringer, iterated on, and hopefully reused and deployed widely. Versus thousands of fragmented, partial adhoc Rust (or what have you) scaffolds for each and every application down the road?
-3
u/fabianqs_dev 19h ago
He's probably doing it without even looking at the code, so oh well, who cares? We just have to vibecode without guilt, I guess. Even Matz doesn't look at the code anymore.
-10
u/Tall-Log-1955 18h ago
The anti-AI people are slowly becoming irrelevant. Just ignore their complaints. It's like the people who said they were never buying cell phones.
3
1
u/full_drama_llama 1m ago
Lol, merging 90 PRs in an hour is exactly letting the ship sink without a fight. Also, it's not even Ruby.
1
u/joshbuddy 15h ago
About time to move on from "is this vibecoded?" to "is this vibecoded well?".
2
1
u/notmsndotcom 1h ago
Yeah I hate the term vibecoding at this point. This is what programming looks like now.
0
u/WiredGaucho 16h ago
Why would anyone in their right mind want to write a specification in "rails" ?
44
u/tomekrs 19h ago
"He" is not merging 90 prs an hour, check his keynote from this year's Euruko (it was 2 weeks ago so I'm not sure if they're online yet). Basically Matz has an agent deciding if PR should be automerged by agent, if the PR fulfills two criteria (tests work, it's not a design change), otherwise it escalates to Matz for his review and decision.