Hacker News Reader

Comment by CodingJeebus | Hacker News Reader

I literally just patched an AI-generated API endpoint on a new service at work that shipped without any auth whatsoever, because AI was re-implementing the auth token check method individually in each child controller instead of implementing once in a before_action hook. That's Rails 101 stuff and the app is small. It was so obvious that I saw it right away just reading the code, I didn't even set an agent loose to do an initial inspection. It was a real "yeah I still got it" moment for me.

I'm on board with the idea that agents are going to write most of the code, but not checking it is just insane to me, based on some of the things I've seen committed in commercial codebases recently.

View on HN

One of the strengths of Rails was that it helped developers who maybe didn't always know the "best way" to build things to build in a standards compliant way – not that you couldn't do things like return a 200 for Not Found if you really wanted to etc.

I'm always pleased when working with a dev who has Rails experience even if they've since moved stack, as often they have picked up and learned the value of these good behaviours. Perhaps it's as much a community thing as a framework thing, or combination of both.

Agentic development definitely still has room to improve, but I suspect that there is some future framework (maybe even language) designed to help minimise these types of mistakes.

Interesting that all the patterns Rails adopted for humans to write better code can't easily be funneled into the LLM doing the job now. Seems like it should be.

Is it types? Are types the answer? Is it rust?

I think the issue with Rails, as a long time developer in that ecosystem, is that much of the default assumptions are a) not common (not so far off-piste that a human can't get used to them, but outside the center of the bell curve), and b) not explicit. So it's very common to do things like install a plugin that has across-the-repo effects but that is only documented in e.g. the config directory and the bundle. Unlike, say, NPM, when you install a new package where you explicitly have to e.g. import it everywhere you want to use it.

As time has gone on Rails has gotten better about this, but it still means that "your rails" and "my rails" are different enough that AI could easily get confused.

As you say, the other aspect is the intense dynamism which works against AI, which again prefers to have everything explicit and reasonable about from the text.

So I ended up going back to Javascript after a brief 12 year digression into Ruby. I still love Ruby but it's just not the right language for the current environment and team structures - typescript is "worse is better" in the right ways that it's a much better choice for both frontend/backend being the same and better type systems.

Sorry, but what’s “install a plugin” in rails? That’s not a thing; not even a thing someone who’s ever worked on a rails app would say by mistake.

How certain are you about that? https://guides.rubyonrails.org/v2.3/plugins.html

Back in the very early days you would have used script/plugin install (svn url)

Here's one of my mirror repositories migrated from SVN into git. https://github.com/jaggederest/acts_as_voteable

Types are great. No nulls are great. Exhaustive switches are great. Derive macros and Serde are great. Detailed errors are great.

However Rust has one serious problem, BUILDS. It’s slow and it takes up a ton of space and memory. You will be working around this on any sizeable codebase. Using cargo check to ration your compiles, a dedicated build box, etc. Now imagine you're using it for a web application with compiled maud templates... you're potentially waiting minutes to see your changes.

If we accept that over half of the people building with rust are using agents (I'm sure this is much higher in reality), then you should also accept that there is a ton of time and resources spent on building / compiling. Optimizing this should probably be a top priority. They need someone who will be fanatical about shaving time and memory use from the build process.

Sounds like OCaml has the answer then. It has the equivalent of all the great things you described in Rust, plus compile speeds similar to or better than Go. Agents should be able to blaze through changes with it.

Sounds like I should check in on rust in a year or so.

Yeah. I'm going through an exercise right now with a large codebase where I'm split some of it up into crates so that iterating on specific parts incurs less build overhead. Literally changing my architecture... which annoyed me a bit, but it does make sense.

> Agentic development definitely still has room to improve, but I suspect that there is some future framework (maybe even language) designed to help minimise these types of mistakes.

Maybe there will be one day, but what are the odds that it will meaningfully move the needle for existing platforms such that manual code review is unnecessary? "Blindly trust the output" is not a feasible security posture today.

I still review PRs, but rarely suggest changes. The most meaningful reviews come from our review bots. I mostly review broad architectural decisions as a way to keep abreast of changes in the codebase. There's a cohort of engineers I work with who I would be perfectly okay with letting the clankers review, approve, and merge their PRs. But there's a larger cohort of engineers who need what I would call a directional code review.

Software engineering is so back.

When designing systems, you want the important details to be right. Especially with authentication and authorization.

From an architecture level, you can know which classes are important to review and which ones are not.

Yeah that is how I see it.

In Software Engineering, we learned about requirements, testings, system design, UMLs, etc, and those seems to be more relevant than ever.

Agile is dead. It presumed writing the code was the slowest part of the cycle. Now it makes more sense to only start writing code when the requirements are known as the code is quick and low cost to change if/when the requirements change later.

There are two problems that arise from cheap code:

1. You get complexity back at the speed that you add code. Also the complexity compounds.

2. As a human you are still responsible for your code, and you need to understand how the important parts of the code base work.

When you combine these problems, you get a complicated code base where you don't understand the important parts.

That is why software design is getting a comeback. It actually helps with both problems. Less complexity and more understanding.

Agreed, this is very critical point, I always thought big part of software engineering is the art and science of managing ever-growing complexity.

The part I'm still not sure about is the 2nd point, I just don't know how good those LLMs will get at managing complexity and how important is for human to understand the details of the code. I'm personally not sure yet..I could imagine a future where we have have much more higher level tools to manage the comprehension and complexity challenges. Or it could be that LLMs will never fully comprehend the full architecture and humans will always be needed for that kind of big-picture analysis. I really don't know, and frankly I don't think anybody knows.

Why do you think an AI audit (say from Fable/Astra at xhigh) wouldn't have caught this?

What model though?

Reply on news.ycombinator.com