the point of that section is that attackers and security researchers will use / are using loops, and you as the maintainer are not able to opt out of others doing this. an unwilling participant.
My favorite part of Ruby is the testability. You can test anything, easily, without having to make interfaces and other design decisions specifically around tests.
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.
half the time you’re going to discover the right decision / path while you’re coding.
focus time went from hammering code to figuring out how to solve the problem. PRs are now how we exchange ideas. meetings are still productivity theater.
The author effectively argues deep thinking is dead, that people are no longer going to take the time to understand the problem and solution space before they solve it.
I think that’s untrue, I think it’s /more/ important than before. I think you’re going to have significantly more leverage with these tools if you’re capable of thinking.
If you’re not, you’re just going to produce garbage extremely fast.
The use of these tools does not preclude you from being the potter at the clay wheel.
People talk about writing the code itself and being intimate with it and knowing how every nook and cranny works. This is gone. It’s more akin to on call where you’re trudging over code and understanding it as you go.
Good code is easy to understand in this scenario; you get a clear view of intent, and the right details are hidden from you to keep from overwhelming you with detail.
We’re going to spend a lot more time reading code than before, better make it a very good experience.
> This post brings up a lot of (imo true) points that I honestly can't share with the ai-lovers at work because they will just get in a huff. But the OP is right - we automate stuff we don't value doing, and the people automating all their code-gen have made a very clear statement about what they want to be doing - they want _results_ and don't actually care about the code (which includes ideas like testing, maintainability, consistent structure, etc).
I havent run into this type yet, thankfully. As an AI lover, the architecture of the code is more important than before.
* It’s harder to understand code you didn’t write line by line, readability is more important than it was before.
* Code is being produced faster and with lower bars; code collapsing under its own shitty weight becomes more of a problem than it was before.
* Tests/compiler feedback helps AI self correct its code without you having to intervene; this is, again, more important than it was before.
All the problems I liked thinking about before AI are how I spend my time. Do I remember specific ActiveRecord syntax anymore? No. But that was always a Google search away. Do I care about what those ORM calls actually generate SQL wise and do with the planner? Yes, and in fact it’s easier to get at that information now.
I keep seeing “Claude image understanding is poor” being repeated, but I’ve experienced the opposite.
I was running some sentiment analysis experiments; describe the subject and the subjects emotional state kind of thing. It picked up on a lot of little detail; the brand name of my guitar amplifier in the background, what my t shirt said and that I must enjoy craft beer and or running (it was a craft beer 5k kind of thing), and picked up on my movement through multiple frames. This was a video slicing a frame every 500ms, it noticed me flexing, giving the finger, appearing happy, angry, etc.
I was really surprised how much it picked up on, and how well it connected those dots together.
This will get written off as victim blaming, but there’s some truth here.
I don’t use Claude code for everything. I’ve fallen off the bike enough times to know when I’ll be better off writing the changes myself. Even in these cases, though, I still plan with Claude, rubber duck, have it review, have it brainstorm ideas (“I need to do x, I’m thinking about doing it such and such way, can you brainstorm a few more options?”)
I agree with that being fastest, but not cheapest.
In my experience these one off reports are very brittle. The app ends up making schema changes that are breaking to these one off reports, and you usually don’t find out until it goes to production.
I’ve dealt with the maintenance nightmare before. At current gig we’re exploring solutions, curious what a robust pipeline looks like in 2025.
The ORM piece is interesting — we use ActiveRecord and Ruby, and accidentally breaking schema changes within app will get caught by the unit test suite. I would love for a way to bring OLAP reports in similarly to test at CI time.
load_async is still concurrency, but not parallelism. The queries themselves can run parallel, but when materializing AR objects e.g., only one thread can run at a time. A greedy thread in process will still subject you to GVL waits
I spent 10 years doing C#, and the last 3 doing Ruby. I never thought of N+1 as that big of an issue. These queries are typically fast (1ms * 100 is still only 100ms…) and multithreaded web servers are non blocking on IO like database calls.
But these sporadic elevated response times kept showing up on endpoints, where they’d be hundreds of milliseconds slower than normal, but by some extension of 100ms. Say, normally 5ms, now taking 105ms, or 505ms, or more.
Then I learned about ruby’s non parallel but concurrent model, where within a process only one thread can execute at a time. In most workloads you’ll hit IO quickly, and the threads will play nicely. But if you have a CPU crunching exercise, it’ll delay every other thread waiting to execute by 100ms before it preempts. Now consider you’re doing 10 1ms queries inter process with a greedy thread, and you’re waiting at minimum 1010ms.
Still love Ruby but the process model gave me a reason to hate N+1s.
Writing is really beneficial for exploring the problem space.
Many times I’ve confidently thought I understood a problem, started writing about it, and come away with new critical questions. These things are typically more visible from the abstract, or might not become apparent in the first few release milestones of work.
I’m reminded of a mentor in my career, who had designed an active/active setup retroactively for a payment gateway. He pulls up a Lucidchart and says “this diagram represents 6 months of my life”.
They’re not always necessary or helpful. But when they are you can save weeks of coding with a few days of planning.
I agree that LLMs capabilities with a language are going to be extremely relevant. Community, API consistency, and whatever other factors that are going to increase LLM usefulness will decide the popularity of languages in the coming years.
I’m not sold on the importance of static typing though. I’ve had great results with Ruby and Python with 4o, o1, and to a limited degree Copilot.
One of the biggest benefits of Ruby is how simple testing is. The language is so dynamic that mocking/stubbing and intercepting or whatever is dead simple stupid.
So the “static types prevent you using LLM hallucinations” does not hold for me. I’m going to write tests covering the method (which the LLM will probably help with), and I’m going to get an undefined method error.
Agree the DB side is overstated. These particularly suck though in ruby on multithreaded servers (eg puma), where N+1s are constantly giving control of the GVL to another potentially greedy thread. I’m sure python multithreaded servers will suffer similarly.
I manage at a lower level, a team of developers. I’m a big fan of stating a clear goal and letting the developer/team decide how to tackle. I may have suggestions, I may veto proposed solutions if I have legitimate problems with it, but ultimately I want them to be the drivers. In my experience they take ownership, are more motivated, and it helps them grow. They’re more likely to solve little problems on their own and only involve me as needed.
Spot on with cost, as with everything you have to be pragmatic.
Tests are great for:
* High risk items (large consequence when it goes wrong)
* Documentation
* Weird unintuitive things
We had a C# project recently that needs to detect changes between a DTOs properties. At implementation, all the comparisons would be done over value types, but if someone added a reference type that didn't properly implement equality this would silently fail (likely for months). Good case for adding a test that ensures the change detection works for all properties.
For portable non-concentrate, Mighty by Storz and Bickel is hands down the best device I've used. The engineering is flawless: amazing battery life, extremely durable, easily replaceable wear/tear parts, use while charging, fast heat up times, a poker built into the base of it... I could go on. It was pricey but I've had it 4+ years, with no signs of decaying battery life or any non wear/tear part replacement, despite a lot of use and a lot of abuse.