What About Rails? (jardo.dev)

there's an important caveat here - LLMs absolutely can write better code than me, but they can also write far worse code, and often don't seem to be able to tell the difference. I find myself spending a lot of time prompting the bots to refine their code in specific ways that I only know about because I read the generated output.

    but my anecdotal experience is that LLM written 
    software is very reliable and easy to extend and 
    develop.

Too much discourse creates a false dichotomy of "awesome, wonderful, hand-crafted code" vs "shitty AI slop."

A lot of hand-crafted code is pretty bad. This is true even with talented engineers: there are often edge cases they did not think of... and in many cases, could not have thought of.

And AI code is pretty good if it's steered and vetted by a knowledgeable engineer. It is clear to me, and has been clear for a long time, that "talented engineer plus AI" is the winning combination and will remain that way for at least the near future.

Same happened when the first smartphones came out, and everything was about "mobile first". Everyone will use their mobile phones for everything, desktop is dead, every app should be primarily designed for smartphones, everything comes after. Turned out smartphones just another interface that are good for some things, and not good for some other. Same for the "cloud native" movement.

I see this sentiment a lot, but UI has a greater purpose than just serving the customer needs, it also be used to shape them.

Imagine if instead of going to the grocery store, you called a number and told them what you needed. Sometimes you don't know everything you need. Sometimes you end up discovering something new and buying it even if you didn't plan on it.

I don't think that is what everyone wants, or at the very least its not what I want. My ideal software has a well designed and thought through user interface for the primary interactions, allowing me to think about the goal I'm trying to achieve rather than how I'm manipulating the underlying data model.

Additionally to that please also provide access to the underlying data. Ideally in the form of a locally accessible API but I'll accept a remote one if necessary, provide a CLI on top of that as well if you like.

A question becomes, how do you evolve a chat experience to task specific actions?

I’m building an app to explore scripture. Chat is an amazing starting point. But it’s terrible once you get into reading the actual scripture.

I think we will see more of this in the future. Here is how I’ve envisioned evolving an experience out of chat. Curious if others have their own ideas.

https://trysojourn.app

If the UI is completely local and the chat is not, then I prefer UI.

Even though most of my projects have a UI, I build a CLI/API version so that the LLM can interact with it directly. I have been using this "CLI driven development" approach for more than a year now and have had fantastic results. The CLI arguments make it easy for LLM to interact with software it wrote.

I usually ask LLM to build a lib, then expose as a CLI and a RESTful API.

For technically competent users, sure. but for everyone else the UI should just follow the principal of least surprise.

Words are a great UI. They can be easily converted into audio and haptics. We already have many systems in place that do exactly this with words.

Sure, pretty graphics are nice, but their sole intent should be to convey information. A User Interface that does not allow a person to easily have information conveyed to them is a bad interface.

The modern AI world isn’t perfect, but for a large portion of people who have accessibility needs, it’s absolutely a positive impact on their life in a way that no single technology has been until now.

A chatbot using an LLM of course not, it suffers from hallucinations, it may do what you want but there is a change it won't and you have to fight it to get the desired result.

Chatbots are far WORSE than traditional UI for everything. If some product has a chatbot functions it's the first thing I disable, if it's not possible to disable it, I avoid the product.

And GUI applications are typically preferred, at least for the normal people and not us nerds, to CLI applications, since you know people like moving a mouse and clicking on buttons (or tapping them on a touchscreen) that learning commands: a chatbot doesn't make the CLI experience less awful for the average user, and for the nerd user, he prefers to use the CLI directly (replace asking the chatbot with man or --help and you don't need to emit tons of CO2 and transmit your personal data to a datacenter on the other side of the world to do stuff you did with MS-DOS)

Never because a lot of software is written for the human to use.

The last thing people want is interacting with a chatbot for anything that doesn't require a chatbot.

> in terms of functionality and value to users, software ought to be malleable and composable.

No, it shouldn't. The last thing people want is for software to change from under them, or be replaced with the bullshit that is a chatbot.

> plaster a ‘programmable’ interface on top of unstructured data/interface meant for humans

Ah yes. I can imagine everyone "plastering programmable interfaces" on top of daily stuff they want to do. Like buying a ticket to a museum. Ordering Doorsash. Sending a meme to a friend. Renting a car...

It's all opportunity cost.

Edit: throw in mandated security audits and maintenance for SOC2 compliance or whatever else you're on too, depending on the industry you're in.

Also: the coded apps that AIs build are unmaintainable without a tech background. They may work for exactly their proposed happy-path and that may be great. But over time I can’t see how it’s possible these apps get maintained.

We're only a few persistent widgets and a better persistent storage story away from this possibility.

Tomorrow's software will need to be _perfect_, or else it won't differentiate from "Claude, build a basecamp-style project management tool for my team".

I’ve spent the last three years tweaking away at this algorithm. There are so many little details that have had to come together to make it an enjoyable experience. For example, take the one problem of balancing multiple language: What is the best way to balance multiple languages? How should you switch between them, and how often? What happens if you are over performing in one language and underperforming in another? What happens if you have more reviews in one language than another that isn’t in line with your priorities? How do you deal with competing learning speeds and language priorities? Spiky review burdens? What happens when you change your language priorities?

This is probably the most trivial part of the algorithm, and it took years of trial and error and dozens of iterations to get it to feel right. It requires knowing about SRS, the FSRS algorithm, language learning principles, and even then tons of experimentation, trial and error, and hundreds of days of daily usage.

I’ve asked LLMs every step of the way what to do. I’ve probably taken <1% of the advice I was given. Just asking an LLM “build an SRS app that balances multiple languages” would produce a result, but one that would definitely be terrible to use, and probably would end up slowing you down, not speeding you up. Explaining to it any of the issues that you would come across when using it will likely suggest to changes that will only make things worse, based on the thousands of terrible ideas I’ve seen confidently produced.

The hard part of a product is not the idea, but the experience of using it. The valueable work is normally not in the big feature specs, but the hundreds of little paper cuts that have all been smoothed over. The time saved is not because you don’t have to code it, but is from not having to become an expert in several different fields.

[1] https://phrasing.app

Claude can 100% build you your own basecamp quickly, but there is a lot of good thinking that has gone into a product. Edge cases. Integrations. Clarity of thinking and ways to extend it. Agents love standing on the shoulders of good crystalized cognition (grep, curl etc), but I think that extends even beyond base CLI tools.

Which is not to say that "cheapest alternative" won't be much more important than it is now, but the tools that will succeed are the ones that solve clear problems with accessible CLI/tool-call like interfaces and take significant load off the agent running, while doing it efficiently and cost effectively so they are clearly better than building it yourself.

To be fair, there will be a ton of margin collapse and that will be unachievable by a lot of current orgs / structures.

His whole argument which I agree with is summed up in a section where he shows a clip of himself 21 years ago saying “look at how much code I’m not writing” and that is the core thesis of rails. And agents provide a better solution than rails with less downside and more upside. So now that the core reason for rails has been overturned, instead of holding onto an old inferior solution to a problem, he has moved on because he is a value driven pragmatist at heart.

He literally built rails to write code as close to English as possible. Expressiveness, get code out of your way so you can focus on solving the non technical problems, stop getting stuck in engineering decisions and focus on business and UX, etc. Now whether his values were truly accomplished some people can argue but what those values are is pretty clear.

DHH created rails for himself and he has been unabashedly firm on his own values, it’s Steve Jobs esque, provides great clarity and focus but pisses people off who deviate from that focus.

Lots of people jumped on rails but don’t share DHH exact values. They see rails as a community ownership not a DHH ownership and they believe in the framework beyond just a tool to solve problems. More specifically they rely on it and helped build it up well beyond “just a tool to write code more like English” to a robust, well maintained usable platform you can build and run sophisticated real world applications with.

DHH has left rails because it no longer is the right solution for his set of values, that’s it. Others in the community rely on Rails to run their systems and will continue to do so until the end of time because let’s face it Rails has been pretty mature since rails 5/6 and despite all the exciting “progress” it’s just a solidly good framework that doesn’t really need to keep up with the trends.

The fact that he went on stage at a Ruby on Rails keynote and talked about his current passions instead of Rails is kind of typical for his style of leadership. The Ruby on Rails project and community were always the DHH show, even though there were years where they tried hard to act like it was an independent community run project now.

This late in the game, I think most RoR fans who are committed enough to attend a RoR conference have aligned themselves with DHH more than RoR, which is why you see some positive responses to a RoR keynote that didn't talk about RoR.

I'm now doubly-glad since it seems like, indeed, the bdfl has lost both the plot and the B. The fact that Omarchy is also some weird corporate-sponsored AI-pilled linux reskin is further concerning.

In retrospect, his jamming of things like thruster, hotwire, etc etc into the framework and then now basically abandoning them has me grateful I didn't adopt them, even though I thought they seemed pretty well-intended at the time.

In the talk he said all Hey's traffic can be served on a Raspberry Pi. I think that pretty much answers your question.

That is very not true for many cases. Agents generating code are usually painfully slow, finding workflows that replace that reasoning with running code usually speed things up in my experience.

The actual code and architecture is where it still lacking IMHO. Especially in rails... Like it will just build the least scalable features if you let it do it's thing. Ten queries for what could be one. No separation of concerns. Huge files, lots of duplicated code and then tens of thousands of units tests that just grow like a fatberg.

If your app does anything serious, if you have serious traffic... you are going to need to review each session finely (and your DB schema with each deploy). It could be that this is maybe an indictment of rails more than LLMs, I guess maybe time will tell.

This is lacking a lot of nuance. There are many types of code. There are many situations where I'm analysing something one-off and if I get 33% success ratio, but can easily verify the result, I'm happy - still saved me time and money. They're are situations where I'm generating graphs from some dataset and I don't have to trust anything - I know what the result should look like, I just need the agent to drive matplotlib. There are low stakes dashboards which I'm happy to generate and develop entirely via agents - they'll embed the updated screenshots in PRs that I can yolo-merge - worst case is that someone complains about something not working next time they visit. Then there's lots of experimenting which was never stopped to hit production anyway.

Finally after all of that you get code that's actually part of deployable features. Of course the trust is nowhere near 100%, but if you have a healthy testing process (e2e, validating different browsers, or whatever is appropriate for your environment), then what's your trust in human developer+review? Because mine is nowhere near 100% either.

In practice there are places where I extremely don't care about the code and never wanted it anyway, places where I'll read the code to check the design or just in case, and places which agents are not allowed to touch (medical billing rules for example).

My version of "code review" is "test failure investigation" and I have a hard rule in my repos that agents never modify existing tests while they're implementing features. This means that when I run the tests after they do a bunch of stuff, I see all the tests break. Mostly they're stale assertions and we patch them up. Sometimes they're regressions and we patch those up, and sometimes I notice something dumb and dive deep into a facet of the architecture that can be improved, spend some time exploring it then get the agent to implement.

I think it's a better approach than trying to read everything and catch bugs or improve quality because you wind up focusing the things that actually matter in the real world rather than the things you think might matter.

This is how I've always approached working with offshore devs too. Focus on testing for quality control, not "code quality". After all, you're going to look at the code you wrote 5 years ago and think it's shit anyway right? So all your code is shit.

Regarding "lack of understanding", here's a recent anecdote: I had a bug in a production (but relatively new) system. The customer was texting me saying that they couldn't scan a QR code because it kept "skipping and glitching". They sent me a short video. I described the problem to the agent and it figured out WAY faster than I would have been able to that the customer's clock was set incorrectly. They turned on network time and bingo bango, the thing worked straight away.

I don't thing "comprehension debt" matters at all, because if you want to know something about the code you ask the agent. I can't remember how anything works after 12 months anyway, so I would frequently have to spend ages grepping my own code when a customer came back and asked me to change something in a system we hadn't touched since last year. Asking an agent the same thing takes minutes and is way more accurate (and fun!)

Most code just has to be good enough.

Coding part of the job (as in „typing with my bare hands“) is gone. Now I get to spend more time making product decisions, capturing constraints and executable specs. Resulting code is boring, consistent and gets the job done.

If your average per request in the application layer is say 20ms. Your p50 is probably 10-15ms and your p99 is probably something like 80ms. p99.9 is probably a good bit higher than that.

If your site is highly interactive, everyone using it is going to regularly run into actions that take long enough that they notice them, and it won’t feel snappy.

Let’s say you went all out and wrote the application layer in C with purely static allocation. You could easily see a p50 around 1-2ms and a p99 of 3-5ms. (This is obviously dependent on the app).

Even with an average time spent waiting in the database of 80ms, you’ve already made a noticeable difference.

That’s not even mentioning the biggest impact, which is that you can likely get by with far fewer application servers.

Now does it make even more sense to optimize your queries? Yes. Definitely. But with faster application stack you can start moving more things into the application layer and out of the database which is generally harder to scale.

And if you have or can build endpoints that don’t hit your database at all, those will actually be 10x faster than before every time.

https://github.com/rails/rails/graphs/contributors?from=6%2F...

Zero commits are from DHH. It seems he already handed reigns over to other people.

All this does is justify the people that have been trying to move on from DHH for years. If his politics didn't do it, or his bullying, maybe the fact that he doesn't even use Rails himself will pull the wool from their eyes.

Rails itself will continue. I see no reason to stop using it.

Not the flex you think it is, Dave!

Assuming no new paradigms on the hardware side that no longer fit into our current programming models, do they? Rails' claim to fame was eliminating "XML sit-ups" to improve the developer experience, but who cares how many "sit-ups" LLMs need to do?

Rails is very insular tech.

A lot of people bet their entire careers on Rails. I've worked on Rails shops, and the majority of developers have not touched another language in years. There are people who never shipped anything in anything but Rails, and haven't done anything in other language since college, or ever if they did a bootcamp.

I have even interviewed a significant number of people doing Rails for ten years who did not know it was possible to launch a Ruby application with `ruby script.rb`.

Not to mention that with the emergence of frontend frameworks, most Rails developers were doing API-only stuff, and barely interacted with the frontend.

I recently left a company that was moving to from Rails to Go (might have been partially my fault), and there were was a bit of a mutiny where several teams have refused to change languages.

DHH is pretty much saying AI is gonna eat this people alive.

Not to mention, those VB client/server apps were not as popular with users as HN likes to reminisce. And modern IT departments have often completely banished that stuff.

Anyway, the only logical conclusion clearly is that most Rails developers are over 40.