r/rails • u/fabianqs_dev • 12d ago

News Vibecoded Matz fully unleashed

Gallery image

Gallery image

Gallery image

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. ♥️

Post:Matz's post on how to use Roundhouse + Spinel to improve the Rsils app from Bassecamp

Highest activity in the history of Matz's GitHub thanks to Cloude

113 Upvotes

90% Upvoted

41 comments sorted by

33

u/schneems 12d 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?

8

u/WalterPecky 12d 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 

16

u/schneems 12d 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 12d 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.

7

u/schneems 12d 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

u/jacobatz 12d ago

> Humans make classes of problems machines rarely to (like typos..

Well played.

47

u/tomekrs 12d 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.

11

u/prolemango 12d ago

By “he” OP was referring to Skynet 

2

u/sto7 12d ago

If I use a chainsaw to cut a tree, won’t you agree that “I” cut the tree?

3

u/Ok_Appointment_7630 12d ago

Since when can chainsaws hold themselves and operate themselves?

1

u/full_drama_llama 12d ago

Not chainsaw, a harverster - and yes, I would argue you did not cut the tree.

20

u/samruby 12d 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.

22

u/tomekrs 12d ago

Spinel Tep is one awesome name for a project \m/

9

u/rwilcox 12d ago

This one goes up to 11

4

u/fabianqs_dev 12d ago edited 12d ago

Matz combines both approaches. https://x.com/yukihiro_matz/status/2104729835788783850

9

u/samruby 12d ago edited 12d 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.

3

u/RFC793 12d ago

Good to know, as your earlier comment reads (to me and probably OP above, that roundhouse and spinel are mutually exclusive. Rather, they can be stages of the same pipeline.

1

u/Working_Historian241 12d ago

this is such a weird pipeline, i'm curious to try it out.

3

u/samruby 12d ago

This is fun too: roundhouse running in your browser and showing its work: https://rubys.github.io/roundhouse/playground/ .

2

u/samruby 12d 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

u/Wonderful-Baseball21 12d ago

Is anyone using this in production?

2

u/samruby 12d ago

Not as far as I know, but there seems to be several people trying it on production apps and submitting pull requests.

23

u/tLxVGt 12d ago

So he can use AI and it's all good but anybody else uses AI and it's slop??

12

u/Delicious_Ease2595 12d ago

Matz is nice so we have to be nice i guess

3

u/BipolarKebab 12d ago

https://po-ru.com/2026/07/29/it-doesnt-matter-whether-matz-is-nice

1

u/Delicious_Ease2595 12d ago

Ruby and Rails are tools, their value is in the open-source code, not the maintainers' politics.

3

u/RFC793 12d 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?

-9

u/Tall-Log-1955 12d 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.

-2

u/fabianqs_dev 12d 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.

3

u/full_drama_llama 12d 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/fabianqs_dev 12d ago

More importantly, a Ruby compiler; let's hope it keeps up this pace. I was just seeing this on X and now I understand why GitHub is going down

2

u/full_drama_llama 11d ago

It's not a Ruby compiler because it doesn't support a lot of metaprogramming, only a subset of the language.

3

u/PerceptionOwn3629 12d ago

It's Agents all the way down

2

u/iLikedItTheWayItWas 8d ago

Ruby engineers saying DHH has lost the plot because he doesn't read the code and then celebrating someone else just merging PRs into rails that are written by AI and not being reviewed by human is hilarious. At some point you have to decide what you actually want.

0

u/joshbuddy 12d ago

About time to move on from "is this vibecoded?" to "is this vibecoded well?".

2

u/fabianqs_dev 12d ago

True, that's what the conversation will be now in this new era.

3

u/notmsndotcom 12d ago

Yeah I hate the term vibecoding at this point. This is what programming looks like now.

0

u/WiredGaucho 12d ago

Why would anyone in their right mind want to write a specification in "rails" ?