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.

No, but you always have the option to opt out of being a maintainer. If "the community" is going to behave badly and bury you under a barrage of vibeslop you can just leave.

EDIT: there's a version of this that could be positive--everything could get a hell of a lot more secure. But that doesn't seem to be what's happening.

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.

The performance of Ruby sucks, though.

I think good code is even more important now.

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.

none of this even kind of addresses why the article implies that people stopped writing good code. why are we going to spend "a lot more reading code than before"? is this an ai generated comment?

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.

Just because you or I may invest effort into deep-thinking, it does not mean that others will.

I'm not worried about this at Modal, but I am worried about this in the greater OSS community. How can I reasonably trust that the tools I'm using are built in a sound manner, when the barrier to producing good-looking bad code is so low

We’re already there. Seeing OpenClaw and the new thing LocalGPT on the front page. It’s clear these projects are pretty heavily vibe coded and I have no trust that they are tested, secure or even work as advertised. It’s going to suck when all projects become that. When you can’t trust that a library works as advertised.

> How can I reasonably trust that the tools I'm using are built in a sound manner, when the barrier to producing good-looking bad code is so low

Honest answer: You never could.

Hm? The article is pretty clear about two claims, IMO: (1) good code has been rare for a long time because the job is a pragmatic one and not a philosophical one but that sometimes "good code" pays off down the line, and (2) possibly the "pays off down the line" will be less important in the future with AI coding tools.

And the comment by 'ElatedOwl is pretty directly responding to that second idea.

LLMs also make refactoring for readability, simplicity and performance far easier.

Nothing has fundamentally changed! A good solution is a good solution.

I do worry that the mental health of developers will take a downturn if they’re forced into a brain rotting slop shovelling routine, however.

So yes readability and good concise code is still important.

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

I regularly show Claude Code a screenshot of a completely broken UI--lots of cut off text, overlapping elements all over the place, the works--and Claude will reply something like "Perfect! The screenshot shows that XYZ is working."

I can describe what is wrong with the screenshot to make Claude fix the problem, but it's not entirely clear to what extent it's using the screenshot versus my description. Any human with two brain cells wouldn't need the problems pointed out.

This is my experience as well. If CC does something, and I get broken results and reply with just an image it will almost always reply with "X is working!" response. Sometimes just telling it to look more closely is enough, or sometimes I have to be more specific. It seems to be able to read text from screenshots of logs just fine though and always seems to process those as I'd expect.

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.

Why not test the OLAP reports?

Surely there is a way to run a raw query in Rails/ActiveRecord and use it in a smoke test?

They call this Data Contracts.

I mean, if you're relying on tests to catch schema changes... then test your sql reports? This doesn't seem like an amzingly cool solution but if that's the one you're already using...

> As the recent US election has shown, it's not what you say - but how you say it, that counts.

Are you implying that Biden spoke with more confidence than Trump, but Harris did not?

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.

Since Rails 7.1 we've had https://www.rubydoc.info/github/rails/rails/ActiveRecord%2FR... which actaully does run queries in parallel.

There's also Rails' russian doll caching, which can actaully results in pages with n+1 queries running quicker than ones with preloaded queries. https://rossta.net/blog/n-1-is-a-rails-feature.html

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

If that’s a problem for you right now I’d suggest giving JRuby a look as it has no GVL and true multithreading.

Hopefully as Ractors mature that problem will be solved for MRI too.