rglynn

I think a lot of commenters here have no idea what Rails actually is, what it solves for, or why its good.

Their perspective is "Rails? Isn't that like, super old??"

> The corpus, and the refresh that changed the answer

I audibly went "ah!", as if in pain from a muscle twinge and immediately came back to the thread to find this comment.

Ain't no way I'm gonna spend my free time reading Claude-isms.

You guys are still using google?

Well put. After reading, I came here to say the same thing.

The times that I "Claude said:" are almost always a case where Claude gave the correct answer.

The real problem is if you paste "Claude said:" without reading what Claude said. Have seen this happen and goes something like:

Sr Engineer: "Claude said:"

Me: "But that doesn't make sense because of X"

Sr Engineer: (having actually engaged thinking effort: human) "Oh yeah, not sure why Claude said that, I think we should do Y instead"

Thank you for this response. I do think this hits home as the most elegant and reasonable approach. For my teams currently, I can see us already moving toward this implicitly, but perhaps needing to take a more explicit approach. I think your framing crystalises it well.

To me, the thing that stands out about the whole state we're in here is PR review.

Yes, in an ideal world, PRs read well, are a joy to review, reflect what you discussed etc etc. We have to be real; there is only so much we can do to that end.

I'm not sure how the best teams do PR review, from my perspective it sucks. I'm talking specifically about the UX. I've always hated Github's PR page, so I typically reviewed by pulling down the branch and opening the diff with $EDITOR.

These days I think there's really no excuse for the awful UX. Linear (a company that isn't even in the domain of code review) put out a basic PR review feature[0] that is already better than what GH offers. It's simple: point a small model at the PR, group file changes together based on theme, add some commentary and sort by importance (schema changes > openapi spec).

Immediately, so much mental load has been reduced without the reviewer or the requester doing anything. This feature is pretty damn basic, and I think there are obvious next steps like generating visualisations which a dedicated product could find the time to implement.

Keen to hear others thoughts on why this is the wrong approach, or if there are tools in wide use that solve for this, or why this isnt the right problem to focus on.

0 - https://linear.app/docs/diffs#guides

Ah good point! Let me just– oh dear, everyone's already dead.

It was posted in one of the other threads here: https://arxiv.org/abs/2512.24873

What do you mean by easy? Do you mean FAANG or equivalent salary? What level of seniority?

Can speak to my experience that if you are a senior engineer in London the market is relatively easy at the moment (or was at the beginning of the year) even with no connections.

I have no comment on sound mixing in general, but just to add context here, Chris Nolan intended[0] for the dialogue in some of the scenes to be inaudible over the score.

I think this is often difficult for people who treat films as logical instead of experiential.

Nonetheless, it is inaccurate to characterise it as poorly mixed, since the goal was for the score to somewhat drown out the dialogue, and the mixing achieves that goal. You can disagree that this is a desirable outcome for the viewer, but art is ultimately subjective.

0 - https://www.reddit.com/r/IAmA/comments/cjtlzp/comment/evg2js...

This is a US-centric take, in Europe, particularly in cities, we walk everywhere.

There is perhaps some relevance to the analogy however, because the US is designed in such a way that makes walking difficult to impossible. I am already seeing this pattern in vibe-coded areas where engineers will just use AI because it's too difficult to parse and edit by hand.

Depends on seniority and market, but my experience has not matched this. In my recent search I even had a company change their process at my request. Too many companies just copy the FAANG approach without considering if it suits their team(s).

We have some responsibility as candidates to tell HR departments and recruiters that some stuff doesn't fly.

I guess you can make the argument that legislating repairability will raise the price floor for devices because it increases the cost to the manufacturer. This isn't a problem for most of us in tech, but affordability can be an issue for many.

Imagining future possibilities and implementing software to account for them are two different things.

The argument here is to validate those possibilities before acting on them.

IME tok/s is only useful with the additional context of ttft and total latency. At this point a given closed-model does not exist in a vaccuum but rather in a wider architecture that affects the actual performance profile for an API consumer.

This isn't usually an issue comparing models within the same provider, but it does mean cross-provider comparison using only tok/s is not apples-to-apples in terms of real-world performance.

More often than not I've seen this be the case. Refactoring as "rewrite using my idiomatic style, so that I can understand it", which does not scale across the team so the next engineer does the same thing.

I like guns and cars, but not sports. How exactly is it performative? Both are engineering marvels and fascinating to watch videos about, and they also happen to be a load of fun.

I watch hours of videos on both with nobody else around and don't really talk about those topics with others much. So in the spirit of HN, I'm actually curious to know what about those interests is performative?

In reverse? What do you mean exactly?

As someone who is neither an Elon fan nor a hater, it irks me how deranged HN is about anything Musk-related.

Other than the inconvenience, is there any privacy risk in just having a separate device purely for those apps and nothing else?

Or is it more of a principle to resist this being forced on us?

I'm not sure where you live but a lot of countries don't have this (yet) or it is optional.

I think it's beneficial to hear this, as I've definitely been on the other side of this before now. So, thanks for sharing.

As much as we can fault the technology and the hype around it, this as much a people problem as anything else. Before AI, this same problem happened with architecture/PoC to implementation hand-offs.

AI is a new tool that a lot of us are still figuring out, but that doesn't excuse poor communication.

I mean to be fair, "Just use Postgres" will get 400 votes here without people even clicking TFA.

Agree with this tactic, very useful when working in a team. I use a --dry-run=false approach.

Capital, both social and economic.

Also data, see https://news.ycombinator.com/item?id=46637328

"... how much ram has the system" is a typo or an ESL mistake, so not an LLM.

This is just for the web interface, the API is staying for now.

IME 5.2-codex (high) is not as good as Opus 4.5, xhigh is equivalent but also consumes quota at a higher rate (much like Opus).

In the future?

I think of it this way:

Is your goal for the software you write to need constant intervention, or would you say you'd aim for it to run smoothly with few bugs?

The team is akin to a piece of software architecture, only much more complex and comprised (partially) of humans.

You want someone to build that team and then have the team up and running, delivering value. When it breaks, or you want it to do new/different things, you need someone to step in to fix it or change it.

They are basically the same, long black is water with espresso poured on top, americano is espresso with water poured on top.